测试计划和测试用例

测试用例的概念和作用

什么是测试用例

• 是为某个业务目标，而编制的一组由测试输入，执行条件以及预期结果组成的案例。

测试用例的作用

• 在开始实施测试之前设计好测试用例，可以避免盲目测试并提高测试效率。
• 测试用例的使用令软件测试的实施重点突出、目的明确。
• 在软件版本更新后只需修正少部分的测试用例便可展开测试工作，降低工作强度、缩短项目周期
• 检验软件是否满足客户需求、体现一个测试人员的工作量、展现测试用例的设计思路

测试用例的四个特性

• 代表性：能够代表并覆盖各种合理和不合理、合法和不合法的、边界的和越边界的以及极限的输入数据、操作等
• 针对性：对程序中的可能存在的错误有针对性地测试
• 可判定性：测试执行结果的正确性是可判定的，每一个测试用例都应有相应的期望结果
• 可重现性：对同样的测试用例，系统的执行结果应当是相同的。

测试用例通常包括以下几个组成元素

• 用例编号、测试模块、用例标题、用例级别、前置条件、测试输入、执行操作、预期结果、实际结果…

用例示例

编写测试用例基本的方法

等价类划分法

应用场景：多用于输入框
概念：等价类划分是指分步骤的把海量的测试用例集减的很小，但过程同样有效 。
等价类：在某个输入域的集合，在这个集合中每个输入条件都是等效的，一般划分为 有效等价类和无效等价类

有效等价类：指符合《需求规格说明书》，输入合理的数据集合
无效等价类：指不符合《需求规格说明书》，输入不合理的数据集合

比如：一个青少年考试的分数（备注13-17岁为青少年）
假设青少年年龄为x,13<=x<=17,数学成绩为y：0<=y<=100
那么年龄按照等价类划分可分为x<13,13<=x<=17,x>17,有效等价类是13<=x<=17，无效等价类是x<13，x>17
数学成绩按照等价类划分可分为y<0,0<=y<=100,y>100,有效等价类是0<=y<=100，无效等价类是y<0，y>100

边界值法

