質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.50%
Ruby

Rubyはプログラミング言語のひとつで、オープンソース、オブジェクト指向のプログラミング開発に対応しています。

C#

C#はマルチパラダイムプログラミング言語の1つで、命令形・宣言型・関数型・ジェネリック型・コンポーネント指向・オブジェクティブ指向のプログラミング開発すべてに対応しています。

Java

Javaは、1995年にサン・マイクロシステムズが開発したプログラミング言語です。表記法はC言語に似ていますが、既存のプログラミング言語の短所を踏まえていちから設計されており、最初からオブジェクト指向性を備えてデザインされています。セキュリティ面が強力であることや、ネットワーク環境での利用に向いていることが特徴です。Javaで作られたソフトウェアは基本的にいかなるプラットフォームでも作動します。

PHP

PHPは、Webサイト構築に特化して開発されたプログラミング言語です。大きな特徴のひとつは、HTMLに直接プログラムを埋め込むことができるという点です。PHPを用いることで、HTMLを動的コンテンツとして出力できます。HTMLがそのままブラウザに表示されるのに対し、PHPプログラムはサーバ側で実行された結果がブラウザに表示されるため、PHPスクリプトは「サーバサイドスクリプト」と呼ばれています。

C++

C++はC言語をもとにしてつくられた最もよく使われるマルチパラダイムプログラミング言語の1つです。オブジェクト指向、ジェネリック、命令型など広く対応しており、多目的に使用されています。

Q&A

3回答

2674閲覧

テストについて

退会済みユーザー

退会済みユーザー

総合スコア0

Ruby

Rubyはプログラミング言語のひとつで、オープンソース、オブジェクト指向のプログラミング開発に対応しています。

C#

C#はマルチパラダイムプログラミング言語の1つで、命令形・宣言型・関数型・ジェネリック型・コンポーネント指向・オブジェクティブ指向のプログラミング開発すべてに対応しています。

Java

Javaは、1995年にサン・マイクロシステムズが開発したプログラミング言語です。表記法はC言語に似ていますが、既存のプログラミング言語の短所を踏まえていちから設計されており、最初からオブジェクト指向性を備えてデザインされています。セキュリティ面が強力であることや、ネットワーク環境での利用に向いていることが特徴です。Javaで作られたソフトウェアは基本的にいかなるプラットフォームでも作動します。

PHP

PHPは、Webサイト構築に特化して開発されたプログラミング言語です。大きな特徴のひとつは、HTMLに直接プログラムを埋め込むことができるという点です。PHPを用いることで、HTMLを動的コンテンツとして出力できます。HTMLがそのままブラウザに表示されるのに対し、PHPプログラムはサーバ側で実行された結果がブラウザに表示されるため、PHPスクリプトは「サーバサイドスクリプト」と呼ばれています。

C++

C++はC言語をもとにしてつくられた最もよく使われるマルチパラダイムプログラミング言語の1つです。オブジェクト指向、ジェネリック、命令型など広く対応しており、多目的に使用されています。

0グッド

1クリップ

投稿2016/09/24 07:57

単体テストや結合テスト、総合テスト全般についての質問ですが、どこまでテストを行えばいいのかが分かりません(どんなテストケースを作ってテスト仕様書をかけばいいのか分かりません)。

テスト仕様書自体は作成することができますが、本当にこれで全て網羅しているのか不安です。
何かアドバイスをいただきたいです。

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

guest

回答3

0

どこまでテストをおこなえば良いかは、プロジェクトの性質や、かけられる金銭的・時間的・人材的コストなどによって違ってくると思います。

テストとはある条件下において意図した動作を行うかを確かめるものです。
ユニットテストでは、ある入力に対して正しい出力が得られるか、または正しくエラーを吐くかなどの確認を行います。
どんなテストケースを作成して良いのか分からないということは、テストすべきコードの仕様を把握できていない、もしくは仕様自体が複雑でテストが困難な状態なのではないでしょうか。

テストの網羅性に関してはカバレッジなどの確認や、境界テストなどの手法によって効率的におこなうことができます。
ただしこれに関しても、バグがないことを保証するためのものではありませんので、あまりカバレッジを100%にすることにこだわらないほうがいいと思います。
もし、あなたの言う「すべて網羅」の意味が「あらゆる状況に対するテストケースの作成」という意味なら、それを実現する方法を私は存じません。

自分の仕事がちゃんとした品質になっているのかという不安は尽きないと思いますが、時間をかけて体系的に勉強したり経験を積んだりするのがベストかと思います。
あなたの望む回答になっているかは分かりませんが。

投稿2016/09/24 09:12

編集2016/09/24 09:14
carimatics

総合スコア740

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

0

Vモデルの考え方を基本にマトリクスとデシジョンテーブルを活用すると良いと思います。

どんなテストケースを作ってテスト仕様書を書くかについては、基本はVモデルに従います。
規模の大小やプロジェクトの進め方が違っても結局はVモデルの考え方が登場します。
テスト仕様書のインプットはテストの工程に対応する設計書だということです。

本当に全部網羅しているかについては、網羅性が見えるようになれば安心感を得ることができます。
テストパターンの洗い出しにマトリクス表を作り、
テストパターンに対する結果の抽出にはデシジョンテーブルを作る
と良いと思います。単純作業に近いので取り掛かりやすく且つ分かりやすいでしょう。
(単純なだけに爆発的なパターン数になります。実質不要なパターンも数に含まれるので冷静に見ましょう)

単体テスト、結合テスト工程においては実際にコードが動いた実績の確認も行うと良いです。Carimaticsさんも回答されているカバレッジの確認です(昨今のプロジェクトでは必須?)。カバレッジ100%にこだわらないほうがよいという考えに賛同します。100%にするためにテスト対象のコードを変更しなければならない場合が存在します。100%にするためにテスト対象を変更しては意味がなくなってしまいます。かといって設計変更はインパクトがある。この場合はテストできない理由を記録し残します。カバレッジはトータルでは100%になることはないと言えるかもしれませんね。

蛇足ですが、Vモデルの考え方はテスト工程で設計工程の記述不足・検討不足をあぶり出すことになったりします。設計そのもののテストにもなっていると言えるでしょう。こうしたものを見つけた場合には懸案事項や課題管理表に記録し報告するようにすると良いでしょう。
(工程が終わっていたり、契約上設計書を変更できない等で受け入れられない可能性が高いですが、こうした活動は次の改善になります。)

投稿2016/09/24 13:46

Hiroshi-Aoki

総合スコア804

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

0

投稿2016/09/24 10:38

退会済みユーザー

退会済みユーザー

総合スコア0

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

まだベストアンサーが選ばれていません

会員登録して回答してみよう

アカウントをお持ちの方は

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.50%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問