【项目管理一点通】（43） 模块测试、系统测试、平台测试

上一节聊了单元测试和功能测试的一些差异，同时也说了这些差异并不影响我们的工作。这节我们开始聊聊模块测试、系统测试和平台测试，之所以将这三个概念放在一起说，是因为本质上他们就是一个概念，之所以形成三个概念，是与我们软件的发展分不开的。
最早时候的软件，功能很单一，一个软件可能就只有一两个功能，而且也没有什么多用户的管理功能，后来功能越来越多，就需要进行功能分类管理，从而形成模块，再后来，随着C/S和B/S架构的出现，平台出现了，很多平台都不是单一的系统，而是多系统的整合，再后来，随着软件的服务化，系统之间的边界逐渐消失，所有系统对外呈现的都是服务接口，我们所看到的的软件边界实际上是个虚拟的边界，是根据实际业务划分的边界，并不代表软件系统的边界。可以说，软件呈现的形式越来越简单，但是软件架构本身却越来越复杂。我们无法再使用之前那种系统和平台的概念去定义现代的软件服务。对应的测试业务也呈现出这种复杂性，如果还用以前的那种思路去定义测试类型，可能就会感到无所适从。
但是，在这种新旧概念交变的时代，为了让大家仍然能够理解测试的历程，我们还是讲讲这些基本概念。
模块测试、系统测试和平台测试都是相对于测试对象的边界而言的，由于测试工作的本质是验证功能单元、模块、系统以及平台的内部的逻辑关系，也就是我们经常说的业务逻辑和数据逻辑。
我们经常提到的是系统测试，这实际上是个宽泛的概念，在广义上我们可以将任何相对独立的软件单元定义成一个系统，所以经常会有模块和子系统混淆的说法。换句话说，一个系统测试就已经泛指模块测试、系统测试以及平台测试了。虽然这是不够严格的说法，但同样不影响我们的工作，因为测试的目标和方法基本一样，所以我们也没有必要纠结这些。
下面我针对系统测试提一些建议，供大家参考。
1、系统测试和功能测试不一样，系统测试不仅仅考虑到功能，更需要考虑到业务的完整性，实际上就是我们经常说的话，做出来的东西能不能用，很多场合下，单个功能肯定不能用，它需要系统内部其他的功能配合才行，比如说业务模块离不开一些基础模块，比如用户管理模块、权限模块等，统计模块离不开报表模块、打印功能等等。而系统测试就是将所有功能串起来进行一个相对完整的测试。
2、系统测试的主要目标是业务的完整性，而不是接口的正确性。虽然接口是否正确仍然会考虑，但已经不是主要的，如果这时候还需要考虑接口测试是否完成，那么最好是做一次功能的回归测试，而不要将其和系统测试混在一起。
3、系统测试的用例的重点也在验证整体的业务逻辑，而不是一些细节上面，比如数据验证、边界测试等等，不建议将功能测试的用例做简单的合并，这样的话会导致测试工作量巨大，而且没有必要。
4、测试工具建议采用自动化工具，可以通过提取关键测试点，并将其串在一起形成一个自动化的脚本，好处就是便于维护，效率高，缺点就是灵活性稍差，如果想人工干预，就得另外想办法。
系统测试是我们内部测试的最后一个环节，换句话说，软件质量是否能够保证也直接取决于系统测试是否全面，这就像我们高考之前的复习一样，首先是复习各个单元，然后是每本书，最后是总复习，那时候会没日没夜地做卷子，那么高考就是验收测试了。生活和工作的意义是一样的，考试就是另一种意义的测试。
本节就聊到这里，非常感谢大家在这么热的天气还能耐着性子阅读，祝大家生活愉快！