要做好测试可不是一件容易的事情。测试工作和软件开发密切相关，却又自成体系。测试并不是一个单独的阶段或活动，测试本身就是一个过程，具有自己的生命周期，从测试计划开始，到测试用例的制定，测试的结构设计，测试代码的编写。测试的生命周期和软件开发生命周期拧在一起，相互影响。当然，我们还是那句老话，罗马不是一天建成的。对我们来说，还是从简单的开始。
在我们谈及精益编程理论的时候，曾经讨论过全面质量管理的概念：生产过程的每一个环节都需要为质量负责，而不是把质量问题留给最后的质检员。这对于软件开发有着很好的借鉴。软件开发中最头疼的就是质量问题，因为人的行为过于不确定了。在经过漫长的软件开发周期之后，软件渐渐成型，但是缺陷也慢慢增多，试图在最后的关头解决长期积累的问题并不是一个好的做法。软件开发到了这种时候，发现和修改缺陷需要付出很大的代价。
我们说，最后关头的测试并不是不重要，但是，软件质量问题应该在整个软件过程中予以重视。
测试的最小单位
测试问题的很重要的思路在于测试的管理上，如何管理一个项目中所有的测试，以及它们相关的文档，相关的代码，如何定义测试人员的职责，如何协调测试人员和开发人员之间的关系？
XP的测试优先和自动化测试实践是一个非常优秀的实践，我们也曾不止一次的提到该实践，但是对XP强调的单元测试，很多人都有一些误解：
XP中提供的例子过于简单，无法和生产环境相结合。XP中的单元测试只是为测试提供了一个具体的操作思路，但是它并不能取代其它的测试原理。如何进行测试，如何组织测试，如何管理测试，这些都要由不同的软件组织自己来进行定义。
测试代码本身不能够适应变化。黑盒测试的理想状况是外部行为不因为内部行为的改变而改变。当需求或是设计发生变化的时候，一段代码的内部行为需要改变，但是外部行为却不需要变化，这样，针对外部接口进行的单元测试同样不需要改变，但是这个规则一旦被违反，我们就需要付出同时改变测试代码的双重代价了。因此，测试代码的设计本身就是很讲究的。
单元测试（有时候也称为类测试）是代码级别的测试，是测试的最小单位。XP非常看重这个最小单位。我们观察测试优先框架XUnit，发现它使用组合模式将大量的最小单位的单元测试组织起来，形成完整的测试网。所以，XP的思路非常的简单：最小单位的测试能够做好，全系统的测试就能够做好。这个思路未必就正确，但是注重最小单位的测试的思路是绝对正确的。每个部件都正确，最后的软件未必正确，但任何一个部件不正确，最后的软件一定是不正确的。
测试优先
文章来源于领测软件测试网 https://www.ltesting.net/
