软件测试转型之路--革新全程软件测试

10分钟看尽全程软件测试

10分钟看尽全程软件测试

发表于：2018-1-29 14:07  作者：山丘的测试之道   来源：博客园

字体：大 中 小 | 上一篇 | 下一篇 |我要投稿 | 推荐标签： 软件测试 软件测试管理 软件测试工程师

　　前言

　　“尽早的介入测试，遇到问题的解决成本就越低”

　　随着软件测试技术的发展，测试工作由原来单一的寻找缺陷逐渐发展成为预防缺陷，探索测试，破坏程序的过程，测试活动贯穿于整个软件生命周期中，故称为全程软件测试

　　全程软件测试，强调整个软件生命周期中，各阶段的测试活动。无论是需求阶段，开发阶段，还是测试阶段，都需要确定在当前阶段测试活动的内容以及成都，确保每个阶段的质量，才能保证产品最终的质量。

　　全程软件测试

　　

全程软件测试图解

　　根据全程软件测试的时间轴线图，我们可以发现测试活动贯穿软件开发的整个生命周期，各个阶段测试活动内容如下：

　　那每个测试活动又到底是如何进行的？需要用的哪些技能或者方法呢？

　　需求阶段

　　一、测试需求分析

　　我个人一直认为需求分析是整个测试活动中除了测试用例设计之外最重要的部分。

　　· 需求分析目的是理解需求，理解业务。

　　· 弄清楚我们的产品有哪些功能？有哪些非功能性需求？

　　· 明白我们的用户群体是什么？用户会如何来使用我们的产品？

　　那我们到底该怎么来进行需求分析呢？

　　具体执行如下：

　　二、测试计划制定

　　当对需求有完整和全面的理解后，接下来我们需要制定详细的测试计划，为即将开始的测试工作做好充足的准备。对于测试计划的理解，我一直分为两种工作规模去看（个人理解，不正确的地方还请见谅）

　　小公司团队

　　小公司测试团队可能本身都没几个人，按照传统理论需要考虑测试活动中各方面的问题，给人的感觉就像杀鸡用3米长的大砍刀一样。

　　我的理解是小团队的测试计划讲清楚以下四个要素就行。

　　· 时间：根据以往经验以及需求理解进行时间估算（小建议：时间节点多争取1到2天时间缓冲，项目过程中难免出现意外事件）

　　· 任务：将测试活动拆分成具体的任务

　　· 人：任务的执行人以及质量监控负责人

　　· 风险控制

　　大作坊团队

　　大公司测试团队往往是涉及多个项目，整个公司的硬件、时间、人力等资源的分配就更为复杂。在这种情况下，需要对各方面有更为精细的计划。

　　· 资源估算：整个项目需要多少资源？硬件资源，人力、时间资源等

　　· 进度控制：每个测试活动时间点控制

　　· 风险控制：对于在测试活动过程中出现问题的解决方案

　　· 资源配置：如何更有效率的使用资源

　　· 验收标准：文档、项目、测试过程的验收标准定义

　　· 测试策略：测试中使用的测试策略

　　小结：

　　在需求分析阶段，测试人员既要详细的理解产品需要，又要从用户的角度出发，分析出需求中不完善的地方，还要协调开发与测试对于需求理解的一致性，保证需求信息在开发和测试双方中的统一。

　　这也就是尽早的将产品缺陷给暴露出来，也会有效的预防缺陷。

　　开发阶段

　　在经过需求阶段的准备工作后，进入开发阶段就意味着撸起袖子加油干的时候。开发阶段对于软件生命周期而言是最重要的阶段。那在这个阶段，又是如何开展测试活动的呢？

　　一、测试用例设计

　　测试用例设计是软件测试工作的灵魂。

　　任何一项测试活动的核心都是测试思维，即如何进行测试。而测试用例就是测试思维的体现。功能的测试优先级、如何操作、输入什么数据、应该有什么的结果等等都体现在测试用例中。那么问题来了

　　到底怎么设计测试用例呢？

　　（由于篇幅原因，这次我主要介绍一下接口测试用例设计方法）

　　首先，我们来看一看接口的执行过程

　　任何一个接口其实都由这三部分构成，那我们在设计测试用例时就可以根据这方面进行考虑。

