测试的用例与测试计划的基础知识

一、测试基础

1、测试分类：功能测试、用户体验测试、性能测试、UI测试、兼容性测试、安装测试、文档测试、 稳定性测试等

2、软件测试的需求标准:

a、文档版本信息：包含文档版本，作者，完成日期，修订版需要加上修订记录（版本号，修订者，日期，内容）。

b、目录结构要清晰，不同级别的标题要区分字号。

c、产品架构：一般只有功能以及信息架构，

d、功能：一级-二级，三级功能要划出。以及产品特性（功能列表，原型界面，详细设计）

e、其它产品需求需根据公司产品需求来定，如（兼容性，产品运营，性能要求等）。

二、测试用例的基本信息

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

2、测试用例好处：

a、在开始实施测试之前设计好测试用例，可以避免盲目测试并提高测试效率。

b、测试用例的使用令软件测试的实施重点突出、目的明确。

c、在软件版本更新后只需修正少部分的测试用例便可展开测试工作，降低工作强度、缩短项目周期。

3、测试用例特性：

代表性：能够代表并覆盖各种合理的和不合理、合法的和不合法的、边界的和越界的以及极限的输入数据、操作等。

针对性：对程序中的可能存在的错误有针对性地测试

可判定性：测试执行结果的正确性是可判定的，每一个测试用例都应有相应的期望结果

可重现性：对同样的测试用例，系统的执行结果应当是相同的。

4、测试用例包含的内容：用例编号、所属模块、用例标题、优先级、前置条件、输入数据、操作步骤、预期结果、实际结果、是否通过、测试人员、测试时间

三、编写测试用例基本方法

1、等价类划分法

应用场景：多用于输入框

等价类划分是指分步骤地把海量（无限）的测试用例集减得很小，但过程同样有效。

等价类 ：何为等价类，某个输入域的集合，在这个集合中每个输入条件都是等效的。

一般可分为有效等价类和无效等价类

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

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

如：计算两个1～100之间整数的和。

2、边界值法

边界值法：选取正好等于、刚刚大于或刚刚小于边界值作为测试数据

应用场合：有数据输入的地方，一般可以使用边界值法。边界值法往往跟等价类划分法一起使用，从而形成一套较为完善的测试方案。

上点：有效等价类和无效等价类之间的分界点。（最大值、最小值）
　　　　离点：边界值左右两边相邻的点是次边界值点。

3、场景法

应用场景：

a、界面特点：没有太多填写项，主要通过鼠标的点击、双击、拖拽等完成操作
b、把自己当做最终的用户，在使用该软件的时候，可能会遇到哪些情形（场景）如：银行ATM取款

主要目的是测试软件的主要业务流程、主要功能的正确性和主要的异常处理能力

场景法：通过运用场景来对系统的功能点或业务流程的描述，从而提高测试效果的一种方法。用例场景来测试需求是指模拟特定场景边界发生的事情，通过事件来触发某个动作的发生，观察事件的最终结果，从而用来发现需求中存在的问题。我们通常以正常的用例场景分析开始，然后再着手其他的场景分析。场景法一般包含基本流和备用流，从一个流程开始，通过描述经过的路径来确定的过程，经过遍历所有的基本流和备用流来完成整个场景。场景主要包括4种主要的类型：正常的用例场景，备选的用例场景，异常的用例场景，假定推测的场景。

 用例场景是通过描述流经用例的路径来确定的过程，

基本流：采用直黑线表示，是经过用例的最简单的路径（无任何差错，程序从开始直接执行到结束）

备选流：采用不同颜色表示，一个备选流可能从基本流开始，在某个特定条件下执行，然后重新加入基本流中，也可以起源于另一个备选流，或终止用例，不在加入到基本流中；（各种错误情况）

 

 

4、正交表法

应用场景：在一个界面中有多个控件，每个控件有多个取值，控件之间可以相互组合，不可能（也没有必要）为每一种组合编写一条用例，如何使用最少最优的组合进行测试。——正交排列法，如打印时文字的设置

 

判定表，因果图也是考虑控件组合，但是组合数量较少（一般不会超过20中）

 

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

a、用最少的实验覆盖最多的操作，测试用例设计很少，效率高，但是很复杂；

b、对于基本的验证功能，以及二次集成引起的缺陷，一般都能找出来；但是更深的缺陷，更复杂的缺陷，还是无能为力的；

c、体的环境下，正交表一般都很难做的。大多数，只在系统测试的时候使用此方法。

5、因果图法

因果图法比较适合输条件比较多的情况，测试所有的输入条件的排列组合。所谓的原因就是输入，所谓的结果就是输出。

图形符号：

恒等：若原因出现，则结果出现；若原因不出现，则结果不出现。

非（～）：若原因出现，则结果不出现；若原因不出现，则结果出现。

或（∨）：若几个原因中有一个出现，则结果出现；若几个原因都不出现，则结果不出现。

