入职华为以来，一直做的是测试工作，这种危机感在近几年愈发强烈，一直想总结一下，但又担心总结不好，动摇军心。但该面对的早晚要面对，需改变的也要尽早改变，一定要有革自己命的勇气。
危机的预兆
举两个测试行业危机的例子：
一个是外部例子。近期参加了几个测试行业交流，测试技术分享方面并没有什么新的发展，还是自动化、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，不仅会让技能水平下降，而且会失去对工作的兴趣，我们只有通过工具或技术不断解决问题，才能挖掘测试工作的乐趣。
免责声明：本网站内容主要来自原创、合作伙伴供稿和第三方自媒体作者投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。任何单位或个人认为本网站中的网页或链接内容可能涉嫌侵犯其知识产权或存在不实内容时，应及时向本网站提出书面权利通知或不实情况说明，并提供身份证明、权属证明及详细侵权或不实情况证明。本网站在收到上述法律文件后，将会依法尽快联系相关文章源头核实，沟通删除相关内容或断开相关链接。
