テストエンジニアのキャサリン・ロディナは言う。
KOMPAS-3D v17バージョンの重要な要素は、新しいインターフェイスです。 その開発は別のブランチで実行され、2〜3日ごとに開発が製品のメインブランチにマージされ、他のチームが使用できるようになりました。 しかし、与える前に確認する必要があります。
インターフェイスは非常に活発に変化しています。 イノベーションのために、以前に行われたことが「壊れた」ということが起こりました。 そのような瞬間を逃さないために、手動の回帰チェックを行いました。 一般的なブランチへの各放電の前に、新しいコードのテストに加えて、古いコードをチェックしました。 時間が経つにつれて、テスターの仕事は同じ名前の映画のように無限のグラウンドホッグの日となりました。各営業日は、すべてのテストケースの手動実行から始まりました。
初めてチェックにかかったのは30分だけでした。 新しいインターフェイスで機能する機能が蓄積されると、回帰チェックの期間が長くなり、稼働日全体に近づきましたが、これは制限ではありませんでした。 新しい機能のテストに費やす時間が少なくなりました。 プログラマーは自分の仕事のチェックを待って並んでいました。 質問が発生しました：「私は何をすべきか？」答えはそれ自身を示唆しました：回帰テストは自動化されるべきです！
最初のタスクはツールの選択です。 このために「車輪を再発明」する必要がありますか？ または、既存の定評のある自動テストプログラムを使用できますか？
調査後、既成のソリューションの適応、テストの作成、絶えず変化するインターフェイスでの動作状態の維持は不可能なタスクであることが明らかになりました。
その結果、独自のモジュールを使用して自身をテストするようにKOMPASを変更することが決定されました。 このアプローチにより、回帰テストにサードパーティ製品を使用できなかった主な問題が解決されます。
1.絶えず変化する環境に干渉しません。
2. 3Dグラフィックスを備えたウィンドウでの完全にシミュレートされたユーザーアクション。
プログラマ向けのKOMPAS-3D自動テストモジュールを作成するタスクは、新しく珍しいものであったため、興味深いものでした。 開発期間全体に十分なインスピレーションがあり、この複雑な作業を実装することができました。 「テープレコーダー」（作成されたモジュールの名前が付けられました）は、回帰テストv17のメインツールになりました。 もちろん、すべてがスムーズだったわけではありませんが、私たちはそれを行いました！
テープレコーダーの使用方法
まず、各要素の手動テストが実行され、エラーが修正され、その解決策が説明されます。 回帰テストの自動テストは、すべてのエラーが修正され、要素が安定した作業の最終段階で記録されます。
録音はレコーダーの原理に従って行われます。 [再生]ボタンを押します-テストケーススクリプトを手動で実行し、[停止]を押します。 テストケースでは、チェック対象の要素を使用したユーザーのアクション（プログラムを開く、構築を完了する、プログラムを閉じる）を完全に説明します。 特定の時点で、コントロールポイントが作成されます。 テストを含むファイルの準備ができました。自動テストに使用できるようになりました。
テストが開始されると、プログラムは事前に記録されたアクションを繰り返し、結果はコントロールポイントで比較され、テストは終了します。
テストスクリプトは、テスターまたはプログラマーを手動で編集する機能を備えたxmlファイルで記述されています。
KOMPAS-3Dソフトウェアは、モジュール、インターフェイス、3Dモデルのモジュール、図面のモジュールに分かれています。 それぞれモジュールと自動テストに分けられます。
インターフェース
インターフェイステストレコードは、イベントをインターフェイスの論理オブジェクトにバインドすることに基づいています。 ボタン名があり、それに発生するイベントがあります。 インターフェイスコントロールポイントは、スナップショットとスクリーンショットの2つの要素で構成されています。
スナップショットは、システムの現在の状態に関するすべてのデータが書き込まれるテキストファイルです。 実際、2つのコントロールポイントを比較すると、スナップショットが比較されます。 すべての違いはエラーとして表示されます。
スクリーンショットは視覚化用です。 結果の視覚的評価を簡素化するために、機能が追加されました。スナップショットで明らかになったすべての違いがスクリーンショットで紫色のフレームで強調表示されます。
スナップショットの違いの視覚化
どのような問題を解決しなければなりませんでしたか：
1.大きなサイズのスナップショット
システムの状態に関するすべての情報を取得したかったため、スナップショットはスペースを取りすぎました。 100テスト-28 GB。
体積を減らすために最初に行われたのは、外観に影響を与えない要素の削除です。 ユーザーに要素が表示されない場合、現時点ではそれらに関する情報は不要であり、スナップショットに記録する必要はありません。 次に、インターフェース全体を選択してコンポーネントに分割しました。必要に応じて、すべての要素、または現在作業中の1つまたは2つの要素に関する情報を書き留めます。
比較するアイテムを選択します。
このアプローチにより、ハードドライブの占有スペースが50倍削減されました。 現在、100個のテストが0.5 GBを占有しています。 テストの実行時間は3回短縮されました-テストあたり平均30秒から10秒になりました。
2.多数のエラー
多くの場合、自動テストの実行の結果として次のインターフェイスの変更を排出した後、エラーのシャフトが観察されました（1つのテストで1000エラー）。 たとえば、パネルの長さが変更され、このパネルにあるすべてのコントロールの長さが変更されました。 テスターは、これを1つの間違い、プログラムを1ダースと見なします。 このようなエラーは、親要素と子要素の間にチェックを追加することでブロックに結合されました。 親と同じエラーが子で発生した場合、結果から除外され、このエラーはテストですでに考慮されていると考えられていました。
3.エラーと改善点の分離
たとえば、アナリストは、左側のボタンが見苦しく、右側に移動する必要があると判断しました。 その結果、このボタンが物理的に存在するすべてのテストでエラーが発生します-ボタンの位置が正しくありません。 このようなエラーを一般的なプールの実際のエラーと区別することは困難でした。 エラーパターンを無視する機能を追加しました。
パターン無視
100個のテストを実行し、そのうちの1つを開き、ボタンを移動したことを確認し、ダミーの「エラーを無視」を配置します。その後のすべてのテストでは、このエラーは消去され、考慮されなくなりました。
4.テストスイートの使用
簡単にソートできるように、各テストには一定数のタグが掛けられています。
タグを使用する
3Dワークスペース
ワークスペースのテストは、インターフェイスとは根本的に異なります。 イベントは、モデルの3次元座標（x、y、z）に関連付けられています。 参照と比較するビットマップを作成します。 このため、サードパーティのImageMagickプログラムが使用され、すべての違いが赤で強調表示されます。
試験例
異なるモジュールのテストは、一緒に、および互いに別々に記録できます。 ビデオからのテストでは、明確にするために、特別なミスが行われました。ホイールとブレーキディスク間の間違った距離が設定されました。 ラスター画像を比較すると、ホイールが赤で強調表示されていることがわかります-ホイールは正しく配置されていません。
ここでどんな困難が生じましたか：
1.スケーラビリティ
異なる解像度（異なるスケール）のモニターでは、カーソルがクリックされたときに突然カーソルを見逃し始めたときに状況が発生しました。 これは、異なるスケールで再カウントするためでした。 ある時点で発生したエラーが重大になりました。 すべてのテストで解像度とスケールを強制することで、この問題を非常に簡単に解決しました。 テストを実行するモニターは関係ありません。プログラムウィンドウは、目的の解像度のサイズに自動的に調整されます。 当然、これは小規模から大規模に機能します。 逆方向では機能しません。 テストを作成するモニターの規模について合意しました。
2.パフォーマンス
たとえば、ユーザーは2秒でアクションを実行し、プログラムは5倍の10秒で実行します。 これらはどのような自動テストですか？ 彼らは理解し始めました。 カーソルの座標は次のように記録されました。モニター上のカーソルの2D座標が取得され、ビデオカードを介してモデル内の3D座標に変換され、その後イベントが発生しました。 変換により、ビデオカードの再描画が継続的に行われ、モデルは常に再描画されました。 多数のパーツが内部にあるボリュメトリックモデルに遭遇した場合、再描画に長い時間がかかりました。 通常、変換を拒否し、すぐにモデルの3次元座標での記録を開始しました。 このチェーンからビデオカードを除外しました。
3.異なるグラフィックカードでのモデルの実装
好むと好まざるとにかかわらず、異なるビデオカードでは、同じモデルのラスターイメージが異なります。 ただし、違いはわずかであり、1％の誤差を割り当てることにしました。 モデルが1％まで一致する場合、モデルは正しいです。 1％を超える場合、エラーが発生しています。 現在、異なるビデオカードでは、モデルは0.01まで一致します。
4.バックグラウンド制御
この問題には解決策がありますが、まだ実装されていません。 3Dモデルの写真があるとしますが、この写真からは、モデルの「背中」に何があるのかがわかりません。モデルを背にして写真を撮るまではわかりません。 モデルをセグメント、頂点、面に分割し、指定された要素ごとにプロパティを比較するために、洗練された制御システムを使用する予定です。
実用化
KOMPAS-3D v17の開発中、2〜3日ごとに回帰チェックが自動的に実行されました。 新しい機能をテストする時間は長くなり、テストを処理する時間は短くなりました。 当初、このレコーダーはインターフェースグループの負荷を軽減することを想定していましたが、他のKOMPAS-3Dモジュールのテストに応用できました。
私たちはそこで止まるつもりはありません。 計画には、自動テストの使用の拡張（理想的には、KOMPASの機能全体をカバーする）、テストベースの拡張が含まれます。 そして、もちろん、その後の更新とサービスパックKOMPAS-3D v17を安定させるための「テープレコーダー」の使用。
インターフェイステストエンジニアのEkaterina Rodina。