学习日志之software engineering(15)——integration testing

在工程中，每个Unit都是一个独立的个体，但是在某些Unit之间会存在一些dependency导致这些Unit在测试时需要进行处理才能从整个系统中给分离出来单独测试。其中Unit在不同类语言中表示的东西也不同，比如在procedual languages(面向过程的语言)中其表现为function，而在oo language(面向对象的语言)中表现为类以及类中的methods。要知道是否在各个unit之间存在有dependency，我们需要画出dependency graph，如下右边所示：其中f1的运行就依赖于f2和f3运行的结果，同样的f2运行依赖于f4的运行结果。

另外这里的f1称为根(root)，而f3和f4称为叶(leaf)

如果需要测试这些存在dependency的Unit则需要对其进行一定的处理。例如如果需要测试f2那么我们就可以弄一个可以替代f4的Unit来给f2传递其需要的数据，这个substitute称为Stubs。当然这个stubs不一定要和f4一模一样可能是f4的精简版，另外在测试f2之前我们还需要保证f4的正确性，即要先测试f4。测试的结构图如下，其中f2 driver中包含了很多的test cases用于这个测试。这个Driver也称为mock，Stubs也称为mock ups.

有时候两个Units分开测试时可以征程工作但是合并到一起就完蛋了，这时就遇上了dependency defect，即此时defect发生在dependency中。在处理多个Unit的情况时我们也是需要将所有的Unit分开测试，然后一级一级合并起来。在前阶段测试的时候要避免过多的Unit一次性合并在一起测试。这种一级一级垒起来的测试方法称为Incremental integration。

这种测试方法主要分为两类：自上而下，自下而上。

在Top down方法中如果遇到像上面的例子一样在两个Unit之间具有dependency那么就需要写一些stubs，而对于bottom up方法就不需要，因为前面的都测试过了直接拿来用就好了。