単体テスト設計のコツ

Size: px

Start display at page:

Download "単体テスト設計のコツ"

ひでたつのたけ
5 years ago
Views:

ESEC2011 ブース内セッション単体テスト設計のコツ日本システム開発株式会社 http://www.

2 目次 1. ユニットテストについて知っておかないといけないこと 1-1. 品質問題の原因とユニットテストの関係 1-2. ソースコードレビューとユニットテストの違い 2. 有効なユニットテストデータの与え方 [ 事例 ] 2-1. [ 事例 1] 有効な値が 10~20 の unsigned short 変数 2-2. [ 事例 2] 参照のみ行う領域の確認 2-3. [ 事例 3] メモリ破壊が起きるコピー処理 3. 危険コードに対するテストデータの与え方 [ 事例 ] 3-1. [ 事例 1] 欠陥となる可能性がある符号変換処理 3-2. [ 事例 2] オーバーフローに誘発されたゼロ割処理 4. ユニットテストまとめ 2

3 1. ユニットテストについて知っておかないといけないこと 3

4 1-1 品質問題の原因とユニットテストの関係不具合の原因の割合約 6 割がソフトウェアの不具合引用 : 2010 年版組込みソフトウェア産業実態調査報告書 - 事業責任者向け調査 - ( 経済産業省 ) 品質の悪い製品を作り出す原因の一部はユニットテストにあるユニットテストは製品不具合の原因に直接的直接的または関与するまたは間接的間接的に 4

5 1-1 品質問題の原因とユニットテストの関係製品欠陥に対して直接的に関与する場合ユニットテスト欠陥の流出ユニットテスト工程で検出すべき欠陥を検出できなかったそのまま製品が出荷されたため欠陥が発生し品質問題による損失を発生させたレビューユニットテスト統合テスト検出できなかったユニットテスト工程以降でも欠陥を検出できずそのまま流出させてしまった 5

6 1-1 品質問題の原因とユニットテストの関係製品欠陥に対して間接的に関与する場合ユニットテスト以降のテストが不十分ユニットテスト工程に不備がありその後のテスト工程で行うはずであった機能テストなどが十分に実施できなかった必要なテストが不十分なまま出荷されたため欠陥が発生し品質問題による損失を発生させた予定ユニットテスト統合テスト実績検出できなかったここで検出ユニットテスト欠陥の対応統合テストが十分にできず統合テストで検出すべき欠陥を流出させてしまった直接の原因が統合テストであるためそもそもの原因であるユニットテストに改善の意識が向きにくい 6

ユニットテストは実施しなければならないユニットテストとソースコードレビューの工程の目的は大きく異なるため

7 1-2 ソースコードレビューとユニットテストの違いユニットテストに対するよくある誤解ソースコードレビューをしっかり行えばユニットテストは実施しなくても問題ないのでは? ユニットテストは実施しなければならないユニットテストとソースコードレビューの工程の目的は大きく異なるためユニットテスト工程を省略することは不可能ユニットテストを実施しないと他の工程は本来の目的を果たすことができない仮に現状ユニットテスト工程を省略していて問題が出ないとしても今の開発体制が崩れたら問題が発生する可能性は大 7

8 1-2 ソースコードレビューとユニットテストの違いソースコードレビューとユニットテストの比較ユニットテストのコツとしてソースコードレビューとの違いを認識しておくことが重要同じ工程評価対象評価範囲インプット評価内容欠陥検出範囲品質保証ソースコードレビューソースコード関数詳細設計静的分析仕様網羅性確認コーディング規約適用確認冗長性確認コメント確認タイミング欠陥確認 ( ロバスト性確認 ) 不可能ユニットテスト実行モジュール関数詳細設計動的分析仕様網羅性確認コードカバレッジ確認ロバスト性確認可能 ( 動作させた範囲 ) ソースコードレビューとユニットテストは評価範囲とインプットは同じだがそれ以外は異なる 8

9 1-2 ソースコードレビューとユニットテストの違いソースコードレビュー以外では検出できない欠陥 Q. タイミングによる欠陥を検出できるか? : : void void func() func() {{ if if (1 (1 == == a) a) {{ b b = = a; a; }} return; return; }} : : a が 1 の時に b を a(1) にすることを期待しているが割り込みが上がると期待しない結果になるここで割り込み a = 3; ユニットテスト以降の工程でこの状況を確実に作り出すことはできない A. ソースコードレビューならタイミングによる欠陥を検出できる 9

