一般的な開発シーンで,
今回はトラブルの原因をコードの中に追求します。
ソースコードの傾向に見る誤りの予測(初級編)
全網羅テストのムダ
テストをしらみつぶしですると,
ソフトウェア開発における障害は,
兆候を読み取る技術とは
テストケースは少ないに越したことはありません。従来どおりのテスト手法や製品領域があることも否定しませんが,
ソースコードの兆候を観察し誤りを予測する
まず,
- [方法1]
コードの外形 - (兆候が現れている対象を選ぶ)
- [方法2]
コードのデータ - (各種コードメトリクスからのアプローチ)
- [方法3]
内部の兆候検知 - (NGワード/
一発でおかしい記述の検出)
端的に言えば,
[方法1]コードの外形で兆候検知
ソースコードのファイル群から,
最終更新日付が怪しい
最後に更新された
ファイル名の長さが怪しい
クラス/
ハイフン付きは怪しい
JavaやC言語では
一番サイズが大きいものが怪しい
サイズが大きいコードは,
[方法2]データからの兆候検知(各種コードメトリクスからのアプローチ)
次に各種の定量数値
NGワードの含有率(トラブル誘発因子の検出)
NGワードとは,
コメント比率の確認(欠陥混入の間接メトリクス)
ソースコード全行数に対する
- コメント率が高いコードは,
頻繁に改変された可能性が高い (ブロックコメントアウトによる履歴保存=コメント率が高くなるため) - 頻繁に改変されたコードは,
テストが不足している可能性が高い (十分な回帰テスト工数を投資しているか疑問) - 頻繁に改変されたコードは,
誤修正欠陥の混入確率が高い (複数人数でテストするため) - 急場で作ったコードはコメント率が低い可能性がある
- 業務アプリケーションや制御のコードではない,
移行ユーティリティやテストコードは, コメント率が低い場合がある
これらの理由から,
IFとELSEの比率(設計欠陥の間接メトリクス)
いわゆる分岐の片抜け,
図3 IFとELSEペアの一般的傾向
①や②はIFが数十~100以上のコードには,
もちろんC言語におけるK&R表記を標準とする場合など,