经常看到网上时不时吵起“测试人员如何转产品”、“QA的长期职业规划”等文章，对于QA工程师而言，貌似都是老生常谈的内容了。原本抱着在某个“特殊时刻”（马桶上）消磨时光的心态点开了这篇文章，居然在如此“恶劣”的环境下用时15min耐心看完了之后，又返回电脑前默默把它左击放入收藏夹。

到底这篇文章讲了什么呢？快收起小马步，听听华为资深测试专家怎么看待测试的行业危机：

入职华为以来，一直做的是测试工作，这种危机感在近几年愈发强烈，一直想总结一下，但又担心总结不好，动摇军心。但该面对的早晚要面对，需改变的也要尽早改变，一定要有革自己命的勇气。

举两个测试行业危机的例子：

一个是外部例子。近期参加了几个测试行业交流，测试技术分享方面并没有什么新的发展，还是自动化、APP 测试能力技术分享。业界的测试专家也普遍进入一个迷茫期，很多测试专家转型敏捷教练、DevOps 流程专家。和几个专家聊了一下，也普遍感觉近几年业界对测试的关注已经逐步偏弱。

另外一个是内部的例子。华为 2017 年应届生招聘已经启动，在启动材料中，明确说明华为已经取消了软件测试工程师的岗位，HR 认为现在的软件需要全栈工程师，开发工程师也需要具备自测的能力。

测试行业发展的顶峰应该在 2000 年后，Google 测试体系大肆宣传的那几年，市面上到处都是 Google 测试的书籍，自动化测试能力也得到业界的高度认同，整个 IT 界都在推广自动化，一个测试专家仅靠自动化能力就会获得比较高的薪资。而近几年随着软件技术的快速发展，技术知识越来越容易获取，技术的迭代周期也不断加速，技术门槛也越来越低。在这种大背景下，专职测试的必要性也在不断受到挑战，特别对于一些创业类的小型公司，在没有专职测试的条件下，产品也能得到市场的认可。

随着软件开源社区的快速发展，软件工具的易用性也在不断加强，各类开发和测试框架层出不穷，技术人员可以很方便的使用框架代码实现自己的需求，按照公司的说法是我们无需自己造轮子。各种轮子的使用，让业务开发变得更加便捷，这也是为什么华为的软件可以使用大量合作的原因，也许不久的将来，这个行业真的会变成劳动密集型行业，未来受到冲击的可能不仅仅是测试和运维，开发一样存在在行业危机。

软件工程方法也在不断演进。以近期盛行的 DevOps 为例，该流程倡导一种全功能团队的运作模式，团队中的各个角色分工相对模糊，开发需要投入自测和运维，这种开发模式体现了及时响应，及时改进的快速迭代思想，提升了对开发的要求，但是对于运维和测试角色，造成了一定冲击。

传统的软件测试，特别是通信类产品和大型的 To B 类软件，对交付质量较高，有很高的门槛。一个测试专家需要了解无线交换、数通网络、小型机、软件、各类信令。专家到各地开局时，往往是单枪匹马，一人搞定，受到办事处同事的敬仰膜拜。记得有次给客户演示 VPN 短号，业务服务器故障一直无法定位，征得客户的同意，直接在交换上做了一个号码变换，先解决演示的问题，当时测试人员要求的技术广度远超于开发人员。

但是近几年，通信业已经无法阻挡软件化的趋势，随着 CT 技术门槛也在不断降低，华为也正喊出了 CT 转 IT 的口号。软件的微服务、云化等技术，让测试人员工作也不断简化，很多新来的同事对直接使用计算云部署环境，对物理服务器的了解也是一知半解，在知识广度方面可能和开发持平，而在深度方面，又不如开发，测试技术不在存在门槛，角色的必需性正在不断的弱化。

华为大部分部门的测试开发比在 1：3 或 1：4 这个比例，这在业界是比较高的，比例高有两方面原因，一方面是和我们的通信软件质量要求比较高有关，需要多轮的验证，需要大型解决方案的交付。另外一方面和华为的 IPD 流程相关，大量的测试交付件，大量的评审和会议，为了确保大家步调的一致性，行管部门还是定期进行飞检和数据晾晒。严谨的流程保障也是有利有弊，从好处来看，可以确保软件的质量不会出现大的问题，适合软件开发的大兵团运作，弊端来看，严重影响到软件的生产效率。

从华为对测试角色的定位看，测试需要承担三种职能角色，一种是管控角色。测试人员就像就像沙丁鱼箱中的鲶鱼一样，不断的通过各种数据，各流程，驱动上游团队持续的保持活跃，进行相关的改进。并且测试作为研发的一个环节，本身也要提供相关 TR 点的素材，配合提供项目的各类测试交付材料。在大型的团队中，这部分的流程和数据还是非常受到领导重视，因此也产生了很多华为自有测试员工，过于投入流程和数据，而忽略业务本身的现象。

