0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

テストの種類と、その観点

Posted at

はじめに

どんなテストを実施すれば良いか?
テストで絶対に実施すべきポイントは何か?
テスト実施者をどうやってアサインするか?
そんなテストの悩みについてまとめてみました。

◆機能に関するテスト

システムが仕様通りに動くことを確認するためのテスト。
目的や実施者や実施タイミング別に分類すると下記のようなテストが求められる。

1.ホワイトボックステスト

システムやコードレベルの構造を確かめるためのテスト。
実施者:コーダー もしくは 詳細設計をした人
実施単位:ソースコード
実施タイミング:モジュール完成時、ソースレビュー時
例)以下のような分岐を実装している場合は19歳、20歳でテストを実施する

if( $age< 20){
  $group = "未成年";
}else{
  $group = "成人"
}

参考:循環的複雑度、条件網羅、分岐網羅

2.ブラックボックステスト

システムの内部構造を知らないが、仕様通りに動くことを確かめるためのテスト
本来入力が発生しないようなデータを入力してエラーや想定外の動作が起きないこともこのテストで確認する
実施者:設計者(アドホックテスト)、新人SE(モンキーテスト)
実施単位:モジュール、画面
実施タイミング:モジュール完成時
例)年齢にマイナス値が入らないことを確認
例)データが0件の場合にエラーが起きないか確認

3.シナリオテスト

実際の業務の通りにシステムを利用するシナリオを作り、予定している業務を実施できることを確かめるためのテスト
顧客にヒアリング、または用意してもらった年間業務スケジュールに則してテストをするのが望ましい
実施者:要件定義実施者、顧客
実施単位:業務単位、年間業務
実施タイミング:顧客レビュー

▶参考:人事労務の年間スケジュール
image.png
引用:https://hrnote.jp/wp/wp-content/uploads/2017/07/26431155c8eb92f99a305e705a223f2c.jpg

◆非機能に関するテスト

仕様として明言されていない性能面のテストや、システム稼働を継続した際のデータ増加などによるレスポンス悪化に問題が無いことなどを確認するためのテスト

負荷テスト

アクセス負荷を与えたり、一定期間(3年分など)で蓄積されるデータを用意してテストをする。
自社で実装したシステムと外部システム間で連携が発生する場合や、システム稼働で膨大なデータが蓄積されていくシステムの場合は必須
実施者:要件定義実施者
実施単位:業務単位
実施タイミング:機能完成、納品前

アクセス負荷テストで検知できるもの

ApacheやNginxのメモリ設定値、サーバースペックが適正かどうか

データ負荷テストで検知できるもの

RDBのインデックス貼り忘れ、不適切なリレーション

0
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?