クラスやメンバ関数ごとに単体テストを行い、すべてのユーザストーリーの受入テストを行っても、プロジェクトが期待どおりに機能するように十分なテストがありますか？ユニットテストと受け入れテストは十分ですか？
たとえば、機能の単体テストと受け入れテストがある場合は、まだ統合テストが必要ですか？また、ユニットと受け入れテストが同じ基準を満たす必要がありますか？テストタイプ間に重複はありますか？
私はここで自動テストについて話しています。使いやすさなどの点で手作業によるテストがまだ必要であることは承知しています。
2nd edition of Code Completeで20〜22章を読むことをおすすめします。それはソフトウェア品質を非常にうまくカバーします。
がここで重要なポイントのいくつかの迅速な内訳（すべてのクレジットは、マコーネルに2004を行く）
Chapter 20です自身
Chapter 21 - 共同建設：
Chapter 22 - 開発者テスト：
単体テストの作成方法については、基本テスト、データフロー解析、境界解析などを考慮する必要があります。これらのすべてについては、本書でさらに詳細に説明します。
これはまさにあなたが求めていたものではないかもしれませんが、私は自動化されたテストでは必ずしも戦略が不十分だと言います。また、ペアプログラミング、正式レビュー（プロジェクトの規模に応じた非公式のレビュー）、テスト用の足場や自動テスト（単体テスト、回帰テストなど）なども考慮する必要があります。
複数のテストサイクルのアイデアは、状況が変化したときにできるだけ早く問題をキャッチすることです。
ユニットテストは開発者が単位で動作することを保証するために行う必要があります。
受け入れテストは、システムが要件を満たしていることを確認するためにクライアントが行う必要があります。
ただし、テストする必要がある2つの点の間で何かが変更されました。これは、ユニットを製品に統合してからクライアントに提供することです。
これは、クライアントではなく製品の作成者が最初にテストする必要があります。あなたがクライアントを招待した分、物事は遅くなるので、あなたはそれに厄介な小さな手を加える前にもっと多くの修正を加えることができます。
私たちのような大きな店では、出荷可能製品が変更される各段階で単体テスト、統合テスト、グローバリゼーションテスト、マスタービルドテストなどがあります。一度すべての重大度の高いバグが修正されると（優先度の低いバグを修正する計画が立てられている）、製品をベータ版のクライアントに提供します。
その段階でバグを修正するのは、私たちが社内で行うことよりもずっと高価です（特に管理者の面で）。
ユニットテストと受け入れテストがすべての拠点をカバーしていないと言っていますか？どちらも自力で捕まえることができないことがありますか？ –
はい、最低限、すべての単体テストを受け入れテストのためにクライアントに引き渡す前に、統合された製品で再実行する必要があります。統合プロセスから発生する可能性のあるバグがあり、ユーザ承認テストでは、開発者/テストチームが思い付くべき無数のものではなく、ユーザの要件をテストするだけです。 – paxdiablo
すべてのメソッドと機能のテストがあるかどうかだけで十分なテストがあるかどうかは分かりません。通常、テストをカバレッジ分析と組み合わせて、すべてのコードパスが単体テストで実行されるようにします。これでさえ十分ではありませんが、あなたのテストでは行使されないコードをどこに導入したかを指針にすることができます。これは、より多くのテストを書く必要があることを示しているはずです。また、TDDを実行している場合は、スピードを落としてより訓練を受ける必要があります。 :-)
テストは、特に単体テストで、良いパスと悪いパスの両方をカバーする必要があります。受け入れテストでは、悪いパスの動作に多かれ少なかれ関心があるかもしれませんが、少なくとも発生する可能性がある一般的なエラーに対処する必要があります。あなたのストーリーの完成度合いによっては、受け入れテストが適切でないかもしれません。受け入れテストとストーリーの間には、しばしば多対1の関係があります。すべてのストーリーに対して1つの自動受諾テストしかない場合は、代替パスについて異なるストーリーを持たない限り、おそらく十分ではありません。
インテグレーションテストは、サードパーティのアプリケーションなどの他のシステムや環境、データベースなどの社内システムと統合テストを行います。統合テストを使用して、コードの動作が予期したとおりになるようにします。
クラスやメンバ関数ごとに単体テストがあり、すべてのユーザーストーリーについて受け入れテストを行っても、プロジェクトの機能が期待どおりに機能することを確認するのに十分なテストがありますか？
いいえ。テストでは、あなたが考えたことを確認することしかできません。あなたが考えていないものではありません。
+1。素晴らしい1ライナー。 –
複数のテストレイヤーは非常に便利です。ピースが動作することを確認するユニットテスト。統合されたユニットのクラスタが期待通りに協調することを示す統合と、プログラムが期待どおりに機能することを示す「受け入れ」テスト。それぞれ開発中に問題を捉えることができます。オーバーラップそれ自体はですが、あまりにも多くのものが無駄になりますが、悪いことではありません。
しかし、悲しいことは、期待は紙の上に非常に不十分に翻訳されている気まずい人間のものなので、製品が「期待通りに」動作することを決して保証することができないということです。良いテストカバレッジは、顧客が「私が心に留めていたものではない」と言うことを妨げるものではありません。頻繁なフィードバックループが役立ちます。あなたの手動ミックスに追加するための「健全性テスト」としての頻繁なデモを考えてみましょう。
重複問題に言及してくれてありがとう。 – KobeJohn
まず、ストーリーカードには受け入れ基準があります。つまり、分析者と一緒に商品所有者が必要とする行動を指定する合格基準が満たされていれば、ストーリーカードが受け入れられます。
受け入れ基準は、自動化ユニットテスト（TDDを介して行われる）と、毎日実行される自動回帰/機能テストを推進する必要があります。私たちが欠陥を左に動かすことを覚えておいてください。すなわち、早く修理するほうが安くて早く見つかるでしょう。さらに、継続的なテストにより、私たちは自信を持ってリファクタリングすることができます。これは開発の持続可能なペースを維持するために必要です。
さらに、自動パフォーマンステストが必要です。プロファイラを毎日または一晩実行すると、CPUとメモリの消費量、およびメモリリークが存在するかどうかがわかります。さらに、ロードランナーのようなツールを使用すると、実際の使用状況を反映するシステムに負荷をかけることができます。 loadrunnerを実行しているマシンのような製品では、応答時間とCPUとメモリー消費量を測定できます。
自動化されたパフォーマンステストは、アプリケーションの実際の使用状況を反映する必要があります。ビジネストランザクションの数を測定します（Webアプリケーションがページをクリックし、ユーザーへの応答やサーバーへの往復）。そのようなトランザクションのミックスを、1秒あたりに届くレートと一緒に決定します。このような情報により、アプリケーションのパフォーマンステストに必要な自動ロードランナーテストを適切に設計することができます。多くの場合、パフォーマンスの問題のいくつかはアプリケーションの実装に戻っていますが、その他のものはサーバー環境の構成によって決定されます。
アプリケーションのパフォーマンスはテストされていることに注意してください。問題は、ソフトウェアをリリースする前または後に最初のパフォーマンステストが行われるかどうかです。私が信じているところでは、パフォーマンス上の問題を抱える悪いところは生産段階にあります。パフォーマンスの問題は修正するのが最も難しく、すべてのユーザーに展開を失敗させてプロジェクトをキャンセルさせる可能性があります。
最後に、ユーザー受け入れテスト（UAT）があります。これらは、リリース前にシステム全体をテストするために、製造オーナー/ビジネスパートナーによってテストされたテストです。一般に、他のすべてのテストのために、アプリケーションがUATの間にゼロの欠陥を返すことは珍しいことではありません。
システムの複雑さによって異なります。あなたの受け入れテスト（顧客の要求を満足させる）があなたのシステムを前から後に動かすならば、あなたはしません。
しかし、製品が（バックエンドミドルウェア/データベースのような）他の層に依存している場合は、製品が幸福にエンドツーエンドでリンクできることを証明するテストが必要です。
他の人がコメントしたように、テストではプロジェクトの機能が期待どおりに機能しているとは必ずしも言えません。
お客様へのフィードバックループや、顧客が理解できるように書かれた/解析可能なテスト（たとえば、BDD styleなど）が実際に役立つことがあります。
技術的には、受け入れテストの完全なスーツですべてをカバーする必要があります。それは言われている、彼らは十分なのほとんどの定義のための "十分"ではない。単体テストと統合テストを行うことで、バグや問題をより早期に、よりローカライズして把握することができ、分析や修正がさらに簡単になります。
手作業で実行されたテストと紙に書かれた指示のフルスーツが、すべてが期待通りに機能することを検証するのに十分であると考えてください。しかし、テストを自動化することができれば、テストをはるかに簡単に行うことができます。紙のバージョンは「完全」ですが、「十分」ではありません。同じように、テストの各レイヤーは「十分な」値に多くを追加します。
異なるテストセットは、異なる「視点」から製品/コードをテストする傾向があります。同様に、QAがテストすることを考えたことのないバグを拾い上げるのと同じように、あるセットのテストは、他のセットのテストでは見つけられないものを見つけるかもしれません。
私は各クラスのユニットテスト および/またはメンバ関数と受け入れ、すべてのユーザーストーリーのため のテストを持っている場合、私は期待通りにプロジェクト 機能を確保するために 十分なテストがありますか？
これはあなたのソフトウェアを表示するのに十分ですが、あなたのテストカバレッジが十分であり、少なくとも限り、機能的に正しいです。さて、あなたが開発しているものによっては、確かに重要ではない機能要件があり、信頼性、パフォーマンス、およびスケーラビリティについて考える必要があります。
あなたのソフトウェアが実際には本当に簡単で、コンポーネントが1つしかない場合を除き、おそらくそうではありません。
ユニットテストは非常に限定されており、すべてを完全にカバーする必要があります。ここでコードカバレッジを高めてください。しかし、それらは一度に1つの機能のみをカバーし、どのように機能するかは関係しません。受け入れテストは、顧客が本当に気にしていることだけを高レベルでカバーするものでなければなりません。また、物事がどのように連携するかについていくつかのバグをキャッチしますが、そのようなテストを書く人がシステムについて深く知らないので、
最も重要なことに、これらのテストは、テスターによって書き込まれないことがあります。ユニットテストは開発者によって書かれ、開発者（およびビルドシステムも理想的には）によって頻繁に（コーディングスタイルに応じて、数分ごとに）実行されるべきです。受け入れテストは、しばしば、顧客または顧客を代理する人によって書かれ、顧客にとって重要なことを考えます。しかし、テスターのように（デベロッパーや顧客のようには思えない）考えてテスターが書いたテストも必要です。
また、一般的にテスターによって書かれているテストの次の種類を、考慮する必要があります。機能の部分をカバーする
受け入れテストは、手元にあるシステムが小さい場合は、クライアントによって手動で行うこともできます。
持続可能なシステムを構築するための単位テストと小規模な統合テスト（単位テストからなる）があります。
システムの各部にテストを書き込まないでください。それは脆い（壊れやすい）と圧倒的です。
システムの重要な部分を決定するには、手作業でテストしてそのパーツだけのテストを作成してみましょう。
自動受け入れテストについて聞いたことがありません。それはどういう意味なの？私は受け入れが顧客によって承認される必要があると思った。 –
Fitnesseのようなプログラムを使用して、状態遷移テーブルに似たテーブルに高水準のテストを作成し、自動的に実行されます。私が話したほとんどの人は、これらを受け入れテストと呼んでいます。 –