開発テストとは？単体テスト、結合テスト、システムテスト
みなさん、こんにちは！
こうへい(@kohei72901660)です。
開発テストついて曖昧だったので、実際に働いてきて経験した内容をまとめます。
開発におけるテストとは
この業界に入った時はものすごく開発のテストが苦手でした。パターンを考えるのがとにかく難しい。。考えることをやめたくなったのをよく覚えてます。
「コーディングだけやってたい！」そう思ってました( ´∀｀ )
そもそも単体テストと結合テストの違いがわからなかったですね笑
ただテストってめんどくさいではなくて、とても大事なんです。
その理由は次になります。
デグレ（デグレーション）防止
要件が多くなってくると、すべてを把握している人がすくなくなってしまいデグレにつながったりします。自分が依然扱った要件でも忘れたりするので覚えてるのは無理です！笑、ほかの人が扱った要件はなおさら知らない！( ´∀｀ )
でも、テストを自動化してたりすればテスト実行した際に以前組み込んだテストの条件に引っ掛かりデグレに気づくことができます。ドキュメントが残っているだけでも効果はあります。
品質保証
さらに、品質の保証になるんですよね。これも開発において大事なことです。なにかあったときに理由を言えて対策できるのもお客さんにとっては納得してもらいやすい。
現場によっては品質保証するのにある指標を用いて管理しているところもあります。コーディングのステップ数からテストのバグ数はいくつまでとか。プレッシャーですが、テストを見つめなおす良い機会でした！
正直あたりまえと思う方もいると思いますが、テストがおざなりになっている現場なんて沢山あるのが現状です。だからこの記事書いてます( ´∀｀ )
じゃあ、もう早くテスト野郎！（笑）
ちょっと待って！すぐにはテストはできないんです！
まずはテスト前に大事なことがあります。
テストする前に大事なこと
テストをするうえで大事なことは、要件から詳細設計までがしっかりとまとまっているかが重要だと思います。
要件定義、基本設計、詳細設計、コーディング、テスト
基本的にはこの流れかと思いますが、要件定義～詳細設計に穴があるとテスト作成段階で「あれ、この条件の時ってどうなるんだっけ？」となり、また要件定義に戻って検討しなければいけません。
なので、実際にコーディングするまでが超重要だと私は思います。
いわゆる上流工程ですね！単価が高いのも上流工程ができるエンジニアであることが多いので、そういう理由からかなと思います！
余談ですが、私が経験のある現場ではアジャイル開発のところが多かったです。テスト段階で要件に漏れがあった場合は別の案件にしちゃって先に進めちゃうことが多かったです。
漏れがあるのはダメですが、働く人みんな人間です。多少しょうがないところもあるので、アジャイル開発だとスピーディーに切り替えられていいなと思ってます！設計が得意な人なんてそんないないのが現状！笑
テストしっかりやろうとしすぎて、テストの保守に工数かかりすぎる場合もあります。それもまた本末転倒ですので、うまい調整が必要だと思います。
そういう意味だと、すべての工程に携わったことのあるエンジニアが強いかなと書いてて思いました！そうなろう！笑
少し脱線してしまいましたが、次にテストについてまとめていきます。
テストの種類ってどんなのがあるの？
僕の経験上から主に3つの工程に分かれるかなと思います。
- 単体テスト・・・UT（Unit Test）
- 結合テスト・・・CT（Combined Test）
- システムテスト・・・ST（System Test）
単体テスト・・・UT（Unit Test）
プログラム単体で行うテストですね。ホワイトボックステストとも言われるかと思います。あらかじめどういう条件でプログラムが書かれているのかがわかっていて、その条件を通るようにテストを作成します。
よく現場だとカバレッジ確認でC0、C1、C2が通るようにするとか、現場によってはC0、C1が通ればよかったりします。僕が経験あるのは後者が多いです。
※C0、C1、C2ってなんだよって方は後日別の記事を出します。
具体的な方法で言うとメソッド（機能）単位で単体テストを実施してました。
テスト対象のメソッドが呼び出しているメソッドがある場合はスタブを作成し、メソッドを呼ぶためにいろんな条件が必要だった場合はドライバを作成します。
このスタブ、ドライバについてもよくわからなかったです。。笑
実際に一つ一つ作ったりしてるとめんどくさいですよね！笑
しかし、今ではテストのためだけに呼び出し機能の処理を変更したいといった場合は簡単にモックを作成できるツールがあったりするのであまり苦労したことはありません(^^)
結合テスト・・・CT（Combined Test）
詳細設計、基本設計どうりに作れているかを確かめるテストかと思います。
こちらはいわゆるブラックボックステストです。
設計書をみながら条件を書き出して、それを満たすインプットから期待通りのアウトプットになるかを確かめます。
プログラムの中身を見ないといったところがブラックボックスの所以なんですかね？
細かいことは置いといて、単体テストとの違いはプログラムの機能単位ではなく、システムのある機能についてのテストであるというところです。
単体テストではスタブやドライバを作成して処理を確認しましたが、結合テストでは出来上がった本当のプログラム同士の関連性で問題が生じないかを見ます。
現場によっては単体テストと結合テストの切り分けができていなくて、結合テストでホワイトボックスなテストをやっているところもあり、単体テストと同じことをやってて非効率だなと感じたこともあります。
私の初めての現場ではまさにそれだったのでテストについてよくわからなかったんだと思います。いい経験ですね！( ´∀｀ )
システムテスト・・・ST（System Test）
システムテストはお客さんの実際に使用する環境（もしくは、それ相当な環境）とデータを用いてシステムを動かすテストです。
結合テストまでは開発環境もしくはテスト環境でテストを実施するのが通常かと思います。もし、お客さんの環境で開発したり単体テストや結合テストをやり、大事なデータを消してしまったら大変です。考えただけでも怖い。。
そんなこと言われたらシステムテストやりたくない！と言われそうですが、やらないといけない理由があります。
まず、お客さんの実際に使う環境で行うので、テスト対象以外のシステムも動いているかもしれません。ほかのシステムとの連携をする場合、その連携がとれるかを見ます。さらに、連携とかなないけど阻害していないかを見ます。
次にシステムの性能をテストします。
結合テストまではそんなに大きくないデータを使ってやることが多いと思いますが、システムテストでは実際に使うデータの場合にちゃんと動くかを評価します。お客さんが動かしてて、システムが止まった！とかだと業務に支障がでるので、そうなる前に事前に防ぐことが目的です。使うであろう最大のデータ量であったりアクセス量を事前に知っている必要があるので、お客さんとの連携も必要です。
具体的には最大のデータを用いた場合にサーバが耐えられるかを見ます。
CPU、メモリ、ディスク容量、IOPSなどが測定パラメータであることが多かったです。もしも、実際に見積もって立ち上げたサーバのスペックが最大データに耐えられない場合はサーバのスペックやシステム構成を見直す必要になります。
サーバのスペックをあげるのもタダではないので、お客さんが出せる額も考えながら、もしも出せない場合はシステム構成であったりプログラムをもっと効率よく処理できないかを見直す必要も出てきます。
あと、システムは耐えてるけどやたら遅い場合にもどこがボトルネックになっているかを調査するのもシステムテストの目的です。
最後に
以上、ずらずらと開発におけるテストについてまとめてみました！
すべていろんな現場を経験したうえでの話です( ´∀｀ )
正直、現場によってテストのやり方は全く違うので、一つの基準として見ていただければ幸いです！
開発全般