```bash
　一般边界值分析是因为程序开发循环体时的取数可能会因为<,<=搞错。
         比如下面代码
　　for(int i = 0;i <100; i ++)
{
　　int j = i+1;
　　System.out.println("循环第“+j+"次")//循环地做某件事情
}
　　这里的程序是循环了100次，所以会做100次;
　　如果程序员不小心，把i <100写成i <= 100，则多循环添加一次，这时候边界值检查是一个很好的测试方法。

对数据进行软件测试，就是在检查用户输入的信息、返回的结果以及中间计算结果是否正确。即使最简单的程序要处理的数据量也可能极大，使这些数据得以测试的技巧是，根据一些关键的原则进行等价类的划分，以合理减少测试用例，这些关键的原则是：边界条件，次边界条件、空值和无效数据。

确定边界值的方法
选取正好等于、刚刚大于或刚刚小于边界值作为测试数据，在边界值中掌握上点和离点的取数。

比如 输入要求是1 ～ 100之间的整数，因此自然产生了1和100两个边界，我们在设计测试用例的时，要重点考虑这两个边界问题。

注明:边界值不是从每个等价类中挑一个作为代表，而是把每个等价类的边界都进行测试。

因果图法

概念：因果图法比较适合输条件比较多的情况，测试所有的输入条件的排序组合。所谓的原因就是输入，所谓的结果就是输出
因果图基本图形符号
恒等：若原因出现，则结果出现，若原因不出现，则结果不出现
非（~）：若原因出现，则结果不出现；若原因不出现，则结果出现。
或（∨）：若几个原因中有一个出现，则结果出现；若几个原因都不出现，则结果不出现。
与（^）：若几个原因都出现，结果才出现；若其中有一个原因不出现，则结果不出现。

因果图的约束符号

E(互斥)：表示两个原因不会同时成立，两个中最多有一个 可能成立
I（包含）：表示三个原因中至少有一个必须成立
O（唯一）：表示两个原因中必须有一个，且仅有一个成立
R（要求）：表示两个原因，a出现时，b也必须出现，a出现时，b不可能不出现
M（屏蔽）：两个结果，a为1时，B必须是0，当A为0时，B值不定

因果图测试用例
例如：有一个处理单价为2.5元的盒装饮料的自动售货机软件。若投入2.5元硬币，按“可乐”、“啤酒”、或“奶茶”按钮，相应的饮料就送出来。若投入的是3元硬币，在送出饮料的同时退还5角硬币。

分析这一段说明，我们可列出原因和结果
原因(输入)：
投入2.5元硬币；
投入3元；
按“可乐”按钮；
按“啤酒”按钮；
按“奶茶”按钮。
中间状态： ① 已投币；②已按钮
结果(输出)：
退还5角硬币；
送出“可乐”饮料；
送出“啤酒”饮料；
送出“奶茶”饮料；

判定法表


场景法

用力场景是通过描述流用例的路劲来确定的过程
这个流经过程要从用例开始到结束遍历其中所有基本流和备选流
基本流是从系统某个初始态开始，再将基本流和备选流结合起来，可以确定以下用例场景

基本流和备选流的区别

正交表法
正交表能够在因素变化范围内均衡抽样，使每次试验都具有较强的代表性，由于正交 表具备均衡分散的特点，保证了全面实验的某些要求，这些试验往往能够 较好或更好的达到试验的目的，
正交实验设计包括两部分内容：第一是怎样安排试验；第二，是怎样分析试验结果
应用场景:在一个界面中有多个控件，每个控件有多个取值，控件之间可以相互结合，不可能为每一种组合编写一条用例，如何使用最少最优的组合进行测试。 正交排列法

正交表测试用例设计方法的特点是什么？

1. 用最少的实验覆盖最多的操作，测试用例设计很少，效率高，但是很复杂
2. 对于基本的验证功能，以及二次集成引起的缺陷，一般都能找出来，但是更深的缺陷，更复杂的缺陷，还是无能为力的
3. 大体的环境下，正交表一般都很难做的，大多数，只在系统测试的时候使用此方法。

测试用例的评审和变更

首先要清楚内部评审的定义，是测试组内部的评审，还是项目组内部的评审。
评审的定义不同，内容也不会相同。
如果是测试组内部的评审，应该着重于：

1. 测试用例本身的描述是否清晰
2. 是否考虑到测试用例的执行效率，往往测试用例中步骤不断重复执行，验证点却不同，而且测试设计的冗余性，都造成了效率的低下；
3. ；是否针对需求文档，测试用例是否覆盖了所有的软件需求；
4. 是否完全遵守了软件需求的规定。这并不一定，因为即使在严格的评审，也会出现错误，应具体情况具体对待

如果是项目组内部的评审，就需要评审委员会来做了，角度不同，评审的标准也不同。
比如收集客户需求的人员注重你的业务逻辑是否正确，分析软件需求规格的人，注重你的用例的评审能够使 用例的结构更清晰，覆盖的用户场景更全面
5. 需要评审的原因
测试用例是软件测试的准则，但它并不是一经编制完成就成为准则。由于用例开发人员的设计经验和对需求理解的深度各不相同，所以用例的质量难免会有不同程度的差异。
6. 进行评审的时机
一般会有两个时间点。第一 是在用例的初步设计完成之后进行评审，第二是在整个详细用例全部完成之后进行二次评审。如果项目时间比较紧张，尽可能保证对用例设计进行评审，提前发现其中的不足之处。
7. 参与评审人员
这里会分为多个级别进行评审
1）部门评审，测试部门全体成员参与的评审
2）公司评审，这里包括了项目经理、需求分析人员、架构设计人员、开发人员和测试人员。
3）客户评审，包括了客户方的开发人员和测试人员。这种情况在外包公司比较常见
8. 评审内容
1）用例设计的结构安排是否清晰，合理，是否利于高效对需求进行覆盖。
2）优先级安排是否合理
3）是否覆盖测试需求上的所有功能点。
4）用例是否具有很好执行性。
5）是否已经删除了冗余的用例。
6）是否包含充分的反面测试用例。充分定义，如果在这里使用2/8法则，那就是4倍于正面用例的数量
7）是否从用户层面来设计用户使用场景和使用流程的测试用例
8）是否简洁，复用性强。

9. 评审的方式
   1)召开评审会议。与会者在设计人员讲解之后给出意见和建议，同时进行详细的评审记录。
   2)通用邮件与相关人员沟通
   3)通用IM(办公通讯)工具直接与相关人员交流方式只是手段，得到其它人员对于用例的反馈信息才是目的。无论采用那种方式，都应该在沟通之前把用例设计的相关文档发送给对方进行前期的学习和了解，以节省沟通成本。
10. 评审结束标准在评审活动中会收集到用例的反馈信息，在此基础上进行用例更新，直到通过评审。
    测试用例的变更
    测试用例并非一成不变，如果软件修改之后发生变化，或者需求发生变更，那么测试用例便不再满足当前版本软件的测试需求，由此需要进行修改和变更操作。

测试计划
—测试时间、工作量、人员
—由于每个人的思维存在局限性，每项测试最后安排不少于2个人测试，以便交叉测试进度安排
—最好能预留一段缓冲时间，用于应对计划的变更，以及让测试员有时间完善和补充测试用例
风险及对策
—可考虑建立后备机制
测试计划包括
测试背景、测试目标、测试范围、测试输出文档、测试策略、测试规模工作量分析、测试进程、测试进度及时间安排、测试资源、人力设备、风险管理
偶然性问题的处理

1. 发现bug之后，我们会先截图，如果确定是偶然性的问题，会将日志和截图 一起提单给开发定位；
2. 如果缺陷在当前版本无法复现，且缺陷的影响程度比较低，可以提交问题单进行跟踪，跟踪三个版本，如果后三个版本都无法复现，就可以关闭该缺陷；
3. 如果是很严重的Bug，比如导致系统崩溃等，并且，实在没有再次出现，除了要及时反馈给上级之外，最后还要写到测试报告中，说明出现了什么现象，但无法再现
   缺陷单包含要素
   缺陷标题、严重级别、问题所属模块、复现步骤、预期结果、实际结果、有关的日志和截图
   测试报告的主要内容
   人力投入、用例统计、问题单分类统计、遗留BUG情况、测试风险、测试对象评估、测试结论