软件测试过程与改进技术论文.doc

xx大学毕业设计(论文) 第 IV 页
软件测试过程与改进技术

摘 要

软件测试是软件质量保证的重要手段，虽然在国外，软件测试技术已经发展到了比较高的水平，但是在国内还没有一个能够适用于中、小型软件公司的软件测试过程规范，导致了这些占中国软件行业很大比重的中、小型软件公司生产出来的软件，质量无法从过程上进行控制，极大的制约了中国软件行业的发展。
其实，单从软件开发的技术来说，国内相比国外并不落后，之所以会在软件测试技术上落后这么多，其根本原因在于国内跟国外软件公司能够使用的软件测试资源有巨大差别，这就决定了无法像软件开发技术一样，将国外现行的软件测试过程直接拿来套用到国内软件公司的开发过程上。
针对这样一种情况，在分析了国内外软件测试资源的具体差别之后，提出了让软件开发人员承当一部分测试任务的想法，同时设计了一些对测试控制的量化标准，用来加强对过程的控制，从而进一步降低由于测试人员水平不同所造成的影响。
本文将介绍课题来源、研究意义和目前情况，然后提出一种适用于国内中、小型软件公司的软件测试过程模型，用来保证软件开发的质量。

关键字：软件测试，质量保证，过程模型，量化控制

The Process of Software Testing and its Improved Techniques

Abstract

Software testing is an important way for quality assurance, overseas, the software testing technology has been developed to a higher level, but in china, there still no software testing process specification for small and medium-sized software companies, these led to the software produced by small and medium-sized software companies which accounted for the majority of software companies in china, can't assure the quality through the process control.
In fact, solely from the development of software technology, China is not so behind compared to foreign. The reason why the software testing technologically backward so many is the vast differences of the useable software testing resources. This determines not like the same software development technology, taking the foreign software testing process directly.
In such a situation, after analyzing the specific differences of china's and foreign, taking the ideas which let the software developers take some testing task. Meanwhile, designing some quantitative criteria for testing. So as to further reduce the level of testing personnel about the impact.
This paper introduces the source of issue, the significance of study , present condition, then raise a software testing process model for Chinese small and medium-sized software companies, to assuring the quality of software development.

Key Words: Software Testing, Quality Assurance, Process Model, Quantization

目 录
1．绪论 1
1.1 课题背景及目的 1
1.1.1 课题背景 1
1.1.2 课题目的 2
1.2 课题目前研究情况及存在问题 2
1.2.1 软件开发过程现状 2
1.2.2 软件过程管理的现状 9
1.2.3 软件测试的现状 11
1.3 课题研究内容及意义 12
1.3.1 研究内容 12
1.3.2 意义 13
2．过程的总体设计 14
2.1 过程中各阶段的关键点的描述 14
2.2 设计原则 14
2.3 小结 15
3．需求分析阶段 16
3.1 需求阶段过程总揽 16
3.2 测试人员介入项目的时间点 17
3.3 测试文档的开发 18
3.3.1 功能点测试说明书 18
3.3.2 测试计划制定 18
3.3.3 测试用例的设计 19
3.4 量化控制数据 22
3.4.1 测试用例编写的时间 22
3.4.2 测试用例的详细程度 23
3.4.3 需求评审的缺陷控制 24
4．设计阶段 25
4.1 过程图 25
4.2 设计评审 26
4.3 单元集成测试用例的设计 26
4.4 系统测试数据的准备 26
4.5 量化控制数据 27
4.5.1 概要设计评审 27
4.5.2 详细设计评审 27
5．编码集成阶段 28
5.1 过程图 28
5.2 代码审查 28
5.3 单元测试 29
5.3.1 单元测试任务 30
5.3.2 单元测试过程 30
5.4 集成测试的方法 30
5.5 量化控制数据 31
5.5.1 代码审查缺陷 31
5.5.2 单元测试缺陷 32
5.5.3 集成测试缺陷 32
6．系统测试阶段 33
6.1 过程图 33
6.2 搭建独立的测试环境 34
6.3 系统测试的执行 34
6.4 测试发现缺陷的管理 35
6.4.1 缺陷的分级标准 35
6.4.2 缺陷的管理过程 41
6.5 系统测试报告 42
6.6 量化控制数据 43
6.6.1 功能点的覆盖率 43
6.6.2 测试用例的通过率 43
6.6.3 系统测试缺陷率 43
总结 44
致谢 45
参考文献 46

