讀書筆記 - 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.

　　Incremental coverage by small tests >= 50%.

　　New significant features are tested by integration tests.

　　Level 4

　　Automate running of smoke tests before submitting new code.

　　Smoke tests should take less than 30 minutes to run.

　　No nondeterministic tests.

　　Total test coverage should be at least 40%.

　　Test coverage from small tests alone should be at least 25%.

　　All significant features are tested by integration tests.

　　Level 5

　　Add a test for each nontrivial bug fix.

　　Actively use available analysis tools.

　　Total test coverage should be at least 60%.

　　面試

　　面試測試的題目，看似簡單，但需要優秀候選人更廣泛更完備測試思維(挖掘更深更多方面的條件、情況)，敢于反思、質疑問題，敢于多一些建議。

　　ACC (Attribute, Component, Capability)

　　可用于風險分析，用例設計，用例指派，探索式測試。個人十分行賞。

　　Example: Determining Attributes, Components, and apabilities for Google+

　　ACC can be performed quickly in a document, spreadsheet, or even on a napkin! Here is an abbreviated example of ACC for Google+.

　　• Google+ Attributes (derived exclusively by watching an executive discuss Google+)

　　Social: Empowers users to share information and what they're up to.

　　Expressive: Users can express themselves through the features.

　　Easy: Intuitive. Easy to figure out how to do what you want to do.

　　Relevant: Shows only information the user cares about.

原文轉自：http://blog.csdn.net/o2o_o2o/article/details/8944072