単体テストとテストケースの作り方 研修コースに参加してみた

今回参加した研修コースは 単体テストとテストケースの作り方 です。
単体テストにフォーカスされたコース名ですが、参加してみると、そもそも品質とは? というところから、何を指標にどのようにテストするのか体系的に解説いただき、最終的にはテストケースを考え、単体テストを自動でやってみるところまで出来ました。
これから QA チームに入る方や、なんとなくテストケースをこなしていることに疑問を持っている方、体系的に学びたい方にはとてもオススメのコースでした。
では、コース内容をレポートします !
コース情報
想定している受講者 | コースではJavaを使うので、Javaの基本的な実装が出来ることが前提 |
---|---|
受講目標 | 単体テストをする意味を理解し、現場で活用できる知識を身につける |
講師紹介
参加してみたレポートでは初めてとなりますが、 大石 宏一さん が登壇されました。
所属されているクロノスでは、IT教育の責任者を務められ、年間100回以上研修に登壇されています。最近ではAIってなんですか、というテーマでよく講演されているそうです。
SEカレッジではプログラミング、メソドロジの分野で主に登壇頂いていますが、一緒にコース開発など行い、過去にはAR系のハッカソンや最近ではAIに関するコースにもご協力頂いています。
品質計画とは?
まずは参加頂いた受講者の方にアンケートです。
- Quality を挙げられる方が大半
- なぜ難しいのか? -> 指標が無いから
- なぜ測定できないのか? -> 契約書に書かれていない -> テストケースがバラバラになってしまう
品質とは??
- 動作は正しくともATMで振込したら10分かかると、品質が良いとは言えない
- システム・ソフトウェアの特性を実現する必要がある
- パフォーマンス
- 操作性 (操作がわかりやすい)
- セキュリティや信頼性
- 様々にある
- つまりクリティカルな特性をきめる必要がある
- どの項目がないと一番ダメなのか
- 品質モデルを作成する
- 品質モデルの作り方
- 指標となるものはある
- ISO 9126 これは特に重要
システムごとに保証すべき品質は違うので、まずは指標を作り、その達成指標を決めていきます。漠然とバグが無ければ良い、テストケースが全部通ったらOKという訳では無いのですね。
機能要求と非機能要求
その指標を考える上で、参考になるものとして機能要求、非機能要求を挙げていただきました。
- 機能要求と非機能要求は結構あいまい
- 非機能要求はユーザーから出てきにくい // 潜在的に持っている
- 非機能要求グレードというのがある
- 大手6社が作ったものをIPAに譲渡
- 非機能要求の見える化と確認の手段を実現する「非機能要求グレード」の公開:IPA 独立行政法人 情報処理推進機構
ここで問題です。
例として挙げて頂いたインターネットバンキングにおいては、どれが非機能要求でしょうか?
テストの考え方
- ISTQB/JSTQB という団体がテストの一般原則をまとめている
- 初期テスト
- 上流でちゃんとレビューしましょう
- 上流で先にテスト書きましょう
- 全数テストは不可能
- int型が入るフォーム1つとっても無限にテストできる
- 欠陥の偏在
- どれだけユーザーに使われる機能や画面なのか、その使用頻度などでバランスを取りましょう
- 殺虫剤のパラドックス
- いつか虫には効かなくなってくる
- 同じテストだけやっていてもわからなくなる
- テストは条件次第
- 先生個人のテスト結果管理システムなのか、センター試験のシステムなのか
- どこまでテストするかは条件次第
まったく関係ありませんが、名前が秀逸です。名前付けはエンジニアのセンスなのかも知れませんね。
テストで大事なこと
システム・ソフトウェアごとに品質モデルが異なると、独自に作りがちですが、標準化機構や団体が定める基準を使うと、お客様の安心に繋がりそう、という大石さんのお話はとても刺さりました。
単体テスト
ターゲットとなる品質の考え方がわかったところで、いよいよ具体的な単体テストについてです。
- 単体という粒度は決まってない (!!)
- 例えば、リクエスト・レスポンスまでなのかなど
- プロジェクトそれぞれで決める
- 単体が決まらないと結合も決まらない
- 一般的にはファイルごと、ユニットごとにやる
- 全般的に異常系のテストが少なくなる…
- 自分が作ったプログラムは自分がテストすることが多い
- テストするときは大丈夫だろうと思わない、 ぶっ壊そう とするマインドセットが必要
- デバッグのときは動けーと思いながらやってるが、テストは逆
確かに言われてみると、単体という単位は曖昧です。例えば、Pull Request やコミット一つとってもその粒度が開発者によって曖昧なので、テストの粒度も曖昧になりがちですね。
単体テストのやりかた
簡単にテストのやり方を解説して頂きました。
- テストダブル
- APIや他の機能とのデータの受け渡しで使用
- ドライバとスタブ
- ホワイトボックステスト
- 命令網羅 (C0) / 分岐網羅 (C1) / 条件網羅 (C2)
- プログラム構造に基づいたテスト
- 条件網羅が難しいが、目視では出来ない。。テスト自動化が得意
- ブラックボックステスト
- 値を突っ込んでやるテスト
- 同値分割 / 境界値分析
- デシジョンテーブル
- 例えば料金プランごとの機能制限など
- 異常系を補う エラー推測
- スペースやnull値
- 例えばうるう年とか記号とか
テストケースのチェックシート
単体テストを行う人によってやり方はマチマチになってしまうので、このチェックシートを渡してやってもらうのがとても良いとのことで、これは便利ですね。
(演習) テスト仕様に基づいてテストケースを考えてみる
実際に下の仕様に基づいて、実際にテストケースを考える演習です。
ここでは品質の基準づくりをやってみたい方、テストケースを書いてみたい方と、個人個人のご希望に合わせて演習いただきました。
品質の基準づくりをやってみたい方向け
解説 ~副特性の解説と観点の例
副特性 | 説明 | 観点(例) |
---|---|---|
成熟度 | 障害が発生した時にソフトウェアが故障(機能停止しない能力 MTBF(平均故障間隔) |
・MTBFは8000時間以上であること |
フォールトトレランス | 障害が起きてもソフトウェアが機能を提供し続ける能力 | ・各コンポーネントは多重化され、いずれかのコンポーネントに障害が起きてもサービスを24時間提供できること |
復元力 | 障害が発生した後にソフトウェアの機能が正常に復帰する能力 MTTR(平均復旧時間) |
・DBとの接続エラーが発生した場合、再接続し10分以内に復帰すること |
信頼性関連適法性 | 信頼性に関する法規、業界標準、規格にソフトウェアが沿っているかを表す | ・「ASP・SaaSの安全・信頼性に係る情報開示認定制度」に準拠しているか |
品質基準づくりワークシート
副特性 | 観点 | 単体テストのメトリクス |
---|---|---|
成熟度 | ||
フォールトトレランス | ||
復元力 | ||
信賴性関連適法性 |
テストケースを書いてみたい方向け
テスト自動化
最後にテスト自動化です。
わかりやすい逸話を大石さんからいただきました。
「テストケースが100個あって、99個通ったけど、1個落ちたら?」 -> テスト自動化しましょう。
ただ、、、テストを書くコストとそれがペイできるかはバランス次第です。が、運用保守まで全部やるのであれば絶対やったほうがよいとのことです。
はい、デグレが起きるたびに思いますよね、テスト自動化して CI したい。したい。。。
テスト自動化をやってみよう
というわけで、テストケースをもとに実際にテストプログラムを書いて、JUnitを実行してみます。
仕様
コード
import java.math.BigDecimal;
public class Calculator {
public static int calc (int price, price, int count) throws Exception {
if (count > 1) {
return price * count;
}
throw new Exception();
}
public static int discount(int price, int count) throws Exception {
return new BigDecimal BigDecimal(calc (price, count)).multiply(
new BigDecimal("0.9")). setScale (0,
BigDecimal.ROUND_HALF_UP). intValue intValue ();
}
}
テストケース (一部)
eclipse で新規テストケースを選ぶと自動生成されるテストクラス
package junit.calculator;
import static org.junit.Assert.*;
import org.junit.Test;
public class CalculatorTest {
@Test // Junit4以降は@が無いとテスト対象になりません~
public void test() { // テスト名は日本語とかで書いておくとわかりよい
fail("Not yet implemented");
}
}
書いたテストコード
import static org.hamcrest.CoreMatchers.*; // 結構書いてないと色々エラーになるのです
import static org.junit.Assert.*;
import org.junit.Test;
public class CalculatorTest {
@Test // Junit4以降は@が無いとテスト対象になりません~
public void calcの正常系() throws Exception{ // テスト名は日本語とかで落ちたテストがわかりやすいですよ~
assertThat(Calculator.calc(34, 9), is(306));
}
@Test (expected = Exception.class) // 例外クラスを指定することもできます
public void calcの数量が 0 の場合は例外が発生する() throws Exception{
assertThat(Calculator.calc(0, 3), is(0));
}
@Test
public void calcの正常系() throws Exception {
// given で準備
int price = 34;
int count = 9;
int expected = 306;
// when 実施
int actual = Calculator.calc(price, count);
// then 検証
assertThat(actual, is(expected));
}
実行 !!!
通ったのもあるぞい!! あとは失敗するテストもあるので、修正します。
なお、カバレッジも取れるので、パッケージごとにやるといいでしょうとのことでした。
テストクラスの注意点や補足
- テスト対象クラスもプログラムなのでミスがあるよね
- なのでポイントは分岐とか繰り返しなし
- DbUnitというのもあって、値の流し込みがしやすい
- 画面系のテスト
- selenide -> selenium は操作系のテスト
- 結合テスト、システムテストフェーズでやってみましょう
今後
最後にトレンドとして定着しているものを紹介いただきました。
この図を見ながら、はぁ、CI/CDやりたい。。 と私が思っていると、コースは修了となりました!
まとめ
なぜ品質モデルが必要なのか、その基準に使えそうなもの、テストのやり方、テストケースを書いて、最後に単体テストを自動実行しました。
3時間で体系的に学びながら、最後手を動かしてみたので、とても実りある時間でした。
また品質モデルの基準はとてもお客様が納得しにくい点なので、ISOやIPA、業界団体が定めているものを使うと安心してもらえる、という話はとても納得できるものでした。
なんとなくテストに疑問を感じていたり、このテストケースで大丈夫なのか、どこまでやるのか悩んでいる方にはとてもオススメのコースです!!
label SE カレッジの無料見学、資料請求などお問い合わせはこちらから!!

SEプラスにしかないコンテンツや、研修サービスの運営情報を発信しています。