3 方法論から
モダンテスト技法へ

概要

  • オラクル問題：テスト設計の基本
    • マイヤーズの三角形を対象にして，
    • 作成したテストケースは
  1. テスト設計： 正しさ？
  2. テストの効果：関数の正しさ？

3.1 経験によるテストの課題

  • 経験指向のテスト設計: 体系的学習ではなく，各自の経験から得た設計方法．
  • マイヤーズ：1979年の著書
    • 三角形問題を当時一流の開発チームで解いた
    • 平均で７割程度のテストケースしか作成できなかった．

マイヤーズの結論：

  • 確立したテストケース設計の方法論を学ぶ必要がある．
  • IBM社OS開発で使われている方法を体系化し著書で示した．

★テスト設計方法論の始まり　

工学とアートの違い：再現性

  • 工学の特徴：再現性の確保
    • 例：建築物の強度計算
      • 専門家が行えば再現性あり
  • エンジニアの要件：再現性
    • 経験によるテスト：アート
      • 再現性が低いのでアートと揶揄された
    • 現代の職場でも見られる（かも）
      • 優れたアート作品が良いとの考えもある

テスト設計の再現性問題

  • 棟梁型のチーム：解決している
    • 対策：経験豊富なリーダーがチーム内を統制
  • 請負型の集団：解決できない
    • 労務管理はあるが，スキルは自己責任
  • 車載ソフトでは
    • 重厚プロセス＋再発防止の追加レビュー
    • 冗長なプロセス，マニュアル規範で抑え込む

3.2 レガシー技術：方法論の確立

モダン技術出現前の対策です．

  • 棟梁的な経験者：絶対数が不足
  • 対策
    • 棟梁の暗黙知を形式知としてまとめる
  • テストの方法論が作られた
    • 1980年代には，ほぼほぼ完成
    • 同値分割，境界値分析，パス網羅，MC/DC
    • 知識としマニュアル化し継承されている．

課題：形式知は再現性を高めたか

  • 同値分割，境界値分析，など
    • 定義を知れば，理解は進むが
    • 仕様から，漏れなく抽出できるか？
  • 複雑な組み合わせは，分解しても理解できない
    • 要素が独立なら分解で済む
    • 依存関係は分解しても同時に作用する
  • 形式知だけでは解決しなかった

テスト設計の方法論

  • 複雑な関係からテストケースを作る
  • テスト設計まで踏み込んだ技術書
  • 1980年 マイヤーズの本
  • 1990年 バイザーの本
  • 数少なく他は，形式知と解説程度
  • 資料2.1参照

テスト設計の考え方

  1. 機能（action）
  2. 条件（condition）
  3. 条件の組み合わせ（condition, decision)
  4. 条件に状態(state)が加わると時系列やシーケンス制御

機能のテスト

  • 機能：入力を出力に変換する
    • 分解したものをActionと呼ぶ
    • 例：正三角形
  • 機能は出力で確認できる．
    • 出力の同値分割（排他的関係）★
    • 独立した機能は分割だけで良い

条件と条件の組合せ

  • 条件
    • 三角形の辺の値は０より大であること
    • 同値分割例：辺iは,２つの部分集合＝同値分割
      • 0以下 と １以上
  • 組合せで，機能が動作する＝ decision
    • 3辺の一つでも0以下なら，”三角形ではない”
    • ”三角形ではない”と言うaction＝機能が起動する
    • 例：三角形ではないの補集合&三辺が等しい.
      • このdecision -> Action　正三角形
    • これらを洗い出す

デシジョンテーブル

  • テスト対象の入力と出力の機能関係（Action)を
  • 入力の条件（condition 同値分割で表現）と
  • 組合せ（decision）で表現する表
  • 設計時の定義がJISに定められている．
    • テスト用の公式定義は無い
    • マイヤーズは提案

重要な設計技術

  • デシジョンテーブルによる設計
  • 安全系では必須の技術．
    • ISO 26262 を始め多くの規格で義務化
  • 専門的な技術：詳細は資料参照

3.3 レガシー技術の課題

  • 方法論は，体系化された一連の活動で実現
    • 実践できれば効果的な技法
    • 知識だけでは実践できない，訓練が必要
  • 例：オブジェクト指向設計，形式手法
    • 多くの方法論の特徴：専門職

学習コストが高い

  • デシジョンテーブル：使えるには
    • 最低でも２日間か３日間の演習が必要
  • バイザーの報告では，それで理解者は少数
    • 最も難しいテスト技法と呼ばれている
  • 結果，実践の場で「訓練されたチーム」は幻

モダン技術

