软件测试过程所需的技能

第9章软件测试过程所需的技能

1本章内容提要■软件测试文档的编写■软件测试用例的设计■缺陷的报告和分析■问题跟踪系统第9章软件测试过程所需的技能29.1软件测试文档根据IEEE829-1998标准有以下测试文档:● 测试计划● 测试设计规格说明书● 测试用例规格说明书● 测试过程规格说明书● 测试项目移交报告● 测试日志● 测试突发事件报告● 测试总结报告31．测试计划的内容根据IEEE829标准，测试计划包含以下几个部分：4●测试计划标识符：一个唯一的名称或编号。●简介：包括对所有相关政策和标准文档的引用，以及高层产品计划。●测试项：一个测试项就是将要测试的一个软件项（功能、模块、特征等）；列出所有的测试项或者参考一个列出所有这些项的文档；同时包括对规格说明（如需求和设计）和手册（如用户操作和安装）的引用。●测试的特征：列出哪些特征要测试，哪些特征不进行测试以及不测试的理由。

1．测试计划的内容5●方法：描述测试的全面方法—主要行为、技术（例如使用白盒测试还是黑盒测试技术），使用的工具（例如自动化测试工具是自己开发还是购买商业工具）等。●测试项通过/失败的准则：测试人员如何断定程序是否通过或未通过给定的测试。●测试交付物：列出所有要为该产品编写的测试文档。●测试任务：列出准备测试和执行测试必需的所有任务；说明任务之间的相关性，完成它们所需要的特殊技能、人员等资源，谁完成任务，牵扯多少精力，以及每个任务何时可以完成。

1．测试计划的内容6●环境需求：描述必需的硬件、软件、测试工具、实验设备等。●责任：为管理、设计、准备、执行、证明、监察、改正、解决等的小组（或人）指定责任。●人员及培训：包括每个技能水平你需要多少人，他们需要进行多少培训。●测试进度：列出所有带日期的里程碑，以及何时需要何资源（人员、机器、工具和设备）。测试进度可以使用固定日期，也可以使用相对日期。

1．测试计划的内容7●风险和意外事故：明确指出项目的潜在问题或者风险区域，这是对测试工作最有影响的因素。●核准：谁必须批准这一计划？为他们的签名留出空间。例：根据IEEE829标准，参考的系统测试计划模板。

1．测试计划的内容8修改编号修改日期修改后版本修改者修改位置修改内容概述

版本更新记录表一：1．介绍

1.1目的说明文档的目的。

1.2范围说明文档覆盖的范围。

1.3缩写说明定义文档中所涉及的缩略语（若无则填写“无”）。

1.4术语定义定义文档内使用的特定术语（若无则填写“无”）。系统测试计划模板91.5引用标准列出文档制定所依据、引用的标准（若无则填写“无”）。

1.6参考资料列出文档制定所参考的资料（若无则填写“无”）。系统测试计划模板102．测试项目对被测试对象进行描述。3．测试特征描述测试的特征。4．测试方法

分析和描述本次测试采用的测试方法和技术。5．测试标准

描述测试通过的标准以及测试审批的过程，测试挂起/恢复的条件。6．系统测试交付物测试完成后提交的所有产品。

7．测试任务系统测试计划模板11

8．环境要求

8.1硬件需求

8.2软件需求

8.3测试工具

8.4其他

9．角色和职责

10．人员及培训

11．系统测试进度系统测试计划模板129.1.2软件测试用例

1、什么是测试用例2、测试用例的评价标准3、设计的基本原则4、测试用例规格说明的内容：标识符测试项输入说明环境要求特殊过程要求测试用例间的相关性139.1.3软件测试报告

软件测试报告是一系列测试的总结，是在完成一个测试周期后可能提交的测试类型的总结。它简要地描述了已完成的测试，并对测试结果进行评估。按照IEEE829标准，它包括以下几个部分：14●测试报告标识符。●总结。表明什么已经被测试（包括版本ID），在什么环境下进行的测试，并总结对它的评价。需要参考测试用例规格说明。●变异。报告测试过程相对指定测试过程的任何偏离，并解释原因。●广泛性评估。测试是否与测试计划要求的一样广泛？什么模块、特征或特征组合没有得到足够测试，为什么？●结果总结。对什么问题进行了报告，哪些问题得到了解决，以及解决方案是什么？哪些问题仍然没有解决？软件测试报告组成15●评价。在测试结果基础上对每个已测试项（程序或模块）的全面评价。或者，在实际使用中估计风险和这一项失败的可能性。●活动总结。总结诸如为该报告中总结的测试工作的人员数量、使用的总的机器时间、总的消耗时间以及任何特殊事件或使用的其他值得一提的资源。●核准。

软件测试报告组成169.2缺陷报告和分析171、软件没有实现产品规格说明书要求的功能。2、软件出现了产品规格说明书指明不应该出现的错误。3、软件实现了产品规格说明书未提到的功能。4、软件没有实现产品规格说明书虽未提及但应该实现的目标。5、软件难以理解、不易使用、运行缓慢，或者从测试员的角度看，最终用户会认为不好。

9.2.1缺陷报告的内容软件缺陷至少满足下列五个规则之一:18缺陷报告的内容：（1）缺陷报告编号。唯一性。（2）程序名。所测试的程序名。（3）版本号（发布号）。用来标识被测的代码。（4）报告类型。描述发现的问题类型。问题类型可分为编码错误、设计问题、文档错误、硬件、建议、质疑。9.2.1缺陷报告的内容19（5）严重性。对问题严重程度的评分。评分从1（较轻的，如拼写错误）到10（影响巨大，如导致系统失效）分为10个等级，但现实中超过4个等级就很难可靠地评价问题。因此我们可以采用4个等级：轻微的，一般的，严重的和致命的。（6）附件。报告缺陷时可能会附上的数据文件、图形用户界面的截图等。在报告中要注明包含了哪些附件。9.2.1缺陷报告的内容20（7）问题概要。对问题进行简要描述，可以帮助每个人很快地评审突出的问题，并找到相应的缺陷报告。（8）问题能否重现。能、不能或者有时能。（9）问题描述。详细描述问题以及问题如何重现。（10）报告人。报告人的名字必须填写。（11）时间。发现问题的时间，而不是填写报告的时间。9.2.1缺陷报告的内容21（12）责任人。填写负责处理该问题的小组成员或管理人员的名称。（13）注释。预留给程序员或项目经理等其他处理该报告的人员使用。（14）状态。最常用的状态是：开放、关闭和已解决。（15）优先级。优先级由项目负责人或小组共同决定，要求程序员根据优先级依次修复缺陷。优先级通常是5～10级。不同的公司优先级的设置与定义也各不相同。9.2.1缺陷报告的内容22（16）处理状态和处理版本。常用的不同类型的处理状态：

●未解决。● 已改正。● 不能重现。● 暂缓。●符合设计。●报告人撤回。●需要进一步信息。●不同意建议。●重复。9.2.1缺陷报告的内容23（17）暂缓处理。（18）签名9.2.1缺陷报告的内容249.2.2缺陷分析缺陷报告提交的目的是为了程序员能再现缺陷，从而找到修复缺陷的方法。如何重现缺陷，首先需要分析缺陷。分析缺陷的提示和技巧：（1）不要想当然地接受任何假设。（2）查找时间依赖和竞争条件的问题。（3）边界条件软件缺陷、内存泄露和数据溢出等白盒问题可能会慢慢自己显露出来。（4）