xx大学软件学院

xx大学毕业设计(论文) 第 49 页
1．绪论
1.1 课题背景及目的
1.1.1 课题背景
软件是“(1)能够完成预定功能和性能的可执行的指令(计算机程序)；(2)使得程序能够适当地操作信息的数据结构；(3)描述程序的操作和使用的文档”[1]。而软件测试是根据软件开发各阶段的规约和软件的内部结构，精心设计一批测试用例（包括输入数据及其预期的输出结果），并利用这些测试用例去运行程序，以发现软件中不符合质量特性要求（即缺陷或错误）的过程。
进行软件测试的两个主要原因是：“对质量或可接受性做出判断，以及发现问题。” [2]软件测试不等同于程序测试。软件测试应当贯穿软件生存周期全过程。因此，需求描述、需求规格说明书、设计说明书以及程序本身等都应成为软件测试的对象。换句话说，软件测试包括程序测试和各类文档的评审，这就是对软件测试的广义理解。相对的狭义理解就是程序测试，但也不等于要等到程序编好了才进行测试。
对于软件测试的发展，Edward Kit 在他的畅销书“Software Testing In The Real World : Improving The Process”[3]中将其分为三个阶段：
第一个阶段是60年代及其以前，那时软件规模都很小、复杂程度低，软件开发的过程随意。开发人员的Debug过程被认为是唯一的测试活动。其实这并不是现代意义上的软件测试，当然一阶段也还没有专门测试人员的出现。
第二个阶段是70年代，这个阶段开发的软件仍然不复杂，但人们已开始思考开发流程问题，并提出“软件工程Software Engineering”的概念。但是这一阶段人们对软件测试的理解仅限于基本的功能验证和Bug搜寻，而且测试活动仅出现在整个软件开发流程的后期，虽然测试由专门的测试人员来承担，但测试人员都是行业和软件专业的入门新手。
第三个阶段是80年代及其以后，软件和IT行业进入了大发展。软件趋向大型化。与之相应，人们为软件开发设计了各种复杂而精密的流程和管理方法（比如CMM和MSF），并将“质量”的概念融入其中。软件测试已有了行业标准（IEEE/ANSI ），它再也不是一个一次性的，而且只是开发后期的活动，而是与整个开发流程融合成一体。软件测试已成为一个专业，需要运用专门的方法和手段，需要专门人才和专家来承担。
对比以上国外软件发展的各个阶段说明可以发现，目前国内的软件测试发展跟美国的70年代很相似，虽然很多公司已经具备了专职的测试人员，却都是技术能力较弱的人来担当，一般的做法就是开发不行的就去做测试，因为测试“不需要太多技术”，像这样的认识是非常错误的。同时对于测试过程也没有进行严格的定义，只是编码完成了就找测试人员来乱点一通，然后发现问题了再拿去修改，对于问题是怎么发现的，以及如何解决的都没有进行记录，以至于经常会在相同的问题上重复浪费资源。
虽然说在软件测试方面比国外落后了很多年，但是，单从软件开发过程方面来说，国内却并不落后，各种新技术、新框架的应用都很普遍，究其原因也是跟国内软件的开发环境有关，因为目前国内的公司普遍重视开发而轻视测试，因为在开发上运用一项新技术马上就能看到效益，而软件测试方面的改进却不那么容易看到成效，因而像国外那种大投入的软件测试新技术也就不那么容易引入到国内，这也就导致了开发的技术跟测试的技术发展严重不同步，针对这样的现象，急需一套适合中国国情的软件测试过程来提高国内软件开发的质量。

1.1.2 课题目的
本课题的研究的目的就是要根据国内现有的软件开发及测试资源现状，设计出一套更合理，并且适合于中国中、小型软件公司开展使用的软件测试过程模型，用来保证这些软件公司的软件开发质量，解决这些公司由于测试资源上的缺陷而无法套用国外现行测试模型的困境。

