软件系统测试方案

软件/信息系统测试方案

目录

1 引言 (5)

1.1. 编写目的 (5)

1.1. 适用范围 (5)

1.2. 参考资料 (5)

2 参加与测试相关的评审 (6)

2.1.参加评审的目的 (6)

2.2.岗位与职责 (6)

2.2.1项目经理 (6)

2.2.2事业部测试组长 (6)

2.2.3项目管理部测试组组长 (7)

2.2.4入口、出口条件 (7)

2.2.5可测试的特征 (7)

3 制定测试计划 (8)

3.1制定测试计划的目的 (8)

3.2岗位与职责 (8)

3.2.1项目经理 (8)

3..2.2事业部测试组长 (8)

3.2.3项目管理部测试组组长 (8)

3.3入口、出口条件 (8)

3.4编写测试计划 (9)

3.5编写测试用例 (9)

3.6编写测试用例的目的 (9)

3.7岗位与职责 (9)

3.7.1开发组 (9)

3.7.2事业部测试组 (9)

3.7.3项目管理部测试组 (9)

3.7.4入口与出口条件 (9)

3.8如何编写测试用例 (10)

3.8.1测试用例覆盖准则 (10)

3.8.3白盒测试案例的设计 (11)

3.8.4语句覆盖 (11)

3.8.5分支覆盖 (11)

3.8.6逻辑覆盖： (11)

3.8.7条件覆盖 (11)

3.8.8条件/分支覆盖 (11)

3.9获取测试用例的方式 (12)

3.9.1.1等价类划分 (12)

3.9.1.2边界值分析 (13)

3.9.1.3错误推测 (13)

3.9.1.4因果图法 (13)

3.10评审测试案例 (14)

3.11参考内容 (14)

4、单元测试 (14)

4.1单元测试目的 (14)

4.2岗位与职责 (14)

4.2.1项目经理 (14)

4.2.2单元测试负责人 (14)

4.2.3单元测试人员 (14)

4.2.4开发小组 (14)

4.2.5入口、出口条件 (15)

5.3单元测试方法 (15)

5.4单元测试检查单 (15)

5.5单元测试的流程 (15)

6参考内容 (16)

7组装测试 (16)

7.1组装测试目的 (16)

7.2岗位与职责 (17)

7.2.1项目经理 (17)

7.2.3组装测试人员 (17)

7.2.4开发小组 (17)

7.2.5入口与出口条件 (17)

7.2.6组装测试方法 (18)

7.2.6.1一次性组装; (18)

7.2.6.2增量式组装 (18)

7.2.6.3自顶向下 (18)

7.2.6.4自底向上; (19)

7.2.6.5组装测试流程： (19)

8验收测试 (19)

8.1验收测试的目的 (19)

8.2岗位与职责 (20)

8.2.1项目经理 (20)

8.2.2验收测试负责人 (20)

8.2.4验收测试人员 (20)

8.2.5开发小组 (20)

8.2.6入口与出口条件 (20)

8.2.7验收测试步骤 (20)

9参考资料 (22)

1引言

1.1.编写目的

软件测试是软件生命周期的重要环节，也是软件质量保证的主要活动。测试方案是规范测试流程、指导测试活动的标准。

主要针对测试管理人员、测试设计和执行人员及质量保证人员在测试活动时参照执行。

1.1.适用范围

本规程用于朝阳区网格化信息管理系统的所有测试活动。

1.2.参考资料

《软件项目计划规程》

《评审规程》

软件测试的定义

1.2.1什么是软件测试

测试：是通过分析和执行程序发现软件不满足质量要求的缺陷的过程。软件测试是根据软件开发各阶段的规格说明和程序的内部结构而精心设计的一批测试用例，并利用这些测试用例去运行程序，以发现程序错误的过程。

1.2.2软件测试的目的

(1)目的在于发现错误；

(2)一个好的测试用例在于能发现至今未发现的错误；

(3)一个成功的测试用例是发现了至今未发现的错误。

