Tagged

testing

A collection of 22 posts

テストケースの作成方法:テスト ケースの書き方とは?
testing

テストケースの作成方法:テスト ケースの書き方とは?

この記事では、完全なテストケースを作成する方法について具体的な手順を説明します。 テストケースの詳細については以下の過去記事で紹介していますので、下記のリンクをご覧ください。 テストケースとは? なぜテストケースが重要なのか テストケースの作成準備テストケースを作成する前に、顧客から提供された仕様書を注意深く読んで分析する必要があります。 何か分からないことがある場合は、チームメンバーまたは顧客と話し合って、最も正確なテストケースを作成できるようにする必要があります。 テスト ケース 作成まず、テストケースを作成するために必要なツールを選択する必要があります。 テストケースを手動で作成するツールとして弊社SHIFT ASIAではExcelをよく使用しており、個人的にも強くお勧めします。 また、Excel以外にもインターネット上にさまざまな無料ツールが公開されているので、必要に応じてダウンロードし、使用することもできます。 次にテストケースを完了するための基本的な手順を以下にご紹介します。 Step1:テストの目的を決定する顧客の要件仕様を明確に理解する必要があります。 ソフトウェアシステムの機能のテストケースを書き始めるとき、最初にすべきことは、システムの要件を理解して定義することです。 例:新規会員登録機能には、登録の成功と失敗の確認が必要です。 Step2:テストパフォーマンスを決定する (ソフトウェアシステムの理解に基づく)優れたテストケースを作成するには、機能要件を十分に理解している必要があります。また、 操作を含めソフトウェアがどのように使用されているかを理解した上で、さまざまな機能を整理していきます。 例:正常な登録メールを作成するには、次の基準を満たす必要があります。 →新規登録メールの作成が完了できること →新しく作成したメールで正常にログインできること →データベース(DB)に登録されたメールが保存されていること Step3:非機能(non-function)

テストマトリクスとは
testing

テストマトリクスとは

はじめにソフトウェアテスト工程ではテスト結果を抜け漏れなくチェックすることが欠かせません。今回はテストケース手法として、テストマトリクスを活用する方法について解説します。 1.  テストマトリクスとはマトリクスとは、テストの全体像を表示し、テスト結果をキャプチャするためのフローグラフのノード数のサイズの正方形のテーブルです。 マトリクス上の各行と列はノードの名に対応しており、各セルは行ノードと連携している列ノードに対応したケースの名前です。 2. テストマトリクスが必要な理由テストマトリクスは、主に下記の目的に使用できます。 ・一連のテストを記録するには2つの基準の交点に基づいており、記入すると希望回数の場合が実施されたことを証明するものとして使用されます。 ・入力データに対して実行されたテストの数をすばやく示します。 ・欠陥が発生する特定の状況を特定するのに役立ちます。 ・マトリックスが入力データで満たされると、テストケースが除外されていないことを確認するためのチェックリストとして機能します。 3. ソフトウェアテストにおけるテストマトリクスの利点と欠陥 利点:・シンプル、簡潔。 ・抜け漏れを避け、チェックが必要なすべてのケースをカバーできます。 ・入力データに変更があった場合、テストケースを簡単に変更できます。 ・環境で多くのエラーが発生する領域にテストを簡単に集中させることができます。 ・複数の入力条件の組み合わせがある場合、複数のケースを簡単にテストできます。 欠陥:・ケースが多すぎると混乱します。 ・出力の表現の難しさが存在します。 ・プロジェクトをよく知らないと混乱を招きます。 ・観点が多いと混乱を招きます。 4. マトリックスの作成方法 テストマトリクスを作成するには、次のことを行う必要があります。 ・テストするオブジェクトを行に配置します。 ・列にテストケースを表示します。 ・行と列を組み合わせて、テストするケースに優先順位(重み)を付けます。 なお、テスト時に使用されるマトリックスファイル構造には、関数リストと視点の組み合わせがあります 機能リストの入力データは縦に並べられ、視点は横に並べられます。

