1C：エンタープライズプラットフォームの開発における自動化

この記事では、1C：Enterprise 8テクノロジープラットフォームの開発とテストを自動化する方法について説明します。 1C：Enterprise 8プラットフォームは、ビジネスアプリケーションとその実行環境を作成するためのツールセットです。 これは、C ++、Java、およびJavaScriptの大規模（1,000万行を超えるコード）プロジェクトです。 何十人ものプログラマーがそれに取り組んでおり、同時に製品の最大10種類のバージョンを開発およびサポートしています。



プラットフォームは、OSおよびデータベースのさまざまなバージョンで実行されます。

• OS：Windows、Linux、macOS
• DBMS：MS SQL、PostgreSQL、IBM DB2、Oracle、独自のファイルDBMS
• モバイルOS：Android、iOS、Windows

いくつかのタイプのクライアントをサポートします：

• シンクライアント
• 太ったクライアント
• Webクライアント （Internet Explorer、Microsoft Edge、Chrome、Firefox、Safari）
• モバイルクライアント

上記のOS、DBMS、ブラウザの多くのバージョンをサポートする必要があることを考えると、プラットフォームのテストは簡単な作業ではありません。

一般的な自動化タスク

私たちが設定した目標：

• ルーチン開発およびテストタスクを可能な限り自動化および加速します。
• 最小限のテスト労力での継続的なテスト
• 製品バージョンに高品質の新しいコードのみを追加します
• 古い機能を壊さないでください
• 製造プラットフォームの重大な欠陥の数をゼロにする
• 問題を早期に検出して、調査と修正のコストを最小限に抑える

プラットフォームの複数のバージョンの同時開発



継続的インテグレーション（CI）の実践を使用しています。 コードの作業コピーを共通のメインブランチにマージすることは、変更されたプロジェクトのマージ、自動アセンブリ、および自動テストが実行された後、1日に数回行われます。 アセンブリまたはテスト中に問題がある場合、変更されたコードが修正のために返されます。





1つのプラットフォームバージョンの開発プロセス



CIが直面する課題：

• 組立
  
  
  • さまざまなタイプの一連のアセンブリと、連続サイクルの一部としての可変バージョンのその後のテスト。 テスト結果の孤立した変更の調査を高速化するために、インクリメンタルコンパイルを使用します。変更されたものと直接的な依存関係のみがコンパイルされます。 アセンブリは完全なテストサイクルのために完全に組み立てられます。 追加のアセンブリの必要性と順序は、予備分析が自動化されたテスト結果によって決まります。
  • 重大な変更（統合ビルド）を別に確認します。 エンジニアが変更を重要と考える場合、最初に変更を別のブランチに注ぎ、それを収集してすべてのテストを実行します。 すべてのテストが正常に完了すると、メインブランチに変更が加えられます。
  • 可能であれば自動モードでエラーを最速で検出
  • ルーチンアクションの自動化（ダンプの分析、ブランチ間の変更の移行、エラーの登録）
• 階層テスト
  
  
  • 回帰
  • 単体テスト
  • 統合テスト
  • ストレステスト
  • 視覚的テスト
  • 後方互換性テスト
  • シナリオテスト
• プログレッシブ
  
  
  • ほとんど機能
• 受入試験
• テストの進捗と変更
  
  
  • ここには手動テストが含まれます

自動組み立ては1日に数回行われます。 完全な自動テストサイクルには約1日かかりますが、残念ながら、一部のタスクでは許容できないほど長くなります（テストリソースのバランスを取ると、空きリソースがある場合はプロセスが高速化されます-現時点である場合）。 この悪影響を軽減するために、1時間で実行され、機能の約80％に影響する「ライト」バージョンのテストを開発しています。 したがって、一般的な理解-アセンブリがどれほど効率的であるか-私たちははるかに速く得ることができます。 時間が必要ない場合があります。

現在、テスト時には、以前のテストサイクルの結果が考慮され、問題のある/新しい/修正されたテストが高い優先度で起動されるため、テストの開始時に最も変更可能な機能の変更の進行状況を直接確認できます。



一部のタイプのアセンブリでは、同じシリーズ内で10個の障害が発生したときに一連のテストが自動的に中断される場合、他のアセンブリ/他のバージョンなどのテスト用のリソースを解放するために、「10個の障害」ルールが採用されます



約70台の物理サーバーと約1,500台の仮想サーバーが、アセンブリとテストに参加しています。

ツール

ジェンキンス

Jenkinsは継続的な統合システムとして使用しています。 ピーク時には、1日あたり20のプラットフォームアセンブリから実行されます。 1つのアセンブリを完了するのに約1.5時間、テストするのに1時間かかります。 アセンブリは、アーキテクチャ（Windows、Linux、macOS）、各アセンブリ-同時に数百のスレッドで並行して実行されます。 数年前のこのアプローチにより、すべてのアーキテクチャを備えたプラットフォームの1つのバージョンのアセンブリ時間を8時間から80分に短縮することができました。

