Clever Geek Handbook

“一个按钮即可全部测试。” 如何使所有集成不可见

您好，Khabrovites！我们Vladimir Myasnikov和Vladislav Egorov是Mir Plat.Form集成测试团队（NSPK JSC）的代表。今天，我们将向您介绍我们已经开发和正在开发的自动化工具，这使得减少团队内部流程中的日常工作成为可能。



前言



Mir Plat.Form支付生态系统包括数十个系统，其中大多数系统使用各种协议和格式相互交互。我们，集成测试团队，验证这些交互是否满足既定要求。







目前，该团队正在使用13个任务和业务关键系统。关键任务系统可确保Mir Plat.Form履行其主要职能，从而确保俄罗斯银行卡系统的稳定性和连续性。关键业务系统负责支持向Mir Plat.form客户提供的其他服务，而公司的直接运营活动则依赖这些服务。将产品发布到PROD的频率从每周一次到每季度一次不等，这完全取决于系统和参与者对更新频率的准备情况。去年，我们总共计算了大约200个发布版本。



简单的数学说如下：被测试的链数是N系统*它们之间的M集成* K版本。即使使用13个系统* 11个集成* 27个发行版本的示例，也大约有3,861个可能的系统兼容性选项。答案似乎很明显-自动测试？但是问题要严重得多，只有自动测试才能拯救您。鉴于系统及其集成的数量不断增加，以及发布的频率不同，始终存在测试错误的系统版本链的风险。因此，存在错过系统间交互中的缺陷的风险，例如，影响了Mir支付系统（PS）的正确操作。



自然，在PRODA中，此类错误的存在是不可接受的，我们团队的任务是将这种风险降低到零。如果您还记得上面的文字，“打喷嚏”不仅会影响Mir Plat.form的内部系统，还会影响市场参与者：银行，商人，个人，甚至其他支付系统。因此，为消除风险，我们采取了以下方式：



  • 引入了统一的发布基础。对于此任务，Confluence中的发行日历就足够了，表明PROD中安装的系统的版本。
  • 我们根据发布日期跟踪集成链。在这里，我们也没有开始重新发明轮子，我们将进一步需要它。为了解决此问题，我们使用JIRA中的Epic结构进行发行版的集成测试。System3版本1.111.0的示例结构：






一方面，所有这些措施有助于提高团队对已测试的集成，系统版本及其在PROD中发布的顺序的了解。另一方面，由于人为因素，仍然存在错误测试的可能性：



  1. 如果已更改任何系统的发布日期，则团队成员需要在JIRA中手动更正日历和整个结构，包括完成任务的期限以及可能的测试系统版本；
  2. 在测试集成之前，您需要确保测试环境包含正确版本的系统。为此，您需要手动通过测试平台并执行几个控制台命令。


此外，还出现了其他日常工作，有时会占用大量时间。



很明显，这种为发布的集成测试做准备的过程需要以某种方式自动化，并且如果可能的话，可以组合成一个界面。这是我们自己的救生自行车应运而生的地方：集成测试监控系统或简称SMIT。



您想在正在开发的系统中实现哪些选择？



1.清晰的发布日历，能够显示特定日期的所有系统的版本；



2.监视环境以进行集成测试：



  • 环境清单；
  • 可视显示作为独立环境一部分的测试台和系统；


  • 测试平台上部署的系统的版本控制。


3.在Jira中自动处理任务：



  • 创建一个Epic发布结构；
  • 测试任务的生命周期管理；
  • 如果发布日期发生变化，则更新任务；
  • 将吸引力报告纳入测试任务。


4.在Bitbucket中自动处理分支，即在项目中创建发布分支：



  • 集成自动测试；
  • 集成环境的自动加热。


5.直观的用户界面，用于运行自动测试和更新系统版本。



什么是史密斯



由于系统并不复杂，因此我们对技术并没有变得太聪明。后端是使用Spring Boot用Java编写的。前端是React。对数据库没有特殊要求，因此我们选择了MySql。由于习惯于使用容器，因此上述所有组件都包装在Docker中，并使用Docker Compose构建。SMITH与其他Mir Plat.Form系统一样快速且可靠地工作。







积分





  • Atlassian吉拉。在jir中，用于创建，打开，投入工作和关闭的用于测试每个特定集成的任务，如果所有测试都成功，则注释中将链接到诱惑报告。
  • Atlassian BitBucket. , , / . “” , .
  • Jenkins. Jenkins, . , , glue Cucumber.
  • . . ssh.




在维护日历并监视SMIT中的环境状态之前，需要创建一个受测系统及其之间的关系的列表。可以通过Web界面进行所有设置：







将被测系统添加到SMIT列表后：



  1. 将“敲响”环境列表中名为SYS_CMD的系统的所有主机；
  2. 使用配置中指定的命令找出该系统的版本；
  3. 会将当前版本的系统及其出现的环境写入其数据库。