　　针对接口的输入条件进行设计：

针对接口的处理逻辑进行设计：

　　针对输出结果设计：

　　其他方面考虑：

　　· 接口超时处理

　　· 废弃接口处理

　　二、测试用例评审

　　测试用例的评审无疑是为了给测试用例进行查漏补缺。

　　评审方式：

　　· 测试内部评审

　　· 项目组评审：项目相关人参与评审（开发、测试、产品）

　　注意：

　　· 项目组评审时，一般是会议的形式，由于测试用例的数量关系，会议上评审会占用很长的时间，造成时间资源的浪费。

　　· 建议大家在评审前先将测试用例邮件发送给评审会议相关人，让他们提前能对测试用例进行了解，熟悉。会议中进行反馈，记录后，会后再修改。

　　三、测试执行

　　前面的工作做的充足的话，在测试执行的时候就会非常简单了。只需要根据测试用例一条一条去执行程序即可。发现缺陷就提交缺陷，测试通过就继续回归。

　　各位看官现在应该是心里一万个XXX呼啸而过～～哪有说的那么简单。

　　其实测试执行的过程真的很简单，只是在执行的过程中各部门的协作，沟通以及各项文档的输出很复杂。下面我们来聊聊在测试执行过程要注意的几方面问题。

　　1、测试与开发的沟通

　　“XXX 我这有个问题，你过来看下”

　　“什么问题？你演示下我看看”

　　“这不是问题，这个地方只能这样做”或者 “这不是问题，我刚刚跟需求确认过的”

　　“这样做不合逻辑啊！”

　　“那你说怎么处理？”

　　“我觉得应该....处理”

　　“你先跟需求确认下吧”

　　这应该是测试工程师的日常吧。测试与开发沟通无疑是关于某个功能或者产品的，主要围绕几个以下几个点：

　　· 程序某个地方存在问题

　　· 产品需求信息在测试和开发中不统一

　　· 程序某功能应该是怎么处理

　　· 缺陷修复后的验证

　　既然知道问题的核心，我们就要想办法规避这些问题。假设一开始提问题的时候就把问题的特征，位置，以及操作步骤，截图都一目了然的提交给开发，是不是很大程度上可以节省测试演示的时间？

　　另一个最容易出现的问题就是信息不统一，这个需要整个项目组有意识的培养健全的工作流程，通过工作流程来规避这种信息不对称的情况。这种情况将大大增加测试与开发的沟通成本。

　　2、测试与需求的沟通

　　测试人员与需求的沟通难点主要还是体现在需求不明确或者需求变更上。

　　很多时候需求人员的需求文档都是不全面的，测试人员在写测试用例时需要一次又一次的与需求进行确认，一来二去，需求估计有种想把桌子里40米长的大刀放桌上来。

　　另一方面在项目过程中，不可避免的会出现需求变更，只要出现变更就意味着之前的测试准备工作就作废。

　　所以在与需求的沟通是非常频繁又火星四溅的，那怎么更好的与需求进行沟通呢？

　　· 切记不能停留在口头沟通，确认

　　· 所有的需求确认或者需求变更都需要文档化，实在不行也需要发邮件

　　· 每一次确认、变更都需要通过项目相关人

　　· 建立完善的需求变更体系，流程上控制需求变更

　　3、测试结果的反馈

　　相信大家应该遇到过偶现的缺陷，开发重现时就没有了，忙活了半天，被开发嫌弃了一顿

　　测试结果的反馈容易出现问题的地方就是结果描述不清楚，增加项目的时间和沟通成本。解决这个问题最好的办法就是将测试结果尽可能的描述清楚。

　　测试结果反馈分为两种：

　　· 在沟通工具中向开发反馈缺陷

　　· 在缺陷管理工具中提交缺陷

　　到底怎样提交/描述清楚一个缺陷？在下文中，我会详细介绍。

　　四、缺陷管理

　　在开发阶段，测试人员最重要的产出就是缺陷。缺陷不仅仅是数量多，就越有价值。更应该关注缺陷的质量、缺陷的管理以及缺陷分析。

　　怎么样提出质量高的缺陷？怎么样对缺陷进行管理和分析？见下图

　　