Jenkinsは、Webサービスを通じて、タスクトラッカーであるタスクベース（1C：Enterpriseプラットフォームに記述されています）と統合されています。問題が発生した場合、タスクベースで直接エラーを自動的に生成し、ログとテストアーティファクトへのリンクを適用します。 Jenkinsは、必要に応じて、公開用のプラットフォームを準備し、ダンプをフィルター処理して解析します。



また、Jenkinsはテストを管理し、多数の仮想マシンを含む任意のハードウェア構成に任意の複雑なシナリオを実装できるようにします。また、1日最大70回まで1,500台のサーバーにプラットフォームを配信およびインストールするなどの追加作業も行います。

Apache JMeter

JMeterには非常に価値のある品質があります-多数のユーザーの作業をエミュレートするためのハードウェア要件が低くなっています。 JMeterでは、1つのテストで混合負荷を生成することもできます-HTTP、SOAP、JDBC、LDAP、SMTP、TCP。



特に、JMeterを使用して、アプリケーションクラスターとその個々のコンポーネントのパフォーマンスをテストし、多数（最大10,000）のユーザーでアプリケーションクラスターの負荷テストを行います。 このテストでは、1台のデータベースサーバー、2台の1Cサーバー、1台の負荷サーバーで十分です。



単一のクラスターがテストされる4つのテストベンチ、フォールトトレラントおよび非フォールトトレラント構成のクラスターがあります。 これらの構成をテストするには、2台の物理マシンのみが必要です。





JMeterパフォーマンスチャート

テストセンター

より複雑なテストには、製品テストセンター （ Corporate Toolkitの一部）を使用します。 テストセンターは、1C：Enterprise 8プラットフォームの構成です。 これにより、マルチユーザーテストシナリオを記述し、自動的に実行し、進行状況を監視できます。 いわゆるコンベア上でテストセンターを運営しています。 1つのパイプラインは、仮想マシンが配置されている2つの強力な物理サーバーで構成されています。

• 1つのアプリケーションサーバー1C
• 1台のデータベースサーバー
• 1ライセンスサーバー
• クライアントセッションを備えた40台のサーバー

コンベアの精度を改善するために多くの努力をしました。 現在、同じプラットフォームのバージョンと構成でテストを実行すると、結果の広がりは1.5％未満です。 100個の非常に高速なクライアント（ポーズなしで操作を実行）または実際のユーザーに近い1000個のクライアント（アクションの間にポーズを入れて普通の人の作業をエミュレート）が1つのコンベアで動作します。

コンベヤーは、典型的なスタンドオプションを設計します。

• 小さい
• 中
• 大きい

コンベアから15種類の作業現場の構成を組み立てることができます。 構成は、サーバー構成、フォールトトレランスで異なります。 サーバーはLinuxおよびWindows上に配置できます。 テストのベース（およびテストシナリオ）は、2つのバージョンで用意されています。

• クラウド、 1cfreshテクノロジー（多数の比較的小さなデータ領域を持つデータベース）
• CORP、大規模展開用（大規模ベース）

構成された個別の情報ベース（1cfreshテクノロジーでの作業のテスト用）：

• 1C：会計
• 当社の経営
• 給与および人事管理

CORPオプションでは、構成がテストされます。

• 給与および人事管理
• 1C：ERPエンタープライズ管理2

負荷テストには、1、2、4、10個のコンベアが含まれます。

負荷テストは、100、200、400、3000、および10000ユーザーのオプションで利用できます。

作業サイトのさまざまな構成では、クラスター内のサーバーの数は1から6まで異なります。



1つのデータベースで10,000人のユーザーに対してテストを実行するには、2つの稼働中の1Cアプリケーションサーバーを使用します。 各クラスター構成は、各テストの開始時に数百のパラメーターから自動的に構成されます。 実際、次の理由から、スタンドは作業のために完全に準備されていると想定できます。

• 配信されたプラットフォーム
• スクリプトが配信されます
• クラスターが構成されています
• データベースの読み込み
• 構成ファイルが構成されます（指定されたパラメーターに従って）
• インフォベースの出版物の準備

クラスター構成スクリプト、構成ファイル、OS、特別な処理はGitに一元的に保存され、変更があると自動的にスタンドに配信されます。

また、テストシナリオの再構築（製品バージョンの更新中にデータベース構造が変更される）もあります。 同じスタンドでリストラをテストしています。 テストが完了した後、最終結果がチェックされます-データベース内のデータが正しく更新され、データベース構造が新しいバージョンに対応している必要があります。 古い再構築メカニズムと新しい再構築メカニズムの両方がテストされています。



