从软件工程的角度来说，软件开发主要分为需求分析、概要设计、详细设计、编码、测试、安装及维护6个阶段。软件测试项目的过程管理绝不仅限于测试阶段，因为软件测试不能在代码全部完成后才开始，而应在项目需求分析阶段就开始审查需求分析文档、产品规格说明书，在设计阶段需要审查系统设计文档、程序设计流程图、数据流图等，在代码测试阶段需要审查代码，查看是否遵守代码的变量定义规则、是否有足够的注释内容等。从软件开发生命周期的角度来说，软件测试项目的过程管理在各个阶段的具体内容是不同的；但在每个阶段，测试任务的最终完成都需要经过从计划、设计、执行到结果分析、总结等一系列步骤，这构成软件测试的一个基本过程。

软件测试项目的过程管理主要集中在软件测试项目的启动、测试计划、测试用例设计、测试执行、测试结果的审查和分析，以及如何开发或使用测试过程管理工具上。本篇主要是从管理的角度去讨论如何组织、跟踪和控制这些过程，而不是从测试技术的角度去讨论如何设计和实现。测试过程管理的基本内容如下所述。

（1）测试项目启动阶段：首先需要确定项目负责人，即项目小组组长，项目组长确定以后，才可以组建整个测试小组，配合开发等部门开展工作；其次要参加有关项目计划、分析和设计的会议，获得必要的需求分析、系统设计文档，以及相关产品/技术知识的培训和转移。

（2）测试计划阶段：确定测试范围、测试策略和方法，对风险、日程表、资源等进行分析和估计。

（3）测试设计阶段：制订测试的技术方案，设计测试用例，选择测试工具，编写测试脚本等。测试用例设计需要做好各项准备再开始进行，最后还需要其他部门帮忙评审测试用例。

（4）测试执行阶段：搭建相关的测试环境，准备测试数据，执行测试用例，对发现的软件缺陷进行报告、分析、跟踪等。测试执行不涉及较高的技术性，但它是测试的基础，直接关系到测试的可靠性、客观性和准确性。

（5）测试结果的审查和分析阶段：测试执行结束后，需要对测试结果进行整体或综合的分析，以确定软件产品质量的当前状态，为产品的改进或发布提供数据和依据。从管理上讲，需要组织好测试结果的评审和分析会议，做好测试报告或质量报告的编写和评审。

软件测试的计划阶段

本篇将从测试项目实施和管理的角度，进一步讨论软件测试项目计划的实施目标和标准、计划阶段的细分、测试项目计划的要点和编制测试计划的一些技巧等。

1.软件测试项目计划的目标

测试项目计划的整体目标是确定测试任务、确定所需的各种资源和投入、预见可能出现的问题和风险，以指导测试的执行，最终实现测试目标，保证软件产品质量。制订测试计划需要达到的目标如下。

（1）为各项测试活动制订切实可行的、综合的计划，包括每项测试活动的对象、范围、方法、进度和预期结果。

（2）为项目实施建立一个组织模型，并定义测试项目中每个角色的责任和工作内容。

（3）开发有效的测试模型，可正确地验证正在开发的软件系统。

（4）确定测试所需要的时间和资源，以保证其可获得性、有效性。

（5）确立每个测试阶段测试完成及测试成功的标准、需要实现的目标。

（6）识别出测试活动中各种风险，并消除可能消除的风险，降低那些不可能消除的风险所带来的损失。

2.软件测试项目的标准

为保证测试可按计划执行，必须确认满足何种外部条件测试才能开始，即需要在测试计划中定义软件测试项目的输入标准，然后定义测试项目的输出标准。

（1）测试的输入标准如下。

① 整体项目计划框架：需要在框架清晰的情况下制订测试计划。

② 需求规格说明书：只有将用户具体的、实际的需求了解透彻，才能制定准确的测试需求和测试范围。

③ 技术知识或业务知识：技术的变化或新技术的引入需要事先准备，包括人员的培训。

④ 标准环境：符合用户使用环境或业务运行环境的需求。

⑤ 设计文档：设计文档是设计软件测试用例的重要参考资料，帮助测试人员了解系统的薄弱环节、关键点等。

