软件测试流程及规范V1.1

二、各阶段具体流程1.需求分析阶段1.1步骤说明1、需求定义基本完成，SRS编写完成。

2、开评审会，由需求调研人员、开发组、设计组、测试组等人员对需求中不清楚、不完整、存在疑义的地方提出问题，相关人员解答并确认。

3、当评审未通过，直接打回，重新修改SRS，问题解决后，重新提交评审。

4、当评审通过后，依据SRS，项目整体计划，设计、编写《测试计划》和《测试设计》，具体模板见附件。

5、开评审会，由开发组、设计组、测试组等人员对计划和设计中不清楚、不完整、存在疑义的地方提出问题。

6、当审批未通过，直接打回，优化测试计划、测试设计，问题解决后，重新提交评审。

7、审核通过后，进入下一阶段。

1.2测试通过打回标准1.3、阶段的输出输入：最新SRS、项目计划输出：测试计划、测试设计2、单元及集成测试流程2.1步骤说明：1、理解需求和设计理解设计是很重要的，特别是要搞清楚被测试模块在整个软件中所处的位置，这对测试的内容将会有很大的影响。

需要记住的一个原则就是：好的设计，各模块只负责完成自己的事情，层次与分工是很明确的。

在单元测试的时候，可以不用测试不属于被测试模块所负责的功能，以减少测试用例的冗余，集成测试的时候会有机会测试到的。

所以，单元测试主要是关注本单元的内部逻辑，而不用关注整个业务的逻辑，因为会有别的模块去完成相关的功能。

2、概览源代码浏览一下源代码，主要任务：1）初步检查源代码的编码风格与规范。

2）大致估算测试工作量，比如：需要多少的测试用例、需要写多少的驱动模块和装模块等。

3）确定模块的复杂程度，初步制定测试的优先级等。

3、精读源代码认真阅读和分析代码，主要任务：1）理解代码的业务逻辑。

2）检查代码与设计是否相符，如果详细设计没有该模块的流程图的话，先去画出流程图。

3）仔细研究逻辑复杂的模块。

4）可以采用一些检查列表来检查程序可能会出现的问题。

4、设计测试用例综合运用白盒测试方法（和结合黑盒测试方法）来设计测试用例，包括功能测试、性能测试等，要达到一定的测试覆盖率。

在设计测试用例的过程中，流程图或控制流图是分析的好帮手。

5、搭建单元测试环境使用工具或自己写的框架将有助于单元测试的实施。

在这个阶段主要就是写桩模块和驱动模块，第4步所设计的测试用例是通过驱动模块传递给被测试模块的，然后驱动模块想办法获取被测试模块对数据的处理结果，并判定返回的实际结果与测试用例的预期结果是否一致，通过测试框架来记录执行的结果，对于出现的错误，还需要统计错误的信息，供执行完之后分析。

6、执行测试运行写好的驱动模块完成对被测试模块的测试。

7、补充和完善测试用例单元测试也是个循序渐进的过程，可能一开始考虑的不够全面，或预期的覆盖标准太低，需要在测试过程中不断补充测试用例，直到满足要求为止。

8、分析结果，给出评价根据测试的结果分析、查找错误的原因，并找到解决的办法。

测试结束之后，根据测试过程的数据统计，给出被测试对象评价2.2测试通过打回标准1、通过标准2、打回标准2.3、阶段的输出输入：最新SRS、项目计划、详细设计输出：单元测试计划、单元测试用例、单元测试总结分析。

3、系统测试流程系统测试是将已经确认的软件、计算机硬件、外设、网络等其他元素结合在一起，进行信息系统的各种组装测试和确认测试，系统测试是针对整个产品系统进行的测试，目的是验证系统是否满足了需求规格的定义，找出与需求规格不符或与之矛盾的地方，从而提出更加完善的方案。

系统测试发现问题之后要经过调试找出错误原因和位置，然后进行改正。

