Code Complete
(Ch22 Developer Testing)
2010/12/17
shiumachi
http://d.hatena.ne.jp/shiumachi/
http://twitter.com/shiumachi
http://www.facebook.com/sho.shimauchi

Agenda
● 22章 開発者テスト
●
22.1 ソフトウェア品質における開発者テストの役割
●
22.2 開発者テストの推奨アプローチ
●
22.3 テストに関するあれこれ
●
22.4 典型的エラー
●
22.5 テスト支援ツール
●
22.6 テストを改善する
●
22.7 テスト記録を保存する

はじめに
● この資料は、某所で開催されている「Code
Complete 読書会」での発表資料です
● 原著、つまり英語版の Code Complete をベー
スにしているので日本語版と訳語が違う場合が
あります
●
誤読とかも普通にありますので気づいたら指摘して
いただけるとうれしいです

Chapter 22 Developer Testing
22
章 開発者テスト

関連トピック
Ch. 3 コンストラクション実行の
ための前提条件
Ch. 23 デバッグ
Ch. 20 ソフトウェア品質の
展望
Ch. 22 開発者テスト
Ch. 21 協調コンストラクションの
Ch. 29 インテグレーション

実践

テストの種類(1)
● ユニットテスト
●
一人のプログラマが書く程度のクラス、ルーチン、小さな
プログラムのテスト
● コンポーネントテスト
●
複数のプログラマが書く程度のクラス、パッケージ、小さ
なプログラムのテスト
● 統合テスト
●
2つ以上のクラス、パッケージ、コンポーネント、サブシス
テムなどを組み合わせたテスト
●
通常はテスト対象のクラスが2つできたらすぐに開始する

テストの種類(2)
● リグレッションテスト
●
以前実行して通ったテストをもう一度実行する
● システムテスト
●
最終調整のためのテスト
●
他のソフト・ハードとの統合テスト、セキュリティ、性
能、リソース枯渇、タイミング問題などの低レベルの統合
ではテストできなかった問題をテストする
● その他のテスト(この章の範囲外)
●
βテスト、顧客受け入れテスト、性能テスト、設定テスト、
プラットフォームテスト、ストレステスト、ユーザビリ
ティテストなど

テスト
開発者が実行するテスト
開発者以外が実行するテスト
βテスト
この章のスコープ
はこちら
顧客受け入れテスト
ユニットテスト
性能テスト
コンポーネントテスト
設定テスト
結合テスト
プラットフォームテスト
リグレッションテスト
ストレステスト
システムテスト
ユーザビリティテスト

ブラックボックステストと
ホワイトボックステスト
● ブラックボックステスト
●
テスターは内部構造を見れない
●
この章の範囲外
● ホワイトボックステスト
●
テスターは内部構造を理解している
●
この章の範囲はこちら

テストとデバッグ
● テスト
●
エラーを検知するためのもの
●
この章の範囲はこちら
● デバッグ
●
既に検知されているエラーを分析・修正するための
もの
●
23章で扱う

22.1 ソフトウェア品質における開発者テストの役割

テストだけじゃ効果が薄い
● ソフトウェア品質においてテストは重要である
● 残念ながら多くの場合、テストだけがソフト
ウェア品質プログラムに使われる
● テストよりも協調開発の方が半分以下のコスト
でより多くのエラーを検出可能

一つのテストだけじゃ効果が薄い
● 単一のテストだけでは50%以下のエラーしか検
知できない
●
どのテストでも同じ
● 組み合わせて使用してようやく60%以下になる

テストを開発者が嫌がる理由
● テストだけが、開発を終わらせることを目的と
していない
● テストはエラーがないことを保証してくれない
● テストそれ自体はソフトウェア品質を向上しな
い
● テストは開発者に「自分のコードからエラーを
見つけようとすること」を要求する
●
でも多くの開発者はエラーなんて見つけたくない

プロジェクトに占める開発者テストの割合
2,000行程度だと25%、500,000行だと8%ほど

開発者テストの結果の使い道
● 開発中における製品の信頼性のアセスメント
● ソフトウェア修正のためのガイド
● エラーの統計情報を活用
●
適切な研修の実施
●
次回のテクニカルレビューにおける指針
●
次回のテストケースの作成

