软件部署及测试

11 系统部署及测试

 11.1系统部署

针对实际环境进行系统的安装部署。

11.1.1单机部署架构

互联网建设初期,用户访问量有限,数据量不大,多数系统采用单台服务器部署应用服务,系统服务、文件、数据库等所有系统资源部署在一台服务器上.

 

11.1.2.应用和数据分离

随着用户量和数据量的不断攀升,业务对系统的性能要求越来越高,这是需要将应用和数据分离,单独部署相关的业务组件。

 

11.1.3.引入NoSQL数据库架构

随着用户不断的增加,关系型数据库压力变大,访问延迟,性能下降,这时加入缓存技术,将查询较多数据缓存起来,以加快应用访问速度。

 

11.1.4.应用集群部署

在访问量高峰时期,单一的系统服务往往无法承受巨大的访问量,这时就需要做集群服务,以减少单台服务器的压力。

 

中小企业应用系统多数为集群部署,既保证系统的稳定性,又能降低因服务器故障,造成数据丢失的风险。

其他在应用集群部署方案上演变的架构系统,如:分布式、微服务架构等,对系统稳定性和安全性做的更加出色。

11.2 测试流程

完全生命周期测试模型基础上,根据本项目的特点、要求、具体情况和成本效率进行裁剪,并对安全性、系统接口以及系统性能提出重点的测试方法,具体系统测试实施分为需求分析、编写测试计划、测试设计、测试执行、测试结果输出五个阶段。我公司将和采购人、监理公司三方共同成立项目测试组。

测试流程:需求分析-->编写测试计划-->测试设计-->测试执行-->测试结果输出

11.2.1需求分析阶段

阅读需求,理解需求,主要就是对业务的学习,分析需求点,参与需求评审会议。

11.2.2测试计划阶段

主要任务就是编写测试计划,参考软件需求规格说明书制定项目总体计划,内容包括测试范围,环境资源的准备,进度安排,人力物力的分配,整体测试策略的制定,风险评估与规避措施有一个制定。

11.2.3测试设计阶段

主要是编写测试用例,会参考需求文档(原型图),概要设计,详细设计等文档,用例编写完成之后会进行评审。

11.2.4测试执行阶段

搭建环境,执行冒烟测试,然后按照测试用例进入正式测试,进行bug跟踪管理直到测试结束。

11.2.5测试结果输出

出测试报告,确认是否可以上线

  详细测试流程:了解用户需求-->参考需求规格说明书-->测试计划-->编写测试用例-->评审用例-->搭建环境-->冒烟测试-->执行测试用例-->bug跟踪处理-->测试报告输出-->版本上线-->上线验证-->面向用户

11.3测试方案

   测试方案是从测试的角度去分析或者说分解需求,在方向上明确要怎么测,分析结果就是测试点和测试方法。

 11.3.1引言

  1. 编写目的;
  2. 预期读者;
  3. 参考资料;

 11.3.2测试范围

 11.3.3测试策略(根据不同的测试类型考虑不同的测试方法)

功能测试;
兼容性测试;
性能测试;
接口测试;
安全性和访问控制测试;
数据和数据库完整性测试;
集成测试;
用户界面测试;
负载测试;
强度测试;
容量测试;
故障转移和安装测试;
配置测试;
安装测试等。
功能测试,根据需求分析的思维导图和功能测试的测试用例覆盖功能模块;

       兼容性测试,要根据产品的应用场景来考虑,比如IE、Chorme、ios、android、不同机型等等;

       性能测试,根据产品架构、预估数据、线上数据来判断需要执行性能测试的功能接口(比如登录接口);

       接口测试,安全性测试等等要根据实际的项目需求来确定。

       将需要用到的测试类型按照测试场景、测试方法等以引用文件的形式填写到测试计划中去,以便让所有项目人员清楚的知道要做哪些测试工作以及怎么做。

 11.3.4测试资源

  1. 测试人员;
  2. 测试环境(测试服务器环境、终端测试环境、网络环境);
  3. 测试工具(bug管理工具、用例管理工具、性能测试工具等);
  4. bug的等级定义;

 11.3.5进度安排

           测试工作量估算

  测试评估(业务复杂度、测试复杂度、产品质量要求、人员数量及能力)  ;
  进度安排(评估不同阶段、不同类型的测试工作的工作量、分配人力、预估时间) ;
           输出文档

测试计划;
   功能测试用例;
   性能测试方案;
   bug数据;
   性能测试数据;
   测试报告等等。

 11.3.6发布标准

          测试完成标准

   测试计划里所有测试类型都已经完成了;
   功能上、兼容性上没有影响用户使用的Bug ;
  允许遗留小部分影响不是很大的Bug,但这个数量应该小于一个值 ;
  性能上符合设计目标和上线要求 这些标准都是针对测试工作本身的要求。
           产品发布标准

   产品需求都已完成;
  符合交互设计规范,符合视觉要求,设计已通过评审 ;
  遗留的一定比例数量的小部分Bug通过项目组完成了风险评估,都认可且问题不大;
  产品使用说明或用户手册或更新log都已完备等等。    

 11.3.7风险说明

   测试范围的风险,比如说测试需求分析是否准确、到位,是否漏了测试点,是否遗漏了某个测试类型,所以测试需求分析是整个测试工作的基础,还有就是产品需求变更的风险,加需求、减需求、改需求都需要重新进行测试需求分析;
  测试进度的风险,比如说做计划时工作量估计的不准,导致项目延期,还有可能开发工作没有按时完成或改bug不及时导致进度延后,还有可能测试人员因为别的项目更重要抽调走了或者请假、离职等原因造成人员变动;
  产品质量的风险,比如开发的代码质量比较低或者测试人员是新人对业务不熟悉,能力和经验有所欠缺等等;
  测试环境的风险。

11.4 测试管理

11.4.1 测试环境

由本项目主要是对现场的系统环境进行测试,所以利用环境现场。

11.4.2 测试数据

实施功能测试和负载压力测试时,需要运行系统相关业务,这时需要一些数据支持才可运行业务,这部分数据即为初始测试数据。例如检索系统中的元数据。

在初始的测试环境中需要输入一些适当的测试数据,目的是识别数据状态并且验证用于测试的测试案例,在正式的测试开始以前对测试案例进行调试,将正式测试开始时的错误降到最低。

对系统实施负载压力测试的时候,经常会需要准备大数据量,实施独立的测试或者与并发负载压力相结合的性能测试,这部分数据为业务测试数据。例如测试并发业务,那么要求对应的数据库中有相当的数据量。

在负载压力测试过程中,为了模拟不同的虚拟用户的真实负载,需要将一部分业务数据参数化,这部分数据为参数化测试数据。例如模拟不同用户登录系统,就需要准备大量用户名及相应密码参数数据。

总之准备测试数据可以概括为:

              1. 识别数据状态
              2. 验证测试案例
              3. 业务数据提供负载压力背景
              4. 脚本中参数数据真实模拟负载

  • 1
    点赞
  • 4
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值