什么是测试左移?

上一篇 / 下一篇  2020-08-13 18:03:28 / 个人分类:其他

  1.左移之前:较早的测试过程,待提测后正式开始测试,提bug,回归,发布UAT/生产,会产生的问题或风险
  1>需求问题:敏捷模式下需求不够清晰,细化是常态,导致需求;
  2>用例问题:未了解开发的设计方案,认识不了改动范围,导致功能点或场景遗漏;
  3>成本问题:各个阶段修复问题的成本相关很大,越早修复成本越低;
  4>需求风险:产品功能或交付的用户体验不够友好,不符合习惯行为;
  5>延期风险:转测前未把控迭代版本开发进度,可能导致转测延期;
  6>质量风险:转测的版本质量完全依赖开发个人能力的高低;
  2.左移之意:测试左移简单来说其实就是通过测试人员提前介入项目,推动需求明确/细化,把控各节点/风险等前期一系列的活动,保证按需开发,转测质量,以达到缩短测试周期的目的
  1>提前介入:测试人员提前介入项目,了解产品故事,需求背景;
  2>推动需求:深入梳理,分析需求,发现需求中的问题;
  3>把控节点:版本各关键节点的把控,如需求评审,开发设计,用例评审,提测质量;
  4>识别风险:了解版本开发进度是否正常,技术是否有困点,是否能按时转测,风险规避方案;
  5>核对输出物:核对产品原型,UI是否相符,是否遗漏;
  6>冒烟测试:正式测试的准入标准,以保证后面测试工作的开展;
  3.可做之事:不同阶段,左移可具体落实的动作
  1>需求分析:需求分析不只是了解需求,更应该评估需求质量,分析需求的合理性和完整性;
  a>UI交付时间点;
  b>需求结合原型或UI,加强理解且核对二者;
  c>依据后端开发设计文档,分析表和接口的设计;
  d>前端需要把需求拆分成很小的功能点清单列举出来,细到特殊字段需要加校验的粒度;
  e>需求分析时,需要注意各需求之间的关联性,保证功能统一性,正确性;
  f>分析正常场景时,结合业务背景/业务意义进行分析,可能会发现因需求不够具体化而不符合实际业务场景的问题;
  2>需求评审/管理:需求的准入,管理标准是版本迭代的基石
  a>评审:需求评审时,产品说明需求市场价值,让团队人员更好理解和把关需求开发条件是否成熟
  b>管理:Bug区分出是需求问题或需求变更类型
  c>插入:插入需求需要评估审核,tapd标识,回归阶段不接紧急需求;
  3>开发设计:前后端开发针对需求的实现方案,后端提供接口,客户端与数据库的桥梁,抽象对象来组织数据给到客户端
  a>业务逻辑:复杂业务逻辑画出业务逻辑图,结合数据落库说明实现过程;
  b>表设计:三大范式五大约束,表的索引,字段类型,结构;
  c>接口业务性:
  <1>充分存在的理由,必须设计这一接口意义价值;
  <2>职责明确:一个接口只负责一个业务功能;
  <3>接口要处理的业务逻辑尽量单一;
  <4>高内聚低耦合:一个接口要包含完整的业务功能,而不同接口之间业务关联尽可能的小;
  <5>API级别和重要性划分;
  e>接口规范性:
  <1>有统一的接口设计规范说明;
  <2>接口和参数的命名有意义且清晰;
  <3>入参格式统一,输入的校验,禁止随意拓展参数;
  <4>接口的异常处理能力,如错误码/错误信息与业务/业界挂钩
  4>用例评审技巧:高质量的用例是测试工作的重要保证,所以用例评审是测试工作最关键的环节,没有之一
  a>设计思路:用例设计前,先出设计思路给到测试负责人,对齐思路后再进行用例设计;
  b>用例类型:正常,异常,UI,数据,权限,平台兼容性,业务数据兼容性;
  c>用例描述:用例描述精练准确,清晰明了;
  d>发出时机:用例提前半天发出给到相关人员;
  e>参与人员:用例提前半天发出给到相关人员;
  f>评审优先级:按需求优先级高到低进行评审;
  5>测试准备:执行测试需要的一些环境,数据等相关事项需要在转测前完成,以保证执行测试的效率
  a>业务数据:测试所需的数据提前准备,如账号,角色,业务数据(保险公司,调度规则配置)等;
  b>真实数据:测试业务,与业务数据有关时,拿到真实的业务数据例子,按真实业务数据进行正常测试;
  c>sql脚本:涉及到数据测试时,提前梳理表关系,编写sql脚本用于测试;
  d>数据流:完成正向的业务流程测试,更需要关心业务流和数据流的关系,提前熟悉了解;

TAG: 测试左移

 

评分:0

我来说两句

Open Toolbar