大叔大婶带你走一条接地气的测试进阶之路

告诉你如何从执行测试到管理测试(20)

上一篇 / 下一篇  2017-10-25 22:46:05 / 个人分类:项目管理

第二十章 为什么要从梳理测试点开始做测试设计?

需求评审基本接近尾声了,开发开始写代码去了,我们也进入了测试设计阶段。在早上的晨会上,我要求大家不要着急直接去写测试用例,而是先梳理一下各自需求的测试点。有些人不明白,就问我,一般不都是按照测试用例去执行吗?测试点又是什么?

我说,测试点其实就是功能点对应的测试项,比如我们要测试 APP 的订单列表,那订单列表就是 APP 的一个功能点,而对于这个功能点,列表的 UI 布局、订单数据的完整性、列表超过12条之后的自动分页、空数据页面以及列表数据展示速度,这些测试项就是测试点。

我们如果要再进一步细化测试点,就是在设计测试用例了。之所以我们要先从测试点开始梳理起,我先说下为什么吧:

  1. 测试点比功能点会更精细一些,可以根据测试点得出更为精准的测试工作量估算;
  2. 在功能点的优先级已经确定的前提下,我们可以再对测试点做一个优先级的分析,当项目出现风险的时候,比如测试时间被压缩的时候,就可以舍弃一些低优先级的测试点,优先完成重要的测试点;
  3. 先将测试点梳理出来,然后再根据实际需要,针对部分测试点设计测试用例,一方面能节省部分人力,另一方面也可以提高测试设计的效率,而不会盲目地一上来就设计测试用例,最后执行时发现,有些测试用例都是为了设计而设计,没有任何价值;
  4. 我们目前因为也没有引入比较好的 Case 管理系统,所以从执行进度跟踪管理的角度来看,测试点的颗粒度正正好;

这几个就是我要求你们先梳理测试点的理由,接下来,我们再看一下整体的测试思路,你们就能理解和接受了。

功能性需求的测试思路:

  1. 根据公司的质量要求,确认测试目标;
  2. 阅读需求文档,确定测试范围、测试难点和测试重点;
  3. 根据功能点,梳理测试点,并制定优先级;
  4. 制定测试策略,根据风险和项目事业环境因素,分析可用的时间和人力;
  5. 基于测试点,采用合适的方法完成测试用例的设计和开发;
  6. 基于测试点,采用合适的工具完成自动化脚本的设计和开发;
  7. 执行测试用例,并提交缺陷;
  8. 执行自动化脚本,并分析执行结果;
  9. 根据缺陷的分布和测试覆盖率的分析,及时调整测试策略和测试执行;

如果你们没有其它意见,我们就先从测试点梳理开始吧,给大家两天的时间,等大家测试点都梳理好了,我们就开始设计测试用例。


TAG: 项目管理 测试 测试管理

 

评分:0

我来说两句

日历

« 2024-03-24  
     12
3456789
10111213141516
17181920212223
24252627282930
31      

数据统计

  • 访问量: 71505
  • 日志数: 82
  • 建立时间: 2017-09-03
  • 更新时间: 2018-01-11

RSS订阅

Open Toolbar