导图社区 《How google tests software》
Google的工程总监讲述Google是如何测试软件的。软件测试和开发人员必看的经典书籍,帮你深入理解软件测试。英文版读书笔记,原汁原味,提炼易懂。
编辑于2020-08-12 17:00:30《How google tests software》
Google's goal :
Build the core of a product and release it the moment it is useful to as large a crowd as feasible , and then get their feedback and iterate.
Principles
Stop treating development and testing as separate disciplanes
Quality is achieved by putting development and testing into a blender and mixing them until one is indistinguishable from the other
Test Related Roles
Software engineer (SWE)
coding of feature
SE in Test (SET)
concerns more about quality than features
Test engineer (TE)
put test on behalf of user first and developers second
Organization
Testing is a independent BU. The member is deployed to different project.
Testing is owned by the entire engineering team and not just those with the word test in their job title
Types of Tests
small tests
verify the behavior of a single unit of code
medium tests
validate the interaction of one or more unit of code.
large tests
verify that the system works as a whole all the way from UI down to backend storage system.
70/20/10 percent of small, medium and large tests.
small tests lead to code quality. Medium and large tests lead to product quality.
Code Coverage
A great tool for measuring whether a project's tests have a healthy mixture of small, medium and large.
Code Reviews
Reviewing design documents is purposeful and not like reading a newspaper , there are specific goals to pursue
completeness
correctness
consistency
design
interfaces and protocols
testing
Fast Iteration
ACC
Attribute
They are the quality and characteristics that promote the product and distinguish it from the competition
Component
They are the core components and chunks of code that make the software what it is
Capability
Capabilities are the actions the system performs at the command of the user
The most important aspect of capabilities is that they are testable.
Notes on ACC
Capability is described by components and each components' attribute.
Each capability should be inked to at least one test case
Not all capabilities are equal. Some are more important that others.
RISKS
The enterprise benefits from well calculated risks.
risk analysis
two factors
frequency of failure
rarely
seldom
occasionally
often
failure impact
minimal
some
considerable
maximal
Qualitative rather than quantitative analysis
If you can't test everything, test the most important stuff first, and the most important stuff is the riskiest stuff.
BUG
Handle on bug rate, simply stop adding features when the incoming bug rate exceeds the team's ability to fix them
Bug Handle
Report bug -> view bugs -> record & playback bugs
Bug create -> assign -> fix (-> re-assign) -> verify (-> re-assign) -> accept
Tool: e.g. Bugzilla