⑥ 足够的资源：包括人力资源、时间资源，硬件资源、软件资源和其他环境资源。

⑦ 人员组织结构：项目经理、测试组长、小组成员等的责任及相互关系已确定。

（2）测试的输出标准如下。

① 测试执行标准。

② 缺陷描述和处理标准。

③ 文档标准和模板。

④ 测试分析、质量评估标准等。

3.测试实施策略的制定

测试策略描述当前测试项目的目标和所采用的测试方法。此目标不是上述测试计划的目标，而是针对某个应用软件系统或程序等具体的测试项目要达到的预期结果，包括在规定的时间内需要完成的测试内容、软件产品的特性或质量得到确认的方面。

测试策略还需要描述测试不同阶段（单元测试、集成测试、系统测试等）的测试对象、范围和方法以及每个阶段内所需要进行的测试类型（功能测试、性能测试、压力测试等）。

在制定测试策略前，需要确定测试策略项。测试策略制定需要考虑的内容如下。

（1）需要使用的测试技术和工具。例如，60%用 Rational Robot自动测试，40%采用手工测试。

（2）测试完成标准，用于计划和实施测试及通报测试结果。例如，95%以上的测试用例通过并且P1、P2级别的缺陷全部解决。

（3）影响资源分配的特殊考虑。例如，有些测试必须在极冷或极热的环境下进行，有些测试必须在周末进行，有些测试必须通过远程环境执行。

在确认测试方法时，需要根据实际情况，结合测试方法的特点来选择合适的方法。下面介绍两种常用的划分方法。

根据是否需要执行被测软件来划分，分为静态测试和动态测试。静态测试包括产品规格说明书、程序代码的审查等，在工作中容易被忽视，在测试策略上应说明如何加强这些环节。

根据是否针对系统的内部结构和具体实现算法来划分，分为白盒测试和黑盒测试。如何将白盒测试和黑盒测试有机地结合起来，也是编写测试策略时需要处理的问题之一。尽管用户更倾向于基于产品规格说明的功能测试，但白盒测试可以发现潜在的逻辑错误，而这种错误往往是功能测试无法发现的。

综上所述，可能需要在“基于测试技术的测试策略”和“基于测试方案的综合测试策略”之间进行选择。

4.测试项目计划阶段的细分

测试项目的计划需要经过计划初期、起草、讨论、评审等不同阶段，才能制订完成，并不能一气呵成。并且不同的测试阶段（单元测试、集成测试、系统测试、验收测试等）或不同的测试类型（安全性测试、性能测试、可靠性测试等）都可能需要有具体的测试计划。

（1）计划初期要收集整体项目计划、需求分析、功能设计、系统原型、用户用例（User Case）等文档或信息，理解用户的真正需求，了解技术难点和弱点或新的技术，与其他项目相关人员进行交流，确保在各个主要方面理解一致。

（2）测试计划最关键的步骤是确定测试需求、测试层次。要将软件分解成一个个的单元，对各个单元编写测试需求。测试需求也是测试设计和开发测试用例的基础，并且是用来衡量测试覆盖率的重要指标。

（3）计划起草是根据计划初期掌握的各种信息、知识，确定测试策略，设计测试方法，完成测试计划的框架。

（4）在将测试计划提供给其他部门讨论之前，要预先在测试小组/部门内部进行审查。

（5）召开有需求分析、设计、开发人员参加的计划讨论会议，测试组长对测试计划的思想、策略做较为详细的介绍，并听取在场人员对测试计划中各个部分的意见，进行讨论交流。

（6）项目中的每个人都应当参与测试计划的评审，包括市场、开发、支持、技术写作及测试人员。计划的审查是必不可少的，出自于一个测试工程师的定义不一定是完整或准确的。此外，测试工程师很难评估自己的测试计划，就像开发者很难测试自己的代码一样。每一个计划审查者都可能根据其经验及专长提出修改建议，有时还能提供测试工程师在组织产品定义时没有掌握的信息。

（7）在计划讨论、评审的基础上，综合各方面的意见，即可完成测试计划书，然后上报给测试经理或项目经理。得到批准，方可执行。

测试计划不仅服务于软件产品当前版本，而且还是下个版本的测试设计的主要信息来源。在进行新版本测试时，可以在原有的软件测试计划书上做修改，但需要经过严格审查。

5.测试项目计划的要点

软件测试计划内容主要包括产品基本情况、测试需求说明、测试策略和记录、测试资源配置、计划表、问题跟踪报告、测试计划的评审结果等。除了产品基本情况、测试需求说明、测试策略等，测试计划的焦点主要集中在以下几个方面。

（1）目标和范围：产品特性、质量目标，各阶段的测试对象、目标、范围和限制。

（2）项目估算：根据历史数据，采用恰当的评估技术，对测试工作量、所需资源（人力、时间、软硬件环境）做出合理估算。

（3）风险计划：测试可能存在的风险分析、识别，以及风险的回避、监控和管理。

（4）日程：获取项目工作分解结构，并采用时限图、甘特图等制定时间/资源表。

（5）项目资源：人员、时间、硬件和软件等资源的组织和分配，人力资源是重点，且与日程安排联系密切。

（6）跟踪和控制机制：质量保证和控制，变化管理和控制等。

测试计划书的内容也可按单元测试、集成测试、系统测试、验收测试等阶段去组织，为每个阶段制订一个计划书，也可为每个测试类型（安全性测试、性能测试、可靠性测试等）制订特殊的计划书。

同时，可为上述测试计划书的每项内容制订一个具体实施的计划。例如，对每个阶段的测试重点、范围、所采用的方法、测试用例设计的思想、提交的内容等进行细化，供测试项目组的内部成员使用。一些重要的项目中会形成一系列的计划书，如测试范围/风险分析报告、测试标准工作计划、资源和培训计划、风险管理计划、测试实施计划、质量保证计划等。

6.编制测试项目计划的技巧

在计划书中，有些内容仅作为项目参考，如测试项目的背景、所采用的技术方法等；但有些内容则可看作一种结论或承诺，必须要实施或必须达到目标，如测试小组结构和组成、测试项目的里程碑、面向解决方案的交付内容、项目标准、质量标准、相关分析报告等。

若要做好测试计划，测试设计人员需要仔细阅读相关资料，包括用户需求规格说明书、设计文档、使用说明书等，全面熟悉系统，并对软件测试方法和项目管理技术有深刻的理解。此外还有一些技巧，具体如下所述。

（1）确定测试项目的任务，清楚测试范围和测试目标，例如，提交什么样的测试结果。

（2）让所有合适的相关人员参与测试项目的计划制订，尤其是在测试计划早期。

（3）对测试的各阶段所需要的时间、人力及其他资源进行预估，尽量做到客观、准确、留有余地。

（4）制定测试项目的输入、输出和质量标准，并和有关方面达成一致。

（5）建立变化处理的流程规则，识别出整个测试阶段中内在的、不可避免的变化因素，并思考如何进行控制。

软件测试的设计和开发阶段

测试计划完成后，测试过程即将进入软件测试设计和开发阶段。软件测试设计建立在测试计划书的基础上，应认真理解测试计划中的测试大纲、测试内容及测试的通过准则，以及通过测试用例来完成测试内容的典型的逻辑转换，将其作为测试的实施依据，最终实现所确定的测试目标。软件设计是将软件需求转换成软件表示的过程，主要描绘出系统结构、详细的处理过程和数据库模式；软件测试设计则是将测试需求转换成测试用例，描述测试环境、测试执行的范围和层次、用户的使用场景。因此软件测试设计和开发是软件测试过程中技术深、要求高的一个关键阶段。

1.软件测试设计和开发的主要内容

（1）制订测试的技术方案。确认各个测试阶段需要采用的测试技术、测试环境和平台以及选择测试工具。有关系统测试中的安全性、可靠性、稳定性、有效性等的技术方案是这部分工作内容的重点。

（2）设计测试用例。根据产品需求分析、系统技术设计等规格文档，在测试的技术方案基础上设计具体的测试用例。

（3）设计特定的测试用例集合，满足特定的一些测试目的和任务。即根据测试目标、测试用例的特性和属性（优先级、层次、模块等），选择不同的测试用例，构成执行某个特定测试任务的测试用例集合（组），如基本测试用例组、例外测试用例组、性能测试用例组、完全测试用例组等。

