读书笔记 - How Google Test Software

<How Google Test Software>(《谷歌如何测试软件》)的确为神秘谷歌公司揭开一层面纱，讲到了谷歌的代码文化和测试文化，讲到了角色划分，职责划分，测试种类划分，讲到优秀的不同角色的人应该具有什么样子的，讲到测试的创新和工具，还有大量的人物访谈。

这里的笔记主要包含：个人感兴趣的，值得备忘的，需要后续关注的东西记录。测试和质量都不仅仅是是测试人员的事情，还需要团队，公司的支持。

谷歌内部开发和测试角色和职责范围

The software engineer (SWE) is the traditional developer role. SWEs write functional code that ships to users. They create design documentation, choose data structures and overall architecture, and they spend the vast majority of their time writing and reviewing code. SWEs write a lot of test code, including test-driven design (TDD), unit tests, and, as we explain later in this chapter, participate in the construction of small, medium, and large tests. SWEs own quality for everything they touch whether they wrote it, fixed it, or modified it. That's right, if a SWE has to modify a function and that modification breaks an existing test or requires a new one, they must author that test. SWEs spend close to 100 percent of their time writing code.

The software engineer in test (SET) is also a developer role, except his focus is on testability and general test infrastructure. SETs review designs and look closely at code quality and risk. They refactor code to make it more testable and write unit testing frameworks and automation. They are a partner in the SWE codebase, but are more concerned with increasing quality and test coverage than adding new features or increasing performance. SETs also spend close to 100 percent of their time writing code, but they do so in service of quality rather than coding features a customer might use. 

The test engineer(TE) is related to the SET role, but it has a different focus. It is a role that puts testing on behalf of the user first and developers second. Some Google TEs spend a good deal of their time writing code in the form of automation scripts and code that drives usage scenarios and even mimics the user. They also organize the testing work of SWEs and SETs, interpret test results, and drive test execution, particularly in the late stages of a project as the push toward release intensifies. TEs are product experts, quality advisers, and analyzers of risk. Many of them write a lot of code; many of them write only a little.

测试组织结构和流程

测试尽早参与，各个环节参与，多Review文档，代码，架构。Code Review 是专门有一套Submit的流程。

高度自动化，强调持续集成。

测试分大中小测试，大中小范围、执行人、时间和要求不一样。

测试度（测试成熟度）的等级

Summary of Test Certified Levels
Level 1

Set up test coverage bundles.
Set up a continuous build.
Classify your tests as Small, Medium, and Large.
Identify nondeterministic tests.
Create a smoke test suite.

Level 2

No releases with red tests.
Require a smoke test suite to pass before a submit.
Incremental coverage by all tests >= 50%.
Incremental coverage by small tests >= 10%.
At least one feature tested by an integration test.

Level 3

Require tests for all nontrivial changes.