缺陷处理流程图

　　缺陷管理是软件测试活动中极其重要的一环，很多时候测试用例并没有发现多少缺陷，反而自己在运行程序的过程中发现了很多缺陷，那这些缺陷就是对测试用例的补充，对之后的测试就可以提供思路。

　　小结：

　　在开发阶段，测试人员最主要的工作就是发现缺陷，但是在这个过程中会伴随着很多其他的问题，需要我们在工作流程中去规避。最重要的就是把测试放在整个项目中，是各个部门的团队协作。

　　很多团队的问题并没有出在测试用例设计，测试执行，缺陷提交中，更多的出现在各部门之间的沟通、协作中。

　　发布阶段

　　进入发布阶段就意味着产品已经通过了测试，可以发布到线上，交付给用户使用。那如何确认测试已经通过？在发布过程中，我们测试人员又需要完成哪些工作？

　　测试通过准则规范

　　上线前，需要确认测试已经通过，现在程序越来越复杂，如果没有量化的规范，就很难确定测试到什么时候可以上线。所以我们需要设定测试通过的准则，只有达到准则才能上线

　　· 测试需求功能覆盖率100%

　　· 测试用例通过率95%以上

　　· 遗留缺陷没有严重程度3级以及以上的缺陷

　　测试报告

　　完成测试后，提交测试报告，给出此次测试过程中的数据，例如：测试用例的数量，发现缺陷的总数，各个严重程度的缺陷数量，总共修复的缺陷数量以及缺陷修复率等等

　　系统回滚方案

　　每一次发布都不能说百分之百的没有问题，如果真的出现问题，我们该如何处理？

　　· 如果线上出现的问题不是很严重，尽量当时处理掉再上线

　　· 如果线上出现的问题很严重，就必须要系统回滚，保证线上用户的正常使用

　　· 系统回滚方案须跟开发/项目经理确认

　　线上功能检查

　　· 程序原有功能的回归测试

　　· 新上线的功能全面测试

　　小结：

　　每一次发布后，测试人员都应该持续反馈，改进、总结每个版本中遇到的问题，不管是缺陷还是流程问题，从一次次的问题中总结一些经验，提高整个软件生命周期的质量

　　日常维护阶段

　　产品上线后，用户能稳定的长期使用，就意味着发布的功能进入到日常维护阶段。而这里并不是终点，这个阶段将一直存在。

　　在这个阶段，测试人员的主要工作就比较简单

　　· 持续测试，没有产品是没有缺陷的

　　· 即使收集用户反馈的问题，并尽快组织人员修复

　　· 长时间稳定性测试（自动化测试）

　　总结

　　全程软件测试，关注的是在整个软件生命周期中，各个阶段的测试活动。

　　通过对各个阶段的过程质量把控，从而提高产品的测试质量。产品的质量并不是测试能决定的，而是整个项目构建过程中，通过一次次的优化过程，不断的总结成长，是整个项目团队决定的。

　　不同的工种都在这个过程中起到举足轻重的作用，而全程软件测试强调不断提高每个阶段的质量，最终提高项目团队的综合能力，从而提高产品质量

选择测试之路——路上的迷茫

　　2010年12月31日，在网易从事了多年开发之后，依依不舍地离开，面临的是一个完全从零开始的全新职位：SQA，也就是tester。

　　当时对为什么被选择做软件质量保证，而不是继续在研发上进取，持有保留态度：凭什么要我转，不是别人？这个时候，多年的伙伴、领队——雷叔就把我的优点暴露出来了：认真、心细、负责；好吧，基于以上几点，只有“我行”，只能给力了。

　　从心底里，对质量管理、SQA等概念，我并没有多想，因为根本想不了，脑子里面没有太全面的认知，即使雷叔讲过一些，我还是觉得不够全面，不知道业界是如何做的？所以心里多多少少有点担心！

　　几个人成立一个新团队，什么都是从零开始，关键还是要有一些流程，这几年开发中也积累了些经验，总结了些问题。在12月底，我提交了《软件质量保证第一季度计划》，这个计划后来也成为了整个质量保证体系的核心，大概纲要如下：

