测试是一项很矛盾的任务，一方面，如果能够只测试那些怀疑可能有问题的部分，就可以大幅度减少测试时间，对程序进行更深入的测试；另一方面，最少怀疑的地方却是经常会出差错的地方，于是测试人员很难断言哪个部分的程序不会出差错。程序的测试既不可能完全测试，也不可能不去测试，那么解决测试时间的问题就转化为寻找测试平衡点的问题，既对于不同的模块或程序“应该测试到什么程度”。

对于广智书店系统来说，我们根据模块复杂的程度、基于测试用例的数量以及需要测试的需求数量来划分一个模块需要测试到什么程度。测试的越深入，自然分配的测试时间和资源也越多。归纳起来现在可分为4种复杂程度：最简单而且不重要的模块，我们只进行随机测试，以提高测试速度，让出更多的时间和资源来测试下面更复杂或更重要的模块。

复杂一些的模块我们会先进行模拟用例的测试，这种测试没有用例的指导，但测试的人员一般曾经写过类似的测试用例，他可以参照以前雷同的用例来进行测试，测试的时候有一定的方向性和指导性，模拟用例测试后再进行回归测试和随机测试。比如前台的一些报表就是采用这种测试方法。

更复杂一些的模块，我们会先准备测试用例，再进行用例测试，然后是回归测试和随机测试，随机测试后还需要对原来的用例进行用例的补充，根据随机测试来完善测试用例。使以后的用例测试可以发现在随机测试中发现的问题，提高用例的覆盖面。现在前台的大多数模块都是采用这中方法进行测试。

最复杂的模块，我们会先写用例，然后由其他人员进行用例的审核，审核以后需要修改和补充用例，再进行用例测试，然后是回归测试和随机测试，最后就是根据随机测试来完善用例。最复杂模块的测试加入了用例的审核，用例审核是一个广集众智的过程，因为写用例的人的思维方式或者是测试技能又或者是业务知识总会有一定的局限性，如果有不同的同事，从不同的方面对用例进行审核，那对用例质量和用例覆盖面的提高将有莫大的帮助。就拿连锁触发的测试用例来说，用例先由我根据测试的覆盖面以及自有的业务知识完成用例，然后是源源根据业务知识和对连锁机制的理解来审核用例，最后小蔡再更多的从业务的特殊性和完整性来补充触发的用例，使得触发用例在多次审核修改后比较好的覆盖了连锁触发的需求。

下来我们对模块进行测试时，可以根据采用不同的测试模式来计划测试需要的时间，从而更合理的安排有限的测试时间，让不同的模块得到不同的测试程度。