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

http://www.ltesting.net/ceshi/ceshijishu/csgl/2013/1226/206952.html

原文转自：http://www.infoq.com/cn/articles/whole-software-testing-practice-requirements-to-operational

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 原文转自：http://www.infoq.com/cn/articles/whole-software-testing-practice-requirements-to-operational

开发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%

　　测试进度和问题分析：

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

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

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

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

　　小结：

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

　　5 日常运营阶段测试

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

阶段	开发人员	测试人员	QA人员
日常运营	生产故障登记	版本问题反馈和改进提议 生产故障分析	管理日常运营活动

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

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

　　版本问题反馈和改进提议 

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

　　生产故障分析

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

　　6 总结

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

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