业界实战介绍-Google

• Google的迭代测试架构

1. 简单来说 Google 的迭代测试架构如下：

1.1 按照测试版本

1.1.1 金丝雀版本

        使用频率：每日都要构建
        使用人员：工程师、管理人员    
        目的：用来排除过滤一些明显不适宜的版本。

1.1.2 开发版本

        使用频率:一般是每周

        使用人员:开发人员日常使用    
        目的:判断是否能满足日常真实工作的需求    

1.1.3 测试版本

        使用频率:每个月的最佳版本

        使用人员:工程师，可能给外部合作伙伴 

        目的:可以被挑选为内部尝鲜版本，也可以作为 beta测试的候选版本。   

1.1.4 beta或发布版本

        由非常稳定测试版本演变而来，是对外发布的第一个版本。    

1.2 按照测试类型

1.2.1 小型测试

        一般来说(并非所有)都是自动化实现
        目的：验证一个单独函数或者独立功能模块的代码是否按照预期工作，着重于典型功能性问题、数据损坏、错误条件和大小差一错误。

        执行人员：一般由SWE来实现，少量由SET，很少由TE.
        通用称呼：通常就是单元测试，和外部隔离且没有依赖。

1.2.2 中型测试    

        通常也是自动化实现，会涉及两个甚至更多的模块交互。    
        目的：验证这些“功能近邻区"之间的交互，以及彼此调用之间的功能是否正确。

        执行人员：SET会驱动这些测试的实现和运行;    SWE会深度参与、一起编码、调试和维护这些测试。在开发后期TE会通过手动的方式或者自动化的执行这些用例。
        通用称呼：集成测试

1.2.3 大型测试    

        自动化测试、或者探索式测试
        目的：关注模块的集成，更倾向于结果驱动，验证软件是否满足最终用户的需求。    
        执行人员：SWE,SET,TE
        通用称呼：系统测试或端到端测试

1.3 激励机制

        目的：让开发重视测试工作
        测试认证描述：如果一个团队完成了一系列测试任务，这个团队会得到一个通过“认证”的标识。最初级别是0，掌握的基本的优秀代码习惯是1，然后继续通过水平考核,最终达到5。

• 在Google，TE的主要职责包括：
• 

• Google的测试人员结构

2. Google 的测试人员架构

2.1 测试部门

        在Google，软件测试团队归属于一个被称为“工程生产力”（Engineering Productivity，也翻译成工程效率或者工程生产率）的中心组织部门，这个部门的指责横跨开发测试人员使用工具的研发、产品发布和各自级别的测试，从单元级别的测试到探索性级别的测试。

2.2 测开比例

        Google开发和测试的人员比例可能是10:1，甚至更大，在测试人员如此缺乏的情况下，写代码的开发人员也承担了质量的重任，在Google每一个写代码的开发者本身就是测试者。

        在Google，开发和测试融合在一起，开发和测试必须同时开展，他们认为开发者比专职的测试人员更适合做测试工作。

2.3 测试职责

        在Google，那些被认为是专职的测试者的人，他们实际的职责是让其他的工程师更有效率和质量意识，很大一部分体现在避免因马虎粗心而导致的返工。

2.3.1 Software engineer   

        开发部门 SWE的代码。负责自己的模块测试。开发角色，传统意义上的，实现最终用户所使用利用SET的成果来测试自己开发的的功能

2.3.2 software engineer in test

        开发角色，工作重心在可测试性和通用测试基础框架上，几乎花费百分之百的时间在编写代码上，供SWE测试自己的功能。

        SET是SWE在代码库上的合作伙伴，更关注于质量提升和测试覆盖率的增加。
        生产力部门模块，以及令人惊叹的自动化。 SET应该关注于高质量的、可测试的、可复用的

2.3.3 Test engineer    

        TE关注点，即把用户放在第一位来思考。测试角色，和SET关系密切，有自己的不同的关

        TE是真正的产品专家、质量顾问和风险分析师。

2.3.4 不同人员之间合作方式

        方式：测试人员(SET和TE)基本上以租借的方式进入产品团队
        汇报：测试人员并不是直接向产品团队进行汇报
        权力：测试部门有自己选择决定的优先级,在可
        两者合作方式配测试人员。靠性、安全性等问题上都不会妥协;可以自行分
        优点：SET和TE时刻保持新鲜感;好的测试想法可以快速在公司内部蔓延。(但是请注意，这一条是建立在Google的产品和服务很大程度上有比较强的集成关联关系，测试人员可以比较容易的保持相关的专业技能，从而自由穿梭。)

• Google的测试计划和风险

3. Google 的测试计划和风险

3.1 测试计划

3.1.1  愿景

        愿景应当在项目执行中发挥核心作用；应当在软件的整个生命周期中持续有效；随着代码库的更新而更新，时刻代表着最新的产品功能。

3.1.2 预期特性

        1）及时的更新

        2）描述了软件的目标和卖点

        3）描述了软件的结构、各种组件和功能特性的名称

        4）描述了软件的功能和操作简介    

3.1.3 最佳实践ACC建模方式

        1）Attribute Component Capability,即特质、组件、能力。整个ACC过程要快速行动，动态迭代。
        2）A代表特质，按照谷歌的定义，Attributes是产品的形容词( adjectives)，是与竞争对手相区别的关键特征.    
A代表特质  
        3）Component 组件 是系统的名词，在特质被识别之后确定。     组件是构成待建系统的模块;他们正是测试人员要测试 的对象。   
        4）Capability 能力是系统的动词，代表着系统在用户指令下完成的动作。他们是对输入和响应、对查询的赢啊、以及代表用户完成的活动。能力处于特质和组件的交点。组件执行某种功能    来满足产品的某个特质，这个活动的结果是向用户提供某种能力。
        最重要的特点是可测试性。

3.2 风险分析

3.2.1 失败频率

        1）罕见 rarely    发生故障的可能性很小，恢复起来也很容易。    
        2）少见 seldom 少数情况下会发生，但在使用场景复杂度不高的情况下，发生的可能性很小。    
        3）偶尔occasionally    故障的情形容易想象，场景有点复杂，该能力是比较常用的。    

        4）常见 often    所属的特性使用量大、复杂度高、问题频繁    

3.2.2 影响

        1）最小minimal    用户甚至不会注意到的问题    
        2）一些 some    可能会打扰到用户的问题    
        3）较大 considerable    故障导致使用受阻    
        4）最大maximal 发生的障碍永久性的损害产品的声誉，并导致用户不再使用它。