受け入れテストを理解しようとしていますが、それがどこから始まるのか、またはどのような種類のテストが関係しているのか混乱しています。自動化 GUI テスト フレームワークを使用する必要がありますか、それとも単体テストを使用する必要がありますか? 受け入れテストの境界とは?
編集: 私の質問は、自動受け入れテストに関するものです。
質問する
1334 次
3 に答える
2
受け入れテストは、アプリケーション/ソフトウェア全体が開発および統合された後に行われます。受け入れテストは、主にアプリケーションがユーザーの要件を満たしているかどうかをテストするために行われます。
受入試験には主に2種類あります。
- アルファテスト
- ベータテスト
受け入れテストは、主にクライアント (ソフトウェアの開発を依頼した人) とエンド ユーザーによって行われます。
アルファ テストはクライアントによって行われます。彼は開発者に助けられています。ここで、クライアントはソフトウェアを見て、すべての要件が満たされていることを確認します。
ベータ テストは、アルファ テストが完了した後に行われます。ここで、アプリケーションは、エンド ユーザーとして行動し、アプリケーションを使用する一連の人々にリリースされます。
于 2012-11-22T16:20:40.343 に答える
1
単体テストを受け入れテストと混同しないでください。
受け入れテストは基本的に要件であり、次のようにテストとして記述されます。
- 要件がいつ満たされるかは明らかです。
- 実際のテストは、計画と実行がより簡単です。
単体テストは、小さなコードの自動テストであり、定期的な（そして非常に嫌われている）手動チェックを必要とせずに、すべての小さな部分を監視するために使用されます。
于 2012-10-10T19:03:18.953 に答える
0
UIの道をたどることができます。Selenium または WatiR は、UI ベースのテスト スイートの実行に使用できる堅実なツールです。あなたが Dot.Net 開発者であれば、WatiN を使用できますが、2011 年 4 月以降新しいバージョンがなかったため、WatiN の問題はほとんどなくなっているように見えることです。
しばらく前に、SpecFlow (詳細は後述) と watiN を統合して、適切なテスト スイートを動作させることができましたが、問題なく動作しました。
しかし、時間が経つにつれて、UI ベースのテストを行っていたときに、ページをロードして何かをクリックし、DB で結果を確認するだけであることに気付きました。時々、画面にも予想されるメッセージが表示されていることも確認しましたが、それだけです。この結論が、私を UI ベースのテストから遠ざけました。
私が始めたことは、UI がルールとイディオムに基づいて構築されていることを確認することです。現在のツール (asp.net mvc、かみそりテンプレート、またはさらに優れた - knockout.js ) を使用すると、あまり苦労することなくこれを行うことができます。UI が体系的に構築され、誰もが好きなフィールドをページに投げるわけではない場合、ほとんどの場合、テストする必要があるのはそれを構築するメソッドだけであり、結果ではありません。もちろん、私がそれをテストしたい場合（そしていくつかのシナリオではそうするでしょう）、QUnitのようなツールでテストする方がはるかに簡単（かつ高速）です。
したがって、現在の ATDD の実践方法は次のとおりです。
- ビジネス要件をテスト コードに取り込むには、 specflowを使用します。
- 「分離コード」のみをテストします。
- UI の配管にノックアウト JS を使用する (多くのカスタム バインディングを使用)
- ビューに返されるモデルの標準を作成します。
- UI 動作テストを単体テストとして扱います。
Specflow の良い出発点は次のとおりです: http://www.infoq.com/articles/Spec-Flow
于 2012-10-10T21:03:31.157 に答える