大数据开放平台系统测试方案（学习模板）

数据开放系统测试方案版本编号*变化状态简要说明变更人变更日期批准人批准日期V1.0新增梁凤梅2020/4/26邓波2020/4/26TOC\o"1-3"\h\u152991.前言 452531.1.编写目的 4295311.2.术语描述 483091.3.测试依据和参考 5280401.3.1.测试依据 5137241.3.2.参考资料 525972.项目需求 656812.1.系统功能需求 6259303.测试目标 9117043.1.功能测试 9176513.2.性能测试 9144943.3.应用安全检测 9206604.系统调研 945134.1.业务调研 9194544.2.架构调研 1070164.3.性能指标调研 1040534.3.1.请求响应指标 10122884.3.2.资源使用率 1099505.测试安排 1133485.1.测试环境 11182225.2.测试工具 11110396.测试设计 12325796.1.功能测试设计 1279086.1.1.测试内容 12225376.1.2.测试技术 12245606.1.3.测试方法 12317176.2.性能测试设计 16255946.2.1.测试内容 16130696.2.2.测试策略 16159536.2.3.测试用例 19183666.3.安全测试设计 21111996.3.1.测试内容 21146086.3.2.测试方法 22303507.测试计划 2265188.风险分析 22前言编写目的本方案描述了数据开放台（以下简称“本项目”）的功能、性能及安全测试的需求、测试目标、测试内容、测试策略和测试规划，用于指导该系统的系统测试工作。术语描述类型术语描述功能测试测试及时率测试人员执行测试任务及时程度的统计，避免消极延期测试任务的执行。按时间段统计。按月统计：当月在“期望测试结束时间”内完成的测试任务数量/“期望测试结束时间”在当月的测试任务总数*100%测试完成率测试人员在某时间段内完成测试任务的比例，避免消极延期测试任务的执行。按时间段统计。按月统计：当月已完成的“期望测试结束时间”内测试任务数量/“期望测试结束时间”在当月内的测试任务数量*100%用例评审率测试用例经过评审的比例，在一定程度上可保证测试的质量。统计公式：经过评审的测试用例模块的数量/测试用例模块总数量*100%首轮用例执行率评估产品首次提交测试时的完整程度，执行率越高表明该产品的功能越完整，越低表明该产品有较多功能点没有实现或无法验证。按模块进行统计。统计公式：首轮测试用例执行数/测试用例总数*100%首轮用例通过率评估产品首次提交测试时程序的基础质量，节省测试工作量和测试成本，同时也是评估开发能力的一个侧面指标。按模块进行统计。统计公式：首轮测试用例通过数/首轮测试执行用例数*100%回归测试缺陷修复率产品提交缺陷修复测试时，衡量缺陷修复质量的高低。按测试记录表进行统计。统计公式：当次缺陷关闭数量/当次缺陷提交数量*100%性能测试性能测试是指通过模拟生产运行的业务压力和使用场景组合，测试被测系统性能是否满足生产要求负载测试是性能测试的一种类型，通常是指让被测系统在其能忍受的压力的极限范围之内连续运行，来测试系统的稳定性。稳定性测试也叫可靠性测试，是性能测试的一种类型，是指连续运行被测系统，检查系统运行时的稳定程度压力测试是性能测试的一种类型，通常是指持续不断地给被测系统增加压力，直到将被测系统压跨为止，用来测试系统所能承受的最大压力并发测试是性能测试的一种类型，通常是指多用户并发访问下测试系统的性能表现性能指标描述服务器或应用系统性能的一些指标，如CPU利用率、内存利用率、系统响应时间等系统响应时间是指系统对请求作出响应所需要的时间吞吐量是指单位时间内流经被测系统的数据流量，一般吞吐量越大，系统单位时间内处理的数据就越多，系统的负载能力也越强并发是指多个同时发生的操作。需要注意的是，并行和并发不是一个概念，并发是同时发生，并行是同步运行点击率每秒钟向服务器提交的HTTP请求数TPS指单位时间内系统处理的业务量思考时间指每个请求之间的时间间隔安全性测试安全性测试是在IT软件产品的生命周期中，特别是产品开发基本完成到发布阶段，对产品进行检验以验证产品符合安全需求定义和产品质量标准的过程测试依据和参考测试依据《GB/T25000.51-2010软件工程软件产品质量要求与评价（SQuaRE）商业现货（COTS）软件产品的质量要求和测试细则》《需求规格说明书》备注：需求规格说明说目前缺失参考资料GB/T15532-2008计算机软件测试规范GB/T9386-2008计算机软件测试文档编制规范 项目需求验证数据开放台的功能是否正常可用，同时评估系统处理能力及系统应用安全是否满足用户需求，是否存在明显的安全隐患，并为系统升级改造提供参考信息，故对该系统的功能、性能及安全进行测试。本次测试按照《需求规格说明书》中的需求及系统目前实际部署现状测试约束，依据《软件工程软件产品质量要求与评价（SQuaRE）商业现货（COTS）软件产品的质量要求和测试细则》对本系统进行测试。系统功能需求子系统名称功能模块（一级）功能模块（二级）功能模块（三级）测试目标对本系统的功能、性能及应用安全进行检测，测试目标主要包括：功能测试检测系统功能模块设计是否满足用户业务需求，功能能否正常使用，人机交互界面是否注重操作易用便捷性，本系统与其他系统及台数据交换是否正常。性能测试检测系统当前的性能状况，评估系统在现有环境下的用户数量、系统响应时间等指标。在性能测试过程中，检测系统业务执行情况及服务器系统资源的使用情况。结合性能测试结果，综合评估系统的性能状况，为今后系统台的维护、性能调优等提供客观数据依据。应用安全检测检测系统在输入验证、身份鉴别、访问控制、日志安全审计、会话管理、软件容错、漏洞扫描等应用系统安全上是否存在明显的漏洞。系统调研业务调研（1）系统概况本项目依托信息技术建立XX数据开放台，顺应国家以及省XX加强务信息资源的开发利用，加强务信息共享，规范务信息资源社会化增值开发利用工作，合理规划务信息的采集工作，加强务信息资源管理的思路和要求。以前期倒逼、后期需求为导向，形成XX数据资源开放的顺向机制。目前智慧城XX已经建设了大数据台项目，形成了一套务大数据的数据标准体系、数据共享交换台，在此基础上，数据开放台将进一步整合的各类数据，建设XX数据开放台和XX数据开放管理系统，利用大数据思维和技术将整合后的各部门的数据和业务专题数据，以多样化数据格式面向公众开放。本项目主要包含XX数据开放台（门户）、XX数据开放管理系统两个系统。XX数据开放台（门户）主要包括门户首页、数据、应用、资讯、互动、个人中心六大业务模块，约47项功能。数据开放管理系统包括后台首页、系统管理、Swagger管理、工作流程、运营管理、应用管理、资源管理、问卷调查、互动管理、用户管理、任务管理、网站管理、数据需求管理、特殊数据管理十三大业务模块，约61下项功能。用户群里主要是需要获取XX各部门数据的个体或者单位、需要利用XX台宣传产品的个体或者单位、需要将数据面向公众开放的个体或者单位、对XX各部门数据感兴趣的个体或者单位、需要利用XX台宣传产品的个体或者单位。（2）核心业务分析本项目核心功能如下：

