软件测试规范.docx

软件测试规范.docx

《软件测试规范.docx》由会员分享，可在线阅读，更多相关《软件测试规范.docx（11页珍藏版）》请在冰点文库上搜索。

软件测试规范

CompanyDocumentnumber：

WTUT-WT88Y-W8BBGB-BWYTT-19998

软件测试规范

软件项目测试规范

一、概述

本规范是对项目软件测试的一份规范性文件，对软件测试过程中所涉及到的测试类型、测试方法、测试标准、测试流程以及软件产品责任单位所承担的职责进行总体规范，以有效保证软件产品的质量。

软件测试是对软件设计的一种控制手段，是对软件产品质量的一种检查和审核手段。

软件设计单位应采取有效措施保证软件产品的质量，软件测试应按本规范要求对软件进行检查、测试，软件设计单位应保证对测试错误进行修正。

测试过程中发现的软件错误必须及时改正，这就是软件测试的任务。

为了改正错误，首先必须确定故障的准确位置，这是测试过程中最困难和任务。

需要周密审慎的思考和推理。

改正错误常常包括修正原来的设计，必须通盘考虑而不能“头痛医头脚痛医脚”，应该尽量避免在测试过程中引进新的故障。

二、测试类型

项目软件测试类型包括单元测试、集成测试（组装测试）、有效性测试（功能测试）、系统测试、回归测试和用户测试（验收测试）。

单元测试

主要针对软件设计单元、功能模块进行测试，测试内容包括模块程序结构检查、代码测试和模块内功能测试。

集成测试（组装测试）

主要针对软件设计单元、功能模块组装、集成为系统时，对软件单元、功能模块的接口、连接进行测试。

有效性测试（功能测试）

按照系统功能需求规定对系统的功能、流程、数据、业务规则等进行测试，以及对系统基本特征如操作、界面、报表等的合理性、一致性进行测试。

系统测试

为系统性能测试，如安全性、可靠性、稳定性测试，以及对系统其它性能如负载能力、处理能力以及响应时间等进行测试。

回归测试

在软件设计错误修正、设计修改以及软件升级后，主要针对软件修改、影响部分进行有效性测试和系统测试。

用户测试（验收测试）

为用户方组织的有效性和系统测试。

三、测试的方法

逻辑覆盖法

根据测试用例，运行被测试程序，使程序中的每个可执行语句、执行条件至少执行一次。

语句覆盖　

语句覆盖就是设计若干个测试用例，运行被测程序，使得每一条可执行语句至少执行一次。

判定覆盖

判定覆盖就是设计若干个测试用例，运行被测程序，使得程序中每个判断的取真分支和取假分支至少经历一次。

判定覆盖又称为分支覆盖。

条件覆盖

条件覆盖就是设计若干个测试用例，运行被测程序，使得程序中每个判断的每个条件的可能取值至少执行一次。

判定－条件覆盖

判定－条件覆盖就是设计足够的测试用例，使得判断中每个条件的所有可能取值至少执行一次，同时每个判断中的每个条件的可能取值至少执行一次。

条件组合覆盖

条件组合覆盖就是设计足够的测试用例，运行被测程序，使得每个判断的所有可能的条件取值组合至少执行一次。

路径测试

路径测试就是设计足够的测试用例，覆盖程序中所有可能的路径。

条件测试路径选择

当程序中判定多于一个时，形成的分支结构可以分为两类：

嵌套型分支结构和连锁型分支结构。

对于嵌套型分支结构，若有n个判定语句，需要n+1个测试用例；

对于连锁型分支结构，若有n个判定语句，需要有2n个测试用例，覆盖它的2n条路径。

当n较大时将无法测试。

循环测试路径选择

循环分为4种不同类型：

简单循环、连锁循环、嵌套循环和非结构循环。

（1）简单循环

①零次循环：

从循环入口到出口

②一次循环：

检查循环初始值

③二次循环：

检查多次循环

④m次循环：

检查在多次循环

⑤最大次数循环、比最大次数多一次、少一次的循环。

（2）嵌套循环

①对最内层循环做简单循环的全部测试。

所有其它层的循环变量置为最小值；

②逐步外推，对其外面一层循环进行测试。

测试时保持所有外层循环的循环变量取最小值，所有其它嵌套内层循环的循环变量取“典型”值。

③反复进行，直到所有各层循环测试完毕。

④对全部各层循环同时取最小循环次数，或者同时取最大循环次数。

（3）连锁循环

如果各个循环互相独立，则可以用与简单循环相同的方法进行测试。

但如果几个循环不是互相独立的，则需要使用测试嵌套循环的办法来处理。

（4）非结构循环

这一类循环应该使用结构化程序设计方法重新设计测试用例。

等价划分法

所谓等价类，就是指某个输入域的集合，集合中的每个输入对揭露程序错误来说是等效的，把程序的输入域划分成若干部分，然后从每个部分中选取少数代表性数据作为测试用例，这就是等价类划分方法。

它是功能测试的基本方法。

使用这一方法设计测试用例要经历划分等价类（列出等价类表）及选取测试用例两步。

