読者です 読者をやめる 読者になる 読者になる

MyController

WEB業界素人の僕がまた見返しそうなことのメモです。

テスト仕様書の概要と作成方法

とても大事なこと。

・誰がテストをしても同じ結果になること。

・正常に→×、具体的に何がどうなればOKかを記載。

 

 

概要

・機能テスト

最も一般的なテスト。機能を確認する

 

・性能テスト

テスト対象に入力を与えたり,動作させたりしたときに,正しい実行結果が出るかどうかを確認する

 

・負荷テスト

ユーザがストレスを感じない程度の時間内で実行されなければならない

性能テストに関連して,テスト対象が実行できる限界のリソースを見極める

 

ユーザビリティテスト

ユーザにとっての「使いやすさ」に着目したテストで,特に高齢者や障がい者などに配慮した「アクセシビリティ」の高い作りになっているかどうかの確認が必要になる場合がある。

 

・セキュリティテスト

ソフトウェアの実行中に機密情報が漏洩しないことや,外部からの悪意を持った攻撃に耐えられることを確認。

 

テストの方法

 ・動的テスト

テスト対象を動かしてみて結果を確認

 

・静的テスト

1.ソフトウェアを構成するソースコードを読む,すなわちレビューする

2.もうひとつソースコードの記述パターンをチェックする静的解析

 

 

 

テストケース作成技法

ブラックボックステスト

テスト対象に入力を与えて,実行された結果が正しいかどうかを確認。

このときに,テスト対象の中でどのような処理が行われているかは気にしません。

テスト対象の「仕様」に基づいたテストケースの作成技法です。

 

ホワイトボックステスト

テスト対象に入力を与えた際に,どのような順序で処理が実行されたり,データの値が変化したりするのかを確認。

テスト対象の「構造」に基づいたテストケースの作成技法

 

・グレーボックステスト

ブラック、ホワイトボックステスト技法をあわせて,仕様と構造の両方に着目しながらテストケースを作成する

 

テスト仕様書で絶対に必要な項目リスト 

  1. テストを実施した環境
  2. 実施するテストの内容
  3. テストを実施するためのシステムの操作手順
  4. テストの実行結果
  5. 個々のテスト項目を識別するための番号や記号(通し番号など)
  6. テストを実施した年月日
  7. テストを実行した担当者
  8. 障害報告票番号(発生した障害の詳細を開発グループに報告する帳票の識別番号)