1、实现数据提供部门可以通过多元化的途径将本单位的数据利用数据开放台可直面公众；

2、实现对XX数据感兴趣的人可以通过多元化的途径查看获取XX的开放数据；

4、实现数据管理部门对XX开放数据的发布申请等进行管理；

5、实现对数据开放门户的数据使用的统计分析；XX数据开放台（门户）面向公众，访问量大。XX数据开放管理系统主要是运维人员、数据管理单位使用，访问量较少。综上可知，使用频繁、数据量大，可能造成较大访问压力的为XX数据开放台（门户），因此该系统作为性能测试的重点考察对象。架构调研本系统为B/S结构，采用集中式部署，在正式运行时由3台服务器部署组成，并放置在互联网、务外网中供用户访问。性能指标调研请求响应指标由于本项目目前并未完成需求规格说明书输出，性能指标主要依据业务通用标准，只做测试暂时性参考。分类系统最长响应时间*适用场景简单操作类≤3秒信息录入等简单操作核心业务功能≤3秒登录、保存、提交等操作复杂查询类≤10秒报表统计等复杂操作资源使用率结合信息系统运行维护业界通用标准和云计算有限公司研发中心要求，确定本系统的资源利用率指标如下：分类指标要求适用场景应用服务器CPU使用率≤75%使用频度高和业务数据计算量大的业务场景内存使用率<70%数据库服务器CPU使用率≤75%使用频度高和业务数据计算量大的业务场景内存使用率<70%中间件服务器CPU使用率≤75%使用频度高和业务数据计算量大的业务场景内存使用率<70%测试安排测试环境本次测试在测试环境执行，以下是测试环境的软、硬件配置：序号用途硬件台配置1应用服务器虚拟机:CPU：32核内存：64核硬盘：2T2数据库服务器虚拟机:CPU：32核内存：64核硬盘：2T3文件服务器虚拟机:CPU：32核内存：64核硬盘：2T测试工具序号工具名称用途1HPApplicationLifecycleManagement11.00（简称ALM）用于测试用例管理、测试集管理及缺陷管理2Fiddler请求分析3LoadRunner11.0脚本开发、测试执行、测试分析5Appscan安全漏洞扫描测试设计功能测试设计测试内容本次功能测试从系统产品的界面、架构出发，按照需求规格说明书对系统各项功能点进行验证，根据功能测试用例，逐项测试，检测系统主体流程是否正常可用，是否达到用户要求的功能，系统界面是否清晰美观，菜单及功能按钮操作是否便捷灵活，对于异常输入是否有提示以及容错处理等。测试技术功能测试主要采用黑盒测试技术。常见的黑盒测试技术方法有等价类划分法、边界值分析法、错误推测法、因果图法和综合策略等。等价类划分法把所有可能的输入数据，即程序的输入域划分成若干部分，然后从每个子集中选取少数具有代表性的数据作为测试用例。等价类划分有两种不同的情况：有效等价类和无效等价类。边界值分析法边界值分析方法是对等价类划分方法的补充。使用边界值分析法方设计测试用例，应先确定边界情况。通常输入和输出等价类的边界，就是应着重测试边界的情况。其次，应当选取正好等于、刚刚大于、或刚刚小于边界的值作为测试数据。错误推断法基于经验和直觉推测程序中所有可能存在的各种错误，有针对性地设计测试用例。例如，设计一些非法、错误、不正确和垃圾数据作为输入。因果图法因果图法是一种适合于描述对于多种输入条件组合的测试方法，根据输入条件的组合、约束关系和输出条件的因果关系，分析输入条件的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件涉及的各种组合情况。因果图法一般和判定表结合使用，通过映射同时发生相互影响的多个输入来确定判定条件。因果图法最终生成的就是判定表，它适合于检查程序输入条件的各种组合情况。采用因果图法能帮助我们按照一定的步骤选择一组高效的测试用例，同时，还能指出程序规范中存在什么问题，鉴别和制作因果图。因果图法着重分析输入条件的各种组合，每种组合条件就是“因”，它必然有一个输出的结果，这就是“果”。综合策略综合策略即是同时运用多种测试技术执行测试。测试方法常见的功能测试方法主要有：界面测试、各类编辑页面测试、常用功能键测试、工作流测试、业务测试、易用性测试、统一性测试等。界面测试测试界面设计是否合理、简洁、美观，操作是否方便；

