備忘ぶ録-新犬小屋

ココログ「備忘ぶ録(https://kotatuinu.cocolog-nifty.com/blog/)」のコピー場所です。

ユニットテストについて

ウチのチームでユニットテストレベルの不具合が摘出されておらず、システムテスト終わりに見つかってしまうという問題が発生している。
そこで、ユニットテストの考え方を書き出してみる。

  • ユニットテストの目的は、詳細設計書(クラス・関数についての設計書)の仕様を満たしているか動作確認を行う事。
  • 詳細設計書は、関数についての仕様を記述してある。入力に対してなにがしか処理を行った結果、出力を行うのが関数の役割。
    入力値に対して出力値を確認するのが、ブラックボックステスト
    関数内の分岐を考慮して、そのケースを確認するのがホワイトボックステスト。if文の条件式で真偽値となるケースを確認するとか。
  • テストの指標としてカバレッジ(網羅性)がある。C0/C1/C2=命令網羅/分岐網羅/条件網羅。
    目指したいのは分岐条件の条件式毎の確認を行う条件網羅。(if(A==1 && B==2) とあったら、Aが1、1以外×Bが2、2以外の4パターンを確認する)
    • 条件網羅は、条件式が多くなると組み合わせが爆発的に多くなり、工数が膨らむ。
      項目数を減らす考え方にAll-Pair法(ペアワイズ法)がある。関数の引数が複数ある場合、引数2つ一組で見てその値の組み合わせがテスト項目のどこかで出現されるようにするもの。全組み合わせではなく2引数の組み合わせというところがミソ。2引数の組み合わせで7・8割は問題を摘出できるという統計から求めたブラックボックス的手法。
      • 引数:A,B,C,Dがそれぞれ0~2の値をとる場合、AB,AC,AD,BC,BD,CD の組み合わせに対して、2引数が取りうる組み合わせ00,01,02,10,11,12,20,21,22 を、ABCDで組み合わせる。
        すると、以下の9通りに収束できる。
        A B C D
        0 0 0 0
        0 1 1 1
        0 2 2 2
        1 0 2 1
        1 1 0 2
        1 2 1 0
        2 0 1 2
        2 1 2 0
        2 2 0 1

        上記は9パターンであるが、全パターンを組み合わせると3^4=81パターン必要となる。
        全て確認してコストに見合うかどうかという話。
        件数を減らすにも、根拠と理由を持って必要がある。

  • ユニットテストは関数を対象とした物なので、関数内の処理が複雑になるほどテストも複雑になる。
    よって、複雑なチェック条件は一つの関数に入れるのではなく、別の判定関数に切り出す。その判定関数を使用する所は真偽を確認するだけでよくなる。
  • 既存関数の修正を行うときに、正常に動いている所を修正するのは怖い事(動いている物は、触らなければそのまま動く」という考え)ではあるが、修正するのはもう仕様が変わってしまって、それは正しく動かないことなので(だから修正する)わかりやすく書き換える方が保守性を考慮すると今後の修正コストが下がる。怖いのは分るが、だからテストを正しく行って確認する。
  • ユニットテストがやりやすくなる関数を作る事。これは、単純なテストデータで、ユニットテストが出来る事を目指せば良い。
    つまり、関数を作ってテストを作るのでは無く、テストを考えて関数を(分割して)作る事を考える。(動く関数を作ってから分割するでもよいか)

★テストは品質を上げる作業ではなく、品質が悪い所とその傾向を洗い出すための作業です。
→テストの結果を受けて、どこにどの様な問題が多いか、どうしてそのような問題を起こしたかを確認し、その問題の傾向から品質向上施策を考えてバグを潰していきます。

★テストはただ実行するものではありません。
 ・入力値→[処理]→出力値[結果]を確認するものです。
 ・処理を実行して落ちなければいいという物ではありません。入力値に対応する結果を確認してください!
 ・入力値は、条件を分岐する全てのケースを確認してください、if文の分岐を通ればいい物ではありません!