入职华为以来，一直做的是测试工作，这种危机感在近几年愈发强烈，一直想总结一下，但又担心总结不好，动摇军心。但该面对的早晚要面对，需改变的也要尽早改变，一定要有革自己命的勇气。
　　危机的预兆
　　举两个测试行业危机的例子：
　　一个是外部例子。近期参加了几个测试行业交流，测试技术分享方面并没有什么新的发展，还是自动化、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% 都是在测试的具体执行和一堆的事务性工作上，每日都在加班加点，很少有沉下心来分析问题的根因，通过学习不断寻找技术改进的方向。
　　从测试技术发展来看，测试的工具化或自动化肯定是未来的趋势，自动化的比例会不断的提升，但是机器的自动化短期内无法实现完全脱离测试人员的，仍然需要人工接入进行相关的自动化设计。从执行的特点看，测试分为两类，一类是固定场景的验证，一类是未知场景的探索。