【读书活动感悟】—等价边界读书组—《软件测试的艺术》第5章 模块（单元）测试

第五章：“模块”测试

     本书中讲解的模块测试（或单元测试）的概念，是对程序中的单个子程序、子程序或过程进行测试的

过程，也就是说，一开始并不是对整个程序进行测试，而是首先将注意力集中在对构成程序的较小模块的测试上面。以模块进行测试的动机的原因理解为3个：

      1、先将测试精力集中在程序较小的单元上。

      2、由于模块有独立的属性，模块测试减少了调试的难度，提升了问题发现的效率

      3、单模块测试通过，可以确保后期多模块组合测试通过的效率

    本书所讲的模块测试，还是着重在于白盒测试，但我们日常工作多数是黑盒为主，不过我们也存在业务模块的概念，与我们日常的工作也是有较高的匹配度的

     书中从三个方面来探讨的模块测试：
       1、测试用例的设计方式。

           主要介绍的是逻辑覆盖的方法，需要列举出所有的判定条件去穷举，但是从列出判断条件来看，只有这一种方式并不能完全将问题排除，还需要再结合条件覆盖，才可以获取到较满意的测试效果。

           我们日常的用例设计，也并非单一的一种设计方式，而是根据实际的用户需求，去进行多重条件覆盖，多测试方法覆盖，选择出最适合本需求的设计方法，这样才能确保尽可能的覆盖到所有场景。 

           好的用例，并不是说我用了多少测试方法，把现在等价类、边界值、因果图、错误猜测、逻辑判定等全部测试方法都用上才算是好用例，而是应该去选择最适合的才是最好的。有的需求用例一看篇幅很大，设计了大几十条，但是实际执行时发现，好多都是无效设计场景，这给执行人员增加了很大的难度。

          所以我们应该灵活的运用这些测试方法，选择有效的，排除无效的，让场景覆盖更加精准、全面。
     

       2、模块测试及集成的顺序。

            书中的模块测试适配我们的工作中，可以理解为一个需求涉及很多的业务或者是多组联合开发的场景，如果由一位测试人员全部负责，那肯定是需要将大需求分割为多个较小较独立的业务模块，先将各个模块测试完，再进行系统性的集成测试。如果是多组联合开发、多位测试，那在测试一个需求时，应该是各组分别测试完成，然后必须进行集成测试。

      3、 对执行模块测试的建议

              以这张图为例，我们一个需求，涉及改造的点是A、B、C、D、E、F，那这六部分都可以被划分为一个模块，测试时先从每个模块测起，先确保每个模块代码的准确性，再进行集成测试，保持整体业务的准确性。
              分析今年的生产bug，有一些是在改造功能时，只识别到了B改动点，而测试时，我们也只测试了B模块的功能，但是最终发布到生产导致了异常。最终发现B做为中转节点，对上下游的业务起到了很关键的接收和转出，如果自己变动了，上下游不验证适用性，不进行集成测试，大概率是会出问题的。
             模块测试只是一个需求测试周期的一小part，不是每个模块全测试通过就确保没问题了，而是需要各模块串联起来进行集成测试，与我们这几年提出的场景用例、场景测试的理念结合起来，更好的覆盖场景，保障质量。