每天努力一点点,坚持下去 ------ 博客首页

高效测试计划&工作量排期

我们先来思考力下:

  • 如何一步一步制定测试计划

  • 如何进行需求分析

  • 如何进行测试策略、工期和资源安排

迭代测试常见的问题

 建立测试计划步骤概述:

  • 测试目标:是质量第一 还是快速上线
  • 质量目标:是由 测试目标而来 
  • 进行需求分析【测试的基石】:
  1. 测试的优先级
  2. 测试的重点
  3. 测试难点
  4. 测试关键路径......
  • 测试策略(测试的颗粒度、测试的原则 )
  1. 整体的测试策略
  2. 阶段的测试策略
  • 制定测试计划
  1. 资源的安排
  2. 风险的识别处理......

迭代测试-高效计划实战

质量目标----------->测试目标

  • 产品商业价值 -->质量第一
  1. 找到该产品最核心的产品是在做什么
  2. 针对的客户来到我们这里最主要是要做什么
  3. 给产品带来最大收益的是什么
  • 项目铁三角 --> 快速上线
  • 线上事故率 --> 线上无P0 和 P1级事故

需求分析:

——从上往下、从左往右,看到的所有按钮全部记录下来

 

第一步:关联分析 

——从实际操作流程,我们把已经梳理出来的测试点来进行归纳调整下---> 具有操作相关联的放到一起

  • 快速熟悉:将所有可以看到的功能点展现到思维导图或是其他文档里面

  • 目标分解,由大到小 -->大、小 类的关联性分析(优先级的划分)

  • 通过思维导图进行需求分析

  • 用连接线把有关联的流程全部串起来 --> 生成Excel

小类分析:

  1. 优先级的划分【除了产品给到的优先级,我们也要有自己的优先级】

  2. 识别测试重点【关键功能】

  3. 识别强关联功能

  4. 识别弱关联功能

 

第二步:测试策略

——整体测试策略

  • 业务和技术的深度掌握
  1. 业务:深挖用户使用场景,了解每一个细节和逻辑
  2. 技术:业务相关的接口、数据表结构等,了解的越深,测试时思路越多,测试方法更有效,测试效果也会更高

 

  • 多样式测试:从业务场景、交互、UI、兼容性、数据逻辑、业务逻辑、性能测试等多个角度去测试,Bug产生效率会更高,质量也会更稳定,而不是仅仅功能测试。

 

  • 组内组外充分沟通
  1. 敏捷研发更强调沟通、强调人与人的作用
  2. 在快速迭代下,很多信息都处于冰山下面,只有不断的交流和沟通,才能被挖掘出来

——版本测试策略

  • 详细设计的脚本验证

  • 测试要点的探索式测试

  • 交叉抽测和回归测试

 

  • P1功能点 特别重要,应充分的考虑用户的使用场景,覆盖功能的各种细节,以及各种异常

  • 在详细测试完了第一轮之后,在对P1进行探索性测试

 

  • P2,进行一次用例的详细设计后,验证即可。不需要采取探索式的测试
  • P3,针对测试要点的编写,直接进行 探索式测试 即可
  • P4,可以不编写测试要点,直接根据 需求文档 验证即可

Ps: 如果业务的商业价格十分巨大,在小的功能也是重点;如果没有商业价值,在重要的功能也其实没有那么重要(比如是内部的OA系统)。

第三步:制定计划

  • 工期的评定:对每一个功能点进行工期的评定
  • 开始评定是需考虑到:【关联度】、【重要程度】
  • 测试点分配:相关联同一个人来做

评估的工期是不是合理:评定完了后,再次进行评审下:

——发现如果分配的时间来看不合理,想到我们的版本测试策略,比较重要的模块可以使用 交叉测试的思路,可以允许部分任务的交叉,调整为工期分配平均一些

  • 进度安排:

测试的顺序,根据测试点的优先级进行排序展开

  •  里程碑进度安排

——Excel 看起来的时间安排并不是一目了然,需要进行调整,然后再把【回归测试】加入

 测试开始时间是否如我们所愿-->开发提测的影响-->参考开发计划-->通过开发提测的时间-->确定下测试开始时间

在制定测试计划时,一定要知道开发计划,需要计划也要知道,这样才利于测试整体的工作的安排。

  •  风险处理:根据【风险的历史库】 【预先识别的风险】-->制定【风险策略】

  •  研发流程 :根据【开发计划】制定之外,也要根据【研发流程】来制定;如:需要进行冒烟测试

——如对产品要求非常高,对产品要求非常细致,还需要制定【集成测试计划】、【单元测试计划】等等。

 


 

posted @ 2021-02-06 21:35  他还在坚持嘛  阅读(353)  评论(0编辑  收藏  举报