1、第 7 章 系统的测试7.1 系统的测试框架在软件系统开发的各个环节都有可以产生问题，因此需要不断的进行测试。目前，一种主流的思想认为任何系统开发后都存在各种各样的缺陷，而这些缺陷的存在是不可避免的。测试的目的不是证明系统的准确性，而是为是尽可能的发现系统存在的问题，从而减少当系统交付客户后暴露出的问题，从而提升用户的体验、降低系统的开发、运行与维护成本。软件测试 27-30的方法很多。在本系统中测试策略主要以时间为序，按目的展开测试。具体测试框架如图 7-1 所示：单元开发阶段组件组装阶段系统完成阶段单元测试代码测试集成测试功能测试系统测试性能测试图 7-1 本系统测试的框架软件测试贯穿软件
2、工程的每个阶段，一般来讲单元测试对应系统开发中的模块、类、方法。由于每个单元较小，最适合由开发人员自行测试。由于不同的类、模块、包等由不同开发人员开发，在集成时需要进行集成测试，看在调用方面是否存在问题。由于这一部分不与具体功能关联，所以测试规模不大。在开发的各个阶段有单元测试、集成测试、系统测试与验收测试等不同的测试。然而这四种测试的测试计划制定时间与其开展的时间正好相反。测试计划的制定与测试工作的开展在时间上有较强的应对关系，相关情况如图 7-2 所示：用户需求 验收测试逻辑设计系统测试物理设计 集成测试软件开发软件测试详细单元设计 单元测试编写代码验证验证验证验证图 7-2 程序开发对应
3、测试类型7.2 单元测试7.2.1 单元测试作用就范围而言单元测试是软件测试是最小规模的一种。单元测试只关注某个方法、类的内部处理细节，如顺序与路径等。单元测试需要注意以下几点内容：1）测试目标单元的执行过程是否与预期一致。2）单元测试需要关注测试目标内部的路径。在有较多路径的情况下需要采用路径覆盖，使得尽可能多的路径被测试到。如果忽略了一些非主要的分支路径，则这种隐患可能在系统运行时显露出来。单元测试根据测试的目的，又有不同的分类等。例如功能单元测试用于测试单元是否实现了预期的目标，逻辑单元测试用于了解被测试单元的逻辑是否合乎要求，而集成单元测试则用于了解不同单元之间的相互调用情况。7.2.
4、2 基于 NUnit 的单元测试在微软的 VS.NET 集成开发环境中内容了 NUnit 单元测试工具，该工具能根据测试目标的名称、输入、输出等相关信息生成桩模块。相关模块结构如下：TestMethodpublic void TestMethod1(参数 1，参数 2，.)/ 定义相关参数值/ 将期望值与运行结果进行比对/ 输出对比结果。在提供了桩模块后系统还会生成驱动模块，只需要驱动模块中提供输入参数与期望值，系统会自动进行批量测试。7.2.3 单元测试的实现在得知 NUnit 的工作原理后，只需要提供测试用例即可进行单元测试。此处测试用例的编写有一定的依据，在本系统中这些依所为为需求分析时
5、的数据字典、数据流图等。以下列举出系统中常用的几个测试用例。表 7-1 用户入职时间合法性检查用例测试用例 期望结果 实际结果20121212 32323232323232323 “ ”输入空格 321 321 321 321 321 DEF.COMASD &%$%#$% 4432126 DFEH ab （2）表 7-2 所示为用户邮箱测试用例。表 7-2 用户邮箱测试用例测试用例 期望结果 实际结果 DEFABC.COM “ ” *&%& 123456 123123.COM 123123 1286123 123 （3）白盒测试反馈此处的白盒测试主要用于测试小范围的代码段或简单的逻辑片段，如表
6、 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 为用户
7、职位测试用例，职位由不超过 10 位的英文、中文字符组成，不能与一些保留字相同。表 7-5 用户职位测试用例测试用例 期望结果 实际结果Dream Dream Dream 21_21 2010-10-10 %&%#$() abcdefg ABCDEFGQWERRTYU 山山山山山 while return 7.3 系统的集成测试7.3.1 集成测试的作用在开发时，由于不同开发人员在沟通、理解方面的偏差可能造成系统不同接口互不配置，从而导致系统集成过程无法成功的情况。因此需要使用集成测试来达到这一目标。这一目标的时间安排在编码之后。该测试只需关注能否衔接而无需关注安全、性能等问题。7.3.2 集
8、成测试策略本系统中集成测试采用自下而上的方式进行。即从最下层的模块入手进行模块的组合。当对第 N 层进行测试时，由于第 N-1 层已经完成了集成并通过了测试，所以就不用再写桩模块。这在一定程度上提高了系统测试的效率。选择这种集成方式，管理方便、测试人员能较好地锁定软件故障所在位置。集成测试中的主要步骤：1）制定审核测试计划2）制定和审核测试用例3）进行测试活动4）书写测试报告具体细节见表 7-6:表 7-6 系统集成测试过程活动 输入 输出 职责制定集成测试计划 设计模型集成构建计划集成测试计划 制定测试计划设计集成测试 集成测试计划设计模型基础测试用例测试过程集成测试用例测试过程测试脚本测试
9、过程编制测试代码更新测试过程实施集成测试 集成测试用例测试过程工作版本 测试驱动(底向上) 编制驱动或桩执行集成测试 测试脚本工作版本测试的相关结果 测试并记录结果评估集成测试 集成测试计划测试结果测试评估摘要 和开发人员一道进行设计，得到测试报告7.3.3 集成测试的实现由于项目的规则，集成测试的范围很大，下文仅以人员管理为出发点进行举例说明。其流程如图 7-3 所示，测试用例如表 7-7 所示。表 7-7 集成测试用例测试用例 成功/失败Linq to SQL 能否与原有已经架构融合 Success发起工作流后能否保存流程 Success文件发送后能否被正常接收 Success立案的状态变
10、更时是否都有应对者 Success工作人员能否正常看到需要处理的流程 Success复杂业务与简单业务间的调用能否正常进行 Success读取 c o n t e x t 位置通过 c o n t e x t 读取 b e a n r u l e D e f i n e S e r v i c e初始化类U s e r i n f o , 并设置初值插入测试值i n s e r t U s e r删除测试值i n s e r t U s e r通过 J d b c T e m p l a t e 查找插入数据通过 J d b c T e m p l a t e 查找删除数据a s s e r
11、t E q u a l s ( 查询结果 ，预期值 )a s s e r t E q u a l s ( 查询结果 ，n u l l )回流动事务图 7-3 集成测试流程图 从表 7-7 的测试结果可以得知，本系统在集成测试上没有发现明显问题。7.4 系统测试 7.4.1 性能测试目的与方法性能测试主要是模拟现实中用户的数量来实现对系统的访问，使得在系统高负荷运行的情况下找出系统的处理能力及存在的瓶胫，以便加强系统的健壮性。作为一款 B/S 结构的应用程序，由于其体系结构的特点，在发布后主要的压力集中于服务器端，因此对于这一类型的应用程序，性能测试特别重要。在本应用中，为模拟客户的最终运行环境
12、，设置测试的系统拓扑结构如下：外网客户端内网系统服务器内网客户端数据库服务器测试服务器测试记录终端图 7-4 系统测试拓扑图在上图中，将用户分为内网与外网用户，并需要相关设备如下：表 7-8 相关设备设备 数量台式电脑 10应用程序服务器(PowerEdge R710) 1数据库服务器(PowerEdge R710) 1测试服务器(PowerEdge R710) 1在测试时由之前选定的测试人员在各自的联网计算机上运行性能测试工具LoadRunner。每个 LoadRunner 运行实例各开启一定数量的系统进程，模拟3000 用户同时在线的负荷，基本与系统使用最高峰值的负荷。测试的主要目的是模拟
13、系统在强大的运行负荷下是否能够正常运行，功能是否完整，其结果如下： 表 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 人的情况下，系统相应较快，在 12
14、00-1500 人同时使用的情况下，系统速度中等，此时服务器负荷较大，但是不影响用户正常使用；超过 2000 人同时使用时，系统负荷较为严重，用户操作时间大幅度延长，但系统功能依旧稳定。超过 2500 人并发操作时，系统响应速度很慢，这是用户操作可能不流畅，且不能保证系统能够一次完成用户所需的功能；超过 3000 人时，某些客户端出现了响应超时的现象。但对于本系统而言，上述的数字已经完全能支撑本系统的运行。7.4.2 系统安装测试安装时需要考虑各种异常情况，这些异常情况有：数据库版本不匹配、Web 服务器设置问题、访问权限不足、文件太大不符操作系统格式、硬盘空间不足等。是否有正确的配置文件与完整的安装手册也是安装测试所需要关注的内容。表 7-10 给出了安装测试的用例。表 7-10 安装测试用例通过/不通过 测试通过 测试数据库版本是否正确通过 测试是否有正确的配置文件通过 测试安装手册是否完整 通过 测试在不同操作系统下的适用性上面给出了安装测试时需要考虑的部分内容。能够应对普通情况下的安装情况。但由于客户环境千差万别，在系统安全程度要求较高的时候还需要进行更为严格的安装测试。7.5 本章小结本章对国土资源监察管理信息系统进行了测试。该测试以软件工程的过程为向导，以单元测试、集成测试、系统测试为例谈了本系统中的测试策略并给出了少量的测试用例。
