哈喽大家好哎呀，今天给大家普及一下测试用例如何设计，看牛逼的大佬们是如何测试的。

测试用例笔试题

出题：在一个页面上有一个输入框，一个计数器(count)按钮，用于计算一个文本字符串中字母a出现的次数，请设计一系列测试用例来测试这个web界面请添加图片描述
很多朋友可能拿到这道题的时候已经开始写下123了，但是从经验上来说，追求数量而非质量的倾向，是一种低效的工作方式。

特别是在有面试官在旁边看你答题的时候，请保持沉思者保持10-15秒
能够针对题目提出一些问题的候选者会被认为是更有潜质的测试人员，比如大写还是小写？只是英文输入吗？计算完成后文本会被清除吗？多次按下按钮会发生什么事情？诸如此类问题。

通常来说，我们考虑一个测试对象至少要从以下六个方面来考：

功能性
易用性
可靠性
性能
安全性
兼容性

如果你是一个测试菜鸟，从功能性出发，你可以会列出下一个典型的列表：

“banana”： 3 （一个合法的英文字）
“A” 和"a" ： 1 (一个简单有正常结果的合法输入)
“” : 0 （测试一个结果为0的合法输入）
NULL : 0 (简单的错误输入)
“AA” 和 “Aa” 和 “aa” （个数大于1并且所有字符都是a/A的输入）
“b” : 0 （一个简单的非空合法输入，结果为0）
“aba” : 2(目标字符出现在开头或者结尾，以寻找循环边界错误)
“bab” 1 (目标字符出现在中间)
space/tabs ： N （空白字符与N个A的混合）
不包含a的长字符串：N（N大于0）
包含a的长字符串：N

更优秀的测试工程师，会开始考虑后面五个方面，设计以下用例

质疑界面的外观，调色板和对比度（这与相关应用风格一致么？）
文本框太小了，建议加长以便显示更长的输入字符串
这个应用能否在同一台服务器上运行多个实例，多个用户同时访问是否会出现问题？
是否会根据用户的输入自动匹配内容？
建议使用真实的数据，如从词典或书中选择输入内容。
提出疑：“输入的数据是否会被保存”，输入字符串中可能会包含地址或者其他身份信息，并且这些信息如果被保存是否需要加密处理来保证用户数据的安全性。
输入html和javaScript脚背语言，看是否会破坏页面渲染。
尝试复制粘贴字符串
提出疑问：“计算足够快么？在大并发下如何使用”
提出疑问：“用户如何找到该页面”
提出疑问：“有快捷键的设置没有？比如输入完字符敲入回车而不是点击提交按钮是否可行”

还有一些测试点，只有经验丰富的测试工程师才会想到

意识到计算会通过URL-encodedHttp GET请求传递到服务器，字符串可能会在网络传输时被截断，因此无法保证支持多长的URL

建议将此功能参数化
考虑该应用是否应该国际化
考虑到其他语言的α
考虑输入法的半角和全角输入是否相同
考虑编写脚本或者手工采样来探知字符串长度的上线，然后确保在此区间内功能正常。
考虑背后的实现和代码。也许已经有一个计数器遍历该字符串
提出疑问：“HTTP POST方法和参数会被黑掉吗？也许有安全漏洞？”
用脚本创建各种有趣的排列组合和字符串特性，如长度、a的个数等，自动生成测试输入和验证

游戏测试123事

1. 设计步骤

1.1 文档阅读

一定不要不阅读需求文档，上来直接写需求用例，至少读三遍文档
1 细致理解功能设计意图和设计思路
2 避免粗略的理解带来的用例遗漏
3 一些重要的数据可能隐藏在不起眼的语句中
4 加深对功能的理解，否则随着时间的推移，可能会遗忘很多内容
- 带着思考去阅读，如果让你设计这个功能，还有更优的选择吗？

1.2 功能细节探讨

不明白的地方需要及时确认，切忌脑补想当然
尽量早额确认细节，最好在写之前就确认完毕
关注需求变更，需求变更之后，一定要跟程序和策划确认

1.3梳理逻辑

文档不一定是按照标准流程写的，而且经常存在功能交叉的地方
我们需要先梳理出框架之后，逐步细化

1.4 功能拓展性思考

设计缺陷思考：升级；拆解；道具；领取道具数量，次数
测试难点思考：领取次数，刷新（测试，不能直接等）
关联度思考：道具存储问题
特殊情况思考：断电，断网，服务器维护

1.5 兼容性相关思考

版本兼容：同时存在两个版本是，不同的版本
功能兼容：老的功能中添加新的英雄
操作系统版本兼容：mac和Windows
分辨率兼容：美术展示等

