1、Right——结果是否正确？
对于测试而言，首要的也是最明显的任务就是查看所期望的结果是否正确——验证结果。
对于许多有大量测试数据的测试，考虑用一个独立的数据来存储测试数据，然后让单元测试读取该文件。不过需要多注意一下测试数据。不管是文件中的还是代码中的测试数据，都很有可能是不正确的。实际上，经验告诉我们，测试数据比代码更有可能是错的，特别是人工计算的，或者来自原有系统计算结果的测试数据。因此，当测试数据显示有错误发生的时候，你应该在怀疑代码前线对测试数据检查两三遍。
2、B——是否所有的边界条件都是正确的？
找边界条件助记短语CORRECT
Conformance（一致性）——值是否和预期的一致
Ordering（顺序性）——值是否如应该的那样，是有序或者无序的。 Range（区间性）——值是否位于合理的最小值和最大值之内
Reference（依赖性）——代码是否引用了一些不在代码本身控制范围之外的外部资源。
Existence（存在性）——值是否存在（例如，是否是非null，非0，在一个集合中等等）。
Cardinality（基数性）——是否恰好有足够的值？
Time（相对或者绝对的时间性）——所有事情的发生是否是有序的？是否在正确的时刻？是否恰好及时？
3、I——能查一下反向关联吗？
例如，可以用对结果进行平方的方式来检查一个计算平方根的函数，然后测试结果是否和原数据很接近。
4、C——能用其他手段交叉检查一下结果吗？
通常而言，计算一个量会有一种以上的算法。我们可能会基于运行效率或者其他的特性来选择算法。那是我们要在产品中使用的；但是在测试用的系统中，可以使用剩下算法中的一个来交叉测试结果。
另一种方法就是：使用类本身不同组成部门的数据，并且确信它们能“合起来”。例如，图书馆的数据系统，借出数加上躺在架子上的库存数应当永远等于总藏书量。这些就是数据的两个分开的不同组成部门（借出数和库存数），它们甚至可以由不同类的对象来汇报它们，但是它们仍然必须遵循上面约束（总数恒定）。
5、E——你是否可以强制错误条件发生？
搞一个无效参数之类的做法是小菜一碟，但是不拔网线要模拟网络错误就需要一些特殊的技术了，使用Mock对象可以解决此类问题。
以下是常见的环境方面的因素：
- 内存耗光
- 磁盘用满
- 时钟出问题
- 网络不可用或有问题
- 系统过载
- 受限的调色板
- 显示分辨率过高或者过低
5、P——是否满足性能要求？
一个检查起来会很有益处的部分是性能特性，而不是特性性能本身。然后性能特性却又一种类似“随着输入尺寸慢慢变大，问题慢慢变复杂”的趋势。
我们想要的是一个性能特性的快速回归测试。很多时候，也许我们发布的第一个版本工作正常，但是第二个版本不知道为何变得很慢。我们不知道为什么，也不知道改变了什么，或者什么时候谁敢的，几乎一切都是未知的。