テスト密度とバグ密度の指標について
testing

テスト密度とバグ密度の指標について

はじめにテスト密度とバグ密度は、下流工程で定量的な品質指標として使用され、案件品質の分析評価に欠かせないものです。これらの指標の下限値~上限値と実績テスト密度と実績バグ密度を組み合わせることで、どの機能に品質面の懸念があるかを確認することが可能です。 これにより該当する機能のテスト項目の網羅性をレビューしたり、バグ内容を深く検証したり、現象発生区分/原因区分/原因工程/バグ重要度などの品質についてより詳しく分析したりすることができます。そこで今回はテスト密度とバグ密度についてご紹介します。 目次 1.テスト密度とは 2.バグ密度とは 3.どのようにバグ密度を分析するか 1.テスト密度とはテスト密度とは、案件の規模単位(SLOC・FP)でテスト項目の件数を示す指標です。テスト密度はテスト件数を規模単位で割るという方法で算出します。 (SLOC:ソースコードの行数、FP:ファンクションポイント) テスト密度の指標設定は、下流工程のスケジュールなどの作成の時に社内の品質指標と案件の特性などを組み合わせ、対応範囲の各テスト工程の指標の下限値/標準値/上限値を設定します。 テスト密度の分析・評価は、以下のように行います。 各テスト工程におけるテスト設計の段階で、設定されたテスト密度の指標を使用し、実際テスト設計の件数がその指標を達成するかどうかを確認します。ただ、実績テスト設計の件数が多ければ多いほど、テストの網羅性が高いという意味ではないため、テスト設計の成果物の品質を保証するためには、テスト密度の指標評価だけではなく、各機能のテスト項目の網羅性が高いかを徹底的にレビューすることが重要です。 各テスト工程のテスト実行段階においては、普段、テスト工程の途中での判定やテスト工程修了時の判定で、指標と実際バグ密度、[NN1] テスト項目の消化件数の差異を分析評価します。

テストケースサンプル事例:良いテストケースを書くためのベストプラクティス
testing

テストケースサンプル事例:良いテストケースを書くためのベストプラクティス

はじめにテストケースのサンプルは、組織によって異なる場合があります。 しかし、テストケースを作成するために標準のサンプルを使用することは、プロジェクトのテストプロセスを設定する上で最初の一歩と言えます。 また、ビジネスチームがテストケースを確認するプロセスがある場合は、両方の当事者が合意したサンプルでテストケースをフォーマットする必要があります。 このチュートリアルでは、例を使用して手動テストでテストケースを作成する方法を学習します。 マニュアルテストでテストケースを作成する方法まずシナリオのテストケースを作成しましょう。ここでは「ログイン機能を確認する」ことを例に説明します。 手順①: シナリオを説明する簡単なテストケースは次のようになります。 手順②: 実行するためのテストデータが必要になります。 手順③: 環境で特定の一連のアクションを実行する必要があります。 この場合、以下のように手順を文書化します。 ● テスト手順は上記のように単純ではないため、ドキュメントが必要です。 ● 手順を文書化することにより他の利害関係者がレビューしやすくなります。 手順④: ソフトウェアテストのテストケースの目標は、期待される結果をチェックすることです。 この場合、以下のように文書化する必要があります。 良いテストケースを書くためのベストプラクティス最後になりますが、良いテストケースを書くために必要なポイントを以下にまとめてみましたので、ご興味のある方は是非参考にしてください。 1. テストケースはシンプルで透過的である必要がある できるだけ単純なテストケースを作成します。テストケースの作成者がそれらを実行しない可能性があるため、それらは明確かつ簡潔でなければなりません。 2. エンドユーザーを念頭に置いてテストケースを作成する ソフトウェアプロジェクトの最終的な目標は、顧客の要件を満たし、使いやすく操作しやすいテストケースを作成することです。このため、テスターはエンドユーザーの視点を念頭に置いてテストケースを作成する必要があります。 3. テストケースの繰り返しを避ける テストケースの繰り返しは避けましょう。他のテストケースを実行するためにテストケースが必要な場合は、前提条件列のテストケースIDでテストケースを呼び出します。