2.功能模块划分

2.1 功能模块划分时应遵循什么样的规则？

高内聚低耦合：购买月卡和购买单个分开
重整体，轻局部：从整体关注

2.2 功能模块划分有哪些较好的方法？

功能流程法：将功能的基本流程画出来。根据每个大的环节进行模块划分，然后再细化和差缺补漏。
举例子：银行ATM的取款功能进行模块划分：
插卡环节-> 密码登录环节->输入金额环节->取走钱币环节->取卡环节
举例子：Dota这款游戏进行模块划分：
dota->战斗中的内容->英雄->动画;技能
dota->战斗中的内容->道具
dota->战斗中的内容->地图
dota->战斗之外内容->账号登录，按键设置
按照类型划分法：按照功能包含的不同类型进行划分
兵种测试，道具测试
兵种：可以训练的不同兵种
道具：可以消耗道具和不可消耗道具
类型划分法比较适合用一个功能种类相对独立，种类之间关联度较低的情况

2.3 模块划分注意的事项

不同的划分方法适用于不同的场景，要具体问题具体分析
有时候一个功能选择结合多种方法进行划分
划分方法不重要，划分原则更重要一些
划分完毕后，要结合需求文档重新梳理，确保模块清晰。覆盖完整

3. 测试用例的编写

3.1 格式：

一个清晰的格式而非常重要
1可以让用例脉络清晰明了
2方便后续需求变化之后更新维护
3方便执行人员快速入手

首页内容
1、用例名称
2、用例对应的游戏版本
3、编写人，编写日期、备注
4、修改人、修改日期、修改备注

正文页内容
1、功能逻辑图
2、用例id
3、模块名称
4、测试先决条件
5、输入信息
6、输出结果
7、备注信息

关于格式需要注意的注意点

1.尽量保持逻辑清晰
2.尽量保持一个输入只对应一个输出
3.保证每次更新用例之后都有明确的记录标注
4、尽量保证每一个用例内格式统一

3.2 常用的测试用例编写方法

等价类划分
等价类：指的是在一个输入集合内。任何输入数据对数输出的验证来讲都是等效果的，所以我们只需要取少量代表性的就可以了
边界值就是对等价类的一种补充
因果图是输入和输出的一种关系判定表

3.3 测试用例编写注意事项

输入条件要单一明确，尽量不要使用容易引起误解的词语
输出要可判断且明确，最好不要用“显示正确”这种词汇
测试步骤要可执行
保持尽量高的覆盖度
能抽象的尽量抽象出来，避免无意义的冗余

4.测试用例整理与维护

需求变化后需要及时更新老的测试用例，并写清楚修改情况备注（修改内容，产品和开发负责人）
测试用例应该尽量避免冗余，如果遇到重复的用例，需要根据实际情况进行修改
注意测试用例的备份，写完后最好本地自己也备份一份，避免线上被人误删

2. 游戏bug详解

2.1 bug详解

发现bug仅仅是测试工作的开始

2.2 Bug的鉴定标准

与需求设计不符合
违背常识

2.3 BUG 的生命周期；

发现bug --> 提交给开发 --> 开发修复 --> 测试验证 --> 通过后关闭–> 上线前回归
测试验证如果不通过 --> 不通过继续指派给开发

2.4 BUG的等价划分：
P0：致命错误，需要立即修复，如宕机，重起性报错等
P1：严重错误，需要紧急修复，如功能流程错误、数值错误等
P2：一般错误，允许一段时间内修复，如功能的简单错误、界面错误等
P3：无关紧要的错误，允许延期修复，如错别字、某个像素点缺失等等
2.5 BUG的提报标准
标题：【模块名称】+ 简短描述
测试环境：标明测试用的版本，系统，服务器，账号等。
描述：bug的详细描述，卡住可继续前进，卡住不能走
重现步骤：重现bug修复后的结果
备注：log，截图等
2.6 BUG的验证标准：
严格按照复现步骤验证
去除测试环境影响
验证标准：需要注明验证的版本、服务器等
拓展：是否对其他功能有影响，做简单回归
注意点：验证不能只看前端展现，更应关注后端数据
2.7 BUG的跟踪与推动：
每个人都有责任跟踪自己的bug的修复状态
及时与开发沟通，了解修复状态并提供修复过程中的支持
久不能修复的bug需要与开发和上级确认如何处理
bug修复后，需要及时验证
2.8 BUG的数据分析：
1 从bug级别：P2等级bug比较多，P0、P1较少，说明项目可以
2 从项目人员bug数据：
3 功能模块bug数据