ゆもつよ論文解説会
▼当日、ツイートされた内容です。
－－－－－－－－－－－－
▼公開された資料です。
－－－－－－－－－－－－
▼当日の僕のメモです。
入出力データの順序情報に基づくブラックボックステスト手法に関する研究
このタイトルで博士論文を書きました。
１．緒論
ゆもつよメソッドが必要なのかというのが問題意識。
ソフトウェアの規模と複雑度合いが増加している。
テストケースは、ファンクションポイントに対して１．３から１．５乗というケーパーズ・ジョーンズが言っている。
ＦＰ規模は３０年で１０倍。１．５乗だから膨大になる。
多くの人がテストケースを作成する工程に必要とされているにも関わらず、テストケースを作成するために、テスト対象を詳細化していくことが大切。
しかし、明確に定義されたルールがない。
何らかの考え方に基づいて詳細化していくんだけど、その考えが明確でない。
個人個人がそれぞれの考えに基づいて詳細化していく。
これが、テストケース数の増加や漏れの原因になると湯本さんは考えています。
テスト対象のことを知らないでテストケースを作っていたりします。
複数の人に分かれてテストケースを作るために、お見合いや、重複が発生しています。
これらのことから、テストの活動がソフトウェアの品質を確保する役割を果たせず、コスト増に繋がる。
これが問題意識です。
研究テーマ
目的：ブラックボックステストのテストケース抽出において、テストケースを作成する工程に投入される人員が、必要なテストケースの抽出において、抜け漏れを防止する。
２．研究対象のソフトウェアの構成
ソフトウェアシンポジウムに入っている。アプリケーションソフトウェアの図を使っている。
タスクは該当のテストレベルから見た入力を出力に変化する処理
状態は広範囲でタスクの有効性を決めているもの（保持データとして実装する場合もある）
保持データとは、処理で利用するデータのうち、データベースや内部メモリに保存されているもの
状態は保持データとして実装されている場合もあるし、機械的に実装されている場合もある。
テストレベルのサイズによってタスクのサイズも変わる。
システム オブ システムズのように大きいものを対象とするならば、タスクも大きくなる。
研究の対象として、システムテストレベルを対象としている。
なぜ、システムテストレベルを選んでいるかというと、湯本さんが感じている問題が一番表れるところだから。
テスト開発プロセスは、テスト分析とテスト設計を対象としている。ISTQBのテストプロセスのうち。
ブラックボックステストを研究の対象としている。
ブラックボックステストの課題を２つ取り上げた。
仮説を立てた。テスト対象の詳細化の問題。
テスト対象をテスト設計できるサイズまで詳細化していく方法が経験則や個人の考え方に基づいている。
自分の思うがままにテストケースを作ってくださいってやりますと、ばらばらになります。
会社でオンサイトでやると、４つのグループがそれぞれ異なった書式になる。
もう一つの課題として、機能間の統合に対するテスト抽出の問題。
機能間を統合させて、テストケース数は、単に津の機能や制御構造の和ではなく積になる。
システムテストでは、状態千二に伴う時系列の組み合わせのテストも求められる。
テストケース数は爆発する。
時系列の組み合わせとして、状態遷移テスト設計によるS1網羅基準（１スイッチカバレッジ）があるが、これは２つの状態遷移における遷移数の積となり、膨大なテスト工数をひつようとする課題。
S4ぐらいにならないと見つからないというのがある。
Sを画面遷移とみると爆発する。
テストカテゴリーベースドテスト
テスト分析での分類の一貫性欠如に対する先行研究。
予備実験を行う。
実験をして集めました。
テスト分析手法を適用する前と後で結果の相関をみてみる。
ばらつくという仮説があるんだけど、どの程度ばらつきがあるのかを示す。
個人でやって、グループでやって、ということをサンプルを取得した。
テストベースを与えて、各人の経験でやってもらう。
次にテスト分析手法を与えると、どう違うのかという実験。
実験題材：組込み題材：Bluetoothヘッドセット。
実験題材：エンプラ題材：フライト予約システム
このテストベースの量（パワーポイントで１２枚）フィーチャーも同じくらい。
演習の時間は４０分。
見つけるべき
実験の結果、全部で８チームでやった。手法という知識を適用するとよくなる、わるくなる。
すべて洗い出せたらA+、前よりよくなったらAとか、そういうふうに実験をやった。
この実験は、対称グループ（知識を与えるグループ、与えないグループ）でやったのではなく、個人が成長するものでやった。
経験で書かせると
１８人 テスト条件（使用項目）
１９人 テストケース
１７人 P-V（パラメータ・バリュー）
３人 シナリオ（なにをする、このあとなにをする、そうしてどうなった）
もともとの書き方とゆもつよメソッドに相関があるかなと思ったけど、相関は無かった。
テストケースの抽出手法を新しいものを提案した。
４章から変えています。
テストベースを網羅的に分析できる
ゆもつよメソッドはテスト対象からやらなければならないテスト条件に向かって、
論理的機能構造は、抽象度が高いので、実際のテスト対称に合わせて言葉を変えて、テスト条件を見つけていく。
テストカテゴリーで挙げて行く方法は、コンサルならばよいけれども、網羅性にかける。
I/Oテストデータパターンというのを考案した。
単一の入出力に対しては９パターンしかない。この９パターンがあるかどうかを洗い出すと、抜け漏れなくだせるのではないかと考えた。
この流れで、テスト条件を特定できるかを適用評価した。
村上さん・渋谷さんのところで、やってみた。I/Oテストデータパターンを適用して見つかるか、見つからないかをやってみた。
I/Oテストデータパターンをみつけると、たくさん見つかった。
P1が特にテストカテゴリと実プロジェクトの差異が大きいことが分かる。
智美塾のスライドに載っている。
なぜこのテストケースをやらないのか？ それは当然だから、それはホワイトボックステストでやっているはずだから、というものは現場では多くある。
５．ジャーナル論文
I/Oテストデータパターンだけでは対応できない、単一の入出力だけではなく、統合して確認すべきテスト条件に着目する。
ゆもつよメソッドの中で、相互作用に割り当てられたものを具体的にテストケースを作成するときの方法が、順序組合せテストを提案した。
順序組合せの手法では、状態遷移テスト設計→アクション、アクションとアクションが重なるので、複数の機能を動かすという意味になる。
S0は自分たちだけでテストできるけれども、S1はお隣さんも含まれるので、不具合が見つけやすくなる。
最初の変更タスクから出力がでるんだけど、データや状態に影響を与えるので、波及タスクはこれに影響を受ける。
タスクの中にも処理が入っている。制御構造を持っているはずだ。
２つのタスク間の順序組合せを対象とする。
変更タスクと波及タスクの組合せをテストケースとする。
波及タスクは、変更タスクを見つけた後に、データストアに対して、入力エッジをもっていて、源泉に出力するものを波及タスクとする。
・・・独り言・・・
拡張CRUD図というのがなんだか読めなかったんだけど、次のような現場で使っている図をイメージしたら理解できた。
機能｜入力｜出力｜エンティティ１｜エンティティ２｜・・・・
入力のセルには画面名やファイル名などが入る。
この入力をエンティティのように個別に書けば拡張CRUDになる。
・・・独り言終わり・・・
S1にすると２８個の遷移パスになります。
２８個テストすれば、１２４５はテストしたことになります。
しかし３はテストできません。
S1の網羅基準ではテストできないということが分かった。
テストケースの抜け漏れが課題なので、I/Oテストデータパターンで
複合している課題に対して順序組合せテストを活用する。
単一のものをI/Oテストデータパターン
相互作用の