10 1-2 ソースコードレビューとユニットテストの違いユニットテスト以外では検出できない欠陥 Q. コンパイル環境によって動作が異なる場合必ず正しいソースコードレビューが行えるか? : : unsigned unsigned char char a a = = 255, 255, b b = = 255; 255; unsigned unsigned short short c; c; c c = = (unsigned (unsigned short)(a short)(a + + b); b); : : ある環境では 510 ある環境では 254 A. レビューアが全てのコンパイラの動作を把握することはほぼ不可能であるため必ず正しく行えるとは限らない実際に動作させるユニットテストで差分を検出する必要がある 10

11 1-2 ソースコードレビューとユニットテストの違いまとめ 1. 欠陥検出範囲はソースコードレビューの方が広いソースコードレビューの方が多くの欠陥を検出できる 2. ユニットテストは機械的に全ステップ評価する唯一の工程目視で行うソースコードレビューに対しユニットテストは機械的にテストすることでヒューマンエラーを防ぐユニットテストの後工程では全ステップに対してテストを行わないためユニットテストでステップに対する評価を完了しておく必要がある 3. ソースコードレビューは品質証明にならないソースコードレビューはレビューアがNGと判断した箇所だけに指摘が出るため他に欠陥が10 件潜伏している可能性も 100 件潜伏している可能性もあるユニットテストは品質証明になるユニットテストは与える INPUT に対するテスト結果を記録として残すためこの INPUT を与えれば正常に動作するということを証明できる (INPUT を網羅する必要あり ) ソースコードレビューとユニットテストは共に必要 ( それぞれで何を重視すればよいか? が重要となる ) 11

12 2. 有効なユニットテストデータの与え方 [ 事例 ] 12

13 2 有効なユニットテストデータの与え方 [ 事例 ] 有効なユニットテストにするために重要なことどのようなテストケースを作成するかどのようなテストデータを与えるかこのようなユニットテストを OJT で行うことは難しい ( 現場に指導できる人材が少ない ) 有効なユニットテストを考えるための事例 [ 事例 1] 有効な値が 10~20 の unsigned short 変数 [ 事例 2] 参照のみ行う領域の確認 [ 事例 3] メモリ破壊が起きるコピー処理 13

14 2-1 [ 事例 1] 有効な値が 10~20 の unsigned short 変数同値分割とは同値分割同値分割はテストデータを抽出する手法の一つ起こりうるすべての事象を洗い出し同じ事象を発生させる入力値の集合を作成この入力値の集合を同値クラスと呼ぶ同値分割では同値クラスから代表値を選出しテストデータとする 14

15 2-1 [ 事例 1] 有効な値が 10~20 の unsigned short 変数例 ) 有効な値が 10~20 の unsigned short 変数の場合 long func(unsigned short data) { if ((10 <= data) && (20 >= data)) { : } : } を境界とした同値クラスに分割分割した同値クラスから代表値を選出同値クラスの代表値同値クラス同値クラス同値クラス Q.data の初期値に何の値を指定するか? A. 例えばを指定したとするしかし 50 では欠陥が検出できない可能性がある 15

16 2-1 [ 事例 1] 有効な値が 10~20 の unsigned short 変数例 ) 有効な値が 10~20 の unsigned short 変数の場合検出できない欠陥と対策 50をテストデータとして指定 50 上位バイト下位バイトバイトの変数である有効範囲は 10~20 の 1 バイト範囲である下位バイトが有効値と同じビットの値の評価が正しくできない可能性がある ( 例えば 266 が有効値とみなされる欠陥 ) 266をテストデータとして指定 266 上位バイト下位バイト対策変数を2バイトで評価しているか検証できる値を使用する ( 例えば266) 上位バイトを評価に使用しているか確認できる下位バイトが有効範囲内であれば誤った判断をしていないか確認できる 16

