Renga BIMシステムはどのようにテストされていますか？

先ほど、KOMPAS-3Dのテストの配置方法とKOMPAS-3D のインターフェイスのテストの自動化について説明しましたが 、本日はBengシステムRengaのテストについて説明します。

ソフトウェアの開発過程にある多くの企業は、回帰エラーの問題に直面しています。 残念ながら、私たちも例外ではありませんでした。 この記事では、この問題が私たちにどのように現れ、どのような解決策を見つけたかをお伝えしたいと思います。 しかし、最初に、どのシステムを開発しているか、そして社内でテストプロセスがどのように構成されているかを説明する価値があります。

連歌とは

Renga Architectureは、建物の外観、情報モデル、図面の素早いレイアウトを作成するためにRenga Software （ASCONと1Cのジョイントベンチャー）が開発した建築および建設BIMシステムです。 そのユーザーは、建築家、デザイナー、およびコンストラクターです。




Rengaには、建物の建築モデルの作成、構造部品の設計、図面や仕様の取得に必要な多くのツールが含まれています。

もちろん、システムの機能全体をテストします。 テスト時には、ユーザーが3Dと2Dの両方でモデルを操作でき、すべてのプロジェクトエンティティが相互接続されていることを考慮する必要があります。 最初に、テスターは機能が手動で機能していることを確認し、コンプライアンスがチェックされます。 この段階では、開発者が後で修正するバグがあります。 手動テストとバグ修正の後、統合テストの作成に進み、機能を自動テストでカバーします。 次に、テストプロセスをさらに詳細に説明し、どのようにしてそれを実現したのかを説明します。

手動テスト

手動で多くの時間をテストします。 壁などの新しいオブジェクトの動作を確認するには、以下を確認する必要があります。

• 3Dおよび2Dの壁構造。
• 特性点の壁を編集し、そのプロパティとパラメーターを変更します。
• 他のオブジェクトと交差するときの壁の動作（天井、柱、梁などが壁を切断する）。
• 壁のあるデザインを描く。
• 計算された壁の特性（長さ、面積、体積など）の結論の正確さ。
• 壁材の応用と展示。
• 窓や出入口を挿入するときの壁の働き。
• 壁補強：パラメトリック補強、壁のネットとフレームのレイアウト。
• 壁パラメーターのローカライズ。

これは、新しいオブジェクトを追加するときにチェックする内容の完全なリストではありません。 これらのオブジェクトと関係がいくつあるか想像してみてください！

手動テストの過程で、再現が困難なエラー、またはシステムの特定の状態で発生するエラーが見つかります。 ユーザーインターフェイスにエラーがある人を驚かせる人はいないと思います。以下にリストしたエラーは非常に興味深いものです。

• 「小さな半径の円弧階段上の手すりの誤った表示。」 これは、アプリケーションでこのエラーがどのように見えるかです。

手すりは、小さな半径の階段にあるのではなく、「シュート」します。

• 「ツールバーのボタンが入れ替わっています。」 約1か月間、ボタンが逆になるケースをキャッチしようとしました。これは、さまざまなケースでさまざまな方法で発生したためです。

その結果、非常に珍しい再生手順が明らかになりました：3Dビューでコンテキストメニューを呼び出し、マウスの左ボタンでツールバーのいくつかのボタンをクリックし、ツールバーで現在のタブを離れて戻り、ボタンが場所を変える必要があります！ 説明した手順に従ってエラーが安定して再生され始め、すぐに修正されました。 それを再現する方法を学ぶのにもっと時間がかかりました。

自動テスト

BIMシステムの開発は6年前に開始されました。 開発の最初の段階で、アプリケーションは手動で単体テストでテストされました。 すべての機能に単体テストのテストカバレッジがありましたが、それにもかかわらず、すでに行われたことを壊していることに気付き始めました。 問題は、モジュールが個別に機能することでしたが、それらの統合によりエラーが発生しました。 問題は増大しており、統合テストをユニットテストに追加して、すべてのシステムモジュールの共同動作を検証することが決定されました。

既製のソリューションを見つける

