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


要明白持续集成只是产品集成的一种方式 , 不论是开发过程是瀑布模式、增量模式还是迭代模式 , 都可以采用持续集成的思路 。 要明白持续集成的一个核心是将整个开发过程透明化 , 同时将集成工作提前化 。 尽可能早的暴露问题和风险 , 同时纠正在前期系统分析和架构设计中的不足 。
对于持续集成我们往往会强调每日构建、冒烟测试、自动化测试等内容 。
强调开发、测试和生产环境的部署流水线作业 。 但是要明白对于大型产品集成仍然会包括模块内测试和集成、模块间测试和集成、跨系统间的测试和集成工作 。 对于单个模块内可以采用每日构建和持续集成策略 , 但是对于模块间和跨系统我们可以采取分迭代式的集成方式进行集成 。
集成测试流程
那些年向前冲|微服务下产品集成和集成测试框架流程集成测试是将模块按照设计要求组装起来同时进行测试 , 主要目标是发现与接口有关的问题 。 如数据穿过接口时可能丢失;一个模块与另一个模块可能有由于疏忽的问题而造成有害影响;把子功能组合起来可能不产生预期的主功能;个别看起来是可以接受的误差可能积累到不能接受的程度;全程数据结构可能有错误等 。
对于集成测试阶段的流程可以参考上图 , 在验收测试阶段流程和该图类似不再说明 。
从该图中可以看到作为集成测试的负责方在进行集成测试执行前需要制定集成测试计划 , 集成测试方案和策略并联同甲方信息化管理部门和开发厂商共同进行计划和方案的评审 。 在方案评审通过后再开始单个业务组件的集成测试用例的设计 , 业务组件间的接口和服务测试用例的设计工作 。
开发厂商在开发验证环境自身的单元测试通过后将形成一个稳定的可用于集成测试的版本 , 在这个时候可以提交集成测试申请;而对于配置管理方来说则根据提交的集成测试申请进行待测试版本的提取 , 并将测试版本部署到集成测试环境 , 成功部署完成后通知集成测试负责方进行集成测试工作 。
集成测试方根据设计好的功能测试用例和接口服务测试用例开始进行业务组件的功能测试和上下游的接口服务测试工作 , 确保单个业务组件功能正确 , 和上下游业务组件之间的衔接正确 。 在这里重点还是集成方案中的集成顺序分析 。 在集成测试执行完成后输出相应的集成测试结果 , 如果存在相应的缺陷则打回到开发商 , 开发商在进行缺陷修复和自测通过后再提交第二轮的集成测试 。
在多轮集成测试缺陷全部关闭后 , 需要在集成测试环境再进行一次回归测试 。 当回归测试仍然通过后可以开始输出相应的集成测试评估报告并提交评审 。 在集成测试评估报告和开发商 , 验收测试商一起评审通过后该业务组件可以开始提交验收测试 , 并进入详细的验收测试流程 。
集成方案和策略可以以多种方式进行集成测试 , 而下面是三种常用的类别:
第一种方法是由上而下的集成测试方法
首先测试和集成最高级别的模块 。 这使高级别的逻辑和数据流可以在过程的早期阶段测试 , 有助于最大限度地减少对驱动程序的需求 。 但是 , 对存根 (stub) 的需求使测试管理变得复杂 , 低级别的实用工具在开发周期中相对较晚的阶段测试 。 由上而下的集成测试的另一个缺点是不能很好地支持有限功能的早期发布 。
第二种方法是由下而上的方法要求
首先测试和集成最低级别的单元 。 这些单元常被称为实用工具模块 。 通过使用这种方法 , 使用工具模块在开发过程的早期阶段测试 , 最大限度地减少了对存根 (stub) 的需求 。 但是 , 不利的方面是对驱动程序的需求使测试管理变得复杂 , 高级别的逻辑和数据流在晚期测试 。 与由上而下的方法一样 , 由下而上的方法也不能很好地支持有限功能的早期发布 。


推荐阅读