17 2-2 [ 事例 2] 参照のみ行う領域の確認例 ) 参照のみ行う領域を更新していないことを確認する場合関数 func() は外部変数 flag を参照している ( 更新はしない ) 外部変数 flag 参照 flag が更新されていないことを確認 func() を呼び出す前と後で flag の値が同じであればよい flag に xx を設定関数 func() func() 呼び出し flag が xx か? flag が xx なら更新していない Q.flag の初期値に何の値を指定するか? A. 例えば 1 を指定したとするしかし 1 では欠陥が検出できない可能性がある 17

18 2-2 [ 事例 2] 参照のみ行う領域の確認例 ) 参照のみ行う領域を更新していないことを確認する場合検出できない欠陥と対策関数 func() は外部変数 flagを参照している ( 更新はしない ) flagの初期値として 1 を指定 func() 呼び出し前 flag = 1 func() 呼び出し後 flag = 1? 外部変数 flag 参照関数 func() 偶然初期値と同じ値に flag を更新している可能性がある一般的によく使用する値 (1 や 0) では意図しない所で偶然初期値と同じ値に書き換えられている可能性がある対策マジックナンバー (0xaaなど) を指定する値を変えて複数回テストする 18

19 2-3 [ 事例 3] メモリ破壊が起きるコピー処理例 ) 配列をコピーする場合 From To Size を指定してコピーを行う処理 (From To はメモリのどこでも指定できる ) From To 元データコピー先 Size 元データ (From) がコピー先 (To) へ Size の値だけコピーできていればよい多くの場合サイズに着目したテストを実施している (0 配列の最大値を指定 ) しかしサイズだけに着目したテストでは欠陥が検出できない可能性がある 19

20 2-3 [ 事例 3] メモリ破壊が起きるコピー処理例 ) 配列をコピーする場合検出できない欠陥コピー元データの開始位置 (From) コピー先データの開始 (To) データサイズ (Size) の関係によって発生するメモリ破壊メモリ破壊が起きるパターン 1 元データの後方とコピー先の領域が重なっている場合元データコピー先先頭から順にコピーすると後方のデータを使用する時にはコピー処理により上書きされてしまっている 2 元データの前方とコピー先の領域が重なっている場合コピー先元データ末尾から順にコピーすると前方のデータを使用する時にはコピー処理により上書きされてしまっている 20

21 2-3 [ 事例 3] メモリ破壊が起きるコピー処理例 ) メモリ破壊が起こるコピー処理対策コピー処理がある場合の正しいテスト観点 From To Size この 3 つの組み合わせが必要 From 元データ To コピー先 Size 組み合わせを考えないとテストに抜けが発生する 21

22 3. 危険コードに対するテストデータの与え方 [ 事例 ] 22

23 3 危険コードに対するテストデータの与え方 [ 事例 ] 危険コードに対するテストデータ危険コードは多くの値で正常に動作するがある特異な値を与えた場合に欠陥となる危険コードを考慮しないとテストが漏れる本章で紹介する事例 [ 事例 1] 欠陥となる可能性がある符号変換処理 [ 事例 2] オーバーフローに誘発されたゼロ割処理 23

