软件开发文档：系统的测试示例文档.docx

第7章 系统的测试
7.1系统的测试框架
在软件系统开发的各个环节都有可以产生问题，因此需要不断的进行测试。目前，一种主流的思想认为任何系统开发后都存在各种各样的缺陷，而这些缺陷的存在是不可避免的。测试的目的不是证明系统的准确性，而是为是尽可能的发现系统存在的问题，从而减少当系统交付客户后暴露出的问题，从而提升用户的体验、降低系统的开发、运行与维护成本。
软件测试[27-30]的方法很多。在本系统中测试策略主要以时间为序，按目的展开测试。具体测试框架如图7-1所示：

图7-1本系统测试的框架

软件测试贯穿软件工程的每个阶段，一般来讲单元测试对应系统开发中的模块、类、方法。由于每个单元较小，最适合由开发人员自行测试。由于不同的类、模块、包等由不同开发人员开发，在集成时需要进行集成测试，看在调用方面是否存在问题。由于这一部分不与具体功能关联，所以测试规模不大。
在开发的各个阶段有单元测试、集成测试、系统测试与验收测试等不同的测试。然而这四种测试的测试计划制定时间与其开展的时间正好相反。测试计划的制定与测试工作的开展在时间上有较强的应对关系，相关情况如图7-2所示：

图7-2程序开发对应测试类型
7.2单元测试
7.2.1单元测试作用
就范围而言单元测试是软件测试是最小规模的一种。单元测试只关注某个方法、类的内部处理细节，如顺序与路径等。单元测试需要注意以下几点内容：
1）测试目标单元的执行过程是否与预期一致。
2）单元测试需要关注测试目标内部的路径。在有较多路径的情况下需要采用路径覆盖，使得尽可能多的路径被测试到。如果忽略了一些非主要的分支路径，则这种隐患可能在系统运行时显露出来。
单元测试根据测试的目的，又有不同的分类等。例如功能单元测试用于测试单元是否实现了预期的目标，逻辑单元测试用于了解被测试单元的逻辑是否合乎要求，而集成单元测试则用于了解不同单元之间的相互调用情况。
7.2.2基于NUnit的单元测试
在微软的VS.NET集成开发环境中内容了NUnit单元测试工具，该工具能根据测试目标的名称、输入、输出等相关信息生成桩模块。相关模块结构如下：
[TestMethod]
public void TestMethod1(参数1，参数2，…..)
{
// 定义相关参数值
// 将期望值与运行结果进行比对
// 输出对比结果。
}
在提供了桩模块后系统还会生成驱动模块，只需要驱动模块中提供输入参数与期望值，系统会自动进行批量测试。
7.2.3单元测试的实现
在得知NUnit的工作原理后，只需要提供测试用例即可进行单元测试。此处测试用例的编写有一定的依据，在本系统中这些依所为为需求分析时的数据字典、数据流图等。以下列举出系统中常用的几个测试用例。
表7-1 用户入职时间合法性检查用例
测试用例
期望结果
实际结果
20121212
√
√
32323232323232323
χ
χ
“ ”[输入空格]
χ
χ
321 321 321 321 321
χ
χ
DEF.COMASD
χ
√
&%$%#$%
χ
χ
4432@126
χ
√
DFEH ab
χ
√

（2）表7-2所示为用户邮箱测试用例。
表7-2用户邮箱测试用例
测试用例
期望结果
实际结果
abc@
√
√
[e-mail]
√
χ
“ ”
χ
χ
*&%&^
χ
χ
123456
χ
χ
[e-mail]
χ
χ
123@123
χ
χ
1286@123 123
χ
χ

（3）白盒测试反馈
此处的白盒测试主要用于测试小范围的代码段或简单的逻辑片段，如表5.3为白盒测试用例。
表7-3白盒测试用例
√/χ
测试
√
1、 代码已经遵守开发标准，未见错误
2、 代码逻辑经验证无误
3、 代码有良好的编码风格，注释简洁易懂
4、代码层次结构按规范编写
√
1、 使用NUnit对所有单元进行的测试
2、 所有的代码逻辑均进行了测试

（4）其他功能模块测试
表6-4所示为用户ID的测试用例。
表7-4用户ID测试用例
测试用例
期望结果
实际结果
20110101
χ
√
Dream
√
√
Dream Dream
χ
χ
21_21
χ
χ
2010-10-10
χ
χ
%&%#$$()
√
χ
abcdefg
χ
χ
ABCDEFGQWERRTYU
χ
χ
山山山山山
χ
χ
姓名
√
√
while
χ
χ
return
χ
χ

