01

引言

做测试也有几年时间了，也负责过很多大大小小的项目测试工作。以前一直觉得IT行业工作是份高大上的工作，但接触后才发现这份工作并不那么高大上，还有点苦逼。

我们接触到的每一款产品背后都有着一个或多个团队的心血。每个成功的产品背后都有着一个成功的产品团队，在团队中，测试作为产品最后的一道门槛，测试的好坏取决了一个产品的用户体验度及舒适度。那么，作为测试的软件测试工程师，我们该怎么保证一个产品的质量呢？我们今天来聊一聊这个。

02

软件测试工程师职责

作为软件测试工程师，对比软件开发工程师，我们可以体现的工程在哪里呢？作为测试，难道真的只是单纯的找找BUG吗？

如果是刚刚接触测试这个行业，我肯定是这样认为的，但是，这个只是其中的一小部分而已。

回到上个问题对比软件开发工程师，我们可以体现的工程在哪里，对于这个问题，个人总结可以概述成二个要点：一是项目质量保证，二是测试效能提升。结合这二点去展开测试工作其实就是要求软件测试工程师能够把一个业务或者整块业务的质量保证体系建立起来，这也是作为一个软件测试工程师的职责。但是，在这里需要提一句，项目的质量保证不只是单单软件测试的事，而是整个团队的事。

那么，怎么才能做好这二方面呢？

03

思考如何才能保证项目质量

怎么保证一个项目的测试质量，这个问题贯穿了软件测试的整个周期。我们一般的测试流程都是：首先项目需求或者迭代需求都会对接到产品那边，由产品设计具体的方案在需求评审。测试这边呢参与需求评审，然后根据需求设计出对应的测试方案、测试脚本及排期，当然了，测试方案、测试脚本这些也是也进行评审的。然后等开发完毕提测后开始冒烟测试、探索性测试、提BUG、确认测试、回归测试等测试，当测试通过后测试周期就算结束了。之后投入下一个项目或迭代继续重复这样的流程。这样的流程看起来有问题吗？看起来是没问题的。只不过测试会很被动。从这个流程我们可以看到有三个节点，一是产品、二是开发、三是测试。当产品需求质量差，开发质量差的时候测试只能被动接受，而被动接受的结果是测试会进行漫长痛苦的测试过程及因为质量差导致上线延期，甚至有可能一个问题在生产裸奔几个月最后在涉及到相关业务的时候现场才发现，最后被现场的人质疑为什么这么简单的问题都不能发现，你们测试的价值在哪里？其实这问题在大部分小公司及中型公司都是很容易见到的。其实，这里最关键的节点还是产品。产品设计的需求是否与客户一致取决了后面一系列流程的质量。举一个常见的场景：当产品的需求管控能力、业务能力、设计能力、语言书写等产品能力有限制时设计出来的需求可能是不完善的甚至是与目前系统功能重复的。这部分需求过了需求评审且开发已经开发完，测试用例也已经评审且在测试了，后面发现需求有问题或者不满足条件需要在原有的基础上不断新增新的字段、规则、逻辑等。累加的越多，开发的效率、质量及测试的效率、质量都会逐步下降，这就造成了项目或者迭代的延期。好的一个产品，背后都有一个优秀的产品经理。看到我上面的这个例子，可以看出不管是产品的需求质量还是开发的代码质量测试都只能被动接受。那么，我们怎么把这种被动划为主动呢？目前比较好的一个模式是：测试左移及测试右移。下面我们来说说测试左移及右移。

04

项目质量保证落地之测试左移

我们先来看看什么是测试左移，测试左移就是在提测之前已经介入了测试。流程与上面基本一致，不一致的是在需求评审时不只是了解需求，更是要去评估需求的质量，分析需求的合理性以及完整性。在开发阶段时参与设计方案的设计，了解开发的实现方式。因为很多开发可能只对他负责的那一块熟悉，作为测试需要评估改动范围以及是否有遗漏的模块和系统。当然了，测试还可以通过提供测试用例或者自动化测试脚本的方式给开发，让开发在设计时考虑地更全面，同时方便开发在提测前进行自测，有助于提高产品质量，毕竟越早发现问题，解决的成本就越低。测试人员还需要不断地培养产品、开发人员的质量意识，同时提供必要的技术支持，协助产品、开发更好的进行测试，比如公共用例、测试工具、测试脚本等。

我们可以看到，在这种流程下，测试由被动化为了主动。这里有个常说的TDD概念，就是测试驱动开发。这样，我们会发现提测的质量及效率都提高了，原本提测后还需要花一天的时间进行冒烟测试，现在可以有时间进行更多的探索性测试。

当测试完成后，测试活动就结束了吗？肯定是不行的。为了检验测试团队的质量保证体系质量，我们还需要进行测试右移。

05项目质量保证落地之测试右移

那么，什么是测试右移呢？

测试右移是上线后测试人员还需要