テストケースとは? なぜテストケースが重要なのか
testing

テストケースとは? なぜテストケースが重要なのか

はじめにテストケースの作成はソフトウェア開発において不可欠な活動であり、ソフトウェアテストの最も重要な部分の1つと見なされています。この記事ではテストケースについて、そもそもどういったものであるのか、なぜ必要なのか、どのような内容が記載されているかを解説したいと思います。 テストケースとは何であるかを知りたい場合は参考にしてください。 テストケースとはテストケースとは、ソフトウェアやシステムが期待通りに動作するかを確かめるため、提供された手順や利用するデータ、条件、実行パターン、期待される結果などを念頭に置いて文書化したものです。テストケースは、テストチーム、開発チーム、および管理者によって使用され、アプリケーションのドキュメントがない場合は、テストケースをベースラインドキュメントとして使用することが可能です。 誰がテストケースを作成することになっているかテストケースは通常、品質保証(QA)チームまたはテストチームのメンバーによって作成され、各システムテストの段階的な手順として使用することができます。 開発チームがシステム機能または一連の機能を終了すると、テストが開始されます。 これは、テストケースのシーケンスまたはコレクションは、テストスイートと呼ばれます。 テストケースにはどのような側面が含まれているかテストケースは、以下にあげる項目で構成されます。 1) 対象: ここでは、テスターはその特定のテストケースで実施する対象(特定の機能・UIなど)を言及します。 2)手順: ここでは、テスターは目的を達成するために従う必要のあるステップに言及します。 3)期待値: ここでは、テスターは提供された要件に従って期待される出力について言及します。 4)入力データ: これはテストを実行する際に利用するデータを指します。 5)

ユーザ 受入テスト(UAT)とは
testing

ユーザ 受入テスト(UAT)とは

はじめにソフトウェア製品の価値は顧客要件と利用者のニーズを満たしているかどうかによって決まります。そのため、現在のソフトウェア検証モデルにおいては単体テスト(UT)、統合テスト(IT)、システムテスト(ST)の各種テストを実施した後、ユーザ受入テスト(UAT)を行うことが必要です。今回は、ユーザ受入テストについて一緒に見ていきましょう。 ソフトウェア検証の工程ユーザ受入テストの概要1.ユーザ 受入 テストとはユーザ受入テストとは、ソフトウェア製品が顧客要件と期待に沿って動作するか、ユーザのニーズを満たしているかを確認するために顧客/エンドユーザーによって実施されるテストの一種です。そのテストはソフトウェア製品が正式に運用または市場にリリースされる前の最終的な階段で実施されています。 ソフトウェア製品の作成工程2.実施対象前述のとおりユーザ受入テストを実施する主体は以下になります。 ●エンドユーザー ●顧客 3.なぜユーザ受入テストが必要なのか次にユーザ受入テストのメリットを見ていきましょう。ユーザ受入テストの代表的なメリットは以下の通りです。 ● 全ての機能が正常に動作するかどうかを確認することで、システムに残存している不具合を発見することが可能 ● プロジェクト実行中に加えられた変更・追加の部分が全て開発者に伝達されているかを確認することが可能 ● ユーザ受入テストの手法にはアルファテストとベータテスト(Alpha & Beta Testing)の2種類が含まれているため本番環境でテストを実施しやすくなり、エンドユーザーにもたらす影響を確認することが可能 4.ユーザ受入テスト実施の手順以下がユーザ受入テストの基本的なステップです。 ユーザー受入テストの基本ステップ● ソフトウェア製品を作成するためのビジネス要件を分析します ● ユーザ受入テストのテスト実施計画を立てます ● テストシナリオを作成します ● 受入テストを実施するためのテストケースを作成します ● 実際のデータに最も近いテストデータを用意しておきます ● ユーザ受入テストを実施します ● テスト実施後の結果を記録します ● 製品の状態・機能を全て確認します