第二种角色是质量服务角色。就是测试要对产品投入实际的测试执行工作，发现版本的质量问题。在华为传统观念中，测试部应该对产品的质量负责，负责的重要标准就是测试部需要对版本进行一次完整测试，需要输出相关结论。在华为和开发和测试分工中，也是基于一种不信任的配合关系，测试人员不需要关注开发测试过程中已经验证了什么，版本转测试后，测试必须完整版本验证工作，从部门的角度给出最终的结论。而这种测试定位，在互联网领域中，已经逐步的弱化，只有关键的产品才会投入专职的测试专家进行测试设计和执行工作。

第三种是工程能力角色，类似 Google 的工程生产力部门，定位为提升研发过程效率和质量，输出相关工具和方法的支撑，提升整个研发过程的测试效率。目前这部分的专家主要集中在 2012 实验室和几个大产品线的工具部。而产品测试（业务测试）投入的能力建设，主要集中在 DFX 的特性测试以及自动化能力方面。

对于华为传统的 To B 类产品，测试投入的 1、2 两个角色职能的工作非常多，也占用了业务测试团队的大量时间，特别对于具体的测试执行，各产品线业务测试投入大量合作员工进行基础的测试保障。对于工具和测试能力的提升，2012 实验室的测试行业投入较多，在 6+1 测试工具有了一些成果，但是能力和业务还是有一定的脱节，行业专家不会介入业务太深，业务定制化的测试需求也较多，导致很多实际的业务测试效率问题，仍然需要业务自身解决。

我所在的云服务属于公司内少有的 To C 类产品。我们所有的产品都是无需向运营商交付的，对自有业务需求的控制比 To B 产品好太多，也可以在我们自有的环境上进行灰度发布，Beta 测试，很多快速交付的实践都在产品中落地，因此可以做到每月至少一次的迭代发布。

但是对于云服务测试来讲，也仍然面临的较多的问题。我们的测试开发比在 1：7 到 1：10，基本上一个人负责一个或者多个模块的测试，在华为的质量体系下，我们也是要遵从华为一些质量交付件，例如云服务需要与 EMUI 进行版本的配套，相关的测试交付还是要参考 IPD 的流程，所以在流程工作的投入上，测试人员投入的仍然很多，各类的会议也是很多。安全交付件更是如此，这是公司的红线。在组织职责方面，测试和开发的组织职责也可以相对独立，不存在开发自测交付的概念，在版本交付后，所有的测试的工作需要测试部独立承担，包括外部采购的合作项目，可能开发需要投入一个 PM，但是测试要完成所有验收。未解决测试执行覆盖的问题，也是大量使用了合作员工，合作自有比也超过 5：1，合作的流失和培养一直都是历史难题。

因为团队规模比较小，能力建设方面也主要采用合作的模式，依赖外部的测试能力和 2012 的团队，来推进云测， 6+1 等方面工作合作，测试的重点依然的是自动化，DFX 等方面。而对于业务体验等方面关注的力度并不足。交付类测试仍然是我们工作的主要方向。

虽然前面讲了很多测试的危机和问题，但是从行业发展的必要性来讲，测试是质量的重要保障，测试行业不可能被淘汰，我们只需要考虑如何让我们的行业价值更高，让自己不会被这个时代所抛弃。

公司一直倡导的都是工匠精神，但是软件行业和传统的手艺不同，我们所使用的工具在不断的变化，十几年前，我们还在使用 Basic、Pascal，但是现在已经是 Java 的天下了，软件的工匠精神不是比拼的是对语言和工具的熟悉，更多的在于软件系统的经验。

测试的定位，不是仅仅发现版本的问题，或者做简单测试技术工具的投入，而是应该定位更高一层，测试是整个产品的质量守护者，需要具备提前预防质量风险的能力，应该具备推进产品测试技术改进的能力，也应该具备产品研发过程中（含开发环节）测试效率提升的能力。测试能真正从客户角度去看待和发现问题，并推动客户质量满意度的不断提升。这个定位很高，实现过程也很难，我们现在普通的测试人员 80% 都是在测试的具体执行和一堆的事务性工作上，每日都在加班加点，很少有沉下心来分析问题的根因，通过学习不断寻找技术改进的方向。

从测试技术发展来看，测试的工具化或自动化肯定是未来的趋势，自动化的比例会不断的提升，但是机器的自动化短期内无法实现完全脱离测试人员的，仍然需要人工接入进行相关的自动化设计。从执行的特点看，测试分为两类，一类是固定场景的验证，一类是未知场景的探索。