1. 搭建项目管理平台
2. 搭建持续集成平台
3. 规范开发流程
4. 制定软件质量保证规范流程
5. 建立缺陷管理
6. 建立风险管理库、经验教训库（长远计划）

　　2011年1月25日，苦于没有规范的流程，做起事来还是不够顺畅，在奋战多日之后，制定了《产品研发质保流程手册》，简单来说，划分了：需求、开发、发布三个阶段，每个阶段定义验收的产物。为什么要制定这个？必须有章可依，否则步伐不稳健，走的再远，也会乱。

　　道路上，难免遭遇坎坷，要不断提升自己，也有三点切身体会：

1. 如电影《热血教练》中卡特教练所说，先把基本功练扎实了，才能有胜算。既然从零开始，就不要被困惑不已的琐事所纠缠着，下决心突破，可以研读质量管理、缺陷预防、软件测试、持续集成等书籍，并且通过互联网了解一些公司是如何开展测试和质量管理的方方面面。
2. 个人价值迎合团队价值，果断取舍，为团队利益着想。
3. 坚定信念，避免浮躁，把握远景，不要急于寻求成就感。

　　同时，在调研期间，我意识到持续集成很重要，并按照当前的需求，重点关注以下几点：持续测试、持续审查、持续反馈。

图：早期的开发、测试流程原型图

　　无悔选择测试之路——路上的抉择、进取

　　有了流程规范，接下来是实施和持续改进。这些规范运用在一个项目上，先做了三个月，不停地测试，编写功能测试用例，也走了2条弯路：

1. 用例花了大量时间编写，就连打开浏览器、输入xx、点击登录，这些也记录了（这种是早期状况）。 我居然还请缨加入开发，因为看到一些任务完成不了。后来雷叔也指明，测试做测试应该去做的，如果我当时帮忙做开发，那么很多测试都完成不了，一样保证不了质量。
2. 所以，测试人员除了要了解业务，使用简单、清晰的语言结构来进行测试之外，还应该准确定位自己，明白自己在整个版本迭代中，控制质量的位置！

　　事后想想，那段日子锻炼了什么？那三个月无法忘记，每天高强度测试，用的最多的就是：功能测试（边界值、场景法），白盒测试。其实就是锻炼了测试的基础技能和流程管理。

　　后来测试管理流程逐步建立起来，但是在测试过程中，应当如何提高代码质量？这个阶段我们参考了敏捷开发中高质量 Java 代码开发实践，做了一些适合团队的改进，见下图：

图：质量提升的模式

　　这种迭代版本中Java代码质量提升的模式，已经采用了将近一年，非常有效。

　　同年Q2，我们对测试管理进行了改进，其中是受到 @段念-段文韬 《组织敏捷测试》影响，采用类似“一页纸计划”的测试文档（在此要感谢@段念-段文韬）在redmine进行管理。之前每次整理测试计划，发送给开发人员，实际上耗费了一些时间，并且成效不大，现在的任务：需求、开发、测试，全部交给redmine管理，所有事情一目了然，对任何人都是可见的，有没有完成，进度如何，非常清晰。

　　为了规范整个开发测试流程的管理，包括开发、测试的交互，我们又制定了轻量级的 SQA框架，见下图：

图：最初制定的SQA框架

　　不过此后这个框架也发生了比较大的变化，做得更好、更轻量级。无独有偶，我偶然的机会买了一本@朱少民老师的：《全程软件测试》，发觉这个SQA框架也是渗透到目前的每个环节，更适合目前团队的scrum模式，在此也要感谢@朱少民老师，真是相见恨晚，不然可以少走很多弯路！！！

　　大家可能会问：Scrum模式、用户故事，测试人员怎么利用？为什么想到这个？如果遗漏了测试场景，团队会很不爽，怎么避免呢？结合@Aullyxiao的《软件测试之魂》提到分层测试的想法，想了想，还可以这么整：

图：分层测试图

　　对于目前的开发架构来说，一个用户故事，涉及这四个点，可以从这四个点入手来进行质量保证。如何做呢？单元测试就开发人员处理了；代码审查，测试人员可以参与和监督，其实就是要保证：将开发任务与提交到SVN的代码进行关联。这样一来，当测试人员检查开发任务的时候，就可以找到改变过的代码。我曾经试过从这些代码里面查看逻辑，找到分支场景，补充到测试用例里面。

