7

マウスとキーボードのイベントを記録して再生することで、GUI ユーザー シナリオを記録および再生できる GUI テスト フレームワークをいくつか作成しています。

現在、マウス イベントは として記録されてい(press or release, (x, y))ます。ただし、宛先ウィジェットが数ピクセル移動するだけで、構造と他のすべてが同じままである場合、テストケースは機能しなくなるため、これは非常に脆弱です。

これを行うためのより良いアプローチは何ですか? 私が考えることができるいくつかのこと

  • ウィジェットとその親ウィジェットのツリーに、宛先ウィジェットの「ツリー パス」を記録します。つまり(press or release, (top level, first child, second child, destination))、「子リスト」は Qt のQObject子リストによって返されるものです。これには、テストが内部コード構造に依存するという欠点があると思います。

  • テスト可能なすべてのウィジェットに一意の名前を付け、再生時にその名前でウィジェットを検索します。これは無視できないオーバーヘッドのようです。

他のアイデアと、これに対する一般的に受け入れられている「最良の」アプローチは何ですか?

4

1 に答える 1

1

仕様

テスト ケースがテストの特定の設定やコードの変更にどの程度バインドされるかは、ユーザーが決定します。それは基本的に、仕様がどれほど厳しいかという問題です。

一方では、「機械的」または「ダム」テストがあります。厳密に制御された初期条件でテストしている可能性があります。初期ウィンドウ位置の同じ設定がテスト前に事前に設定されている、同じプラットフォーム スタイルが適用されている、同じフォントが利用可能であるなどです。その場合、それは合理的な期待です。ウィジェット内で 2 つのボタンを切り替えたり、最初のウィンドウ/ダイアログ サイズを変更したりすると、テストは失敗するはずです。

一方、「人間」のテストがあります。紙から台本を読む人間がテストで成功するなら、テストが成功することを望むかもしれません。このような場合、フォント、視覚要素の位置などの小さな変更は重要ではありません。人間のテスターは、そのような変更に容易に適応します。

これら 2 つの極端な例は、アプリケーションのさまざまな部分、または製品ライフサイクルのさまざまな段階に一度に適用される場合もあります。

航空宇宙飛行管理システムの UI を設計している場合、仕様の変更でカバーされていない UI の変更は実際にはバグになるため、完全に「機械的」で適応性のないテストが必要になる可能性がある側面があります。 .

コンシューマ アプリケーションを設計している場合、バグ修正やマイナー リリース全体で仕様を厳密に維持したい場合がありますが、メジャー リリースなどではこれを緩和することができます。

テストケースとテスト済みコードからの協力

より柔軟でより人間らしいテストを実装するには、テストされるコードまたはテスト ケース生成プロセス、またはその両方からの協力が必要です。

テスト ケース生成プロセス (テスト スクリプト、人間など) には、特定のイベントの意味に関する重要な知識があります。たとえば、一般的なボタンのクリックは、実際にはボタンの中央に向けられています。その場合、ボタンのアクティブ領域の角が丸くてクリックに反応しないかどうかは問題ではありません。クリックは、ボタンが特定のプラットフォームのボタン バーの右端または左端にあるかどうかに関係なく、「OK」というラベルの付いたボタンに送信される場合もあります。

テストされたコードには、特定のイベントの分類に関する重要な知識も含まれています。たとえば、ペイント プログラムのキャンバス上でのクリックの場合、クリックの座標自体が重要な場合があります。それ以外の場合、正確な座標ではなく、重要なのはウィジェット内の特定の視覚要素である可能性があります。後者の場合、プラットフォームのスタイル設定またはコードの更新によるウィジェットの外観の変更により、相対座標が不要になる可能性があります。

于 2014-02-10T19:29:28.903 に答える