22.2 開発者テストの推奨アプローチ

システマティックにテストしよう(1)
● 要件1つ1つに対し、その要件が実装されている
ことを確認できるテストをすること
●
セキュリティ、ストレージ、インストールプロセ
ス、システム可用性などに注意
– 要件定義時には見過ごされている
● 設計1つ1つに対し、その設計が実装されている
ことを確認できるテストをすること
●
テストケースはできる限り早く、遅くとも設計
フェーズで計画すること

システマティックにテストしよう(2)
● 「基礎テスト」を詳細テストケースに加える
●
データフローテスト
●
コードカバレッジ100%にするためのテスト
● 開発組織内で作り上げられてきたエラーチェッ
クリストを活用する
● テストケースを設計する→要件バグ・仕様バグ
が減 →
る エラー修正コストが減る

テストファーストしよう
理由：安上がりだから
バグを仕込んでから修正までの時間が短いほどコストは下がる

テストファーストする理由
●
テストラストより苦労して書くことはない
●
不具合を仕込んでも発見が早くなる
●
コードを書く前に要件や設計について考えるようにな
る
●
要件バグを早く見つけやすくなる
●
下手な要件はテストを書きにくい
●
テストケースを書いておけばテストラストも以前と同
様にできる
テストファーストはとっても有用

でも銀の弾丸

じゃないので過信は禁物！

開発者テストの限界
● クリーンテスト(正常系テスト)になりやすい
●
未成熟な組織は正常系:異常系のテスト比率が5:1
●
成熟した組織だと1:5 (25倍！)
– 正常系を減らしているのではなく、異常系の数が25倍
● カバレッジに対して楽観的になりやすい
●
ちゃんとカバレッジチェックツール使おう

22.3 テストに関するあれこれ

そんなにテストできねえよ！
● 名前・住所・電話番号の全パターンのテスト
●
26^20 * 26^20 * 10^10。約 10^66
●
英数字だけでこれなので、日本語だとさらに多い
●
ノアが方舟から下りてきてから秒間1兆回テストし
ても、まだ1%も終わってないぐらいの量
● 当然こんなの無理なので、効率よくテストケー
スを選ぶ必要がある

構造化基礎テスト
●
全てのコードを少なくとも1回通るような最小の数の
テスト
●
コードカバレッジテストは最小でなくてもいい
●
作り方は簡単
1.コードを真っ直ぐ通るパスとして1を足す
2. ifなどの条件文、forやwhileなどのループ文、and や or
それぞれに対し1を足す
3. case文ごとに1を足す。defaultがない場合はさらに1を
足す
4.出てきた数字が、最小のテストケース

構造化基礎テストの実例
1つ目:条件式を通らずに
Statement1;
下まで実行
Statement2;
if ( x < 10 ) {
2つ目:if 文の中を
Statement3;
通過するように実行
}
Statement4;
● 必要なテストケースは少なくとも2つ
●
x < 10 のケース
●
x >= 10 のケース

もっと複雑な例

もっと複雑な例
&& があるので2つカウント

データフローテスト
●
データの使い方もバグが入りやすいポイントなので注意
●
データの状態は以下の5つ
●
Defined
–
初期化されたが未使用の状態
●
Used
–
使用された状態
●
Kil ed
–
free された状態
●
Entered
–
あるルーチンに入った直後の状態
●
Exited
–
あるルーチンから出るときの状態( return で値を返すとか)

データの状態の組み合わせ
● 普通のデータフローは Defined-Used-Killed
● 以下のようなケースは怪しい
Defined
Defined
Used
Used
Kil ed
Kil ed
Entered
Entered
Exited
Exited

データフローテストの作り方
全ての Defined-Used の組み合わせをテストする
if ( Condition1 ) {
基礎

テストで (false, false) のケースと
(true, true) のケースを作成
x = a;
} else {
(true, false) の条件で
x = b;
このデータフローをテスト
}
if ( Condition2 ) {
(false, true) の条件で
このデータフローをテスト
y = x + 1;
} else {
y = x – 1;
}