システムテスト定義・種類・テスターのシステムテスト種類の選択基準
testing

システムテスト定義・種類・テスターのシステムテスト種類の選択基準

はじめに今回は「システムテスト(ST:System Testing) とは何でしょうか」、「システムテストにはどんな分野がありますか」、「システムテストにはどんな手法がありますか」、「テスターになるにはどんな準備が必要ですか」といった質問にそれぞれ回答していきたいと思います。では、一緒に見ていきましょう。 システムテストとは 定義システムテスト(ST: System Testing) は、「総合テスト」又は「システム試験」とも呼ばれています。システムテストとは、顧客要求と期待に沿って統合後のソフトウェア製品の機能をすべて動作するかどうかを確認する技法です。 現在のソフトウェア検証工程によると、システムテストは単体テストと結合テストを実施した後に行うことになっています。 システムテストの主な分野システムテストの対象となる分野は一般的には以下のとおりです。 ●パフォーマンス:エラーが発生せずにシステムがユーザー要求に従って動作することを確認します。 ●セキュリティー:コンピュータのデータ、アプリケーション、ネットワーク、デバイスへの不正アクセスなどのセキュリティー違反の対策を行います。 ●回復性:もしシステムがクラッシュした場合、期待どおり速やかにシステムが回復できるかどうかを確認します。 ●インタフェース:システムテストの工程にもソフトウェア製品のインタフェースが検証されます。インタフェースであろうと機能であろうと顧客要求通りソフトウェア製品の動作を確認します。 ●可用性:システムが継続して稼働し、安定して利用できることを確認します。 ●構成可能性:開発環境から本番環境に移動する際、故障が発生していないようにソフトウェア製品をインストールできるかを確認します。 ●持続可能性(サステナビリティ):大容量と高負荷を処理する際にシステムが問題なく動作することを確認します。 ●ドキュメント:

システムテストとは何か? なぜシステムテストが必要なのか
testing

システムテストとは何か? なぜシステムテストが必要なのか

はじめにソフトウェアの開発では、完璧なプログラム・アプリケーションを完成させるために欠かせない工程が数多く存在します。そのうちの不可欠な工程のひとつとして、システムテストがあります。システムテストというのは、プログラマーまたは開発者にとってよく知られている用語ですが、IT業界とは関係ない多くの人にとってはあまり馴染みがないものです。そこで今回は、システムテストについて一緒にみていきましょう。 システムテストとは 定義システムテスト(ST: System Testing) は、「総合テスト」または「システム試験」とも呼ばれており、全ての機能が統合した状態で、ソフトウェアまたはシステム全体の全てのコンポーネントと機能が要求と仕様書に沿って動作するかどうかを確認する工程です。そして、さまざまなハードウェアとソフトウェアに統合した場合にも仕様書どおりに安定した動作を確保することが求められます。 アプローチ方法現在のソフトウェア開発モデルでは、高品質のソフトウェアを作成するために通常、単体テストと結合テストが完了した後にシステムテストを実施します。また、テストのアプローチ方法はブラックボックステストの技法に基づいて行われることが一般的です。すなわち、コーディング、プログラミングなどのシステムの内部動作に関する知識を必要とせずに、ソフトウェアの外部性能のみを確認する手法で実施されます。 システムテストのメリットテクノロジー製品の開発プロセスにおいてはソフトウェア検証の工程が非常に重要です。「なぜシステムテストが必要なのか」という質問に答えるために、以下にシステムテストのメリットを簡単にまとめましたので、ご覧ください。 ●国際標準(ISO/IEC)を満たした製品・アプリケーションの品質確保が可能 ●顧客要求または仕様書の記載に沿ってソフトウェア製品の性能・機能の動作を確保することが可能 ●ソフトウェア製品のシステム全体の検証を実施することで本番環境で発生し得るエラーと不具合を最小限に抑えることが可能 ●顧客から製品・アプリケーションに対する信頼と満足を獲得することが可能 ●製品に発生しているエラーと不具合を何度も繰り返して検証する必要がなくなり、作業効率の向上が可能

