入门级----需求的分析以及测试用例的设计与编写

PDCA循环（戴明循环）plan do check action

1、测试需求的分析和确定

2、测试计划

3、测试设计

4、测试执行

5、测试记录和缺陷跟踪

6、回归测试

7、测试总结和报告

 

1、测试需求的分析和确定

 

1.1需求规则说明书的检查要点

（关于怎样才能做好软件的需求分析工作，以及度量软件需求，请参考的《探索需求-设计前的质量》一书，《Exploring Requirements : Quality Before Design》）

例子：

1、是否覆盖了用户提出的所有需求项（完整性）

用户的原始需求素材（用户需求文档，用户提供的相关材料，调研记录，与用户的沟通记录）

2、用词是否清晰，语义是否存在歧义（明确性）

找出诸如也许，可能，大概，大约等关键词，因进一步明确需求，才不会导致后期与开发的理解冲突

3、是否清楚地描述了软件系统需要做什么及不做什么（必要性）

覆盖不多不少，少了则是需求覆盖不充分，多了则可能是不必要，强加给客户的功能，既浪费人力，也增加软件实现的风险

4、是否描述了软件使用的目标环境，包括软硬件环境（完整性）

应根据实际用户所适应的软硬件环境和网络环境进行测试，

5、是否对需求项进行了合理的编号（可修改性）

为了需求的维护和管理

6、需求项是否前后一致、彼此不冲突（一致性）

比如说明书描述软件使用环境时没提到需要在Linux平台下使用，而在描述安装包的开发时则要求需要支持Linux，会让人产生疑惑感

7、是否清楚说明了系统的每个输入、输出的格式，以及输入输出之间的对应关系（可测性）

检查每一类的输入是否存在固定的输出，如没有则是缺乏判断和验证系统正确性的依据

8、是否清晰描述了软件系统的性能要求（完整性）

有时候必要时还包括安全性的需求，如果确实需要则需要考虑

9、需求的优先级是否合理分配（优先级）

关键特效，重要特效，用户关心的功能，用户迫切想要的功能优先

10、是否描述了各种约束条件（可测性）

约束条件的完整，合理，与用户的业务场景一致

单据：输入大于0的

 

2、测试计划

         --一场对所有软件BUG展开的歼灭战

确定测试范围

制定测试策略

测试资源安排

-------测试难道、时间、工作量、人员

-------由于每个人的思维存在局限性，每项测试最后安排不少于2个人测试，以便交叉测试

进度安排

-------最好能预留一段缓冲时间，用于应对计划的变更，以及让测试员有时间完善和补充测试用例

风险及对策

-------可考虑建立后备机制

 

3、测试的设计及测试用例

方法：

等价类划分法

边界值分析法

等价类+边界值

基本路径分析法

因果图法

场景设计法

错误猜测法

正交表与TCG的使用

 

 

等价类划分法:

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

 

比如：在一个系统中，填写一个多少岁的成年人数学考了多少分（假设成年人年龄为x,0<x<=18,数学成绩为y：0<=y<=100

那么年龄按照等价类划分可分为x<0,0<x<=18,x>18,有效等价类是0<x<=18，无效等价类是x<0，x>18

 

数学成绩按照等价类划分可分为y<0,0<=y<=100,y>100,有效等价类是0<=y<=100，无效等价类是y<0，y>100

 

边界值分析法：（一般是与等价类划分一起使用）

　　一般边界值分析是因为程序开发循环体时的取数可能会因为<,<=搞错。

 

　　比如下面代码

　　for(int i = 0;i <100; i ++)

