软件工程CMMI测试管理指南Word格式文档下载.docx

软件工程CMMI测试管理指南Word格式文档下载.docx

《软件工程CMMI测试管理指南Word格式文档下载.docx》由会员分享，可在线阅读，更多相关《软件工程CMMI测试管理指南Word格式文档下载.docx（24页珍藏版）》请在冰豆网上搜索。

变化状态

简要说明（变更内容和变更范围）

日期

变更人

批准人

V0.1

C

创建文档

*变化状态：

C——创建，A——增加，M——修改，D——删除，AU——审核

1目的

为软件测试工作提供指导。

2范围

适用于软件单元测试、集成测试、确认测试和系统测试。

3术语定义

缺陷（Bug）：

缺陷是对软件产品预期属性的偏离现象。

覆盖率（Coveragerate）：

语句覆盖率、测试用例执行覆盖率，测试需求覆盖率等的总称。

4软件测试基础

4.1测试的定义

软件测试是为了发现错误而执行程序的过程。

或者说，软件测试是根据软件开发各阶段的规格说明和程序的内部结构而设计一批测试用例（即输入数据及其预期的输出结果），并利用这些测试用例去运行程序，以发现程序错误的过程。

4.2测试的原则

a）尽早地和不断地进行软件测试；

b）测试用例应由测试输入数据和与之对应的预期输出结果这两部分组成；

c）程序员应避免检查自己的程序；

d）在设计测试用例时，应当包括合理的输入条件和不合理的输入条件；

e）充分注意测试中的群集现象；

f）严格执行测试计划，排除测试的随意性；

g）应当对每一个测试结果做全面检查；

h）妥善保存测试计划，测试用例，Bug统计和最终分析报告，为维护提供方便。

4.3测试信息流

测试过程需要三类输入：

软件配置：

包括软件需求规格说明、软件设计规格说明、源代码等；

测试配置：

包括测试计划、测试用例、测试驱动程序等；

测试工具：

测试工具为测试的实施提供某种服务。

测试之后，用实测结果与预期结果进行比较。

如果发现出错的数据，就要进行调试。

对已经发现的错误进行错误定位和确定出错性质，并改正这些错误，同时修改相关的文档。

修正后的文档一般都要经过再次测试，直到通过测试为止。

如果测试发现不了错误，那么可以肯定，测试配置考虑得不够细致充分，错误仍然潜伏在软件中。

这些错误最终不得不由用户在使用中发现，并在维护时由开发者去改正。

4.4测试与软件生命周期各阶段的关系

软件开发过程是一个自顶向下，逐步细化的过程，而测试过程则是依相反的顺序安排的自底向上，逐步集成的过程。

低一级测试为上一级测试准备条件。

参看图4.1，首先对每一个程序模块进行单元测试，消除程序模块内部在逻辑上和功能上的错误和缺陷；

再对照软件设计进行集成测试，检测和排除子系统（或系统）结构上的错误；

随后再对照需求，进行确认测试。

最后从系统全体出发，运行系统，看是否满足要求。

图4.1

4.5测试的过程与策略

软件测试的主要工作是在项目或产品系统集成时进行测试，但是软件测试人员需要在项目及产品的需求调研阶段就应该进入，进入的目的主要是熟悉项目及产品的相关需求，流程，功能特点以及项目的整体进度，为后续的系统测试阶段做准备工作。

主要工作内容是参加需求和开发人员的评审工作，有效的与需求和开发人员进行沟通，来获取测试所需要的各种文档和项目及产品知识。

倘若测试人员没有参与需求调研，那么必须仔细阅读系统需求相关文档，弄懂业务（或通过需求工程师的讲解，培训来获取）。

时间允许最好能做统一的系统业务培训。

在这里我们将软件测试分为五大阶段：

其中包括：

单元测试、代码评审、代码集成测试、数据库完整性测试、系统集成测试。

（一）单元测试

单元测试是使用Junit测试框架，每次重构系统之后，必须保证所有单元测试通过，以避免因为重构导致的缺陷。

单元测试对于功能性方法应达到100%的测试覆盖率。

Ø

定义

单元通俗的说就是指一个实现简单功能的函数。

单元测试就是只用一组特定的输入（测试用例）测试函数是否功能正常，并且返回了正确的输出。

测试准入条件

✧《UML设计图》，其中包括：

用例图、类图、时序图。

✧《单元测试范围》，其中包括：

