技術とか戦略とか

IT技術者が技術や戦略について書くブログです。

情報処理技術者試験対策「ブラックボックステストのテストケース設定」

目次

https://1drv.ms/b/s!AivF3bzWXOzuhG1Xk5hscKYqkLkM

-------------------------------
前回の記事で予告した通り、今回はブラックボックステストの話をします。
 
ある変数の値の大小により分岐が行われる場合に、下記の2つの考え方によりテスト設計を行います。

  • 同値分割
    各々の分岐先について、任意の値を一つ抽出し代表値として採用する。
    (怖い上司度≧6か否かで分岐が行われる場合、怖い上司度が5以下の任意の値のケースと、怖い上司度が6以上の任意の値のケースでテストする)
  • 境界値分析
    分岐先が変わる境界となる値を代表値として採用する。
    (怖い上司度≧6か否かで分岐が行われる場合、怖い上司度=5のケースと怖い上司度=6のケースでテストする)

 

試験対策としては以上を覚えておけば良いのですが、バグは境界値で起こる可能性が高いことから、実務では境界値分析しか使いません。
また、テストケースも2ケースでは不十分で、実務では定数項-1、定数項と同じ、定数項+1の3ケースでテストすることが望ましいです。
(コーディングミスで≧を=と書いてしまった場合に、2ケースでは見つからないことがあります(というかありました)。怖い上司度の例だと、怖い上司度=7のケースをテストしないとミスが見つかりません。)
 
前回の記事の繰り返しになるのですが、実務では複数の判定条件の組み合わせを考える必要がある場合があります。
この場合、組み合わせを漏らさないようにするためには、デシジョンテーブルを作成することが有効です。
例えば、以下のような例の場合、

f:id:akira2kun:20180704231623j:plain

以下のようにデシジョンテーブルを作る必要があります。
(3×2×2=12通りの組み合わせを記述)f:id:akira2kun:20180704232428j:plain

実際に全ての組み合わせをテストするわけではないですし、実際にはデシジョンテーブル作成時にいくつかのケースを端折ったりするのですが、慣れない内は全組み合わせをデシジョンテーブルに書くべきです。
デシジョンテーブルに全組み合わせを記述しておけば、必要なテストケースを選定する時に頭が整理されますし、他の人(先輩や有識者)に見てもらうこともできます。

情報処理技術者試験対策「ホワイトボックステストのテストケース設定」

目次

https://1drv.ms/b/s!AivF3bzWXOzuhG1Xk5hscKYqkLkM

-------------------------------
新人に単体テストを任せると大抵テスト漏れでやらかして同じような指導をしているので…これを期に今まで指導してきた内容を記事として残します。
ブラックボックステストについては次回の記事で説明するとして、今回はホワイトボックステストの話をします。
 
例として、以下のような分岐を考えます。
自分の責任で遅刻した時(迷子や寝坊)に言い訳をする処理です。
f:id:akira2kun:20180704065451j:plain
ホワイトボックステストのテストケースの設定方法としては、以下のものがあります。
・命令網羅
 全ての命令を1回以上実行

・判定条件網羅(分岐網羅)
 全ての経路を1回以上通過
・条件網羅
 判定条件中の全ての条件について真/偽それぞれ実行
・判定条件/条件網羅
 判定条件網羅+条件網羅
・複数条件網羅
 判定条件中の条件の全ての組み合わせを網羅
 
今回の例では、それぞれ以下のようなテストケースの設定となります。
 f:id:akira2kun:20180704065517j:plain
ちなみに、カバレージツールは、テストケースの網羅性を客観的に判断するために使用します。
大抵のカバレージツールでは、C0カバレージとC1カバレージを計測します。
C0は命令網羅、C1は判定条件網羅を計測します。
原則としてカバレージは100%を達成する必要があります。
(ただし、単体テストでは発生しない例外条件がある等の理由で100%を必達としない現場はあります)
しかし、仮にC0・C1が共に100%だったとしても、必要なテストが網羅されたわけではないということは上記の例を見れば明らかだと思います。
バレージ的には、寝坊フラグ=trueのケースをテストしなくてもOKということになってしまいますが、カバレージの結果だけを見て単体テスト完了としてしまうと後で痛い目を見ます。
例えば、いつもの集合場所で待ち合わせる場合にも「いやぁ道が入り組んでて…」という言い訳を返すバグが総合テストで見つかったり…。
そうならないために、プログラムの目的を理解した上で、必要なテストケースを各自の判断で盛り込む必要があります。
 
なお、今回は一つの判定条件に注目しましたが、実際にテストケースを考える時は複数の判定条件の組み合わせを考える必要がある場合もあります。
例えば、以下のような例の場合、怖い上司かどうかで言い訳関数の挙動が変わるかどうかも見る必要が出てきます。
(怖い上司の時にしっかりとした言い訳を返してくれるか気になりますよね…?)

f:id:akira2kun:20180704223851j:plain

ただし、ある判定条件の結果が別の判定条件の結果に影響を及ぼさないなら、判定条件の組み合わせを考える必要がありません。
上の例で怖い上司の判定条件の代わりに今日の運勢の判定条件であれば、(運勢次第で言い訳を変える人でなければ)この2つの判定条件の組み合わせを考える必要はありません。

情報処理技術者試験の出題分野の目次

情報処理技術者試験対策の記事を書くにあたり、ひとまず出題分野の目次を作成しました。

今後、記事を上げる度に、目次にリンクを追加していきます。

https://1drv.ms/b/s!AivF3bzWXOzuhG1Xk5hscKYqkLkM

 

改めて書き出してみると、ハードウェアから経営学まで、本当に広い分野の知識を求められていますね。

これらの出題分野について理解していれば、(IT業界で生きていく上では)どのような業務にあたっても他の人より前の位置からスタートできますし、他の業務の人と話す時にも共通言語で話すことができるようになります。

合格を目的にするのであれば、午前問題でしか問われないような分野や午後の選択式問題で逃げられる分野については過去問を丸暗記するだけで十分なのですが、それでは勿体ないと思っています。