ホワイトボックステストとは
testing

ホワイトボックステストとは

ソフトウェアやシステムは人間が開発する以上、不具合などが発生することはどうしても避けられません。こうした不具合を防ぐためにはソフトウェア製品の品質と適切な機能を保証することが欠かせませんが、その上で主要な役割を果たすのがソフトウェアテストです。ソフトウェアテストにはいくつかの手法がありますが、今回は「ホワイトボックステスト」というテスト技法について、詳しくご説明します。 1. ホワイトボックステストとはホワイトボックステストとは、どのコードの行がエラーを引き起こしているかをテストすることでプログラムのソースコードと内部構造を評価するテスト技法です。つまり、システムの内部構造がクリア(ホワイト)な状態を前提としたテストということです。 この技法はオープンボックステスト、クリアボックステスト、コードベーステスト、単純なボックステスト、ガラスボックステストとも呼ばれ、テスト対象は機能、機能モジュールなどのソフトウェアコンポーネントです。ホワイトボックステストは、ソフトウェア開発の初期でエラーを検出する上では最も効果的な手法です。 2. ホワイトボックステストのメリットとデメリット仮にGUI(Graphical User Interface、グラフィカル・ユーザ・インターフェース)が使用できなくてもテスト自体は早めに開始することが可能です。 開発者は、単体テストの作成中にホワイトボックステストを使用しますが、Junit (Java フレームワーク)、 PHPUnit (PHPフレームワーク)、NUnit (.Net フレームワーク) などの単体テスト補助ツールを利用することで品質保証における客観性を保証することができます。ただし、ホワイトボックステストを実行するテスターはコードを詳しく理解できる知識を持っている必要があります。また、コード構造によりテストケースの再利用はほとんど不可能です。 3.

ブラックボックステストとは
testing

ブラックボックステストとは

ソフトウェアの品質を高める上で欠かせないテスト工程では、いくつかの主要なテスト技法が存在します。今回はその中のひとつであるブラックボックステストについてご紹介します。 ブラックボックステストとはブラックボックステストとは、システムの内部構造を考慮せずプログラムが仕様通り設計されるかを検証するテスト方法です。システムの内部構造を直接確認することはできないシステムをブラックボックス(中身が見えない箱)に見立ててテストを実行するため、このように呼ばれています。ブラックボックステストはシステムの内部構造を理解していない場合でも、仕様書があればテストを実施できるというメリットがあり、主に機能テストとシステムテストで行われるほか、機能以外のユーザビリティなどのテスト(非機能テスト)でも実施されます。 ブラックボックステストのテスト技法としては主に以下の5種類があります。 1. 同値分割法 同値分割法とは入力条件を類似と見なすことができるグループ(同値クラス)に分割し、テストを実行する技法です。同値クラス分は、出力、内部変数、時間に依存する値(例えば、イベ ントの前後)のほか、インターフェースパラメータにも存在し、テスト実行においては各クラスから代表的な値を使って分析します。同値分割法は単体テスト、統合テスト、システムテストなどのすべてのレベルのテストに適用できます。 2. 境界値分析(限界値分析) 境界値分析とは、仕様条件の境界となる値(境界値)とその隣の値に対してテストする技法のことです。境界値とは、ある範囲の最小値または最大値などの同値分割した領域の端に当たる値です。具体的には「未満」や「以下」などが該当し、こういった境界部分は間違いを引き起こしやすく、