是基于系统整体需求说明书的黑盒类测试，应覆盖系统所有联合的部件。

对象不仅仅包括需测试的软件，还要包含软件所依赖的硬件、外设甚至包括某些数据、某些支持软件及其接口等。

3.1步骤说明1、测试组收到测试任务通知书，告知较为确切的测试内容、日期。

2、根据最新SRS和各设计文档，将已经确认的软件、计算机硬件、外设、网络等其他元素结合在一起，针对整个产品系统进行的测试。

3、编写此阶段系统测试方案，通过评审，优化系统测试方案。

4、然后编写或补充系统测试用例，用例完成后，需要通过评审，优化系统测试用例。

5、执行冒烟测试用例，测试版本仅少量严重程度低的bug未修改引起的不通过，反馈项目组，通知延长冒烟测试时间；测试版本符合冒烟测试打回标准，冒烟测试不通过，直接打回或挂起，结束测试。

测试完成度满足冒烟测试开始条件，重新发起测试申请。

6、当不通过时，退回或挂起。

7、当完成冒烟测试后，进行系统测试，提交bug报告，审核bug，当审核未通过时，补充测试用例，当审核通过汇总bug，总结报告。

8、当开发人员完成缺陷的修改后，提交新的版本，测试人员继续开始做回归测试。

当测试版本仅少量bug未修改引起的不通过，反馈项目组，通知延长系统测试时间；测试版本符合系统测试打回标准，系统测试不通过，直接打回，结束测试。

待测试完成度满足系统测试开始条件，重新发起测试申请。

9、当缺陷的统计曲线出现的逐渐收敛，并且得到控制。

10、分析缺陷的原因。

11、提交测试报告。

12、进入下一阶段。

3.2测试通过打回标准1）通过标准2）打回标准3.3、阶段的输出输入：最新SRS、项目计划、详细设计输出：系统测试计划、系统测试用例、测试总结分析。

4、验收测试软件产品测试组对经过内部单元测试、集成测试和系统测试后的软件所进行的测试，测试用例采用业务流程测试用例。

4.1步骤说明1、验收测试进入准则1）软件产品通过单元测试、集成测试和系统测试。

2）项目组提交以下测试文档：测试计划、测试用例、测试日志、测试通知单、测试分析报告。

3）待验收的软件安装程序。

2、测试错误类型参考软件测试停止标准.doc3、对用户手册和帮助的验收规定1）用户手册和帮助的编制要使用非专门术语的语言，充分地描述该软件系统所具有的功能及基本的使用方法。

2）使用户（或潜在用户）通过用户手册能够了解该软件的用途，并且能够确定在什么情况下，如何使用它。

3）语句通顺、简洁，语义明确，错别字小于0.1%。

4）对相关名词解释应易于被用户理解。

5）对相关界面的说明要符合操作流程并将每一项功能解释完整、清楚。

6）保证用户手册、帮助能够正确指导用户使用软件。

4、软件验收测试合格通过准则1）软件需求分析说明书中定义的所有功能已全部实现，性能指标全部达到要求。

2）所有测试项必须符合以下标准：(以下比例为错误占总测试模块的比例)3）需求分析文档、设计文档和编码实现一致。

4）用户手册及帮助符合对用户手册及帮助的验收规定(编写人在责任认定书上签字时对于软件产品的各项功能描述、名词解释、结构、语句表达等方面均要保证其正确性并加以说明)。

5）验收测试文档齐全（见验收测试进入准则）。

6）以上五条其中之一不满足要求，视为不合格。

三、缺陷管理3.1缺陷定义软件缺陷（Defect），常常又被叫做Bug。

所谓软件缺陷，即为计算机软件或程序中存在的某种破坏正常运行能力的问题、错误，或者隐藏的功能缺陷。

具体归纳为以下这些问题。

