系统测试示例文档
系统测试报告参考文档
系统测试报告1 系统测试报告写作的目的1、软件测试人员对整个系统测试工作进行总结，对被测试对象进行评估，并对以后的测试工作给出建议2、测试经理通过测试报告了解被测试产品的质量情况、测试过程的质量3、软件开发项目经理通过软件测试报告了解开发产品的质量情况，并在下阶段的开发工作中采取应对措施4、在软件测试报告中，软件测试人员作出的软件产品质量评估，可以作为软件产品是否对外发布的重要参考依据。
2 系统测试报告写作的要点2.1 概述简单介绍被测对象、测试特性及其版本/修订级别情况指明本次系统测试活动所依据的测试计划、测试方案、测试用例及测试过程，对测试内容也要进行简要说明2.2 测试时间、地点、人员描述本次测试的时间，地点和测试人员，以及人员分工。
例如：2.3 环境描述描述本次测试的环境，包括软硬件、测试仪器、组网图等。
例如：2.4 总结和评价2.4.1 测试过程质量统计评估1、工作量数据统计例如：分析：1）可以根据不同模块每千行代码投入的工作量来查看哪些模块测试比较充分；哪些模块测试不够充分。
2）结合模块的实际情况，对关键模块或者复杂模块投入的测试人时比例应相对较高；对非关键或者简单的模块投入的测试人时比例可以相对较低，根据该指标可以用来衡量测试过程中测试资源的分布是否合理。
2、用例数统计例如：分析：1）可以根据用例数/KLOC来查看哪些模块用例设计的比较充分；哪些模块用例设计的相对比较少，结合模块的具体特点，需要进行分析，避免关键模块用例设计不充分的情况。
2）可以根据不同模块用例数来了解不同测试人员的工作量；结合时间方面的数据，对工作量少而花费时间较多的情况进行调查分析，对其中存在的问题采取相关策略进行有效的规避。
3、用例对需求的覆盖率例如：分析：从需求的覆盖率来查看不同的需求对应的用例数，可以考量不同需求测试的程度：1）对于重要的关键的需求，应该设计比较充分的用例；2）对于功能比较简单的需求，可以设计相对少的用例；3）对于没有用例对应的需求，一定要调查相关负责人员的工作情况，避免工作中的不认真导致的测试的不全面性。
系统测试全文档
系统测试1。
测试定义：验证被测试软件与需求是否一致的一系列的测试活动(测试计划、设计、用例、缺陷报告)2。
测试的方法：A是否看内部结构：黑盒测试：不关注软件的内部代码，只关注输入和输出验证是否和需求一致的优点：关注用户体验，验证明确缺点：发现不了隐藏的问题白盒测试：测试代码的逻辑，验证代码是否正确优点：发现隐藏的问题缺点：忽略用户体验，技术要求，费时B是否依赖工具：自动测试：由工具执行的测试优点：省时省力、可重复、准确率高、测试的覆盖率高、人做不了缺点：成本高、人员技术、没有想象力人工测试：由人来执行的测试优点：缺点：C 是否程序运行：静态测试：被测的程序没有运行（界面，文字描述）动态测试：被测的程序运行3。
质量：软件满足需求的程度1功能性：软件能做什么，不能做什么2 易用性：布局：控件左对齐，上下左右均匀分布字体：大小颜色统一，描述适当提示和帮助信息快捷键3 性能性：速度、资源利用率低4 可移植：不同的操作系统，不同的浏览下（兼容性）5 可靠性：能处理各种错误信息面试题：你是电梯测试公司的测试负责人，一个用户打来电话说，一栋楼的电梯需要检测。
你们能做吗？能先给我一个测试方案看看嘛？4。
测试过程：常见的生命周期模型模型：定义了生命周期中要做的各项工作的规范和顺序瀑布模型重点环节：1、需求分析，需求规格文档2、总体设计，概要设计文档3、详细设计，详细设计文档4、编码，写代码5、测试，在编码完成后进行优点：顺序清晰缺点：1、由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险2、如果软件规模大，需求难以一次到位V 模型实现：顺序测试：阶段划分单元测试：测试单模块代码（开发做）集成测试：测模块间的接口系统测试：测试整体的系统验收测试：用户参与的测试项目验收测试：客户验收项目产品验收测试：阿尔法（α）测试：可控(公司内部)贝塔（β）测试：不可控双V模型W 模型系统测试：系统<<测试计划>> ：人员，时间、任务安排、软件功能点等----测试经理系统<<测试设计>>：方法，工具、数据、来源---高级测试工程、测试经理系统测试实现：<<测试用例>>- ---测试人员用例编号标题步骤描述预期结果3C001 整数加法 1.启动计算其2.点1+2C002 小数加法 1.启动计算其3.32.点1.1+2.2系统测试执行：<<报缺陷报告>> ，<<测试总结>>回归测试：被测软件被修改或增加新功能后重新测试的过程5。
软件工程_医院挂号系统_软件测试文档
《医院挂号系统软件测试文档》2012年6月1日目录1 系统测试........................................................ I I1.1 测试环境.................................................. I I1.2 测试用例设计与执行记录.................................... I I1.2.1 登陆模块............................................. I I1.2.2 图书出借管理模块...................... 错误!未定义书签。
1.3 测试可行性分析............................................ V I系统测试1.1 测试环境1. 操作系统：Windows XP2. 数据库：SQL Server 20053. Visual Studio .NET1.2 测试用例设计与执行记录1.2.1 用户登陆模块医院挂号系统登陆模块用户登陆模块测试项目/软件医院挂号系统程序版本 1.0.0功能模块名Login 编制人用例编号- P ri_Login编制时间2012.05.17 相关的用例无功能特性用户身份验证测试目的验证是否输入合法的信息，允许合法登陆，阻止非法登陆预置条件无特殊规程说明如数据库访问权限参考信息需求说明中关于“登陆”的说明测试数据用户名=00001 密码=00001 用户类型=挂号工作人员操作步骤操作描述数据期望结果实际结果测试状态1 输入用户名，密码，按“登陆”按钮。
用户名=00001，密码=00001，用户类型=挂号工作人员跳转到挂号工作人员主界面跳转到挂号工作人员主界面2 输入用户名，密码，按“登陆”按钮。
用户名=00005，密码=00001，用户类型=挂号工作人员显示警告信息“用户名或密码错误，您还有*次机会”显示警告信息“用户名或密码错误，您还有*次机会”3 输入用户名，密码，按“登陆”按钮。
系统测试设计用例设计方法三篇
系统测试设计用例设计方法三篇篇一：系统测试设计用例设计方法目录一、等价类分析法 (2)二、边界值分析 (2)三、错误猜测法 (3)四、判定表法 (3)五、流程分析方法 (4)六、正交试验设计法 (4)七、状态迁移法 (6)一、等价类分析法等价类划分方法针对手机状态大致可以归几个大类：1.按键类（等价法）：有效输入和无效输入（有效输入指UM和菜单指示；无效输入指测试菜单功能此时没有定义的按键和用户动作）；2.外部中断类（等价法）：常用、不常用及无效2.1.常用：来电和来消息（短信、彩信、push消息）；掀合盖；侧键；耳机＆FM；情景模式；电量不足2.2.不常用：充电；闹钟＆记事本＆关机时间＆整点报时提示；Icon＆动画显示；Icon＆动画刷新；编辑界面＆pop显示框输入为空或满；编辑界面＆pop 显示框状态输入法默认＆字符编码默认；失效SIM卡；大容量等SIM卡兼容；排序；号码识别；2.3.无效：“资料读取中…”；“复制中…”；“请稍后再试”3.存储器类3.1.等价法分类：读或写；不读或不写。
3.2.因果法分类：先SIM卡后手机；先手机后SIM卡；提示用户选择存储器（对比Nokia）。
3.3.操作分类：读；写；新增；删除；复制（先删除后新增；先新增后删除）状态类：正确；错误；变更；用户设定变更举例一，短消息发送功能:英文：Default7-bitalphabet(over160characters)合法等价类：0～160非法等价类：：>160Thequickfoxjumpsoverthelazybrowndog中文：UCS-2alphabet(over70characters)合法等价类：0～70非法等价类：：>70诺基亚（英文）：Extendeddefault7-bitalphabet(over140Bytes)，智慧短信，可以携带黑白图片。
合法等价类：0～140非法等价类：：>140在写字板里面输入“联通”二字，保存后，再打开，即出现乱码。
系统测试报告文档
系统测试报告文档一、背景介绍系统测试是软件开发生命周期中的一项重要环节，目的是验证软件系统是否满足需求规格说明书中所定义的功能需求和性能指标。
本系统测试报告将对系统测试工作进行总结和说明。
二、测试目的本次系统测试的目的是验证系统的功能和性能是否符合需求规格说明书中的要求，发现缺陷并进行修复，为软件的正式上线提供依据。
三、测试环境1.硬件环境：-设备：PC台式机- CPU：Intel Core i7-9700K-内存：16GB-存储：SSD500GB2.软件环境：- 操作系统：Windows 10- 浏览器：Chrome、Firefox四、测试范围本次系统测试的范围包括以下几个方面：1.功能测试：验证系统的各项功能是否正常可用，包括但不限于登录、注册、浏览商品、下单、支付等功能。
2.兼容性测试：测试系统在不同浏览器下的兼容性，确保系统在各种浏览器上都能正常运行。
3.性能测试：测试系统在高并发情况下的性能表现，包括响应时间、吞吐量、并发用户数等指标。
4.安全测试：测试系统的安全性，包括对输入数据的过滤和校验、防止SQL注入、XSS攻击等。
五、测试过程和结果1.功能测试：基于需求规格说明书编写测试用例，覆盖系统的各个功能点。
测试人员根据测试用例一一进行测试，发现了部分功能缺陷。
在开发人员的修复下，重新进行了测试，确认缺陷已经解决。
2. 兼容性测试：测试人员在不同浏览器下对系统进行测试，包括Chrome、Firefox等。
测试结果表明系统在各个主流浏览器上均能正常打开和操作。
3.性能测试：测试人员使用性能测试工具对系统进行了压力测试。
测试结果表明，在1000个并发用户的情况下，系统仍然保持稳定，响应时间在1秒以内。
4.安全测试：测试人员通过输入恶意数据对系统进行了安全测试，包括SQL注入、XSS攻击等。
测试结果表明系统对于恶意输入有良好的过滤和校验机制，能够有效防止攻击。
六、存在的问题及改进措施1.在功能测试中发现了部分缺陷，虽然后续修复了该缺陷，但仍需要对开发过程中的质量控制进行改进，提高开发人员的测试意识和测试能力。
系统测试报告实例
系统测试报告实例一、引言系统测试是软件开发过程中的一个重要环节，它的目的是验证系统的功能、性能、可靠性、安全性等方面，以保证软件质量和满足用户需求。
本文档将对ABC公司开发的销售管理系统进行系统测试的过程、方法和结果进行详细说明。
二、测试目的和范围本次系统测试的目的是验证销售管理系统的功能、性能、安全性和可靠性等方面，以确认系统是否满足需求并且能够稳定运行。
测试范围包括系统的所有功能模块以及相关的性能指标和安全机制。
三、测试环境测试环境如下：操作系统：Windows Server 2024数据库：MySQL8.0测试工具：JMeter、Selenium硬件配置：CPUi7-8700；内存16GB网络环境：局域网四、测试方法系统测试将采用黑盒测试方法，通过测试用例对系统的功能进行全面覆盖，同时利用Selenium进行系统的自动化UI测试。
性能测试将使用JMeter对系统的响应时间、并发用户数等方面进行测试，并分析系统的瓶颈和可能存在的问题。
五、测试用例本次系统测试共编写了100个测试用例，其中包括常规功能测试、异常功能测试、边界值测试、安全测试、并发测试等。
具体的测试用例和测试结果将在附录中详细列出。
六、测试结果1.常规功能测试：经过测试，系统的所有常规功能均能够正常运行，没有出现功能性问题。
2.异常功能测试：在输入错误数据的情况下，系统能够正确地检测并给出错误提示，保证了系统的异常处理能力。
3.边界值测试：系统在边界值测试中表现正常，没有出现越界或溢出等问题。
4.安全测试：系统的登录和数据访问控制机制能够有效防止非法用户的入侵和数据泄露。
5.性能测试：系统在高并发用户数下运行平稳，响应时间符合预期，系统的吞吐量和并发用户数达到了设计要求。
七、问题和改进建议在测试过程中，提出了一些系统存在的问题和改进建议，如：一些功能的操作流程不够直观，建议增加用户引导性的设计；一些批处理操作的执行时间较长，建议对操作逻辑进行优化等。
(完整word版)测试用例(word文档良心出品).doc
输入/动作
期望的输出/相应
实际情况
输入《傅雷家书》进行查询
访问成功，显示是否可借
吻合
接口D（管理员登录管理员登录
接口）
输入/动作期望的输出/相应实际情况
管理 员ID:0078002010,密码 ：登录成功吻合
hujianfeng
用户名：abcdefghijklmnopad,密用户名超过边界，显示错误吻合
1.1被测试对象（单元）的介绍
校 园一 卡 通信 息 系 统 的用户接口，是用户与计算机交互的接口，系统管理员通过接口对一卡
通进行管理，以及对用户的消费金额进行更新。硬件接口包括校园一卡通，扫描仪器，用户通过校园
一卡通可以借书，还书以及续借，图书管理员通过校园一卡通可以查阅用户的基本资料。扫描仪器通
前提条件承压测试之前系统正常运行
输入数据期望的性能（平均值）实际性能（平均值）
系统正常运行的同时，打开系统崩溃吻合
1000个页面
同时进行借书和新书入库操作系统正常运行吻合
5.图形用户界面测试用例
5.1被测试对象的介绍
被测试对象主要包括各种图形用户界面（GUI），包括登录界面，校园一卡通界面，办卡界面，
实际情况
《C程序设计》从扫描仪扫描经
显示用户是否超期，未超期还书
吻合
过
成功
《JAVA程序设计》从扫描仪扫
显示用户超期天数（
4天），
吻合
描经过
3.健壮性测试用例
3.1被测试对象的介绍
健壮性测试是用于对校园一卡通信息出现故障时，是否能够自动回复或者忽略故障继续运行。
3.2测试范围与目的
测试范围包括校园一卡通信息，以及有关的硬件设施。相关的功能。
测试记录模版
测试记录模版
标题，测试记录模版。
日期，2022年10月15日。
测试人员，小明。
测试目的，测试新版本软件的稳定性和功能性。
测试环境，Windows 10操作系统，软件版本号，V2.0。
测试内容：
1. 启动软件，软件启动速度较快，没有出现闪退现象。
2. 功能测试，测试了软件的各项功能，包括新功能和已有功能，均能正常运行。
3. 界面测试，界面设计简洁大方，操作流畅，没有出现卡顿或者界面错位的情况。
4. 兼容性测试，软件在Windows 10操作系统上运行良好，没有出现兼容性问题。
5. 性能测试，软件运行稳定，占用系统资源较少，对电脑性能影响不大。
测试结论：
经过本次测试，新版本软件在稳定性和功能性方面表现良好，没有出现重大
bug或者功能异常。
软件界面设计简洁大方，操作流畅，用户体验良好。
在Windows 10操作系统上运行稳定，没有出现兼容性问题。
总体来说，新版本软件
值得推荐使用。
改进建议：
1. 增加一些常用功能的快捷键，提高用户操作效率。
2. 在下个版本中增加一些新的实用功能，丰富软件的功能性。
3. 进一步优化软件的性能，提高软件的运行效率。
小结：
本次测试记录了新版本软件的稳定性和功能性，通过测试发现软件表现良好，但也提出了一些改进建议。
希望开发团队能够认真考虑改进建议，进一步提升软件的用户体验和性能。
CMMI 3标准文档模板-系统测试
CMMI 3标准文档模板第13章系统测试 (1)13.1 介绍 (1)13.2 系统测试规程 (2)13.2.1目的 (2)13.2.2角色与职责 (2)13.2.3启动准则 (2)13.2.4输入 (2)13.2.5主要步骤 (3)[Step1] 制定系统测试计划 (3)[Step2] 设计系统测试用例 (3)[Step3] 执行系统测试 (3)[Step4] 缺陷管理与改错 (3)13.2.6输出 (3)13.2.7结束准则 (4)13.2.8度量 (4)13.3 实施建议 (4)第13章系统测试系统测试（System Test, ST）的目的是对最终软件系统进行全面的测试，确保最终软件系统满足产品需求并且遵循系统设计。
系统测试过程域是SPP模型的重要组成部分。
本规范阐述了系统测试的规程，该规程的“目标”、“角色与职责”、“启动准则”、“输入”、“主要步骤”、“输出”、“完成准则”和“度量”均已定义。
本规范适用于国内IT企业的软件研发项目。
建议用户根据自身情况（如商业目标、研发实力等）适当地修改本规范，然后推广使用。
13.1 介绍系统测试流程如图14-1所示。
由于系统测试的目的是验证最终软件系统满足产品需求并且遵循系统设计，所以当产品需求和系统设计文档完成之后，系统测试小组就可以提前开始制定测试计划和设计测试用例，而不必等到“实现与测试”阶段结束。
这样可以提高系统测试的效率。
系统测试过程中发现的所有缺陷必须用统一的缺陷管理工具来管理，开发人员应当及时消除缺陷（改错）。
图13-1 系统测试流程图项目经理设法组建富有成效的系统测试小组。
系统测试小组的成员主要来源于：✧机构独立的测试小组（如果存在的话）。
✧邀请其它项目的开发人员参与系统测试。
✧本项目的部分开发人员。
✧机构的质量保证人员。
系统测试小组应当根据项目的特征确定测试内容。
一般地，系统测试的主要内容包括：✧功能测试。
即测试软件系统的功能是否正确，其依据是需求文档，如《产品需求规格说明书》。
系统测试案例分析..
构，服务器是一台PC Server（4路2.7GHz 处理器，4GB
内存），安装的平台软件包括Microsoft Internet
Information Server5.0，，SQLServer 2000。
使用2台笔记本电脑安装测试工具模拟客户端执行“登
录”业务操作。
Page 3
测试目标
Page 23
2.跨站点脚本攻击—如何预防？
从应用程序的角度： • 对Javascrīpt,VB scrīpt, HTML,ActiveX, Flash等 语句或脚本进行转义. • 在 服务端正式处理之前提交数据的合法性(合法性检查主要包括三项:数据类型,数据 长度,敏感字符的校验)进行检查等。最根本的解决手段,在确认客户端的输入合法之 前,服务端 拒绝进行关键性的处理操作. 从测试人员的角度: • 在需求检查过程中对各输入项或输出项进行类型、长度以及取 值范围进行验证，着 重验证是否对HTML或脚本代码进行了转义。 • 执行测试过程中也应对上述项进行检查。
Page 17
案例三 Web项目安全性测试
安全性测试案例分析
WEB的安全性测试主要从以下方面考虑： 1.SQL Injection(SQL注入) 2.Cross-site scritping(XSS):(跨站点脚本攻击) 3.Email Header Injection(邮件标头注入) 4.Directory Traversal(目录遍历) 5.exposed error messages(错误信息)
Page 15
测试结果-集群环境的服务器端性能-A
服务端资源占用情况绝对值变化不大，但CPU占用递增20%左右较为稳定
Page 16
问题
1）集群是否比单机环境效率高？ 2）单机与集群环境下，应用服务器与数据服务器资源利用 率如何？是否存在瓶颈？单机环境与集群环境相比，哪种资 源占用率较高，哪种资源占用率递增较快？ 3）此系统是否可以采用集群的方案？
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
第7章系统的测试
7.1系统的测试框架
在软件系统开发的各个环节都有可以产生问题，因此需要不断的进行测试。
目前，一种主流的思想认为任何系统开发后都存在各种各样的缺陷，而这些缺陷的存在是不可避免的。
测试的目的不是证明系统的准确性，而是为是尽可能的发现系统存在的问题，从而减少当系统交付客户后暴露出的问题，从而提升用户的体验、降低系统的开发、运行与维护成本。
软件测试[27-30]的方法很多。
在本系统中测试策略主要以时间为序，按目的展开测试。
具体测试框架如图7-1所示：
图7-1本系统测试的框架
软件测试贯穿软件工程的每个阶段，一般来讲单元测试对应系统开发中的模块、类、方法。
由于每个单元较小，最适合由开发人员自行测试。
由于不同的类、模块、包等由不同开发人员开发，在集成时需要进行集成测试，看在调用方面是否存在问题。
由于这一部分不与具体功能关联，所以测试规模不大。
在开发的各个阶段有单元测试、集成测试、系统测试与验收测试等不同的测试。
然而这四种测试的测试计划制定时间与其开展的时间正好相反。
测试计划的制定与测试工作的开展在时间上有较强的应对关系，相关情况如图7-2所示：
图7-2程序开发对应测试类型
7.2单元测试
就范围而言单元测试是软件测试是最小规模的一种。
单元测试只关注某个方法、类的内部处理细节，如顺序与路径等。
单元测试需要注意以下几点内容：1）测试目标单元的执行过程是否与预期一致。
2）单元测试需要关注测试目标内部的路径。
在有较多路径的情况下需要采用路径覆盖，使得尽可能多的路径被测试到。
如果忽略了一些非主要的分支路径，则这种隐患可能在系统运行时显露出来。
单元测试根据测试的目的，又有不同的分类等。
例如功能单元测试用于测试单元是否实现了预期的目标，逻辑单元测试用于了解被测试单元的逻辑是否合乎
要求，而集成单元测试则用于了解不同单元之间的相互调用情况。
在微软的集成开发环境中内容了NUnit单元测试工具，该工具能根据测试目标的名称、输入、输出等相关信息生成桩模块。
相关模块结构如下：[TestMethod]
public void TestMethod1(参数1，参数2，…..)
{
// 定义相关参数值
// 将期望值与运行结果进行比对
// 输出对比结果。
}
在提供了桩模块后系统还会生成驱动模块，只需要驱动模块中提供输入参数与期望值，系统会自动进行批量测试。
在得知NUnit的工作原理后，只需要提供测试用例即可进行单元测试。
此处测试用例的编写有一定的依据，在本系统中这些依所为为需求分析时的数据字典、数据流图等。
以下列举出系统中常用的几个测试用例。
表7-1 用户入职时间合法性检查用例
（2）表7-2所示为用户邮箱测试用例。
（3）白盒测试反馈
此处的白盒测试主要用于测试小范围的代码段或简单的逻辑片段，如表 5.3为白盒测试用例。
表7-3白盒测试用例
（4）其他功能模块测试
表6-4所示为用户ID的测试用例。
表7-5为用户职位测试用例，职位由不超过10位的英文、中文字符组成，不能与一些保留字相同。
表7-5 用户职位测试用例
7.3系统的集成测试
在开发时，由于不同开发人员在沟通、理解方面的偏差可能造成系统不同接口互不配置，从而导致系统集成过程无法成功的情况。
因此需要使用集成测试来达到这一目标。
这一目标的时间安排在编码之后。
该测试只需关注能否衔接而无需关注安全、性能等问题。
本系统中集成测试采用自下而上的方式进行。
即从最下层的模块入手进行模块的组合。
当对第N层进行测试时，由于第N-1层已经完成了集成并通过了测试，所以就不用再写桩模块。
这在一定程度上提高了系统测试的效率。
选择这种集成方式，管理方便、测试人员能较好地锁定软件故障所在位置。
集成测试中的主要步骤：
1）制定审核测试计划
2）制定和审核测试用例
3）进行测试活动
4）书写测试报告
具体细节见表7-6:
由于项目的规则，集成测试的范围很大，下文仅以人员管理为出发点进行举例说明。
其流程如图7-3所示，测试用例如表7-7所示。
从表7-7的测试结果可以得知，本系统在集成测试上没有发现明显问题。
7.4系统测试
性能测试主要是模拟现实中用户的数量来实现对系统的访问，使得在系统高负荷运行的情况下找出系统的处理能力及存在的瓶胫，以便加强系统的健壮性。
作为一款B/S结构的应用程序，由于其体系结构的特点，在发布后主要的压力集中于服务器端，因此对于这一类型的应用程序，性能测试特别重要。
在本应用中，为模拟客户的最终运行环境，设置测试的系统拓扑结构如下：
图7-4 系统测试拓扑图
在上图中，将用户分为内网与外网用户，并需要相关设备如下：
在测试时由之前选定的测试人员在各自的联网计算机上运行性能测试工具LoadRunner。
每个LoadRunner运行实例各开启一定数量的系统进程，模拟3000用户同时在线的负荷，基本与系统使用最高峰值的负荷。
测试的主要目的是模拟系统在强大的运行负荷下是否能够正常运行，功能是否完整，其结果如下：
表7-9 压力测试数据表
从上面的测试结果可以看出，系统在最多900人同时使用情况下，响应速度很快，用户可以快速完成相关操作。
并发用户数在900-1200人的情况下，系统相应较快，在1200-1500人同时使用的情况下，系统速度中等，此时服务器负荷较大，但是不影响用户正常使用；超过2000人同时使用时，系统负荷较为严重，用户操作时间大幅度延长，但系统功能依旧稳定。
超过2500人并发操作时，系统响应速度很慢，这是用户操作可能不流畅，且不能保证系统能够一次完成用户所需的功能；超过3000人时，某些客户端出现了响应超时的现象。
但对于本系统而言，上述的数字已经完全能支撑本系统的运行。
安装时需要考虑各种异常情况，这些异常情况有：数据库版本不匹配、Web 服务器设置问题、访问权限不足、文件太大不符操作系统格式、硬盘空间不足等。
是否有正确的配置文件与完整的安装手册也是安装测试所需要关注的内容。
表7-10给出了安装测试的用例。
上面给出了安装测试时需要考虑的部分内容。
能够应对普通情况下的安装情况。
但由于客户环境千差万别，在系统安全程度要求较高的时候还需要进行更为严格的安装测试。
7.5本章小结
本章对国土资源监察管理信息系统进行了测试。
该测试以软件工程的过程为向导，以单元测试、集成测试、系统测试为例谈了本系统中的测试策略并给出了少量的测试用例。