类、接口、方法、变量、输入参数、输出参数。

测试环境：

✧单元测试的环境与开发环境一致。

如图所示：

代码开发是用MYEclipse（8.0.0）

✧MYEclipse（8.0.0）打开步骤（详细请参见：

系统单元测试操作手册）：

测试的职责划分

单元测试由开发组完成。

质量控制

测试用例评审（类、方法的覆盖率）

测试方案

✧测试依据：

测试的覆盖种类：

✓语句覆盖：

语句覆盖就是设计若干个测试用例，运行被测试程序，使得每一条可执行语句至少执行一次。

✓判定覆盖（也叫分支覆盖）：

设计若干个测试用例，运行所测程序，使程序中每个判断的取真分支和取假分支至少执行一次。

✓条件覆盖：

设计足够的测试用例，运行所测程序，使程序中每个判断的每个条件的每个可能取值至少执行一次。

✓判定——条件覆盖：

设计足够的测试用例，运行所测程序，使程序中每个判断的每个条件的每个可能取值至少执行一次，并且每个可能的判断结果也至少执行一次。

✓条件组合测试：

设计足够的测试用例，运行所测程序，使程序中每个判断的所有条件取值组合至少执行一次。

✓路径测试：

设计足够的测试用例，运行所测程序，要覆盖程序中所有可能的路径。

单元测试方案主要有条件测试，基本路径测试，循环测试。

通过上面的方法可以实现测试用例对程序的逻辑覆盖，和路径覆盖。

✧测试手段：

使用Junit单元测试工具。

✧测试内容及步骤：

在组件设计结束后，由设计人员定义单元测试的范围及具体内容。

统一测试框架（见环境搭建）。

建立测试程序，其中包括三个部分：

数据准备区、测试准备区、测试区。

其中数据准备区中确定被测函数的输入数据、成员变量、局部变量。

测试准备区明确桩程序、预期值等。

测试区中则调用被测函数。

执行单元测试，并修改测试中发现的问题，定期生成单元测试报告。

测试完成标准

✧按照单元测试用例完成了单元测试；

✧源代码符合编程规范；

✧单元测试、代码评审应覆盖所有代码（可不包括复用的代码）。

✧缺陷清除率达到100%。

测试的提交物

✧单元测试用例评审报告

✧单元测试范围定义

✧单元测试代码

（二）代码评审

代码评审通过走查、审查的方式，对产品组件的最小单位模块进行检查，发现各类缺陷。

《功能权限编码规范》

《命名规范》，其中包括：

应用程序命名规范、变量命名规范、应用程序注释规范。

✧代码评审的环境与开发环境一致。

代码审查由开发组完成。

代码评审（程序覆盖率）

程序算法、编程思路是否清晰、无代码冗余，真正符合编码规范。

包名、类名、变量名、程序注释是否符合命名规范。

代码走查、代码审查。

严格按照：

✓《编码规范》，其中包括，程序算法、编程思路、代码冗余。

✓《命名规范》，其中包括：

应用程序命名规范、变量命名规范、应用程序注释规范，进行代码走查、代码审查。

在组件设计结束后，由设计人员定义代码评审的范围及具体内容。

执行代码评审，并修改评审中发现的问题，定期生成代码评审报告。

按照代码评审范围完成代码评审；

源代码符合编程规范；

各基类和存储过程的正常值测试全部通过；

各基类和存储过程的异常值测试通过率达85%以上；

缺陷清除率达到100%。

代码评审范围定义

代码评审报告

代码检视表（开发人员交叉测试产生）

（三）组件集成测试

集成测试必备文档

《接口详细描述文档》

集成测试定义

代码集成测试集中在检查软件设计的几个单位模块上的组合，通过测试发现模块间的接口、业务功能与定义的功能、接口说明是否符合、以及其他的编码错误。

开发组完成部分（或全部）编码与单元测试，形成了较稳定的可测试软件版本；

集成测试由开发人员完成；

集成测试代码和单元测试代码一样放在目标测试项目下的测试工程文件夹下；

根据需要还要添加集成测试所需要的jar包；

测试接口方法：

✓获得接口指针，逐个调用接口函数验证其正确性；

✓如果接口函数没有参数，测试返回值，纯虚函数要在继承的类中重载，不然不能生成类的实例，没有办法生成实例，不存在动态测试的问题， 

只能检查代码做静态测试；