小课堂week14 Google软件测试之道

读《Google软件测试之道》

在IT领域，Google是一面旗帜，是一家很是善于思考善于尝试的公司。随着面临挑战的不断增大，传统的测试开展方式也愈来愈力不从心，这本书讲述的就是一次完整的转型过程，很是的有价值。这是本老书了，一年多前就拜读过，当时更多看到的是差距和困难，随着一年的努力和尝试，忽然以为有点开窍，和你们作一些分享。

基本理念

Google在质量方面的基本共识是:

质量不是被测试出来的

具体的工做目标是：

让每一个工程师都注重质量

从业多年，这个口号其实常常能听到，可是大多数时候只是一个口号而已，很长一段时间，我甚至以为开发人员缺少质量意识已成为了一种天性，如何破开这块坚冰，Google也许能带来点启示。

组织变革

Google的变革是从组织开始，面临的是几个比较大的问题。

测试部门是否须要保留?
从思惟角度说，开发是一种建立思惟，而测试是一种破坏思惟，二者是没法同时兼容的。
一个部门是比较难兼容两种思惟方式的，因此Google保留了独立的测试部门。

测试部门的定位如何？
新部门的名称叫作 Engineering Productivity工程生产力部门
从部门的名称就能够看到，主要关注生产力提高方面

工程生产力部门如何工做?
关键在于人员的分工，主要有两类角色SET和TE
TE(测试工程师)和常规测试角色相似，主要负责功能层面的验证
SET(测试开发工程师)这是一个全新的职责，其目标是帮助开发人员进行测试

Google变革的核心是新增了一个全新的角色SET，这个角色主要起到了开发和测试的融合剂，也是把质量意识进行普及的关键。

测试分类

SET这个角色是如何协同工做的，关键是Google的测试分类。

测试分类是这样的：

小型测试：单元测试。
中型测试：两个或两个以上模块，关注功能交互。
大型测试：三个或以上，使用真实用户场景和数据。

初看到这个分类，我是感受有点凌乱的，命名上也太不严谨了。
从技术角度，对三类测试有个更详细的区分，明确了不少。

	小型测试	中型测试	大型测试
时间	10ms内	1s内	尽量快
强制结束	1min	5min	15min
网络服务	模拟	仅本地	是
数据库	模拟	是	是
文件系统	模拟	是	是
用户界面	模拟	不鼓励	是
系统调用	否	不鼓励	是
多线程	不鼓励	是	是

小型测试的特色是运行时间短，并且没有外部依赖。
并非符合全部条件就算小型测试，以下代码虽然符合，但仍然不算小型测试，由于其输出结果不稳定。

public String getString(){
        return new SimpleDateFormat("yyyy-MM-dd hh:mm:ss.SSS")
                        .format(new Date());
    }

三类测试的分工以下：

小型测试运行时间短、无依赖、输出稳定，这些特性无疑都很是有利于测试，大多数开发人员彻底可以胜任，全部小型测试是由开发人员SWE来负责。同时，小型测试是全部模块的基石，构成了这个质量体系的稳固基础。并非全部代码都能符合小型测试的要求，因此SET的第一个职责是帮助开发人员将代码重构符合小型测试。

中型测试会涉及到外部依赖和模块间接口，相对难度较高，因此主要由SET来负责，同时，SET会负责接口相关的开发。

大型测试主要面向用户，会由TE来负责。

在Google，SWE、SET和TE共同协做来完成质量工做，但三者之间有着严格的边界区分，小型测试数量庞大易于测试，须要的是细节逻辑的掌握，SWE负责最为合适；在此基础上，中型测试须要实现接口和外部依赖，专业性较强，由SET负责；大型测试主要面向用户和价值，由TE来负责。三者共同构成了质量的金字塔。

ACC测试法

TE角色因为小型测试和中型测试的支持，主要关注用户体验和业务价值。工做方法叫作ACC测试法。

A特性、C组件、C能力是一个矩阵表达法。每一项能力(系统功能)须要同时考虑功能和特性(业务价值)两方面。

	特性1	特性2	特性3
组件1	能力
组件2		能力
组件3			能力

ACC是一种测试计划的安排法，和传统的树形结构相比，增长了特性的维度，突显了业务价值。可是这种方法主观性比较大，对测试人员有必定的要求。

小结

书中对于SET和TE的工做有着较为具体的描述，限于篇幅就再也不赘述。整本书读下来，让我印象最为深入的Google解决问题的思路。面对质量这个业界的巨大难题，Google的作法不是口号，也是否是革命，而是面对每一个具体问题，进行了很是人性化的解决，将一个很是大的问题进行了分解。虽然其解决方法有着浓重的Google特点，咱们不能够彻底照搬，可是解决问题的思路和衍生的众多技术成果倒是很是值得咱们学习的。