感谢测试大牛邰晓梅（博客）的推荐。最近读了《Fifty quick ideas to improve your tests》
这本书真的很不错
有可爱的插图
也有可怕的样例
偷学一点出去卖，收到热烈的反馈
一点心得
书中提出了50条关于改进测试的点子，按照主题分为产生测试灵感，设计好的case，改进系统可测试性，以及管理大型测试集几组。
不少点子都很有启发性。更难能可贵的是，每个点子作者不仅提出见解，分析收益，更给出了如何实施的指导。
非常值得一读。
以下是一些印象深刻的点子。
从问 “总是/从不” 开始
当进入一个新领域时，最危险的不是大家都认为你是菜鸟的时候；而是已经待的足够久，以至于大家假定你已经了解了领域里的基本常识。比如“飞行过程中不能开舱门”
快速理解领域常识的一个方法是问什么事情应该总是会发生的，或从来不会发生。从这些问题，你可以迅速的知道最基本的假设和约定。
而且，由于这种绝对的论断很容易被驳倒。往往当列出一条“总是/从不”时，就会有人指出不符合的特例。然后就可以由此展开对业务的深入讨论。
带入情绪
系统不仅仅可以有happy path（一切顺利的开心路径），还可以有胆战心惊路径, 漫不经心路径，尴尬路径，健忘路径……
避免用数学公式来描述测试
尽管公式初看起来非常严谨完善，但是公式往往只是复述了从别处搬来的规则。无益于我们发现还遗漏的用例，或增进对系统的理解。相反，它会给我们虚假的信心相信测试已经完全。
比如如下规则
| 交易日期 | 包括在报表？ |
|---|---|
| 报表产生日期 - 30 < 交易日期 | 不包括 |
| 报表产生日期 - 30 < 交易日期 < 报表产生日期 | 包括 |
| 交易日期 > 报表产生日期 | 不包括 |
看起来非常完整。但是是否澄清了下面的疑问呢？
- 交易日期和报表日期是仅仅包括日期还是日期时间格式？
- 时区会有影响么？
- 如果报表日期为3月3日，那么3月3日 00:01是否包括在里面？ 23:59:59呢？
- 闰年和夏令时会不会对边界发生影响？
避免使用公式，用具体的例子说明系统的行为。
说明测试的目的，而不是如何做
如前面可怕的样例贴图里的测试：“按这里，那里显示xxx，再按这里，又会显示xxx，……，最后输入xxx，得到的结果是xxx”……
这样只是描述步骤的测试，除了当初写它的人外没人可以理解。这样的测试无法让干系人查看是否符合业务，无法给测试人员启发，只能从头到尾机械执行。经过一段时间的变更之后系统无法维护，只能从头再录一次这样的流程。
不要自动化手工测试用例
即便最详细的手工测试脚本，也只是指导测试人员探索系统的手册而已。它本身并不能完整说明系统应该的行为。测试人员执行时会发现很多用自动化难以检查的输出。一旦流程出错，对人来说可以容易的绕过小问题继续，而对电脑却是复杂的技术问题。
为自动化测试设计专门的用例。自动化测试并不是为了替代手工测试。
改善测试可读性，而非写测试的效率
太多的测试工具专注于高效的写出测试用例。然而快速写出一堆用例并不能真正增进我们对系统的理解。无法理解的测试也是无法维护的。在系统长期的生命周期中，测试的可读性远远比快速写出测试重要。
