软件测试工程师职能

---

前言

以下文章提取于微信公众号：测试小哥进阶

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

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

---

一、软件测试工程师职责

作为软件测试工程师，对比软件开发工程师，我们可以体现的工程在哪里呢？作为测试，难道真的只是单纯的找找BUG吗？如果是刚刚接触测试这个行业，我肯定是这样认为的，但是，这个只是其中的一小部分而已。

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

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

---

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

怎么保证一个项目的测试质量，这个问题贯穿了软件测试的整个周期。

我们一般的测试流程都是：首先项目需求或者迭代需求都会对接到产品那边，由产品设计具体的方案在需求评审。测试这边呢参与需求评审，然后根据需求设计出对应的测试方案、测试脚本及排期，当然了，测试方案、测试脚本这些也是也进行评审的。然后等开发完毕提测后开始冒烟测试、探索性测试、提BUG、确认测试、回归测试等测试，当测试通过后测试周期就算结束了。之后投入下一个项目或迭代继续重复这样的流程。

这样的流程看起来有问题吗？看起来是没问题的。只不过测试会很被动。从这个流程我们可以看到有三个节点，一是产品、二是开发、三是测试。当产品需求质量差，开发质量差的时候测试只能被动接受，而被动接受的结果是测试会进行漫长痛苦的测试过程及因为质量差导致上线延期，甚至有可能一个问题在生产裸奔几个月最后在涉及到相关业务的时候现场才发现，最后被现场的人质疑为什么这么简单的问题都不能发现，你们测试的价值在哪里 ？其实这问题在大部分小公司及中型公司都是很容易见到的。

其实，这里最关键的节点还是产品。产品设计的需求是否与客户一致取决了后面一系列流程的质量。举一个常见的场景：当产品的需求管控能力、业务能力、设计能力、语言书写等产品能力有限制时设计出来的需求可能是不完善的甚至是与目前系统功能重复的。这部分需求过了需求评审且开发已经开发完，测试用例也已经评审且在测试了，后面发现需求有问题或者不满足条件需要在原有的基础上不断新增新的字段、规则、逻辑等。累加的越多，开发的效率、质量及测试的效率、质量都会逐步下降，这就造成了项目或者迭代的延期。好的一个产品，背后都有一个优秀的产品经理。

看到我上面的这个例子，可以看出不管是产品的需求质量还是开发的代码质量测试都只能被动接受。那么，我们怎么把这种被动划为主动呢？

目前比较好的一个模式是：测试左移及测试右移。下面我们来说说测试左移及右移。

---

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

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

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

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

---

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

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

测试右移是上线后测试人员还需要关注线上情况，不是功能上线测试人员的测试活动就结束了。通过线上监控和预警，及时发现问题并跟进解决，将影响范围降到最低。在有些时候，其实应该在开发设计时就要考虑预警功能，系统层（如CPU、内存问题）、应用层（如响应时间）、业务层（如WMS的出库、入库等，金融系统的注册率、交易量等）等出现异常的时候通过邮件等方式发出预警，相关人员才能知道哪里出了问题。技术人员要比业务人员先发现问题，如果业务人员已经发现业务量明显下降，说明问题已经很严重了。

在测试右移的过程中，测试人员相当于推动剂和添加剂。可以推动开发需要补充监控预警功能，同时可以提供监控指标。除此之外，测试人员更需要关注线上业务及用户使用情况，更多地关注用户价值高、使用率高的功能，在用例中补充遗漏的场景，尽量多地覆盖这些功能。甚至这里可以引入测试人员的绩效管理，可以根据BUG量及BUG的一个严重等级引入KPI考核。

结合上面所述，我相信，就算不能完全解决产品的质量问题，但是也可以使产品的质量提升一个或者几个等级。不管是测试左移还是测试右移，都是为产品质量服务。

那么，当项目的质量得到保证后怎么提升测试效率呢？接下来我们来说说测试效能提升。

---

五、测试效能提升

举些例子：当开发自测需要造数据、开发自测完后测试冒烟测试不通过、新增功能后回归老流程等。我们可以想想，如果我们手工的去处理这些东西耗费的时间有多少，是否可以把这部分时间花在更有价值的地方上？

那么，如何做到测试效能提升呢？我们可以分二方面来提高测试效能，一是测试能力，二是测试流程。

首先说说测试能力，我们可以合理引入自动化，以上述例子，我们可以把自动化用于在开发自测打包后的冒烟及回归等可以利用自动化的场景下持续测试，利用Jenkins等持续集成工具进行持续测试。或者可以在原有的DevOps流程上衔接测试流程。在项目质量保证的大前提下，任何可以提升测试效率的工具都是好工具。除此之外，在测试过程中还要多写、多累积一些通用的快捷脚本，比如当需要大批量回传接口或者造大批量数据时，像这种情况跑脚本是不是比自己手动弄快的多。其实这些都是将自己转换成测试能力的过程。

除了测试能力外，我们还可以关注当前的测试流程有哪些是可以不用的，如果在原有基础上加其它东西的话会不会有什么新变化，这变化带来的好处和坏处是什么。这些都是身为一个专业的测试人员去考虑的。

---

六、结语

在项目质量保证的大前提下，高效的完成测试工作及保证对应的质量。而怎么让这个目标落地或优化，这才是软件测试的工程。

那么，本篇文章内容就到这，各位觉得不错的可以三连分享哦！886~