第9章软件测试过程所需的技能教学文案

《第9章软件测试过程所需的技能教学文案》由会员分享，可在线阅读，更多相关《第9章软件测试过程所需的技能教学文案（85页珍藏版）》请在金锄头文库上搜索。

1、1,第9章软件测试过程所需的技能,2,本章内容提要 软件测试文档的编写 软件测试用例的设计 缺陷的报告和分析 问题跟踪系统,3,9.1 软件测试文档的编写,和程序员开发程序必须编写程序规格 说明一样，测试人员在测试过程中也需要编写例如测试计划或是测试用例的测试文档。良好的测试文档可以提供以下三个主要的功能： 1.为完成测试技术任务提供了便利 为了编写一个好的测试计划，在开发该计划时必须以一种系统的方式对程序进行调查，从而使得对程序的处理更加清晰、彻底和有效。在测试的规 划期间创建的清单和图表会以如下的方式 提高测试程序的能力。,4,（1）提高测试覆盖率：测试计划要求有一个程 序特征清单，要列出

2、该清单就必须找出所有的 特征。如果在测试中使用该清单，就不会遗漏掉任何 一个特征。常见的有用的做法是在清单中列出由该 程序创建的所有报告，以及所有错误信息、菜单选 项、对话框，每一对话框的所有选项等。创建清 单时越仔细彻底，遗漏的东西就越少。 （2）避免不必要的重复和遗忘项目：当核对测 试的清单或图表上的项目时，可以很容易地 看出已经测试过的和还没有测试过的项 目。,6,（5）提供最终测试的结构：当所有编码工作完 成，系统的每部分看起来可以一起工作了，最 终测试就开始了。但是现在的产品发布都存 在着很大的压力，只有很少的时间可以用来 安排最终测试。所以以前测试的优秀笔录 将帮助确保最后一次运行

3、了重要测试。如果 没有这些笔录，就不得不记住哪些测试需要重新运行。 （6）检查完整性：不完整的测试计划会不同程度 地遗漏程序中的缺陷。测试计划通常会因 为忽略了程序区域、缺陷类别、测试 类别，或是简单疏忽而存在漏洞。,7,2改善了测试任务与测试过程间的联系,（1）交流了测试人员策略背后的思想。 （2）得出测试准确度和覆盖率的反馈。文档的读者会告诉你忘记测试的程序区域，你对程序某些方面 的误解，以及未反应出的产品最新变化。 （3）得出测试深度和时间进度的反馈。有些测试计划会产生许多关于测试数量的争议。一些项目经理 辩称测试计划要求的测试过多，这样就产生了不 必要的进度延迟，而其他项目的经理可能会

4、抗 议说测试太少了，想要延长测试进度或者增 加测试人员从而增加测试的数量。,8,不管是否存在测试文档，上面的问题都会浮现出来，而测试计划则有助于集中讨论，并 使得达成特定协议更加容易。当一个清晰、详 细的测试计划可供参考时，这些讨论就会更 加理性，现实和实用。 （4）交流测试工作的规模。测试计划显示出了要进行的工作以及已完成工作的数量，这会帮 助经理及其他人理解为何你的测试小组规模 如 此庞大，而且要花这么长的时间来完成。 如果项目只对如何更快或是不那么昂贵 地执 行项目感兴趣，那他就会考虑 简化或者淘汰最难以测试的程序区域。,9,（5）分派工作。如果你能够给下一个测试 人员提供一个书面的详细

5、指令集，那么委 派及监督产品的部分测试就要容易得多。 3为组织、规划与管理测试项目提 供了结构 （1）达成有关测试任务的协议。测试计划明确指出测试人员将要做（或不做）什么工作。让其他 人对这个计划进行评审，包括项目经理以及相 关的经理、程序员、测试人员、营销人员，以及 可能在项目中提出更进一步测试要求的其他 人，尽早利用评审引出不同意见，讨论并 解决。,10,（2）确定任务。一旦你了解了要做什么，就能估计并证明所需资源（金钱、时间、人员和设备）是否有效。 （3）结构。确定任务时，可以看到很多概念上相关的以及方便共同进行的事情。把这些任务 集分组，并把某组中的所有任务分配给同一 个人或同一小组。

