ソフトウェア工学 開発管理
テストのレベルと計画
以下はそれぞれ目的が異なる別々のテスト。一緒くたにはできない。
受入れテスト
– 顧客の要求を満たしているかを確かめる
– 要求獲得・分析工程の成果としてテスト計画ができる
システムテスト
– システム全体として要求仕様を満たすかを確かめる
– 要求分析工程の成果としてテスト計画ができる
統合テスト
– モジュールの組合わせが正しく機能するかを確かめる
– モジュール設計工程の成果としてテスト計画ができる
単体テスト
– モジュールが単体で正しく機能するかを確かめる
– アルゴリズム設計工程の成果としてテスト計画ができる
テスト計画書には規格があり、代表的なものにIEEE829-1988がある。（後述）
テストパラダイム
テストを作成するタイミングには2つの考え方がある。
どちらか1つのみではなく、2つを組み合わせて行うことが現実的。
– 古典的テスト計画（スクリプトテストパラダイム）
システムが出来上がってテストが可能になるずっと以前の段階でテストの手順，テストケース，テスト報告のやり方
などを事前に定義する。テストケースを作ること自体が分析の結果や設計の結果にあいまいな点をなくす効果があるため、テストの計画をできるだけ早い段階で行うことを重視する。
ただし、システム仕様（要求定義）の品質に大きく依
存することや、事前に計画を立てるので柔軟性に欠けること、定型かつ大量のテスト実行により，テストのス
キルを低下させる場合があるなどの欠点がある。
– 適応型テスト計画（探索的テストパラダイム）
• 計画できるときに計画できるところまでを計画
し，計画できるようになるまでは計画しない。
システムの適切な振舞いに対する仮説を作成
→仮説を反証するようなテストをいくつか設計
→それらのテストケースを実行し結果を観察
→仮説に反する結果を評価
→仮説が証明されるか反証されるまで上を繰り返す
これらをテストのみに割り当てられた時間枠（1～２時間）内で集中的に行う。どのテストをどういう順番でテストすべきかが分かっている場合にはかえって非効率になる。
ただし、事前に計画が不在なことから，欠陥を予防する効果は期待できないという欠点がある。
信頼性のメトリクス
信頼度成長曲線
テスト実行週間と発見されたバグの数を記録していくことで、信頼度成長曲線を描くことができ、バグの数が予測できるのでテスト工程をマネージメントするのに役立つ。
信頼性のメトリクスを用いて検証の結果達成される信頼性を測る。測る際に誤差や属人性が少なく、開発対象の品質を代表するものが好ましい。完璧なメトリクスは存在しないので、実際には、いくつかのメトリクスを組み合わせて判断をする。
バグメトリクス
・発見されるバグ（欠陥）の数
– 時間経過に従って累積
– ある期間毎の発見数
– 重要度別に分類
– モジュール別に分類（ＬＯＣごとに正規化）
など
・バグの修正に必要な時間
– 平均バグ修正時間
コードカバレッジメトリクス
・文カバレッジ（Ｃ０），分岐カバレッジ（Ｃ１）などの基準に従ってどれだけ網羅的にテストされているか
– 時系列に沿って計測
– 単調増加ではない場合もある
・特定のテストケース集合のどれくらいの割合を通過したか
ソースコードメトリクス
・行数（ＬＯＣ）とそれに関わるメトリクス
– バグ密度（千行あたりいくつのバグが潜む？）
バグの数／ＫＬＯＣ
複雑度メトリクス
複雑なプログラムほどバグが出やすいため、複雑度を図り、テストを慎重に行う目安になる。
・サイクロマチック数
– １～１０：シンプルなプログラム，バグのリスクはほとんどない
– １１～２０：多少複雑で，バグのリスクが存在
– ２１～５０：複雑，バグのリスクが高い
– ５１～：管理・テストは不可能，バグのリスクが著しく高い
テストの終了判定
どこまでテストすればよいのか？テストにはキリがない。テストする前にテストの終了基準を設ける。
• カバレッジの目標値
• 欠陥検出率
• 限界コスト
• チームの合意
• その他の要因
テスト文章
テスト文書の標準規格（IEEE829-1988）より、ソフトウェアテストで利用可能な八つの文書
– テスト計画書 テストのレベルごとに作られる。
– テスト設計仕様書 テスト項目ごとに作られ、テストの集合が作られる。
– テストケース仕様書 テスト項目をテストケースにする。
– テスト手順書
– テスト項目移管レポート
– テストログ タイムスタンプ、誰が何をやって合格したか？
– テスト不具合レポート テストに合格しなかった場合
– テストサマリレポート テスト実行割合、合格割合など
これらの文章はテスト管理ソフトで管理されることが多い。バグトラッキング機能などと連携し文章作成の支援機能がある。
ソフトウェア工学 仕様の検証
レビュー（見直し：review）
レビューには大きく分けて以下2種類の方法があり、いずれも，主に仕様への準拠性を確認する。 顧客の要求，特に非機能要求の充足を確認することは難しい。仕様（要求定義・設計）やプログラムコードを読み直すことで検証。仕様を見直し、誤りを早めに修正し、品質管理を行う。実践的には、プロジェクトの進捗把握と計画に利用される。
レビューのタイミングはウォーターフォール的でモデルの場合は、フェーズ毎に上流から渡される文書を対象とする。アジャイルなどの発展的開発では、くり返し開発をするたびに見直しをする（１～２週間程度のスパン）。
レビューとテストの技術は補完関係にあり、検証の対象・目的に応じて使い分けが必要となる。
検証の対象が要求仕様・設計などの文書であればレビューしかできない。
プログラムであれば、目的によってレビューでできることもあるが、テストの方が有利なことも多い。
開発プロセスであればレビューでしか検証できない。
レビューの前提
・何が「正しい」のか定義されていないといけない。 正しさを検証するためのチェックリストなどを持ちいる。
・対象となる文書について，必要事項が定められた形式で構造や文法の正しいものが与えられている。 対象の中身の正しさを検証できる状態であること
・開発の管理側（あるいは顧客側）が，レビューによる初期的なコスト増に合意している
・レビュー結果を対象文書の作成者に対する人事的な評価に使わない。（社内の余計な争いを避ける）
インスペクションとウォークスルー
いずれも欠陥を発見する目的で行う。
インスペクション（査閲：inspection）
文書を検査して欠陥を発見する。計画、概要提示、事前検討を受けて行うインスペクション会議を中心とした一連の作業。インスペクション会議は1-2時間で行い、修正に関しては話合わない。
インスペクションへの参加者と役割
作者
– 対象となる文書を作成，あるいはその文書についての責任を持つ。インスペクション会議後、文章を修正する。
読者
– インスペクション会議において文書を読み上げる
インスペクタ
– 文書の欠陥や問題点を見つける
書記
– インスペクション結果を記録する
モデレータ
– インスペクションプロセスの進行を統括管理し，結果をチーフモデレ
ータに報告する
チーフモデレータ
– インスペクションプロセスの改善を図る（チェックリストの更新など）
インスペクションのチェックリストを作成する
ありがちな欠陥のリスト
– ドメイン知識に基づいて作成
• 当該ドメインにおいてなくてはならない要素・見落としがちな要素
• アーキテクチャ設計の妥当性
• システムモデル（構造・振舞い），モジュール設計，アルゴリズム等の常識的なパターン
– プログラミング言語の知識に基づいて作成
• 型・データフロー・依存関係など
• ｃｆ．ホワイトボックステスト，静的解析
ウォークスルー（徒歩検査：walkthrough）
一定のパターンで文書を模擬（机上）実行する
モデル検査検証
システムの振舞い仕様が要求される性質を満たすかどうかを示す。
検証の対象となるシステム
– 通信プロトコル
– 並行・分散システム
↑これらは再現が難しいためテストによる検証が難しい。
振る舞い仕様の検証方法
振舞い仕様を状態遷移システムで記述する。
仕様の満たすべき性質を形式的に記述する。
仕様が性質を満たすことを示す
– 定理証明に基づく（c.f. 正当性証明）
– 状態空間の網羅的な探索に基づく➔モデル検査
モデル検査検証（model checking verification）
状態遷移システムで定まる振舞いから遷移
状況のグラフを作成する。 並行性を持つシステムの場合，複数モデルの直積をとる。
あらゆるイベント系列に対して可能な遷移からグラフを作成していくと合成したシステム全体の状態空間となる。
検証したい性質を時相論理式により記述（時間の要素が入っていることが重要）
– CTL（計算木論理），LTL（線形時相論理），など
状態空間グラフの経路探索により性質の充足・非充足を検査し、経路の確認を行う。
例：「哲学者の食事問題」
ソフトウェア工学 静的検証
プログラムの静的検証（static V&V of program）
検証とは、仕様の検証を行うもので、動的解析と静的解析がある。
静的検証は、正当性の証明を行う。動的検証では、プログラムが完全に正しいことは保証的ない。
正当性証明の手順
①仕様を事前条件と事後条件で記述
②ループに対して不変表明をおく．その他の表明を必要に応じて挿入
③事前条件／事後条件や表明を前後に持つプログラムの実行経路について，経路の先頭
の条件から，最後の条件が導き出されることを証明
– 例：Hoare論理の利用
④プログラムが正しく停止することを証明
Hoare論理
手続き型言語の要素に対して形式的意味を定義する。
すべての原穂は以下4つで表現できると仮定し、表記を置き換えていく。
① 代入文： x := e
代入文の公理（割当公理） {Q[e/x]} x := e {Q}
代入文x := e の実行後に事後条件Qが成り立つためには，事前条件としてQ[e/x]が成り
立っている必要がある
例 – {x+1 = 10} x := x+1 {x = 10}
② if文の規則： if B then S1 else S2 end
（ELSEあり）{P and B} S1 {Q} {P and not B} S2 {Q} / {P} if B then S1 else S2 end {Q}
（ELSEなし）{P and B} S {Q} P and not B ⇒ Q / {P} if B then S end {Q}
③while文の規則： while B do S end
{P and B} S {P} / {P} while B do S end {P and not B}
ループで何もしなくて出てくる場合もあるので、ループ前でも成立するPが肝になる。
④ 複合文： S1; …; Sn
複合文の規則（連結規則）{P} S1 {R1} {R1} S2 {R2} ... {Rn-1} Sn {Q}/{P} S1; S2; ... ; Sn {Q}
⓹帰結の規則
P⇒P1 {P1} S {Q1} Q1⇒Q / {P} S {Q}
※P1の条件をいかに弱い条件にできるかが重要。ー最弱事前条件
※簡単なIF文でも人手でやるのでとても時間がかかる
制御フロー・データフロー解析（control flow/data flow analysis）
・プログラム要素間の依存関係の解析
– 制御的な依存関係
– データの依存関係
・制御フローグラフ
– 制御の依存関係を図示
・データフローグラフ
– データの依存関係を図示
・依存関係の把握
– 変更が影響する範囲の特定
– 誤りの場所や原因の特定
プログラムスライシング（program slicing）
特定の文や変数値に関係するプログラムの部分を抽出したもの。プログラム依存グラフ（PDG）の作成を行う。
コードクローン分析（code clone analysis）
コードクローンとはソースコード中に存在する，全く同一あるいは類似したコード断片のこと。コードクローンは単なるコピー&ペーストによって発生したり、 常套句的なプログラム記述であったり（ 例：ファイルのオープン，データベース接続など）、何らかの意図に基づくなどの理由で発生する。
コードクローンの弊害はソフトウェアの保守が難しくなること。そのため、検証の立場からするとクローンを除去することが重要になる。ーリファクタリングという。
クローンを自動的に見つけようとすると、コードクローンの定義が必要になるが、定義を決めるのは困難。
●コードクローンの検出方法
– 行単位の比較に基づく方法
検出の精度は低いので実用的ではない。：'{', '}' の位置やそれらの有無による違いによっても検出が不可になる。
– 抽象構文木の比較に基づく方法
ソースコードの構文解析結果から抽象構文木（AST: Abstract Syntax Tree)を作成。コンパイラ技術の延長で、商用のツールも存在する。（CloneDR)
– プログラム依存グラフの比較に基づく方法
ソースコードの意味解析結果からプログラム依存グラフ（PDG）を作成
– メトリクスに基づく方法。検出の精度は高いが計算量が膨大。
関数・メソッドの部品単位でメトリクスを計算しメトリクスの値が近いものをコードクローンとして抽出する。
– トークンの比較に基づく方法
ソースコードに出現するトークンの系列を比較し，類似するサブ系列をコードクローンとして検出。適切な精度を保ちながら，大規模なコードの解析にも利用可能。
欠測データ 多重代入法
前回
多重代入法
多重補完法ともいう。
ベイズ理論に基づき何らかの値を補間する方法であり、補間のモデルがいくつかの条件を満たせば、欠測メカニズムがMARの下で妥当性を持つ手法。
欠測値の事後分布からランダム抽出を通じて疑似的な完全データをm組作成する。それを最終的な推定量の標準誤差の推定に反映する。多重代入法の手順は以下3つで構成される。
①補間ステップ ：補間モデルを用いて作成した欠測値の事後予測分布からｍ組のランダムな予測値を欠測に補間し、疑似的な完全データをｍ組作成する。
②解析ステップ ：ｍ組のデータを標準的な統計手法でm回解析する
③併合ステップ ：ｍ組の解析結果を統合する。
解析ステップでは、線形モデル、ロジスティック回帰モデルなどの標準的な統計手法を用いて疑似完全データを解析し、統合を行う。そして、最終的に統合されたパラメータ推定とその標準誤差に基づき統計的推測を行う。
①補間ステップ
データが欠測している変数の型ごとに使用できる補間法が異なるため、補間モデルを選ぶ。
|
欠測パターン |
データが欠測している変数の型 |
補間モデルの表変量の型 |
補間モデル |
|
単調 |
連続型 |
任意 |
・FCS法 ノンパラ：予測平均マッチング ノンパラ：傾向スコア法 |
|
２値データ |
任意 |
・ロジスティック回帰補間法 |
|
|
名義カテゴリカル |
任意 |
・一般化ロジットモデル補完法 |
|
|
非単調 |
連続 |
連続型 任意 |
・マルコフチェーン・モンテカルロ法 ・FCS法 |
②解析ステップ
疑似的な完全データを標準的な統計手法を用いて、パラメーター推定
＝
（
,
)
とその分散
＝
（
,
)
を得る。
③統合ステップ
の単純な算術平均を統合したものが点推定
となる。
の分散
は
(
) =
と推定でできる。
ただし、 は
の共分散行列
の平均である補間ないの分散共分散行列
及び、は
の補間内の分散共分散行列。（いづれも式は省略・・）
となる。
こうした考え方は実験や臨床などサンプリングをするものにはすぐに適応可能だが、時系列の場合にはこの考え方に時系列の特性を加える工夫が必要になる。
それはまた次の記事で。
本記事は以下書籍をもとに勉強しているものです。
欠損データのパターンとメカニズム
(統計解析スタンダード) 阿部 貴行 を参考に勉強していきます。
※この話は、臨床実験などの”経時的”なデータもしくは 複数のグループの差を検討するときに使う手法で、”時系列”データでは扱いが違うようなので注意。
私はこれに気が付かず、やらなくていいことをやってしまいました。
データに欠損があるデータを「不完全データ」という。
データに欠損があると、最小二乗法を用いてパラメータ推定を行うことができないため、データが不完全なレコードは解析から除外する。ただし、除外した解析が妥当性を持つには強い条件（ランダムな欠損であること）が必要なので、もう少し緩い条件下でも妥当性を持つ統計手法が必要になる。
一般的な欠損データの対処法は大きく以下の3つに大別される。
①complete-cace(CC)解析（およびその重み付け解析）
②欠損値を予測値で補完する方法
③不完全データとして尤度を記述する方法
これら手法の詳細は別記事にするとして、その前にやるべきことがある
欠損のパターン
欠損パターンごとに使用できる手法が異なるため、統計解析の前にデータの欠損パターンと欠損の比率をようやくすることが解析の第一歩になる。
単調なパターンと非単調なパターン
，
，
の列を持つ
があるとして、その列と行を入れ替えて、変数を欠損の少ないものから並び替え、レコードも欠損の少ない順から並べ替えたとする。その時このような行列になるものを単調なパターンという。
単調なパターンのイメージです。（絵が雑ですみません）
それ以外の欠損パターンを非単調なパターンと言います。
欠損のメカニズム
次に考えるのは欠陥のメカニズム。
データYを与えたときの欠損の有無を表す２値の確率変数Mの条件付き確率
f(M|Y,Φ）として以下の3つに分類される。
① MCAR (Missing Completely At Random) ：f(M|Y,Φ）＝ f(M|Φ）
すべてのデータに対してランダムに欠損が生じるという最も強い仮定。例えば臨床試験で患者が研究から離脱し、その後の値が欠損した場合、MCARは強すぎる仮定であることが多い。仮にMCARが成り立てば、complete-case(CC)解析はバイアスのない推定値を与える。
②MAR (Missing At Random) ：f(M|Y,Φ）＝ f(M|,Φ）
※は欠損がないデータ
観測されたを与えれば欠損はランダムに生じるというメカニズム。つまり、MARとは、欠損確率を観測されたデータ
で説明できるという条件。実際の研究、およびそのデータ解析では欠損メカニズムがMARであると仮定することが多い。
③MNAR (Missing Not At Random)
観測されたを与えた下でも、データの欠損確率が欠損したデータの値
に依存するというもの。
データの解析者は欠損メカニズムの仮定を選び、その結束メカニズムのもとで適切な手法を用いて統計解析を行う必要がある。
以下に欠損メカニズム事に適切な統計手法を示す。
|
欠損メカニズム |
Yが連即変数 |
Yが2値変数 |
|
MCAR |
１）１時点のデータ ・分散分析モデルのCC解析 ２）経時測定データ ・一般線形混合効果モデル |
１）１時点のデータ ・ロジスティック回帰のCC解析 ２）経時測定データ ・GEE解析 |
|
MAR |
１）１時点のデータ ・EMアルゴリズム ・多重補間法 ２）経時測定データ ・一般線形混合効果モデル ・多重補間法 |
１）１時点のデータ ・多重補間法 ２）経時測定データ ・一般線形混合効果モデル ・多重補間法 ・GEEの重み付け解析 |
|
MNAR |
・選択モデル ・パターン混合モデル |
・選択モデル ・パターン混合モデル |
ソフトウェア工学 動的検証
システムテスト（System Testing）とは
システム全体のテストをする。システム全体での動作を検査，主に例外・異常処理，非機能要求，品質，などを対象とする。（⇔単体テスト、結合テスト）
機能のテストでカバーしきれないところをテストする。
構成テスト（configuration testing）– 異なる構成上での動作に関して
ソフトウェアが保証する動作環境は数多くあるので、効率よくテストするのがポイント。
ー同値クラス分割の利用 いくつかの構成をグループ化して、グループ内は同じだとみなす。
ーペア構成テストの利用
その構成がユーザによく使われるか？その構成とこれまでにテストした構成との差は大きいかなどの情報から、テスト設計者がテストを設計する。
※機能テストが十分終わっていることが条件
負荷テスト（stress testing）– 負荷をかけた時の挙動に関して
短時間に大量のデータの入力，処理の実行， データの出力を行わせ、プログラムのあらゆる部分に負荷をかける。
→長期間にわたる高負荷での稼働をし、メモリリークなどに起因する障害の検出を行う。
※テストは完全に自動化すべきであり通常、自動化ソフトが用いられる。
• 人間が長期間同じように負荷をかけ続けるのは不可能
• 属人性・再現性が得られる
l性能テスト（performance testing）– 性能充足に関して
ソフトウェアの分析・設計段階で想定した性能が期待通り出ているかどうかのチェック。
想定する性能の定義が明確でなくてはいけないので、 定量的な基準による定義が必要。性能要求が満たされないことで大幅な手戻りが発生する場合もあるので、設計の段階からテストをするべき。
■アーキテクチャ検証
– 十分な性能を発揮できる構造になっているか
机上（静的）検査・プロトタイプでのテスト
■性能ベンチマーク
– 開発されたソフトウェアの性能テスト
■性能回帰テスト
– 変更されたソフトウェアの性能テスト
■性能チューニングと受け入れテスト
– 要求される性能を満たすかのテスト
■２４×７性能モニタ
– 実データに似たデータでの模擬運用テスト
利用性テスト（usability testing）– 使いやすさに関して
ＵＩの使い勝手・仕様をテストする。ユーザの側に立ち，ユーザの要求を満たしているかどうかをチェックするので、開発に関わる人間がするべきではない。
セキュリティテスト
機密性・完全性・可用性が保たれること
– 機密性（confidentiality）
• 許可された者だけが特定の情報にアクセスできる
– 完全性（integrity）
• 情報とその処理方法が正確で，完全であること
– 可用性（availability）
• 許可された利用者が，必要とする時に必要とする情報にアクセスできること
悪意のある攻撃なので、通常のテストでは対応できない。
テストの考え方としてはプログラムレベルとシステムレベルの2つに大別できる。
①プログラムレベルで脆弱性を検出
– コードレビュー
• テストでは見つからない脆弱性は多い
–静的解析ツールの利用による支援
– 入力テスト
• 境界値分析などによりテストケースを設計し，徹底的に入力テストを行う
– モジュール指向テスト
• プログラムを部品に分解し，部品ごとに徹底的な入力テストを行う
②システムレベルで攻撃への耐性をテスト
– 実際の攻撃の種類に合わせたテストパターン
• 不正プログラム
– ウィルス，ワームなど
• 情報漏洩，なりすまし，ソーシャルエンジニアリ
ング
• クロスサイトスクリプティング
• クエリインジェクション
• スパイウェア
典型的な攻撃パターン
オーバーフロー
メモリからプログラムを実行することが可能なアーキテクチャの計算機で潜在的に可能。バッファあふれを故意に発生させ、スタック領域中のリターンアドレスを書き換え、任意のプログラムを実行可能にする。
→領域長のチェックを行わないコードが原因。 配列・文字列の長さ、データ長（long/short，float/double）、ライブラリ関数（gets(), sprintf()など）。
フォーマット文字列バグ
フォーマット文字列の直接出力によるスタック情報などの漏洩。
動的にページを構成するWebサイトの入力チェックの甘さを突く攻撃する。 ユーザからの（テキスト）入力をそのままブラウザに表示するWebサイト
例（PHPスクリプト）：
print("入力内容を確認してください．<br />");
print("名前:" . $_POST['name'] . "<br />");
※名前の入力内容にHTMLタグ（ブラウザで解釈される
スクリプト）が含まれていたら？
クエリインジェクション
サーバデータベースと連携する（Web）システムの入力チェックの甘さを突く攻撃
その他のテスト
スモークテスト（smoke test）
ビルドが正常にできているかどうかのテスト。本格的なテストができるのかどうかのテスト。ビルド時のミスによりソフトウェアが動かなくなっていないことを確かめる（ビルド確認テスト）。ハードウェアのテストのときに、電源を入れてテストをするときに煙が出てないか確認するところから来た名前。
回帰テスト（regression testing）
ソフトウェアの修正に伴って行うべきテスト。バグ修正により，関連する他の箇所でバグが発生しないかを確かめる。原則的には、今まで行ったテストをすべてやり直すことになるが、省力化するためには影響範囲を限定することが必要。影響範囲を限定することは難しい問題。
災害情報学 災害と情報
災害情報とは、防災および減災のために必要とされる情報と考えられる。（日本災害情報学会設立趣意書より）
情報とは？
DIKWモデル
単なる「データ」があるだけでは役に立たない。整理されていない情報は理解、学習（＝加工）に多くの時間が必要になる。形がないが、それ自体に価値がある一方で、存在するだけでは使えない。
コミュニケーションモデル
人と人のコミュニケーションには、情報の送り手が伝えたかったメッセージを、メディアを通して受け手が正しく受け取ることが重要。表情や身振り、言語、文字や図などもメディア。送り手と受け手の間で、表現 と文脈(コンテキスト)について、共通の知識･理解が前提として必要になる。
「災害の教訓を生かす」場面で「情報」が不足していたから「情報」を増やすことは正しいか。
例えば雨量計という｢モノ｣を増やしても、「データ」を増やすだけ。どの程度の雨量なら｢大きい(危険)｣のかはその場所によって異なるので「情報～知識」がなければ効果を発揮しない。
また、データ、情報、知識のいずれも、「送り手」が発信されていたとしても、「受け手」が認知･理解･活用しなければ効果を発揮しない。だからメールやSNSなど「メディア」を高度化しても解決するとは限らない。
事例１ 仙北市田沢湖田沢供養佛 雨量の情報はあるのに、受け手が認識しておらず、情報が不足しているとして新たな100台の雨量計の設置を計画した。
事例２ 2016年台風10号災害岩手県岩泉町 IP告知システムを導入していたのに、緊急放送の運用がうまく回っておらず、通常の放送で伝達した。
