一般在接触测试时,都是从黑盒测试方法开始的,因为其技术相对简单一些,只需要关注外部条件,包括输入、输出结果,而不需要关注系统的内部结构。但随着测试的深入,测试人员将不满足于这种黑盒测试方法,开始关注被测试系统的内部构造,并逐渐深入,比如以下从系统的架构设计到代码实现的思考。
1)根据系统的内部结构,采取相应的对策实现。例如,数据层和业务逻辑层,都可以采用API 直接调用的测试方法。
2)在代码层,根据程序结构,分别采用代码覆盖、分支覆盖、条件覆盖等方法来设计测试用例。
从这个演化的过程,可以隐隐约约地看到测试架构的形成。为了真正能解决问题,需要提高测试效率和测试覆盖率。测试不是单纯的,测试的方法也不是一成不变的,而且还要有系统性。
从测试结构来看,不仅要了解全部的测试内容,从单元测试到系统测试、从功能测试到非功能测试,如“附录B 软件测试的详细分类”,而且需要在分析、归纳和总结的基础上,将测试抽象到更高层面;提纲挈领,从整体上更好地把握测试任务。下面,将就功能测试和非功能测试分别讨论,而自动化测试架构,留到下一节讨论。
1、功能测试
撇开非功能性测试,先谈软件产品的功能测试,以此来分析软件测试的架构。在功能测试中,不仅要完成业务逻辑的验证,还要进行用户界面和输入空间的验证。我们在讨论软件测试方法时,经常谈到的黑盒方法中的等价类划分、边界值分析、决策表、因果分析等方法,实际上都只是功能测试的冰山一角,仅为对输入空间的验证。为了使软件具有更好的质量,包括低缺陷率和高稳定性、可维护性,需要在代码这个层面进行充分的测试,就是人们常提到的单元测试,特别是对代码的评审、通过工具对代码进行静态分析。也就是说,在功能测试中,不光要进行不同层次的测试,还要针对不同空间或领域进行相应的测试,可以用图2-3 简要加以描述。
图2-3 不同视角看功能测试
如果展开讨论,不同的测试领域会侧重采用不同的测试方法,如基于用例的测试,主要用于用户界面测试,但也会用于业务逻辑验证;而基于模型的测试,主要用于语法验证和业务逻辑验证等。图2-4 系统地介绍了不同测试领域的测试方法,其中几个用英文书写的说明如下:
FSM(Finite State Machine,有限状态机)
ForS(Formal Specification,形式规格说明)
FunS(Functional Specification,功能规格说明)
图2-4 功能测试架构示意图
这些测试方法构成了功能测试的架构,即设计一个软件项目的测试功能,就要从用户界面验证、业务逻辑验证、输入空间验证和语法验证4 个方面去考虑。针对不同的方面,根据软件应用系统的技术特点等,选择或决定合适的测试方法、工具等,也是测试架构这个层面需要考虑的。