- ベストアンサー
単体テスト手順書
bin-chanの回答
単体テストは、システム全体の中での位置づけを気にしない状態(単体)で そのプログラム(で良いのかな?)に求められている機能について「のみ」、を 試験することでしょう。 「求められている機能」は仕様書に記述されていませんか? 操作手順書とも関連していると思います。 1.性別で「1」を選択して「男性」と表示されること。(OK/NG) 2.性別で「2」を選択して「女性」と表示されること。(OK/NG) のような感じでしょうか。
関連するQ&A
- 単体テストを自分でも組めるのか?
単体テストを自分でも組めるのか? C++でOOPに挑戦しているんですが、CppUnit?とか全くわからないのですが 単体テストの概念は分かるのです。 自分はC++の経験が浅く使いこなすようになったばかりの新参者なんです。 この状態で単体テストというものを用いてプログラムを組むことは可能なんでしょうか? もしくは開発効率は上がるんでしょうか?
- ベストアンサー
- C・C++・C#
- 単体テストのテストケースの考え方(あげかた)について
単体テストのテストケースの考え方(あげかた)について 最近、プログラム(java)をはじめたものです。 単体テストを行ううえで、 まず、テスト仕様書の作成を行う(正確にいえば詳細設計段階でやりますが…)と思いますが、 そのテストケースのあげかたはどういう着眼点であげればよいのでしょうか? 単体テストは、詳細設計に対してのテストだと思いますので、 基本的には、詳細設計で作成いたフローチャートの分岐をすべてのケース通るような仕様書を作成しています。 ただ、このやり方だと、問題があるような気がするのです。 たとえば、javaでMapを使用していて、 入力値が、値が固定のMap(例:1,2,3)に入っていればtrue、入っていなければfalseという処理があるとき、 フローチャートでは、trueかfalseかの2パターンしかなく、 実際のコードの記述もget(入力値)で、あるかないかだけ判断するため、2パターンです。 しかし、実際は、固定Mapの値1,2,3,とそれ以外という選択肢があるとおもうのですが、 こういう場合は、1、2、3、それ以外の4パターンのテストを行うべきでしょうか? それとも、Mapにあるかないかだけの部分なので、trueの時とfalseの時の2パターンでいいのでしょうか?
- ベストアンサー
- その他(プログラミング・開発)
- 単体テストの品質の見方を教えてください。
単体テストの品質を確保するために、 作成したソースのステップ数に対して、 1.「テストケース数」はどれくらい用意すれば、妥当と言えるのでしょうか? 2.「バグ数」もどれくらい上げれば、出し尽くしたと言えるのでしょうか? 現場によって、様々かもしれませんが、客観的に数字を教えて頂きたいです。(数字の出し方とかあれば、お願いします。)
- ベストアンサー
- SE・インフラ・Webエンジニア
- 「単体テスト」に関する深刻な愚問です。
「プログラム内のロジックの網羅性」という表現が【単体テスト】の説明文の中に登場していたのですが、意味合いが全く解説されていなかったものですから、畏れ入りますが、その意味を教えて頂けませんでしょうか?
- ベストアンサー
- その他([技術者向] コンピューター)
- 【C言語】単体テストのイメージが全くつかない
閲覧ありがとうございます。 C言語での改修案件に携わっているのですが、当方C言語も開発も経験のないものでして、単体テストについてお伺いしたいです。 システムBの単体テストをしたいとします。 システムBは、別サーバにあるシステムAからソケット通信で電文を受け取り、同サーバにあるシステムCにメッセージキューで電文を送ります。 また逆に、システムCからメッセージキューで電文を受け取り、システムAにソケット通信で電文を送ることもあります。 基本的にデータの中継を担うシステムです。 このとき、一体システムBの単体テストはどのような項目をやるのが正しいのでしょうか? (※CUnit等は使えません) JavaはJUnitを使っての単体テストの学習はしたことがあるのですが、C言語での単体テストの項目もやり方も全く想像がつきません。 私にPGの才能がないことは重々承知しておりますので、出来れば分かりやすくお教えいただければ幸いです。 よろしくお願いいたします。
- 締切済み
- C・C++・C#
- 単体テスト、結合テスト、テスト仕様はどこまで詰め込む?
今、テスト仕様書を作成しており、 みなさまのご意見が伺えたらと思って書き込みさせていただきました。 単体テスト、結合テストの仕様書を作っているのですが、 パターン数がやはりべらぼうに多いので、どこまでで 割り切るかで悩んでいます。 考えれば考えるほどパターン数は出てくるのですが、 それらを作る工数、テストする工数を考えると、 う~ん・・・という感じです。 100%バグのないシステムを作ることは不可能で、 そのコストは∞とされていますが、可能な限りそうしたいのは やまやまですが。 ある本には顧客が70%を望んでいるなら開発としては71%を達成できたらよく、それ以上を求めることは技術者のエゴと書いてありました。 確かにまずされない操作のテストパターンを大量に生成する時間があったら、クライアントはユーザビリティを上げるなどして欲しいはずです。 でも70%ってどうやって決めたらいいのでしょう? 何でもいいので皆さんどうされているか、アドバイスいただけたら幸いです。
- ベストアンサー
- その他(プログラミング・開発)