24 3-1 [ 事例 1] 欠陥となる可能性がある符号変換処理例 )signed 変数を unsigned 変数として扱いたい場合 long func(signed char arg) { : if (0 > arg) { arg = -arg; // 符号変換処理 } : } 符号変換処理としてよく実装されるが欠陥が潜んでいるこれまで複数のプロジェクトで同じ誤りがあった Q.arg に何の値を指定するか? A. 例えばを指定したとするしかしでは欠陥が検出できない可能性がある 24

25 3-1 [ 事例 1] 欠陥となる可能性がある符号変換処理例 )signed 変数を unsigned 変数として扱いたい場合検出できない欠陥とポイント long func(signed char arg) { : if (0 > arg) { arg = -arg; // 符号変換処理 } : } この符号変換処理において符号を変換できない値が 1 点だけ存在する arg に -128 を与えた場合のみ符号変換処理を行っても符号が変換されないため unsigned 変数として扱うことができないポイント argに-128が指定されないことを確認する -128が指定される場合指定されても問題ないことを確認する 25

26 3-2 [ 事例 2] オーバーフローに誘発されたゼロ割処理例 ) 演算後に除算している場合 long func(unsigned char arg1) { :: a = (b / (unsigned char)(arg1 + 5)); :: } arg1 を +5 しているためゼロ割が発生しないと判断を誤りやすい arg1 = 0 long func() {{ :: }} Q.arg1 に何の値を指定するか? A. 例えばを指定したとするしかし代表値最小値最大値だけでは欠陥が検出できない可能性がある 26

27 3-2 [ 事例 2] オーバーフローに誘発されたゼロ割処理例 ) 演算後に除算している場合検出できない欠陥とポイント long func(unsigned char arg1) { :: a = (b / (unsigned char)(arg1 + 5)); :: } この演算処理においてゼロ割を発生させる値が 1 点だけ存在する arg2 に 251 を与えた場合のみ +5 するとオーバーフローするため除算の分母が 0 になりゼロ割が発生するポイント特定の値を与えられた場合のみ欠陥となるコードがあることを認識してテストを行うコードを見ないと有効なテストができないケースもあり得ることを認識する 27

28 4. ユニットテストまとめ 28

29 4 ユニットテストまとめ品質の良いユニットテストのために必要なものユニットテストの位置づけについての正しい理解 ( 特にソースコードレビューとの違い ) ユニットテストは開発において非常に重要な工程だが正しい知識を持って実施できていることが少ないテストケース設計の知識いかに有用なテストケースを作るかが重要テストデータの与え方の知識テストケースが正しくても与えるテストデータによって欠陥が検出できるかできないかが決まる 3つの知識が揃って始めて品質の良いユニットテストができるただし 3つの知識をOJTだけで習得するのは難しい Off-JT で3つの知識を習得する必要がある 29

30 単体テスト関連サービスについて単体テスト教育単体テストはどの開発プロジェクトでも実施しますが明確に実施方法が定まっていませんそんな開発現場で活用してもらうために単体テストに特化した教育コンテンツを揃えています C 言語版 C++ 言語版のコンテンツがあります本コンテンツを使用したセミナーを定期的に開催しています主催ガイオテクノロジー株式会社 URL : 単体テスト代行サービスソフトウェア品質を確保するために重要な工程である単体テストを代行しますブラックボックスホワイトボックスロバスト性の観点から高品質な単体テストを実施します単体テスト代行サービスの効果に不安がある場合試験的に数関数に対して単体テスト代行サービスを実施することも可能ですガイオテクノロジー株式会社の単体テスト代行サービスを支援しておりますテスト導入支援テスト導入支援は単体テスト以外の内容もカバーしたサービスです単体テスト以外 ( 設計や結合テスト ) の工程も改善しなければソフトウェア品質が向上しない場合お客様の現場に合った方法をご提案します例テストガイドライン策定テスト設計レビュー設計書確認ガイオテクノロジー株式会社のテスト導入支援を支援しておりますご質問ご相談資料請求はこちらまで : emb-sales@nskint.co.jp 30

31 単体テスト以外 (Android) のサービスについて Android アプリケーション開発初級編 Android OS の基礎知識を学ぶとともに Android アプリケーション開発の基本となるプログラミングモデルを講義と実習から習得します Android アプリケーション開発応用編 Android の中枢であるアプリケーションフレームワークの仕組みを理解するとともに実際の Android アプリケーション開発でよく発生する問題点の事例解決策などを理解することでより高度な Android アプリケーション開発のスキルを習得します Android 開発ポーティング編ターゲットボード上の Linux システム上に Android 特有のドライバの構築とミドルウェア Android アプリケーション等の搭載を行いますまた Android のチューニング技術なども習得する事により実践的な Android 技術者の育成が可能になります ( 企画 : 株式会社エンベデッドシステム開発 : 日本システム開発株式会社 ) その他必要スキル教育 (Java, デザインパターン等 ) 株式会社豆蔵との連携により Android 開発に必要なその他技術要素の習得も可能です (Java, デザインパターン,, UML 等 ) ご質問ご相談資料請求はこちらまで : emb-sales@nskint.co.jp 31

32 御清聴ありがとうございました 32

040402．ユニットテスト

040402．ユニットテスト 2. ユニットテストユニットテスト ( 単体テスト ) ユニットテストとはユニットテストはプログラムの最小単位であるモジュールの品質をテストすることでありその目的は結合テスト前にモジュール内のエラーを発見することであるテストは機能テストと構造テストの2つの観点から行うモジュールはプログラムを構成する要素であるから単体では動作しないドライバとスタブというテスト支援ツールを使用してテストを行う