ストレステスト中に、自動的に収集および分析します。

• テストセンターによるとすべてのエラー
• プラットフォーム技術雑誌の例外
• プラットフォームのテクノロジーログからのすべてのリクエスト
• ログからのすべてのエラー
• 実装に関する技術情報を使用して実行される操作のすべての測定
• すべての機器負荷データ

すべてのデータについて、レポートが自動的に生成され（テストの種類に応じてさまざま）、責任者によって送信されます。 すべてのデータは、統計とテスト結果を含む特別なデータベースに保存され、集約されます。





テストセンター画面



また、ハードウェア障害、ネットワーク障害、メモリ不足、CPUリソース、およびディスク領域のシミュレーションを使用して、フェールオーバークラスターで「1C：ERP Enterprise Management 2」構成の10,000ユーザーの作業の負荷テストを実行します。 これは大規模なテストシナリオであり、1Cサーバープロセスがテスト全体で1つずつフリーズし、一部のプロセスがtaskkillユーティリティによって「強制終了」され、ネットワークが切断されて復元されます。 テストの一環として、異なるサブシステムでの作業のユーザーシナリオ（倉庫、購入、販売、相互決済など）が実行されます。 ERPストレステストでは、約400の主要な操作が実行され、テストには数時間かかります。

構成パフォーマンスの比較

説明したシステムに加えて、パフォーマンスを比較できる内部ツール「構成パフォーマンス比較」（SEC）が機能します。

• 同じプラットフォーム上の同じ構成の異なるバージョン
• 同じ構成の2つのバージョンのプラットフォーム
• 同じプラットフォーム/構成の異なるバージョンのデータベース/ OS

「構成のパフォーマンス比較」システムは、通常の負荷テスト中に収集されるすべての同じパラメーターを収集します。 システムにより、エラーの発生、サーバーの負荷の変化、リクエストの期間の変化（または以前は存在しなかったリクエストの出現）を自動的に検出できます。



問題の症状である可能性がある劣化と改善の両方を分析します。



システムを比較に使用できます

• 構成バージョン
• プラットフォームバージョン
• DBMSバージョン
• 任意の設定

その結果、詳細な情報とパフォーマンス、機器負荷の比較とともに、合格した負荷テストに関するレポートを取得します。 レポートには、DBMSへのクエリの実行時間、例外の事実などが含まれます。



パフォーマンスの比較とは、キー操作ごとに、構成の全体的なパフォーマンス、平均ランタイム、および平均APDEXを測定することです。

ビジュアルテスト

上記のツールはすべて、ユーザーの作業をエミュレートし、テストされた構成の組み込みオブジェクトの適切なメソッドを呼び出し、WebサービスやHTTPサービスなどを呼び出します。 しかし、ユーザーが実際に見ているものを正確にテストすることも非常に重要です。特に、ユーザーがWebクライアントで作業している場合（ブラウザーでインターフェースを描画するにはかなり時間がかかる場合があります）。 新しいバージョンに切り替えても自動テストに関するパフォーマンスが変わらないという状況に直面しましたが、ストップウォッチを持つ人を植えると、彼は古いバージョンで1つの番号を受け取り、新しいバージョンでまったく異なる番号を受け取りました。 これは、特に、新しいバージョンでは何らかの理由で変更される可能性のあるグラフィカルインターフェイスのレンダリングの時間によるものです。

ほぼすべてのアプリケーションの視覚的なテストを実行できる独自のツールを作成しました。 このツールは、アプリケーションを起動したユーザーのアクションをスクリプトファイルに書き込みます。 このツールは、画面の作業領域の画像も記録します。 クライアントの新しいバージョンを監視する場合、ユーザーの参加なしにスクリプトが再生されます。 スクリプトを再生するとき、ツールは、キーストロークまたはマウスボタンをシミュレートする前に、記録されたスクリプトと同じ画面イメージ（ピクセルに正確）の外観を期待します。



このツールは、25ミリ秒の精度でアプリケーションのパフォーマンスを測定し、結果をログに書き込み、さらに自動比較します。 場合によっては、スクリプトの一部をループバックして（たとえば、順序の入力を数回繰り返す）、スクリプトの実行時間の低下を分析します。 このテストは、パフォーマンスの測定に加えて、プラットフォームの新しいバージョンで、ユーザーがシンクライアントとブラウザで以前のバージョンのアプリケーションと同じ画面を表示することを確認することもできます。



「Managing Our Company」構成で注文を入力するスクリプトを実行する例-注文は5回入力されます。 ユーザーがインターフェイスの可用性に即座に応答する場合の1C：エンタープライズプラットフォームの実際の速度は次のとおりです。

