ソフトウェア工学 ホワイトボックステスト２
前回
構造化テスト（structured testing）
制御フローグラフのトポロジ分析に基づくテストケースの選択手法。トポロジは、モノのつながりをモデル化する数学の分野。比較的小さい部品の単体テストに向く。
①制御フローグラフの作成
② グラフのサイクロマチック数（Ｃ）を計算する
Ｃ＝リンク数－ノード数＋２
– グラフの形の複雑さを表現するメトリクス
– McCabe尺度（測度）とも呼ばれる
グラフ内の条件分岐がすべて二値判定（出力
リンクが過不足なく２個）の場合
Ｃ＝ｐ＋１ でも可
③Ｃ個の基礎パスの組を選ぶ
ループを含まず制御フローグラフを通過するパス
④ 各基礎パスに対応したテストケースを作る
⓹テストケースに従ってテストを実行する
※適用範囲と制約
・コード量が多くなると非現実的
・テスト実施者にプログラミング技術を要求
・時間的なコストが大きくなりがち
・ コードに書かれていないことはテストできない
データフローテスト
制御フローテストの拡張したもの。 制御フローに沿って変数ライフサイクルをテストする。 静的検証と動的検証と両方可能。
定義→使用→消滅
これが制御フローの中で正しく出現するかをテストする。
定義・使用・消滅をどの要素に対応付けるかはプログラミング言語の仕様に依存
– 定義
• 変数宣言（初期化されない場合は除外）・明示的な生成(new)
• 代入（式の左辺として登場）
• 仮引数宣言（＝呼び出し時に実引数による初期化）
– 使用
• 右辺値として参照
• 実引数，返値としての参照
– 消滅
• 明示的な消去（delete）
• 有効スコープ（ブロック・関数）からの抜け出し
ソフトウェア工学-ホワイトボックステスト
ホワイトボックステスト
テスト対象ソフトウェアの内部パス，構造，実装に関する知識を前提としたテスト
＝プログラムが読めないとテストできない
適用範囲
– 単体テスト，統合テスト，システムテストの３レベルに適用
可能（受け入れテストには向かない）
制御フローテスト（control flow testing）
プログラムコード内の実行パス（path）の識別をする。パスを網羅するテストケースを作成し、テストの実行・出力結果の分析を行う。
制御フローグラフ（control flow graph）
フローチャートをもう少し抽象化したもの。丸と矢印のみが用いられる。
■構成要素
– 処理ブロック
• 逐次的な処理系列
• 途中からブロックに出入りできない
– 判定ポイント
• if-then-else, switch-caseに対応
– 合流ポイント
• 複数の制御フローが合流する点
カバレッジ
– レベル０からレベル７まで
・レベル１ テスト対象であるプログラム（モジュール）の中の文が少なくとも１回実行される＝制御フローの丸の部分をすべて通る。
・レベル２ 分岐カバレッジともいう。すべての分岐条件判定に対し，true/false（case)が少なくとも１回ずつ評価されるように実行＝制御フローの矢印をすべて通る。
・レベル3 条件（コンディション）カバレッジともいう。すべての条件が少なくとも１回ずつtrue/falseに評価されるよう実行。 条件節中に複合条件がある場合、各条件が少なくとも１回ずつtrue/falseになるようにする。
・レベル４ 分岐／条件カバレッジともいう。 分岐の各出口を少なくとも１回ずつ通過し，かつ分岐内の各条件が少なくとも１回ずつtrue/falseと評価されるように実行
・レベル５ 複合条件カバレッジともいう。 複合条件がどのように評価されるかを加味して実行。 制御フローグラフをコンパイラの評価方法を加味して再構成し，分岐／条件カバレッジを達成するテスト入力を選択。
・レベル６ パスカバレッジ（制限付き）と考えられる。 繰り返しの存在がテストケースの作成が不可能になってしまう。→ 厳密なレベル７から繰り返し回数を制限する。最小回数（と繰り返しなし）、典型的な繰り返し回数、最大回数（とその前後）など
・レベル７ パスカバレッジともいう。 制御フローグラフ内のすべての経路（パス；path）を通過するように実行。 各判定ポイントでのtrue/falseの全組み合わせを実現するテスト入力を選択。ループがある場合は、組み合わせが無数になってしまうため、100%のカバレッジを達成することは不可能。
カバレッジ率
制御フローグラフ中でテストしたいカバレッジレベルをどの程度達成したかを表す。
例• C0カバレッジ50% などと表す。
開発前に、どの程度のカバレッジ率を目指すのか決める。
ソフトウェア工学 ブラックボックステスト2
前回
ディシジョンテーブルテスト（decision table testing）
条件によって振る舞いが異なるシステムの振る舞いを確認する。その条件を書いたものがディシジョンテーブル。複雑なルールが少数存在する場合に有効な方法。
ディシジョンテーブル
– 条件の集合とビジネスルールの組み合わせ表
– システムの内部動作を表す
ディシジョンテーブルからテストケースの生成する。
テストケース
– 二値条件の場合，そのままテストケースに
– 多値条件の場合，境界値分析の考え方を統合
※ ルール数が多い場合には表・テストケースの作成が困難
※ ディシジョンテーブルが存在しない場合，テスト担当者が作成しなければならない
ペア構成テスト（pairwise testing）
入力変数と値の数の組み合わせが多い場合に有効に場合に有効なテスト。 テストケース数を大幅に削減可能。
– 例：Webサイトの互換性テスト
• クライアント（ブラウザ）とそのＯＳ，プラグインの種類，サーバとそのＯＳ，・・・の組み合わせが発生し、入力のサブセットを選択する必要がある。
– できるだけ故障が発見できるサブセットの選択する。
→「すべての『変数値のペア』」をテスト
ペア構成テストの例：Webサイトの互換性
さまざまなクライアント・サーバの組み合わせでWebページが正常に見えるかテストしたいという状況を考える。
■変数と取りうる値
– クライアント（IE, Firefox, Opera）
– クライアントＯＳ（Windows, Mac, Linux）
– サーバ（apache, IIS）
– サーバＯＳ（Windows, SunOS, Linux）
– すべての組み合わせ：３×３×２×３＝５４通り
直交表の利用（実験計画法: 医薬品の臨床試験）をして、テストケースを作成する。
– 直交表とは・・任意の２列にすべての組み合わせが出現する表
– 例：１，２，３のペア
→９行４列の直交表: L9(3^4) 変数のとる値がより小さい直交表を選び、余ったところには任意の値を入れる（Don’t care)
入力変数を識別するのに必要な最小の直交表に入力値を割り当てる
– これをテストケース（入力）とする
– 期待出力は別途必要
テストケース数は５４から９に削減
※直交表の代わりに全ペアアルゴリズムを用いることもできる（参考： http://www.satisfice.com/tools.shtml）
※入力される値に依存関係がある場合には，さらにテストケース数を減らすことができる• テストケース数を大幅に削減可能
状態遷移テスト（state transition testing）
システムの状態遷移仕様に基づくテスト。 ステートチャート（状態遷移図）や 状態遷移表（状態とイベント，アクションの組み合わせ表）が記述できることが条件。
– テストケースのレベル
レベル1： すべての状態を少なくとも１回訪れる
レベル2： すべてのイベントが少なくとも１回起動される
レベル3：すべての遷移が少なくとも１回行われる
レベル4：すべてのパスが少なくとも１回実行される
– ループがあると、無限個のテストケースとなる
– 無効パスのテスト
• システムに求められるディペンダビリティに応じて
※システム外部からのイベントにシステムが応答する必要のない場合には適用できない
例：事務文書（伝票）の定型処理，など
ドメイン分析テスト（domain analysis testing）
複数の変数を同時にテストしたい（テストすべき）場合に有効。 同値クラス・境界値テストを多次元に拡張・一般化したもの。複数の変数を効率上の理由（テストを減らしたい），あるいは変数の相関関係を検証する目的f不等式で表せるような制約があるとき）変数間にで同時にテストする場合に有効。 変数値が数値をとる場合にもっとも有効
文字列やブール値などにも一般化可能。
変数がｎある時、値はｎ次元空間を動くと考える。変数が動ける空間のことをドメインという。
– onポイント：境界上の値
– offポイント： 境界に隣接する値
– inポイント： 境界条件を満たすが境界上にはない値
– outポイント：いずれの境界条件も満たさない値
ポイントの分析
– 境界上のポイントがドメイン内（境界条件が、A ≦10など’閉じている’場合）
• onポイントは境界上でドメインに含まれる
• offポイントはドメイン境界の外側にある
– 境界上のポイントはドメイン外（境界条件が、A ＜10など’開いている’場合）
• onポイントは境界上でドメインに含まれない
• offポイントはドメイン境界の内側にある
ドメイン分析テストケースの作成
– それぞれの不等式条件に対し，onポイントとoffポイントを各１個ずつ
– それぞれの等式条件に対し，onポイントを１個，offポイントを２個ずつ（onポイントより少し大きい値，少し小さい値）
– 表を用いたテストケース作成の補助
ドメインテストマトリクス
ユースケーステスト（usecase testing）
主にシステムテスト，受け入れテストのレベルでのテストに向く。ユースケースは抽象度の高い記法であり，入力・出力の選び方が難しい（テストの有効性を左右す
る）可能性が高い。ユースケースであらわされる典型的で抽象度の高いトランザクションのみをテストする。 テストが網羅するのも代表例のみなので細部の条件などは網羅できない。
設計戦略としてユースケースの優先度付けをして行う。
– 頻繁に使われるユースケースのテストを行う
– 入力は同値クラス分析や境界値分析に基づいて選択
– 基本系列のテストケースを作成
- 繰り返し系列の場合，何度かループを通過
– 代替系列のテストケースを作成
- 境界値・無効値/offポイントなどを入力
– アンチシナリオのテストケースを作成（想定外のエラーが発生するなどのシナリオ）
安全性・セキュリティに関わるテストもここに含まれる。
災害・防災学 ハザードマップを見るときの注意点
素因と誘引
自然災害には素因と誘引がある。
素因ーその土地が持っている災害に関わる性質（地質、気候、地形、人口など）。
誘引ー災害を発生させる直接的な日来がけ（地震、豪雨、津波など）。Hazardとほぼ同じ。
素因 ＋ 誘引 ＝ 災害
誘引が激しいだけでは災害は起きない。
思いもよらないところで災害発生はあまりない。誘引の予測は難しい一方で、ここではこんな災害が起こりうるということ（素因）はある程度分かる（ハザードマップ、地形分類図など）。水防法、土砂災害防止法等でハザードマップの整備は飛躍的に進んだ。
ハザードマップとは
発生の予想される自然災害について、その被害の及ぶ範囲、被害の程度、さらに非難の道筋、避難場所等を表した地図、災害予測図（デジタル大辞林）
上記のように、ハザードと避難に関する情報が載っている地図。しかし、いろんな種類のハザードマップが実際にはあり、ハザードのみを記しているものもある。
ハザードマップを見るときの注意点
・家一軒ごとの危険性の違いを表現できるような精度はない。
・計算の条件次第でも大きく変わるので新しいものが古いものよりよいということもない。
・起こりうる複数のケースが重ねて表示されていることもあるが、すべてが同時発生するわけではない。
・色が塗られていないところは安全とは言えない。
ー洪水 中小河川では、浸水想定自体が行われていないこともある。
ー土砂 地形的に危険性があっても住家等がなければ危険個所には指定されない。
新規開発地域では危険が変化する場合もある。
精度
精度とはいいかえれば、誤差やばらつきが小さいということである。
ハザードマップにも”精度”がある。例えば、国土交通省のハザードマップのあるデータソースには ”1/25000地形図程度の精度”とある。これは、基盤地図情報によれば、以下表のようになる。
| 都市計画区域内 | 都市計画区域外 | |
|---|---|---|
| 平面位置の誤差 | 2.5メートル以内 | 25メートル以内 |
| 高さの誤差 | 1.0メートル以内 |
5.0メートル以内 |
地図上のどこが都市計画区域内か一般の人にはわからないので、大きな誤差の方を見る。
ハザードマップには地図の上にハザードが重ね合わせられているが、地図の精度とハザードの精度は異なることがほとんど。だから、ハザードマップを拡大して家屋一軒ごとの危険性の有無を厳格に読み取るような使い方は適切でない。
（こうした、ハザードマップの誤差に関する知識は一般にはあまり知られていない）
反面教師にしたい論文ー人工知能初期の2008年論文
原文 Prediction of the intern parameters tomato greenhouse in a semi-arid area using a time-series model of artificial neural networks
訳【人工ニューラルネットワークの時系列モデルを用いた半乾燥地域におけるトマト温室内の内部パラメータの予測】
時系列の現実データをどのように扱っていったのかをメインにまとめたいと思ったのですが、読み進めていくと、”人工知能”の初期の論文であったためか、まとめ方が非常にラフで参考になりませんでした。
こういう論文書いてはいけないなと思ったので反面教師として途中まで読んだ分のメモです。
論文の狙い
論文の書かれた2008年当時に流行り初めていた”人工知能”を使って、外気象のデータを使って、ハウス内の温度と湿度が予測できることを示しています。
いわゆる「やってみた」系であると思います。
収集データ
外環境は、ハウスの２ｍ上に設置されたセンサーによって以下の項目を収集
- 温度Tと周囲の空気の水分M
- 温室内の外気の速度Vと風向Dw
- 温室外の全放射量Rt
- 温室外の地面の温度
ハウス内では
-温度
-湿度
が計測された
前処理（pre-treatment)
次の式で0.1-0.9の間で正規化を行った。
よくある"min-max normalization"ではβの後ろの部分のみを用いますが、αとβを設定することで敢えて0.1-0.9の間に値が収まるようにしたようです。この意図は私の知識不足でわかりません・・。誰かわかりましたら教えてください。
モデルの選択
3月25日から31日までのデータをテストモデル用に、3月3日から24日までの残りのデータを残りの3月3日から3月24日までのデータはトレーニングモデルに使用し,MRW, MAE, SE, MQE, R^2が小さくなるようなモデルを選択したとのことで、詳細は語られていません。。
結果
学習データの集計単位についても明らかにされていないのですが、1時点先の予測をしたところ、R^2＝0.991の予測が得られたということで、かなり直近の予測をしていたのではないかと思います。
論文を書く際の反面教師としての学び
あまり良論文ではありませんでした。反面教師ですね。。。
・まず、論文としての意義や目的があいまいでした。何に課題を感じているのか？何を解決しようとしているのか読者にわかるようにする。
・なぜ、そのような処理や方法をとることにしたのか、独自性はどんなところなのか、わかるようにする。
・データをどんな単位で記録し、集計したのかわかるようにする。
・モデル選定に関しては適当にやってみたで選択するのではなく、理論ベースで展開する。
災害・防災学ー風水害２
大雨によって生じる現象
大雨それ自体で人が死ぬということはない、大雨が起こす現象によって災害が発生する。
洪水
河川洪水
河川の水位が上昇し、破堤や越流が遅り、河川水が河道外へあふれること。
高水敷に公園や駐車場、畑があり、そこに水がくることを災害のように言うことがあるが、高水敷は”川”の一部なので、そこに水がくることはいわば”当たり前”のこと。
内水氾濫
破堤、堤防からの越流はなく、流域から集まった水が排水できずたまる。
水の力は 水深×流れの速さ
だから、何センチまでの水深であれば安全ということは言えない。
土砂移動現象 Mass Movement
斜面崩壊（崖くずれ）
地中にしみ込んだ水分が土の抵抗力を弱め、雨や地震などの影響によって急激に斜面が崩れ落ちること。崖崩れで土砂が到達する範囲はげ家の高さの1倍以内のことが9割。長くても3倍以内。崖の傾斜が30度以上だと土砂災害警戒区域となる。
地すべり
比較的緩い斜面で、低速でその地域まるごとずるずると動いていく。普通は数㎝/日以下。一時的に高速化するときでも歩行速度程度。活動は長期。発生場所は地質によって限定される。
土石流
土砂、石礫と水が混合して一体となって流れ下る現象。長距離、高速（数百～数千ｍ、数十km/ｈ）。流れが速いので、谷底にいたとして土石流を目視してから川から直交する方向に逃げたとしても助からないかもしれない。
災害・防災学ー風水害1 災害統計を見るときの注意点
前回
風水害
「自然災害」の1つ。強風、大雨、および高潮、波浪により起こる災害の総称（気象庁）。多くの場合、風と雨は一緒に起こる。
大雨・豪雨ー災害が発生する可能性のある雨。（大雨と豪雨の明確は違いはなく、降雨量の定義もない。）
地震による犠牲者は毎年いないが、風水害の犠牲者は毎年いる。→身近、リスクが高い災害と考えられる。
事例
①2019年台風19号 死者・行方不明者87人（直接死のみ）（消防庁）
洪水で家が流された家屋は限定的だが、流されていない家屋の屋内で浸水でなくなっているケースが多い。
もう一つ特徴的だったのが、自動車移動中の被災（27人）。25人は水関連で亡くなった。
浸水想定区域内での犠牲者発生が7割。「想定外」の場所で多く被災しているわけではない。
②平成30年（2018年）7月豪雨 死者・行方不明者230人（直接死のみ）（消防庁）
広域で土砂災害（犠牲者に5割）、洪水災害（犠牲者の4割）があった。
岡山県の真備町では51人が屋内で死亡しているが、家屋が流されたのは3か所。
深い浸水(5ｍ）があったが国土交通省のハザードマップでは5ｍ以上の浸水が想定されており、「想定外」ではなかった。
③平成29年（2017年）7月九州北豪雨 死者・行方不明者43人（直接死のみ）（消防庁）
山地河川の洪水（＝深さがあり流速が早い＝押し流す力が強い）の被害。川の位置が変わってしまうような山地河川の洪水では家屋が流される。
④2016年台風10号 死者・行方不明者27人（直接死のみ）（消防庁）
主に山地河川の洪水。
⑤平成27年（2015年）9月関東・東北豪雨 死者・行方不明者8人（直接死のみ）（消防庁）
広域な平野部の河川洪水（堤防氾濫）。数千規模での家屋の浸水があった。
⑥平成26年（2014年）8月豪雨 死者・行方不明者74人（直接死のみ）（消防庁）
土砂災害が広島市の八木という地域の狭い範囲で土砂災害が生じ、死者74人が亡くなった。
⑦昭和57年（1982年）7月豪雨 死者・行方不明者330人（直接死のみ）（消防庁）
⑧昭和47年（1972年）7月豪雨 死者・行方不明者458人（直接死のみ）（消防庁）
1回目の斜面崩壊で生き埋めになった人を助けるために救助に入った人を2回目の斜面崩壊が襲い、二次被害によって多くの犠牲者が出た。
災害の統計を見るときの注意
災害の統計を見るときには
・災害統計は時間とともに変化する
・統計にカウントされる基準は時代とともに変化する
ということに留意する必要がある。
例として以下をみてもらいたい。
令和元年8月27日からの大雨の建物被害の報告数について消防庁の発表情報を時系列に追っていくと以下のような報告の推移となっていた。
災害発生から1カ月近く経つと床上浸水が減り、半壊の報告数が多くなっていくことから、床上浸水から半壊へ判定が変更されるようだということが分かる。
出典：消防庁
令和3年5月時点の水害における被害基準はこちら
http://www.bousai.go.jp/taisaku/pdf/r303shishin_3.pdf
また、全壊か半壊かの基準が時代とともに変更され（近年は基準を低くする傾向にある）ため、過去の災害と被害規模を比較するには、床上浸水以上の被害の総計値で比較する必要がある。こうした統計上の基準が変遷していることは一般に知られていないことであり、特に留意が必要。
これは、死者・行方不明者についても同様のことがいえ、災害発生の1カ月以降からは行方不明者が減り、死者・行方不明者の総計も減少する傾向がある。