功能键、数据项信息是否齐全；确认系统中同一功能名称是否统一；设计样式、风格是否与系统其它模块统一；

确认页面内所有字段名称显示风格是否统一；滚动条的应用是否正确；多窗体界面是否能完全显示数据和按钮等。新增页面及功能测试

各字段输入正确的信息值保存，确认系统是否可以正确完成新增操作；

进入添加界面不输入任何信息值，单击“保存”功能按钮，系统应该给出某个不允许为空字段的提示信息；

不允许为空的字段前面加上*作为标记；

编码/编号字段不允许输入中文及特殊字符，否则系统应该给出相应的提示信息；

测试编码/编号字段不允许重复，否则系统应该给出相应的提示信息；确认字段是否已做长度限制，如果输入值超出长度范围，那么在保存时系统应该给出提示信息；

非法测试，如：校验数值型字段输入非数值，保存时系统是否给出相应的提示信息；

边界测试，如：确认数值型字段的边界值（如：有效值为„0-100‟整数，那么输入-1

或101

保存时系统应该给出相应的提示信息；输入值为0、100

系统应该能正确保存信

息值；输入0

到100

内的整数值系统应该正确保存信息值）；精确值测试，测试小数位数是否在定义的长度内；字段精确值是否正确（四舍五入否）。

