序文
Mir Plat.Form支払いエコシステムには、数十のシステムが含まれており、そのほとんどはさまざまなプロトコルと形式を使用して相互に作用します。私たち統合テストチームは、これらの相互作用が確立された要件を満たしていることを確認します。
現在、チームは13のミッションおよびビジネスクリティカルなシステムで作業しています。ミッションクリティカルなシステムは、Mir Plat.Formがその主要な機能を実行することを保証し、ロシアのバンキングカードシステムの安定性と継続性を保証します。ビジネスクリティカルなシステムは、会社の直接的な運用活動が依存するMirPlat.formクライアントに提供される追加サービスをサポートする責任があります。リリースをPRODにロールアウトする頻度は、週に1回から四半期に1回までさまざまです。これはすべて、システムと参加者の更新頻度に対する準備状況によって異なります。昨年、チームを通過したリリースは合計で約200件に上ります。
簡単な計算によると、テストされるチェーンの数はNシステム*それらの間のM統合* Kリリースです。 13のシステム* 11の統合* 27のリリースバージョンの例を使用しても、約3,861の可能なシステム互換性オプションがあります。答えは明らかなようです-自動テスト？しかし、問題はもう少し深刻で、自動テストだけではあなたを救うことはできません。システムとその統合の数が増え、リリースの頻度が異なることを考えると、間違ったシステムバージョンチェーンをテストするリスクが常にあります。したがって、たとえば、Mir支払いシステム（PS）の正しい動作に影響を与えるなど、システム間の相互作用の欠陥を見逃すリスクがあります。
当然、PRODAではそのようなバグの存在は容認できません。私たちのチームの仕事は、このリスクをゼロにすることです。上記のテキストを覚えている場合、「スニーズ」はMir Plat.formの内部システムだけでなく、市場参加者（銀行、商人、個人、さらには他の支払いシステム）にも影響を及ぼします。したがって、リスクを排除するために、次の方法を実行しました。
- 統合リリースベースを導入しました。このタスクでは、Confluenceのリリースカレンダーで十分であり、PRODにインストールされているシステムのバージョンを示しています。
- リリース日に従って統合チェーンを追跡します。ここでもホイールを再発明しませんでした。さらに必要になります。この問題を解決するために、リリースの統合テストにJIRAのEpic構造を使用しました。System3のリリース1.111.0の構造例：
一方では、これらすべてのアクションは、テストされた統合、システムバージョン、およびPRODでのリリースのシーケンスに関するチームの理解を向上させるのに役立ちました。一方で、人的要因による誤ったテストの可能性は依然としてあります。
- システムのリリース日が変更された場合、チームメンバーは、タスクの完了期限や、場合によってはテストされたシステムのバージョンを含め、カレンダーとJIRAの構造全体を手動で修正する必要があります。
- 統合をテストする前に、テスト環境が正しいバージョンのシステムで構成されていることを確認する必要があります。これを行うには、手動でテストベンチを調べて、いくつかのコンソールコマンドを実行する必要があります。
さらに、追加の日常業務が発生し、時間のかなりの部分を占めることもあります。
リリースの統合テストを準備するこのプロセスは、何らかの方法で自動化する必要があり、可能であれば1つのインターフェイスに組み合わせる必要があることが明らかになりました。これが私たち自身の命を救うバイクの出番です：統合テスト監視システムまたは単にSMIT。
開発中のシステムにどのようなオプションを実装しますか？
1.特定の日付のすべてのシステムのバージョンを表示する機能を備えた明確なリリースカレンダー。
2.統合テストのための監視環境：
- 環境のリスト;
- 別の環境の一部であるテストベンチとシステムの視覚的表示。
- テストベンチに配置されたシステムのバージョン制御。
3. Jiraのタスクでの自動作業：
- エピックリリース構造の作成。
- テストタスクのライフサイクル管理。
- リリース日が変更された場合のタスクの更新。
- 魅力的なレポートをテストタスクに配置します。
4. Bitbucketのブランチでの自動作業、つまりプロジェクトでのリリースブランチの作成：
- 統合自動テスト。
- 統合環境の自動加熱。
5.自動テストを実行してシステムバージョンを更新するための直感的なUI。
SMITHとは
システムは複雑ではないので、テクノロジーで賢くなりすぎませんでした。バックエンドは、SpringBootを使用してJavaで作成されました。フロントエンドはReactです。データベースに特別な要件はなかったので、MySqlを選択しました。コンテナを使用するのが通例であるため、上記のすべてのコンポーネントはDockerでラップされ、DockerComposeでビルドされました。SMITHは、他のMirPlat.Formシステムと同じように迅速かつ確実に動作します。
統合
- アトラシアンジラ。jirでは、特定の各統合をテストするためのタスクが作成され、開かれ、作業に取り掛かり、閉じられます。すべてのテストが成功すると、魅力レポートへのリンクがコメントに添付されます。
- Atlassian BitBucket. , , / . “” , .
- Jenkins. Jenkins, . , , glue Cucumber.
- . . ssh.
カレンダーを維持し、SMITで環境の状態を監視する前に、テスト対象のシステムとそれらの間の関係のリストを作成する必要があります。すべての設定は、Webインターフェイスを介して行うことができます。
テスト対象のシステムをSMITリストに追加した後：
- 環境のリストにあるSYS_CMDという名前のシステムのすべてのホストを「ノック」します。
- 構成で指定されたコマンドを使用して、このシステムのバージョンを検索します。
- このシステムの現在のバージョンとそれが表示される環境をデータベースに書き込みます。
その結果、SMITには、バージョン番号など、使用されている環境にデプロイされているすべてのシステムに関する情報が含まれます。この情報に基づいて、リリースカレンダーを視覚化できます。
リリースカレンダー
システムの所有者または製品開発チームのチームリーダーがPRODに新しいリリースをインストールした日付を教えてくれた後、このリリースをカレンダーに登録します。これが写真である
ことがわかります。数日で複数のリリースが同時にインストールされ、「ヒート」が発生する可能性がある競合に簡単に気付くことができます。同じ日に複数の新しいバージョンのシステムをインストールすることは非常に危険であるため、製品の所有者にはこれらの競合が通知されます。
また、カレンダーのあるページには、特定の日付のすべてのシステムのバージョンを表示する機能があります。カレンダーに
新しいリリースを登録すると、SMITは自動的にJiraにEpic構造を作成し、Bitbucketのプロジェクトにブランチをリリースすることに注意してください。
環境状態
SMITHのもう1つの非常に便利な機能は、特定の環境の現在の状態を表示することです。このページでは、環境に含まれるシステムのリストとそれらのバージョンの関連性を見つけることができます。
スクリーンショットでわかるように、SMITHはhost-4.nspk.ruで古いSystem 4バージョンを見つけ、それを更新することを提案します。白い矢印の付いた赤いボタンを押すと、SMITHはJenkinsジョブを呼び出して、現在の環境にシステムの現在のバージョンをデプロイします。対応するボタンを押した後、すべてのシステムを更新することもできます。
統合テスト環境
テスト環境をどのように定義するかについて少しお話しする価値があります。 1つの環境は、展開されたMir Plat.formシステムとカスタマイズされた統合（1つのスタンドに1つのシステム）を備えたスタンドのセットです。合計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はマスターブランチから構成ファイルの現在の内容を取得します。
テストの実行
SMITを作成する目的の1つは、統合自動テストを開始する手順を可能な限り簡素化することでした。例を使用して最終的に何が起こったかを考えてみましょう。
システムテストページ（この例では、システム3）で、統合を確認するシステムのリストを選択できます。必要な統合を選択し、「テストの開始」ボタンをクリックした後、SMITHは次のことを行い
ます。1。キューを形成し、対応するJenkinsジョブを順次起動します。
2.ジョブの実行を監視します。
3.Jiraの対応する問題のステータスを変更します。
- ジョブが正常に完了すると、Jiraのタスクは自動的に閉じられ、魅力レポートへのリンクと、この統合で欠陥が見つからなかったというコメントが添付されます。
- ジョブに障害がある場合、Jiraのタスクは開いたままになり、統合を担当する従業員からの決定を待ちます。従業員は、テストの失敗の原因を特定できます。統合の責任者は、統合カードに表示されます。
出力
SMITHは、統合テストのリスクを最小限に抑えるために作成されましたが、チームとしてもっと欲しかったのです。特に、ボタンを1回クリックするだけで、正しいテスト環境で自動テストが開始され、必要な統合一致ですべてがチェックされ、Jiraのタスクがレポートとともに開閉されることが望まれました。このような自動テスターのユートピア：システムに何をチェックするかを伝え、コーヒーを飲みに行きます:)
私たちが何とか実装したものを要約しましょう：
- 特定の日付にすべてのシステムのバージョンを表示する機能を備えたビジュアルリリースカレンダー。
- UI , , ;
- ;
- UI ;
- Epic Task Jira, Allure ;
- Bitbucket.
現在、システムは統合テストチームの直接メンバー間でクローズドベータテストを受けています。見つかった欠陥がすべて解消され、システムが安定して機能するようになったら、関連チームの従業員や製品所有者が独自にテストを実行して結果を調査できるように、アクセスを開放します。
したがって、理想的なシナリオでは、システムが統合要件を満たしていることを確認するために必要なことは、SMIT Webインターフェイスに移動し、それを介して必要なシステムを更新し、すべてのチェックボックスを選択してテストを実行し、それらがすべて正常に完了したことを確認することです。タスクは自動的に作成され、魅力レポートが入力され、対応するステータスがこれらのタスクに割り当てられます。