1

我目前正在开始一个新项目,我们希望使用可重用的组件和服务开发一个新系统。

我们目前有 30 多个系统,它们都有共同的元素,但目前我们孤立地开发每个系统,所以感觉就像我们经常重复代码,当然我们有 30 多个独立的代码库需要维护和支持。

我们想做的是创建一个使用共享组件的通用平台,以实现新集合的快速开发、重用代码和重用自动化测试,并减少需要维护的代码库。

到目前为止,我们的想法是我们将为特定模块(例如用户管理和安全系统访问)建立一个通用代码库,这些模块可以由它们自己的通用 Web 模块、API 和上下文组成。这将创建一个通用的代码包。

然后,我们可以部署这些不同的组件/包来构建一个新系统,以节省对相同模块的一遍又一遍的编码,因此如果新系统需要管理用户,您可以获得用户管理包并使其满足您的需求. 但是,因为我们有 30 多个系统,我们将为每个集合多次部署组件。此外,我们意识到某些系统将需要独特的功能,因此有可能为通用模块添加扩展以满足系统特定需求,或者选择不使用通用模块之一并创建一个新模块,但使用其余模块的通用组件。

例如,如果我们有 4 个组成系统 A、B、C 和 D 的通用组件。可以部署这些组件来创建以下系统设置:

系统 1 - A、B、C 和 D(对所有通用组件感到满意)

系统 2 - Aa、B、C 和 D(扩展组件 A 以包含特定功能)

系统 3 - A、E、C 和 F(不能重用组件 B 和 D,因此创建特定的,但仍然重用组件 A 和 C)

这给我带来了一些问题,因为我需要能够测试这个平台和每个系统以确保它工作,这是我第一次遇到必须测试这样的设置。

我已经阅读了一些关于微服务以及如何测试它们的内容,但是这些通常只针对使用微服务的 1 个系统来解决问题,我们正在查看具有不同配置的多个系统。

到目前为止,我的想法使我相信,对于将由不同集合使用的通用组件,我可以在基本代码级别创建自动化测试,然后这些测试将确认通用功能,因此无需重新测试这些对每个组件再次起作用,而不是在部署后进行手动感知检查。然后在每个系统级别可以添加额外的自动化测试来检查可能创建的特定功能。

理想情况下,我希望设置某种测试平台,以便如果对用户管理等核心组件进行更改,则可以在核心级别触发所有自动测试,然后特定系统测试将共享组件的所有系统,以确保任何更改都不会影响核心功能或对特定系统产生连锁反应。然后需要进行快速手动检查。每次更改共享组件时,我都热衷于尝试消除大量手动测试开销,检查 30 多个系统。

我们以敏捷的方式工作,对于我们当前的项目,我们设置了强大的持续集成流程,因此当开发人员签入一些代码 (Visual Studio) 时,这会触发将运行所有单元的 CI 构建 (TeamCity / Octopus)测试,前提是所有这些测试都通过了,这将触发一个集成构建,它将运行我的 QA 自动化测试,这些测试混合了在 API 级别运行的测试和使用 SpecFlow 和 PhantomJS 或 Selenium Webdriver 的 Web 测试。我们希望保留这种框架以保持快速反馈循环。

这一切在理论上听起来都很棒,但我正在努力将一些东西付诸实践并创建一个完善的测试策略来涵盖这种系统设置。

所以我真的希望有人在过去遇到过类似的事情,并且对解决这个问题的最佳方法有想法,并且已经证明它们是有效的。

考虑到每个系统可能看起来不同,但具有共享代码,我渴望更好地了解如何设置测试平台/装备以帮助所有系统的持续集成。

您认为可能有帮助的任何想法或博客/白皮书等链接将不胜感激!

4

1 回答 1

1

你的方法非常好,因为很快我将不得不面对和你一样的问题——到目前为止,我可以给你我的想法。我很确定

创建一个完善的测试策略来覆盖这种系统设置

不能挤在一个帖子里。所以大图看起来像这样(对我来说) - 你正处于企业应用程序集成过程的中间,要测试的基本基础将是数据迁移。也许你需要考虑面向服务架构的概念

使用共享组件的通用平台

因为它将使您能够将应用程序功能作为服务提供给其他应用程序。这里的间接好处是 SOA 涉及显着简化的测试。服务是自治的、无状态的、具有完整记录的接口,并且与实现的横切关注点分开。有很多资源,例如E2E 测试有效测试 SOA

于 2014-10-07T07:48:14.790 回答