对于固定场景的验证，有预期的输入和输出，无论是接口测试还是 LLT （底层测试），都是具备这个特点。测试人员的重点是将具体的场景抽象为自动化用例，提升回归测试的工作效率。对于基于 UI 的自动化，因为产品可能存在较大变动，UI 识别也存在部分确定性，我们可以量力而行或尽可能抽象为接口自动化。在自动化工作中，测试要对开发有足够的可测试性要求，产品具备良好的代码解耦的架构。

对于未知场景的探索，主要是针对没有对应测试设计的测试驱动。可以分为工具类的自动化探索，例如我们手机可靠性测试使用的 monkey，以及安全测试的 fuzzy 等。测试的场景由工具生成和决定。另外一种是人工的探索测试，这个概念近几年也比较盛行。但个人认为这种在可行性上还是有一定难度，对测试人员的经验要求较高，目前我们也并没有组织，主要通过 Beta 测试，引入大量普通用户完成各类场景的探索。

任何测试都是不能 100% 发现问题，网上问题的发生也是很难避免，测试需要尽量降低网上问题的级别和发生概率，并且需要具备较高质量风险防范的意识，对于高风险产品必须有双重（或三重）的防范机制。例如我们做一个支付类产品，可能会在存在某些质量问题，导致用户未支付的情况下，支付状态进行了更新（这个例子可能大家感觉不会出现，但是现实中有各类可能）。测试人员必须对产品提出，有额外的管控系统，对账号进行准实时的核查比对，确保收支一致。互联网有过类似的安全，2012 年某东积分兑换 BUG 的问题轰动一时。好的测试专家需要像扁鹊大哥一样，尽可能的识别和规避可能的质量风险。

测试人员的技能模型应该保持多样性的发展，在广度方面不断延伸，深度方面可以选择一两项技术进行不断挖掘。有三点需要测试重点关注：

编码能力：特别对于新员工，这个能力是与开发有共同语言的基础。测试人员需要了解对应业务的代码框架，构建工具，以及 LLT 测试，持续推动开发过程中的改进，能给予代码提出测试建议，将质量构建在开发阶段。

组网能力：测试需要对系统的组网，以及实际的部署情况有清晰的技术理解，这样才能发现更多的质量问题和隐患。这个说起来是比较简单，但是如果做到深入的了解，还是有很高的技术难度，例如我们现在各个业务使用的 CDN 和 DNS，如何组网可以让我们的系统体验会更快更好。用户使用的 UC、QQ 浏览器等是具备缓存加速，在缓存场景下是否会对某些业务特性产生影响。

业务能力：测试不能脱离业务，这也是为测试人员未来转型产品经理或其他岗位的一个必备能力。无论开发还是测试，能在整个职业生涯中，坚持到底的，是少之又少。大型产品线如有测试系统部之类的部门，如果脱离业务，纯粹投入技术规划或流程规划，往往会逐步被产品边缘化。

产品会有各类的隐患和问题，测试人员如果长期只发现简单的 BUG，不仅会让技能水平下降，而且会失去对工作的兴趣，我们只有通过工具或技术不断解决问题，才能挖掘测试工作的乐趣。

小编读后感

我想到了前一段读的一篇文章中提到《探索式软件测试》一书，作者 James Whittaker结合自己二十年的经验，从多个角度结合实例阐述了探索式软件测试的创新意识。他把测试职业发展的道路比喻为爬山，从初学者阶段到专家阶段之间存在着一个“测试的山峰”，人们需要通过一系列个人辅导、获取信息和接受常规指导来翻越山峰。成为一个测试初学者是很容易的，成为职业的测试人员也并不艰难，最难的是，如何翻越那座位于职业测试人员和测试专家之间的山峰。

随着互联网的电商、金融等公司蓬勃发展，这些公司的技术团队的规模也快速增长，应用规模快速扩大，测试环境日益复杂，测试力量也在不断变化，应用验证成本不断提升，软件产品的质量含义也在变。在之前的专栏中，百度资深测试工程师永哥也和大家聊了聊“软件质量的变迁”（点击查看原文），他提到：

所以：

千万千万不要把自己只当成一个纯手工测试人员

千万千万不要把自己只当成“找到最多缺陷的人”，而是“找到最有意义缺陷的人”

千万千万不要把自己只当成找bug的工程师，而是服务质量和产品品质的守护者

如果你看的意犹未尽，如果你想随时随地充实自己，请扫描以下二维码，关注我们的公众账号，可以获取更多技术类干货，还有精彩活动与你分享~