我目前正在启动一个新项目，我们希望使用可重复使用的组件和服务来开发新系统。
当前，我们有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）
这给我带来了一些问题，因为我需要能够测试该平台和每个系统以确保其正常工作，这是我第一次不得不测试这样的设置。
我已经阅读了一些有关Mircroservices及其测试方法的文章，但是这些通常仅针对使用微服务的1个系统解决了这个问题，我们正在研究具有不同配置的多个系统。
到目前为止，我的想法使我相信，对于将由不同集合使用的通用组件，我可以在基本代码级别上创建自动化测试，然后这些测试将确认通用功能，因此无需重新测试这些通用功能。除了在部署后手动进行感觉检查以外，每个组件都可以再次运行。然后，可以在每个系统级别添加其他自动化测试，以检查可能创建的特定功能。
理想情况下，我想要建立某种测试平台，以便如果对诸如用户管理之类的核心组件进行了更改，则有可能在核心级别触发所有自动测试，然后触发所有针对将共享组件的所有系统进行的特定系统测试，以确保任何更改都不会影响核心功能或对特定系统产生连锁反应。然后将需要快速手动检查。我热衷于尝试在每次更改共享组件时消除30多个系统的大量手动测试开销。
我们以敏捷的方式工作，对于我们当前的项目，我们建立了一个强大的持续集成过程，因此，当开发人员检入某些代码（Visual Studio）时，这将触发一个CI构建（TeamCity / Octopus），它将运行所有单元测试，前提是所有这些测试均通过，然后将触发一个集成版本，该版本将运行我的QA自动化测试，该测试是在API级别运行的测试与使用SpecFlow和PhantomJS或Selenium Webdriver进行的Web测试的混合。我们希望保留这种框架，以保持快速反馈循环。
从理论上讲，这听起来很棒，但是我正在努力尝试将一些东西付诸实践，并创建一种合理的测试策略来涵盖这种系统设置。
因此，我真正希望的是，有人过去曾遇到过类似的事情，并曾思考过解决此问题的最佳方法，并证明了他们的工作能力。
考虑到每个系统可能看起来有所不同，但是共享代码，我渴望更好地了解如何设置测试平台/钻机以帮助所有系统进行持续集成。
您认为可能有帮助的任何想法或指向博客/白皮书的链接都将不胜感激！！
最佳答案
您的方法非常好，从那以后我将不得不面对像您一样的问题-到目前为止，我可以给您我的想法。我很确定
创建合理的测试策略以涵盖此类系统设置
不能被压在一个帖子中。因此，大图看起来（对我而言）-您处于Enterprise application integration流程的中间，要进行测试的基本基础将是Data migration。也许您需要考虑Service-oriented architecture的概念
使用共享组件的通用平台
因为它将使您能够将应用程序功能作为服务提供给其他应用程序。间接的好处是SOA涉及到大大简化的测试。服务是自治的，无状态的，具有完整记录的接口，并且与实现的跨领域关注点分开。像E2E testing或efficiently testing SOA这样的资源很多。
关于testing - 测试多个系统中的可重用组件/服务，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/26218391/