リリースごとに、お客様はソフトウェアにいくつかの古い問題を見つけているようです。実際には新しいコードは一般的に堅実ですが、すべてのリリースに複数のバグがあるように見えます。
小さな問題に先んじるために、テスターに毎月1つのアプリで数時間の月次回帰テストを実行させる追加のテストを実装しようとしました。このプロセスをソフトウェア強化プロセスと呼びますが、バグを十分に把握しているようには見えず、作成する新しいコードが常にあるため、非常に後回しのプロセスのように感じます。
この種のテストのコツはありますか？一度に1つの特定の機能をターゲットにする必要がありますか？
テスト手順を開発するときは、次の種類のテストを実装することをお勧めします。
単体テスト（プロジェクトの個々のコンポーネントをテストして機能をテストする）。これらのテストでは、ソフトウェアのどこでエラーが発生したかを特定できるため、これらのテストは重要です。基本的に、これらのテストでは、単一の機能をテストし、モックオブジェクトを使用して動作をシミュレートし、他のオブジェクト/エンティティの値を返します。
あなたが言及した回帰テスト
特性テストでは、1つの例として、自動生成された入力（ユーザー入力をシミュレート）でプログラムを自動的に実行し、結果を保存して、すべてのバージョンの結果をこれらの結果と比較します。
最初はこれを導入するのは非常に大変ですが、自動化された非回帰テストに追加されるリリースとバグ修正が増えると、時間を節約できるようになります。
膨大な数のダムテストを設計するという罠に陥らないことが非常に重要です。テストはあなたの人生を楽にするはずです。テストがどこで壊れたかを理解するのに時間がかかりすぎる場合は、問題をすばやく見つけることができるように、より良いメッセージ/問題の理解が得られるようにテストを再設計する必要があります。
環境によっては、これらのテストを開発プロセスにリンクすることができます。
私の環境では、バージョン管理にSVNを使用しています。ボットはすべてのリビジョンに対してテストを実行し、失敗したテストと、それを破ったリビジョンの名前と寄稿者（彼のログイン）を含むメッセージを返します。
編集：
私の環境では、C ++とC＃の組み合わせを使用して、Financeで使用される分析を提供します。コードは、C ++であり、インターフェイスをC＃に移行し、分析のコアをC ++で維持しようとしている間、かなり古いものです（主に速度要件）
ほとんどのC++テストは、手書きの単体テストと回帰テストです。
C＃側では、ユニットテストにNUnitを使用しています。一般的なテストがいくつかあります。
警告ポリシーは0です。コードのこの部分の警告をバイパスすることが有用である理由を正当化できない限り、警告を生成するコードをコミットすることを明示的に禁止します。例外安全性、デザインパターンの使用、およびその他の多くの側面に関する規則もあります。
明示的に規則とベストプラクティスを設定することは、コードの品質を向上させるもう1つの方法です。
この種のテストにトリックはありますか?
あなたは、「小さな問題を先取りするために、テスターに毎月 1 つのアプリで毎月数時間の回帰テストを行ってもらっています」と述べました。
「回帰テスト」とは、「古い機能を手動で実行する」ことを意味していると思います。
これまでに発見されたことのない古いバグを探しているかどうかを判断する必要があります (これは、これまでに実行したことのないテストを実行することを意味します)。または、以前に実行したテストを繰り返して、以前にテストした機能が変更されていないことを確認するかどうか。これらは2つの相反するものです。
「回帰テスト」は、後者を行っていることを意味します。
問題が「顧客が私たちのソフトウェアのいくつかの古い問題を見つけた」ということである場合、あなたの顧客は、あなたが以前に実行したことのないテストを実行しているかのどちらかです (この場合、これらの問題を見つけるには、古いソフトウェアの新しいテストを実行する必要があります)。または、以前にテストして見つけたバグを見つけているが、それらを見つけた後に修正していないように見える.
一度に 1 つの特定の機能をターゲットにする必要がありますか?
正確に何をしようとしていますか：
非常に一般的なアドバイスは、バグは家族に住んでいるということです。そのため、バグを見つけたら、その親、兄弟、いとこを探します。次に例を示します。
他のアドバイスとしては、それは顧客の期待を管理することであるということです。あなたは、「実際には、新しいコードは概してしっかりしているのに、すべてのリリースに複数のバグがあるように見えます」と言いましたが、本当の問題は、バグがあるという誤った認識であるかのように書き下ろし。
常に新しいコードを書く必要があるため、非常に面倒なプロセスのように感じます
ソフトウェアの開発は、バックグラウンドでバーナー上で行われるのではなく、誰かが作業しているか、していないかのどちらかです。経営陣は、誰かをこのタスクに割り当てるか (つまり、以前に発見されていない既存のバグを探すか、以前に発見されたがまだ報告されていないバグを修正するか)、または新しい開発に専念して、顧客がバグ検出を行います。
編集:バグを見つける方法はテストだけではないことに注意してください。次のものもあります。
それぞれの横に付けたパーセンテージは、各手法の欠陥除去率の尺度です (McConnel のSoftware Estimation book の 243 ページから取得)。最も効果的な 2 つの手法は、正式なコード インスペクションと大量のベータ テストのようです。
そのため、正式なコード レビューを導入することをお勧めします。これは、ブラック ボックス テストよりも欠陥を検出するのに適している可能性があります。
ここでは単体テストについて多くのことが語られていますが、これ以上同意することはできません。Josh が単体テストが機械化されたプロセスであることを理解してくれることを願っています。単体テストはアプリのコーディング後ではなくコーディング前に作成する必要があるという点で、私は PJ に同意しません。これは TDD またはテスト駆動開発と呼ばれます。
一部の人々は、中間層のコードを実行する単体テストを作成しますが、GUI コードのテストは無視します。それは不謹慎です。アプリケーションのすべての層の単体テストを作成する必要があります。
単体テストもコードであるため、テスト スイートの QA の問題があります。コードカバレッジは良好ですか？単体テストに偽陽性/偽陰性のエラーはありますか? 正しいことをテストしていますか？品質保証プロセスの品質をどのように保証しますか? 基本的に、その答えは査読と文化的価値に帰着します。チームの全員が、適切なテストの衛生管理に専念する必要があります。
バグがシステムに導入されるのが早ければ早いほど、バグがシステムにとどまる時間が長くなり、それを取り除くのが難しくなり、費用もかかります。そのため、継続的インテグレーションと呼ばれるものを検討する必要があります。正しく設定されている場合、継続的インテグレーションは、その日の変更をチェックインした直後に、プロジェクトがコンパイルされ、単体テストの完全なスイートで実行されることを意味します。
ビルドまたは単体テストが失敗した場合、問題のあるコーダーとビルド マスターは通知を受け取ります。彼らはチームリーダーと協力して、最も適切なコース修正がどうあるべきかを決定します。問題を修正して修正をチェックインするだけの簡単な場合もあります。追加の介入が必要な包括的なパターンを特定するには、ビルド マスターとチーム リーダーが関与する必要があります。たとえば、家族の危機により、開発者のコーディングの品質が底をつく可能性があります。CI と管理者による監視がなければ、何が起こっているのかを認識して是正措置を取るまでに、バグに 6 か月かかる可能性があります。
開発環境については言及していません。あなたが J2EE ショップである場合は、以下を検討することをお勧めします。
コーディングが終了したら、まず単体テストを行う必要があります。ここで、修正すべきいくつかのバグが発生するので、別のユニット テストを実行して、新しいバグが発生したかどうかを確認する必要があります。単体テストが終了したら、機能テストに進む必要があります。
あなたはここで、あなたのテスターが毎月回帰テストを行っていると言いましたが、まだ古いバグが出てきています。したがって、テスト ケースは定期的に更新する必要があると感じているため、テスターと一緒に座ってテスト ケースを確認することをお勧めします。また、レビュー中に、どのモジュールまたは機能にバグが発生するかを強調します。それらの領域に重点を置き、それらの領域にさらにテスト ケースを追加し、それらを回帰テスト ケースに追加して、新しいビルドが来たらそれらのテスト ケースを実行するようにします。
プロジェクトが長期的なものである場合は、もう 1 つ試すことができます。テスターと話し合って、回帰テスト ケースを自動化する必要があります。夜などのオフタイムにテスト ケースを実行すると、翌日には結果が得られます。また、回帰テスト ケースが定期的に更新されず、古い回帰テスト ケースと新しい進行テスト ケースを実行すると、テストされていないいくつかのモジュールが欠落している場合に大きな問題が発生するため、回帰テスト ケースを更新する必要があります。
（すべての）既存のものに戻ってテスト戦略を実装するのは面倒です。長くて難しくて、誰もやりたがらないでしょう。ただし、新しいバグが発生した場合は、そのバグに関するテストを開発することを強くお勧めします。バグ レポートが得られない場合は、(a) 動作するか、(b) 動作しないことをユーザーが気にしないかのいずれかです。いずれにせよ、テストは時間の無駄です。
識別されたらすぐに、 redになるテストを書きます。たった今。次に、バグを修正します。修正されたことを確認します。テストが緑色になったことを確認します。新しいバグが発生するたびに繰り返します。
申し訳ありませんが、テストが不十分であるか、遅すぎるか、またはその両方である可能性があります。