私はホワイトボックステストの世界に比較的慣れていないので、現在取り組んでいるプロジェクトの1つについてテスト計画を立てるのに助けが必要です。現時点では、テスト可能なコードを探して、そのための単体テストを作成しています。私はどういうわけかそれが行われるべき方法ではないことを感じています。このプロジェクトをテストするための最善の準備についてアドバイスをいただけますか？使用できるツールやテストプランテンプレートはありますか？違いが出るのであれば、使用されている言語はC++です。
1876 次
3 に答える
3
ホワイトボックステストの目標の1つは、コードステートメントの100％（または可能な限り近い）をカバーすることです。テストが実行するコードと見逃したコードを確認できるように、C++コードカバレッジツールを見つけることをお勧めします。次に、できるだけ多くのコードがテストされるようにテストを設計します。
もう1つの提案は、ifステートメント、forループ、whileループなどの境界条件を調べて、「灰色」の領域、誤検知、および誤検知についてこれらをテストすることです。
重要な変数のライフサイクルを調べるテストを設計することもできます。それらの定義、使用法、および破壊をテストして、それらが正しく使用されていることを確認します:)
始めるための3つのアイデアがあります。幸運を
于 2010-05-24T08:22:04.103 に答える
2
「レガシーコードを効果的に使用する」を試してください：http：//www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052
「レガシー」とは、テストのないコードを意味するため、これは適切です。かなり良い本でもあります。
関連するツールは次のとおりです。http：//code.google.com/p/googletest/およびhttp://code.google.com/p/gmock/ 他の単体テストおよびモックフレームワークがあるかもしれませんが、私はこれらに精通しており、私はそれらを強くお勧めします。
于 2010-05-24T08:51:15.800 に答える
2
現時点では、テスト可能なコードを探して、そのための単体テストを作成しています。私はどういうわけかそれが行われるべき方法ではないことを感じています。
「テスト駆動開発」の主な利点の1つは、テスト容易性を念頭に置いてコンポーネントを設計することを奨励することです。つまり、コンポーネントをよりテストしやすくします。
私の個人的な（非TDD）アプローチは次のとおりです。
- 必要な機能と実装された機能を理解する：「アプリオリ」（つまり、ソフトウェアの機能仕様を読む/知ることによる）と、ソースコードを読んで機能をリバースエンジニアリングすることの両方。
- 実装された/必要なすべての機能に対してブラックボックステストを実装します（たとえば、「1つは内部実装をテストする必要がありますか、それともパブリックな動作のみをテストする必要がありますか？」を参照してください）。
したがって、テスト対象の機能をリバースエンジニアリングすることを除いて、私のテストは「ホワイトボックス」ではありません。次に、そのリバースエンジニアリングされた機能をテストし、役に立たない（したがってテストされていない）コードがないようにします。コードカバレッジツールを使用して、ブラックボックステストによって実行されるソースコードの量を確認することはできます（ただし、頻繁には使用しません）。
于 2010-05-24T08:20:03.010 に答える