结果，SMIT将包含有关在所用环境上部署的所有系统的信息，包括其版本号。根据此信息，您可以可视化发布日历。



发布日历



在系统所有者或产品开发团队的团队负责人告诉我们在PROD中安装新版本的日期后，我们在日历中注册该版本。事实是这样的：







在几天内一次安装多个版本的情况下，您很容易注意到冲突，并且可能会产生“热量”。产品所有者将收到这些冲突的通知，因为在同一天安装多个新版本的系统确实很危险。



在带有日历的页面上，还具有显示特定日期所有系统版本的功能：







值得注意的是，在日历中注册新发行版时，SMIT在Jira中自动创建Epic结构，并在Bitbucket中的项目中发行分支。



环境状况



SMITH的另一个非常方便的功能是查看特定环境的当前状态。在此页面上，您可以找到环境中所包含系统的列表及其版本的相关性。







正如您在屏幕快照中看到的那样，SMITH在host-4.nspk.ru上发现了一个过时的System 4版本，并提供了对其进行更新。如果您按下带有白色箭头的红色按钮，则SMITH将调用Jenkins job，以在当前环境中部署系统的当前版本。按下相应的按钮后，也可以更新所有系统。



集成测试环境



值得介绍一下我们如何定义测试环境。一个环境是一组展台，这些展台具有已部署的Mir Plat.form系统和定制的集成（在一个展台上是一个系统）。我们总共有70个展位，分为12个环境。



在集成自动测试项目中，我们有一个配置文件，测试人员可以在其中配置测试环境。文件结构如下所示： 



{  
   "properties":{  
      "comment":" system property   Environment.     property,   ,      System.getProperties()",
      "common.property":"some global property"
   },
   "environments":[  
      {  
         "comment":"  name,  Environment   common +  .  common1",
         "name":"env_1",
         "properties":{  
            "comment":" system property  Environment.    property.    ,      System.getProperties()",
            "env1.property":"some personal property"
         },
         "DB":{  
            "comment":" TestResource' DbTestResource.     id,       ",
            "url":"jdbc:mysql://11.111.111.111:3306/erouter?useUnicode=yes&characterEncoding=UTF-8&useSSL=false",
            "driver":"com.mysql.jdbc.Driver",
            "user":"fo",
            "password":"somepass"
         },
         "SYS_CMD":{  
            "comment":" TestResource'   RemoteExecCmd.    type = remote",
            "type":"remote",
            "host":"10.111.111.111",
            "username":"user",
            "password":"somepass"
         }
      }
   ]
}


除了该文件对于集成自动测试项目正常工作是必需的以外，它还是SMIT的附加配置文件。当您请求更新有关SMIT中环境的信息时，HTTP请求将发送到我们的位桶的API，我们在其中存储带有集成自动测试的项目。通过这种方式，SMITH从master分支获取配置文件的当前内容。



运行测试



创建SMIT的目标之一是尽可能简化启动集成自动测试的过程。让我们使用一个示例来考虑一下最终得到的结果：







在系统测试页面（在此示例中，系统3）上，您可以选择要检查其集成的系统列表。选择所需的集成并单击“开始测试”按钮后，SMITH：



1.形成队列并依次启动相应的Jenkins作业；

2.监控工作执行情况；

3.更改Jira中相应问题的状态：



  • 如果作业成功完成，那么Jira中的任务将自动关闭，链接到魅力报告并附带注释，表明在此集成中未发现任何缺陷。
  • 如果作业有问题，则Jira中的任务将保持打开状态，并将等待负责集成的员工做出决定，该员工将能够确定测试失败的原因。可以在集成卡中看到负责集成的人员。


输出量



创建SMITH是为了最大程度地降低集成测试的风险，但是作为一个团队，我们想要更多！特别是，希望之一是，只需单击一下按钮，即可在正确的测试环境下启动自动测试，并在必要的集成匹配中检查所有内容，并在Jira中打开和关闭任务以及报告。如此空想的自动测试人员：告诉系统要检查的内容-并去喝咖啡:)



让我们总结一下我们成功实现的目标：



  1. 可视发布日历，能够显示特定日期所有系统的版本；
  2. UI , , ;
  3. ;
  4. UI ;
  5. Epic Task Jira, Allure ;
  6. Bitbucket.




目前，系统正在集成测试团队的直接成员中进行封闭Beta测试。当消除所有发现的缺陷并稳定地执行系统功能时，我们将向相关团队的员工和产品所有者开放访问权限，以便他们可以独立运行我们的测试并研究结果。



因此，在理想情况下，检查系统是否符合集成要求所需要做的就是进入SMIT Web界面，通过它更新必要的系统，选择所有复选框并运行测试，然后检查是否已成功完成所有测试。任务将自动创建，魅力报告将被填写，相应的状态将分配给这些任务。


More articles:


All Articles