软件测试规范Word下载.docx
《软件测试规范Word下载.docx》由会员分享，可在线阅读，更多相关《软件测试规范Word下载.docx（17页珍藏版）》请在冰豆网上搜索。
2．软件测试的目的
第一是：
确认软件的质量，其一方面是确认软件做了你所期望的事情（Dotherightthing），另一方面是确认软件以正确的方式来做了这个事件（Doitright）。
第二是：
提供信息，比如提供给开发人员或程序经理的反馈信息，为风险评估所准备的信息。
第三是：
软件测试不仅是在测试软件产品的本身，而且还包括软件开发的过程。
如果一个软件产品开发完成之后发现了很多问题，这说明此软件开发过程很可能是有缺陷的。
因此软件测试的第三个目的是保证整个软件开发过程是高质量的。
软件质量是由几个方面来衡量的：
一、在正确的时间用正确的的方法把一个工作做正确（Doingtherightthingsrightattherighttime.）。
二、符合一些应用标准的要求，比如不同国家的用户不同的操作习惯和要求，项目工程中的可维护性、可测试性等要求。
三、质量本身就是软件达到了最开始所设定的要求，而代码的优美或精巧的技巧并不代表软件的高质量（Qualityisdefinedasconformancetorequirements,notas“goodness”or“elegance”.）。
四、质量也代表着它符合客户的需要（Qualityalsomeans“meetcustomerneeds”.）。
作为软件测试这个行业，最重要的一件事就是从客户的需求出发，从客户的角度去看产品，客户会怎么去使用这个产品，使用过程中会遇到什么样的问题。
只有这些问题都解决了，软件产品的质量才可以说是上去了。
总之，软件测试的目的就是尽可能发现并改正测试的软件中的错误，提高软件的可靠性，保证软件的质量，最终让客户用的放心，用的满意！
三、软件测试的流程
1．软件测试总体流程图
2．详细流程如下：
N
Y
2.软件测试流程细则
一、需求阶段：
测试人员了解项目需求收集结果包括项目需求规格说明、功能结构及模块划分等。
测试人员了解项目需求变更。
测试人员会同项目主管根据软件需求制定并确认《测试计划》（附录五）。
二、设计编码阶段：
测试人员制定《测试大纲》（附录三、附录四）。
项目开发组对完成的功能模块进行单元测试，测试人员参与单元测试过程；
单元测试完成，产生单元测试报告。
所有单元测试及相应的修改完成后，项目开发组组织进行集成测试，测试人员参与集成测试过程；
集成测试完成后，产生集成测试报告。
三、测试阶段：
项目开发组完成集成测试后，提交测试所要求的待测软件及各种文档、手册、前期测试报告（《需求分析》、《软件设计规范》和上一级《测试报告》附录一、附录二）。
测试组安排和协调测试设备、环境等准备工作。
测试组按测试计划、测试大纲的要求对待测软件进行有效性测试、集成测试。
填写《错误报告》（附录六）。
对修改后的情况进行复合。
测试结束后，测试人员对测试结果进行汇总；
测试主管审核测试结果，得出测试结论；
测试组进行测试分析和评估，编写《测试分析报告》（附录七）。
提交《测试分析报告》。
将所有文件存档。
对测试未通过的待测软件，测试人员汇总并向项目开发组提交测试错误报告。
项目开发组对测试错误报告进行确认，对有争议的问题可由上一级技术负责人确认和仲裁；
项目开发组针对测试错误报告进行逐项修改，修改完成后再将待测软件及错误修改情况提交及测试组进行回归测试。
待测软件测试通过后，项目测评结束。
制作《用户操作手册》（帮助文件）。
四、用户测试阶段：
项目开发组与用户方商定测试计划、测试内容、测试环境等。
项目测试组向用户方提供项目内部测试汇总报告。
由项目开发组或测试组配合用户进行用户方测试。
由用户方编制用户方软件测试报告（程序错误报告和测试分析报告），若用户方不愿或无法编制测试报告，则经与用户方协商由我方测试人员编制用户方测试报告，经用户方签字后即可生效。
项目经理与用户方对用户方测试进行确认。
四、软件测试的原则
软件测试从不同的角度出发会派生出两种不同的测试原则，从用户的角度出发，就是希望通过软件测试能充分暴露软件中存在的问题和缺陷，从而考虑是否可以接受该产品，从开发者的角度出发，就是希望测试能表明软件产品不存在错误，已经正确地实现了用户的需求，确立人们对软件质量的信心。
为了达到上述的原则，那么需要注意以下几点：
1．应当把“尽早和不断的测试”作为开发者的座右铭
2．程序员应该避免检查自己的程序，测试工作应该由独立的专业的软件测试机构来完。
3．设计测试用例时应该考虑到合法的输入和不合法的输入以及各种边界条件，特殊情况要制造极端状态和意外状态，比如网络异常中断、电源断电等情况。
4．一定要注意测试中的错误集中发生现象，这和程序员的编程水平和习惯有很大的关系。
5．对测试错误结果一定要有一个确认的过程，一般有A测试出来的错误，一定要有一个B来确认，严重的错误可以召开评审会进行讨论和分析。
6．制定严格的测试计划，并把测试时间安排的尽量宽松，不要希望在极短的时间内完成一个高水平的测试。
7．回归测试的关联性一定要引起充分的注意，修改一个错误而引起更多的错误出现的现象并不少见。
8．妥善保存一切测试过程文档，意义是不言而喻的，测试的重现性往往要靠测试文档。
五.软件测试类型
除非是测试一个小程序，否则一开始就把整个系统作为一个单独的实体来测试是不现实的。
与开发过程类似，测试过程也必须分步骤进行，每个步骤在逻辑上是前一个步骤的继续。
大型软件系统通常由若干个子系统组成，每个子系统又由许多模块组成。
因此，大型软件系统的测试基本上由下述几个步骤组成：
1.模块测试
在设计得好的软件系统中，每个模块完成一个清晰定义的子功能，而且这个子功能和同级其他模块的功能之间没有相互依赖关系。
因此，有可能把每个模块作为一个单独的实体来测试，而且通常比较容易设计检验模块正确性的测试方案。
模块测试的目的是保证每个模块作为一个单元能正确运行，所以模块测试通常又称为单元测试。
在这个测试步骤中所发现的往往是编码和详细设计的错误。
2.子系统测试
子系统测试是把经过单元测试的模块放在一起形成一个子系统来测试。
模块相互间的协调和通信是这个测试过程中的主要问题，因此这个步骤着重测试模块的接口。
3.系统测试
系统测试是把经过测试的于系统装配成一个完整的系统来测试。
在这个过程中不仅应该发现设计和编码的错误，还应该验证系统确实能提供需求说明书中指定的功能，而且系统的动态特性也符合预定要求。
在这个测试步骤中发现的往往是软件设计中的错误，也可能发现需求说明中的错误。
不论是子系统测试还是系统测试，都兼有检测和组装两重含义，通常称为集成测试。
4.验收测试
验收测试把软件系统作为单一的实体进行测试，测试内容与系统测试基本类似，但是它是在用户积极参与下进行的，而且可能主要使用实际数据（系统将来要处理的信息）进行测试。
验收测试的目的是验证系统确实能够满足用户的需要，在这个测试步骤中发现的往往是系统需求说明书中的错误。
六、软件测试方法
1．黑盒测试
黑盒测试（black—boxtesting）又称功能测试、数据驱动测试或基于规范的测试（即criterion—basedtesting）。
用这种方法进行测试时，被测程序被当作看不见内部的黑盒。
在完全不考虑程序内部结构和内部特性的情况下，测试者仅依据程序功能的需求规范考虑确定测试用例和推断测试结果的正确性。
因此黑盒测试是从用户观点出发的测试，黑盒测试直观的想法就是既然程序被规定做某些事，那我们就看看它是不是在任何情况下都做的对。
完整的“任何情况”是无法验证的，为此黑盒测试也有一套产生测试用例的方法，以产生有限的测试用例而覆盖足够多的“任何情况”。
由于黑盒测试不需要了解程序内部结构，所以许多高层的测试如确认测试、系统测试、验收测试都采用黑盒测试。
具体的黑盒测试方法如下：
（1）等价类划分，
（2）因果图方法，（3）边值分析法，（4）错误码推测法，（5）随机数法，就是从更广泛的角度来进行黑盒测试。
每一个方法都力图能涵盖更多的“任何情况”，但又各有长处，综合使用这些方法，会得到一个较好的测试用例集。
（1）等价类划分：
等价类划分是一种典型的黑盒测试方法。
等价类是指某个输入域的集合。
它表示对揭露程序中的错误来说，集合中的每个输入条件是等效的。
因此我们只要在一个集合中选取一个测试数据即可。
等价类划分的办法是把程序的输入域划分成若干等价类，然后从每个部分中选取少数代表性数据当作测试用例。
这样就可使用少数测试用例检验程序在一大类情况下的反映。
在考虑等价类时，应该注意区别以下两种不同的情况：
有效等价类：
有效等价类指的是对程序的规范是有意义的、合理的输入数据所构成的集合。
在具体问题中，有效等价类可以是一个，也可以是多个。
无效等价类：
无效等价类指对程序的规范是不合理的或无意义的输入数据所构成的集合。
对于具体的问题，无效等价类至少应有一个，也可能有多个。
确定等价类有以下几条原则：
如果输入条件规定了取值范围或值的个数，则可确定一个有效等价类和两个无效等价类。
例如，程序的规范中提到的输入条包括“……项数可以从1到999……”，则可取有效等价类为“l考项数＜999”，无效等价类为“项数＜l，，及“项数＞999”。
输入条件规定了输入值的集合，或是规定了“必须如何”的条件，则可确定一个有效等价类和一个无效等价类。
如某程序涉及标识符，其输入条件规定“标识符应以字母开头……”则“以字母开头者”作为有效等价类，“以非字母开头”作为无效等价类。
如果我们确知，已划分的等价类中各元素在程序中的处理方式是不同的，则应将此等价类进一步划分成更小等价类。
输入条件
有效等价类
无效等价类
。
根据已列出的等价类表，按以下步骤确定测试用例：
为每个等价类规定一个唯一的编号；
设计一个测试用例，使其尽可能多地覆盖尚未覆盖的有效等价类。
重复这一步，最后使得所有有效等价类均被测试用例所覆盖；
设计一个新的测试用例，使其只覆盖一个无效等价类。
重复这一步，使所有无效等价类均被覆盖。
这里强调每次只覆盖一个无效等价类。
这是因为一个测试用例中如果含有多个缺陷，有可能在测试中只发现其中的一个，另一些被忽视。
等价类划分法能够全面、系统地考虑黑盒测试的测试用例设计问题，但是没有注意选用一些“高效的”、“有针对性的”测试用例。
后面介绍的边值分析法可以弥补这一缺点。
（2）因果图方法
等价类划分法并没有考虑到输入情况的各种组合。
这样虽然各个输入条件单独可能出错的情况已经看到了，但多个输入情况组合起来可能出错的情况却被忽略。
采用因果图方法能帮助我们按一定步骤选择一组高效的测试用例，同时，还能为我们指出程序规范的描述中存在什么问题。
利用因果图导出测试用例需要经过以下几个步骤：
分析程序规范的描述中哪些是原因，哪些是结果。
原因常常是输入条件或是输入条件的等价类。
结果是输出条件。
分析程序规范的描述中语义的内容，并将其表示成连接各个原因与各个结果的“因果图”。
由于语法或环境的限制，有些原因和结果的组合情况是不可能出现的。
为表明这些特定的情况，在因果图上使用持殊的符号标明约束条件。
把因果图转换成判定表。
把判定表的每一列写成一个测试用例。
（3）边值分析法
边值分析法是列出单元功能、输入、状态及控制的合法边界值和非法边界值，设计测试用例，包含全部边界值的方法。
典型地包括IF语句中的判别值，定义域、值域边界，空或畸形输入，末受控状态等。
边值分析法不是一类找一个例子的方法，而是以边界情况的处理作为主要目标专门设计测试用例的方法。
另外，边值分析不仅考查输入的边值，也要考虑输出的边值。
这是从人们的经验得出的一种有效方法。
人们发现许多软件错误只是在下标、数据结构和标量值的边界值及其上、下出现，运行这个区域的测试用例发现错误的概率很高。
用边值分析法设计测试用例时，有以下几条原则：
如果输入条件规定了取值范围，或是规定了值的个数，则应以该范围的边界内及刚刚超出范围的边界外的值，或是分别对最大、最小及稍小于最小、稍大于最大个数作为测试用例。
如有规范“某文件可包含l至255”个记录……“，则测试用例可选1和255及0和256等。
针对规范的每个输出条件使用原则〔a〕。
如果程序规范中提到的输入或输出域是个有序的集合（如顺序文件、表格等）就应注意选取有序集的第一个和最后一个元素作为测试用例。
分析规范，尽可能找出可能的边界条件。
一个典型的边值分析例子是三角形分类程序。
选取a，b，c构成三角形三边，“任意两边之和大于第三边”为边界条件。
边值分析相等价类划分侧重不同，对等价类划分是一个补充。
如上述三角形问题，选取a＝3，b＝4，c＝5，a＝2，b＝4，c＝7则覆盖有效和无效等价类。
如果能在等价类划分中注入边值分析的思想。
在每个等价类中不只选取一个覆盖用例，而是进而选取该等价类的边界值等价类划分法将更有效，最后可以用边值分析法再补充一些测试用例。
（4）错误码推测法
猜错法在很大程度上是凭经验进行的，是凭人们对过去所作的测试工作结果的分析，对所揭示的缺陷的规律性作直觉的推测来发现缺陷的。
一个采用两分法的检索程序，典型地可以列出下面几种测试情况：
被检索的表只有一项或为空表；
表的项数恰好是2的幂次；
表的项数比2的幂次多1等。
猜错法充分发挥人的经验，在一个测试小组中集思广益，方便实用，特别在软件测试基础较差的情况下，很好地组织测试小组（也可以有外来人员）进行错误猜测，是有效的测试方法。
（5）随机数法
即测试用例的参数是随机数。
它可以自动生成，因此自动化程度高。
使用大量随机测试用例测试通过的程序会提高用户对程序的信心。
但其关键在于随机数的规律是否符合使用实际。
2、白盒测试方法
白盒测试也称结构测试或逻辑驱动测试，它是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作，而不顾它的功能，白盒测试的主要方法有逻辑驱动、基路测试等，主要用于软件验证。
白盒法考虑的是测试用例对程序内部逻辑的覆盖程度，所以又称为逻辑覆盖法。
最彻底的白盒法是覆盖程序中的每一条路径，但这不可能，我们希望覆盖的路径尽可能多一些。
为了衡量测试的覆盖程度，需要建立一些标准，目前常用的一些覆盖标准是：
（1）语句覆盖；
（2）判定覆盖；
（3）条件覆盖；
（4）判定／条件覆盖；
（5）条件组合覆盖。
（1）语句覆盖
程序的某次运行一般并不能执行到其中的每一个语句，因此，如果某语句含有一个错误，而它在测试中没执行，这个错误就不可能被发现。
为了提高发现错误的可能性，应该在测试时至少要执行程序中的每一个语句。
所谓“语句覆盖”测试标准，它的含义是：
选择足够的测试用例，使得程序中每个语句至少都能执行一次。
例子：
ProcedureExample（VarA,B,C:
real）
begin
if（A>
1）and（B=0）
thenx:
=x/A；
if（A=2）or（x>
1）
=x+l
end;
为了使程序中每个语句至少执行一次，只需设计一个能通过路径ace的例子就可以了。
例如选择输入数据为：
A=2，B=0，x=3
就可达到“语句覆盖”标准。
显然，语句覆盖是一个比较弱的覆盖标准。
如果第一个条件语句中的and错误地写成or，上面的测试用例是不能发现这个错误的，或者是第二个条件语句中x>
1误写成x>
0，这个测试用例也不能暴露它。
我们还可以举出许多错误情况是上述测试数据不能发现的。
所以，一般认为“语句覆盖”是很不充分的最低的一种覆盖标准。
（2）判定理盖
比“语句覆盖”稍强的覆盖标准是“判定覆盖”（或称分支覆盖）。
这个标准是：
执行足够的测试用例，使得程序中每个判定至少都获得一次“真”值和“假”值，即使得程序中的每一个分文至少都通过一次。
对上面那个例子，如果设计两个测试用例，就可以达到“判定覆盖”的标难。
为此，我们可以选择输人数据为：
（1）A=3，B=0，x=l
（2）A=2，B=1，x=3
“判定覆盖”比“语句覆盖”严格，因为如果每个分支都执行过了，自然每个语句也就执行了。
（3）条件覆盖
它的含义是：
执行足够的测试用例，使得判定中每个条件获得各种可能的结果。
对于例子程序,我们只需设计以下两个测试用例就可满足这标准：
（1）A＝2，B＝o，x＝4（沿路径ace执行）
（2）A＝1，B＝l，x＝l（沿路径aN执行）
虽然同样只要两个测试用例，但它比判定覆盖中两个测试用例更有效。
一般来说，“条件覆盖”比“判定覆盖”强，但是，并不总是如此，满足“条件覆盖”不一定满足“判定覆盖”。
例如对语句。
IF（AANDB）THENS
设计两个测试用例：
A“真”B“假”和A“假”B“真”。
对于上例我们设计两个测试用例为：
（1）A＝1，B＝o，x＝3
（2）A＝2，B＝l，x＝1
亦是如此，它们能满足“条件覆盖”但不满足“判定覆盖”。
（4）判定／条件覆盖
针对上面的问题引出了另一种覆盖标准，这就是“判定／条件覆盖”，它的含义是：
执行足够的测试用例，同时满足判定覆盖和条件覆盖的要求。
显然，它比“判定覆盖”和“条件覆盖”都强。
对于例子程序，我们选取测试用例：
（1）A=2，B=0，x=4
（2）A=1，B=l，x=l
它满足判定／条件覆盖标准。
值得指出，看起来“判定／条件覆盖”似乎是比较合理的，应成为我们的目标，但是事实并非如此，因为大多数计算机不能用一条指令对多个条件作出判定，而必须将源程序中对多个条件的判定分解成几个简单判定。
这个讨论说明了，尽管“判定／条件覆盖”看起来能使各种条件取到所有可能的值，但实际上并不一定能检查到这样的程度。
针对这种情况，有下面的条件组合覆盖标准。
（5）条件组合覆盖
“条件组合覆盖”的含义是：
执行足够的测试用例，使得每个判定中条件的各种可能组合都至少执行一次。
这是一个最强的逻辑覆盖标准。
再看例子程序，必须使测试用例覆盖八种组合结果
（1）A>
1，B=0（5）A=2，x>
1
（2）A>
1，B<
>
0（6）A=2，x<
（3）A<
l，B=0（7）A<
2，x>
（4）A<
0（8）A<
2，x<
必须注意到，（5）、（6）、（7）、（8）四种情况是第二个条件语句的条件组合，而x的值在该语句之前是要经过计算的，所以我们还必须根据程序的逻辑推算出在程序的人口点x的输入值应是什么。
要测试八个组合结果并不是意味着需要八种测试用例，事实上，我们能用四种测试用例来覆盖它们：
（1）A＝2，B＝o，x＝4；
（2）A＝2，B＝1，x＝l；
（3）A＝l，B＝o，x＝2；
（4）A＝1，B＝1，x＝l。
上面四个例子虽然满足条件组合覆盖，但并不能覆盖程序中的每一条路径，可以看出条件组合覆盖仍然是不彻底的，在白盒测试时，要设法弥补这个缺陷。
3、ALAC（Act-like-a-customer）测试
ALAC测试是一种基于客户使用产品的知识开发出来的测试方法。
ALAC测试是基于复杂的软件产品有许多错误的原则。
最大的受益者是用户，缺陷查找和改正将针对哪些客户最容易遇到的错误。
七、测试用例及数据的格式
1．用例编写格式
模块编号
查看
用例编号
SXT
用例名称
查看XX功能
用例级别
1-5
用例描述
根据提供的测试数据查看XX功能。
（本用例在系统的首页。
默认在XX分页面）
测试步骤
编号
名称
前置条件
优先级
描述/步骤
预期结果
SXT.001
….
（无/简单描述）
1/2/3
（描述性语言）
（概括性描述）
SXT.002
SXT.003
……..
2．用例的执行结果:
测试号
实际结果
状态
问题简述
GUID
（主/子编号）
文字描述
图片描述
（P/F/W）
（无/简述）
SXT.VIE
2
SXT.VIE.001
相关实际操作结果的描述，并查看显示图片….
P
出现问题描述补充，或者问题出现的前提描述，或者问题的严重性简述
3
SXT.VIE.002
无
4
……
3．测试数据格式
4.备注：
（1）编号规则如下：
测试用例中的编号：
项目名+功能模块名+子功能模块名+编号
（各名称均为英文名大写前三个字母或单词大写首字母）
例如：
SXT软件中查看某一具体功能的第一步
SXT.VIE..001
（2）用例优先级
根据该功能模块被用户使用的频率高低依次分为：
1级2级3级
使用频率最高使用频率次高使用频率较低
八、测试报告
1.bug报告格式（测试员提交）
序号
001
BUG名称
Bug的名称
测试类型
单元测试/集成测试/系统测试
BUG描述
出现bug的现象的简单描述
对应用例
缺陷级别
S1/S2/S3
发生概率
高/中/低
所属模块
用例所对应的模块（如检测功能模块）
操作步骤
简单的路径描述：
（如登录→打开→查看…）
BUG状态
未解决
备注
Bug发现过程中的截图及说明详见该文档。
BUG影响分析
Bug的出现会带来的相关后果的简单分析，或者个人意见阐述。
2．测试阶段性总结报告（测试员提交）
项目名称
测试负责人
测试人
测试开始时间
测试结束时间
测试耗时
用例总数
有效用例总数
无效用例总
升级会员 