表7-5为用户职位测试用例，职位由不超过10位的英文、中文字符组成，不能与一些保留字相同。
表7-5 用户职位测试用例
测试用例
期望结果
实际结果
Dream
√
√
Dream Dream
χ
χ
21_21
χ
χ
2010-10-10
χ
χ
%&%#$$()
χ
χ
abcdefg
χ
χ
ABCDEFGQWERRTYU
χ
χ
山山山山山
χ
χ
while
χ
χ
return
χ
χ
7.3系统的集成测试
7.3.1集成测试的作用
在开发时，由于不同开发人员在沟通、理解方面的偏差可能造成系统不同接口互不配置，从而导致系统集成过程无法成功的情况。因此需要使用集成测试来达到这一目标。这一目标的时间安排在编码之后。该测试只需关注能否衔接而无需关注安全、性能等问题。
7.3.2集成测试策略
本系统中集成测试采用自下而上的方式进行。即从最下层的模块入手进行模块的组合。当对第N层进行测试时，由于第N-1层已经完成了集成并通过了测试，所以就不用再写桩模块。这在一定程度上提高了系统测试的效率。
选择这种集成方式，管理方便、测试人员能较好地锁定软件故障所在位置。
集成测试中的主要步骤：
1）制定审核测试计划
2）制定和审核测试用例
3）进行测试活动
4）书写测试报告
具体细节见表7-6:
表7-6 系统集成测试过程
活动
输入
输出
职责
制定集成测试计划
设计模型
集成构建计划
集成测试计划
制定测试计划
设计集成测试
集成测试计划
设计模型
基础测试用例
测试过程
集成测试用例测试过程
实施集成测试
集成测试用例
测试过程
工作版本
测试脚本
测试过程
编制测试代码更新测试过程
测试驱动(底向上)
编制驱动或桩
执行集成测试
测试脚本
工作版本
测试的相关结果
测试并记录结果
评估集成测试
集成测试计划
测试结果
测试评估摘要
和开发人员一道进行设计，得到测试报告

7.3.3集成测试的实现

由于项目的规则，集成测试的范围很大，下文仅以人员管理为出发点进行举例说明。其流程如图7-3所示，测试用例如表7-7所示。
表7-7集成测试用例
测试用例
成功/失败
Linq to SQL能否与原有已经架构融合
Success
发起工作流后能否保存流程
Success
文件发送后能否被正常接收
Success
立案的状态变更时是否都有应对者
Success
工作人员能否正常看到需要处理的流程
Success
复杂业务与简单业务间的调用能否正常进行
Success

图7-3 集成测试流程图
从表7-7的测试结果可以得知，本系统在集成测试上没有发现明显问题。
7.4系统测试
7.4.1性能测试目的与方法
性能测试主要是模拟现实中用户的数量来实现对系统的访问，使得在系统高负荷运行的情况下找出系统的处理能力及存在的瓶胫，以便加强系统的健壮性。
作为一款B/S结构的应用程序，由于其体系结构的特点，在发布后主要的压力集中于服务器端，因此对于这一类型的应用程序，性能测试特别重要。在本应用中，为模拟客户的最终运行环境，设置测试的系统拓扑结构如下：

图7-4 系统测试拓扑图

在上图中，将用户分为内网与外网用户，并需要相关设备如下：
表7-8 相关设备
设备
数量
台式电脑
10
应用程序服务器(PowerEdge R710)
1
数据库服务器(PowerEdge R710)
1
测试服务器(PowerEdge R710)
1

在测试时由之前选定的测试人员在各自的联网计算机上运行性能测试工具LoadRunner。每个LoadRunner运行实例各开启一定数量的系统进程，模拟3000用户同时在线的负荷，基本与系统使用最高峰值的负荷。测试的主要目的是模拟系统在强大的运行负荷下是否能够正常运行，功能是否完整，其结果如下：
表7-9 压力测试数据表
同时在线人数
响应时间（秒）
要求（秒）
评价
300
0.21s
1s
快
600
0.53s
1.5s
快
900
1.03s
1.8s
较快
1200
2.63s
3s
中等
1500
3.13s
4s
中等
2000
4.78s
5s
较慢
2500
6.36s
6.5s
慢
3000
8.52s
8s
慢
3100
10.23s
10s
超时

从上面的测试结果可以看出，系统在最多900人同时使用情况下，响应速度很快，用户可以快速完成相关操作。并发用户数在900-1200人的情况下，系统相应较快，在1200-1500人同时使用的情况下，系统速度中等，此时服务器负荷较大，但是不影响用户正常使用；超过2000人同时使用时，系统负荷较为严重，用户操作时间大幅度延长，但系统功能依旧稳定。超过2500人并发操作时，系统响应速度很慢，这是用户操作可能不流畅，且不能保证系统能够一次完成用户所需的功能；超过3000人时，某些客户端出现了响应超时的现象。但对于本系统而言，上述的数字已经完全能支撑本系统的运行。
7.4.2系统安装测试
安装时需要考虑各种异常情况，这些异常情况有：数据库版本不匹配、Web服务器设置问题、访问权限不足、文件太大不符操作系统格式、硬盘空间不足等。是否有正确的配置文件与完整的安装手册也是安装测试所需要关注的内容。表7-10给出了安装测试的用例。
表7-10安装测试用例
通过/不通过
测试
通过
测试数据库版本是否正确
通过
测试是否有正确的配置文件
通过
测试安装手册是否完整
通过
测试在不同操作系统下的适用性

上面给出了安装测试时需要考虑的部分内容。能够应对普通情况下的安装情况。但由于客户环境千差万别，在系统安全程度要求较高的时候还需要进行更为严格的安装测试。
7.5本章小结
本章对国土资源监察管理信息系统进行了测试。该测试以软件工程的过程为向导，以单元测试、集成测试、系统测试为例谈了本系统中的测试策略并给出了少量的测试用例。