OJT研修 「テスト実施、テスト設計の技術習得」 日時: 8月22日(月) 場所: 本社5階
テストの役割を理解し、テスト技法の内容を理解し、この研修の中の課題に対し、成果物作成(テスト仕様書)の作成と、そのための調査の方法の説明。 ●この研修の進め方 テストの役割を理解し、テスト技法の内容を理解し、この研修の中の課題に対し、成果物作成(テスト仕様書)の作成と、そのための調査の方法の説明。 ーテストの役割と代表的技法 ソフトウェア開発におけるテストとはなにか、そのための代表的技法を理解する、 ー課題の理解とテスト仕様書の作成 提示された課題に対し、成果物作成(テスト仕様書)と、調査の方法の説明(JavaのWEBアプリの設計書を見て、テスト仕様書を、機能面、性能面、保守性、ユーザビリティ、セキュリティ面の総合的観点)から作成。 ーテスト実行 作成示された(テスト仕様書、テストケース)に従い、テストの実施とテスト結果報告
テストとは何か
プログラミング開発の手順 4
「要件を満たすことを保証する」 「欠陥やバグを検出する」 「リリース後の品質リスクを見積もる」 「開発プロセス改善の指標となる」 ソフトウェアテストとは コンピュータのソフトウェアプログラムを実行し、それが意図したとおりに動くかを観測・評価・検証する作業のこと。 ソフトウェアテストを行う目的としては、 「要件を満たすことを保証する」 「欠陥やバグを検出する」 「リリース後の品質リスクを見積もる」 「開発プロセス改善の指標となる」 などが挙げられる。
開発を複数の工程に分け各工程の終了時に成果物を作成することにより、各工程における品質の確保を図ります。 開発モデルに従うソフトウェアテスト 開発モデルとは、システムを開発するための方式として標準化されている、開発の手順や手法のことである。 代表的な開発モデルとしては、ウォーターフォールモデルやプロトタイプモデル、スパイラルモデル、アジャイル型開発モデルなどがある。 各種の開発モデル、 ウォーターファール型開発モデル 開発を複数の工程に分け各工程の終了時に成果物を作成することにより、各工程における品質の確保を図ります。
テスト技法
ソフトウェアテストの主な分類 (ウォーターファール型開発モデル) 単体テスト……プログラミングの成果を検査するテスト 結合テスト……内部設計の仕様を満たしていることを確認するテスト システムテスト……外部設計の仕様を満たしていることを確認するテスト 運用テスト(システムテスト)…要件定義を満たしていることを確認するテスト
各工程での品質に係る作業
テストの工程 テスト計画 -テスト全体の指針や概要をまとめる。 テストの目的、対象範囲、実施方法、テスト体制、 テスト環境、スケジュール、合格基準など。 テスト分析 -テスト対象を理解する(仕様書を理解する) -テストの目的を理解する(ユーザを理解する) テスト実装 -テストの設計(テスト仕様書作成)し、 テストシナリオ、テストケースを作成 テスト報告
テスト設計という工程 テスト設計という工程は定義されていません。ただし,この標準テストプロセス図とは別に用意されているテストプロセス詳細という文書では,テスト設計は「テスト実装」の中で行う"作業"として定義されています。
テスト設計での作業 テスト仕様書 テストケース テストシナリオ テスト仕様書は、SEやプログラマにとって、システムを高品質にするための文書です。「バグ発見・修正を管理するために必要な文書」。また顧客からみると、「要件定義書で決めた事項が満たされたシステムになっているかどうか、導入前にチェックして確認するための文書」です。 加えて ・後で見たとき、テストが網羅されていることがわかること(他人が確認できること) ・テストの操作の妥当性が、ほかの人が見ても確認できること テストケース ユーザーの使用状況を反映した入力データを用いてソフトウェアを実行し、事前に想定した結果と実際の実行結果をつき合わせて合否の判定を行う。このテスト用の“入力データ”とそれを実行したら得られるであろう“事前に想定した結果”の対をテストケースという。 すなわち、テストケースを使って対象を実行してみる“行為”がテスト(testing)である。 テストシナリオ テスト(テストケースの実行)を効率的/効果的に行うために一連のテストに順序性や意味づけを行うため(例 ユーザシナリオにもとに作成)のもの
テスト設計技術
テスト仕様書の内容
テスト仕様書で必要な項目リスト テストを実施した環境 実施するテストの内容 テストを実施するためのシステムの操作手順 テストの実行結果 テスト仕様書に記述すべきものとして、以下の事項があります。 テストを実施した環境 実施するテストの内容 テストを実施するためのシステムの操作手順 テストの実行結果 個々のテスト項目を識別するための番号や記号(通し番号など) テストを実施した年月日 テストを実行した担当者 障害報告票番号(発生した障害の詳細を開発グループに報告する帳票の識別番号)
まずはテスト環境について明記する テスト仕様書の先頭には、「テストを実施した環境」を記述します。ここでは、ハードウェア環境やソフトウェア環境、ネットワーク環境など、「どのような環境でテストを行ったか」を説明します。 ただし、テストを実施した環境を記述するだけでは十分ではありません。「顧客にとって必要な情報は何か」を考えるのです。ここで必要なのは、「要件定義書で規定した環境」との関係が分かることです。
①テスト実行環境の明確化 テスト実行時の環境を明確にします。 テスト実行時の環境にテスト実施目的により差異がある場合は、どの環境を使用するかというのを テストケースごとに明確にしておく必要が有ります。 記述例: テスト環境 ソフトウェア ・XXXXXシステム用アプリケーションVersion y.y ・Windows zz Service Pack aa ハードウェア .acer xxxxx
顧客リストの顧客のIDを入力すると顧客情報が正しく表示されることを確認する。 テスト仕様書のフォーマット(例) テスト項目番号 大項目 確認内容 操作手順 確認結果 確認日 確認者 障害報告票番号 機能 顧客情報の表示 顧客リストの顧客のIDを入力すると顧客情報が正しく表示されることを確認する。
テストシナリオとテストケースの作成手順(例)
シナリオの想定
テストの大項目(例) • 機能 • 性能 • 信頼性 •操作性 • 障害対応性 • セキュリティ
テストケースと実装の例 ここでは、例として商品(Product)の値段(price)を値引きするメソッド(#discount_price)について考えます。 class Product def initialize(price: 0) @price = price end def discount_price(percent: 0) @price * (100 - percent) / 100 product = Product.new(price: 100) product.discount_price(percent: 20) #=> 80 テストケース 値引率が20%のとき、値段は¥80になる 値引率が101%のとき、例外を返す 値引率が-1%のとき、例外を返す 値引率として文字列を渡すと、例外を返す 値引率が1.5%のとき、値段は¥99になる
テストケース(例)
今回の課題の日本語 e_ラーニングシステムの プログラム仕様書
1.テスト分析(プログラム仕様書の理解) 2 テスト設計(テスト仕様書作成とテストケース作成) 2-2 プログラム課題作成(内定者) 2-2-1 課題作成の仕様書説明 2-2-1-1 プログラム開発作業 2-2-1-2 テスト仕様書作成とテストケース作成 2-3 テスト仕様書作成とテストケース作成(ゴルフ同好かいサービス他)(インターン生) 3 テスト実行とテスト実施 4 テスト実施結果の評価