这篇post是测试书籍“测试之美”的读书笔记
Chapter 1 测试者之美
一旦测试人员学会阅读字里行间暗藏的玄机，观察显而易见之外的事物，询问一针见血的问题，以及眼界的扩展，你就成为了一名真正的测试强人，通过继续学习和掌握新的工具，你的力量将会随着职业生涯不断增强
Chapter 6 缺陷管理和测试用例的有效性
TCE (test case effectiveness)是一种衡量测试用例有效性的方法，也能反映测试人员的表现
TCE = (Nt / Ntot) * 100% Nt是qa发现的bug总数， Ntot是产品所有发现的缺陷数量(为qa发现的Nt和非qa测试周期发现的bug总数的和)
如果TCE = 100%， 表示没有missed bug，那么这个测试质量就不错了。所以我们的目标是用更有效的测试用例尽可能地减少missed bug，提高TCE。
在测试时，总有些bug不是通过test case找到的，那么我们需要调查这些bug，得出条件，增加到test case中。并且在以后的测试周期中进行测试。通过加权的TCE更能反映qa测试周期和测试逃逸发现的缺陷的质量。也就是把bug的严重程度考虑进去。
这里还介绍了分析missed bug然后对应的纠正行动
| 原因 | 纠正行动 |
|---|---|
| 不完整的测试用例 | 审查测试用例的目标功能区域。加强并重新设计测试用例 |
| 没有测试用例 | 基于导致缺陷的功能实现测试用例 |
| 测试执行问题 | 审查test step |
| 不正确的测试用例 | 审查正在测试的功能。测试用例编写之后，它是否有改变 |
| 不正确的功能规范 | 联系BA或设计人员。检查功能规范审查流程。 |
Chapter 8 大规模自动化之美
自动化不仅仅是简单地编写和运行那些不需要人为干预的测试用例。许多自动化之所以失败，是因为流程中很多部分没有自动化。自动化应该是整个过程从头到尾，从测试人员的编写玩script到得到 test report，都必须被自动化。
对于漂亮的自动化过程，我们可以有以下几点：
- 自动化什么？自动化到什么程度？ 应该100%自动化那些应该被自动化的测试。别让自动化的努力放在不值得自动化的行为上。
- 测试代码要写得好。易于理解和维护。对测试代码要有审阅和静态分析。采用系统进行源代码控制。源代码控制通过使测试人员能够研究到测试代码，上层基础结构和附属文件完整的改变历史记录而让维护变得简单。
- 选对工具。别浪费时间精力去处理不好用的工具。
- 管理好测试辅助文件。比如：数据文件、文档、插件或测试用到的其他数据。
- 自动化测试和测试用例的管理。每一个Test Case能查到其对应的脚本的名称是什么以及脚本的基本信息，比如：运行用的配置环境要求，属于哪类测试等等。自动化和test case的管理最终要达到的目的是：当有一个失败的结果的时候，你需要知道具体的哪一项测试失败了，它测试的是哪一个组件，是什么造成了失败，并且它运行的是哪一类测试。
- 把分析和测试失败的调查自动化。当测试失败了，系统能创建一个新的bug或是更新一个已有的报告。
如果有一个美的自动化系统，随着它得到改善，团队的测试人员会有越来越多的时间去做他们最擅长的，并且是他们当初从一开始就被雇佣来做的事：测试软件。
Chapter 12 软件以用为本
这章故事不错，以及描述作者为了保障质量而做的各种努力，推荐阅读。
这章里介绍了一个现在很流行的测试方式 - 探索性测试：同时进行测试设计和执行。探索性测试现在很火因为敏捷测试的流行。敏捷开发火起来后，给测试人员的带来了新的挑战和压力，如何在很短的时期内保证产品的质量，达到交付水平，人们在不断的探索中。有人提出了一个方法：敏捷功能测试 = 新特性的手工测试（Use Case验证和探索性测试） + 原有功能的自动化测试 （回归测试）。
大家第一感觉会说探索性测试会不会和ad-hot testing / free testing / random testing 一样啊。其实不然。本章给了一个区别的概念：探索性测试有时与随机测试混淆。随机测试通常指即兴的缺陷发现过程。从定义上理解，任何人都可以做随机测试。
而探索性测试是基于feedback的，边设计边测试，有侧重点的，高度依赖测试人员的背景，水平和经验的一种测试技术。
大家感兴趣的话，可以google探索式测试，相信你会找到更多的资料。
Chapter 16 socialtext的测试
这章提到了一个问题：自动化测试并不自动。提出的观点很典型，就是自动化测试如果不完善会miss bug，不能代替手工测试。
Chapter 17 高效测试之美
SLIME - Security, Language, requIrements, Measurement, Existing。 作者通过这样的测试顺序和内容来保证测试质量。Security就是安全性测试，包括跨站脚本，sql注入，越权访问，信息泄露等等。Language就是多国语言文本数据的测试，类似本地化测试。requIrements就是测试new feature的功能测试。Measurements就是性能测试 performance testing，包括load testing和stress testing。Existing一致性就是对系统现存功能的行为进行测试，类似回归测试
脚本 - 一个好的tester可以通过开发一些实用的脚本来提高测试效率。如：写程序来验证数据的有效性，写程序来处理那些繁琐重复的工作等等
思维导图 - 是一个进行头脑风暴的思维整理的图形化工具。将原始的想法放在图的中央，然后分支出许多新的想法，也就是更多的测试点和case。它会列出系统的细节，然后越来越具体。通过preview meeting可以大家坐到一起来查看思维导图，大家就会不断完善这个图。这个图就会告诉tester什么是正确的测试用例，你可以使用哪些case来增加测试的广度。