6、一组接一组地集中测试。 （4）组织。一个全面开发的测试计划要确定由谁执行什么测试，如何测试，何时何地，利用 什么资源完成，以及为何要完成这些特 定的测试或测试集。,11,（5）调整。项目经理或项目的主任测试员把测试 计划作为一个委派工作以及告知其他人某人已 分配了什么工作的基础。及时跟踪正在执行 的任务，以及那些花费了比预期的时间更长 时间的任务，必要时迅速调整人员和设备 的分配。 （6）改进个人责任。 测试人员明白他应该对什么负责。委派工作时，如 果你对任务加以描述并对你的期望值进行解释，测试 人员就会对你有更好的理解，并且认真地对待分配的 任务。,12,确定一个重要的测试的计划问题。假定你

7、把程序的某 个区域分配给了某个测试员，他报告说已经对其进行了测试，接着有人发现该区域存在一个可怕的缺 陷。这种事情时有发生。一个详细的测试计划可以 帮你确定计划或者某个独立测试人员是否存在问题。 确定一个重要的测试计划的设计问题。如果测试人员 没有发现一个特别令人尴尬的缺陷，只是因为测试 计划中没有包括对该缺陷的测试，那么测试计划 是否就存在问题？我们再次强调，测试计划通常 会遗漏缺 陷，这是个不幸但很正常的情况。不要仅 仅因为某个 被遗漏的缺陷令人尴尬就修改过程 或者找替罪羊。,13,（7）衡量项目状态并增加项目透明度。测试 计划的进展报告能有效地度量到目前为止所 付出的测试努力和预测的进度

8、。如果在项目开始时就写下完整的测试计划，就能够预测通过该 测试计划要花多长时间，在项目完成前你期望 它运行多少次（或者通过它的一个回归测试子 集），以及每一测试周期何时开始。在项目 的任何时间点上，都应该能够报告进度，并与 你的初期期望值进行比较。这些报告反映了测试速度，以及对所谓整体项目进度的真实性检查。这 类状态报告能够在为你判断一个基本的项 目人力水平（供预算使用）上起到重要 作用。,14,根据IEEE829-1998 标准有以下测试文档,测试计划 测试设计规格说明书 测试用例规格说明书 测试过程规格说明书 测试项目移交报告 测试日志 测试突发事件报告 测试总结报告,15,9.1.1 软

9、件测试计划,测试计划是我们工作中会遇到的最基本 的测试文档。 测试新手一般不会被安排为测试项目做全面的测试计划，通常这是由测试负责人或测试经理来做。而测试员一般是协助建立测试计划，因此需要了解计划测试工作包括哪些内容，测试计划需要哪 些信息。,16,1测试计划的目标 测试计划是提供产品测试工作的概述，根据 IEEE829关于软件测试文档的标准，测试计划的目 的是“规定测试活动的范围、方法、资源和进度；明确正在测试的项目、要测试的特性、要执行的测试任务、每个任务的负责人，以及与计划相关的风险”。 尽管测试计划采用的都是书面文档的形式，但是测试计划文档只是创建详细计划过程的一个副产品，重要的是计划

10、过程本身，而不是产生的最终结果文档。所以说测试计划过程的最终目标是 交流（而不是记录）软件测试小组的意图 、期望，以及对将要执行的测试任务的理解。,17,2测试计划的内容 根据IEEE829标准，测试计划包含以下几个部分。我们希望你不要因为要使文档与IEEE标准保持一致而感到约束，该标准只是提供了一个仔细思考过的背景，你需要把它应用到你的需要中去。另外，不要在测试一开始就强迫写出所有的东西。该标准有助于预先写出测试计划的第一稿，然后在继续工作时再逐渐编写和细化剩余的部分。,18, 测试计划标识符：一个唯一的名称或编号， 如果在一个数据库中存储了所有文档的话就很 有用。 简介：包括对所有相关政策