划分等价类：

有效等价类、无效等价类

确定测试用例：

为每个等价类规定一个唯一的编号；设计一个测试用例，使其尽可能多地覆盖尚未覆盖的有效等价类；设计一个新的测试用例，使其只覆盖一个无效等价类。

　等价类划分是一种典型的黑盒测试方法，使用这一方法时，完全不考虑程序的内部结构，只依据程序的规格说明来设计测试用例。

等价类划分方法把所有可能的输入数据，即程序的输入域划分成若干部分，然后从每一部分中选取少数有代表性的数据做为测试用例。

使用这一方法设计测试用例要经历划分等价类（列出等价类表）和选取测试用例两步。

划分等价类

等价类是指某个输入域的子集合。

在该子集合中，各个输入数据对于揭露程序中的错误都是等效的。

测试某等价类的代表值就等价于对这一类其它值的测试。

等价类的划分有两种不同的情况：

①有效等价类：

是指对于程序的规格说明来说，是合理的，有意义的输入数据构成的集合。

②无效等价类：

是指对于程序的规格说明来说，是不合理的，无意义的输入数据构成的集合。

在设计测试用例时，要同时考虑有效等价类和无效等价类的设计。

划分等价类等价类的原则。

（1）如果输入条件规定了取值范围，或值的个数，则可以确立一个有效等价类和两个无效等价类。

例如，在程序的规格说明中，对输入条件有一句话：

“……项数可以从1到999……”

则有效等价类是“1≤项数≤999”

两个无效等价类是“项数＜1”或“项数＞999”。

（2）如果输入条件规定了输入值的集合，或者是规定了“必须如何”的条件，这时可确立一个有效等价类和一个无效等价类。

例如，在Pascal语言中对变量标识符规定为“以字母打头的……串”。

那么所有以字母打头的构成有效等价类，而不在此集合内（不以字母打头）的归于无效等价类。

（3）如果输入条件是一个布尔量，则可以确定一个有效等价类和一个无效等价类。

（4）如果规定了输入数据的一组值，而且程序要对每个输入值分别进行处理。

这时可为每一个输入值确立一个有效等价类，此外针对这组值确立一个无效等价类，它是所有不允许的输入值的集合。

例如，在教师上岗方案中规定对教授、副教授、讲师和助教分别计算分数，做相应的处理。

因此可以确定4个有效等价类为教授、副教授、讲师和助教，一个无效等价类，它是所有不符合以上身分的人员的输入值的集合。

（5）如果规定了输入数据必须遵守的规则，则可以确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）。

例如，Pascal语言规定“一个语句必须以分号‘;’结束”。

这时，可以确定一个有效等价类“以‘;’结束”，若干个无效等价类“以‘:

’结束”、“以‘,’结束”、“以‘’结束”、“以LF结束”等。

确立测试用例

在确立了等价类之后，建立等价类表，列出所有划分出的等价类。

再从划分出的等价类中按以下原则选择测试用例：

（1）为每一个等价类规定一个唯一编号；

（2）设计一个新的测试用例，使其尽可能多地覆盖尚未被覆盖的有效等价类，重复这一步，直到所有的有效等价类都被覆盖为止；

（3）设计一个新的测试用例，使其仅覆盖一个尚未被覆盖的无效等价类，重复这一步，直到所有的无效等价类都被覆盖为止

边界值分析法

使用边界值分析方法设计测试方案首先应该确定边界情况，这需要经验和创造性，通常输入等价类和输出等价类的边界，就是应该注重测试的程序边界情况。

选取的测试数据应该刚好等于、刚刚小于和刚刚大于边界值。

也就是说，按照边界值分析法，应该选取刚好等于、稍小于和稍大于等价类边界值作为测试数据，而不是选取每个等价类内的典型值或任意值作为测试数据。

边界值分析也是一种黑盒测试方法，是对等价类划分方法的补充。

人们从长期的测试工作经验得知，大量的错误是发生在输入或输出范围的边界上，而不是在输入范围的内部。

因此针对各种边界情况设计测试用例，可以查出更多的错误。

比如，在做三角形计算时，要输入三角形的三个边长：

A、B和C。

我们应注意到这三个数值应当满足A＞0、B＞0、C＞0、A＋B＞C、A＋C＞B、B＋C＞A，才能构成三角形。

但如果把六个不等式中的任何一个大于号“＞”错写成大于等于号“≥”，那就不能构成三角形。

问题恰出现在容易被疏忽的边界附近。

这里所说的边界是指，相当于输入等价类和输出等价类而言，稍高于其边界值及稍低于其边界值的一些特定情况。

使用边界值分析方法设计测试用例，首先应确定边界情况。

应当选取正好等于，刚刚大于，或刚刚小于边界的值做为测试数据，而不是选取等价类中的典型值或任意值做为测试数据。

实践证明，软件在输入、输出域的边界附近容易出现差错，边值分析是考虑边界条件而选取测试用例的一种功能测试方法。

边值分析是对等价类划分的有效补充。

因-果图法

分析程序规格说明的描述中哪些是原因,哪些是结果。