（4）测试开发。根据所选择的测试工具，将所有可进行自动化测试的测试用例转换为自动化测试脚本的过程。

（5）测试环境的设计。根据所选择的测试平台及测试用例所要求的特定环境，进行服务器、网络等测试环境的设计。

软件测试设计中还需要考虑：所设计的测试技术方案是否可行、是否有效、是否能达到预期的测试目标；所设计的测试用例是否完整，边界条件是否考虑，其覆盖率能达到多高；所设计的测试环境是否和用户的实际使用环境比较接近。

关键是做好测试设计前的知识传递，将设计/开发人员已掌握的技术、产品、设计等知识传递给测试人员；同时，需要做好测试用例的审查工作，不仅需要通过测试人员的审查，还需要通过设计/开发人员的审查。

2.测试用例设计的方法和管理

（1）测试用例设计方法

软件测试用例设计有白盒测试和黑盒测试相对应的设计方法。黑盒测试的用例设计采用等价类划分、因果图、边界值分析、用户界面测试、配置测试、安装选项验证等方法，适用于功能测试和验收测试。而白盒测试的用例设计有多种方法，具体如下所述。

① 采用逻辑覆盖（包括程序代码的语句覆盖、条件覆盖、分支覆盖）的结构测试用例的设计方法。

② 基于程序结构的域测试用例设计方法，其中“域”是指程序的输入空间。域测试是在分析输入空间的基础上，完成域的分类、定义和验证，从而对各种不同的域选择适当的测试点（测试用例）进行测试。

③ 数据流测试用例设计方法是通过程序的控制流，从建立的数据目标状态的序列中发现异常结构的测试方法。

④ 根据对象状态或等待状态变化来设计测试用例，也是比较常见的方法。

⑤ 基于程序错误的变异来设计测试用例，可有效地发现程序中某些特定的错误。

⑥ 基于代数运算符号的测试用例设计方法。受分支问题、二义性问题和大程序问题的困扰，此方法使用较少。

（2）测试用例的属性

测试用例需要经过创建、修改和不断改善的过程，一个测试用例应具备的属性如下。

① 测试用例的优先次序。优先级越高，被执行的时间越早，执行的次数越多。由优先级最高的测试用例组构成基本验证测试（Basic Verification Test,BVT），每次构建软件包时，都会被执行一遍。

② 测试用例的目标性。有的测试用例为主要功能而设计，有的测试用例为次要功能而设计，有的测试用例为系统的负载而设计，有的测试用例则为一些特殊场合而设计。

③ 测试用例所属的范围及其所属的组件或模块。这种属性被用来管理测试用例。

④ 测试用例的关联性。测试用例一般和软件产品特性相联系，多数情况下用于验证产品的某个功能。这种属性可被用于验证被修改的软件缺陷，或对软件产品紧急补丁包的测试。

⑤ 测试用例的阶段性。测试用例属于单元测试、集成测试、系统测试、验收测试中的某一个阶段。对每个阶段构造一个测试用例的集合并执行，容易计算出该阶段的测试覆盖率。

⑥ 测试用例的状态性。若测试用例当前无效，则被置于非激活状态，不会被运行，只有被激活的测试用例才被运行。

⑦ 测试用例的时效性。针对同样功能，可能所用的测试用例不同，因为不同的产品版本在产品功能、特性等方面的要求不同。

⑧ 所有者、日期等属性。测试用例的属性还包括创建人、创建时间、修改人、修改时间。

根据上述属性，再结合测试用例的编号、标题、描述（前置条件、操作步骤、期望结果）等，即可对测试用例进行基于数据库方式的良好管理。

（3）测试用例的审查

测试用例设计完成后，需要经过非正式和正式的审查，两种审查方式具体如下所述。

① 非正式的审查：一般在测试小组内部进行，同测试组人员互相检查或让资深人员、测试组长帮助审查。

② 正式的审查：一般通过正式 E-mail 将已设计好的测试用例发送给相应的系统分析、设计人员和程序员，让其先通读一遍，将发现的问题记录下来。然后由测试组长或项目经理召开一个测试用例评审会，由测试设计人员先对测试用例的设计思想、方法、思路等进行说明，然后系统分析、设计人员和程序员提出问题，测试人员做出回答，必要时进行讨论。