機能テスト

機能テストも積極的に開発しています。 OSとデータベースのメインバージョンの組み合わせをテストします。このような組み合わせごとに独自の仮想マシンのセットがあり、組み合わせのセット全体が1つのコンベヤを形成します。 このパイプラインへのOSとDBの新しい組み合わせの自動追加。 各機能テストは、可能なすべての組み合わせで実行される一連のタスクに変わります。 タスクは最初のフリースタンドによって実行されます。 Configurator （1Cアプリケーション開発環境）、埋め込み言語機能、クエリ言語などがテストされます。



Configuratorをテストするとき、Configuratorのコマンドラインで使用可能なコマンドのほとんどを確認します。 さらに、特別なライブラリ（外部には提供しません）があり、UIの直接テストに頼ることなく、ユーザーインターフェイスからのみアクセス可能なConfiguratorの内部ロジックをテストできます。 したがって、構成拡張機能、比較/結合機能、およびその他のConfigurator機能を操作するためのほとんどの機能がテストされます。



このモードでテストするために、1C言語でスクリプトを作成できます。 スクリプト内では、テスト目的で特別なオブジェクトを使用できます。 このモードでコンフィギュレータを起動すると、1つのテストでクライアントアプリケーションの起動と組み合わせることができます。 これにより、コンフィギュレーターをテストする手段としてだけでなく、テスト環境を構成する方法としてもこのモードを使用できます。

自分のドッグフードを食べる

日常業務で使用する1C：エンタープライズプラットフォームで書かれた社内ツールが多数あります。 プラットフォームの最新ビルドで動作します。 以下では、そのうちの2つ、「タスクベース」と「従業員レポート」について説明します。

タスクのベース

社内のタスクトラッカーである「タスクベース」は、1C：Enterpriseプラットフォームで記述された構成です。 これは、OSとDBMSが異なるプラットフォームの異なるバージョンで21の独立したデータベース（一部は動作中、一部はテスト中）です。データベースはプラットフォームデータ交換メカニズムを介して同期されます。 プラットフォームのバージョンは毎日更新され、一部のサーバーでは、プラットフォームの実験的なバージョンが個別の新機能とともにインストールされます。プラットフォームの新しいキャプティブ機能は、翌日に「タスクのベース」でテストできます。さまざまなデータベースインスタンスはさまざまなサーバー環境（OS、DBMS）およびさまざまなバージョンのプラットフォームで動作し、ユーザーはさまざまなクライアント（シンクライアント、モバイルクライアント）から、またさまざまなブラウザーからWebクライアントを介してログインします。したがって、異なる環境で異なるバージョンのプラットフォームのテストが実行されます。

従業員レポート

「従業員レポート」は、1C：エンタープライズプラットフォーム開発部門の従業員が使用するタイムトラッキング用のタイムトラッカーです。プラットフォームの最新ビルドで動作します。

「1C：ドキュメント管理」

また、標準の1C：ドキュメント管理ソリューションを使用します。これは、当社のすべての従業員が使用し、プラットフォームの新しいバージョン、まだリリースされていないバージョンで使用されます。

適用ソリューションのプラットフォームテスト

一般的なアプリケーションソリューション（「エンタープライズアカウンティング」、「当社の管理」、「給与および人事管理」など）の自動ビジュアルテストとともに、主なケースのテスト計画に従ってシナリオ、ビジュアル、マニュアルテストを実行します。プラットフォームの品質が一定レベルに達した後、適用された構成の開発者に、プラットフォームの新しいバージョンでの開発に切り替えて、リリース準備中のバージョンで製品をテストするよう依頼します。

パートナーによるプラットフォームベータテスト

一部のパートナーは、まだリリースされていない以前のバージョンの1C：Enterpriseプラットフォームの使用に関心を持っています。そのようなパートナーは、1C でNDAに署名し、テストバージョンのリリース前にプラットフォームアセンブリにアクセスし、実際の状態でプラットフォームの最新バージョンを使用する機会を得ます。これにより、パートナーはプラットフォームの問題を早期に検出し、プラットフォームのリリースバージョンでこれらの問題が発生しないことを確認できます。このようなパートナーからの高い優先度で見つかったエラーに関するリクエストを検討します。ところで、この記事の読者の1人が1C：Enterpriseプラットフォームのベータテストに参加したい場合は、CorpTechSupport @ 1c.ruに連絡してください。

計画

この計画には、開発の完了からリリースまでの時間を短縮するために、メインアセンブリのリリース準備が常に整っていることを前提とした継続的デリバリーへの移行が含まれています。これを実現するために、テストカバレッジを拡大し、機能テストと負荷テストを開発します。