软件开发是一个迭代和累积的过程，越是底层的缺陷，发现的时间越晚，修复缺陷的代价越高。软件开发项目一般是以工程的方式运作的，作为工程会有明确的目标，因此，风险的控制非常重要。如果已知缺陷存在而无法修复，软件产品是无法发布的。如果在后期发现严重问题，修复难度很大或者需要大面积的改动，项目的风险会陡然增加。项目组面临的选择只有延期完成或宣布项目失败。很多失败的项目都是因为多次的延期而宣告失败的。可见，从项目整体的角度而言，“尽可能早地发现问题”才能降低风险，而问题越迟发现，项目的风险越高，对整体进度的影响越大。

　　作为测试专家，应该考虑的问题是如何更早地发现缺陷，以及有效地解决缺陷。

　　正如之前曾经提及的，开发的前期，缺陷可能已经存在但不容易暴露。那么，有没有办法让问题“提前”暴露呢？

　　发现问题的可行方法有两类，分别是分析方法 和测试方法。分析主要使用逻辑分析推理的方法发现缺陷和评估问题的严重性，并根据所处的阶段得到解决的方法。例如，有一个报表系统，起初是使用直接SQL查询的方式实现报表功能的。对实现的方法进行分析，可以发现，要生成条件复杂的报表，需要完成执行效率较低的查询语句，执行查询的时候是需要给相应的表格加锁的，因此有可能影响对相同的表有业务操作的模块。单从报表模块的设计和功能实现而言，使用直接的SQL查询已经可以满足功能上的需求，但综合考虑运行效率和跨模块的相互影响，通过分析可以得到结论--报表系统使用直接SQL查询的方法，在系统完成实现后会带来性能和系统级别的缺陷。

　　测试和分析人员可以针对这个问题直接创建一个缺陷，虽然这并不是通过测试发现的。针对这个问题，项目组有机会在设计阶段修复这个潜在的缺陷。这里使用“潜在的”作为定语，是因为这个缺陷没有经过测试证实，而是通过分析的方法推导认定的。但由于理据充分，本质上这个缺陷和测试发现的缺陷是一样的。为了提高查询效率，考虑使用物化表存储报表的内容，再通过筛选物化表的记录生成报表。因为有了物化表，可以把生产数据和报表数据大限度地隔离，避免了数据锁定而引起的冲突；物化表从性质上也保证了查询的效率。重新设计和实现以后，可以认为对这个缺陷有了一个解决方法。后要做的是通过严谨的测试证实问题已经解决或者潜在的问题得到避免。测试的方式是对设计分析时认为有问题的场景进行模拟，如果在这种场景下没有出现此前认为会出现的问题，那么这个缺陷解决方案被认为是可以接受的。

　　分析方法不需要等待缺陷目标的开发完成并使用测试进行验证，然而，这种方法对分析人员技能要求较高。分析人员在需求分析和设计方面的经验必须比较丰富，才能准确定位问题所在。实施难度相对较低的是测试方法。测试方法设计出有针对性的场景，并在测试环境上模拟该场景。如果测试的输出和预期的输出存在差异，则能证实问题的存在。然而，要使用测试的方法发现问题，对测试环境是有要求的。要运行测试场景验证用例是否成功，前提是测试的场景能够在测试环境中正常运作。黑盒测试方式的测试用例一般是端对端（End-To-End）的，也是测试用例是个完整的业务场景，而不仅仅是一个单元。在开发的早期，要走通一个端对端的用例大多情况下只是个奢望。可用的方式是使用“假对象”（Mock Object）或模拟器把端对端场景中没有完成实现的部分补充完整。

　　例如，在一个面向服务的体系结构（SOA）开发模式下的系统，如果某些流程中服务并没有开发完成，但目标测试用例必须用到这个没完成的服务，为了让用例完整地走通，可以设计一个简单的假对象。假对象不实现任何逻辑，对于任何输入，仅返回符合格式要求的特点数据。有了假对象返回的内容，业务流程能以这种临时的方式完成。因为测试的重点在于已经完成的部分，因此假对象没有任何业务逻辑，也不会影响测试的有效性。如果测试验证失败，则证明测试目标存在缺陷。这时候可以对缺陷进行跟踪和解决。为了在早期发现问题，使用假对象或"假业务数据"来完成测试，都是常用的"主动测试"策略。

　　无论是使用分析方法还是测试方法发现的问题，都通过创建缺陷来跟踪。高效的项目组一般都有完善的缺陷跟踪机制和系统，使应有的资源流向相应缺陷并尽早解决问题。缺陷跟踪系统定义了缺陷的生命周期和相关信息 ，如图1-3所示。

　　缺陷（Bug），一般是指系统存在的问题或者需要加强的细节。从广义的角度而言，系统中任何需要修改或强化的任务都可以归类为缺陷。发现缺陷的人员在系统中创建一个新的缺陷，对于这个缺陷而言，创建的人是缺陷的创始人（Originator）。创始人会明确说明缺陷的内容，包括测试的时间、环境、测步和问题的描述、建议等。缺陷创建后，它处于开启（Open）状态，在任何时候它都会有一个直接的负责人（Owner），负责人是必须对缺陷采取行动的那个人。负责人的义务是推动缺陷的解决。初始化的时候，系统会根据一定的规则指定缺陷的负责人，创始人或者被指定的负责人可以重新指定（Assign）更适合解决该缺陷的人员为新的负责人。

　　针对一个开启状态的缺陷，首要的任务是验证其有效性，因为在不少情况下，缺陷对应的问题是由于不符合规定的操作导致的。遇到这种缺陷时，负责人仅需要把缺陷退回（Return）给创始人。如果缺陷被返回，创始人可以再次确认缺陷是否合法，假如缺陷确实合法，则可以重新开启（Reopen）缺陷，使缺陷回到开启状态；如果证实缺陷仅是不符合规定的操作引起的问题，则可以把它取消（Cancel）。取消状态是缺陷生命周期的其中一种终结状态。如果负责人经过验证后证实了缺陷的有效性，那么下一步的工作是谋求解决方法。开始考虑解决方案前，需要接受（Accept）这个缺陷，使缺陷的状态从开启转成工作中（Working）。