数据开放平台和数据应用平台-测试方案

1、沧州智慧城市建设办公室城市大数据中心建设项目-数据开放平台和数据应用平台测试方案作者潘燕辉最后修改日期2018年6月5日审核 人张广良最后审批日期2018年6月5日批准 人张广良最后批准日期2018年6月5日3 / 9目录1 引言 31.1. 目的 31.2. 适用范围 31.3. 参考文档 31.4. 预期读者 32 测试范围与职责 32.1. 测试目标 32.2. 测试范围 33 测试环镜 43.1. 测试环境PAAS拓扑43.2. 硬件环境说明诉讼 43.3. 软件环境说明 54 测试策略 54.1. 策略概述 54.2. 用例设计策略 54.3. 测试轮次考虑 64.4. 测试方法 6

2、4.4.1 产品需求测试方法 64.4.2 产品架构测试方法 64.4.3 产品特性测试方法 65 测试风险 76 限制条件 76.1. 进入准则 76.2. 退出准则 76.3. 再启动准则 76.4. 结束准则 76.5. 回归测试 87 测试资源 87.1. 人力资源 87.2. 测试工具 88 测试进度 81引言1.1. 目的通过界定测试范围，明确测试环境，测试策略，测试风险，帮助测试人员更好地开展 测试工作，帮助产品组其他成员了解系统测试工作。1.2. 适用范围适用于数据开放门户以及数据应用管理平台的系统测试活动。1.3. 参考文档大沧州市智慧城市大数据中心-需求规格说明书（终稿）1

3、.4. 预期读者平台产品组人员，包括：测试人员，开发人员等。平台产品交付组项目人员。平台产品质量评审人员。2测试范围与职责2.1 测试目标验证数据开放门户以及数据应用管理平台是否符合沧州大数据中心需求设计文档。2.2 测试范围数据开放门户以及数据应用管理平台的主要功能测试数据开放门户以及数据应用管理平台的安装部署测试3测试环镜3.1 测试环境PAASC扑3.2 硬件环境说明诉讼IP地址用途操作系统服务器配置是否虚 拟机10.1.155.12110.1.153.10510.1.158.29客户端Windowsxp2C4G 300G否10.126.3.161PAAS1,mysql,redi s,

4、monitorCentOS Linuxrelease7.2.151124C16G900G否10.126.3.163PAAS2,ELK, Svn,gitlab,Jenki nsCentOS Linuxrelease7.2.151124C64G900G否10.1.108.132Cluster2CentOS Linuxrelease 7.2.15112C2G50G否10.126.3.86Cluster2CentOS Linuxrelease 7.2.151124C16G 200G否10.1.159.181Cluster2CentOS Linux release24C128G 1T否7.2.15111

5、0.1.108.158Cluster2CentOS Linuxrelease 7.2.15112C3G50G否10.1.155.110ClusterCentOS Linuxrelease 7.2.15112C8G100G是3.3 软件环境说明软件名称软件版本软件用途Jdk1.8平台基础运行环境Mysql5.6以上数据库服务Nginx1.10以上集群所需服务Gitlab8.0.2持续集成使用代码仓库Redis3.2.1RC,存储应用访问信息,monitor组件使 用Elk , logstash1.7.1查找应用日志Logstash1.5.4采集应用日志Mongodb3.4.4存储应用日志dock

6、er1.11.2以上应用隔离使用4测试策略4.1 策略概述为了达到全面覆盖产品功能的测试要求，考虑从多个维度设计测试活动。它们分别是：产品需求维度，产品架构维度，产品特性维度。产品需求维度重点考察运营管理平台的功能实现与产品需求原始描述的符合程度。主要包括需求说明书中的功能验证，用户使用场景的模拟等。产品架构维度重点考察运营管理平台所采用的架构能否满足用户需求。主要包括对外开放的资源管理，内容运营，运营统计等。产品特性维度主要包括功能性，可靠性，易用性，效率，可维护性，可移植性。4.2 用例设计策略针对产品需求的用例设计采用模块，集成，场景描述的分层设计策略。针对产品架构的用例设计采用常规策略

