1.Google在平台方面有特定的目标，就是保持简单且统一。开发工作机和生产环境的机器机器都保持统一的Linux发行版本；一套集中控制的通用核心库；一套统一的通用代码、构建和测试基础设施；每个核心语言只有一个编译器；与语言无关的通用打包规范；文化上对这些共享资源的维护表示尊重且有激励。
2.最重要一点，SET是软件工程师，正如我们招聘宣传海报和内部晋升体系中所说的那样，是个100%的编码角色。这种测试方式的有趣之处在于它使测试人员能尽早介入到开发流程中去，但不是通过“质量模型”和“测试计划”的方式，而是通过参与涉及和代码开发的方式。这会使功能的开发工程师和测试的开发工程师处于相同的地位，SET积极参与各种测试，是测试富有效率。
3.SET与功能开发人员坐在一起。这样讲可能更公平一些，测试也是应用产品的一种功能特性，而SET是这个产品功能特性的负责人。SET参与SWE的代码评审，反之亦然。
4.在面试SET的时候，在代码要求标准上与SWE的招聘要求是一样的，而且增加了一个额外考核---SET需要了解如何去测试他们编写的代码。换句话说，SWE和SET都需要回答代码问题，而且SET还要求去解答测试问题。
5.一个产品如果在概念上还没有完全确定成型时就去关心质量，这就是优先级混乱的表现。许多来源于Google百分之二十努力的产品原型，在其后dogfood或beta版本发布时，还要经历重现设计，原始代码保留的概率几乎为零。很明显，在实验初期阶段强调测试是一件非常愚蠢的事情。
6.当然，物极必反，风险总是相对的。如果一个产品太长时间没有测试的介入，早期在可测试性上的糟糕设计在后期也很难去做改进，这样会导致自动化难以实施且测试工具极不稳定。在这种情况下，不得不以质量的名义来做重构。这样的质量“债”会拖慢产品的发布，甚至长达数年时间。
7.Google内部其实也并存着不同的文化。没有项目会认为如果得不到测试资源，他们的产品就将不复存在。开发团队在寻求测试帮助的时候，有义务让测试人员相信他们的产品是令人兴奋且充满希望的。
8. 作为工程师，SET在团队中有一个巨大优势，就是拥有产品方面最广泛的视野。通常来说，代码复用和模块交互方面的设计会由SET来做，而不是SWE。
9.为了能够尽早可以运行集成测试，针对以来服务，SET提供了mock与fake。
10.在端到端的自动化测试上过度投入，常常会把你与产品的特定功能设计绑定在一起，这部分测试在整个产品稳定之前都不会特别有用。
11.小型测试带来优秀的代码质量、良好的异常处理、优雅的错误报告；大中型测试会带来整体产品质量和数据验证。
12.检验一个项目里小型测试、中型测试和大型测试之间的比例是否健康，一个好的办法是使用代码覆盖率。如果中大型测试有20%的代码覆盖率，而小型测试有近100%的覆盖率，则说明这个项目缺乏端到端的功能验证。如果结果数字反过来，则说明这个项目很难去做升级扩展和维护，由于小型测试较少，就需要大量的时间消耗在底层代码调试差错上。
13.招聘到技术能强的测试人员只是刚刚开始的第一步，我们依然需要开发人员参与进来一起做测试。其中我们使用的一个关键方法就是被称为“测试认证”的计划。现在回过头来再看，这个计划对开发人员做测试这个根深蒂固文化的形成有着巨大的帮助。
苏公安网备 32011402010933号