1.2 课题目前研究情况及存在问题
1.2.1 软件开发过程现状
要想真正设计出一套适用于国内中、小型软件公司的软件测试过程模型，首先，就必须要对他们所使用的软件开发过程模型有所了解，根据IT168的“中国软件项目开发管理体系建立状况分析”[4]我们可以发现，目前国内中、小型软件公司常见的软件开发模型包括以下几种：
1.2.1.1 边做边改模型（Build-and-Fix Model）
在这种模型中，既没有规格说明，也没有经过设计，软件随着客户的需要一次又一次地不断被修改.在这个模型中，开发人员拿到项目立即根据需求编写程序，调试通过后生成软件的第一个版本。在提供给用户使用后，如果程序出现错误，或者用户提出新的要求，开发人员重新修改代码，直到用户满意为止。 其基本过程可以用图1.1表示：
软件的第一个版本
对系统进行修改，直到客户满意
维护

图1.1 边做边改模型流程图
这是一种类似作坊的开发方式，对编写几百行的小程序来说还不错，但这种方法对任何规模的开发来说都是不能令人满意的，其主要问题在于：
（1） 缺少规划和设计环节，软件的结构随着不断的修改越来越糟，导致无法继续修改；
（2） 忽略需求环节，给软件开发带来很大的风险；
（3） 没有考虑测试和程序的可维护性，也没有任何文档，软件的维护十分困难。
目前国内采用该种开发模式的公司一般都是10人以下的小公司或是创业初期的公司，由于中国目前存在大量这样的小公司，因此这种开发模式下开发出来的软件数量也是相当庞大的，不过按照中国软件的正常发展，2-3年内，这类软件公司就会转型，或者是被清理掉，因此，针对这类模型没必要设计专门的软件测试模型。
1.2.1.2 瀑布模型（Waterfall Model）
1970年Winston Royce提出了著名的"瀑布模型"[5]，瀑布模型将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落，具体流程如图1.2所示：
系统需求
软件需求
分析
测试
设计
编码
实施

图1.2 瀑布模型流程图
在瀑布模型中，软件开发的各项活动严格按照线性方式进行，当前活动接受上一项活动的工作结果，实施完成所需的工作内容。当前活动的工作结果需要进行验证，如果验证通过，则该结果作为下一项活动的输入，继续进行下一项活动，否则返回修改。
瀑布模型强调文档的作用，并要求每个阶段都要仔细验证。但是，这种模型的线性过程太理想化，已不再适合现代的软件开发模式，其主要问题在于：
（1） 各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量；
（2） 由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发的风险；
（3） 早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。
这是目前国内中、小型软件公司中以接项目为主要业务公司的最为普遍的开发模型，当然也不是完全按照这种模型，下文中还会有更具体的分析。

1.2.1.3 原型模型（Prototype Model）
先借用已有系统作为原型模型，通过“样品”不断改进，使得最后的产品就是用户所需要的，其过程模型如图1.3
原型样品模型
分析
设计
编码
测试
使用

修改与改进

