今週の金曜にShibuya.tracに参加しようと思います。
手ぶらで参加するのもあれなので、この3ヶ月ほどTestLinkを使って気づいたことをまとめようと思います。
使ったきっかけ
テスターの要員確保してないプロジェクトで、いきなりテストしてくれって言われてどうしようかと悩んでいたときに、「そういや昔TestLinkってのをブックマークしたっけ」と思い出し、使ってみようと思ったのが始まり。
書き方メモ
tracとの対応
- tracのコンポーネントとトップレベルスイートを大体1:1対応させる。
- trac上でタスクとして定義しているチケットごとにテストスイートを作成する。
- テストケースには以下の内容を書く。
- 概要:対応するチケットへのリンク貼るだけでいい。補足説明いるなら追加。
- 実行方法:どのユーザでログインするか、どのブラウザを使うか、どのオブジェクトを対象にアクセスするかを明確に書く。例) IE6を使い、ユーザ user01 でログイン。
にアクセスし、「ブログを編集する」ボタンを押す。 - 期待結果:どういう現象が起きれば成功なのか明確に書く。先の例を元にすると、「ブログを編集する」ボタンを押して、「編集できません」エラーが表示されても、もしかしたらそのブログは user02 のもののためエラーが出ることが成功かもしれない。余裕があればどの仕様書の何ページに根拠があるか書いてもいい。あれば便利だがこれやるとケースの作成時間・修正時間がひどいことになる。第一現行のTestLinkは大量のテストケースの作成・編集には向かない。
- 失敗した場合のtracへのチケット登録は以下のように。
- 説明にはテストケースの番号と、できればURL必須。TestLinkはフレーム使ってるのでURL取得が面倒。
- 実行環境(ブラウザなどの自分の環境や、テストしたリビジョン番号等)、再現方法(ケースの実行方法のコピペでいい)、現象、本来あるべき動作(これも期待結果のコピペ)を書く。
ケース書いてから実行まで
- ケースを作成するのは「仕様」だが、テストケースの追加やテスターアサインはトップページから行う。初めわからなくてめっさ苦労した。
- ケース追加やアサイン時、一度に大量に表示すると重くなる。体感で、1000件ぐらい同時表示するとお茶を飲んで待つ程度。一斉チェックを押すときも同様。
実行時の注意
- リビジョン番号は正確に記載しておくこと。
- リビジョン番号を更新すると、一見テストケースの実行記録がリセットされているように見えるが、記録はちゃんと残ってるので安心していい。どこまでやったのかが分かりにくいが。(本当はリビジョンごとにテストケースやり直さなきゃいけないから、TestLinkのこの動作の方が正しいんだけどね)
結果の閲覧
All-pair法
- 最近一番仲良しな友達。
- 「テストって全部の入力項目の組み合わせ網羅しようと思ったら天文学的数字になってやばいよね」→「でも2つ以下の要因で起きるバグがほとんどらしいよ」→「じゃあ全ての項目のペアだけ網羅すりゃいいんじゃね？」という、楽して最大の効果を発揮したい感あふれるなんとも私好みなモデル。
- 真面目な解説はこちらが詳しい。第1回 組み合わせテストの技法：組み合わせテストをオールペア法でスピーディに！｜gihyo.jp … 技術評論社
- TestLinkとの連携にgaryoさんのツールを使っている。ただしちょっと改造している。
- 入力項目の表が、1行目:項目名、2行目:値となっているのを行列変換した。1行ごとに1項目と値が表示される。
- 「概要」「詳細」「期待結果」もそれぞれのテストケースに記入するようにした。
- そのうち公開しようかと思ったが、何とも使いにくいのでどうしたものか。
All-pair法の数学的な話
電車の中とかで暇なときに考えてたことのまとめ。
きっとどこかで誰かが研究してるんだけど、見つからない。
入力項目の種類の数を m とする。
ここで、全ての入力項目において選択肢(ここではスイッチと呼ぶ)の数が等しいケースを考える。
スイッチの数を n とし、全てのペアの数を P(m,n)とすると、
P(m,n) = (nC1)^2 * mC2
= n^2 * m * (m-1) / 2
特に n=2 の場合(全ての入力項目がオン/オフの場合など)、P(m,2)=2m(m-1)。
P(m,n)を網羅できる最小のテストケースの数を T(m,n) とする。
一つのケース内で、異なる2つの入力項目による組み合わせは1つしか消化できないため、T(m,n)は異なる2つの入力項目の全組み合わせの数を下回ることがない(これ重要)。
また、各テストケースで1つのペアを消化するケースを考えれば、P(m,n) を上回ることもない。
よって、
n^2 <= T(m,n) <= P(m,n)
もう一度 n=2 の場合について考える。
スイッチが○と×しかないとする。
このとき、以下のテストケースを用意すれば全てのペアを網羅することができる。
- 全てが○のケース(1ケース)
- 全てが×のケース(1ケース)
- 一つだけ○で、他が全て×のケース(mケース)
よって、以下の式が成り立つ。
4 <= T(m,2) <= m+2
ここまでの話から以下のような情報が出てくる。
- いくらallpair法を使っても、テストケースの最小の数は決まっている。それは、「入力項目のうち最もスイッチが多い項目と、2番目にスイッチが多い項目の全ての組み合わせの数」である。試してもらえればわかるが、他の入力項目のスイッチがどれだけ少なくても、2つだけスイッチ数30とかあると、もうそれだけでテストケースは1000近くになる。
- スイッチがオンオフだけの場合、テストケースが入力項目の数を超えることがない。例えば100個の入力項目があれば、テストするペアの数は単純計算で2^100だが、テストケースの数は102で済む。
私の場合、ケース数に対し支配的な入力項目のスイッチがどうしても減らせず、かつ時間がない場合は思い切ってペア網羅度の低い項目はテストをはしょったりする。入力項目やスイッチの数にもよるが、数個の入力項目のスイッチだけが極端に多い場合はペア網羅数の多いケース上位20%ぐらいで50%のペアを網羅できたりする(50%のテストケースでペア8割ぐらい網羅)。幸いallpair生成ツールはペア網羅数順にソートしてあるので、下半分ぐらい削ってしまえば最低限のテストはできたりする。あくまでどうしても時間ないときの緊急措置だが。