原因是输入条件或是输入条件的等价类。

结果是输出条件。

因果图是一种形式语言，由自然语言写成的规范转换而成，这种形式语言实际上是一种使用简化记号表示数字逻辑图。

因果图法是帮助人们系统地选择一组高效测试用例的方法，此外，它还能指出程序规范中的不完全性和二义性。

因果图的适用范围

如果在测试时必须考虑输入条件的各种组合，可使用一种适合于描述对于多种条件的组合，相应产生多个动作的形式来设计测试用例，这就需要利用因果图。

因果图方法最终生成的就是判定表。

它适合于检查程序输入条件的各种组合情况。

用因果图生成测试用例的基本步骤

（1）分析软件规格说明描述中，哪些是原因（即输入条件或输入条件的等价类），哪些是结果（即输出条件），并给每个原因和结果赋予一个标识符。

（2）分析软件规格说明描述中的语义，找出原因与结果之间，原因与原因之间对应的是什么关系根据这些关系，画出因果图。

（3）由于语法或环境限制，有些原因与原因之间，原因与结果之间的组合情况不可能出现。

为表明这些特殊情况，在因果图上用一些记号标明约束或限制条件。

（4）把因果图转换成判定表。

（5）把判定表的每一列拿出来作为依据，设计测试用例。

在因果图中出现的基本符号

通常在因果图中用Ci表示原因，用Ei表示结果，各结点表示状态，可取值“0”或“1”。

“0”表示某状态不出现，“1”表示某状态出现。

主要的原因和结果之间的关系有:

表示约束条件的符号

为了表示原因与原因之间，结果与结果之间可能存在的约束条件，在因果图中可以附加一些表示约束条件的符号。

错误推测法

列举出程序中可能有的错误和容易发生错误的特殊情况。

人们也可以靠经验和直觉推测程序中可能存在的各种错误，从而有针对性地编写检查这些错误的例子。

这就是错误推测法。

错误推测法的基本想法是：

列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据它们选择测试用例。

由于等价划分和边界值都只孤立地考虑各个输入数据的测试功效，而没有考虑多个输入数据的组效应，可能会遗露了输入数据易于出错的组合情况，选择输入组合的一个有效的途径是利用判定表或判定树为工具，列出输入数据各种组合与程序应作的动作（及相应的输出结果）之间的对应关系，然后为判定表的每一列至少设计一个测试用例。

选择输入组合的另一个有效途径是把计算机测试和人工检查代码结合起来。

通过代码检查发现程序中两个模块使用并修改某些共享的变量，如果一个模块对这些变量的修改不正确，则会引起另一个模块出错，因此这是程序发现错误的一个可能的原因，应该设计测试方案，在程序的一欠运行中同时检测这两个模块，特别要着重检测一个模块修改了共享变量后，另一个模块能否像预期的那样正常使用这些变量。

如果两个模块相对独立，就没有必要测试它们的输入组合情况。

四、技术开发部门及项目组内部测试

测试依据

●项目测试计划

●软件需求规格说明书

●软件功能结构及模块划分

●软件设计文档

●设计规范（包括编码规范、功能接口规范、操作规范、界面组织及报表格式规范）

●项目测试规范及部门项目内部测试规范

测试类型

●单元测试

●集成测试

测试结果

●单元测试报告

●集成测试报告

五、测评组总体测试

测试依据

●项目测试计划

●软件需求规格说明书

●软件功能结构及模块划分

●设计规范（包括编码规范、功能接口规范、操作规范、界面组织及报表格式规范）

●项目测试规范

●测试大纲

●单元测试报告

●集成测试报告

●测试申请报告及具体测试安排

测试类型

●有效性测试（功能测试）

●系统测试

测试结果

●有效性及系统测试记录

●测试错误报告

●测试分析及评估报告

●测试结论

六、测试错误类型

本规范只定义有效性测试、系统测试错误，部门项目内部测试由部门项目自行确定。

本规范定义以下五类测试错误类型。

A类—严重错误，包括以下各种错误：

1．由于程序所引起的死机,非法退出

2．死循环

3．数据库发生死锁

4．因错误操作导致的程序中断

5．功能错误

6．与数据库连接错误

7．数据通讯错误

B类—较严重错误，包括以下各种错误：

1．程序错误

2．程序接口错误

3．数据库的表、业务规则、缺省值未加完整性等约束条件

C类—一般性错误，包括以下各种错误：

1．操作界面错误（包括数据窗口内列名定义、含义是否一致）

2．打印内容、格式错误

3．简单的输入限制未放在前台进行控制

4．删除操作未给出提示

5．数据库表中有过多的空字段

D类—较小错误，包括以下各种错误：

1．界面不规范

2．辅助说明描述不清楚

3．输入输出不规范

4．长操作未给用户提示

5．提示窗口文字未采用行业术语

6．可输入区域和只读区域没有明显的区分标志

E类—测试建议

七、测试标准

各类软件测试合格须符合以下标准。

A类错误

B类错误

C类错误

D类错误

E类建议

无

无

暂不作要求

以上比例为错误占总测试模块的比例。