小课堂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特色，我们不可以完全照搬，但是解决问题的思路和衍生的众多技术成果却是非常值得我们学习的。