11.1系统部署
针对实际环境进行系统的安装部署。
11.1.1单机部署架构
互联网建设初期,用户访问量有限,数据量不大,多数系统采用单台服务器部署应用服务,系统服务、文件、数据库等所有系统资源部署在一台服务器上.
11.1.2.应用和数据分离
随着用户量和数据量的不断攀升,业务对系统的性能要求越来越高,这是需要将应用和数据分离,单独部署相关的业务组件。
11.1.3.引入NoSQL数据库架构
随着用户不断的增加,关系型数据库压力变大,访问延迟,性能下降,这时加入缓存技术,将查询较多数据缓存起来,以加快应用访问速度。
11.1.4.应用集群部署
在访问量高峰时期,单一的系统服务往往无法承受巨大的访问量,这时就需要做集群服务,以减少单台服务器的压力。
中小企业应用系统多数为集群部署,既保证系统的稳定性,又能降低因服务器故障,造成数据丢失的风险。
其他在应用集群部署方案上演变的架构系统,如:分布式、微服务架构等,对系统稳定性和安全性做的更加出色。
完全生命周期测试模型基础上,根据本项目的特点、要求、具体情况和成本效率进行裁剪,并对安全性、系统接口以及系统性能提出重点的测试方法,具体系统测试实施分为需求分析、编写测试计划、测试设计、测试执行、测试结果输出五个阶段。我公司将和采购人、监理公司三方共同成立项目测试组。
测试流程:需求分析-->编写测试计划-->测试设计-->测试执行-->测试结果输出
11.2.1需求分析阶段
阅读需求,理解需求,主要就是对业务的学习,分析需求点,参与需求评审会议。
11.2.2测试计划阶段
主要任务就是编写测试计划,参考软件需求规格说明书制定项目总体计划,内容包括测试范围,环境资源的准备,进度安排,人力物力的分配,整体测试策略的制定,风险评估与规避措施有一个制定。
11.2.3测试设计阶段
主要是编写测试用例,会参考需求文档(原型图),概要设计,详细设计等文档,用例编写完成之后会进行评审。
11.2.4测试执行阶段
搭建环境,执行冒烟测试,然后按照测试用例进入正式测试,进行bug跟踪管理直到测试结束。
11.2.5测试结果输出
出测试报告,确认是否可以上线
详细测试流程:了解用户需求-->参考需求规格说明书-->测试计划-->编写测试用例-->评审用例-->搭建环境-->冒烟测试-->执行测试用例-->bug跟踪处理-->测试报告输出-->版本上线-->上线验证-->面向用户
11.3测试方案
测试方案是从测试的角度去分析或者说分解需求,在方向上明确要怎么测,分析结果就是测试点和测试方法。
11.3.1引言
- 编写目的;
- 预期读者;
- 参考资料;
11.3.2测试范围
11.3.3测试策略(根据不同的测试类型考虑不同的测试方法)
功能测试;
兼容性测试;
性能测试;
接口测试;
安全性和访问控制测试;
数据和数据库完整性测试;
集成测试;
用户界面测试;
负载测试;
强度测试;
容量测试;
故障转移和安装测试;
配置测试;
安装测试等。
功能测试,根据需求分析的思维导图和功能测试的测试用例覆盖功能模块;
兼容性测试,要根据产品的应用场景来考虑,比如IE、Chorme、ios、android、不同机型等等;
性能测试,根据产品架构、预估数据、线上数据来判断需要执行性能测试的功能接口(比如登录接口);
接口测试,安全性测试等等要根据实际的项目需求来确定。
将需要用到的测试类型按照测试场景、测试方法等以引用文件的形式填写到测试计划中去,以便让所有项目人员清楚的知道要做哪些测试工作以及怎么做。
11.3.4测试资源
- 测试人员;
- 测试环境(测试服务器环境、终端测试环境、网络环境);
- 测试工具(bug管理工具、用例管理工具、性能测试工具等);
- bug的等级定义;
11.3.5进度安排
测试工作量估算
测试评估(业务复杂度、测试复杂度、产品质量要求、人员数量及能力) ;
进度安排(评估不同阶段、不同类型的测试工作的工作量、分配人力、预估时间) ;
输出文档
测试计划;
功能测试用例;
性能测试方案;
bug数据;
性能测试数据;
测试报告等等。
11.3.6发布标准
测试完成标准
测试计划里所有测试类型都已经完成了;
功能上、兼容性上没有影响用户使用的Bug ;
允许遗留小部分影响不是很大的Bug,但这个数量应该小于一个值 ;
性能上符合设计目标和上线要求 这些标准都是针对测试工作本身的要求。
产品发布标准
产品需求都已完成;
符合交互设计规范,符合视觉要求,设计已通过评审 ;
遗留的一定比例数量的小部分Bug通过项目组完成了风险评估,都认可且问题不大;
产品使用说明或用户手册或更新log都已完备等等。
11.3.7风险说明
测试范围的风险,比如说测试需求分析是否准确、到位,是否漏了测试点,是否遗漏了某个测试类型,所以测试需求分析是整个测试工作的基础,还有就是产品需求变更的风险,加需求、减需求、改需求都需要重新进行测试需求分析;
测试进度的风险,比如说做计划时工作量估计的不准,导致项目延期,还有可能开发工作没有按时完成或改bug不及时导致进度延后,还有可能测试人员因为别的项目更重要抽调走了或者请假、离职等原因造成人员变动;
产品质量的风险,比如开发的代码质量比较低或者测试人员是新人对业务不熟悉,能力和经验有所欠缺等等;
测试环境的风险。
由本项目主要是对现场的系统环境进行测试,所以利用环境现场。
实施功能测试和负载压力测试时,需要运行系统相关业务,这时需要一些数据支持才可运行业务,这部分数据即为初始测试数据。例如检索系统中的元数据。
在初始的测试环境中需要输入一些适当的测试数据,目的是识别数据状态并且验证用于测试的测试案例,在正式的测试开始以前对测试案例进行调试,将正式测试开始时的错误降到最低。
对系统实施负载压力测试的时候,经常会需要准备大数据量,实施独立的测试或者与并发负载压力相结合的性能测试,这部分数据为业务测试数据。例如测试并发业务,那么要求对应的数据库中有相当的数据量。
在负载压力测试过程中,为了模拟不同的虚拟用户的真实负载,需要将一部分业务数据参数化,这部分数据为参数化测试数据。例如模拟不同用户登录系统,就需要准备大量用户名及相应密码参数数据。
总之准备测试数据可以概括为:
-
-
-
-
-
-
- 识别数据状态
- 验证测试案例
- 业务数据提供负载压力背景
- 脚本中参数数据真实模拟负载
-
-
-
-
-