1.2.3软件测试的原则

(1)应当尽早地和不断地进行软件测试。

(2)测试用例应当由测试输入数据和与之对应的预期输出结果这两部分组成。

(3)程序员应避免检查自己的程序。

(4)在设计测试用例时，应当包括合理的输入条件和不合理的输入条件。

(5)充分注意测试中的群集现象。

(6)严格执行测试计划，排除测试的随意性。

(7)应当对每一个测试结果做全面检查。

(8)妥善保存测试计划，测试用例，出错统计和最终分析报告，为维护提供方便。

1.2.4测试与软件开发各阶段的关。

2参加与测试相关的评审

2.1.参加评审的目的

1、有利于采用最优的方案和技术。

2、避免错误的发生。

2.2.岗位与职责

2.2.1项目经理

指定单元测试的负责人参加《详细设计说明书》的评审；

2.2.2事业部测试组长

指定集成测试的负责人参加《概要设计说明书》的评审；

2.2.3项目管理部测试组组长

指定系统测试的负责人参加《需求规格说明书》的评审；

2.2.4入口、出口条件

2.2.5可测试的特征

1)是否规定了测试标准？根据该标准，能否充分地保证质量？这些标准能

否规定具体的测试内容。

2)是否明确设计规格和测试规格之间的对应关系

3)功能的完整性

4)性能;

5)可用性;

6)可靠性, 有效性, 有用性(适用性);

7)兼容性 (如, 代码可容易的从一个平台到另一平台的移植);

8)可维护性 (如, 可修复和容易地作较小修改);

９）可扩充性 (如, 可做出较大地增量补充且不引起主要地重写)；

3 制定测试计划

3.1制定测试计划的目的

制订一个合理计划，作为管理和执行软件项目测试的活动的基础。

3.2岗位与职责

3.2.1项目经理

制定《单元测试计划》。

评价测试方法和工具。

关注各级测试的入口出口准则。

3..2.2事业部测试组长

制定《组装测试计划》。

3.2.3项目管理部测试组组长

制定《验收测试计划》。

3.3入口、出口条件

详细设计

《详细设计说明书》

经过评审并得到批

准；

制定《单元测试计划》 《单元测试计

划》经过评审并

得到批准；

3.4编写测试计划

1) 测试计划应依据项目经理在《项目总体计划》和《项目开发计划》中对测试

活动给出的时间计划。

2) 规定测试活动的任务、测试方法、进度、资源、人员职责等 3) 编写测试计划应遵循《测试计划模版》 4) 评审测试计划，参考《评审规程》

3.5编写测试用例

3.6编写测试用例的目的

导出有可能发现软件错误的测试集。

3.7岗位与职责

3.7.1开发组

由执行单元测试的人员负责编写《单元测试案例》。

3.7.2事业部测试组

由执行组装测试的人员负责编写《组装测试案例》，与接口有关的案例由设计人员编写。

3.7.3项目管理部测试组

由执行验收测试的人员负责编写《验收测试案例》，与结构有关的案例由系统分

析人员编写。 3.7.4入口与出口条件

3.8如何编写测试用例

3.8.1测试用例覆盖准则

3.8.2测试用例的选择

测试用例的选择应该满足:

1)发现错误可能性大的输入数据或操作；

2)被测程序的执行结果应该是可判定的；

3)测试的执行过程和结果是可以再现的。

3.8.3白盒测试案例的设计

3.8.4语句覆盖

按照设计的测试用例，执行测试，保证每一可执行语句至少执行一次。

3.8.5分支覆盖

按照设计的测试用例，执行测试，使得程序中每个判断的取真分支和取假分支

至少经历一次。

3.8.6逻辑覆盖：

3.8.7条件覆盖

在测试时，设计若干测试用例，运行被测程序，使程序中的每个条件的可能取值至少满足一次。

3.8.8条件/分支覆盖

在测试时，设计足够的测试用例，使得判断中每个条件的所有可能取值至少出现一次，并且每个判断本身的判定结果也至少出现一次。