3.4 モダン技術の出現

  • 立派な方法論＋習熟したエンジニア
    • 関数レベルのテストでは，あまりに高コスト
    • 組込み系の実装や派生開発では高コスト
  • 現場向けモダンテスト技法は
  • Tools and Techniques (T&T)
    • 「道具とその活用技術」へ向かう
    • 「方法論と習熟」から道具活用へ
    • AI はさらに後のポストモダン技術

「テストのデバッグ」概念

  • 難しい方法論を使って最初から正解を求める
    • 熟練エンジニアとして正しいが
  • 普通のエンジニア
    • 無理：普通のテストケースから
    • テストのデバッグをしながら
    • 順次テストを完成して行く

プログラミングスキル

  • プログラミングのスキル
  1. 設計でレビューを重ね，完全なコードを書く
  2. 速くコードを書いて，デバッグを繰り返し完成させる
  • どっちのスタイルが現実的ですか
  • グループで討論してください

【演習3-1】プログラミングスタイル

  • 結果を共有ノートに書いて
  • 考えられる理由も
  • 【ブレークアウトルーム 7分】

【演習3-2】テストのデバッグ

  • テスト：ここではテストデータ作成
  • さらに実行環境，実行を含めて
  • テストのデバッグについて討論して
  • 必要性や方法など
  • 職場ではどうしている
  • 自身の考えややり方は
  • 【ブレークアウトルーム 7分】
  • グループでまとめて

デバッグを可能にするには

  • まずいところを測り検出する道具
  • デバッグを繰り返す持続力

誤りや漏れ検出：複式簿記に学ぶ

double_entry cluster_system 複式簿記システム 伝票 伝票(Transaction) 借方 借方(Debit) 伝票->借方 記録 貸方 貸方(Credit) 伝票->貸方 記録 整合性確認 整合性確認(Verification) 日計 日計(Daily Balance) 整合性確認->日計 フィード バック 借方合計 借方合計(Debit Total) 借方->借方合計 貸方合計 貸方合計(Credit Total) 貸方->貸方合計 借方合計->日計 検算 貸方合計->日計 検算 日計->整合性確認

複式簿記と開発プロセスの類推性

  • 借方（Debit） ↔︎ 設計プロセス（開発側）
  • 貸方（Credit） ↔︎ テストプロセス（検証側）
  • 伝票（Transaction） ↔︎ 仕様
  • 日計（Daily Balance） ↔︎ 検算結果・整合性確認

設計プロセスとテストプロセス

process_overview 仕様書 仕様書 (Specification) 設計プロセス 設計プロセス (Design Process) 仕様書->設計プロセス 基準 テストプロセス テストプロセス (Test Process) 仕様書->テストプロセス 基準 テスト対象 テスト対象 (SUT) 設計プロセス->テスト対象 テストプロセス->テスト対象 検証 検証結果 検証結果 (Verification Result) テスト対象->検証結果 検証結果->設計プロセス 開発フィードバック 検証結果->テストプロセス テストフィードバック

冗長構成による検算システム

  • どの位，信頼性が上がるか
  • 設計の誤り率 \(R_D\)
  • テストの誤り率 \(R_T\)
  • 結果としての誤り率 \(R_{TD}=R_D * R_T\)
  • 例：共に10％の誤り 0.1 * 0.1 ＝ 0.01
    • 理論的な誤り率は1％（10倍向上）
  • 理論が崩れる事象は
    • テストの網羅率が低い場合

テストのデバッグ具体例

  • 網羅率の確保
  • そのための道具
  • GCOV （GCC系）演習2で使用
  • llvm-cov （Clang LLVM）
  • 詳しくは演習にて

網羅度を達成すると

  • 方法論を習得した結果と同程度のテスト設計品質
    • 新人レベルでも達成できる
  • 現場向けモダンテスト技法
    • 網羅度をモニターして
    • テスト設計のデバッグを速く実行
  • 前提
    • テスト環境の準備
    • 網羅のための網羅でなく，テスト入力と正解値も追加して行く

3.5 関数レベルのテスト：まとめ

  • 実装（プログラミング）
  • テスト実行
  • 最初は共に誤りを含んでいる
  • 相互に検算しながら完成させる
  • テストファーストの考え方
  • 成果物は，完成したコード
  • 完成したテスト：共に維持管理
    • 非公式なデバッグ –> 公式なテスト成果物

演習で確かめる

  • 網羅度の尺度には様々あるが
  • GCOVで十分
    • 理由：抽象構文木への展開
    • 現代のGCCやclangの機能

演習Ex03　割引問題

  • 仕様は資料参照
  • 機能が排他的な関係：割引率が変わる
  • テストの世界では，結果の同値と呼ぶ
  • 入力は原因と呼び，condition＝同値分割する

Ex04 派生開発：割引追加

  • 派生開発におけるロジックの変更
  • どのような影響があり
  • テスト設計はどうするのか
  • 経験的な方法で求めるのは困難
  • 仕様は資料参照

次は，