图1.3 原型模型流程图
原形模型的特点：
(1）开发人员和用户在“原型”上达成一致。这样一来，可以减少设计中的错误和开发中的风险，也减少了对用户培训的时间，而提高了系统的实用、正确性以及用户的满意程度。
（2）缩短了开发周期，加快了工程进度。
（3）降低成本。
原型模型的缺点：
当告诉用户，还必须重新生产该产品时，用户是很难接受的。这往往给工程继续开展带来不利因素。
在国内这种模型一般很少有公司会单独使用，一般是结合瀑布模型来使用。

1.2.1.4 增量模型（Incremental Model）
与建造大厦相同，软件也是一步一步建造起来的。在增量模型中，软件被作为一系列的增量构件来设计、实现、集成和测试，每一个构件是由多种相互作用的模块所形成的提供特定功能的代码片段构成，流程如图1.4：
增量1
分析
设计
编码
测试
分析
设计
编码
测试
分析
设计
编码
测试
增量3
交付的增量1
交付的增量2
交付的增量3
增量2
图1.4 增量模型流程图
增量模型在各个阶段并不交付一个可运行的完整产品，而是交付满足客户需求的一个子集的可运行产品。整个产品被分解成若干个构件，开发人员逐个构件地交付产品，这样做的好处是软件开发可以较好地适应变化，客户可以不断地看到所开发的软件，从而降低开发风险。但是，增量模型也存在以下缺陷：
（1） 由于各个构件是逐渐并入已有的软件体系结构中的，所以加入构件必须不破坏已构造好的系统部分，这需要软件具备开放式的体系结构。
（2） 在开发过程中，需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型，但也很容易退化为边做边改模型，从而是软件过程的控制失去整体性。
在使用增量模型时，第一个增量往往是实现基本需求的核心产品。核心产品交付用户使用后，经过评价形成下一个增量的开发计划，它包括对核心产品的修改和一些新功能的发布。这个过程在每个增量发布后不断重复，直到产生最终的完善产品。
对于该模型，在国内也是经常跟瀑布模型搭配起来使用。

1.2.1.5 螺旋模型（Spiral Model）
1988年，Barry Boehm正式发表了软件系统开发的"螺旋模型"[6]，它将瀑布模型和快速原型模型结合起来，强调了其他模型所忽视的风险分析，特别适合于大型复杂的系统。其过程如图1.5所示：

图1.5 螺旋模型流程图
螺旋模型沿着螺线进行若干次迭代，图中的四个象限代表了以下活动：
（1） 制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件；
（2） 风险分析：分析评估所选方案，考虑如何识别和消除风险；
（3） 实施工程：实施软件开发和验证；
（4） 客户评估：评价开发工作，提出修正建议，制定下一步计划。
螺旋模型由风险驱动，强调可选方案和约束条件从而支持软件的重用，有助于将软件质量作为特殊目标融入产品开发之中。但是，螺旋模型也有一定的限制条件，具体如下：
（1）螺旋模型强调风险分析，但要求许多客户接受和相信这种分析，并做出相关反应是不容易的，因此，这种模型往往适应于内部的大规模软件开发。
（2）如果执行风险分析将大大影响项目的利润，那么进行风险分析毫无意义，因此，螺旋模型只适合于大规模软件项目。
（3）软件开发人员应该擅长寻找可能的风险，准确地分析风险，否则将会带来更大的风险
一个阶段首先是确定该阶段的目标，完成这些目标的选择方案及其约束条件，然后从风险角度分析方案的开发策略，努力排除各种潜在的风险，有时需要通过建造原型来完成。如果某些风险不能排除，该方案立即终止，否则启动下一个开发步骤。最后，评价该阶段的结果，并设计下一个阶段。
螺旋模型一般是做产品的公司会采用的比较多一点，由于中国的中、小型软件公司还是以接项目为主，并且起开发模型更多的是采用瀑布模型、原型模型和增量模型的混合体，所以以下所设计的软件测试过程模型也是针对这种情况。

1.2.2 软件过程管理的现状
既然说到了软件开发的过程模型，就不得不提一下目前软件过程管理的现状，目前主要有两大体系，CMMI和ISO9000。

1.2.2.1 CMMI
CMMI（Capacity Maturity Model Integrated）中文的意思是能力成熟度集成模型。CMMI有两个表示方法（Representation），分别为阶段式（Staged Representation）和连续式（Continuous Representation），涉及面很广，其领域覆盖了软件工程（SW）、系统工程（SE）、集成产品开发（IPPD）和系统采购（SS）等学科。
CMMI是在取得巨大成功的SW-CMM模型的基础上，结合EIA/IS731模型以及IPD-CMM模型而形成的一个全新的集成型模型。CMMI融入了大部分最新的软件项目管理实践，是IT行业最佳实践的集合，同时弥补了SW-CMM模型中的缺陷。CMMI的实施能够提高企业的管理水平，同时降低企业的研发成本。
CMMI Staged Representation中共分为5个等级[7]，每个等级中包括数量不等的PA（Process Area），其不同的等级代表了企业不同的研发、管理成熟度。
Level 1――初始级。在初始级水平上，企业对项目的目标与要做的努力很清晰，项目的目标得以实现。但是由于任务的完成带有很大的偶然性，企业无法保证在实施同类项目的时候仍然能够完成任务。企业在一级上的项目实施对实施人员有很大的依赖性。
Level 2――管理级。在管理级水平上，企业在项目实施上能够遵守既定的计划与流程，有资源准备，权责到人，对相关的项目实施人员有相应的培训，对整个流程有监测与控制，并与上级单位对项目与流程进行审查。企业在二级水平上体现了对项目的一系列的管理程序。这一系列的管理手段排除了企业在一级时完成任务的随机性，保证了企业的所有项目实施都会得到成功。
Level 3――定义级。在定义级水平上，企业不仅能够对项目的实施有一整套的管理措施，并保障项目的完成；而且，企业能够根据自身的特殊情况以及自己的标准流程，将这套管理体系与流程予以制度化。这样，企业不仅能够在同类的项目上生到成功的实施，在不同类的项目上一样能够得到成功的实施。科学的管理成为企业的一种文化，企业的组织财富。
Level 4――量化管理级。在量化管理级水平上，企业的项目管理不仅形成了一种制度，而且要实现数字化的管理。对管理流程要做到量化与数字化。通过量化技术来实现流程的稳定性，实现管理的精度，降低项目实施在质量上的波动。
Level 5――优化级。在优化级水平上，企业的项目管理达到了最高的境界。企业不仅能够通过信息手段与数字化手段来实现对项目的管理，而且能够充分利用信息资料，对企业在项目实施的过程中可能出现的次品予以预防。能够主动地改善流程，运用新技术，实现流程的优化。
按照目前国内中、小型企业的过程管理状况，多停留在Level 3或以下，很少有能达到Level 4——量化管理级的，尽管如此，在测试过程中加入量化控制依然是必要的，这样可以反过来促进开发过程的进步。

1.2.2.2 ISO9000
ISO9000族标准是国际标准化组织在1994年提出的概念，是指由ISO/TC176（国际标准化组织质量管理和质量保证技术委员会）制定的所有国际标准。该标准族可帮助组织实施并有效运行质量管理体系，是质量管理体系通用的要求和指南。它不受具体行业或经济部门的限制，可广泛适用于各种类型和规模的组织，在相互合作与交流等方面促进相互理解和信任。
总体来说ISO9000标准在国内软件行业应用的不如CMMI广泛。

1.2.3 软件测试的现状
软件测试目前在国内受重视的程度越来越高，应该说总体发展方向还是好的，根据《2006年度软件测试行业专项调查报告》[8]中的信息，目前软件测试的重要性已经得到了越来越多的企业的关注。数据显示，有68.2%的受调查企业认为软件测试非常重要，必须要设立专门的测试部门，并将其视为与开发环节同等重要的地位。但是目前国内的测试行业还有很多方面是有待改善的。
大致上来说，目前国内所普遍存在的有两种测试应用模型：
一种是狭义上的: 其主要任务就是发现 BUG。这一过程主要是发生在编码完成之后，正式发布之前，并且测试的随机性太大，发现的缺陷没有进行专门的管理，测试对于软件质量的控制上效果并不明显。国内的中、小型软件公司的测试目前均属于这种。
另一种是广义上的: 测试是全过程的（涵盖项目的整个生命周期）。它本身也是一个过程。但是因为其需要的投入资源比较多，因而目前在国内只有较大型的软件公司和外企在使用。
虽然说目前国内把软件测试作为软件生命周期的一个必不可少的环节，已经达成共识。但中、小型软件企业中，对测试的定位仍然偏低。这种偏低主要体现在:人员配置和待遇上，因而也就决定了目前这类企业无法直接引入国外的先进测试过程，而想要在短期内改变测试的资源状况也是不可能的，因而就非常有必要根据国内企业目前的实际情况设置一套测试的过程。

1.3 课题研究内容及意义
1.3.1 研究内容
该论文的研究内容就是要根据目前国内软件过程开发的现状，并且结合国外的一些先进的软件测试的思想，设计出一套能够被大多数国内中小型软件公司所采用的软件测试过程，以提高这些中小型公司的软件开发质量。
针对国内的中小型软件公司，在测试方面会遭遇到如下几个关键性的问题：
1、测试资源少。相对于国外软件公司动辄1：1甚至1：2的开发测试人员比例，国内企业目前是难以做到的，通常一个100人左右的软件公司，能够做到的极限就是提供1-2个的专职软件测试人员的职位，因此，想要做到为每一个开发团队分配一个测试人员都是很奢侈的想法，像国外目前所采用的测试模型，在国内也是完全不适用的，因此，如何分配好有限的测试资源将是本课题所要解决的主要问题之一。
2、测试人员专业技术水平不高。因为目前国内的软件测试从业人员多是新入门的行业新人或者是开发能力较弱，由开发转到测试的，并且，从国内目前所开展的测试来看，也主要是集中在黑盒的功能测试上，多为手工测试，稍微强一点的也就是使用一些商业的自动化测试工具，来进行一些简单的回归测试，按这样的需求来看，也无法吸引到技术能力强的人来从事测试工作，这也就说明了为什么国内的开发测试人员配比会跟国外有那么大的差距，想要在短时间内去提高软件测试人员的整体技术水平是很难了，所以该课题另一个需要解决的问题就是如何来通过过程的控制尽量减少由于软件测试人员技术能力不强所造成的影响。
3、测试的随意性太大。由于缺少一些量化数据的统计分析，导致了目前的测试具有很大的盲目性，如，测试用例需要写到多详细，测试什么时候能够结束了等。另外就是，缺少对发现的缺陷的跟踪管理，很有可能由于开发人员的疏忽而导致了发现的缺陷没有被修改，或者是对于同一个缺陷，在第二次发现的时候，却忘记了上一次是如何修改好的，这就是缺陷的管理不健全所导致的。因此，本课题的最后一个需要研究的问题就是如何找到量化的数据来对测试进行跟为合理的控制，以及如何对发现的缺陷进行记录管理。

1.3.2 意义
本论文的意义就在于根据国内目前软件开发的实际情况，对软件测试过程进行了合理的改进，使得软件的质量即使在目前测试资源较缺乏，测试技术水平不高的情况下，依然能够得到比较好的保证，并且引入缺陷的跟踪管理机制，使得测试的重用性提高，可以指导以后的开发，从而降低总体的测试成本。
2．过程的总体设计
2.1 过程中各阶段的关键点的描述
在综合的考虑了目前国内软件开发的现状以及模型的可重用和移植性后，决定以瀑布模型为基础来建立测试的模型，因为其他国内所使用的过程模型从根本上来说，也还是能够被分解为瀑布模型，当需要对该测试模型进行移植的时候，只需要将开发模型分解后再代入就可以了。以下就针对瀑布模型的各个关键过程点，来说明一下目前的问题以及需要改进的地方：
1． 需求分析阶段：因为本阶段是软件开发的起始阶段，因此要根据目前的测试资源情况，找到一个合适的切入点，并且这一阶段需要编写系统测试的测试计划跟测试用例，如何进行量化控制也是一个关键点。
2． 设计阶段：该阶段因为会涉及到一些技术实现的细节问题，如果解决好目前软件测试人员技术能力不强的问题是该阶段的关键。
3． 编码集成阶段：该阶段所遇到的主要问题依然集中在测试人员技术能力的不足上面，所以基本上是跟设计阶段一样。
4． 系统测试阶段：这一阶段的重点就是如何对发现的系统缺陷进行记录管理，以及对结果数据的分析上。

2.2 设计原则
由于本文所设计的测试过程是面向目前国内所有中、小型软件公司的，而这些公司所采用的技术工具也各式各样，因此，在设计的过程中，将尽可能的不设计到具体的技术及使用的工具，而仅仅是提供一个可以普遍适用的的过程框架，仅定义出在软件开发各阶段的关键活动，这样各公司可以根据自己的实际情况来选用合适的技术工具，进而增强了本过程的适用性。

2.3 小结
本章是对设计的软件测试过程的总体概述，简略说明了整个测试过程中各个过程关键点的重、难点，为后面几章中的过程设计指明了方向。最后，明确了该过程的使用对象，既国内的中、小型软件企业，由此提出了过程的设计原则。
3．需求分析阶段
3.1 需求阶段过程总揽
该阶段的流程如图3.1：
图3.1 需求阶段测试流程图
流程描述如下：
首先，是由开发人员进行需求调研，并编写需求调研报告，然后根据对需求调研报告的分析，形成第一版的需求规格说明书（SRS）。
之后，就是由开发人员跟测试人员共同参加的需求评审会，这也是测试人员第一次参与到项目中，作为测试人员，审核重点是检查文本对用户需求定义的完整性、严密性和功能设计的可测性。同时这种审核对于测试人员也是一种热身活动，使他们尽早地进入技术和业务状态。
在需求评审通过了之后，要对正式的需求规格说明书进行基线，然后是测试人员根据基线后的需求规格说明书编写功能点测试说明书，制定测试计划，设计系统测试用例。在这三个文档都出来之后，需求阶段测试人员的工作就完成了。

3.2 测试人员介入项目的时间点
在这里，我们把测试人员介入项目的时间点定义在需求调研完成，第一版的需求规格说明书出来，进行评审的时候，根据对软件缺陷修复成本的分析[9]，我们可以发现，缺陷被发现的越早，其修复的成本也将会越低，根据这一结论，我们可以很容易的推断出，如果测试人员在需求调研的时候就介入到项目中将会是最理想的情况，因为需求调研是整个项目的开始阶段，如果再这一阶段的时候就能很好的控制缺陷，将大大降低项目开发后期的成本，但是很遗憾，由于需求调研是一个长期的过程，需要大量的人力投入，而公司的测试资源是有限，按照现有的情况，经常是会有5-6个项目在同时开展，而实际能提供的测试资源却只有两到三个人，要把测试人员在进行需求调研的时候就投入到项目当中显然是不可能的，因此，测试人员介入的时间必须后推，于是，在需求评审会上介入就成为了最佳的选择。要评审的需求可以在评审会前的2-3天由项目组提交给测试人员，然后由测试人员抽时间进行预审，把其中发现的问题记录下来，留待正式的评审会上解决，这样在整个需求开发阶段，需要测试人员投入的工作量就大大降低了，并且只有需求评审会的时间是固定的，像之前的需求预审及之后的测试用例设计等，都可以根据其他项目的进展及优先级情况来灵活的对测试资源进行调度，极大的缓解了测试资源不足的问题，并且也把查找缺陷的最初阶段定义到了需求开发阶段，在成本和资源之间取得了一个很好的平衡。
3.3 测试文档的开发
3.3.1 功能点测试说明书
一旦需求规格说明书基线了之后，就可以开始考虑测试需求的整理——也就是明确地定义现阶段要“测什么”。测试需求的确定将为我们制定进度时间表分配资源以及如何确定某个阶段测试工是否完成提供一个可供衡量的标准。当然还有更重要的一点：已被确定的测试需求是我们进行测试用例设计和考虑测试覆的依据。整理测试需求的第一步，就是要“测试需求”。这里的“测试需求”中的“测试”是一个动词，指的是对软件需求本身的检查。这是测试工作的开始。软件分析设计阶段测试人员除制定测试计划书等本职作外，还有一个必不可少的任务，那就是将系统的可测性落实到书面文档，以备将来编写测试用例。之所以要这么做，是因为加强测试用例在测试过程中的地位、强化测试用例管理过程，如果编写测试用例直接参考需求规格说明书或者分析流程图这样跨度大，难度也大，是造成测试用例不完备、覆盖范围小的重要原因。
因此首先需要编写的文档就是功能点测试说明书，它是软件的详细测试分析文档，其主旨是将系统分析人员的分析文档加工成站在测试角度的功能点分析文档，重要的是描述对系统分解后每个功能点逐一的效验描述，包括何种方法测试，何种数据测试，测试结果期望值等，这些信息都是描述性的，无需具体数据，只要用容易理解的自然语言就可以了，明确地描述一项需要测试的内容，对于多项测试内容，应尽可能地剥离开来，它的作用是据此编写测试用例，以及测试执行时的参考依据，它直接来源于需求，覆盖最全，也最贴近客户。

3.3.2 测试计划制定
接着需要制定测试计划，一个测试计划应包括：产品基本情况调研、测试需求说明、测试策略和记录、测试资源配置、计划表、问题跟踪报告等等。其中包括的具体内容如下，1、产品基本情况调研：这部分应包括产品的一些基本情况介绍，例如：产品的运行平台和应用的领域，产品的特点和主要的功能模块，产品的特点等。对于大的测试项目，还要包括测试的目的和侧重点。2、测试需求说明：这一部分要列出所有要测试的功能项。凡是没有出现在这个清单里的功能项都排除在测试的范围之外。万一有一天你在一个没有测试的部分里发现了一个问题，你应该很高兴你有这个记录在案的文档，可以证明你测了什么没测什么。3、测试的策略和记录：这是整个测试计划的重点所在，要描述如何公正客观地开展测试，要考虑：模块、功能、整体、系统、版本、压力、性能、配置和安装等各个因素的影响。要尽可能的考虑到细节，越详细越好。4、测试资源配置：制定一个项目资源计划，包含的是每一个阶段的任务、所需要的资源，当发生类似到了使用期限或者资源共享的事情的时候，要更新这个计划。5、计划表：测试的计划表可以做成一个多个项目通用的形式，根据大致的时间估计来制作，操作流程要以软件测试的常规周期作为参考，也可以是根据什么时候应该测试哪一个模块来制定。6、问题跟踪报告：在测试的计划阶段，我们应该明确如何准备去做一个问题报告以及如何去界定一个问题的性质，问题报告要包括问题的发现者和修改者、问题发生的频率、用了什么样的测试案例测出该问题的，以及明确问题产生时的测试环境。

3.3.3 测试用例的设计
在测试计划制定好以后就要开始测试用例的设计了，首先，从覆盖率来说，测试的用例要达到最大覆盖软件系统的功能点。编写测试用例时，基本就是将《功能点测试说明书》中的每个功能点进行操作上的细化：一是从步骤上描述到达校验点的方式，二是从内容上以何种数据校验功能点。其次，从数量来讲，测试用例不能太少，必须至少能覆盖系统需求，以免测试人员不能在测试开展的整个时期按照用例执行。应该说测试用例的数量很难用数学模型来模拟，更没办法用具体的数字去衡量，只能掌握一个原则：系统需求必须要覆盖。
最后，说一下测试用例格式上除一般说明外的几个要点：一是要制定适合本公司的测试用例模版，统一风格和延续传统；二是测试用例的修改及运行都有日志记录。
以下是一个测试用例模版的例子，可以作为参考。这里的测试用例是以EXCEL文件的形式存在，当然也可以使用其他的文档形式，如表3.1和表3.2：

表3.1 测试用例的更改记录

其中表3.1记录的是测试用例的历史记录，主要是记录该测试用例的版本信息，以下对各信息项做具体的说明：
对于“版本”一列是用来记录该测试用例的版本信息，一般从 0.9开始，代表未经过评审的非正式版本，以后的版本号依次增加，如，1.0，1,1等。
“提案人”一列需要记录的是用例的编写者，对应的后面的“批准人”一列需要填写的是用例的评审者。而“日期”一列记录的是用例的编写日期。
“描述”一列需要记录的是该测试用例所对应的需求的版本，这样做的目的是方便需求变更之后对测试用例的管理，当测试用例进行变更的时候还要在此处写明变更的记录。
对于最后一列的用例个数则是记录该表格中编写的测试用例个数，其中表格的一行就算做一个测试用例，以方便测试后一些量化数据的取得。

表3.2 功能测试用例的记录形式

对于表3.2就是测试用例记录的主体部分了。以下对其中的信息项目进行说明：
“测试项目就是”对应的项目名称。
“测试模块”就是该表格里测试用例所对应的系统的模块名。
“功能点编号”是该SHEET中对应功能点的编号，可以在需求中找到。
“用例编号”用来标识该SHEET，一般就是用功能点编号在最后加上一个流水号就可以了，如001，002等。
“软件要求”是用来记录该系统的服务端，客户端运行时的软件要求，作用就是指导测试环境的搭建
“硬件要求”用来