软件测试过程所需的技能

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

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

2、所有的特征。如果在测试中使用该清单，就不会遗漏掉任何一个特征。常见的有用的做法是在清单中列出由该程序创建的所有报告，以及所有错误信息、菜单选项、对话框，每一对话框的所有选项等。创建清单时越仔细彻底，遗漏的东西就越少。 （2）避免不必要的重复和遗忘项目：当核对测试的清单或图表上的项目时，可以很容易地看出已经测试过的和还没有测试过的项目。4（3）分析程序并提出好的测试用例：例如在图形用户界面的数据输入项，每一个边界值都是一个很好的测试用例，因为边界值要比非边界值更容易发现缺陷。 （4）削减测试数量：不是从本质上增加遗漏缺陷的数量，而是改进测试的效率。其中的诀窍在于确定那些足够相似的测试用例，这样就

3、可以预期从每一个用例中获得同样的结果。接着只使用这些测试之一，而不是所有。5（5）提供最终测试的结构：当所有编码工作完成，系统的每部分看起来可以一起工作了， 最终测试就开始了。但是现在的产品发布都存 在着很大的压力，只有很少的时间可以用来 安排最终测试。所以以前测试的优秀笔录将 帮助确保最后一次运行了重要测试。如果没 有这些笔录，就不得不记住哪些测试需要重 新运行。 （6）检查完整性：不完整的测试计划会不同程 度地遗漏程序中的缺陷。测试计划通常会因 为忽略了程序区域、缺陷类别、测试类别， 或是简单疏忽而存在漏洞。62改善了测试任务与测试过程 间的联系（1）交流了测试人员策略背后的思想。 （2）

4、得出测试准确度和覆盖率的反馈。文档的读者 会告诉你忘记测试的程序区域，你对程序某些方 面的误解，以及未反应出的产品最新变化。 （3）得出测试深度和时间进度的反馈。有些测试计 划会产生许多关于测试数量的争议。一些项目经 理辩称测试计划要求的测试过多，这样就产生了 不必要的进度延迟，而其他项目的经理可能会抗 议说测试太少了，想要延长测试进度或者增加测 试人员从而增加测试的数量。7（4）交流测试工作的规模。测试计划显 示出了要进行的工作以及已完成工作的数量， 这会帮助经理及其他人理解为何你的测试小组 规模如此庞大，而且要花这么长的时间来完成 。如果项目只对如何更快或是不那么昂贵地执 行项目感兴趣，那

5、他就会考虑简化或者淘汰最 难以测试的程序区域。（5）分派工作。如果你能够给下一个测试人员提供一个书面的详细指令集，那么委派及监督产品的部分测试就要容易得多。83为组织、规划与管理测试项目提供了结构 （1）达成有关测试任务的协议。测试计划明确指 出测试人员将要做（或不做）什么工作。让其他人对这个计划进行评审，包括项目经理以及相关的经理、程序员、测试人员、营销人员，以及可能在项目中提出更进一步测试要求的其他人， 尽早利用评审引出不同意见，讨论并解决。9（2）确定任务。一旦你了解了要做什么，就 能估计并证明所需资源（金钱、时间、人员 和设备）是否有效。 （3）结构。确定任务时，可以看到很多概念 上相

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

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

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

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

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

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

12、否通过或未通过给定的测试。 测试交付物：列出所有要为该产品编写的测 试文档。 测试任务：列出准备测试和执行测试必需的 所有任务；说明任务之间的相关性，完成它们 所需要的特殊技能、人员等资源，谁完成任务 ，牵扯多少精力，以及每个任务何时可以完成。19 环境需求：描述必需的硬件、软件、测 试工具、实验设备等。 责任：为管理、设计、准备、执行、证明、 监察、改正、解决等的小组（或人）指定责 任。 人员及培训：包括每个技能水平你需要多少 人，他们需要进行多少培训。 测试进度：列出所有带日期的里程碑，以及 何时需要所有资源（人员、机器、工具和设 备）。测试进度可以使用固定日期，也可以使用相对日期。 20

13、 风险和意外事故：明确指出项目的潜在问 题或者风险区域，这是对测试工作最有影响 的因素。 核准：谁必须批准这一计划？为他们的签名 留出空间。根据IEEE829标准，我们提供了一个可以作为参考的系统测试计划模板。各个 公司可以根据自己的实际情况和每个项 目的具体情况确定测试计划的模板（如 下表）。21修改编号修改日期修改后版本修改者修改位置修改内容概述版本更新记录 表一 ：1介绍1.1 目的说明文档的目的。1.2 范围说明文档覆盖的范围。1.3 缩写说明定义文档中所涉及的缩略语（若无则填写“无”）。1.4 术语定义定义文档内使用的特定术语（若无则填写“无”）。 221.5 引用标准列出文档制定所

14、依据、引用的标准（若无则填写“无”）。1.6 参考资料列出文档制定所参考的资料（若无则填写“无”）。 2测试项目对被测试对象进行描述。 3测试特征描述测试的特征。 4测试方法分析和描述本次测试采用的测试方法和技术。 5测试标准描述测试通过的标准以及测试审批的过程，测试挂起/恢复的条件。 6系统测试交付物测试完成后提交的所有产品。7测试任务 238环境要求8.1 硬件需求8.2 软件需求8.3 测试工具8.4 其他9角色和职责10人员及培训11系统测试进度 24 IEEE829标准为我们列出了应该包含在测试用例规 格说明中的重要信息:测试用例规格说明标识符。一个唯一的名称或编号 。可以由测试设计

15、过程说明或测试程序说明引用的 唯一标识符。 测试项。描述被测试的详细特性、代码模块等。它还 要提供产品说明书的引用信息或者测试管理所依据 的其他设计文档。 输入说明。按值、值的范围或者（如果是文件）按名 称列出所有输入内容或条件。确定相关的其他所有 东西，包括内存驻留区域，由操作系统传递的值， 支持程序或数据库，显示的提示消息以及输入之间 的关系。描述任何时间安排上的考虑。9.1.2 软件测试用例25 输出说明。描述进行测试用例的预期输出结果，包括列出所有输出值和消息，以及考虑包括响应时间。 环境要求。是指执行测试用例必要的硬件、软件、测试工具，设备和人员等。 特殊过程要求。列出在设置、测试人

16、员行为或要为输出进行的分析中的任何不寻常情况。 测试用例间的相关性。在测试之前必须执行什 么测试，为什么，如果程序没有通过那些测试 会发生什么？即：如果一个测试用例依赖于其 他用例，或者受其他用例的影响，应该说明。269.1.3 软件测试报告按照IEEE829标准包括以下几个部分： 测试报告标识符。 总结。表明什么已经被测试（包括版本ID）， 在什么环境下进行的测试，并总结对它的评价 。需要参考测试用例规格明。 变异。报告测试过程相对指定测试过程的任何 偏离，并解释原因。 广泛性评估。测试是否与测试计划要求的一样 广泛？什么模块、特征或特征组合没有得到足 够测试，为什么？ 结果总结。对什么问题进行了报告，哪些问题 得到了解决，以及解决方案是什么？哪些问题 仍然没有解决？279.1.3 软件