根据实际情况测试名称字段是否具有唯一性，（一般情况下名称是不允许重复的，具体

问题具体分析），否则系统应该给出相应的提示信息；

确认各字段名称书写是否正确；

确认特殊格式的字段是否已做标准格式的限制（如：电子邮件、邮编等）；

测试如果某字段信息值是从另一个模块中选择输入的，那么需要确认其它相关联字段的信息值是否也相应的正确的自动带入，并且这些字段应该都是只读的；创建人/编辑人、发布人、创建时间、创建人字段应该设为只读的，而且此类字段值应该

默认当前操作人的姓名；

如果某个字段可以点选输入多个信息值，那么测试该字段是否接受，并保存了点选输入的多个信息值；

对于多选字段，测试是否具有记忆上次选择值并已验重；

引用其它模块的字段信息值的字段长度是否与被引用模块相应字段长度一致。多行添加编辑页面测试测试插入单行是否可以正确保存相应字段值；

插入/添加多行测试是否对多行相应字段空值是否进行校验（通常如果有多条空行保

存时系统会弹出XXX

字段不允许重复提示信息，要求仅对空行不保存即可，不需

要提示的）；

多行添加，测试如果某个字段值太长保存后是否会导致界面混乱；

保存保存新添加的多行记录信息；

保存勾选待删除记录，单击此功能按钮系统正确完成删除操作

；插入空行单击此功能按钮系统插入一条空的记录行。

主子表编辑页面

测试只有保存主表信息后才能维护子表信息，否则系统应该给出相应的提示信息；

如果子表信息是否需要维护取决于主表中的某个字段值，那么请确认主表中相关联

的字段取值是否对应子表的存在（主表中较常用的取决子表存在的字段是“底层否”，

如果与底层相关联一般只有在底层才能维护其子表信息）；

如果子表中有继承主表信息，那么确认继承的信息是否完全正确。左树右表的测试：添加、修改、删除保存后目录树信息是否要自动刷新；

添加界面：测试继承上级信息的字段（如：上级机构名称、上级机构编码等）值系

统是否自动生成，而且信息值是否是只读的；

测试是底层节点才可以进行添加操作，还是非底层节点才可以进行添加操作（业务

测试）；

含有子结点信息的当前结点是不允许修改为“底层”结点的选择按钮可以相互切换

；为操作方便，建议“有效否”的字段值添加时默认为“有效”。常用功能键的功能测试：

保存所有编辑页面如果未输入任何信息值而单击“保存”，系统应该给出“XXX

字

段不允许为空”的提示信息；

保存如果某字段输入值有错误或超出长度范围，那么单击“保存”按钮时，系统应

该给出相应的提示信息；

保存输入相关信息单击“保存”后，建议系统给出“保存成功”提示信息；保存测试新增/修改信息保存后，信息列表是否自动刷新

；浏览测试该功能键功能是否已经正确实现，单击此按钮系统应该弹出文件选择页面，

并且可以选择输入相关附件；

上传附件测试上传功能已经正确实现，确认上传的附件在界面相应位置是否显示；下载测试下载功能已经正确实现（可以将上传到服务器的附件下载的本地相应位置）；重新上传保存操作后上传功能按钮名称应该自动变为“重新上传”，并且可以重新上

传附件

；发布测试该功能键功能已经正确实现，单击些功能按钮系统完成发布操作，相应的

