这篇文将讨论测试人员日常工作，及怎样将质量灌输到软件中。我们将先讨论什么是软件测试，什么是质量保障，它们之间如何关联？软件测试和质量保障涉及到哪些日常工作，有哪些问题点和领域可改善，以及作为一个测试者，如何在任何软件开发生命周期中，都能对开发过程提供价值呢。

　　什么是软件测试？

　　软件测试是分析者用来发现软件缺陷的有组织的过程。你可能会问，什么是缺陷？缺陷是代码中导致软件应用中断的问题。没有任何软件是完全无缺陷的，测试者的目标是减少在项目中找到的缺陷，并且将质量灌输到软件应用中。软件测试包括检验软件不能满足用户需求规格说明中描述的需求及不能满足用户所需的过程。软件测试者通过分析软件来获知软件是否符合用户的期望。软件测试是一种设计来适当保障软件符合用户所需质量的活动。

　　什么是质量保障？

　　质量保障是恰当的确保软件过程在有效的方式下，被有条不紊地被执行的所有活动的汇总。它涉及到正确的做测试和做正确的测试。软件质量保障检查软件过程是否正确且符合组织内部运作的标准。质量保障涉及到软件测试外更多的内容，但软件测试依然是质量保障专业需要的内容。缺了它，就不能称保证质量保障过程是正确妥当的。它们之间如何互相关联呢？

　　就如你看到的，软件测试只是软件质量保障的一个方面。软件测试通常被称作为质量控制。在组织中，质量控制是质量保障计划中的一个组件。在一些组织中，软件测试角色从质量保障分析师角色中被剥离出来。在这样的组织中，软件质量保障涉及到完成技术检查列表和文档评审以检验软件和文档均能符合标准。

　　软件测试和质量保障的日常任务

　　软件需求规范一旦被产出，测试人员就“测试”文档确认需求是否完整、正确、一致，和可被测试。在一个敏捷的环境中，软件需求一旦编写出来就会被测试。在瀑布式的软件开发生命周期中，软件需求规范先被编写出来，然后测试它的完整性、正确性、一致性和可测试性。完整性通过需求是否能告诉你在哪里测试、如何测试及要测试什么来衡量。正确性意味着你知道要测试的应用的一些方方面面。你必须对你要测试的软件有些了解，才能知道需求是否正确。一致性是指需求中不存在逻辑缺陷。可测试的需求是指一份你可以为它编写测试案例的需求。

　　在需求评审之前或之后，一个主测试计划会被编写，包括介绍、背景、范围、缩略语、定义、将被测试的特性、不被测试的特性、约束、假设、风险和意外、日程表、角色/责任、和参考。主测试计划被测试团队用来决定测试工作将被执行多长时间。测试人员也使用主测试计划作为测试计划。介绍、背景、范围、术语、定义和参考是测试计划的前序。它们简述项目的背景，预期的读者是谁及项目的确切定义是什么（包括哪些内容和不包括哪些内容）。缩略语简要描述了测试计划中使用到的缩写。定义章节定义了在测试计划中使用到的新术语。参考章节列出了建立测试计划用到的文档资料。典型情况，测试计划引用了软件需求规格和软件设计文档。“将被测试的特性”章节包括所有软件需测试的功能特性的列表、性能需求、可用性需求、和安全需求。“不被测试的特性”章节包括不会被测试的特性。约束和假设章节鉴定出有那些会影响到项目和软件测试的因素，也包括任何项目所持有的基本信念。约束也表述了软件项目所受的限制。在风险和意外章节，所有的风险和意外处理计划及缓解策略一起被表述。没有人喜欢讨论风险，但是这应该是在规范项目计划时，最先的被讨论的问题之一。风险分析是缓解软件开发固有的风险的方法之一。风险分析是处理每个需求涉及到的风险的重要性和优先级的一个系统过程。日程表章节讨论测试活动发生的时间。角色/责任章节简述了谁负责交付什么。最后的一个章节是附录章节。章节之间通常并不是按照我所描述的顺序，但列出的内容已经包括了主测试计划的最主要的那些部分。

　　在需求评审结束后，测试人员开始依照软件需求规格写测试案例或用例。用例记录系统如何和多种角色进行交互，而测试案例的编写更加具体得多。依照使用的方法，一个测试案例或者用例文档被产出。我们假设测试人员编写测试案例。在测试案例文档中，测试者通常要放入描述、测试步骤、期望的结果、实际结果、通过/失败结果和屏幕截图。在测试已经开始以后，屏幕截图是一个用于证明测试已通过的必要附件。测试步骤通常也叫做测试脚本。为了简化问题的描述，这里我们假设采用的是手工测试的方法。迟一些，我们会转向自动化测试的讨论。

　　接下来，作为工作成果中正式评审的一部分，测试案例文档和主测试计划一起被提交评审。基于评审产生修订后的版本。所有的关系人需出席评审会议，包括需求分析师、开发人员、测试人员、项目经理。如果有一个独立的执行软件质量保障的分析师角色，他（她）也被要求参加评审。讨论每一页的文档，找到是否需要作出一些修改，或需要阐明一些问题。一旦问题被记下来，测试人员基于正式评审来修订主测试计划和测试案例。问题将被跟踪直到被关闭，并通过其它批准工作产出的会议制定决策，或者通过email处理工作产出评审。

　　测试人员还需要产出一个绑定软件需求规格到软件设计文档和测试案例文档的跟踪矩阵。在需求和测试案例之间最少需要建立一对一或者一对多的映射。在一些公司，质量保障分析员/测试人员还需要评审软件设计文档，确认每一个需求都已经在软件设计文档中进行了说明。用这种方法，测试人员能完全确认每一个测试案例可以跟踪到一个需求，及每一个需求可以跟踪到一个软件程序、选项，或者菜单。可跟踪性是一个软件测试过程里的关键质量属性。