开发人员测试不同于测试人员测试，前者是白盒测试，后者是黑盒测试。开发人员测试主要包括单元测试，组件测试，集成测试等。不管哪一种，测试的目的都是为了发现缺陷。所以，既然测试，首先就要认为一定会发现缺陷，若是总想着找不到缺陷，就会真的找不到缺陷。测试这件事，要从一开始就考虑，像测试用例，早晚都是要写的，不如先写，想用就能用，还能更早发现需求是否有问题。
作者在书中通过一个例子详细的列出了各种测试的技巧，如下：
1. 设计最可能发现错误的测试用例。
2. 每一条语句都要覆盖至少一次。
3. 每一个变量的赋值与使用的组合都要覆盖。比如x可能为a可能为b，y可能为x可能为2x，那么这就有4种情况要覆盖。
4. 等效的测试用一个就好了。
5. 边界条件处一般要测三个case，等于的，正好大于的，正好小于的。
6. 错误的数据要测，太多的，太少的，太大的，太小的，类型不对的，大小不对的，没初始化的等等。
7. 正确的数据也要测，最小的，最大的，中间的，是不是兼容以前老的数据等。
8. 用例最好便于手工计算验证。
缺陷不是平均分布的，通常集中在一些类或者函数里，符合著名的80/20法则，即80%的缺陷在20%的代码中。一些复杂的类或者函数就比较容易包含很多缺陷。这也是一直强调要降低复杂度的原因之一。有一点要注意的是测试代码本身往往会比要测试的代码更容易有缺陷，这是因为开发人员倾向于认为测试代码用过就不要了，就不像也被测试的代码那样认真写。
有很多工具可以用来让测试更方便高效，不要客气，能用就用。像搭脚手架的，比较的，生成测试数据的，监控覆盖率的，记录的，调试的，控制系统内存的，自动化测试的等。找不到合适的也可以考虑自己写一个，一劳永逸嘛。
随着测试的深入，要不断的改进、提高。怎么样才算提高了呢，自然首先要有一个衡量。所以要根据衡量标准不断的记录需要的数据，看看是不是在提高以及分析怎么样去提高。
最后要说的是就算所有的测试都通过了，也不表示就没有缺陷，测试永远无法证明这一点。要想提高软件质量，更多的测试是一个办法，也不要忘了一开始就设计编码得更好一些。
附上测试用例的checklist:
Checklist: Test Cases
Does each requirement that applies to the class or routine have its own test case?
Does each element from the design that applies to the class or routine have its own test case?
Has each line of code been tested with at least one test case? Has this been verified by computing the minimum number of tests necessary to exercise each line of code?
Have all defined-used data-flow paths been tested with at least one test case?
Has the code been checked for data-flow patterns that are unlikely to be correct, such as defined-defined, defined-exited, and defined-killed?
Has a list of common errors been used to write test cases to detect errors that have occurred frequently in the past?
Have all simple boundaries been tested - maximum, minimum, and off-by-one boundaries?
Have compound boundaries been tested - that is, combinations of input data that might result in a computed variable that’s too small or too large?
Do test cases check for the wrong kind of data - for example, a negative number of employees in a payroll program?
Are representative, middle-of-the-road values tested?
Is the minimum normal configuration tested?
Is the maximum normal configuration tested?
Is compatibility with old data tested? And are old hardware, old versions of the operating system, and interfaces with old versions of other software tested?
Do the test cases make hand-checks easy?
作者在书中通过一个例子详细的列出了各种测试的技巧，如下：
1. 设计最可能发现错误的测试用例。
2. 每一条语句都要覆盖至少一次。
3. 每一个变量的赋值与使用的组合都要覆盖。比如x可能为a可能为b，y可能为x可能为2x，那么这就有4种情况要覆盖。
4. 等效的测试用一个就好了。
5. 边界条件处一般要测三个case，等于的，正好大于的，正好小于的。
6. 错误的数据要测，太多的，太少的，太大的，太小的，类型不对的，大小不对的，没初始化的等等。
7. 正确的数据也要测，最小的，最大的，中间的，是不是兼容以前老的数据等。
8. 用例最好便于手工计算验证。
缺陷不是平均分布的，通常集中在一些类或者函数里，符合著名的80/20法则，即80%的缺陷在20%的代码中。一些复杂的类或者函数就比较容易包含很多缺陷。这也是一直强调要降低复杂度的原因之一。有一点要注意的是测试代码本身往往会比要测试的代码更容易有缺陷，这是因为开发人员倾向于认为测试代码用过就不要了，就不像也被测试的代码那样认真写。
有很多工具可以用来让测试更方便高效，不要客气，能用就用。像搭脚手架的，比较的，生成测试数据的，监控覆盖率的，记录的，调试的，控制系统内存的，自动化测试的等。找不到合适的也可以考虑自己写一个，一劳永逸嘛。
随着测试的深入，要不断的改进、提高。怎么样才算提高了呢，自然首先要有一个衡量。所以要根据衡量标准不断的记录需要的数据，看看是不是在提高以及分析怎么样去提高。
最后要说的是就算所有的测试都通过了，也不表示就没有缺陷，测试永远无法证明这一点。要想提高软件质量，更多的测试是一个办法，也不要忘了一开始就设计编码得更好一些。
附上测试用例的checklist:
Checklist: Test Cases
Does each requirement that applies to the class or routine have its own test case?
Does each element from the design that applies to the class or routine have its own test case?
Has each line of code been tested with at least one test case? Has this been verified by computing the minimum number of tests necessary to exercise each line of code?
Have all defined-used data-flow paths been tested with at least one test case?
Has the code been checked for data-flow patterns that are unlikely to be correct, such as defined-defined, defined-exited, and defined-killed?
Has a list of common errors been used to write test cases to detect errors that have occurred frequently in the past?
Have all simple boundaries been tested - maximum, minimum, and off-by-one boundaries?
Have compound boundaries been tested - that is, combinations of input data that might result in a computed variable that’s too small or too large?
Do test cases check for the wrong kind of data - for example, a negative number of employees in a payroll program?
Are representative, middle-of-the-road values tested?
Is the minimum normal configuration tested?
Is the maximum normal configuration tested?
Is compatibility with old data tested? And are old hardware, old versions of the operating system, and interfaces with old versions of other software tested?
Do the test cases make hand-checks easy?
