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

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

一、测试需求的分析和肯定

二、测试计划

三、测试设计

四、测试执行

五、测试记录和缺陷跟踪

六、回归测试

七、测试总结和报告

 

一、测试需求的分析和肯定

 

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

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

例子：

一、是否覆盖了用户提出的全部需求项（完整性）

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

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

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

三、是否清楚地描述了软件系统须要作什么及不作什么（必要性）

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

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

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

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

为了需求的维护和管理

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

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

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

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

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

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

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

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

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

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

单据：输入大于0的

 

二、测试计划

         --一场对全部软件BUG展开的歼灭战

肯定测试范围

制定测试策略

测试资源安排

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

-------因为每一个人的思惟存在局限性，每项测试最后安排很多于2我的测试，以便交叉测试

进度安排

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

风险及对策

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

 

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

方法：

等价类划分法

边界值分析法

等价类+边界值

基本路径分析法

因果图法

场景设计法

错误猜想法

正交表与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:\PICT\Model.txt”

　　　　可产生全部可能的组合。

　　　　若是想把产生的测试用例存储到某个文件，则可输入如下命令：“D:\PICT\Model.txt” > “D:\PICT\OutPut.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)除了同行评审，应尽可能引入用户参与到测试用例的设计中来

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