11、和标准文档的引用，以及高层产品计划。 测试项：一个测试项就是将要测试的一个软件项（功能、模块、特征等）；列出所有的测试项或者参考一个列出所有这些项的文档；同时包括对规格说明（如需求和设计）和手册（如用户操作和安装）的引用。 测试的特征：列出哪些特征要测试，哪 些特征不进行测试以及不测试的理由。,19, 方法：描述测试的全面方法谁进行测试， 主要行为、技术（例如使用白盒测试还是黑盒 测试技术），以及为每个主要特征组使用的工具（例如自动化测试工具是自己开发还是购买商业工具）等。 测试项通过/失败的准则：测试人员如何断定程序是否通过或未通过给定的测试。 测试交付物：列出所有要为该产品编写的测试文档。

12、 测试任务：列出准备测试和执行测试必需的所有任务；说明任务之间的相关性，完成它们所需 要的特殊技能、人员等资源，谁完成任务， 牵扯多少精力，以及每个任务何时可以 完成。,20, 环境需求：描述必需的硬件、软件、测试工具、实验设备等。 责任：为管理、设计、准备、执行、证明、监察、改正、解决等的小组（或人）指定责任。 人员及培训：包括每个技能水平你需要多少人，他们需要进行多少培训。 测试进度：列出所有带日期的里程碑，以及何时需要所有资源（人员、机器、工具和设备）。测试进度可以使用固定日期，也可 以使用相对日期。,21, 风险和意外事故：明确指出项目的潜在问 题或者风险区域，这是对测试工作最有影响的

13、因素。 核准：谁必须批准这一计划？为他们的签名留出空间。 根据IEEE829标准，我们提供了一个可以作为参考的系统测试计划模板。各个公司可以根据自己的实际情况和每个项目的具体情况确定测试计划的模板（如下表）。,22,版本更新记录,表一：,1介绍 1.1 目的 说明文档的目的。 1.2 范围 说明文档覆盖的范围。 1.3 缩写说明 定义文档中所涉及的缩略语（若无则填写“无”）。 1.4 术语定义 定义文档内使用的特定术语（若无则填写“无”）。,23,1.5 引用标准 列出文档制定所依据、引用的标准（若无则填写“无”）。 1.6 参考资料 列出文档制定所参考的资料（若无则填写“无”）。 2测试项目

14、 对被测试对象进行描述。 3测试特征 描述测试的特征。 4测试方法 分析和描述本次测试采用的测试方法和技术。 5测试标准 描述测试通过的标准以及测试审批的过程，测试挂起/恢复的条件。 6系统测试交付物 测试完成后提交的所有产品。 7测试任务,24,7测试任务,8环境要求 8.1 硬件需求 8.2 软件需求 8.3 测试工具 8.4 其他 9角色和职责 10人员及培训 11系统测试进度,25,9.1.2 软件测试用例,在本书的第1章我们已经讲述了什么是测试用例，测试用例的评价标准，设计的基本原则，并给出了一个测试用例模板。但没有讨论如何记录和编写测试用例。如果你已经开始进行一些软件测试，就有可能

15、实验过各种想法和格式。这里我们将讲述编写测试用例的有关内容和将要考虑的更多选择。,26,IEEE829标准称测试用例说明为“编写 用于输入的实际数值和预期的输出结果 数值。测试用例还要明确指出使用具体测试用例产生的测试程序的任何限制。” 测试用例应该清楚地解释要向软件发送什么值或者条件，以及期望得到什么样的结果。它可以由一个或是多个测试用例说明来引用，也可以引用多个测试程序。IEEE829标准还为我们列出了应该包含在 测试用例规格说明中的重要信息。,27, 测试用例规格说明标识符。一个唯一的名 称或编号。可以由测试设计过程说明或测试程序 说明引用的唯一标识符。 测试项。描述被测试的详细特性、代码模块等。它还要提供产品说明书的引用信息或者测试管理所依据的其他设计文档。 输入说明。按值、值的范围或者（如果是文件）按名称列出所有输入内容或条件。确定相关的其他所有东西，包括内存驻留区域，由操作系统传递的值，支持程序或数据库，显示的提示消息以及输入之间的关系。描述任何时间安排上的 考虑。例如，如果测试人员应当在某条消 息后半秒内输入数据，那就要这样清楚地 说明。,28,输出说明。描述进行测试用例的预期输出 结果，包括列出所有输出值和消息，以及考虑 包括响应时间。 环境要求。是指执行测试用例必要的