信息状态变为“已发布”，发布人、发布时间系统自动生成或已经正确保存；

取消发布测试该功能键功能是否已经正确实现，单击此功能按钮系统完成取消发布

功能，相应信息状态变为“未发布”；关闭单击此功能按钮系统将关闭当前页面；查询单击查询功能按钮，系统按钮输入查询条件进行模糊查询；

删除未勾选待删除记录单击此按钮系统弹出相应提示信息；正常情况下系统删除所选

记录；

选择勾选待选记录，单击此按钮系统完成选择操作；单击选择超链接功能按钮系统完

成选择操作

；修改页面测试：确认各字段是否已经保存了添加界面输入的信息值；

确认各字段所保存/取到的信息值，是否与添加界面输入的相关信息值完全匹配；

确认字段是否保存修改后的信息值；

修改界面的字段长度是否与添加界面相应字段长度一致；

修改界面字段命名是否与新增界面相应字段命名完全一致；管理/维护页面测试：

测试界面整体设计合理，操作方便，尤其是查询条件排放是否整齐，操作是否方便；功能按钮顺序设计是否合理，操作是否方便（一般顺序为查询、添加、删除）；

测试信息列表是否有一定的排序规则；测试维护界面各功能按钮功能是否已经正确实现；测试系统内不同模块相同的查询条件值输入方式是否统一

；测试各查询条件是否起作用，即输入查询条件值可以查到相应查询结果；

测试可以手动输入查询条件什的查询条件支持全部模糊查询；；测试信息列表中显示的信息（字段）是否齐全，是否方便查询/查看；测试信息列表中信息值显示格式是否统一

；测试列表各字段信息值是否有折行显示，要求所有字段不允许折行显示；测试是否提供翻页查询功能，并且功能是否已经正确实现；

测试信息列表中的链接数据是否正确链接到相应信息界面；

工作流

测试流程启动后是否严格按照所选择的流程模板自动流转

；测试在流程流转过程中相关人员是否可以维护流程步骤

；测试流程流转过程中，所有操作按钮是否已完全按需求实现；

测试在流程在流转过程中是否已作权限限制（如：操作按钮的使用权限；附件编辑，

查看权限，信息的编辑、相看权限）；

测试流程跟踪/历史审核信息是否正确，记录是否齐全；

如果当前办理/审批阶段是以组的形式存在的，那么需要根据需求及流程模板的定

义，测试是需要组内成员全部办理/审批完成，流程流转到下一流程阶段，还是只需

组内一个成员办理/审批通过就可以流转到下一个流程阶段；

跟踪测试，跟踪一条数据的流程，保证数据的正确性；业务测试

测试某些特殊字段的选择值是否已经升效；

测试年度信息时，一年只能有一条信息，否则系统应该给出“该年度信息已经存在”

提示信息

；测试年度信息的子表信息：a)同一年度内同一子表内的信息值不允许有重复（编号、

名称）信息，否则系统应该给出相应的提示信息。b)不同年度内同子表内的信息值

是可以有重复信息的

；某些信息只归属于底层信息，在测试时注意当前位置是否是底层；

如果当前结点含有子结点信息，那么当前结点信息是不允许删除，否则系统应该给

出相应的提示信息

；被其它模块引用的信息是不允许删除的；含有子结点信息的当前结点是不允许修改为“底层”结点的

；只有底层结点才能继续维护其子表信息否则应该将其子表信息隐藏

；主模块是否可以正确调用子模块信息；

测试确认主模块调用子模块信息时，被引用的信息是完全对应并且无丢失；

测试被引用的信息是否可以进行修改操作（通常作为基本信息被引用时是不允许进

行修改操作的；而在工作流程中被引用/调用的信息是可以进行修改操作的）；

工作流程是否严格按需求中的业务流程流转；

工作流程中权限分配是否正确；

工作流中必须严格按分配的权限操作

；测试仅限于某个阶段才能进行的操作，在其它阶段是否禁止或无此操作按钮

；根据需求确认，如果当前审核步骤已经审核结束，需要经过某个操作激活下一审核

步骤还是系统自动流转到下一审核步骤