インターフェイスを作成するには、 QTライブラリを使用します。したがって、統合テストを作成するための既製の製品を検索する際に、このライブラリで機能する製品を選択しました。 TestCompleteとSquishを可能なソリューションと見なしましたが、当時のこれらの製品のバージョンは私たちに適合していませんでした。Rengaは、これらの製品が識別および操作できないコントロールを使用しています。 そして、それらなしでは、これらの自動化製品の使用は非現実的でした。

独自のフレームワーク

ユーザーのアクションを繰り返し、必要なコントロールを使用して、必要なチェックのほとんどをカバーする独自のフレームワークを作成することにしました。 このフレームワークの開発は2012年に始まり、最初は次のようにアプリケーションが見えました。



Rengaで新しい機能を作成する過程で、ユーティリティも完成します。 つまり、実際には、Rengaとテストフレームワークの2つのアプリケーションを同時に開発しています。

フレームワークの原理

原則は、スクリプトを記録してから再生し、システムの参照スナップショットと結果のスナップショットを比較することです。 システムスナップショットは、テストの記録および再生時に作成されるxmlファイルによって記述されます。 テスト内のそのようなxmlファイルは、参照と結果です。 テストを記録すると、システムの固定状態の標準xmlファイルのセットが生成され、再生すると、結果のファイルのセットが作成されます。 アプリケーションのさまざまな機能を担当する次のタイプのxmlファイルがあります。

• Guiショット-GUIアプリケーションのログ
• モデルショット-モデルデータ
• シートショット-データと図面の描画
• 補助ショット-オブジェクトと追加のジオメトリの特徴点の位置
• スクリーンショット-自動的に比較されず、視覚的な比較にのみ使用されるpng形式の画像
• 引き出しショット-オブジェクトの描画
• ReportCSVショット-データをCSV形式にエクスポート
• Dxfショット-Dxf形式でデータをエクスポートまたはインポート
• XPSショット-XPSで印刷
• APIショット-APIテスト
• テーブルショット-図面とテーブルデータ
• 仕様ショット-仕様データ
• 仕様ビューショット-図面仕様

上記のように、ユーティリティはRengaで最終決定されており、新しいタイプのシステムスナップショットがRengaに表示されます。 たとえば、最新のリリースに備えて、 仕様をテストするために、仕様ショットと仕様ビューショットがユーティリティに追加されました。 また、特定のテストを見つけるのに便利なように、Pythonのスクリプトを使用したフィルタリングシステムが最近実装されました。

フレームワークの助けを借りて、オブジェクトの描画、図面の印刷、オブジェクト/図面のさまざまな形式へのエクスポートとインポート、オブジェクトの作成と編集、オブジェクトのパラメーターとユーザープロパティの変更、データと図面テーブル/仕様などを確認できます。

現時点では、フレームワークは次のとおりです。



ユーティリティの上部で、テストが保存されるフォルダーへのパス（xmlファイルとスクリプト）、および新しいRengaアセンブリへのパスが設定されます。 右側に、テスターはテストを記録するときに実行する必要がある手順を説明します。 以下は、テストの記録、再生、名前変更などのためのボタンです。

テストはアプリケーションのハンドセットバージョンで記録されるため、この動作は参照と見なすことができます。

新しいテストを記録するには：

1. テストの手順のシーケンスと、システムの状態を修正する必要がある各瞬間について説明します。
2. Recordボタンを押します。Rengaが起動し、上記の手順を繰り返します。
3. Rengaを閉じます。参照xmlファイルとテストスクリプトを作成しました。これにより、将来、テストが記述された機能のエラーを特定できるようになります。

テストが正常に記録されたら、サーバーに送信する必要があります。

1. テストをMercurialバージョン管理システムに配置します。
2. TeamCityを使用してサーバーでテストをプレイするのを楽しみにしています。

フレームワークがエラーをキャッチする方法：

1. 開発者は新しいコードを作業ブランチにアップロードします。
2. Renga.exeの新しいバージョンがアセンブルされています。
3. このバージョンの製品では、テストが再生され、参照（以前にテストされたバージョンで記録された）と結果のイメージ（現在のバージョンで記録された）が比較されます。