1、软件没有达到需求规格说明书中表明的功能；2、软件出现了需求规格说明书中不一致的表现；3、软件功能超出需求规格说明书的范围；4、软件没有达到用户期望的目标(虽然需求规格说明书中没有要求)；5、测试员或用户认为软件的易用性差。

3.2缺陷的修复在实际项目中不是所有的缺陷都会修改，具体见以下情况：1、市场的压力使得产品最终发行有时间限制；2、测试员错误理解或者不正确操作引出的缺陷；3、错误的修改影响的模块较多，带来的风险较大；4、缺陷报告中提出的问题很难重现；5、修改性价比太低。

3.3缺陷的分类标准一旦发现软件缺陷，就要设法找到引起这个缺陷的原因，分析对产品质量的影响，然后确定软件缺陷的严重性和处理这个缺陷的优先级。

各种缺陷所造成的后果是不一样的，有的仅仅是不方便，有的可能是灾难性的。

一般问题越严重，其处理优先级就越高，可以概括为以下五种级别：3.3缺陷的流程目前分公司的缺陷管理使用的是Quality Center9.0，具体安装和使用细节，见使用手册。

在使用时遵循以下的流程，即缺陷的生命周期。

流程中缺陷存在以下6种状态：提交bug状态（New）：开发人员或测试人员发现bug，记录在系统里。

激活状态（Open）：当项目经理或负责人觉得这个bug是问题，将bug置为此状态。

驳回状态（Rejected）:当项目经理或负责人觉得这个bug不是问题，则可以驳回，将bug置为此状态。

已修正状态（Fixed）：开发人员针对缺陷，修正软件后已解决问题或通过单元测试。

关闭状态（Close）：测试人员经过验证后，确认缺陷不存在之后的状态。

重新激活状态（Reopen）：测试人员经过验证后，确认此缺陷存在，之后将其置为此状态。

四、关于单元测试1、首先应该明确单元的含义。

单元在面向对象的程序中指的是一个类，在结构化的方法中指的是一个函数。

2、其次应该明确单元测试的方法。

单元测试的常用方法包括：(1) 静态检查，即采用静态代码检查的工具对程序进行内部逻辑的分析，以分析程序中可能的错误。

(2) 动态测试，通过编写单元测试程序，设计单元测试用例，测试每个函数或每个类的逻辑正确性。

3、如果一个类或一个函数对其他的类或环境依赖性很强，需要编写大量的桩程序或驱动程序，那恰恰说明了这个类或这个函数的设计有问题，违背了“低耦合”的基本设计原则，这也正式敏捷方法中提倡的“测试驱动开发”的作用之一。

4、质量的投入产出也是一种平衡，需要在单元测试上投入到什么程度首先是公司的一个管理方针。

如果每个单元都进行单元测试则测试代码的规模和产品代码的规模能够达到1：1，也就是说编写测试代码的工作量还是比较大的，但是也要看到单元测试的产出。

在单元测试、集成测试、系统测试中，单元测试是投入产出比最大的测试种类，即单元测试在单位时间内发现的缺陷个数大于集成与系统测试。

原则上单元测试的投入最大，找到的缺陷最多，集成测试与系统测试依次递减。

5、在实践中推广单元测试时可以采用如下的方法：1)、加大静态检查的力度。

通过静态检查的工具快速地识别程序中的错误、警告，公司可以规定对检查出的哪些警告、错误必须进行修改，注意如果修改所有的警告、错误可能工作量比较大。

静态检查是一种投入产出比很高的单元测试方法。

在JAVA下可以采用check Style, Source monitor，PMD，Find Bugs，Jslink等。

2)、通过测试策略的选择减少测试程序的工作量。

单元测试一般有三种策略：策略一：自底向上的策略：先测底层的函数或类，再测上层的函数或类，此时只需要编写驱动程序，不需要编写桩程序。

策略二：自顶向下的策略：先测上层的函数或类，再测试底层的函数类，此时只需要编写桩程序，不需要或很少需要编写驱动程序。