MasaoApril's Library.

Software Testingなネタを書いてみた。

JaSST15東海(1)「基調講演：テストから観た実体のモデリングと実装構造の評価 ～検証指向設計の実現に向けて～」

JaSST Tokai Conference TestDesign

　11/6(金)に開催されたソフトウェアテストシンポジウム2015東海(JaSST'15 Tokai)に参加しました。私が聴講したセッションは下記です。

セッション1 基調講演：「テストから観た実体のモデリングと実装構造の評価 ～検証指向設計の実現に向けて～」 松尾谷 徹(デバッグ工学研究所)
セッション 4-1 特別講演：「はじめてのコンコリックテスト ～基本原理から知るホワイトボックステストの新技術とその応用～」 植月 啓次(フェリカネットワークス)
セッション 4-2 事例発表：「安全系組込ソフトウェア開発におけるユニットテストの効率化」 岸本 渉(デンソー)
セッション 4-3 ワークショップ 「意地悪漢字を使ってみよう！ ～テスト設計ワークショップ～」 鈴木 三紀夫(リコーＩＴソリューションズ)
情報交換会

　今回は、セッション1 基調講演：「テストから観た実体のモデリングと実装構造の評価 ～検証指向設計の実現に向けて～」です。

セッション1 基調講演：「テストから観た実体のモデリングと実装構造の評価 ～検証指向設計の実現に向けて～」松尾谷 徹(デバッグ工学研究所)

(1)背景 検証指向設計とは

(1-1)背景
(1-1-1)オブジェクト指向
(1-1-2)流用技術
  • 簡単にコード書ける。 →逆に言うと、バグを書くと簡単にシステムが停止する。
  • プログラム規模が増大し、テストの規模増大という事情がある。
(1-2)開発オーディション

　テスト能力の範囲でソフトウェアを設計する。

(2)派生開発

(2-1)確認すべき2つの仕様
  • 追加、変更、削除された機能やふるまい。
    →派生部分のテスト。
  • 何も変わっていない機能。
    →回帰テスト(Regression Testing)
(2-2)回帰テスト設計
  • 入力となる仕様(成果物)は「？(変更なし)」である。
  • linuxの世界では、回帰テストの部分も含めてリリースしている。
    • 1行変更や追加すると、テストを書くことが当たり前の世界である。
  • 日本は、回帰テストはビッグバーンテストとなっているのが実情である。
(2-3)後工程
(2-3-1)製造業の美徳

　「後工程はお客様」

(2-3-2)製造業のの内なるソフトウェア業では

　Cowboy Programmingで我流でソフトウェア開発するが、共倒れになる。

(2-3-3)解決策
  • 美徳で守るプロセスへ改善
    →精神論では...
  • 現実を受け入れる。
    →新たな解決方法へ
(2-4)派生開発の回帰テスト
  • 問題点
    • 仕様ベースのテストでは不可能。
    • 実装ベースのテストで乗り越える。
  • Concolic Testing
    前のバージョンと現バージョンの動作結果を比較する。

(3)スキルの成長

(3-1)元NECの東さん

　バグとテストケースの対応は...

  • 半分くらい。
  • テストケースの重複。
  • テスト準備でバグを見つけることも。
(3-2)プログラミング演習

　演習法は、「机上でプログラミング→プログラミング組んで実習」よりは「早く習得→早く書いて、早くデバッグ」を行うことにしている。

(3-3)諸々のスキル習得
  • 失敗して、学んでフィードバックする。
  • ブリコラージュ：「デバッグで成長する」。
  • エンジニアリングは、「綿密な論理の積み上げ」。
(3-4)プログラミング

　確かめながら作る。つまり、動かしてみないと分からない。

(3-5)ソフトウェア工学

　1968年NATOの時代に「早期警戒システムの失敗」がきっかけで始まった。

(3-6)テストスキルの実態
  • テスト設計の問題を解く。
    8割の網羅達成者は、全体の5%以下であった。
  • テストスキルが身につかない。
    原因は、テストケース書くがテストケースのデバッグが無い。
  • テスト(デバッグ)
    テスト対象プログラムとgcov
(3-7)テスト対象の出来栄え

　本質は、「検算」である。

(3-8)テストのモデル
  • 検算の変形である。
  • 現状は、テスト側のデバッグが欠如している。
  • テストのデバッグ環境があると、テストスキルが伸びる。

(4)テストのモデル：探索モデル

(4-1)OR(Operations Research)

　Uボードを探索する方法を考案することがきっかけ。

(4-2)探索要素
  • 探索空間
  • 探索目標
  • 有効探知幅
  • 探知速度
(4-3)ランダム探索

　発見確率から見ると非効率である。

(5)プログラムの探索行動

(5-1)問題
  • そもそも探索していないので、探索漏れがある。
  • 時間や工数がかかるのが探知効率の問題である。
(5-2)テスト技法の問題
  • テストケースを詳細化するが、全体を網羅していない。
  • 系統的な技法が敬遠される。
(5-3)テストのデバッグ課題
  • テストケースの重複
  • 実施済みテストのフィードバック
(5-4)マイヤーズの三角形問題

　CFD(原因流れ図)で解く。

(5-5)探知効率

　平行探索に持って行く必要が...

(5-6)まとめ
  • 検算できるようにする必要がある
  • ブリコラージュ＋科学的手法

所感

　ソフトウェアが望まれた動作するか検算できるようにモデルを考えるためには、小さなサイクルで失敗して学んでフィードバックしながらスキルを高めることが必要と痛感しました。また、世の中でやっているソフトウェア設計やテスト設計を幅広く知り、開発プロジェクトで試行することも私にとっての課題の1つと思いました。