您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  要资料 文章 文库 Lib 视频 Code iProcess 课程 认证 咨询 工具 讲座吧   成长之路  
会员   
 
   
 
  
每天15篇文章
不仅获得谋生技能
更可以追随信仰
 
 
     
   
 订阅
  捐助
全程软件测试实践:从需求到运营
 
作者:李乐 来源:infoq 发布于;2016-9-2
来自于要资料   2410 次浏览     评价:      
 

1 全程软件测试图解

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

图-1-传统交付测试

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

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

图-2-全程软件测试图

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

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

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

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

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

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

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

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

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

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

2 需求阶段测试

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

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

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

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

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

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

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

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

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

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

参考经验库质疑开发的时间估算

在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)剩余工时在计划基准接近,代表进展良好,继续保持;

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

缺陷经验库

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

图-7-缺陷总结

提升开发自测质量

测试人员可以提供相关checklist(大家可以根据原作者提供的修改为符合团队的)帮助开发人员在编码过程中关注开发自测的要点,从而提升质量。

图-8-web软件测试checklist

持续集成

利用持续集成(Jenkins)平台,做到快速的构建开发代码,自动的单元测试化,来提高开发代码的效率和质量。

负责单元测试的开发人员,会收到失败构建的邮件;

负责集成测试的开发人员,会收到失败构建的邮件;

负责自动化测试(Selenium)的测试负责人员,会收到失败构建的邮件;

这种方式,确保单元测试、集成测试、自动化测试,有相关人员关注和维护。

图-9-持续集成

Sonar反馈

Sonar is an open platform to manage code quality. As such, it covers the 7 axes of code quality。

图-10-sonar分析结果

测试人员主要反馈问题如下:

Code coverage:团队要求代码覆盖率在80%以上;

Test success:团队要求测试成功率在100%;

Duplications:团队要求代码重复率在10%以下;

Violations:团队要求Major类别的代码规则缺陷在20以下;

开发团队必须保证每个环境的质量目标,才能够保证整个的质量目标。

小结:

测试人员与开发人员永远不是敌对关系,而是协助关系,确切来说是质量天枰的两边,任何一边的工作没有做好,都会失去平衡。

4 发布阶段测试

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

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

测试报告

完成验收测试,提供测试报告,给出测试数据度量,例如:

测试发现缺陷总数:测试过程中产生的去除状态为“无效”、“不用改”的缺陷数目。

测试发现严重缺陷数:测试过程中产生的并去除状态为“无效”、“不用改”的、且严重性为“Major”和“Critical”的缺陷总数目。

测试发现缺陷修复数:测试过程中产生的状态为“已关闭”的缺陷数量;

未解决缺陷数:去除状态为“无效”、“不用改”、“关闭”的缺陷总数。

缺陷修复率:(测试发现缺陷的修复数)÷(测试发现缺陷总数)×100%

严重缺陷率:(测试发现严重缺陷数)÷(测试发现缺陷总数)×100%

严重缺陷修复率:(已修复的严重缺陷数)÷(测试发现严重缺陷数)×100%

测试需求覆盖率:已测试需求个数÷需求总数×100%

缺陷统计分析报告

另外,测试人员还有一项重要工作,对当前版本的缺陷进行统计分析:

按缺陷级别统计:

按缺陷来源统计:

按缺陷状态统计:

测试进度和问题分析:

从BUG的严重级别分布来看,Major级别以上的BUG占12%,占的比重不高,说明大部分的主要功能已经实现了;

其中在sonar定义级别的缺陷,主要集中在代码规范和单元测试覆盖率,说明代码质量有待提高;

版本测试的前期时间较充足,后期随着开发提交完成的功能点增多,BUG数量增多,剩余测试时间变得紧张;

在版本测试期间,发现测试环境存在一次代码被覆盖、两次因开发人员操作失误影响测试执行的情况;

小结:

测试人员应当持续反馈、改进、总结每个版本发生的问题(不管是缺陷,还是过程中出现的),并对缺陷进行分析,总结出一些规律,帮助开发人员建立良好的习惯,改进代码的质量。

5 日常运营阶段测试

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

日常运营阶段,并不是终止阶段,即便需求、开发、发布阶段暂停活动,只要产品提供服务,日常运营都存在着。

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

版本问题反馈和改进提议

对日常运营发生的问题,总结反馈,提出改进建议,并且跟踪实施。

生产故障分析

协助开发排查生产故障,避免测试场景的遗漏。

6 总结

软件测试并不是保证产品质量的最后一道防线,测试人员也不是,测试人员的工作完全可以由更加资深的开发人员来完成,不过现实总是残酷的,目前测试与开发的比例为:1:3,在成熟的团队是这样子,另外一些还在持续改进的团队,由于资源不足,可能去到1:7。开发人员在相当长的一段时间内不可能完全替代测试人员,有个关键要素:思维方式不同,有句古话来形容:江山易改本性难移。当开发人员的思维方式改变的时候,那就成为测试人员了,倒不如把测试人员独立出来更好,并且培养给开发人员一定的测试素养,这个对保证产品质量都是有帮助的。

全程软件测试实践,强调的是贯穿每个阶段的测试活动,不论是开发、还是测试,要理解双方的活动价值,什么时候该做什么事情,什么事情该做到什么程度才算好,保证每个环节的质量,才能够保证产品的全程质量,另外产品质量不是测试出来的,而是构建过程中沉淀下来的,开发人员的素养、测试人员的素养、以及团队对开发测试过程的重视程度,决定了产品质量。产品质量就如同一块蛋糕,应当切分为小块,落实到每个人手里,让每个人尝到甜头,担当起来。

   
 订阅
  捐助
相关文章

性能测试十问:测试经理篇
web前端性能优化进阶路
性能测试综述
VS2010中自动化测试—Web性能测试
相关文档

性能测试
性能测试执行之测试脚本录制
性能测试进阶1-流程篇
性能测试进阶2-方案篇
相关课程

性能测试方法与技术
使用LoadRunner进行性能测试
Android应用的性能测试
基于Android的单元、性能测试
 

LoadRunner性能测试基础
软件测试结果分析和质量报告
面向对象软件测试技术研究
设计测试用例的四条原则
功能测试中故障模型的建立
性能测试综述
更多...   

性能测试方法与技术
测试过程与团队管理
LoadRunner进行性能测试
WEB应用的软件测试
手机软件测试
白盒测试方法与技术

相关咨询服务
建立软件测试规范
性能评测与调优

某博彩行业 数据库自动化测试
IT服务商 Web安全测试
IT服务商 自动化测试框架
海航股份 单元测试、重构
测试需求分析与测试用例分析
互联网web测试方法与实践
基于Selenium的Web自动化测试
更多...   
 
 
 
 
 
每天2个文档/视频
扫描微信二维码订阅
订阅技术月刊
获得每月300个技术资源
 
 

关于我们 | 联系我们 | 京ICP备10020922号 京公海网安备110108001071号