No.8 测试用例的编写和用例评审

1.什么是测试用例：

TestCase是为了某个特殊目标而编制的一组测试输入，执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。

总结：每一个测试点的数据设计和步骤设计。

2.测试用例的重要性：

1.测试用例是软件测试的核心，影响软件测试的因素很多，例如软件本身的复杂程度，开发人员（包括分析，设计，编程和测试人员）的素质，测试方法和技术运用等等，因为有些因素是客观存在的，无法避免，有些因素则是不稳定的，波动的，例如开发团队是流动的，有经验的走了，新人不断补充进来。人工作会受到情绪等因素的影响，有了这些因素，软件测试的稳定性就会受到影响，但是有测试用例，无论是谁来测试，参照测试用例实施，都能保障测试的质量。可以把人为因素的影响减少到最小，即便最初的测试用例考虑不周全，随着测试的进行和软件的更新，也将日趋完善。

因此测试用例的设计和编制是软件测试活动中最重要的，测试用例是测试工作的指导，是软件测试必须遵守的准则。

2.评估测试结果的基准；

3.好的测试用例，不仅方便自己和别人查看，而且能帮助软件设计时考虑的更周全，因此测试用例的编写和设计一样也是非常重要的。测试用例要有执行性（指导性）。

3.测试用例的内容：

（1）用例ID：可以定义测试用例的编号，便于查找测试用例，便于测试用例的跟踪。

产品名-子系统-测试项-xxx，例如：WX-HB-001,QQ-RZ-biaoTi-001，QQ-KJ-SS-FB-001；

（2）用例名称：是测试用例的编辑的名称代号，输入内容+结果（手机号为汉字，界面提示）见名知意；

（3）测试目的：也就是测试用例的目标和使其过程中所要达到的最终要求；（可省略）；

（4）测试级别：也就是指测试用例的等级划分。高中低，或者 1 2 3 4等；

（5）测试环境：软件+硬件环境（一般是兼容性测试时填写）；

（6）测试数据：测试用例是“一组输入，执行条件，预期结果‘，毫无疑问地应该包括清晰地输入数据和预期输出，没有测试数据的用例最多只具有执行性意义，不具有可执行性；

（7）前置条件：执行用例的前置条件；

（8）测试步骤：也就是指测试用例所需要地详细操作过程；（有效的用例可以整合到一条用例中，冒烟测试可以只包括正常情况的一种即可，其余的有效情况可整合在子模块中）页面存在的元素加上双引号，要与页面名称一致，如：在输入框中输入“昵称”：xxxxx

（9）预期结果：每条测试用例地期望结果；（预期结果每一步与实际操作步骤相对应）

（10）实际结果：实际测试结果；

（11）所属模块 子模块

界面显示的专业名词：

①下拉框:

 

②输入框：

 

③按钮：

 

④单选框：

 

⑤复选框：

 

⑥菜单栏：

4.如何编写测试用例：

（1）对测试需求进行分析，依照不同的功能模块列出测试点（详细）；

（2）选择等价类，边界值，错误推测法等测试用例设计方法，根据测试点命名为不同的测试标题，并补充相应的测试步骤及测试数据，预期结果；

（3）测试用例覆盖所有用户需求，包括单个功能和业务功能的覆盖，正面（有效等价类）和反面（无效等价类）用例的覆盖；

（4）编写测试用例注意编写格式，元素包括测试编号，测试标题，预置条件，不存在冗余，重复，二义性（可能，也许，或许，是否）等等；

5.测试用例的原则：

（1）每一个测试点至少有一个测试用例与之对应；

（2）每个测试用例包含的测试步骤尽量不要超过10个，如果过多就进行拆分；

（3）每个步骤只包含一种情况，不能将多种情况放在一个步骤里；

（4）每个测试用例包含的测试步骤不得少于2个；

（5）测试用例设计时应该包含功能的边界情况、等价类等方法；

（6）对于流程尽量实现每个路径的覆盖；

