BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

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

| 作者 李乐 关注 14 他的粉丝 发布于 2013年11月22日. 估计阅读时间: 15 分钟 | QCon上海2018 关注大数据平台技术选型、搭建、系统迁移和优化的经验。

之前一篇文章《软件测试转型之路》介绍过我们转型的一些实践,下文将介绍从2011年3月至今,持续改进的全程软件测试实践活动。

1 全程软件测试图解

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

图-1-传统交付测试

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

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

(点击图像放大)

图-2-全程软件测试图

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

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

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

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

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

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

(点击图像放大)

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

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

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

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

2 需求阶段测试

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

阶段

开发人员

测试人员

QA人员

需求阶段

  • 用户故事分析
  • 用户故事估时
  • 参与用户故事分析、挖掘故事含混性
  • 参考经验库质疑开发的时间估算
  • 保证确认需求活动符合需求管理过程
  • 管理用户故事评审
  • 管理需求变更

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

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

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

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

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

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

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

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

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

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

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

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

3 开发阶段测试

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

阶段

开发人员

测试人员

QA人员

开发阶段

  • 架构评审
  • 功能要点确认
  • 编码开发
  • 单元测试
  • 开发自测
  • 代码评审
  • Bug Fix
  • 功能要点确认
  • 测试用例设计
  • 用例评审
  • 测试探索
  • 功能测试
  • Bug Tracking
  • 回归测试
  • 系统测试
  • 验收测试
  • 管理评审活动
  • 管理文档产物

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

功能要点确认

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人员主要做的事情,如下表所示:

阶段

开发人员

测试人员

QA人员

发布阶段

  • 上线申请
  • 上线部署
  • 服务监控
  • 测试报告
  • 线上功能检查
  • 管理评审活动
  • 管理文档产物

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

测试报告

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

  • 测试发现缺陷总数:测试过程中产生的去除状态为“无效”、“不用改”的缺陷数目。
  • 测试发现严重缺陷数:测试过程中产生的并去除状态为“无效”、“不用改”的、且严重性为“Major”和“Critical”的缺陷总数目。
  • 测试发现缺陷修复数:测试过程中产生的状态为“已关闭”的缺陷数量;
  • 未解决缺陷数:去除状态为“无效”、“不用改”、“关闭”的缺陷总数。
  • 缺陷修复率:(测试发现缺陷的修复数)÷(测试发现缺陷总数)×100%
  • 严重缺陷率:(测试发现严重缺陷数)÷(测试发现缺陷总数)×100%
  • 严重缺陷修复率:(已修复的严重缺陷数)÷(测试发现严重缺陷数)×100%
  • 测试需求覆盖率:已测试需求个数÷需求总数×100%

缺陷统计分析报告

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

按缺陷级别统计:

 

Critical

Major

Medium

Minor

总计

首页

0

0

1

0

1

模块一

0

0

0

2

2

模块二

0

1

2

10

13

模块三

0

0

1

4

5

模块四

0

0

1

2

3

模块五

0

0

3

2

5

模块六

0

1

0

1

2

模块七

0

2

0

6

8

sonar

0

1

2

0

3

总计

0

5

10

27

 

图-11-缺陷统计

按缺陷来源统计:

 

开发1

开发2

开发3

开发4

开发5

遗留

Critical

0

0

0

0

0

0

Major

1

2

0

0

0

2

Medium

1

7

0

1

0

1

Minor

1

7

4

6

3

6

总计

3

16

4

7

3

9

按缺陷状态统计:

缺陷总数

已关闭缺陷数

遗留

缺陷修复率

严重缺陷数

严重缺陷率

已关闭严重缺陷数

严重缺陷修复率

42

40

2

95%

5

12%

5

100%

测试进度和问题分析:

  1. 从BUG的严重级别分布来看,Major级别以上的BUG占12%,占的比重不高,说明大部分的主要功能已经实现了;
  2. 其中在sonar定义级别的缺陷,主要集中在代码规范和单元测试覆盖率,说明代码质量有待提高;
  3. 版本测试的前期时间较充足,后期随着开发提交完成的功能点增多,BUG数量增多,剩余测试时间变得紧张;
  4. 在版本测试期间,发现测试环境存在一次代码被覆盖、两次因开发人员操作失误影响测试执行的情况;

小结:

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

5 日常运营阶段测试

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

阶段

开发人员

测试人员

QA人员

日常运营

生产故障登记

  • 版本问题反馈和改进提议
  • 生产故障分析

管理日常运营活动

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

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

版本问题反馈和改进提议

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

生产故障分析

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

6 总结

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

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

作者简介

李乐博客微博),测试经理,6年以上工作经验,目前就职于ChinaCache质量部。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

很不错的文章! by 胡 零

写的很好,真实!很符合我现在公司的一个流程。不过流程有了,怎么执行还是很重要的。
期待楼主尽快出书啊,哈哈

Re: 很不错的文章! by li le

胡 零,出书可能不是一时半会的事情,测试如何协助开发,并且在开发过程中坚持测试活动,都是要双方认同价值。

好崇拜撸主 by Chen reniaL

好崇拜撸主,流程很赞!在什么公司啊,求推荐~

Re: 好崇拜撸主 by 邓 华岳

你眼睛有毛病么,博主简介明明写着是ChinaCache,蓝汛啊,他们家的CDN不错的!

好的理论需要好的实践 by 张 建峰

哈哈!这套理论我已经实施过了。很不错的。

Re: 好的理论需要好的实践 by li le

再好的理论,没有实践,都是虚幻的;找到适合团队的,哪怕是微创新的实践,团队认可了,都是好的开始。

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

6 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT