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

一方面存在着浪费时间的风险。由非技术人员提 交的报告往往是不完整的，或是问题没说清楚，倒反映 出报告员对产品设计缺乏了解。另一方面，有很多重要的 问题会被无意中遗漏或被有意排除，仅当用户投诉或被某刊物批评后方才显现出来。跟踪系统可能是单用户或是多用户的。 典型的单用户数据库安装在测试工作间的某台计算机上。每个人都在这台机器上录入或读取报告。仅有测试人员或是部分测试人员才可以直接访问该计算机。缺陷报告和项目状态总结报告由项目安排的某个测试人员打印和发放。而典型的多用户系统位于计算机网络或大型机上，能够被所有的测试人员和项目经理访问。程序员和技术文档编写人员也可能有权访问。市场营销人员和技术支持人员可以有权，也可以无权访问它（我们认为他们应该有权访问）。在一个多用户系统中，任何 有权访问的人都可以录入自己的报告、查询数据库 和打印总结报告。 9.1.3 软件测试报告 软件测试报告是一系列测试的总结，是在完成一个测试周期后可能提交的测试类型的总结。它简要地描述了已完成的测试，并对测试结果进行评估。 按照IEEE829标准，它包括以下几个部分： ● 测试报告标识符。 ● 总结。表明什么已经被测试（包括版本ID），在什么环境下进行的测试，并总结对它的评价。需要参考测试用例规格明。 ● 变异。报告测试过程相对指定测试过程的任何偏离，并解释原因。 ● 广泛性评估。测试是否与测试计划要求的一样广泛？什么模块、特征或特征组合没有得到足够测试，为什么？ ● 结果总结。对什么问题进行了报告，哪些 问题得到了解决，以及解决方案是什么？哪些 问题仍然没有解决？ ● 评价。在测试结果基础上对每个已测试项（程序或模块）的全面评价。或者，在实际使用中估计风险和这一项失败的可能性。 ● 活动总结。总结诸如为该报告中总结的测试工作的人员数量、使用的总的机器时间、总的消耗时间以及任何特殊事件或使用的其他值得一提的资源。 ● 核准。 测试报告可以自己编写，也可以使用商业测试 管理工具（例如HP的QC）在一个测试周期 完成后自动生成测试报告。 9.2 缺陷的报告和分析 在执行测试发现了软件缺陷（Bug）时，我们需要及时提交缺陷的报告，供程序员修复缺陷。从表面上看，报告测试所发现的问题，和制定测试计划、有效地使用测试技术寻找软件缺陷相比很简单。实际上，这也是测试人员需要完成的最重要，有时也是最困难的任务。 书写缺陷报告的意义在于使缺陷得到修复，所以要写出非常高效的报告，有效地和程序员进行交流. 我们必须做到以下几点: ● 有效地描述软件缺陷，说明如何让问题重现。如果程序员不能亲眼看到问题，他就会对问题置之不理。 ● 对缺陷进行分析，使用最少的步骤描述问题。如果报告中包含了不必要的步骤，问题会比实际情况看起来更复杂，程序员很有可能延迟处理看起来冗长而又混乱的报告。 ● 报告应该完备，易于理解而且没有敌意。测试人员和程序员之间很容易形成对立关系。从程序员或开发小组的其他人员的角度看，软件缺陷报告是软件测试人员对他们的工作的“成绩报告单”，因此报告的语言不要带倾向性、个 人观点和煽动性。软件缺陷报告应该针 对品，而不是具体的人，只陈述事实。 1、软件没有实现产品规格说明书要求的功能。 2、软件出现了产品规格说明书指明不应该出现的错误。 3、软件实现了产品规格说明书未提到的功能。 4、软件没有实现产品规格说明书虽未提及但应该实现的目标。 5、软件难以理解、不易使用、运行缓慢，或者 从测试员的角度看，最终用户会认为不好。 9.2.1 缺陷报告的内容 软件缺陷：官方定义是至少满足下列五个规则之一的才称发生了一个软件缺陷。 ● 说软件有没有“某个功能”，是指软件 运行时发现“有某个功能”或者“缺少某个功 能”。由于不能报告没有看见的问题，因此 没有看见就不能说存在软件缺陷。因此我 们的缺陷报告（也可以称为问题报告） 必须是在运行软件测试后，看到的软件 缺陷。 ● 缺陷报告的内容在大多数公司都是大同 小异，不同的是组织和标志 。 缺陷报告的内容： （1）缺陷报告编号。它是独一无二的，不存在相 同编号的两份报告。 （2）程序名。你测试的程序名。如果包含一个以上的程序需要说明。 （3）版本号（发布号）。用来标识被测的代码。例如某个版本号可能是2.10b，产品会