回归测试
只要在程序内修改实现，都应该同样进行回归测试。具体的方法可以是：对修改过的代码重新运行现有的测试，确定更改是否破坏了在更改之前有效的任何事物，并且在必要的地方编写新测试。执行回归测试时，首要考虑的应该是覆盖范围足够大但不浪费时间。尽可能少花时间执行回归测试，但不减少在旧的、已经测试过的代码中检测新失败的可能性。
此过程中需考虑的一些策略和因素包括下列内容：
- 立即测试已修复的错误。程序员可能已经处理了症状，但并未触及根本原因。
- 监视修复的副作用。错误本身可能得到了修复，但修复也可能造成其他错误。
- 为每个修复的错误编写一个回归测试。
- 如果两个或更多的测试类似，确定哪一个效率较低并将其删除。
- 识别程序始终通过的测试并将它们存档。
- 集中考虑功能性问题，而不是与设计相关的问题。
- 更改数据（更改量可多可少）并找出任何产生的损坏。
- 跟踪程序内存更改的效果。
生成库
最有效的回归测试方法建立在开发测试库的基础上。测试库由一系列标准测试案例组成，每次生成程序的新版本时都可以运行这些案例。生成测试案例库所涉及的最困难的方面是确定包括哪些测试案例。软件测试领域中的机构给出的最普遍建议是：避免花费过多的时间尝试做出决定并在小心谨慎方面犯错。自动测试以及涉及边界条件和运行时间的测试案例毫无疑问应归入库中。某些软件开发公司只包括实际已经发现了错误的测试。此论据的问题是可能在很久以前就找到并修复了特定的错误。
定期查看回归测试库以消除多余的或不必要的测试。每隔两个测试周期查看一次。当测试代码由多人编写时，重复现象非常普遍。导致此问题的一个示例是测试的重点，当错误或错误变种的持续时间特别长并且在许多测试周期中都存在时，这一点通常会逐步显示出来。可以编写大量的测试，并将它们添加到回归测试库。这些多样的测试对于修复错误是有用的，但是当从程序中消除了对错误及其变种的跟踪时，应选择与错误关联的最佳测试，并将其余的测试从库中移除。
单元测试
最常用的单元测试方法要求编写驱动程序和存根 (stub)。驱动程序模拟调用单元，而存根 (stub) 模拟被调用的单元。开发人员在此活动中的时间投入有时会导致单元测试降到更低的优先级，这几乎总是一个错误。即使驱动程序和存根 (stub) 花费时间和金钱，单元测试仍然提供了一些不容置疑的优点。它考虑了测试过程的自动化，降低了发现应用程序的更复杂片段中包含的错误的难度，并且通常会提高测试的覆盖范围，因为对每个单元都给予了关注。
例如，如果您有两个单元，并认定将它们粘合在一起且最初作为集成单元来测试会更合算，那么错误可能会在不同的地方出现。
- 错误是否因单元 1 中的缺陷所引起？
- 错误是否因单元 2 中的缺陷所引起？
- 错误是否因这两个单元中的缺陷共同引起？
- 错误是否因这两个单元之间的接口中的缺陷所引起？
- 错误是否因测试中的缺陷所引起？
在集成模块中查找错误比首先隔离两个单元，测试每一个，然后集成它们并测试整体要复杂得多。
驱动程序和存根 (stub) 可以重用，因此不用额外编写大量的测试代码，就可以经常重新测试开发周期内不断发生的更改。这实际上降低了基于每个用户编写驱动程序和存根 (stub) 的成本，并且可以更好地控制重新测试的成本。
来自：http://msdn.microsoft.com/zh-cn/library/aa292484(v=VS.71).aspx