；易用性测试依据易用性测试规范对功能的易用性进行检查。统一性测试

所有弹出窗口居中显示；

所有页面设计要求饱和，但尽量不要有横纵滚动条；

页面设计风格要统一；

要求编辑界面、住息列表中、错误提示信息、查询条件中的字段名称完全相同；

添加/修改保存后，添加/修改界面是否自动关闭要求统一；

一个系统中相同功能的按钮名称要统一；

底层结点不允许添加子结点信息，那么单击底层结点时，“添加”功能按钮设为不可

用的，还是系统弹出相应的提示信息，在一个系统中要求统一；

同一个功能按钮，不同模块相同的错误提示信息是否统一；

不同模块相同字段值的输入方式是否统一；

性能测试设计测试内容根据系统调研内容制定本次性能测试内容：负载测试：对选定的测试对象进行混合业务场景性能并发测试，评估系统在正常负载下的性能表现。通过测试工具模拟用户访问系统各个主要功能的使用场景，使整个系统承受的负载压力为系统日常负载，测试连续执行30分钟。压力测试：对选定的测试对象进行单场景的独立业务性能并发测试，评估系统在现有环境下可承载的并发访问量，分析系统可能存在的性能瓶颈。通过测试工具模拟用户访问，系统中数据量产生较大、使用较频繁或用户较关注的功能，并采取阶梯式加压的方式，直至系统资源占用情况达到系统资源占用临界阀值或性能测试过程中出现事务执行失败。稳定性测试：对选定的测试对象进行混合业务场景性能并发测试，评估系统在现有环境下长时间运行时的稳定性，考察服务器的资源是否存在瓶颈。通过测试工具模拟用户访问系统各个主要功能的使用场景，使整个系统承受的负载压力为系统日常负载，测试连续执行8个小时。测试策略为真实反映系统在实际环境下的性能响应，则选择在上线前在生产环境执行测试。执行性能测试再正式上线。使用LoadRunner性能测试工具录制脚本、执行场景和分析测试结果，确保能真实有效地模拟用户的操作场景。使用Loadrunner的监控工具监控测试期间服务器的硬件资源使用情况；使用Windows自带的性能计数器监控测试期间服务器的硬件资源使用情况；使用服务器操作系统自带的监控工具（sar、vmstat）监控服务器的系统资源使用情况。根据系统调研结果及性能测试行业内常规做法，制定以下性能测试对象选取原则：产生数据量较大、或使用率较高、或本系统重点功能的，为本次性能测试的重点，故需执行基准测试、单业务场景的压力测试及混合业务场景的稳定性测试。数据量产生不大，或使用率不高，但是本系统主要功能的，无需执行单业务场景压力测试，但需执行基准测试和混合业务场景的稳定性测试。程序设计相同、使用场景类似的模块选取其中任意一个模块执行测试即可，但是测试施加的负载压力需对应翻倍。数据量产生很小、使用率较低，为系统基础设置功能的，可不作为性能测试考察对象。根据上述测试对象选取原则，制定以下负载策略：序

号模块使用频率测试内容用户范围及数量负载策略典型操作日常负载计算压力测试负载计算稳定性测试负载计算1门户登录频繁√负载测试

√压力测试

√稳定性测试全网用户系统未正式上线运维，暂无负载计算依据，暂按TPS需大于1000S指标做测试依据。使用阶梯加压方式执行，分别使用20、40、60、80、100并发用户数执行使用0.5倍的日常负载TPS的并发用户数执行场景2门户注册频繁负载测试

√压力测试

√稳定性测试全网用户系统未正式上线运维，暂无负载计算依据，暂按TPS需大于1000/S指标做测试依据。使用阶梯加压方式执行，分别使用20、40、60、80、100并发用户数执行使用0.5倍的日常负载TPS的并发用户数执行场景3门户首页频繁√负载测试

√压力测试

√稳定性测试全网用户系统未正式上线运维，暂无负载计算依据，暂按TPS需大于1000/S指标做测试依据。同上同上4数据集访问频繁√负载测试

√压力测试

