文档编写人员.ppt

第9章软件测试过程所需的技能 本章内容提要 ■ 软件测试文档的编写 ■ 软件测试用例的设计 ■ 缺陷的报告和分析 ■ 问题跟踪系统 （1）提高测试覆盖率：测试计划要求有一个程 序特征清单，要列出该清单就必须找出所有的 特征。如果在测试中使用该清单，就不会遗漏掉任何 一个特征。常见的有用的做法是在清单中列出由该 程序创建的所有报告，以及所有错误信息、菜单选 项、对话框，每一对话框的所有选项等。创建清 单时越仔细彻底，遗漏的东西就越少。 （2）避免不必要的重复和遗忘项目：当核对测 试的清单或图表上的项目时，可以很容易地 看出已经测试过的和还没有测试过的项 目。 （5）提供最终测试的结构：当所有编码工作完 成，系统的每部分看起来可以一起工作了，最 终测试就开始了。但是现在的产品发布都存 在着很大的压力，只有很少的时间可以用来 安排最终测试。所以以前测试的优秀笔录 将帮助确保最后一次运行了重要测试。如果 没有这些笔录，就不得不记住哪些测试需要重新运行。 （6）检查完整性：不完整的测试计划会不同程度 地遗漏程序中的缺陷。测试计划通常会因 为忽略了程序区域、缺陷类别、测试 类别，或是简单疏忽而存在漏洞。 2．改善了测试任务与测试过程间的联系 （1）交流了测试人员策略背后的思想。 （2）得出测试准确度和覆盖率的反馈。文档的读者会告诉你忘记测试的程序区域，你对程序某些方面 的误解，以及未反应出的产品最新变化。 （3）得出测试深度和时间进度的反馈。有些测试计划会产生许多关于测试数量的争议。一些项目经理 辩称测试计划要求的测试过多，这样就产生了不 必要的进度延迟，而其他项目的经理可能会抗 议说测试太少了，想要延长测试进度或者增 加测试人员从而增加测试的数量。 不管是否存在测试文档，上面的问题都会浮现出来，而测试计划则有助于集中讨论，并 使得达成特定协议更加容易。当一个清晰、详 细的测试计划可供参考时，这些讨论就会更 加理性，现实和实用。 （4）交流测试工作的规模。测试计划显示出了要进行的工作以及已完成工作的数量，这会帮 助经理及其他人理解为何你的测试小组规模 如 此庞大，而且要花这么长的时间来完成。 如果项目只对如何更快或是不那么昂贵 地执 行项目感兴趣，那他就会考虑 简化或者淘汰最难以测试的程序区域。 （5）分派工作。如果你能够给下一个测试 人员提供一个书面的详细指令集，那么委 派及监督产品的部分测试就要容易得多。 3．为组织、规划与管理测试项目提 供了结构 （1）达成有关测试任务的协议。测试计划明确指出测试人员将要做（或不做）什么工作。让其他 人对这个计划进行评审，包括项目经理以及相 关的经理、程序员、测试人员、营销人员，以及 可能在项目中提出更进一步测试要求的其他 人，尽早利用评审引出不同意见，讨论并 解决。 （2）确定任务。一旦你了解了要做什么，就能估计并证明所需资源（金钱、时间、人员和设备）是否有效。 （3）结构。确定任务时，可以看到很多概念上相关的以及方便共同进行的事情。把这些任务 集分组，并把某组中的所有任务分配给同一 个人或同一小组。一组接一组地集中测试。 （4）组织。一个全面开发的测试计划要确定由谁执行什么测试，如何测试，何时何地，利用 什么资源完成，以及为何要完成这些特 定的测试或测试集。 （5）调整。项目经理或项目的主任测试员把测试 计划作为一个委派工作以及告知其他人某人已 分配了什么工作的基础。及时跟踪正在执行 的任务，以及那些花费了比预期的时间更长 时间的任务，必要时迅速调整人员和设备 的分配。 （6）改进个人责任。 ① 测试人员明白他应该对什么负责。委派工作时，如 果你对