7、。针对产品特性的用例设计采用场景描述策略。无论策略为何，均要保证纳入到测试范围的需求功能点（对应到需求规格说明书中有需5 / 9求编号的功能）至少被用例覆盖一次。4.3 测试轮次考虑系统测试将分阶段完成，通常情况下一个版本安排一个轮次的测试。在人力和时间受限的情况下， 多轮测试结束时应保证针对产品需求的用例至少被执行 遍。4.4 测试方法4.4.1 产品需求测试方法黑盒测试：对于配置相关的功能，通过实际界面与后台操作，验证系统后台处理是否能够满足需求。对于控制相关的功能，通过实际与模拟操作，验证系统控制是否能够满足需求。对于弹性相关的功能，通过一定的压力模拟，验证系统的弹性是否能够满足需求。对

8、于展现相关的功能，通过实际与模拟操作，验证系统前台展现是否能够满足需求。4.4.2 产品架构测试方法白盒测试：对于功能功能，运营管理平台对外提供的功能，需要进行白盒测试。灰盒测试，安装部署测试：对于负载均衡功能，通过实际与模拟操作，验证系统负载均衡的有效性。4.4.3 产品特性测试方法黑盒测试：对于功能性中的隐含要求，互操作性（ CONTAINER功能进行验证；对于可靠性中的成熟性，容错性和易恢复性进行验证；对于易用性中的易学性，易操作性进行验证。安装部署（包括升级）测试：对于可维护性中的稳定性进行验证；对于可移植性中的适应性（OS DB, JDK,浏览器），易安装型，共存性，易替换性进行 验

9、证。兼容性测试：对于可移植性中的适应性（Browser）进行验证。安全测试：验证只有具有系统访问权限的用户才能访问系统，以及通过渗透测试验证系统无安全漏洞 容量测试：对于大量数据对于系统的影响进行测试。强度测试：对于平台针对资源（内存、硬盘）敏感性进行测试。性能测试：对于系统在大流量的数据与多用户操作时软件性能的稳定性进行测试 说明：产品效率特性测试将主要由产品性能测试方案加以描述。5测试风险风险 编P风险描述风险发生可 能性 （高、中、 低）风险的影 响程度 （高、中、 低）责任人规避方法1文档更新不及时2版本更迭快3功能调整4测试时间短5测试环境被占用6限制条件6.1 进入准则测试方案与用

10、例通过评审；版本达到送测标准：提供送测清单，新增与修改功能通过开发人员自测。冒烟测试通过。6.2 退出准则测试版本出现严重问题，测试无法继续。测试按计划完成。6.3 再启动准则影响测试的严重问题被修复，并生成新的待测试版本。6.4 结束准则测试按计划完成，或者严重级别以上的错误个数为零、遗留问题的个数不超过一般问题6.5 回归测试在运营管理平台的测试中，由于人力和时间受限，以往版本所发现的问题验证，以及产品需求测试用例将被分配在多轮测试中执行。最后一轮的全回归测试，仅安排作测试场景的验证。7测试资源7.1人力资源角色测试人员需求具体职责测试工程师41名测试工程师负责制定测试方案、测试计划及测试

11、用例完善2名测试工程师负责产品需求测试，架构，特性测试；1名测试工程师负责产品性能测试7.2测试工具用途工具；商/自产版本测试管理工具Gitlab/nginx无8.0.2/1.4.6缺陷管理工具Gitlab ,8.0.2压力测试工具LoadRunner, apachebenchHP, apache10接口测试工具SoapUI无5.1.2自定义测试工具EclipseApache3.4.18测试进度由于测试进度安排包含在产品计划中，具体每个版本的测试计划另行编制，不在此处体现。任务名称预计花费时间开始时间完成时间资源名称测试方案制定1天2018062320180624测试人员的10%9 / 9测试方案评审1天2018062320180624测试人员，开发经理，架构经理，产品经理测试