前端时间看了google测试之道，收获了一些，在此总结下并打算写一个系列blog，顺便分享给各位，也希望大家多交流，多讨论。另外需要强调的是我说到的一些google测试理论和淘宝的相关测试实践，并不代表所有淘宝测试团队都会这样去做，仅仅代表我的测试团队会做的一些思路上的改变和实践，肯定有不成熟的地方，欢迎讨论。最后需要强调的是，我这边得到的一些google做法仅限于google测试之道那本书，其他的我真不知道，如果有冲突不一致的地方，欢迎大家指出来。
为了让这些blog分享更有逻辑性，我打算分几个专题来分享google测试相关的测试理念。
google测试分享-SET和TE
google测试分享-分层测试
google测试分享-GTA
google测试分享-测试经理
google测试分享-问题和挑战
google测试分享-未来测试
首先我们看下SET和TE的简要说明，然后再看看他们的工作职责有何不同，在项目中发挥什么样的作用。SET就是测试开发工程师（software engineer in test），TE就是测试工程师（test engineer）。我们先不说国内是如何定义这两个不同的职位，也不去关心国内是如何把测试人员/测试工程师/QA 叫成 测试开发工程师，这个话题太大了，而且因人（公司、团队、文化）而异，在这里不讨论了，这里只说明google或理想中的公司是如何来区分SET和TE的。
首先我们看看自己团队中的测试人员是做了哪些测试活动：功能测试（手工和自动化）、性能测试、安全测试等。这里面我要强调的是功能测试的演变。
（1）测试人员从黑盒角度做系统测试，也从用户角度来进行测试设计和测试执行，包括系统质量的全面评估
（2）自动化发展起来了，特别是页面自动化测试，测试人员开始在项目测试上线后编写测试脚本进行自动化回归测试，同时之前的工作不变
（3）随着页面自动化测试的ROI越来越低，接口自动化测试开始了，测试人员在项目过程中或项目上线后针对产品的重要接口进行接口测试脚本的编写，同时之前的工作不变
（4）随着UT的重要性和开发自测的提倡，测试有时候还需要做UT和code review，还要做验收测试，同时之前的工作不变
个人感觉国内只要把测试工作里面包括编写自动化脚本的测试人员都叫测试开发工程师（偶尔也包括测试框架的二次开发等），这里先不谈专门的测试工具开发部门。
我们先来谈谈测试开发工程师（SET）的工作职责吧，首先SET的重点是从开发角度去做测试工作，会把主要精力投入在系统设计和编码阶段。开发人员关注某个功能最优实现方案，SET要有整体产品的视野。SET在设计阶段，帮助开发人员完成代码复用和模块交互方面的设计，SET在设计review的时候，保持目的性：完整性、正确性、一致性、设计、接口与协议、测试（可测试性）。SET的自动化测试相关工作包括隔离容易出错的接口，并针对它们创建mock和fake、构建一个自动化测试工程，控制mock系统的创建和运行，而开发人员使用这些mock接口做一个私有构建，针对这个构建进行自动化测试运行。
另外，SET的第一要务是产品代码的可测试性，同时作为整个项目的质量顾问提供给项目组其他人员关于质量保证的建议。他会主导UT和CT（组件测试）的测试执行工作，同时负责测试自动化体系的长期有效性。由于SET持续的关注自动化测试，他有可能会忽视人工跟踪bug库和每个发布的测试的重要性。但是由于他在系统设计和编码的深入，SET不仅可以看到树木而且可以看到森林；是对测试有强烈兴趣 和天资的开发人员。
接下来我们谈谈测试工程师（TE）的工作范围。首先TE的重点是从用户角度去做测试工作，会把主要精力投入在系统测试阶段，包括自动化回归和手工的探索式测试。TE可以在多个产品之间流转，了解不同的产品技术，为不同的产品进行系统测试和探索式测试。TE的重点在于评估对用户的影响以及软件产品整体目标上的风险，职责范围最广。TE可以从用户产生的影响的角度来说明为什么一个功能不能上线或整个发布不能上线。
从项目的角度来看，项目前期主要是SET的任务，项目后期是面向TE的任务。当然并非所有的产品都需要TE的介入。早期的产品测试计划TE投入不多（特别是UT和CT占主导的产品），后期产品接近尾声，TE引导做探索式测试。但是在需求阶段，TE擅长发现需求中的模糊之处，分析沟通不明确的地方，而且TE角色需要敏锐的洞察力和领导力，很多高级测试经理来自于TE。所有说TE的工作经常需要去打破常规流程，可以在任何时间进入项目，必须迅速评估项目、代码、设计和用户的当前状态，然后决定首要的关注点（这些东西在国内公司的测试团队中从来不被重视，他们认为no code，talk is cheap）。
这里罗列下TE的主要职责：测试计划和风险分析；需求评审、设计、代码和测试；探索式测试、用户场景、编写TC、执行TC、众包、使用统计、用户反馈。我们都知道项目的过程中，风险始终存在的，那么TE是缓解风险活动的协调人，决定对风险较大的领域进行内部测试，要求开发人员和SET增加回归测试。也可以借助dogfood用户、beta用户以及众包进行测试。TE对风险最高的领域负有个人责任，必须编写测试指导（类似于测试方案）。
真正在项目过程中，TE是需要TE了解SET和开发人员的测试后，评估这些测试对风险的影响。高风险区域的每个bug都应该有一个回归测试用例与之对应。TE还要仔细思索高风险的区域，咨询可能的回滚和恢复机制。对于风险较低的区域，可以降低要求，为这些区域编写特定的测试用例是得不偿失的，我们更多的是选择探索式测试，或众包测试。还需要强调的是，TE也会在项目过程中进行系统测试级别的自动化测试脚本编写、CT和ST的自动化测试监控和脚本维护工作，但这不是他工作的核心。
总体来说，TE是稀缺个体，是技术人，关注用户，能在系统疾病和端到端的视角上理解产品。他们是无情的、伟大的谈判专家，最重要的时，他们富有创造性、善于应对模糊性。
如何招聘到好的TE呢，我们需要考察候选人计算机科学和技术技能，也要测试潜力。TE经常能担当领导角色，因为和SET相比，他们站的更高、看的更远，能给理解各自设计问题和风险。我们寻找的是对于事物结构、对于变量和配置的组合的各种可能性和意义的好奇心。是关于事物应该如何工作的强烈感觉以及清晰表达的能力，这里的要点是，给出一个需要各种输入和环境条件的测试问题，请候选人列举出最有意义的可能。另外，就是要考察TE所需要的处理模糊性、反驳槽糕想法的能力。还要考虑比如给开源项目提bug、通用化自己的工作以提高复用性的人。
TE经常在系统测试阶段应用探索式测试的测试方法，而应用探索式测试，首先快速找到哪些测试模式适用于被测产品；多观摩团队其他人提交的bug、讨论发现策略，对每个人来说都是一种极好的学习体验。
SET可能会忽视人工跟踪bug库和每个发布的测试的重要性。TE负责组织包括SET在内的整个测试团队的测试战略。当SET不清楚从何处开始实现测试霍工具时，TE会展示最需要测试的地方并以bug数据做支持。TE还能用真实数据说明他们的方案在预防bug方面的有效性如何。
在google，自动化测试发现bug的比例很多，相比于手工测试。最后，一个令人赞叹的产品背后，总有一个构成多样性的测试团队，包括SET和TE。
----后记
对于TE的描述，某些人可能觉得比较虚，还是SET经常写code实在。国内的测试团队，基本上把SET的工作和TE的工作合二为一，放在一个人的身上，大家其实也看到了SET和TE的技术和要求是不一样的，我们测试团队的测试开发工程师都能很好的具备SET和TE的能力吗，我们真正的测试工作重心到底是什么呢？我们的测试开发工程师都能在产品的测试过程中发挥这么多的作用吗？大家可以自己思考下。
说实话，SET和TE在google的自动化测试过程中的具体差异和细节讲的不是很清楚，没关系，下一个主题会描述的更加清楚。下一个主题：google测试分享-分层测试。
转载自：http://blog.sina.com.cn/s/blog_6cf812be0102vbnb.html
作者：JerryGao
