软件测试_用例篇

软件测试_用例篇

1.评价测试用例的标准
（1）用例表达清楚，无二义性
（2）用例可操作性强
（3）用例的输入与输出明确，一条用例只有一个预期结果
（4）用例的可维护性好
（5）用例对需求的覆盖率高
（6）暴露程序bug的能力强
2.测试用例带给我们的好处
（1）测试执行者的依据
（2）使得工作可重复，自动化测试的基础
（3）评估需求覆盖率
（4）用例的复用
（5）积累测试的方法思路以供后续借鉴
3.测试用例带给我们的困扰
测试用例的设计是费时费力的工作，往往设计测试用例所花费的时间比执行所花费的时间还多
测试用例的设计方法
（1）测试用例的总体设计方法
基于需求的设计

• RBT是基于需求的测试方法，会使测试更加有效，因为他使测试专注于质量问题产生的根源，即需求

• 基于需求的测试是一种最根本的软件测试，需要关注以下两个问题：
  （1）验证需求是否正确、完整、无二义性，并且逻辑一致
  （2）从“黑盒” 的角度，设计充分且必要的测试集，来保证设计和代码都能完全符合需求
  （2）具体的设计方法

• 等价类

依据需求将输入划分成若干等价类，从等价类中选出一个测试用例，如果测试用例测试通过，则认为所代表的等价类测试通过。用较少的测试用例达到尽量多的功能覆盖，解决了不能穷举测试的问题
（1）有效等价类：可以验证程序是否是实现了规格说明中所规定的功能和性能
（2）无效等价类：依据需求说明书，不满足需求的集合
缺点：等价类只考虑输入，没有考虑到输出，因此需要其他的设计方法补充

• 边界值
  边界值分析法是对输入和输出的边界值进行测试的一种黑盒测试。是对于等价类划分法的补充。其测试用例来自等价类的边界

• 因果图

因果图是一种简化了的逻辑图，能直观的表明程序输入条件（原因）和输出动作（结果）之间的相互关系。借助图形来设计测试用例，适合被测试程序具有多种输入条件、程序的输出又依赖于输入条件的各种情况

• 恒等：如果原因为真，那么结果必定为真（动物园运来大熊猫，那么动物园一定有大熊猫）

• 与：只有两个原因都为真，那么结果为真（北京姑娘，必须有房且有车）

• 或：2个原因中有一个为真时，结果就为真（北京姑娘，有房或者有车）

• 非：只有原因为假，结果才为真（你不好好学习，你会找到好工作）
  因果图设计测试用例的步骤：
  （1）分析所有可能的输入和输出
  （2）找出输入与输出之间的对应关系
  （3）画出因果图
  （4）将因果图转换成判定表
  （5）把判定表对应到每一个测试用例
  缺点：对于复杂的输入和输出，会耗费大量时间

• 正交排列

正交法是为了减少用例数目，用尽量少的用例覆盖输入的两两组合
正交试验设计：根据正交性，从试验因素的全部水平组合中挑出部分具有代表性的点进行试验，通过这部分的试验结果分析了解全面试验的情况，找出最优的水平组合。是一种基于正交表的、高效率的、快速的、经济的试验
因素： 在一项试验中，凡是欲考察的变量称为因素（变量）
水平（位级）： 在试验范围内，因素被考察的值称为水平（变量的取值）
正交表的构成
**行数：**正交表中行的个数，即试验的次数（N）
因素数： 正交表中列的个数（C）
水平数： 任何单个因素能够取得的值的最大个数（T）
正交表的两条性质：
（1）每一列中各数字出现的次数都一样多
（2）任何两列所构成的有序数对出现的次数一样多
正交法设计测试用例的步骤：
（1）有哪些因素（变量）
（2）每个因素有哪几个水平（变量的取值）
（3）选择一个合适的正交表
（4）把变量的值映射到表中
（5）把每一行的各因素水平的组合作为一个测试用例
（6）加上你认为可疑且没有在表中出现的用例组合

• 场景设计法
  用业务流把各个孤立的点串起来，为测试人员建立整体业务的感觉

• 错误猜测法
  基于经验和直觉，找出程序中你认为可能出现的错误，有针对性的设计测试用例。（经验丰富）

测试用例的粒度
粒度：测试用例编写的详细程度
（1）测试用例编写的过于复杂，会带来两个问题：效率问题、维护成本问题。另外，如果过于详细，那么留给测试人员的思考时间就会比较少，容易限制测试人员的思维
（2）测试用例编写的过于简单。过于简单的测试用例设计并没有进行设计，而是把需要测试的功能模块记录下来而已，作用仅仅是在测试过程中作为一个简单的测试计划，提醒测试人员测试的主要功能包括哪些而已。

测试用例的设计的本质是在设计的过程中理解需求，检验需求，并把软件系统的测试方法的思路记录下来，以便指导将来的测试

设计怎样粒度的测试用例主要考虑一下内容：
（1）产品的质量要求
（2）项目对用例的要求
（3）测试时间和资源是否充分

• 测试用例的评价
  （1）同行评审
  最敏捷的方式。测试用例的目的是尽可能的全面覆盖需求，而测试人员总会存在某方面的思维缺陷，一个人的思维总是存在局限性，因此需要一起设计测试用例
  （2）用户检查
  引入用户参与测试用例的设计中
  （3）项目组评审
  由测试负责人组织协调开展会议，用例编写人员对用例进行讲解，参会人员有异议当场提出