良好的测试要素
1.1 什么样的测试算是完美
a. 它会检测出一个系统中的所有缺陷
b. 它永远不会将不是缺陷的情况判断为缺陷
c. 它能让我们完全确信它完成了a和b
d. 针对我们的需求，它可以足够迅速和廉价地实现a,b和c
以上就是完美测试的基本特点。
但是我们知道** 测试对多只是采样 **， 测试人员是无法设计出既满足a又满足d的完美测试。所以我们期望只能期望自己的测试时“良好”的测试。
1.2 良好的测试
测试是针对具体问题或者系统的，良好的测试意味着能正确反映出目标的目前状态。换句书上的说法也就是，“良好”并不是属于某个测试的属性，而是只是用来描述某个测试与某个实现之间的特定关系的属性。
1.3 评估测试是否良好
- 开发人员可以在审阅代码时，发现缺陷，可以先不修复，也不告诉测试人员，看测试人员测出缺陷数目，统计估算系统内未发现的缺陷数量
- 测试是否在名义上能够提供测试需要的信息？
- 是否进行了文档记录？是否亲自观察了测试过程？
- 它是否是真实的？不要有意或无意的捏造测试文档
- 你是否理解它？
- 它是否至少覆盖了那些最重要的部分？
- 它是否确实完成了？
- 不同类型的测试活动之间是否有不一致的地方？
- 测试报告中是否有倾向性或过于简化或表面化？
开发与测试人员的心理
涉及第六第七章，信息免疫与防卫心理
当我们在生存规则受到威胁时会感到害怕，这时我们可能会本能的采取一些防卫措施
如开发人员讨厌测试可能是因为他担心测试出现大量缺陷从而影响经理对他开发水平的怀疑。这时他可能会采取一些防卫措施来化解这一窘境。
- 压抑：用户不会这么做的，那不是缺陷
- 合理化：A: 这两个注销操作的流程不同! B: 这是一个特性，没必要统一所有 注销的流程
- 投射：A：响应时间太长了，一直黑屏，几分钟了程序还卡在那里。B：这个操作需要时间，用户应该庆幸处理这么大的数据，系统没有崩溃。
- 转移：你太挑剔了；如果你不复现该问题，我就没法做任何事；这是他们的代码；这不是我的代码
- 过度补偿
- 强迫