如下图所示：所有四条路径可以表示为:L1(ace)、L2（abd）、L3（abe）、L4（acd）。

a

3.9获取测试用例的方式

1)通过非路径分析得到的测试用例；

2)找到尚未测试过的路径并生成相应的测试用例；

3)指定特定路径生成相应的测试用例；

3.9.1黑盒测试案例的设计；

3.9.1.1等价类划分

等价类划分法完全不考虑程序的内部结构，只依据程序的规格说明来设计测试用例，即在输入数据时按合理和不合理划分成若干个等价类，相同的一类

数据中选择一个作为测试用例。

第一步：从开发部门提交的需求说明书中找出每一个输入条件（通常是一句话或一个短语），然后为每一个输入条件划分出多个等价类，这是测

试工作的重要基础。

第二步：确定测试用例，将等价类编号，必须覆盖所有等价类，不能出现相同测试用例。

经验参考：

1）如果输入条件规定了取值范围或值的个数，则可以确立一个有效等价类（即

该输入条件的取值范围或值的个数）和两个无效等价类（即大于和小于该范围

或该个数的那些取值）。

2）如果输入条件规定了输入值的集合，或者规定了“必须如何”的条件，这

时可确立一个有效等价类。

3）如果输入条件是一个布尔量，则可以确定一个有效等价类和一个无效等价

类。

4）如果规定了输入数据的一组值，而且程序要对每个输入值分别处理，这时

可为每个输入值确立一个有效等价类，此外针对所有不允许的输入的集合确立

一个无效等价类。

5）如果规定了输入数据必须遵守的规定，则可以确立一个有效等价类（符合

规则的等价类）和若干无效等价类（从不同角度违反了规则的那些等价类）。

如果确知已划分的等价类中各个元素在程序中的处理方式不同，则应将此等价

类进一步划分成更小的等价类。

3.9.1.2边界值分析

实践表明往往在处理边界情况时容易发生错误。在等价类之间或其他边缘处设计测试用例并将其编号制表。这是经常使用的高效做法。

1)如果输入条件规定了值的范围，则应选取刚刚达到这个范围的边界值以及刚刚

超越这个范围的边界值作为测试输入数据。例如，输入值的范围是 -1.0～1.0，

则可选取-1.0、1.0、-1.001和1.001作为输入数据。

2)如果输入条件规定了值的个数，则用最大个数，最小个数，比最大个数多1，

比最小个数少1的数作为测试数据。例如，某个文件有1～255个记录，则可

选取1个记录、255个记录、0个记录和256个记录的输入文件作为输入数据。

3)如果程序的规格说明书给出的输入域或输出值域是有序集合（如有序表、顺序

文件等），则应选取集合的第一个元素和最后一个元素作为测试用例。

4)如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构的边界值

作为测试用例。例如，在程序中定义的数组下界为0，上界为100，则应选取0

和100作为测试用例。

3.9.1.3错误推测

这是一种需要测试经验和直觉的测试方法，有针对性的设计测试用例。先将可能出现的错误列表，在选择测试用例。

例如：在测试医疗MIS时可考虑到1）药库为空。2）同步操作。3）倒序操作。所以要具体情况具体分析。

3.9.1.4因果图法

1)分析软件规格说明书中，哪些是原因（即输入条件或输入条件的等价类），哪些是

结果（即输出条件），并给每个原因和结果赋予一个标识符。

2)分析软件规格说明书中的语义，找出原因与结果之间以及原因与原因之间的对应关

系，根据这些关系画出因果图。

3)由于语法或环境的限制，有些原因与结果之间或原因与原因之间的组合情况不可能

出现，则可在因果图上用一些记号标明这些约束或限制条件。

4)把因果图转换成判定表。

5)把判定表的每一列所表示的情况生成测试用例。

3.10评审测试案例

参考《评审规程》

3.11参考内容

《测试案例模板》

4、单元测试

4.1单元测试目的