スナップショットが同じ場合-テストに合格、少なくとも1つのスナップショットが異なる場合-失敗したテストとこれらのxmlファイルが示されます。 テストが失敗した場合、指定されたファイルを処理し、不一致の原因を探す必要があります。 以下は、参照と結果のxmlファイルを比較する例です-Guiショット：



その結果、「e_SpecificationParametersPanel」パラメーターパネルの結果ファイルに、参照ファイルにない「e_SpecificationSortDropDownButton」ボタンが表示されたことがわかります。 このため、テストは失敗しました。 このボタンは新しい機能のために追加されているため、この動作は予期されています。 ここで、結果の画像が正しいことを考慮し、それを参照にする必要があります。 したがって、次のテスト再生は成功します。

そして、ユーティリティでのテストの再生方法を次に示します。



サーバーでのテストの構成

各コードがブランチにアップロードされた後、サーバーでテストが再生されます。



少なくとも1つのテストが失敗すると、ビルドはレイアウトされず、テストに使用できません。 テストが成功するまで、開発者は古い機能から何も壊れていないことを確認できないため、このルールにより、おそらく壊れている機能のテストに時間を浪費することはできません。

現時点では8千のテストがあり、それらを再生するには約2〜3時間かかります。 つまり、開発者からテスターへの新機能の配信時間は、何か問題が発生した場合、2〜3時間から1営業日です。 このような多数のテストにより、現在の機能をカバーできますが、場合によっては、稼働中のアセンブリを待つのに我慢する必要があります。 今、私たちはテストをプレイすることで結果をスピードアップする方法を考えています。

未解決のまま残っている問題

テストユーティリティはモジュール統合の問題を解決しましたが、アプリケーションGUIのテストには使用できません。 これは、ユーザーインターフェイス、フォーカス、キーボードからのキーのエミュレーション、スクロール、複数のウィンドウでの作業、つまり手だけでテストする必要があることを意味します。

多くの場合、この機能に関連するエラーがあります。 この問題を解決するために、GUI自動化の完成品を探し始めました。 Ranorexプログラムをテストしましたが、残念ながら、すべてのシナリオがテストされたわけではなく、現在のRengaの実装により一部のコントロールに到達できませんでした。 そのため、デスクトップアプリケーションのユーザーインターフェイスとQtを使用できるユーザーをテストするための既製のソリューションを引き続き探しています。

また、手でインストーラーをテストする必要があります。 過去数か月にわたって、pywinautoでpythonスクリプトの使用を開始することで、この分野で前進してきました。 これまでのところ、このソリューションはまだ初期段階にありますが、今、私たちが取り組む必要のある方向が見えてきました。

まとめると

私たちのプロジェクトでは、約⅔の時間に、テスターは手動テストに従事し、できるだけ多くのバグと脆弱性を見つけ、すべての要件が満たされているかどうかを確認しようとしています。 そしてその後、彼はこの機能が壊れないことを保証する自動テストを書き始めます。 自動テストの出現により、反復から反復まで繰り返される回帰エラーから自分自身を保護しました。 開発者は、数時間後にテストで問題のある領域が表示されることを知っているため、作業ブランチにコードをアップロードすることを恐れません。 また、テスターは新しい機能のテストに専念できます。

このアプローチにより、リリース前に長時間コードを凍結することがなくなります。 実際、リリースをテストして重大なエラーを修正するには1週間で十分です。 そして、これには少数のテストエンジニアと頻繁なリリースが伴います。1年に3〜4回リリースします（平均して、このようなCADシステムは1年に1回リリースします）。

そして、もちろん、私たちは問題を忘れません。 Rengaユーザーが新しい機能をより速く入手できるように、それらを解決しようとします。 あなたの会社が同様の問題を抱えていて、あなたがそれらを解決する方法を見つけたなら、私たちはアドバイスを聞いてうれしいです。

Elena Makarova、Renga Softwareのテストエンジニア。