底辺過ぎてちょっとビビる

26歳からIT業界にいるエンジニアが、まったく成長できてないことを確認するブログ。備忘録的に使いたいとも考えています。

単体テストと結合テスト、そして総合テスト

今、あるWEBアプリケーションシステムのプロジェクトに参画している。とある金融系企業で現行システムにおける基盤側のEOLなどに伴って、それに乗っかっているアプリケーションのリファクタリングを行うというもの。まぁよくあるプロジェクトだ。

 

要件定義~基本設計~詳細設計が終わり、今は開発と単体テストの真っ最中。そのあと結合テストそして総合テスト、受入れテストが待っている。ざっくりと要件定義~基本設計~などと書いたが、実際は基盤側やアプリケーション側からそれぞれ現行システムの機能や環境面の調査が行われて、やっとここまで来た、という感じだろうか。

 

Subversionの基本設計書のフォルダ内にあるファイルを読むと、自分たちが参入するほんの数日前に完成したような機能概要フロー図などがあり、はたして実装・単体テストは順調にいくのだろうか?という疑念が強くある。

 

 

とはいえ、単体テストがすべて完了せずとも、OKになった機能同士で結合テストは可能なはずなので問題はそこまで大きくないかもしれない。(過去単体テスト結合テストまでを一通りするのが割と普通だったので、今回のように単体テスト結合テストで完全にチームが分かれているのが珍しいのだ)

 

というわけで、今は結合テストのテストケース作成のために機能仕様書類を眺めている最中。サンプルになるHTMLの画面を眺めてみたが、そこまで異常に複雑なシステムでないように感じた。ユーザーはいわゆるSEなどのIT職ではなく、一般の社員なので彼らでも問題なく扱えるように簡易な画面構成になっているように思えた。画面数や機能数はやはりそこそこあるが、チーム内できちんと機能を分割してやればできなくはないのではないか・・・?と感じている。ただし、それはテストに関してベテランであれば、という前提がつくと思うけれど。

 

というわけで今読んでる本がこれ。わかりやすいというかとっつきやすい。

 

個人的な単体テストの認識

いわゆる機能個別のテストであり、今回のようなWEBアプリケーションであれば、1画面単位でのテストという認識。

f:id:starscream1999:20170211225122p:plain

サンプルイメージで言うと、「顧客情報登録画面」で入力する顧客名や顧客住所・顧客電話番号等の入力データが定義された範囲で入力されてるかどうかのテストだったり、入力されたデータが「顧客情報テーブル」に正常に格納されているかのテスト。ここではボタンがあるので、「取消ボタン」が押されたならば、(仕様にもよるが)入力されたデータ類がいったん初期化されているかどうかのテストや、「保存ボタン」ならば仮登録という形で顧客登録は行わないけれども、あとで途中まで入力したデータを呼び出してそこから続きを書けるかどうかのテストだったりする。案外一番重要だったりする。

 

個人的な結合テストの認識

いわゆる2つ以上の機能間の連携に関するテスト。今回のようなWEBアプリケーションであれば、画面間やまたがるデータベースに関するテスト、という認識。

 

f:id:starscream1999:20170211230430p:plain

サンプルイメージの図が小さいので画面名を左から順に説明すると、「顧客情報登録画面」「顧客情報検索画面」「顧客情報検索結果表示画面」となっている。画面遷移として矢印が左から右に流れているが、実際はこの通りではないだろう。あくまで登録→検索→検索結果表示という一連の流れだと思ってください。

 

顧客情報登録画面で登録されたデータは顧客情報テーブルに格納される。そして、登録された顧客情報は顧客情報検索画面で入力された情報と合致されるものが顧客情報テーブルから引っ張られて、顧客情報検索結果表示画面で表示される。

 

ここでは3画面にまたがって顧客情報テーブルのデータ内で矛盾が存在しないことを確認すればよいと思う。顧客情報がきちんと反映されているかどうかを確認するといってもいいか。実際にはこんなシンプルな機能はないはずで、一つの画面からいくつもの画面へリンクが張られていて、それぞれの画面間でデータに矛盾がないかや画面遷移で異常がないか、またはブラウザの機能だったり・・・。異常値のデータ入力は単体テストでやってるけど、あえて「異常値が入った場合」として画面間でもテストするのかな。

 

個人的な総合テスト(システムテスト)の認識

 システム全体をうかがうテスト。画面Aか画面Zまですべての画面・機能を通したテストというイメージ。この辺になってくると何をテストするのか?というのがちょっとわからなくなってくる。レスポンステスト?負荷テスト?などなど、今までやったことのないテストもやるかもしれない。正直あまり経験がないので未知の部分ですごく怖い。

 

わかってないことが多いので特に語ることがない・・・。

 

 

今のところ・・・

まだプロジェクトに参入して10日も経っていないので、仕様についてはもちろん業務全般についてもあやふやだ。しばらくしたらメンバー個別に「ここからここまでの機能の結合テストのテストケースを書いてください」と依頼されるだろう。正直何を手本にやったらいいのか、よくわからない。ソフトウェアテストに関する書籍を読んで知識を増やしている最中だけど、最終的に「プロジェクトに依る」としか言えない部分もあるし・・・。

 

今まで我流でテストケースの作成を行ってきたが、ここではせっかくテストケースを作成するために呼ばれているので今後の為にも「テストとはどうすべきか」をしっかり学んでいきたい。そして今後関わるいろいろなプロジェクトで得た知識を活かしたい。

 

あと空調が全体管理なのでどうしようもないけど、作業室が暑すぎる!

 

 

はじめて学ぶソフトウェアのテスト技法
 
【この1冊でよくわかる】ソフトウェアテストの教科書―品質を決定づけるテスト工程の基本と実践

【この1冊でよくわかる】ソフトウェアテストの教科書―品質を決定づけるテスト工程の基本と実践

 
システムテスト自動化 標準ガイド CodeZine BOOKS

システムテスト自動化 標準ガイド CodeZine BOOKS

 
JUnit実践入門 ~体系的に学ぶユニットテストの技法 (WEB+DB PRESS plus)

JUnit実践入門 ~体系的に学ぶユニットテストの技法 (WEB+DB PRESS plus)