单元测试又称模块测试，是针对软件设计的最小单元――程序模块，目的在于发现各模块内部可能存在的各种差错。

4.2岗位与职责

4.2.1项目经理

分析测试度量数据，确保测试得以充分执行；

关注缺陷的解决过程。

4.2.2单元测试负责人

由《单元测试计划》中指定的负责人负责单元测试活动，确保所有测试活动按照计划进行，确保测试记录得到维护，并根据《度量方法》产生测试度量数据；

4.2.3单元测试人员

由《组装测试计划》中指定的测试人员执行单元测试并记录跟踪测试中发现的问题。

4.2.4开发小组

负责解决测试过程中发现的问题；

4.2.5入口、出口条件

阶段入口条件活动出口条件

单元测试1.《单元测试计划

和测试用例》得到

批准；

2.模块编码已经完

成并通过了代码

同行评审

按照单元测试

计划，交叉执

行单元测试案

例。

1.100%代码语句和分支覆盖

2.《单元测试分析报告》完成；

3.《测试问题跟踪记录表》产生

与解决；

4.测试通过审核人的批准以及

项目经理的签发；

5.3单元测试方法

单元测试采用白盒测试技术。

5.4单元测试检查单

执行单元测试时依据此检查单来检查测试的充分性：

?逻辑和算法：正确实现了逻辑和算法

?数据结构（全局和局部）：使用了全局数据结构？哪些？如果有，作了哪些关于全局数据的假设？这些假设正确吗？使用了局部数据？在算法执行的所有

步骤期间，保持局部数据的完整性了吗？

?接口：来自调用模块的数据匹配被调用的模块的期望接收的数据？被调用模块的数据匹配调用的模块提供的数据？

?独立路径：标识了所有穿过模块的独立路径？执行了吗？

?边界条件：了解边界条件吗？进行了测试确保该模块在其边界条件上的适当的操作了吗？

?出错处理：所有出错处理路径均执行到了吗？

5.5单元测试的流程

1)满足以下任何条件的所有的单元、模块、组件都要进行单元测试：

?被修改的代码或者新开发的代码，也就是说没有修改的代码不需要做单元测试；

?跨多个项目使用的模块，如：对公用的模块进行单元测试以确保其满足多

个项目的特殊需求；

?测试经理可以对上面的条件进行增加；

2)测试人员依照《单元测试计划》和《单元测试案例》进行单元测试；

3)单元测试负责人确保《单元测试计划》和《单元测试案例》是经过评审并得

到批准的；

4)当测试用例的测试结果与预期值存在偏差时，测试者记录下实际结果；

5)测试者使用Bug管理系统记录跟踪所有发现的问题，单元测试负责人每天测

试工作后必须备份当天的测试记录。

6)开发组人员对问题进行技术评审，由技术负责人进行确认；

7)如属于程序问题时，开发人员直接进行修改；如属于设计问题，则遵从《变

更规程》进行修改；

8)当修改软件以纠正发现的问题时，测试者需要进行回归测试以保证这些修改

没有带来新的问题；

9)当《单元测试计划》和《单元测试用例》中定义的出口条件得到满足时，单

元测试完成；

10)单元测试阶段完成时，单元测试负责人提交《单元测试总结报告》；

6参考内容

《测试总结报告模版》

7组装测试

7.1组装测试目的

组装测试也叫做集成测试或联合测试，组装测试目的试图发现模块间接口缺陷。

单元测试后还需要进行组装测试的原因：

●一个模块可影响其它模块。

●当结合了子功能后，没导致主要的功能的出现。

●个别的可接受的不精确的计算被扩大到不可接受的范围。

●在单元测试未被检查的接口错误可能出现。

●时间问题（实时系统）在单元测试中不可检查出。

●单元测试不能检查资源争夺问题。

7.2岗位与职责

7.2.1项目经理

分析测试度量数据，确保测试得以充分执行；

7.2.2组装测试负责人