评审完的测试用例经修改后，即可直接用于手工测试或用于测试脚本的开发。

3.测试开发

使用所选择的测试工具脚本语言（如Rational SQABasic）编写测试脚本，将所有可进行自动化测试的测试用例转化为测试脚本。其输入是基于测试需求的测试用例，输出是测试脚本和与之相对应的期望结果，这种期望结果一般存储在数据库中或特定格式的文件中。

（1）测试开发的步骤：首先要搭建测试脚本开发环境，安装测试工具软件，设置管理服务器和具有代理的客户端池，建立项目的共享路径、目录，并能连接到脚本存储库和被测软件等；然后执行录制测试脚本初始化过程、独立模块过程、导航过程和其他操作过程，结合已经建立的测试用例，对录制的测试脚本进行组织、调试和修改，构成一个有效的测试脚本体系，并建立外部数据集合。

（2）由于被测系统处在不完善阶段，在运行测试脚本的过程中容易中断，因此在测试脚本开发时，需要将此类错误处理好，并及时记录当时的状态，而且要求可以继续执行下去。解决上述问题的办法有很多，例如，跳转到别的测试过程、调用一个能够清除错误的过程等。

（3）测试开发常见的问题：测试开发很乱，与测试需求或测试策略没有对应性；测试过程不可重用；测试过程被作为一个编程任务来执行，导致脚本可移植性差。应在脚本的结构、模块化、参数传递、基础函数（库）等方面做好设计，从而避免上述问题。

软件测试的执行阶段

1.软件测试执行阶段的管理难点

测试用例的设计和测试脚本的开发完成后，即开始执行测试。测试执行阶段分为手工测试和自动化测试。

手工测试：在合适的测试环境下，按照测试用例的条件、步骤要求，准备测试数据，对系统进行操作，比较实际结果和测试用例所描述的预期结果，以确定系统是否真正实现了所需功能。

自动化测试：通过自动化测试工具，运行测试脚本，得到测试结果。

自动化测试的管理相对比较容易，测试工具会百分之百地执行测试脚本，并自动记录测试结果。而对手工测试的管理相对要复杂得多，在整个测试执行阶段中，管理上会碰到一系列问题。

（1）如何确保测试环境满足测试用例所描述的要求？

（2）如何保证每个测试人员清楚自己的测试任务？

（3）如何保证每个测试用例得到百分之百的执行？

（4）如何保证所报告的缺陷正确、描述清楚、没有漏掉信息？

（5）如何在验证缺陷和对新功能的测试之间寻找平衡？

（6）如何跟踪缺陷处理的进度，使严重的缺陷及时得到解决？

（7）如何确保正确的测试环境？需要专人（OA实验室管理人员、测试组长等）进行检查。

2.测试阶段目标的检查

测试阶段目标的检查需要对每个测试阶段（单元测试、集成测试、确认测试、系统测试和验收测试等）的结果进行分析，保证每个阶段的测试任务得到执行，达到阶段性的目标。

（1）单元测试：目的在于检查每个程序单元是否正确实现详细设计说明中的模块功能、性能、接口和设计约束等，发现各模块内部可能存在的各种错误。

（2）集成测试：主要目标是发现与接口有关的问题。不管是外部接口还是内部参数的传递，都需要抓住关键模块，关键模块应尽早测试，并将自顶向下、自底向上两种测试策略相结合，对各个模块严格执行。由于涉及系统不同的模块、不同的层次或不同的部门，容易造成一些漏洞、疏忽，需要根据设计文档多提问题、集体审查。

（3）确认测试：主要目的是表明软件是可以正常工作的，并且确保软件的所有功能和性能以及其他特性与用户的要求一致。只有通过了确认测试的软件才具备进入系统测试阶段的资格。

（4）系统测试：目标是保证系统在实际的环境中能够稳定、可靠地运行。包括恢复性测试、安全性测试、强度测试和性能测试等。系统测试技术要求高，占用资源比较多，因此应设计完备，并准备充分。