√稳定性测试全网用户系统未正式上线运维，暂无负载计算依据，暂按TPS需大于1000/S指标做测试依据。同上同上5API接口频繁√负载测试

√压力测试

√稳定性测试全网用户系统未正式上线运维，暂无负载计算依据，暂按TPS需大于1000/S指标做测试依据。同上同上6资讯频繁√负载测试

√压力测试

√稳定性测试全网用户系统未正式上线运维，暂无负载计算依据，暂按TPS需大于1000/S指标做测试依据。同上同上7XX数据开放管理系统（后台）登录频繁√负载测试

√压力测试

√稳定性测试运维人员、数据管理单位系统未正式上线运维，暂无负载计算依据，暂按TPS需大于10/S指标做测试依据。同上同上8XX数据开放管理系统首页统计分析频繁√负载测试

√压力测试

√稳定性测试运维人员、数据管理单位系统未正式上线运维，暂无负载计算依据，暂按TPS需大于10/S指标做测试依据。同上同上测试用例负载测试测试需求对选定的测试对象进行混合业务场景性能并发测试，评估系统在正常负载下的性能表现。通过测试工具模拟用户访问系统各个主要功能的使用场景，使整个系统承受的负载压力为系统日常负载的2倍，测试连续执行30分钟。测试数据/前置条件超时时间：设置响应超时=120秒。即服务器若在2分钟内没有返回响应数据给客户端，则判断该请求超时。测试步骤1、使用负载测试工具LoadRunnerVUG录制以下业务操作，生成虚拟用户脚本，并进行调试：2、在LoadRunner监控中心模拟多个用户访问本系统，执行上述典型业务操作一段时间，随后陆续注销退出系统。具体测试场景设计如下：=1\*GB3①负载测试时间=30分钟；②调整在线用户和思考时间，使各业务功能模块均达到目标TPS；③设置测试工具加载与注销虚拟用户的方式：每10秒登录5个用户；每10秒注销5个用户；3、在负载测试期间，使用Loadrunner的监控工具进行监控服务器的WINDOWS资源监控器、事务响应时间监控器、点击率监控器，每秒HTTP响应数监控器；预期效果负载测试期间系统能正常运行和使用，服务器对客户端发出的业务请求的响应时间在5秒以内。压力测试测试需求对选定的测试对象进行单场景的独立业务性能并发测试，评估系统在现有环境下可承载的并发访问量，分析系统可能存在的性能瓶颈。通过测试工具模拟用户访问，系统中数据量产生较大、使用较频繁或用户较关注的功能，并采取阶梯式加压的方式，直至系统资源占用情况达到系统资源占用临界阀值或性能测试过程中出现事务执行失败。测试数据xx年的基础数据，xx个测试用户前置条件超时时间：设置响应超时=120秒。即服务器若在2分钟内没有返回响应数据给客户端，则判断该请求超时。测试步骤1、使用负载测试工具LoadRunnerVUG录制以下业务操作，生成虚拟用户脚本，并进行调试：2、在LoadRunner监控中心模拟多个用户访问本系统，执行上述典型业务操作一段时间，随后陆续注销退出系统。具体测试场景设计如下：=1\*GB3①阶梯加压用户设置：以20的倍数加压，即20、40、60、80、100……；②每阶梯压力测试时间=30分钟；③设置测试工具加载与注销虚拟用户的方式：每30分钟登录xx个用户；每10秒注销5个用户；3、在压力测试期间，使用Loadrunner的监控工具进行监控服务器的WINDOWS资源监控器、事务响应时间监控器、点击率监控器，每秒HTTP响应数监控器；预期效果压力测试期间系统能正常运行和使用，事务成功通过率达100%。稳定性测试测试需求对选定的测试对象进行混合业务场景性能并发测试，评估系统在现有环境下长时间运行时的稳定性，考察服务器的资源是否存在瓶颈。通过测试工具模拟用户访问系统各个主要功能的使用场景，使整个系统承受的负载压力为系统日常负载，测试连续执行8个小时。测试数据xx年的基础数据，xx个测试用户前置条件超时时间：设置响应超时=120秒。即服务器若在2分钟内没有返回响应数据给客户端，则判断该