由《组装测试计划》中指定的负责人负责组装测试活动，确保所有测试活动按照计划进行，确保测试记录得到维护，并根据《度量过程》产生测试度量数据；

7.2.3组装测试人员

由《组装测试计划》中指定的测试人员执行组装测试并记录跟踪测试中发现的问题。

7.2.4开发小组

负责解决测试过程中发现的问题；

7.2.5入口与出口条件

阶段入口条件活动出口条件

组装测试1《组装测试计划

和测试用例》得

到批准；

2单元测试通过审

核人的批准以及

测试经理的签

发；

3100%正确的执行

代码语句和分支

覆盖

按照组装测试计划，

交叉执行组装测试案

例。

1.《组装测试总结

报告》完成；

2.《测试问题跟踪

记录表》产生与解

决；

3.测试通过审核人

的批准以及事业

部测试组长的签

发；

7.2.6组装测试方法

7.2.6.1一次性组装;

使用一步到位的方法来构造程序，所有模块都预先组装在一起，作为一个整体来

测试。

7.2.6.2增量式组装

7.2.6.3自顶向下

1)用主控模块作为驱动模块，用所有的模块代替桩模块，直接地从属于主模

块。

2)取决于所选的集成方法（先深度或先宽度），在一次集成中用模块替代次桩。

3)随着集成每个模块来运行测试。

4)在成功的完成了一个测试集的基础上，用一个实际的模块代替另一个桩。

5)执行回归测试确保不会由于新的模块集成产生错误。重复第2步～第5步，

直到整个程序集成完毕。

7.2.6.4自底向上;

1)从底层模块开始集成，合并到集成clusters或builds执行一个指定的软

件子功能。

2)写驱动程序（开发作为桩的控制程序）来协调测试用例的输入和输出。

3)测试这个集成clusters。

4)去掉这个驱动程序且合并这个集成clusters，移到程序结构的上一级

7.2.6.5组装测试流程：

1)单元测试通过后项目经理提交正式的组装测试申请给事业部测试组长。

2)组装测试负责人确保《组装测试计划》和《组装测试用例》是经过评审并得到

批准的；

3)测试人员依照《组装测试计划》和《组装测试用例》，进行系统集成与测试；

4)当测试用例的测试结果与预期值存在偏差时，测试者记录下实际结果；

5)测试者使用Bug管理系统记录所有发现的问题，组装测试负责人在每天测试工

作后必须备份当天的测试记录。

6)开发组人员对问题进行技术评审，由技术负责人进行确认；

7)如属于程序问题时，由开发人员进行修改；如属于设计问题，则遵从《变更规

程》进行修改；

8)当修改软件以纠正发现的问题时，测试者需要进行回归测试以保证这些修改没

有带来新的问题；

9)当《组装测试计划》和《组装测试用例》中定义的出口条件得到满足时，集成

测试完成；

10)集成测试阶段完成时，测试负责人提交《集成测试总结报告》；

8验收测试

8.1验收测试的目的

在软件开发结束时，评价软件的过程，以确保开发的软件与需求一致。

验收测试阶段发现的错误数应不超过前期测试发现的错误总数的20%。

8.2岗位与职责

8.2.1项目经理

分析测试度量数据，确保测试得以充分执行；

8.2.2验收测试负责人

由《验收测试计划》中指定的负责人负责验收测试活动，确保所有测试活动按照计划进行，确保测试记录得到维护，并根据《度量过程》产生测试度量数据；8.2.4验收测试人员

由《验收测试计划》中指定的测试人员执行测试并记录跟踪测试中发现的问题。

8.2.5开发小组

负责解决测试过程中发现的问题；

8.2.6入口与出口条件

8.2.7验收测试步骤

1)集成测试通过后，项目经理以产品的最终发行形式（即安装光盘）提交向项目

管理部测试组，并提出书面的验收测试申请，

2)产品提交测试组后，先由测试组组长组织测试人员对产品进行接受测试。符合

测试的产品由测试组长签字,进入验收测试阶段，否则返回项目组重新进行相