与（∧）：若几个原因都出现，结果才出现；若其中有一个原因不出现，则结果不出现。

E（互斥）：表示两个原因不会同时成立，两个中最多有一个可能成立

I（包含）：表示三个原因中至少有一个必须成立

O（惟一）：表示两个原因中必须有一个，且仅有一个成立

R（要求）：表示两个原因，a出现时，b也必须出现，a出现时，b不可能不出现

M（屏蔽）：两个结果，a为1时，b必须是0，当a为0时，b值不定

6、判定表法

7、错误推测法

错误推测法：根据经验或直觉推测程序中可能存在的各种错误，从而有针对性地编写检查这些错误的测试用例的黑盒测试方法

 

例如，测试手机终端的通话功能，可以设计各种通话失败的情况来补充测试用 例：

1) 无SIM 卡插入时进行呼出（非紧急呼叫）

2) 插入已欠费SIM卡进行呼出

3) 射频器件损坏或无信号区域插入有效SIM卡呼出

4) 网络正常，插入有效SIM卡，呼出无效号码（如1、888、333333、不输入任何号码等）

5) 网络正常，插入有效SIM卡，使用“快速拨号”功能呼出设置无效号码的数字

技巧：最重要的是要思考和分析测试对象的各个方面，多参考以前发现的bug的相关数据，总结的经验，个人多考虑异常的情况、反面的情况、特殊的输入，以一个攻击者的态度对待程序，就能设计出比较完善的测试用例来。

四、测试用例的评审与变更

1、首先要清楚内部评审的定义，是测试组内部的评审，还是项目组内部的评审。评审的定义不同，内容也不会相同。

如果是测试组内部的评审，应该着重于：

a.测试用例本身的描述是否清晰；

b.是否考虑到测试用例的执行效率.往往测试用例中步骤不断重复执行，验证点却不同，而且测试设计的冗余性，都造成了效率的低下；

c.是否针对需求文档，测试用例是否覆盖了所有的软件需求；

d.是否完全遵守了软件需求的规定。这并不一定的，因为即使再严格的评审，也会出现错误，应具体情况具体对待。

如果是项目组内部的评审，也就需要评审委员会来做了，角度不同，评审的标准也不同。比如收集客户需求的人员注重你的业务逻辑是否正确，分析软件需求规格的人注重你的用例是否跟规格要求一致，开发负责人会注重你的用例中对程序的要求是否合理。

测试用例的评审能够使用例的结构更清晰，覆盖的用户场景更全面对于测试工程师来说也是一个快速提高用例设计能力的过程。

2、参与评审人员

这里会分为多个级别进行评审。

1)部门评审，测试部门全体成员参与的评审。

2)公司评审，这里包括了项目经理、需求分析人员、架构设计人员、开发人员和测试人员。

3)客户评审，包括了客户方的开发人员和测试人员。这种情况在外包公司比较常见。

3、评审内容

评审的内容有以下几个方面

1)用例设计的结构安排是否清晰、合理，是否利于高效对需求进行覆盖。

2)优先极安排是否合理。

3)是否覆盖测试需求上的所有功能点。

4)用例是否具有很好可执行性。例如用例的前提条件、执行步骤、输入数据和期待结果是否清晰、正确期待结果是否有明显的验证方法。

5)是否已经删除了冗余的用例。

6)是否包含充分的反面测试用例。充分的定义，如果在这里使用2&8法则，那就是4倍于正面用例的数量，毕竟一个健壮的软件。

7)是否从用户层面来设计用户使用场景和使用流程的测试用例。

8)是否简洁，复用性强。例如，可将重复度高的步骤或过程抽取出来定义为一些可复用标准步骤。

4、评审的方式

1)召开评审会议。与会者在设计人员讲解之后给出意见和建议，同时进行详细的评审记录。

2)通用邮件与相关人员沟通

3)通用IM(办公通讯)工具直接与相关人员交流

方式只是手段，得到其它人员对于用例的反馈信息才是目的。

无论采用那种方式，都应该在沟通之前把用例设计的相关文档发送给对方进行前期的学习和了解，以节省沟通成本。

5、测试用例的变更

测试用例并非一成不变。如果软件修改之后发生变化，或者需求发生变更，那么测试用例便不再满足当前版本软件的测试需求，由此需要进行修改和变更操作。

五、测试计划

测试用例模板包括：用例编号、所属模板、用例标题、用例优先级、前置条件、输入数据、操作步骤、预计结果、实际结果、是否通过、测试人员、测试时间

测试报告模板包括：测试目标、测试依据、测试范围、测试环境、测试进度、进度结果、缺陷分布、测试结论、建议、附录等。

测试计划模板包括：确定测试范围、制定测试策略、测试资源安排、人员的分配、时间安排、风险分析等。

测试方法：等价划分法、边界值法、场景法、正交法、因果图法、错误推测法。