那些年向前冲|微服务下产品集成和集成测试框架流程( 四 )


第三种方法(有时也称为伞形方法)测试沿功能性数据和控制流路径进行
首先 , 函数的输入以上面讨论的由下而上的模式集成 。 然后 , 每个函数的输出以由上而下的方式集成 。 这种方法的主要优点是对有限功能的早期发布的支持程度 。 它也有助于最大限度地减少对存根 (stub) 和驱动程序的需求 。 但是 , 这种方法的潜在缺点非常明显 , 因为它的系统性可能比其他两种方法低 , 会导致对回归测试的更大需求 。
由于自顶向下的测试方式需要建立大量的技术服务和业务服务模拟器 , 而且底层的需求变化会对上层的业务组件模块造成较大的影响 。 因此对于私有云PaaS平台中应用的集成测试最好的方式还是以自底向上的模式进行 , 在这个过程中为了保证测试工作的尽早开始和并行 , 可以对少量涉及到技术服务集成的场景采用自顶向下的方式进行集成 。
在整个集成测试方案策略中重点是集成依赖关系和集成顺序的分析 , 具体如下:
那些年向前冲|微服务下产品集成和集成测试框架流程在此图中可以看到 , 首先需要分析业务组件模块之间的相互依赖关系 , 每个模块涉及到的前置依赖模块 , 以及和依赖模块之间需要交互的业务服务接口 。 基于初步的模块依赖关系分析可以开始考虑业务模块的组装和集成顺序 , 在集成顺序的分析中可以根据依赖关系按正向和逆向两种方式进行集成测试顺序的分析和梳理 。
对于正向分析来说则是当前业务模块测试完成后可以测试哪些下游的业务模块;而对于逆向分析来说则是当前模块的前置依赖模块是哪些;如果需要测试当前模块需要首先测试哪些上游的业务组件模块等 。 通过这两种方式的梳理基本可以形成一个大框架的组件集成流程图 。 但是由于业务模块集成本身的复杂性 , 以上的初步集成方案和策略分析还不足够 , 最好的方法还是需要进一步结合业务场景尽快跨模块的业务协同分析 , 具体如下:
那些年向前冲|微服务下产品集成和集成测试框架流程结合该图 , 在集成场景分析中首先是选择需要集成的业务流程 , 分析该业务流程中的各个业务活动以及这些业务模块之间的交互和协同点 。 对于这些交互点需要详细的分析业务功能以及该业务功能涉及到的业务服务接口 , 将这些业务服务接口全部识别出来并进行测试设计和测试数据准备 。
基于以上步骤后可以有针对性的对识别出来的业务流程进行跨模块的端到端测试 , 在这种测试模式下虽然无法保证所有业务模块间的接口全部测试覆盖到 , 但是可以保证关键的业务流程实现跨模块的业务协同和贯通 。
集成测试执行和评估
那些年向前冲|微服务下产品集成和集成测试框架流程对于集成测试执行设计到冒烟测试、业务组件模块的功能测试、业务组件间接口服务测试、性能测试、易用性测试等多方面的内容 , 具体可以参考业界标准的测试方法规范体系 。 对于在测试执行阶段可以简要描述如下:
在集成测试执行过程中需要有相应的缺陷管理工具和平台对缺陷进行统一的管理和跟踪 。 如果从更加全面的工程变更角度来说 , 则需要有完善的需求变更、缺陷管理、版本管理、测试流程管理、发布管理等一系列的研发过程管理工具平台提供支撑 。
对于测试评估则是根据需求设计文档(系统需求 , 产品集成方案、集成设计文档等) , 描述经过测试后 , 哪些组件接口已经实现 , 哪些组件接口没有实现或存在什么问题 , 产品对应系统需求是否通过测试 , 测试执行是否覆盖到所有集成测试用例 。 同时需要对集成测试执行结果以及因测试不充分而引起的风险进行评估 , 说明对系统测试的影响 。 集成测试评估的主要输出包括了:


推荐阅读