2.3 换一种做法

　　08年我和一些来自瑞典的测试专家交流过这个问题，当我提出这个问题时，他们给我的答复出乎意料：既然无法做到全覆盖的测试，不去做，不要试图在现有的测试模式下，设计和执行都投入很大精力去覆盖各种场景和交互，因为这样收效甚微，依然达不到目的。

　　那么怎么做呢？他们建议：FT (Function Test)功能测试环节只做普通、典型、重要场景下的功能验证，保证每个测试特性的基本功能OK。然后开展模拟用户真实使用场景的测试（暂时把它称作UBT，Usage Based Testing），主要考虑各种configurations、scenarios，用simulator模拟真实用户/商用组网环境和以及真实的业务模型，也是说，simulator可以模拟环境configuration，也可以模拟实际业务。当然，做UBT时，首先开展的还是针对老特性的Regression Test，然后在增加具体的业务时，逐步增加新特性涉及的业务类型。

　　假如被测系统如下图的方框，灰色的小块是我们的FT测试覆盖，很多团队都会投入很大精力试图尽大能力增加这些灰色小块的覆盖，但依然会有很多覆盖不到的地方。而UBT相当于红色的范围，虽然没有针对性的设计测试用例，但由于模拟了可能使用的商用场景和业务，业务之间交互的测试在这种测试环境下自动进行，潜在的一般的bug都被自动发现（比较难触发的异常bug依然发现不了），如果这样的UBT连续执行数天都没有问题，此时可以很有信心的说，版本稳定到可以对外发布了，这意味着用少的人力、获得了可信的测试效果。

　　2.4 解决建议

　　所以对于比较复杂的被测系统，与其不遗余力地做无穷无尽的测试覆盖，不如换一种思路，增加一种测试分层-UBT，让很多复杂的交互场景自动覆盖到、让很多很可能出现的bug自动冒出来。

　　不过，要明确的增加一个UBT环节，并非易事，一旦决定要这样做，意味着更多money、time、people的投入，意味着Regression test的加强，同时会有很多问题和困难需要克服(比如探索如何模拟Configuration，然后逐步增加Traffic的模拟，逐步改进）。下图示意了一种可能的演讲过程：

　　当模拟用户使用场景的UBT做到比较满意的阶段后，也许测试人员可以更准确的评价产品的质量：需要在FT报告中，从测试特性角度，只给出典型场景下的各特性测试结果的评价；在UBT报告中，从系统角度，给出更多场景下的整个系统的验证结果，例如“XXX产品在XXXX配置的场景下，连续运行XXX天，没有发现严重的问题，可以对外发布”。

　　本文转自：http://www.taixiaomei.com/archives/173