我之前在传统行业做软件测试，认为软件测试就是发现开发代码中的bug，通过需求评审、开发设计评审、测试用例评审、执行测试用例、线上验证发现代码中的问题。测试角色所掌握的基本技能中不用包含开发能力、牵头能力、整体项目的风险把控、跨组织跨团队的组织协调能力。
但是这种思想是存在问题的。我去年跳槽到了BAT的头部互联网公司，才突然发现测试能干的太多了，绝非只有手工点点，没有技术的工作。结合在头部互联网公司的测试经验，总结下其他小型企业的测试可以转型的方向和践行的路。
第一：搭建造数平台，即测试平台。测试团队应该产出平台型项目，提高测试部门的技术能力，同时有助于提升团队中的个人能力。该平台产出后，使用方不局限于测试内部人员使用，可以是产品验收的工具、开发造数的工具，提升整体团队的工作效率。平台内部实现逻辑，不但局限于调用应用的api接口，也要开发一定的代码，聚合不同业务线的服务，提供部门乃至公司级别的造数服务。通过这个平台，也可以看到公司的核心业务及系统流转。
第二：参与codereview。在头部互联网公司，测试人员辅助开发、业务的趋势越来越弱，演变成了研发流程、生产发布流程中很重要的角色。测试人员只靠功能测试不再满足于日常需求，因为需求变动大，开发变动快。测试人员要进行cr才能了解核心的代码逻辑和设计思想，这样也有助于脱离开发自己承接需求和分析影响。如果能再cr过程中提出有价值的改进意见，这样测试的影响力会更大。
第三：进行红蓝演练。做这件事情的目的在于检查开发人员发现问题的能力、及时性，同时考察系统的监控能力、核对能力。在头部公司，可监控、可灰度、可回滚是生产发布的三板斧，缺一不可。因为一旦出现一点问题，如果不及时发现，可能最终会造成很大的影响。但是这项事项在执行的过程中，需要公司具有一定的基础架构能力。如果公司能保证每项需求都有监控、核对，这个操作也可以不用执行。当然保证的方法有很多，其中一个最有效的方法就是，人肉check有没有加。
第四：doom。录制线上流量，线下回放。保证接口做了改动时，利用doom回归，就可以检查出来是否有问题。虽然看起来提效了，保证了系统的稳定性。但是doom维护起来很复杂，很耗时。如果公司内部没有多余的人力物力搞doom，也可以先往后放放。
第五：核心用例自动化。实现核心用例自动化，可以大大节省回归测试时间，同时也可以让开发人员自测，让测试人员腾出时间做别的事情。编写自动化代码是要贯穿到日常需求中，如果不做的，日积月累，欠的债就会会越来越多，最后就不做了。
第六：线上巡检。这也是一种主动发现问题的手段。同时也是要依赖一定的技术支持。如果在有多余的精力下，可以调研一番并落地。这样你的技术也会得到不少的提升。
综合起来，测试要做的事情太多，业务测试、技术支持、提效工具、技术创新、稳定性、性能测试等这些方面都是可以钻研并深入学习实践到工作中的。欢迎各位同道中人发表自己对于测试行业的看法~大家一起学习一起成长。
