软件测试介绍

少则清晰，测试人员的稀缺导致测试资源很昂贵。（不要招聘太多的测试人员）

质量不等于测试

开发对质量负责（预防行为，不是检测）

卫生间张贴着最佳测试实践

角色介绍

• SWE（Software Engineer）

• SET（Software Test Engineer)

• TE(Test Enginee)

SET也是开发角色，100%时间（不可能吧，严）在编写代码，SET和SWT是合作伙伴

工作重心在可测试性和通用测试基础框架

参与设计评审

为了增加可测试性，甚至会对代码重构

关注质量提升和测试覆盖率增加

SET和SWT是合作伙伴

TE是产品专家，质量顾问和风险分析师

大量时间在模拟用户的使用场景的代码上。

组织结构

测试是独立的部门（工程生产力团队），以租借的方式进入产品

不同项目组的借调，时刻保持新鲜感，也方便好的测试想法快速蔓延。

推广创新技术，直接借调创新的发明者是一个很好的办法

爬走跑

金丝雀版本（每日构建）

开发版本（每周）

测试版本（每月最佳）

发布版本（稳定的测试版本）

测试类型

Google用小型，中型，大型测试（对应我们的单元，集成，系统测试）

小型测试

函数或模块，需要使用mock、fake

中型测试

模块之间的交互

大型测试

真实用户场景和数据

软件测试开发工程师

理想的软件世界，有test harness， test infrastructure，mock and fake任你使用（如，模拟的数据库）

测试代码的主要思路是去破坏，怎样写测试代码以扰乱分离用户及其数据

SET的工作

公共库，共享代码。可复用性大于功能复杂性和设计巧妙性

公共模块必须经过审核

开发人员有编写出干净代码的记录，会被授予“良好可读性”证书

每种语言都有统一的编译器（类似我们的统一开发服务器）

构建系统使用统一的打包规范（和语言无关，linux rpm）

一个产品有多个服务组成，服务之间并行开发，项目早期定下服务之间的接口。早期测试，接口都是虚假的实现

SET非常难招聘（又懂开发又懂测试）

“只有软件产品变的重要的时候质量才显得重要”

产品早期一般不投入测试（可能重新设计），正式批准后，才会寻求测试资源。

项目初期，设计文档(动态更新)

SET有一个巨大的优势，就是产品方面最宽广的视野

SET审核初期阶段的设计文档

接口、协议，采用protocol buffer

可测试性如何，是否需要新增testing hook（为了测试增加接口，显示系统内部状态）

协议与接口

protocol buffer定义的接口和协议由SET实现（SET第一个实现所有的接口和协议），集成测试的运行依赖这些接口，因此SET针对各个模块的依赖提供了mock和fake

自动化计划

试图自动化所有端到端的测试用例，是一个常见的错误（SWE也不会感兴趣）
自动化投入越多，维护成本越大。自动化计划，应该规模更小，目的性更强

端到端的自动化测试投入过度，会把产品特定功能绑定在一起，产品稳定之前都不会特别有用。SET应该投入到提高质量，而不是维护不稳定的测试套件上。

可测试性