もっと複雑な例でデータフローテスト
Defined-Used 1つ目
Defined-Used 2つ目
Defined-Used 3つ目

同値分割
● あるデータにおいて、そのデータのとりうる全
ての範囲を、同じエラーを生成するだろう部分
集合に分割する
● 基礎テストとデータフローをきちんとやってい
れば、相対的には重要ではない
● しかし以下のようなケースでは特に有効
●
ソースを読む時間がなく、仕様からテストするとき
●
データが複雑で、しかもその複雑さがプログラムロ
ジックに反映しきれてないとき

同値分割の例
同値分割のターゲット
●
m_employee[id]governmentRetirementWithheld
●
< MAX_GOVT_RETIREMENT
●
>= MAX_GOVT_RETIREMENT
●
普通は基礎テストの時点で完了してるのでテストケースは
増えない

エラーの推測
見える、
私にもバグが見えるぞ！
● ニュータイプベテランは直感でバグがわかる
● コードインスペクションの過程で作成した「頻
出エラーリスト」を元にテストケースを作ろう
●
ベテランの直感をテストに生かす方法になる

境界値分析
● 世界共通の頻出エラーといえば off-by-one
●
>
と >= を間違えたりとか
● 境界値、境界値+1、境界値-1を全部テストする
● とりうる値の最大・最小値も境界値とみなす
● 値の組み合わせも考慮する
●
a * b の式があるとき、abともに巨大な正数にする
●
あるいは巨大な負数にしたり、と

もに 0 にする
●
入力文字列を全て巨大にする

バッドデータのクラス
● 以下のバッドデータのうち、今までのテスト
ケースでカバーしていないものはテストする
●
非常に小さいデータ(あるいはデータなし)
●
非常に大きいデータ
●
無効なデータ(型が違うとか)
●
間違ったサイズのデータ
●
初期化されていないデータ

グッドデータのクラス
● 正常系データも(漏れてたら)テストする
●
一番中間の値
●
正常値のうち最小・最大値
– 異常系はテストしないので境界値分析とは違う
●
古いデータ
– 特に旧システムからのリプレースなどで必要

22.4 典型的エラー

エラーは偏在している

エラーの多いクラス 31 (7%)
ここを重点的に修正した
→ エラー 1/10 に
→ 保守

コスト 45% 減
→ 顧客満足度もアップ
エラーの少ないクラ
ス
エラーの多いクラス
エラーの少

ないクラス 394 (93%)


IBMの調査結果より

エラーにおける20:80の法則
120
●
20%のクラスが80%のエ
ラーを抱えている
100
●
極端な例だと、たった
1000行に50個エラーが集
80
中し、修正には全システム
エラー多
いクラス
60
の開発コストの10倍がか
エラー少
ないクラ
かったと
か (1960年代
の
ス
40
IBM の OS/360 開発)
20
0
クラス数の比率 エラーの比率

エラーの傾向
4.71 1.74 2.76
25.18
8.12
構造
データ
8.98
実装した機能
コンストラクション
統合
機能要件
テスト定義 or 実行
システム , アーキテクチャ
9.88
不明
22.44
16.19


※ なんか研究によって結果が随分違うらしいので参考程度に。

まだまだあるよ、エラーの統計
●
エラーの三大原因
120
●
APに関する知識不足
100
●
要件の変更や衝突
●
人や組織の協調に関する問題
80
●
つまりコンストラクションでない
複数クラ
60
●
コンストラクションエラーの原因
スに修正
単体のみ
●
95% プログラマ
40
●
2% OS かコンパイラ
●
2% 他のソフトウェア
20
●
1% ハードウェア
0
エラーの割合
85%のエラーは
原因のクラスのみの

修正で済む

どれも研究の一例であることに注意

まだまだまだあるよ
● typo は非常に多く、その修正コストは巨額
●
コンストラクションエラーの36%になることも
●
損害額はひどいのに

なると $1.6B (1300億円)
● 設計の誤解もかなり大きい
●
エラーの16〜19%は設計の間違った実装
● 組織によってこの傾向はかなり変わるので、自
分の組織については実際に測定するのが一番い
い