（5）验收测试：验收测试既可是非正式的测试，也可是正式的、有计划的测试。一个软件产品可能拥有众多用户，不可能由每个用户验收，此时应多采用称为α、β测试的过程。α测试是指软件开发公司组织内部人员模拟各类用户对即将发布的软件产品（称为α版本）进行测试，尝试发现错误并修正。α 测试的关键在于尽可能逼真地模拟实际运行环境和用户可能的操作方式。经过α测试调整的软件产品，称为β版本。紧随其后的β测试是指组织公司外部的典型用户试用β版本，并要求用户报告异常情况、提出批评意见，然后再对β版本进行修改和完善。

3.测试用例执行的跟踪

测试用例执行直接关系到测试的效率、结果，不仅需要做到测试效率高，而且需要保证结果正确、准确、完整等。其管理关键是提高测试人员素质和责任心，树立良好的质量文化意识，其次需要通过一定的跟踪手段从某些方面保证测试执行的质量。

（1）测试效率的跟踪比较容易，按照测试任务和测试周期，可得到期望的曲线，然后每天检查测试结果，了解是否按预期进度进行。

（2）测试结果的跟踪比较困难，应将每个人的执行测试情况记录好，即清楚每个测试用例的执行人员，一旦某个缺陷被遗漏，可以追溯到具体责任人。

4.缺陷的跟踪和管理

缺陷的跟踪和管理一般由数据库系统来执行，但数据库系统也是依赖于一定的规则和流程工作的。管理思路如下所述。

（1）设计好每个缺陷应包含的信息条目、状态分类等。

（2）通过系统自动发送邮件给相应的开发人员和测试人员，使任何缺陷都不被遗漏，并能得到及时处理。

（3）通过日报、周报等各类项目报告来跟踪目前缺陷状态。

（4）在各个大小里程碑之前，召开相关人员的会议，对缺陷进行会审。

（5）通过历史曲线、统计曲线等进行分析，预测未来情况。

5.和项目组外部人员的沟通

为了使测试进展顺利，与项目组外部人员保持良好沟通是非常有必要的，这样，测试碰到的问题比较容易解决，测试中发现的缺陷处理效率也会提高。

（1）下面列举一些有利于沟通的技巧。

① 通过一种合适的、可接受的方式指出对方的问题，尽量做到对事不对人。

② 每周召开一次不同部门一起参加的会议。

③ 建立大项目的邮件组，包含各部门主要人员的邮件地址。

④ 在同一个大项目组的开发、测试人员的日报、周报等需要互相抄送。

⑤ 适当开展一些类似于聚餐的活动，改善组员关系，增进各方面人员的相互了解。

（2）人员间的基本通信方式主要有以下5种。

① 正式非个人方式。例如，正式审查会议。

② 正式个人之间交流。例如，成员之间的正式讨论，有电子邮件跟踪或文字记载，并包含所做出的结论，方便后期跟踪、审查。

③ 非正式个人之间交流。例如，个人之间通过电话、即时消息系统的自由交流。

④ 内部公共论坛。大家就某个主题发表自己看法，提相关问题或回答相关问题。

⑤ 成员网络。例如，成员与小组之外或公司之外有经验的相关人员进行交流。

6.测试执行结束

测试执行全部完成，并不意味着测试项目的结束。测试项目结束的阶段性标志是将测试报告或质量报告发送出去，并得到测试经理或项目经理的认可。除了测试报告或质量报告的写作之外，还要对测试计划、设计和执行等进行检查、分析，完成项目的总结。

关于测试报告或质量报告的写作，主要简单介绍对测试执行结束前后的管理。

（1）审查测试全过程：在原来跟踪的基础上，需要对测试项目进行全过程、全方位的审视，检查测试计划、测试用例是否得到执行，检查测试是否有漏洞。

（2）对当前状态的审查：包括产品缺陷和过程中未解决的各类问题。对产品目前存在的缺陷进行逐个分析，了解对产品质量的影响程度，从而决定产品的测试能否告一段落。

（3）结束标志：根据上述两项的审查进行评估，若所有测试内容完成、测试的覆盖率达到要求以及产品质量达到已定义的标准，即可定稿测试报告，并发送出去。

（4）项目总结：通过对项目中的问题进行分析，找出流程、技术或管理中所存在的问题根源，避免重蹈覆辙，并获得项目成功经验。