专栏名称: 51Testing软件测试网
51Testing软件测试网,人气最旺的软件测试技术门户,提供软件测试社区交流,软件测试博客,人才服务,测试沙龙,测试杂志,测试资料下载等全方位信息服务,是国内最专业的软件测试就业培训、企业服务供应商...
目录
相关文章推荐
51好读  ›  专栏  ›  51Testing软件测试网

全程软件测试实践:从需求到运营

51Testing软件测试网  · 公众号  · 测试  · 2016-12-29 17:31

正文


  1、全程软件测试图解

  传统的软件测试,可以简单描述为下图所示:

  

图-1-传统交付测试

  开发人员完成任务之后,最后交付给测试人员,这种模式下,测试人员不能及早发现需求阶段的缺陷,同时测试工作的开展也滞后了,产品质量得不到有效的过程控制和分析,总体进度可能会由于返工问题造成拖延。

  那什么是全程软件测试,如下图所示:

  

图-2-全程软件测试图

  在整个SDLC中,三条角色主线和四个阶段。

  三条角色主线:开发、QA、测试,文中主要讲解测试。

  四个阶段:需求、开发、发布、日常运营。

  简单来说可以归纳为下图所示:

  

图-3-全程软件测试概述

  测试人员贯穿这四个阶段,开展测试活动,试实践活动简单描述如下图所示:

  

图-4-全程软件测试概述

  每个阶段也有开发人员对应的活动,以及QA人员对应的活动。

  对于产品而言,每次版本迭代,都会经历:需求、开发、发布,最后推向日常运营,发布阶段虚线指向的需求阶段和日常运营阶段,并不是一个终止阶段,而是不断迭代的过程。

  那测试人员是如何开展全程软件测试活动的呢?

  2、需求阶段测试

  在需求阶段,开发人员、测试人员、QA人员主要做的事情,如下表所示:


  作为测试人员的主要实践如下:

  (1)参与用户故事分析、挖掘故事含混性

  在sprint会议上,对用户故事进行分析,检查功能性需求和非功能性需求是否描述清晰,其中可以将非功能性需求作为验收要点,例如一个用户故事:

  • “客户希望提高响应时间”

  测试人员应当协助开发人员消除故事的含混性:提高什么的响应时间和响应时间为多少?可以建议修改为:

  • “客户信息普通查询返回结果的响应时间为5s内”

  说明在“客户信息”模块,进行“普通查询”操作,返回结果的时间在5s内,这个陈述句已经清晰表达了,也达到了消除含混性的效果。同样,测试人员可以编写提高查询效率的用户故事:

  • “客户在信息查询模块,进行普通查询,能够在5s内返回结果”

  • “备注:5s为非功能性需求,也是验收要点”

  (2)考经验库质疑开发的时间估算

  在sprint会议上,开发人员根据经验出牌(团队自己定义的规则,用扑克牌)估算时间,当给出最终结果的时候,测试人员应当对其进行质疑。测试人员借鉴历史经验库:开发人员在某方面的技能如何、该模块曾经产生过何种程度的缺陷、修复缺陷的消耗时间是多少等等,综合考虑,提出疑问,让开发估算最终的时间,尽可能考虑这些因素。当然,测试人员能够质疑的其中一个前提是:测试人员具备相关开发经验。

  小结:在需求阶段,测试人员要发挥作用,减少含混性需求引入到开发阶段、同时协助开发做好时间估算。

  3、开发阶段测试

  在开发阶段,开发人员、测试人员、QA人员主要做的事情,如下表所示:


  作为测试人员的主要实践如下:

  功能要点确认

  Xmind是一个非常好用的脑图工具,通常在开发人员进行编码前,测试人员会针对需求处理的用户故事,与开发人员进行确认,修正理解偏差,确保需求理解一致。

  

图-5-脑图用例模板

  测试用例设计

  测试人员主要设计测试故事点,使用DSL(Domain Specific language),infoq文章(敏捷测试之借力DSL),对测试用例进行描述,包括三个基本要素:

  • Feature、Scenario、Example,补充要素:xmind、Requirement。

  • Feature:把测试分类到某个模块,并对这个特性本身的业务目的进行相关描述,带进业 务目标,传递业务知识。

  • Scenario:标明这个Feature的测试场景,可以使用文字描述步骤,或者使用xmind脑图描述,场景中的数据使用Examples中列出的。

  • Example:引出具体的数据表格把用到的数据都展示出来,避免相同步骤因为测试数据 的变化而重复若干遍造成冗余。

  • Xmind:脑图文件,展示测试故事点

  • Requirement:关联需求管理系统的需求id。

  用例评审

  主要是坚持同行评审的原则,主要在测试组内进行,负责该任务的开发人员也会参与,简单来说就是对测试用例进行查漏补缺的工作。

  测试探索

  进行了“功能要点确认”和“用例评审”后,为了保证测试场景的覆盖率,需要再进行测试探索。在开发人员完成雏形之后,使用探索式测试的策略,对功能基本流程进行有目的的快速走查,挖掘功能不确定的地方和补充测试场景,避免不确定的因素拖延到开发阶段后期,造成返工。

  其中:功能测试、Bug Tracking、回归测试、系统测试、验收测试都是日常测试工作所需环节。

  燃尽图发布

  另外,测试人员还有一项重要工作,每日发布燃尽图,让团队了解当前进度情况,总结问题

  所在,寻求耗时超过预期时间任务的解决办法。

  

图-6-燃尽图

  图形特点:

  1)剩余工时在计划基准上方,代表进度有所延迟,应抓紧进度;

  发现此类问题,需要分析总结,原则是保证交付时间,对相应任务进行调整,拥抱变化,发现任务粒度太大,该拆分的继续拆分;对于重构需要慎重,不要过度深入重构,给测试带来额外工作量,影响整个进度,对于整个版本而言,只有开发、测试在承诺的时间内完成任务,才是真正完成,仅仅开发完成交付算不上成功。

  2)剩余工时在计划基准接近,代表进展良好,继续保持;

  此时也需要查看在这种进度下,优先级高的任务是否得到时间保证,而不是因为处理完简单任务才使得燃尽图长的好看。往往有些开发人员,喜欢挑着任务来做,把简单易做、优先级的任务先完成了,因为这些总在预期内能够完成,所以前期燃尽图的趋势看起来没有问题。

  缺陷经验库

  每个团队都存在开发/测试新人和开发/测试老人,当测试人员与开发新人进行需求确认的时候,还需要进行缺陷经验教训的提醒,避免多走弯路。

... ...

 
推荐阅读

点击阅读☞教你如何用Excel实现简易的需求管理

点击阅读☞老板给你一个需求,你该怎么做?

点击阅读☞我们应当怎样做需求分析:业务领域分析

点击阅读☞敏捷项目中的安全需求管理

点击阅读☞浅谈项目需求变更管理


填问卷,100%送公开课视频!