動的コンテンツの自動テスト

Question

私は、多くのテーブルがあるいくつかの剣道ベースのサイト（一部は開発者によって手作りされている）に対してSQA作業を行っています。これらのテーブルには、多数の行、列、ページ、およびデータが入力されているため、基本的には非常に動的なコンテンツでSQAを実行しています。

行を追加または行を編集のような機能が動作することを確認する自動スクリプトを作成しようとしていますが、プロセスは非常に退屈で失敗しがちです（実際のテーブルコードは不適切ですが、コンテンツが動的であるため、Seleniumスクリプトが間違った行、列などを取得します。）

たとえば、テーブルに行を追加するためのSeleniumスクリプトを作成する場合は、次のようにする必要があります。

特定のテーブルのxPathを把握する
Xpathを保存する
XpathCountを保存する
行を追加する
詳細を記入
新しいXpathCountを入手
新しい行数が元の行数より1多いことを確認してください
これまでのところすべてが適切である場合は、特定のパスを新しい行に取得し、それがあなたの考えている場所であることを願っています
この新しい行のすべてのデータは、行の作成時に入力されたものであると断言します

あなたのテーブルがアルファベット順に物事を保存していて、開発者が実行している他のすべてのテストを制御できないとしましょう。あなたが作ったものもあれば、他の人が作ったものもあります。 Seleniumスクリプトを実行して「行の作成」をクリックすると、「行の作成」ページで、「Bob」というメイン属性名を持つ行の詳細が自動的に入力されます。次にSeleniumは「Submit」をクリックします。

テーブル/ウェブページでは、「BAMF」と「Karl」の間に「Bob」という行が挿入されますが、コンテンツが動的であり、「Bob」を含む行を探す手がかりがないため、セレンテストは最終的に失敗します。テストを実行するたびに「Bob」がどこに行くかを確認するためにテーブルを見る必要がある場合、行をどこに置くかを知るためにスクリプトを更新できますが、自動化しないこともできます。

このようなテストは自動化されていないはずですか？このようなテストスクリプトは、ユーザーが入力した空のテーブルでのみ実行されるはずですか？

Jonathan Eunice · Accepted Answer

あなたはライブの自動テストの正しい道を進んでいるようですが、いくつかの非常に複雑な要因があります：

動的コンテンツは、テストを指定する難しさを高めます。あなたはしばしば、少なくともいくぶんより一般的な言葉でそれを述べる必要があります。
しかし、さらに悪いことに、その他のさまざまな、おそらく競合するテストが並行して行われます。これは本当にアンティを上げます。「ボブ」を追加しているときに、他のテストで「アリス」または「ボブ」が追加される可能性がある場合、アイテムがデータセットの固定位置にあるか、アイテムの数が固定されているとは限りません。ナビゲーションとテストの条件は、はるかに柔軟かつ一般的に述べる必要があります。また、障害に対して柔軟に対応する必要があります。並列環境では、正しく指定されていても、一部のテストは常に失敗します。それは避けられない。「ボブの行を追加する」をテストしているときに、他の誰かが「ランダムな行を削除する」または「AからFの文字で始まるすべてのレコードをパージする」をテストすると、その行が危険にさらされます。時間の経過とともに、十分なテストが行われると、時々競合テストが勝つことがあります。また、一時的な障害になります。テストを再実行します。テストがまったく同じ方法で再度衝突することはほとんどありません。（一時的な問題は、まれであるだけでなく悪化するため、状況を改善する可能性があります。時間に依存するため、追跡、理解、および修正がはるかに困難です。）

いくつかの推奨事項：

自動化をあきらめないでください。データとアプリケーションの動作がより複雑で動的であるほど、より重要ですテストを自動化することです。複雑なシステム。すべての行動を繰り返しテストするためのエネルギーと集中力はありません。大規模なチームが作業を行っている場合でも同様です。自動化が唯一の信頼できる方法です。これらのテストをより柔軟で包括的な方法で指定する方法を学ぶときは、辛抱してください。
テストの分離度を高めます。最近のクラウドインスタンス、仮想マシン、仮想環境は驚くほど安価です。おそらく、独自のアプリインスタンスを生成してテストできます。これにより、並列処理のバガブーが完全に削除され、作業が簡略化されます。また、テストの実行ごとに、またはテストのニーズに合わせていつでもロードできる、初期の事前定義されたデータセットから開始することもできます。しかし、それは難しいかもしれません。私は、経営陣が個別のテストインスタンスを用意することができないと主張した状況にありました。私は、実動システム（プロダクションデータ（shiver））でいくつかのテストを行うことが義務付けられているライブの商用製品にも取り組んできました。
データの分離を向上させます。独自のテストインスタンスを作成できない場合でも、テストの分離を向上させることができます。私はしばしばこれを行うために明らかにユニークなデータを使用します。たとえば、「アリス」と「ボブ」を追加しないでください。「Alice_21387」と「Bob_21387」を追加します。ここで、サフィックスはテスト実行ごとにランダムに生成されたインデックスです。それらのフィールドに数値を追加できませんか？ランダムな文字を追加します。「Alicezcfh」と「Bobzcfh」が競合するテストで使用される可能性はほとんどありません。
テストの失敗を許可します。ほとんどのテストフレームワークには、テストを待機して再試行する機能があります。これを使って。テストが最大N回失敗し、実行間にD秒の遅延が生じます。多くのWebアプリケーションでは、N = 3、D = 15でうまくいきます。テストランナーに組み込みオプションがない場合は、この種の再試行テストロジックを簡単に作成できます。
結果として期待するものに対してテストスクリプトをより堅牢にします。たとえば、挿入後、「Bob」のレコードがテーブルのどこかにある必要がある場合、行番号42に正確に出現することを期待するテストを記述しないでください。代わりに、テーブルのどこかに「ボブ」を期待するテストを記述してください。（ @ Doc Brown へのヒント）

要約すると、自動化されたアプローチをあきらめないでください。それを動作させる方法があります。特に、テスト中に変更されるシステムをテストしている場合は、不完全です。テストを進めるにつれ、テストの調整、強化、改善が必要になる場合があります。しかし、それは実用的で効果的です。それはあなたの唯一の真の希望でもあります。論理的な代替手段である手動テストの繰り返しは、使いやすさ、速度、および信頼性に似たものでは機能しません。