コンストラクションが主たる原因
● 1000行程度だと75%、500k行でも35%ぐらい
● この辺もPJによってまちまち

どれだけエラーを発見できるか？
● 平均的なPJだと1-25個/1000行
● (少なくとも昔の)MSではリリース時に0.5
個/1000行
●
コードリーディングと独立テストにより達成
● 「クリーンルーム開発」を使うと0.5個/1000行
● スペースシャトルのソフトは0個/500,000行
●
ピアレビューや統計的テストなどを活用
● TSPという手法では 0.06個/1000行

テスト自身がエラーの原因になる
● テストはソースコードと同じくらい丁寧に
● ウォークスルーやインスペクションも活用
● テスト計画を作ろう
● テストケースを保存しよう
● ユニットテストフレームワークを使おう

22.5 テスト支援ツール

Scaffolding
● 「足場」という意味
● 「スタブ」「ドライバ」などを作る
● xUnit 系はあまりにも有名
● モックフレームワークでは Mockito が有名
●
PHPならPHPUnit
●
python にもあるよ

Diff
● 説明不要
● オプションの中には便利なものも色々あるので
一度は man を見よう
● --side-by-side で2つのテキストを横に並べて比
較できる
●
幅調

整は –width=N。デフォルト130なので要調整
●
みんな知ってるよね？

テストデータジェネレータ
● 力技だがやっぱり便利
● プログラミングコンテストの練習時に、どうし
ても間違いが分からない問題はジェネレータ
作って正解者のコードと比較したりしてた

カバレッジモニタ
● モニタリングしないで気分だけでやってるとカ
バレッジは60%ぐらいらしい
● PHPUnitには標準でついてる
●
html出力してグラフィカルに表示できる
● python には coverage.py がある

データレコーダとかロギングとか
● 間違ったテストは記録しましょう
● 低レベルのテストでのツールはよく知らない
● システムテストとかだと TestLink あたりが該
当するか？

デバッガ
● みんな大好

き gdb
● 1ステップづつ見ていくのはウォークスルーに
もなる
● PHP だったら xdebug
●
firefox + vimとの連携で1ステップづつ見れる

システム乱雑化
● メモリを0にしたりぐちゃぐちゃにしたり
● webの世界でここまでやるとこあるんだろうか
● OSとか組み込みの世界では gdb から値書き換
えたりしてテストしたりするが、ここまでやる
のか不明

エラーデータベース
● TestLink だと統計機能がある
● redmine

や trac もこれに該当するかもしれない

22.6 テストを改善する

テスト改善の手法
● テスト計画を作ろう
● 再テスト(リグレッションテスト)
●
高品質なプロダクトには不可欠
● テストを自動化しよう
●
リグレッションテストは自動化必須

22.7 テスト記録を保存する

保存すべき情報
● 日付、報告者、ビルドナンバー、修正日時
● 問題の詳細
● 関連するエラー
● エラーの重要度
● エラーの種類
● 発見/修正にかかった時間

自分のテスト記録も保存しよう
● 自分のクセがわかる
● そこからチェックリストも作れる

まとめ

まとめ
●
開発者テスト超重要
●
でも高品質なソフトにはレビューなどの手法を組み合
わせることが必須
●
テストファーストの方が開発時間短縮できる
●
テストケースの多くは形式的手法で簡単に作れる
●
エラーは偏在するのでそこだけ再設計しよう
●
リグレッションテストはテスト自動化で実行しよう

おまけ：最近の組み込み開発事情
●
某社の組み込み開発事情(C言語)
●
ユニットテストで網羅テストやっても費用対効果が上
がらないのでカバレッジだけ確保
●
商用の静的解析ツール「coverity」を使う
●
誤検知が少ないらしい
●
「組み込みの世界においては、起こる可能性のあるも
のは全て起きる。だからそういうものは全て潰す」
●
出てくるエラーは全て潰す
●
エラーを取捨選択するコストも馬鹿にならないため

参考文献

1. “Code Complete, Second Edition”, Steve McConnell, Microsoft Press, 2004

Thank you !