　　在此期间，我还看过@架构师Jack原创的《功能测试用例基础设计模型》，这个文档2天转发已超过150次，我也向所有同行推荐该测试设计模型实例化的测试用例，供大家消化该设计模型。想要的朋友可以去微盘下载《功能测试基础设计模型（24个设计方法的实例化用例）》。

　　我当时还借鉴了@季哥来自淘宝的《探索式测试》系列文章，包括：《探索式测试的秘密——记在淘两年》、 《组合测试法中的全对偶测试法》、《探索式测试实践之缺陷大扫除和结对测试》。

　　当然这么多东西，我觉得自己还需要时间来消化。

　　继续测试之路——路上的风景

　　也许会有人问：有没有后悔做tester？

　　我过去也常问自己：做得开心吗？产品质量提升了吗？看到自己的前景了吗？找到high点了吗？

　　现在我可以回答：OK，我做到了，并且还可以持续做得更好。

　　可能有很多测试人员会问：测试人员的价值到底何在？在这里，我套用和整合@朱少民老师的一些术语，给出我的回答。

　　我认为，Scrum中测试人员价值应当体现在：

1. 预防缺陷的手段，提高洞察力，增强业务知识。

   缺陷在需求、开发前期就已经存在了，关键是用什么手段去挖掘出来预防。在sprint前获取到的需求，测试人员可以站在客户角度上来阐述自己的观点，与开发人员进行充分交流和讨论，使自己在用户体验、业务逻辑等等方面的经验充分体现出来。

2. 在开发过程中，测试人员除了站在客户的角度进行测试，还应当提供更全面的质量反馈，包括代码质量的检查，这个可以通过redmine与SVN双向关联来做检查依据。目前整个过程测试人员尚未参与代码编写，应当参与并推进代码评审，将代码问题及时反馈出来；并且参与或者推进单元测试，检查单元测试状态（确保单元测试达到80%以上覆盖率，帮助开发人员开发出具有良好可测试性的代码），自始至终将质量问题及时反馈出来，保证在sprint的整个过程中质量受到足够的关注，提高质量改进的持续性和可视性。

3. 随着版本任务的增加，每个版本回归测试的成本增加，可以适当考虑部分稳定功能进行自动化测试。当然，这是远景。

4. 持续改进、反馈，充分发挥每个版本统计报告的作用，对缺陷进行分析，总结出一些规律，帮助开发人员建立良好的习惯，改进代码的质量。

　　测试人员，应当在自己的道路上看到风景，以前作为开发，写好一个功能，很high；测试人员也要有这种心境，提高了产品质量，预防了缺陷，很high。找到自己的high法，才可以把测试玩得更爽 ，我知道@朱少民老师、@季哥来自淘宝、@段念-段文韬、@架构师Jack，都玩得很爽，但是有一点：要爽得靠自己，多跟高手交流，有利于提升自己，但是不要刻意复制别人成功的经验，因为每个团队的模式和环境不大相同。

　　总结

　　每个人离开自己熟悉的领域，投入到新的领域中（说实在软件测试也囊括了开发领域），必然存在一些迷茫，不知如何入手，身边如果有一个靠谱的高手，指点一下，眼前将会一片明亮。可惜，现实总是残酷的，往往很多时候，都要靠自己去摸索，只有经历了、深刻体会了，才知道如何改变，以及如何迎接新挑战，调整到恰到好处的心态。这样子，才能够稳健进入转型的轨道。不要害怕改变和投入，一定要坚定信念，在前进的道路上，多参考同行的成功经验：@朱少民老师、@段念-段文韬、@季哥来自淘宝、@架构师Jack、@Aullyxiao，迎合团队价值，不断修正自己的偏差，走出一条华丽的直路！

　　我很庆幸，经历了一个测试团队从无到有的创建，同时也帮助开发人员掌握了一些测试的基本技能，用于推进质量保证，让整个团队达到共识。现在的我，只是刚过了转型的痛苦期，测试工作也仅仅是刚刚开始，还有很多有意义的事情需要去做。

　　路漫漫其修远兮，吾将上下而求索！