{

　　int j = i+1;

　　System.out.println("循环第“+j+"次")//循环地做某件事情

}

　　这里的程序是循环了100次，所以会做100次;

　　如果程序员不小心，把i <100写成i <= 100，则会溢出，这时候边界值检查是一个很好的测试方法。

 

比如：在一个系统中，填写一个多少岁的成年人数学考了多少分（假设成年人年龄为x,0<x<=18,数学成绩为y：0<=y<=100

　　　根据上面的等价类划分法我们可知，年龄的有效等价类是0<x<=18，所以边界值就是0，1，18，19

　　　　　　　　　　　　　　　　　　数学成绩的,有效等价类是0<=y<=100，所以边界值就是-1，0，100，101

 

基本路径分析法：（一般根据流程图）

比如审批合同：

　　编辑合同-提交-审核通过-建帐套

　　编辑合同-提交-审核不通过-修改-提交-审核通过-建帐套

 

因果图法（一般与判定表一起使用）

案例：

 

（1）分析原因及结果

 

 

（2）画出因果图

 

（3）编写决策表

 

（4）设计测试用例

 

场景设计法

　　如果需求规则说明书是采用uml的用例设计，那么可以比较轻松地通过把系统用例影射成测试用例的方法来设计测试用例。需要覆盖系统用例中的主成功场景和扩展场景，并且需要适当补充各种正反面的测试用例和考虑出现异常的情形。

　　场景设计法需要测试人员充分发挥对用户实际业务场景的想象。

错误猜测法

　　错误猜测法是测试经验丰富的人喜欢使用的一种测试用例设计方法。

一般这种方法是基于经验和直觉推测程序中可能发送的各种错误，有针对性地设计。只能作为一种补充。

　　例如，对于一个调用excel的程序，直觉告诉测试人员，它可能发生的错误是在调用的前后过程，比如，用户的计算机没有安装excel,则可能调用失败，甚至抛出异常，因此要做一下环境测试；又如调用了excel后忘记释放对excel的引用，从而导致excel的进程驻留，因此需要检查一下进程的列表看excel进程是否在程序关闭后仍然存在。

 

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

 

正交表法与TCG的使用

　　正交表法是一种有效减少测试用例个数的设计方法。

　　通过根据不同的输入参数，而设计出的不同的用例。

　　例如：我们现在创建客户，输入以下的3个参数：

　　编号：空、中文

　　名称：空、中文

　　性别：男、女

 

以下是用TCG工具映射出来的对应正交：

 

 

 

 

 

 

 

 

 

 

 

 

 

利用均匀试验法设计测试用例

　　该方法是与正交表法类似的一种测试用例设计法。

 

组合覆盖（PICT使用）

　　了解组合覆盖： http://www.pairwise.org/

　　微软的PICT小工具下载：http://msdn.Microsoft.com/en-us/testing/bb980925.aspx

　　PICT接受一个纯文本的Model文件作为输入，然后输出测试用例集合：

　　Model文件格式:<ParamName> : <value1>,<value2>….

　　比如，输入的文件分别有不同参数选择：

　　　　Type:Span,Mirror,Single

　　　　Size:10,,100,500

　　　　File system:FAT,FAT32,NTFS

　　　　把上面的内容存为Model.txt，存储在D:PICT

　　　　在命令行输入以下命令（先进入该文件夹）： “D:PICTModel.txt”

　　　　可产生所有可能的组合。

　　　　如果想把产生的测试用例存储到某个文件，则可输入以下命令：“D:PICTModel.txt” > “D:PICTOutPut.txt”

　　　　还有很多类似的工具，可参考：http://www.pairwise.org/tools.asp

分类数与TESTONA的使用

　　http://www.berner-matter.com/en/products/testona/index.html

　　TESTONA下载地址：http://www.testona.net/cms/upload/3_Raw/testonaLightSetup_4.1.1.exe

测试用例设计的自动化

　　目前，测试用例的设计大部分是需要手工的，这也是由于设计的复杂性和灵活性决定的。在自动化测试领域，测试的执行是首先被自动化的一个方面，目前已经取得了长足的进度。但是在测试用例的设计方面，自动化程度非常低。

　　目前在测试用例设计方面的自动化主要集中在测试数据的生成方面，一些工具也是集中在帮助测试人员产生数据和筛选数据方面，例如TConfig，PICT等。另外，像DataFactory这样的工具则专注于产生大批量的数据表数据。

注意：不要认为测试用例的设计是一个阶段，测试用例的设计也需要迭代，在软件开发的不同阶段都 要回来重新审视和完善测试用例。

测试用例的评价（评审）

　　测试用例设计出来了，如何提高测试用例设计的质量？

　　（1）同行的评审：通过讨论，协作来完成测试用例的设计，尽可能全面的覆盖需求。（一个人的思维性有局限性）

　　  (2)除了同行评审，应尽量引入用户参与到测试用例的设计中来

注意：参与到测试用例评审的人除了测试人员自己和管理层外，还应该包括最终用户或者顾客代表，还有开发人员。