《Google软件测试之道》——笔记（三）

组织结构-借调测试

        大部分情况下，开发与测试会向同一个产品管理者汇报，彼此是一个团队，照理说会平等相处、患难与共，但是实际情况是测试始终在向研发妥协。即使如笔者所在公司，测试与研发为独立部门，且测试直接向总经理汇报，这样的组织架构下，测试给研发让路也是家常便饭。遇到的理由诸如：设计如此、技术难点时间不足、项目时间不够先上线、客户催得紧先发布、代码不规范缺陷反复出现、质量不行就不断的发补丁包......测试疲于奔命导致漏测多，测试没有时间专注于复杂环境测试、性能测试中，在功能测试、黑盒测试中反复打转，更重要的是发号施令的领导们并不站在测试一边，验收至上。

        不断产出的有缺陷的、早产的产品仿佛让这个行业变成一个巨大的草台班子。（代码就这样神奇的运行起来了......）

        在Google，测试是独立存在的部门，他们被称之为工程生产力团队，测试人员也不会专职在一个产品上，他们依据不同产品团队的优先级、复杂度，然后用类似于租借的方式分配测试人员给产品团队。测试人员可以独立决定优先级，也绝不会在可靠性与安全性等问题上妥协。这种借调模式可以让SET与TE始终保持新鲜感，而新鲜感可以更好的暴露产品问题。这种模式使得测试人员可以更好的提升自己专业能力，在不同领域自由穿梭。

开发模式

Google经常在最初的版本里只包含最基本的可用功能，然后在后继的快速迭代的过程中得到内部和外部用户的反馈，在每次迭代时都非常注重质量。

        敏捷开发是行业内很多公司的现状，在Google，产品在发布之前，要经历金丝雀版本、开发版本、测试版本、发布版本。

        金丝雀版本：每日都要构建的版本，用来排除明显不正确的版本；

        开发版本：开发人员使用的版本，具备一定的功能并经过一些测试；

        测试版本：通过了持续性测试的版本，一般是最近一段时间内的最优版本，可是看做内部试用版本；

        发布版本：从十分稳定的测试版本演变而来，，经历了内部使用与质量考核，可对外发布。

        在Google，上述模式称为爬、走、跑模式，由慢变快，由简便繁，循序渐进。

测试类型

        与常规的单元测试、集中测试、系统测试不同，Google用小型测试、中型测试、大型测试来命名测试类型，这表示Google注重测试规模范畴还不是形式。

        小型测试：自动化实现，用于验证单独函数或功能模块的代码是否按照预期工作，注重功能问题、数据损坏、边界值错误、条件错误等。小型测试由SWE来进行，SET少量参与，TE几乎不参与。

        中型测试：自动化实现，用于验证模块间交互、彼此调用的正确性。由SET实现并执行中型测试，SWE深度参与并分析，TE手动执行一些非自动化的用例。

        大型测试：自动化&探索式测试，关注所有模块的集成，使用真实用户使用场景和实际用户数据进行测试，验证是否符合用户的需求，需要消耗较长的时间来执行用例。大型测试由TE主导，所有工程师均需参与其中。