SET第一要务是可测试性，提供程序结构和代码风格建议给开发人员
代码审查需要工具和文化的支持，google将代码审查作为开发流程的中心，代码审查比编写代码更值得炫耀。
只有被证明是值得信赖的开发者，才有往代码库提交代码的资格。用“可读性”区分有资格的提交者和新开发人员。
CL（change list），持续提交优秀的CL，获得“可读性”的代码审查资格。（先要写好代码，才能当这方面的评委，严）。
自动化检查代码风格是否符合要求（这一块，我们需要补上，严）
在与外部公共库（或框架）有交互的地方需要依赖集成测试
项目成员轮流做“构建警察”(我们可以借鉴，每人轮流跟踪jenkins的输出）
TAP(Test Automation Program)

SET工作流程（实例）

详见书籍
（google可以做到修改一个代码，只跑这个模块的单元测试？严）
基于googletest
样例中，将_test后置
xxxx.cc（正式文件）
xxxx_test.cc（测试文件）

测试执行

只有能加速开发过程的自动化测试才有意义，测试不应拖慢开发的速度
新增测试程序，会创建一个构建说明文件（测试名称，源码文件，依赖库及数据，规模大小）。工程师通过一条指令即可触发构建、运行自动化和展示结果（我们有这样的东西吗？现在的方式是必须提交代码，jenkins才会运行，严）

测试大小的定义

小型测试，外部服务（文件系统，数据库，网络）必须通过mock和fake里实现
中型测试，主要目标是验证指定模块之间的交互

测试规模在共享测试平台的使用

测试规模的益处

google维护着不同测试类型之间的健康比例，全部使用大型的端到端自动化测试是错误；全部使用小型的单元测试也是错误的
不同类型的测试都有覆盖率报告（命令行加一个选项即可在浏览器查看覆盖率）（我们的中、大型测试还没有覆盖率报告）
经验法则：70%是小型；20%是中型；10%是大型
如果面向用户，集成度高，用户接口复杂，增加中大型测试比例
基础平台或面向数据，增加小型测试比例
(google的Harvester是一个可视化工具）

测试运行要求

可以设置一个标记以随机顺序执行用例（任意顺序也意味着可以并发）
google的持续集成做了优化，利用依赖分析技术，一个代码变更只运行影响模块的测试（我们能做到吗？严）

测试认证

对开发人员做测试这个文化有巨大的帮助
测试认证是一个富有声望的事情，从1级到5级（有徽章，可以炫耀）
（1-5级对应的内容在书的Page55,56）

与测试认证计划创始人的访谈

级别1：基本操作，还有去除所有非确定性测试（结果不确定的测试），挑选冒烟测试；
级别2：提高增量覆盖率
级别3：测试新增代码
级别4：测试历史遗留代码（针对可测试性做重构）
级别5：更高的覆盖率，每个缺陷对应增加测试用例
通过ToTT（Testing on the Toilet）和其他活动把测试搞得充满激情、趣味和吸引力，包括fixit
针对没有”测试时间”的状况，寻找下面的团队：有兴趣；没有太多冗余代码；有测试战神
试点项目，测试教练帮助团队，各种宣传，积分系统等
团队的测试认证级别代表提高测试的重视程度，是工程生产团队决定是否投入有限测试资源的重要参考指标
最困难的一步“所有的重要代码变更，都需要测试”，遗留代码缺少可测试性（长远角度就是重构增加可测试性）0生巨大的影响
如何用acount(void *s)返回字符串中'A'的次数，有详细的区分普通、更好、优秀的候选人的方法（Page63-67）（这个可以借鉴，严）

测试工程师

TE starting from middle（从头介入不适用于google，因为早期功能不断变化，TE没有太多工作可做）
配备多少测试人员，取决于项目风险和投资回报率
Google只有少数团队采用word文档通过邮件来传递（很老派）
google的文化是分布式和自我管理（大政府理念会受到嘲弄）
ACC（Attribute Component Capability）是测试计划的替代方法
Attribute是区别于竞争对手的关键。测试用例关联到这些标签，就知道哪些Attribute已经完成多少测试。
Attribute和Component要求简洁，Capability描述完整的功能
能力最重要的一个特点就是可测试性
Attribute作为行，Component作为列，形成的表格，每个单元格里都是不同的能力（多条）。
用户故事可以用一系列能力来描述
采用风险分析，将单元格附上颜色
风险分析需要不同人的意见。有个方法很给力，先完成一份，然后发给不同的人，他们发现偏差就会提出意见（树个靶子）

bug的生命周期

google使用buganizer管理bug，分为P0到P5（P0最糟）
当bug到达的速度超过团队修复的能力时，不进行新功能的开发（google强烈推荐这种实践），有助于控制住bug

TE的招聘

寻找正面的价值观：用不那么极端的输入，一遍又一遍的测试用以模拟真实使用场景，保证通用情况下，软件的运行不会出错

google的测试领导和管理工作

海盗领导力：船员武装到牙齿，才能卓著，不愁去处，船长怎么管理这些人？（无法通过强力和恐惧，船员的动力在于劫掠的生活方式和下一次收成的兴奋感）
要靠技术洞察力，令人兴奋的技术冒险，有趣的停靠港口来领导团队
谷歌领导和管理：mentoring and guiding, not dictating

Google Test Analytics

是否有GTA类似的软件供我们使用

与lindsay webster访谈

go-to tester（有困难就找她）
从头到尾理解产品，包括各种文档
代表客户
坦诚某个组件或领域不由自己负责，开发反而尊敬你

测试工程经理

测试工程经理具备TE和SET技能，并具有足够的管理技能
独立贡献者向测试经理（manager）汇报，资深工程师和技术负责人直接向总监（director）汇报

影响力

google特别强调影响力

ankit mehta的访谈

进入一个新项目，头几个兴趣都是在倾听（无法接受医生观察我不到5分钟就开出抗生素的药）
问为什么要做这个测试，很多开发不思考，只做他们知道怎么做的东西或看别人怎么做就怎么做。应该是能提高产品质量，提高工程师开发效率的东西
团队的文化和氛围很大程度来自团队那个资深的人
管理的同时保持技术敏锐

• 留下一部分工作自己做
• 排除干扰（去了另外一个地方工作，干扰少，产能很高）
  只选用最好的人，绝不动摇
  经验：
• 测试和开发采用相同的语言
• 关注测试基础设施建设，让测试更容易
• 20%的用例覆盖了80%的使用场景（自动化这些）
  年轻的测试工程师可能一上来就干，没有思考为什么要写这些测试

Hung Dang的访谈

如果自动化不能带来明确的价值，我们就废弃它

测试总监

Shelton Mar

测试技术必须融入项目团队，需要非常强的工程师

Brad Green

google聘用的都是极端自我驱动力的家伙，“按我说的做”用多了，这群聪明的家伙就会不理你而去做他们觉得最该做的事情（google style， 表面上答应你，后面干自己的事情）

James Whittaker

我发现没有比开发工具更能激发测试人员的创造性和团队士气了（我们是否可以借用，严）
我对google最满意的两件事：测试人员向测试人员汇报；测试人员自己决定自己的发展
Google测试的秘方：技能（测试人员的技术能力）、稀缺性（获得开发人员的帮助）、自动化、迭代集成

google软件测试改进

google的测试流程概况：让每个工程师都注重质量

google测试流程的致命缺陷

• 测试成了开发的拐杖（测试变得越简单，开发越不会去做测试）
• 测试人员更关注自己的角色，而不是他们的产品
• 测试人员崇拜测试产物胜过软件本身（所有测试产物的价值，在于他对代码的影响，再通过产品来体现）、

SET的未来

SET的未来就是开发
测试代码要成为一等公民，由PM管理，由SWE编写
测试功能特性开发应有团队的新成员负责（必须学习产品的所有东西，包括内部设计），是一个非常理想、最佳的热身项目。

结论

软件开发的问题已经彻底改变，继续死守数十年之久的测试教条无异于刻舟求剑
集中测试部门逐渐下发到项目，让他们更敏捷，更少关注测试流程，更多关注产品本身。
测试工程经理是最强的产品专家