记得前阵子，有个同事和我探讨软件测试工程师的职业规划，以及提到最近大厂里面较火的一个岗位，软件测试开发工程师，不少刚毕业的小伙伴对这个岗位都挺好奇的。
第一次看见测开这个字眼的时候是在《谷歌测试之道》这一本书中，老美10多年前就提出大力发展这个岗位了，再加上微软前几年大力发展的全面自动化测试，不少人对这些个岗位的印象就越来越多，而且误解也还不少。
重读了一遍《谷歌测试之道》，把我的观点分享给大家。
先看看《谷歌测试之道》对测开的一个注解：
软件测试开发工程师也是一个开发角色，只是工作重心在可测试性和通用测试基础框架上。他们参与设计评审，非常近距离地观察代码质量与风险。为了增加可测试性，他们甚至会对代码进行重构，并编写单元测试框架和自动化测试框架，测试开发工程师是软件开发工程师在代码库上的合作伙伴，相比软件开发工程师增加的功能开发代码，测开更关注于质量提升和测试覆盖率的增加，测开同样会花费近百分之百的时间在编写代码上，这样做的目的是为了质量而服务。
然后，再来看看《谷歌测试之道》对测试工程师的注解：
相比测开，测试工程师有不同的关注点——把用户放在第一位来思考，代表用户的利益。很多谷歌的测试工程师会花费大量的时间在模拟用户使用场景和自动化脚本的编写上。同时，他们会把开发和测开分门别类的组织起来，分析、解释、测试运行结果。测试工程师是真正的产品专家、质量顾问和风险分析师。
OK，我总结一下：
- 测开要做的事：单元测试、自动化测试、代码评审、测试框架编制等。
- 测试工程师要做的事：模拟用户场景，自动化场景，测试分析，风险评估等。
这么一对比，分工就很清晰了。
再来看看《谷歌测试之道》对于自动化测试计划是怎么说的：
设计文档：设计文档是动态的，测开需要用质量方面广阔的视野去调整并给出建议，并在审阅过程中，对质量和可靠性增加一些必要的内容
接口和协议：测开要对接口代码进行审查，在系统真正搭建起来之前，集成测试的运行依赖这些接口实现，因此，测开要对各个模块的依赖提供mock和fake的实现，在没有所有模块都实现的情况下，集成测试的代码就已经可以开始编写了。
自动化计划：开始不要尝试一下搞定所有端到端的自动化测试，忽然开展大规模的自动化测试，维护成本就会变得非常大，收益就会变得很低。在端到端自动化测试过度投入，常常会把你与产品特定功能设计绑定到一起去。在谷歌，通常会把容易出错的接口进行隔离，针对他们出mock和fake,创建一个轻量级的自动化框架，保证生态远离糟糕代码，并创建环境，保证开发工程师在提交代码前运行了相对应的自动化测试。
看了测开的工作职责，回过头来看看测试工程师的部分：
产品进行测试前的思考：
- 当前软件的薄弱点在哪？
- 安全、隐私、性能、可靠性、可用性、兼容性、全球化等问题？
- 用户场景？交互逻辑？
- 产品与其他产品之间的对接与交互？
- 是否支持快速排查问题，响应机制？
产品测试：计划--用例--bug生命周期--风险评估
测试后期：质量机器人（部分手工用例交付自动化）--探索测试
个人见解：关于测试工程师的活，知道的太多，也就不继续展开了，实际上，我认为未来的测试工程师更多的是一个测试分析师的活，在一些比较难以自动化的，逻辑复杂度较高的地方大展身手，能看到别人看不到的风险，对产品的熟悉程度更甚于产品经理。
《谷歌测试之道》书的后面还有对很多个部门的测试经理访谈的篇幅，关于如何打造一支优秀的测试团队，以及测试经理需要的一些优秀品质等。我总结一下，想成为优秀的测试经理：
- 第一点：去熟悉你的产品，对你的产品了如指掌。
- 第二点：知人善用，员工技能匹配度、员工个人意愿、项目需要、分配记录等。
- 第三点：建立影响力，项目价值，跨团队沟通等等。
最后，《谷歌测试之道》这本书发行8、9年了，很多观点在第一次读的时候和现在再去读的时候感受完全不一样。建议大家有时间一定要再去拜读一下。