テストでうまく機能しないソフトウェアを包括的にテストする方法は？
私は現在、ソフトウェアパッケージの自動テストを実装することを目的としたプロジェクトで働いています。このソフトウェアは、すべてのデータを含むワークスペースと、このワークスペースデータで機能するコードを実行するユーザーインターフェイスを備えているという点で、Excelに少し似ていると想像できます。ユーザーインターフェース自体ではなく、主に「コア機能」のテストに焦点を当てています。以前は、多くのテストが手動で行われ、十分に文書化されていませんでした。
私たちが直面している問題の1つは、本質的にテストしたいものには「完全な」データセットが必要なことです。継承されたアーキテクチャの複雑さのために、何かを単体テストすることは実際には実行可能ではありません-必要なモックは非常に広範囲です。
私たちが直面している別の問題は、コードがいくつかの異なる言語であるということです-ほとんどPythonおよびC++。いくつかのPythonコードはa = Pythonソフトウェアで実行されているインタプリタ。これにより、他の方法ではアクセスしにくいC++コードにアクセスできます。
また、現在の手動テストのレベルは「十分に良い」と見なされており、少なくとも「同じ範囲」を得ることを目指しています。ただし、手動テストは必然的にUIを通過するため、現在の手動ケースは非常に不十分に文書化されているため、手動テストで現在カバーしている内容を知っているのは誰ですか？
良好なカバレッジを実現する方法（またはカバレッジをインテリジェントに測定する方法さえ）を理解するのに苦労しています。
これまでに出くわした標準的な回答の多くは、ここでは当てはまりません。たとえば、「テスト可能なコードを書く」は、コードを書き始めるときに優れたヒントですが、25年以上蓄積された数百万行のコードをリファクタリングすることは、このプロジェクトの範囲ではなく、小規模なチームにとって管理可能なタスクではなく、政治的に不可能です。状況。
優れたテストカバレッジを達成する方法、カバレッジを測定する方法、および一般に、十分に文書化されていない手動テストから、ある種の賢明で包括的な自動テストへの移行に取り組む方法に関するあらゆる提案を探しています。
私は専門家ではないので、特に関連する検索語句がわからない場合は、見落としがちなぶら下がっている果物があるかもしれません-その場合は、正しい方向に向けた穏やかな製品で十分です。よいスタート。
簡単な解決策はありません。 「テスト可能なコードを書く」ことが本当にそれを行う唯一の方法です。
テスト可能なコードを書くことは簡単ではなく、レトロフィットテストは困難です。現代のコーディングにおける進歩の多くは、コードをテスト可能にすることを目的としており、その他の利点として副次的な効果があります。テストを書くのは簡単です！
MrSmithのコメントは良い戦略です。
コードのピースが拡張/リファクタリング/追加/修正された場合、この部分のテストを追加します。時間の経過とともに、このようにしてテストカバレッジを段階的に改善していきます。
これにはいくつかの利点があります。
- 関数型コードを書き直す価値があるかどうかについて、疑い深い人と議論する必要はありません。
- 最も重要な領域でのテストを対象としています。
- あなたはすでにこれらの領域のテストに時間を費やすつもりでした。
- それ以外の点では変更されていない領域がリファクタリングによって破壊されるリスクはありません。
あなた一人じゃありません
冗長な言及ですが、この種のトラブルを抱えていないときにこの質問を読む人は、実際のソフトウェア開発は、多くの時間のプレッシャーの下で実行される複数年の標準以下の開発のケースでいっぱいであることを覚えておくべきであり、その結果、コードベースが乱雑になりますそれにもかかわらず、表面的には、実際に要求されているすべてを提供します。テストなしで25年を超える累積コードを人生に渡した場合、逃げることは必ずしも選択肢ではありません。
現在手元にあるのは手動テストだけです。あなたはそれらがカバーするものを「魔法のように」見つけることはできませんが、あなたはmust費やされた時間から自分を解放しますmanuallyテスト、これはおそらく文書化（または改善、または執筆）に費やされたものです- 実際テスト）。
テストに使用できる唯一の「フレームワーク」が実際のユーザーインターフェイスである場合は、 GUIテスト を検討することをお勧めします。これは、実際には、ソフトウェアを使用しているときに行うことの「シミュレーション」に基づいています。そのため、手動テスターが行う順序で、さまざまなUI要素のあちこちでクリックを生成できます。データセットの自動読み込みやオプションの設定などの問題を克服する必要があるかもしれませんが、コードベースによっては、最終的にこれを達成できる場合があります。
これは現在のGUIフレームワークに大きく依存しているため、簡単または難しいかもしれませんが、現在のテスト方法を自動化する最初の試みは、時間を節約し、新しい自動化された「手動」テストを書くことさえできると思います。 GUIテストツールの一覧については、 ここ を参照してください。
それとは別に、 Robin Bennettの回答 は非常に優れた、時代を超えたアドバイスです。
編集：
「暗闇の中でのショット」かもしれませんが、物事が非常に難しい場合、私は何か助けになるかもしれないものに出くわしたと思います。 私が言ったように 、テストされているものに関して助けることができる唯一の事柄の1つは、継続的なコールスタックトレースです... Valgrind's ツール名前付き callgrind 、a callgraphアナライザー（ Wikipediaによる ）は、そのために役立つ場合があります。ツール 自分自身を説明する ：
Callgrindは、プログラムの実行中の関数間の呼び出し履歴をコールグラフとして記録するプロファイリングツールです。デフォルトでは、収集されたデータは、実行された命令の数、ソース行との関係、関数間の呼び出し元/呼び出し先の関係、およびそのような呼び出しの数で構成されます。オプションで、キャッシュシミュレーションや分岐予測（Cachegrindと同様）は、アプリケーションの実行時の動作に関する詳細情報を生成できます。
有望に聞こえますが、他に優れた代替策がない場合は、これ（または他の同様のツール）を試してみることをお勧めします。各UIベースのテスト中にキャプチャされた詳細なコールグラフ「トレース」は、実際に舞台裏で何が起こっているかを正確に発見することを可能にします。
（特別な参照は この答え に行きます、それは私をその方向に向けました）。
Vector ZitaはGUIテストから正しい方向へと出発します。この回答を追加して、コードカバレッジの問題に対処します。
Vector Zitaの言ったことを実行します。 GUIテストが必要です。このアプリケーションを実行するプラットフォームに応じて、ユーザーインターフェイスを自動化できるツールを見つけることができます。ユーザーインターフェイスをテストしたくない場合でも、ユーザーインターフェイスを使用してコア機能をテストできます。あなたはそれをはるかに高いレベルで行うだけです。 「ユーザーインターフェース」と「コア機能」の観点からテストを考えないでください。ユーザー受け入れテスト、ネガティブテスト、境界テスト、ブラックボックステスト（ここでは、Googleの話題の言葉の数々）の観点から考えてみてください。
ユーザー受け入れテストは、アプリケーションの主な使用例をカバーしており、既存のドキュメントから収集できます。アプリケーションを通して「ハッピーパス」を考えてください。これらは、開始するのに最適なテストです。これらは数が少なく、短い実行時間でコードベースのより広い範囲をテストできます。これは一種の「スモークテスト」です。
ネガティブテストは、アプリケーションの「不幸なパス」をカバーします。誕生日。"これは、既存の要件ドキュメントからも作成できます。
境界テストは、価格が0〜50でなければならないなど、値の範囲内の正しい値と正しくない値を懸念しています。アプリケーションが-1、0、25（適切な中間値）、50、51でどのように動作するかを予測するために、それぞれ1つの自動テストを記述します。ここでも、要件を調べて、どの境界にテストが必要かを確認します。
ブラックボックステスト要件のドキュメントが欠落しているか存在しないギャップを埋めます。これらのテストでは、アプリケーションの動作を確認するために考えられる形式と数量でユーザーインターフェイスにデータをスローします。物事がどのように機能するかについての適切なドキュメントが不足している場合は、ブラックボックステストに合格して、少なくとも現在の機能を知るようにしてください。
これらすべてを、ユーザーインターフェイスにアクセスする自動テストとして記述します。大変な作業になります。テストの実行速度は単体テストよりも遅くなりますが、少なくともテストを実行することになります。
これらすべてのUI自動テストを記述したら、適切な単体テストを有効にするためにコードのリファクタリングを開始できます。この16歳のコードをリファクタリングして、ここで単一責任主体、ここでの懸念の分離、およびここに依存性注入を振り分けます。ユニットテストでその新しいコードを適切にカバーします。既存の自動テストを実行して、何も壊れていないことを確認します（ Red-Green-Refactor を参照）。
その20年前のコードを削り取り、新しい光沢のあるコードに置き換えるまで、すすぎ、繰り返します。うまくいけば、これにより、将来誰かがあなたの光沢のある新しいコードをより速く、より新しくより輝かしいコードに置き換えることができます。
これは、最初に最も正確なコードカバレッジメトリックを取得しません。テストコードとして再利用されるアプリケーションコードの量に応じて、コードカバレッジツールがUIテストの実行時に0％のカバレッジを報告するか、非常に小さな中間で99％のコードカバレッジを報告することがわかりました。ユニットテストをサポートするのに十分なコードベースをリファクタリングした後にのみ、コードカバレッジツールはより正確な数値を提供します。
ただし、最初に、テストでカバーされているコード行とカバーされていないコード行を把握する必要はありません。予想される入力と出力のケースをできるだけ多くカバーし、時間の経過に応じて、または古い機能を変更したりバグを修正したりする必要があるときに、コードベースを段階的にリファクタリングします。