ホワイトボックステストを適切に採用
2459 ワード
ホワイトボックステストを採用するかどうかは、ソフトウェアエンジニアリングの観点から、ホワイトボックステストはプログラムの内部論理構造を見ることができるため、ユニットテスト段階でテストを開始することができ、Bugを修復するコストの面で大きな優位を占めている.また、ある種類のBugについては、ブラックボックスでテストする場合、テストデータやテスト環境の準備に多くの時間や労力がかかりますが、ホワイトボックスでテストする方法は簡単です.ホワイトボックステストはユニットテストに限らず、コードチェック、コードの静的分析、動的分析はホワイトボックステストの範疇に属する.次は、コードを使用して調べたところ、ブラックボックステストではテストが難しい境界値の問題です.
【ケース】境界値テストの問題
背景説明:ある精密機器は環境温度を測定する機能を持ち、環境温度が5°Cから35°Cのときに正常に動作し、温度が30°Cを超えると、測定結果の正確性が影響を受け、機器は警報測定状態に入ることを要求する.
テスト分析:この機能ブラックボックステストエンジニアはテストを実行する時、1杯のお湯で温度センサを加熱し、その温度を境界値35°Cまで上昇させるが、精度の処理問題のため、センサが感知した温度はハードウェア指令を通じてソフトウェアに送信された後、一定の誤差が存在し、ソフトウェアが界面に表示した30°Cは、実際の30°Cを超えたか、実際には30°C未満である可能性がある.また,30.1°C,29.9°Cのような境界データは,この方法ではほとんどシミュレーションできない.この場合、ソフトウェア杭やハードウェア杭(命令シミュレーション)を行うなど、他の方法を考慮する必要があります.この2つの工事コストは小さくありません.最後に,コードチェックの手法を用いてコードをレビューすることにした.
テスト結果:結果はすぐに境界値定義範囲の境界で発見され、開発者は閉区間の表現を開区間の表現と書き、コードフラグメントの例は以下の通りである.
必要に応じて、第1行のコードの正確な表現はif((EnvrTemp>=5)&(EnvrTemp<=30))であるべきである.
小結:ブラックボックステストの検証が困難であるか、重要な論理判断処理に対して、コアモジュールの実現はホワイトボックステスト手段を採用することができる.方法は多く、pc-lintコードの静的解析ツールのような人工分析の代わりにツールを組み合わせることもできます.
プロジェクトテストでは、ホワイトボックステストを展開するかどうかを決定するには、明らかなメリットがあるため、上記の例は良い例です.しかし、どのように展開するかは、コードのカバー率がどれだけ高いかで、頭を叩くだけで撮れるものではありません.多くの要素の中で、人力の投入と産出は最も重要で最も考慮しなければならない問題であり、例えばプロジェクトのコード量がどれだけあるか、すべてユニットテストを行うにはどれだけの人力が必要ですか.ユニットテストは開発者が行う場合、進捗への影響は受け入れられますか?テスト担当者がやれば、コストが大きすぎるのではないでしょうか.現在のリソースの適任度はどうですか.コアモジュールまたはコアコードのみをホワイトボックステストする場合、品質的にプロジェクトのニーズを満たすことができますか?ホワイトボックステストの展開の「度」については、広さと深さを含め、戦略的な意思決定者が慎重に考慮しなければならないことでもあります.時には、仕事が半分になったり、仕事が半分になったりすることもあります.筆者が見た失敗例は、以下を参照してください.
【ケース】コードテストの失敗例
20.4万コードラインのソフトウェアで、2人のテストエンジニアを手配してコードテストを行い、開発者がコードを実現する中期に介入します.2人のテスト担当者は計13ヶ月を費やし、重要モジュールに対してユニットテスト、集積テスト及びコードチェックを行った.プロジェクト終了時には131個の欠陥が提出され,開発者によって取り消された問題は83個あり,本当に開発者によって解決されたことが確認されたのは48個のみであった.人力産出比が予想と大きく異なるため、プロジェクトへの実質的な貢献は明らかではなく、最後にこのコードテストグループをキャンセルするしかなかった.この結果を招いた原因は多く,その中で最も主要なのは,コードの注釈が低い(統計的には8.4%であり,業界公認コード注釈率がコード行全体の30%程度に達するのが理想的である),テスト担当者の介入が遅い,人員が少ない,自身の能力が限られているなど,テスト担当者のコードテストの条件が未熟であることである.
ブラックボックスのテスト技術に比べて、ホワイトボックスのテストは敷居が高く、うまくいかないと苦労して喜ばれません.しかし、白箱のテスト技術は、「良い鋼」であり、良い鋼が刃に使われるだけで、その価値を発揮することができる.
【ケース】境界値テストの問題
背景説明:ある精密機器は環境温度を測定する機能を持ち、環境温度が5°Cから35°Cのときに正常に動作し、温度が30°Cを超えると、測定結果の正確性が影響を受け、機器は警報測定状態に入ることを要求する.
テスト分析:この機能ブラックボックステストエンジニアはテストを実行する時、1杯のお湯で温度センサを加熱し、その温度を境界値35°Cまで上昇させるが、精度の処理問題のため、センサが感知した温度はハードウェア指令を通じてソフトウェアに送信された後、一定の誤差が存在し、ソフトウェアが界面に表示した30°Cは、実際の30°Cを超えたか、実際には30°C未満である可能性がある.また,30.1°C,29.9°Cのような境界データは,この方法ではほとんどシミュレーションできない.この場合、ソフトウェア杭やハードウェア杭(命令シミュレーション)を行うなど、他の方法を考慮する必要があります.この2つの工事コストは小さくありません.最後に,コードチェックの手法を用いてコードをレビューすることにした.
テスト結果:結果はすぐに境界値定義範囲の境界で発見され、開発者は閉区間の表現を開区間の表現と書き、コードフラグメントの例は以下の通りである.
if( ( EnvrTemp > 5 ) && (EnvrTemp < 30 ) )
{
//
}
Else
{
//
}必要に応じて、第1行のコードの正確な表現はif((EnvrTemp>=5)&(EnvrTemp<=30))であるべきである.
小結:ブラックボックステストの検証が困難であるか、重要な論理判断処理に対して、コアモジュールの実現はホワイトボックステスト手段を採用することができる.方法は多く、pc-lintコードの静的解析ツールのような人工分析の代わりにツールを組み合わせることもできます.
プロジェクトテストでは、ホワイトボックステストを展開するかどうかを決定するには、明らかなメリットがあるため、上記の例は良い例です.しかし、どのように展開するかは、コードのカバー率がどれだけ高いかで、頭を叩くだけで撮れるものではありません.多くの要素の中で、人力の投入と産出は最も重要で最も考慮しなければならない問題であり、例えばプロジェクトのコード量がどれだけあるか、すべてユニットテストを行うにはどれだけの人力が必要ですか.ユニットテストは開発者が行う場合、進捗への影響は受け入れられますか?テスト担当者がやれば、コストが大きすぎるのではないでしょうか.現在のリソースの適任度はどうですか.コアモジュールまたはコアコードのみをホワイトボックステストする場合、品質的にプロジェクトのニーズを満たすことができますか?ホワイトボックステストの展開の「度」については、広さと深さを含め、戦略的な意思決定者が慎重に考慮しなければならないことでもあります.時には、仕事が半分になったり、仕事が半分になったりすることもあります.筆者が見た失敗例は、以下を参照してください.
【ケース】コードテストの失敗例
20.4万コードラインのソフトウェアで、2人のテストエンジニアを手配してコードテストを行い、開発者がコードを実現する中期に介入します.2人のテスト担当者は計13ヶ月を費やし、重要モジュールに対してユニットテスト、集積テスト及びコードチェックを行った.プロジェクト終了時には131個の欠陥が提出され,開発者によって取り消された問題は83個あり,本当に開発者によって解決されたことが確認されたのは48個のみであった.人力産出比が予想と大きく異なるため、プロジェクトへの実質的な貢献は明らかではなく、最後にこのコードテストグループをキャンセルするしかなかった.この結果を招いた原因は多く,その中で最も主要なのは,コードの注釈が低い(統計的には8.4%であり,業界公認コード注釈率がコード行全体の30%程度に達するのが理想的である),テスト担当者の介入が遅い,人員が少ない,自身の能力が限られているなど,テスト担当者のコードテストの条件が未熟であることである.
ブラックボックスのテスト技術に比べて、ホワイトボックスのテストは敷居が高く、うまくいかないと苦労して喜ばれません.しかし、白箱のテスト技術は、「良い鋼」であり、良い鋼が刃に使われるだけで、その価値を発揮することができる.