（7）关注需求中特别提出的权限，必输项，初始值和计算结果等内容；

（8）测试用例设计根据测试范围进行评审检查，覆盖全部范围；

（9）功能测试时，根据界面，业务，数据流变化进行用例划分；

（10）测试用例不能只有自己看懂，要清晰明确；

6.用例评审的重要性：

①无论是初级测试工程师，还是高级的，还是专家级的，设计出来的测试用例都是需要经过评审；

②测试用例一般分配给每个人来设计，设计用例的人并不知道在具体执行的时候是否有问题，不能保证自己设计的用例能否覆盖完全；

③保证测试人员和开发人员对于被测试功能的理解的一致性，避免测试过程中针对不过测试人员与开发人员扯皮；

④需求人员参与评审，他们能帮助你找出更多问题，经常在测试的时候，有些细节是无法从需求文档上得知的，需要频繁和需求人员进行沟通（空格的处理，app软件更新）；

⑤现在很多人是项目外包或人员外包，那么完成每一项工作的第一件事就是提交客户评审，当然在提交给客户之前自己的team先评审一下最好，确保提交给客户高质量的产品；

⑥按照用力数量来评估工作量，用例不完整，工时给少了，实际测试的时候就等着加班吧；

7.用例评审的内容：

以会议评审为主，一般我们会在用例初步设计完成后，先进性测试组内部的评审，然后进行项目组内的评审。

用例评审的内容（用例检查清单）：

（1）测试用例是否按照公司定义的模板进行编写；

（2）测试用例本身的描写是否清晰，是否存在二义性；

（3）测试用例内容是否正确，是否与需求目标相一致；

（4）测试用例的期望结果是否确定，唯一；

（5）实际操作步骤与描述步骤相一致；

（6）测试用例是否覆盖了所有的需求；

（7）测试用例设计是否存在冗余性；

（8）测试用例是否具有可执行性；

（9）场景测试用例是否覆盖最复杂的业务流程；

（10）用例设计是否包含了正面，反面的用例；

（11）对于系统自动生成的输入项是否注明了生成规则；

（12）测试用例应包含中间和后台数据的检查；

（13）测试用例应有整齐而的名称和编号；

（14）测试用例应标注有执行的优先级；

（15）测试用例包含相关的配置信息：测试环境、数据、前置条件、用户授权等；

8.用例评审的流程：

参与用例评审的人员：

测试组内部评审：各个测试人员和测试负责人；

项目组内评审：产品，测试，开发；

问题1：为什么要有不同的人员参与评审？

每个人看待问题的角度不同，保证对需求理解的一致性；

流程：

（1）评审当天准备好测试用例；

（2）提前和大家说一下/协商，项目经理，测试负责人，测试人员，产品经理，开发人员，并把用例发给大家；

（3）召开会议评审，针对评审用例检查清单，评审过程中收集相关人员的反馈信息，并在此基础上进行测试用例更新，直到评审通过；

（4）由测试人员或项目经理进行用例评审后的确认；

9.用例评审后的确认：

为了节约时间成本，第一次评审尽量对用例设计考虑全面，提前发现其中的不足之处；但是第一次评审难免会要修修补补的地方，在评审时尽快地修复用例，不能在一两分钟修复地，记录袭来，在会议结束后进行修改。

如果改动不是很多的，可以发出邮件，标明修改部分，再最后确认最终版，如果需要进行二次评审，那么重新开始邀约会议做二次评审。

10.用例评审需要避免：

①测试点含糊用于，每个用例评审都应该确定最终版，少有矛盾或疑惑的需求点，都应该确认下来，不能含糊不清；

②杂乱无章的评审，有顺序有逻辑的进行评审是很重要的一点，如果只想按照自己的思路评审，不顾他人感受，那么就等同于做无用功，这样的用例执行出来也会有一定的质量风险；

③我们的测试用例需要经常更新：增加，删除，修改用例；