google软件测试介绍
质量不等于测试
质量不等于测试。停止开与测试的隔离队里，开发和测试应该并肩齐驱，你需要在写完每一段代码之后立即测试这段代码，当完成了更多的代码时就要做更多的测试
质量是开发过程的问题，而不是测试问题
角色
软件开发工程师（SWE software engineer）
软件测试开发工程师（SET software engineer in test）
测试工程师（TE test engineer）
版本
金丝雀版本：每日够要构建的版本
开发版本：开发人员日常使用的版本，一般每周发布一个
测试版本：通过了持续测试的版本
beta或发布版本：由非常稳定的测试版本演变而来
测试类型（着重强调测试的范畴规模）
小型测试：一般都是自动化实现，用于验证一个单独函数或独立功能模块的代码是否按照预期工作，着重于典型功能性问题、数据损坏、错误条件和大小差一错误等方面（一般运行在fake环境中）
中型测试：通常也是自动化实现。一般会涉及两个或两个以上模块之间的交互。重点在于验证这些功能近邻区之间的交互（一般运行在fake或者真实环境中）
大型测试：涵盖三个或以上的功能模块，使用真实用户使用场景和实际用户数据，关注的是所有模块的集成，更倾向于结果驱动，验证软件是否满足最终用户的需求
软件测试开发工程师
编写功能代码和测试代码在思维方式上有着很大的不同
一个产品如果在概念上还没有完全确定成型时就去关心质量，这就是优先级混乱的表现
70/20/10原则：70%小型测试，20%中型测试，10%大型测试。如果项目面向用户，拥有较高的集成度或者用户接口比较复杂，应该有更多的中型和大型测试；如果是基础平台或者面向数据的项目，则最好有大量的小型测试
SET的面试重点是考察候选人如何思索问题的解决方案，而不是解决方案本身的实现上有多么高雅
测试工程师
ACC attribute component capability ，即特质、组件、能力。这是一种测试计划的替代方法
ACC知道原则如下：
避免散漫的文字，推荐使用简明的列表
不必推销
简洁
不要把不重要、无法执行的东西放进测试计划
渐进式的描述，make it flow
指导计划者的思路
最终结果应该是测试用例
ACC通过指导计划者依次考察产品的三个维度达成这个目标：描述产品目标的形容词和副词；确定产品各部分、各特性的名称；描述产品实际做什么的动词。
影响风险的因素很多，试图精确地、定量地计算风险比缓解风险还要麻烦，在google，我们确定了两个要素：失败频率和影响
风险缓解，一个极端的缓解办法就是去掉风险最大的组件：交付的软件越少，风险就越小
缓解风险措施：
围绕风险大的能力点编写用户故事，并从中确定低风险的使用场景，然后反馈到开发团队，请他们有针对性地增加约束
编写回归测试用例，以确保问题在重现时可以被捕捉到
编写和运行引发故障的测试用例，来推动开发实现恢复和回滚的特性
插入监听代码，以便更早地检测到故障
插入代码监听软件，发现新旧版本间的行为变化以发现回归问题
指南：
对高风险的能力点和特质，一定要编写一系列用户故事，用例或者有针对性的测试之道
认真了解已经完成的面向SET和SWE的测试，评估这些测试对所暴露的风险级别的影响
分析每个高风险的特质，能力对应相关的bug，保证回归测试用例存在
仔细思索高风险的区域，咨询可能的回滚和恢复机制
引入尽可能多的相关各方
为低风险的领域编写特定的测试用例是得不偿失的，我们可能会选择进行探索式测试，或者使用众包去测试这些领域
