テスト漏れを軽減するには

プログラムを作成したあとに、結合テストと単体テストをすると思うのですが　結構漏れが発生してしまっていてとんでもないミスにつながるなどのことがあります。
そこで、単体テストや結合テストの強化としてなにかいい方法はないか、漏れを軽減するにはどうしたらいいのかという状況になっております。

今まで、結合テストだけしかしておらず（それはそれで問題）単体テストは初めて作成していくことになりました。

どうすれば、いい単体テストができるようになるのでしょうか？
単体テストや結合テストで漏れを軽減する方法がある。
こうすればバグが見つけやすくなるなどありましたらご教授お願い致します。

単体テストは、初めてとなりますので全く分からない状態です。
調べているもののテンプレートはたくさんあるし、共通点的なものが見当たりません。。。

Web系のテストとなります。

行動規範の内容に同意します

回答6件

テストはシステム開発の永遠の課題であり答えはまだ誰も出せていませんね。
一応、私の考えを箇条書きで述べておきますが、一個人の意見と思って読んでください。

テストとは「望ましい動作が望ましくできていることを確認するもの」であり、「望ましい動作」が何であるかテスト者が分かっていないとテストの品質は上がらない。
「望ましい動作」のうち重要なものから優先してテストを実施するべき。最初にテスト内容を一覧化することも必要だが必須ではない。「望ましい動作」が理解できていれば自ずとテスト者は最初に最優先のものをテストする。
テスト結果を取得することはテストの品質と関連はない。後になって結果を証明したい場合のみ有効。システム開発の目的は利用者がシステムを利用して何らかのメリットを得ることであり、それとテスト結果との関連はない。（テスト結果は事前にテスト者が挙げたケースに基づいて取得するもの。現実として利用者が不便を感じればそのケースに問題があったことになり取得したテスト結果に意味はなくなる）

というわけで、テストが上手くいかないのでしたら、そのシステムが何故存在するのか、だれがどのように使うためにあるものかを再確認してください。
データの更新のテストでしたら、どういう後工程で更新した値が利用されるのか、データの意味や背景を理解してみてください。

テスト項目の列挙のためのチェックリストなど世の中に色々なツールはありますが、単にテスト項目が増えるだけですと重要なテストが後回しになったり多くのテストをこなすための工数が足りなくなったりして、逆にシステムの品質が落ちる場合がありますので要注意です。
私はテスト者が重要なものから優先してテストをするのが最も良いと考えています。
そのために、テスト者は何がそのシステムにおいて最も重要なものなのかを理解しておく必要があります。

質問では「漏れがある」とのことでしたが、誰にも完璧なテストはできませんから、漏れがあること自体を気にする必要は無いと思います。
問題は漏れの重大さであり、いかに重大な内容に対するテスト漏れを回避するかという点が重要なポイントかなと思います。

投稿2018/11/08 08:20

akabee

総合スコア1947

World

2018/11/09 00:41

大変参考になります。有難うございます

行動規範の内容に同意します

プロダクトの性質に合わせてテストは変わっていくものなので「こうするのが正解」というものはありませんが、テスト観点を整理するのが良いと思います。

テストケースは代表的な入力パターンを網羅しているか
原理的に入力可能なケース（実際には数値だけの文字列を期待しているのに任意の文字列を入力できてしまうなど）は網羅したか、正しく例外処理できているか
境界値のギリギリ内側、ギリギリ外側の入力を正しく処理できているか
nullや空文字や空配列の入力をチェックしたか
サロゲートペアを含む文字列や複数の型の値を含む配列の入力をチェックしたか

などなど、自分たちが気になるポイントを一度洗い出してみてこれらの項目がテストとして表現できているかをテストケースレビューで確認したほうがいいと思います。
もちろん、これらのテスト観点が全てのテストについて必要と言っているわけではなく、ただただ無駄になると判断できるものは削っていいと思いますが、それはチームの皆さんで合意をとって進めましょう。

諸々の事情でテストしにくい関数などが見つかった場合は、どうやればテストしやすくなるかも考えましょう。
参照透明性などのキーワードを参考にしてください。

漏れを防ぐには、例えばホワイトボックステストなども調べてみるといいと思います。
ただ、テストを増やせば製品の安全性が高まるわけではなく安全性が見えるようになるというだけなので、やりすぎてもあまり意味がないことに気をつけてくださいね。

投稿2018/11/08 07:55

mather

総合スコア6753

World

2018/11/09 00:41

やはり答えはありませんよね... ご回答ありがとうございます。

行動規範の内容に同意します

ベストアンサー

要件定義

テストではなく、要件定義の問題だと思います。
要件定義さえしっかりされていれば、テストコードを書くのは難しい事ではありません。

正規表現の場合

teratailでは、正規表現で要件が曖昧な質問が多いので、例にとります。
下記は要件定義がなされていない案件に対して、回答者が要件の洗い出しを行っている事例です。

質問者「記号を含むパスワードにしたいのですが、正規表現が分かりません」
回答者「『記号』とは何の文字を指しますか」
質問者「わかりません。一般的な記号であればいいです。」
回答者「では、 #!"&%$()[]';+-*@,./\~` で良いですか」
質問者「良いです」
回答者「1文字のパスワードでもいいのですか」
質問者「8文字以上です」
回答者「数字や英字は含まなくてもいいのですか」
質問者「含んでほしいです」
回答者「数字もしくは英字のどちらか一方が含まれればいいのですか」
質問者「両方含んでほしいです」
回答者「英字(大文字)、英字(子文字)はどちらか一方が含まれればよいのですか」
質問者「両方含んでほしいです」
回答者「数字、英字、記号以外の文字は含んでもよいのですか」
質問者「良いです」
回答者「改行コード(\r\n)は含んでも良いのですか」
質問者「良くないです」
回答者「全角数字は数字としてカウントしますか。」
質問者「カウントしません」
回答者「全角英字、全角記号、それぞれ英字/記号としてカウントしますか」
質問者「両方ともカウントしません」

要件。

8文字以上でなければならない
半角記号を含まなければならない(半角記号は #!"&%$()[]';+-*@,./~` である)
半角英字(大文字)を含まなければならない
半角英字(小文字)を含まなければならない
半角数字を含まなければならない
改行コード(\r\n)を含んではならない

正規表現。

JavaScript
1/^(?=\D*\d)(?=[^a-z]*[a-z])(?=[^A-Z]*[A-Z])(?=[^#!"&%$()[]';+\-*@,./\~`]*[#!"&%$()[]';+\-*@,./\~`]).{8,}$/

実装コードとテストコード。

JavaScript
1'use strict';
2function sample (password) {
3  return /^(?=\D*\d)(?=[^a-z]*[a-z])(?=[^A-Z]*[A-Z])(?=[^#!"&%$()[]';+\-*@,./\~`]*[#!"&%$()[]';+\-*@,./\~`]).{8,}$/.test(password);
4}
5
6function test (password) {
7  return password.length >= 8 &&
8  /[#!"&%$()[]';+\-*@,./\~`]/.test(password) &&
9  /[A-Z]/.test(password) &&
10  /[a-z]/.test(password) &&
11  /\d/.test(password) &&
12  !/[\r\n]/.test(password);
13}
14
15var passwordList = ['aA9#', 'aA9#0000', 'aA9＃0000', 'aA９#００００', 'ａA9#0000', 'aＡ9#0000', 'aA9#0000\r', 'aA9#0000\n'];
16
17for (let i = 0, len = passwordList.length; i < len; ++i) {
18  const password = passwordList[i];
19
20  console.log(password, sample(password), test(password));
21}

関数 test() は「要件」をそのままコードにしただけである事が分かると思います。

Re: World さん

投稿2018/11/10 11:40

think49

総合スコア18162

YasuoOhgaki

2018/11/13 06:13

テスト漏れを防ぐには要求仕様定義が必要には全面的に同意ですが、サンプルのパスワード仕様に問題があります。問題点：要求仕様がブラックリスト型の定義である - 最大文字数が定義もれ - ”含んではならない”が改行コード（\n\r）のみ。つまり、他の制御記号の対策／取り扱いが定義漏れブラックリスト型とは”ダメなモノを定義”する方法です。ブラックリスト型で仕様を定義すると漏れが発生しやすく脆弱です。ホワイトリスト型は”許可するモノを定義”する方法です。ホワイトリスト型で仕様を定義すると漏れ／想定外が発生しづらくなります。このためセキュリティ標準やガイドラインでは「基本的にホワイトリスト型で定義する」ことを推奨しています。これを踏まえて要求仕様をホワイトリスト型の定義に書き換えると以下のようになります。 - 文字数は8文字以上、512文字以下 - 文字種は半角英数字 + 記号（#!"&%$()[]';+-*@,./\~`）のみで構成されていること - 少なくとも一つ以上の大文字英字、小文字英字、数字、記号を含む入力データ仕様を考える場合、ISO 27000が要求していた入力データの妥当性確認が参考になります。 --------------- 入力データの妥当性確認（10.2.1）業務システムに入力されるデータは、正確で適切である事を確実にするために、その妥当性を確認することが望ましい。業務取引処理（transaction）、常備データ（名前、住所、信用限度、顧客参照番号）及びパラメタ（売価、通貨レート、税率）の入力を検査することが望ましい。次の管理策を考慮することが望ましい。次の誤りを検出するための二重入力又はその他の入力検査。範囲外の値。データフィールド中の無効文字。入力漏れデータ又は不完全なデータ。データ量の上限及び下限からの超過。認可されていない又は一貫しないデータ。その妥当性及び完全性を確認するために重要なフィールド又はデータファイルの内容の定期的見直し。入力データに認可されていない変更があるかどうかについての紙に印刷した入力文書の点検（入力文書に対する変更はすべて、認可を得ることをが望ましい。）。妥当性確認の誤りに対応する手順。入力データのもっともらしさを試験する手順。データ入力仮定にかかわっているすべての要因の責任を明確に定めること。 --------------- 参考： https://blog.ohgaki.net/iso27000-and-input-validation 因みにISO 27000:2014から、セキュアプログラミング技術は体系的にまとめられ普及した、として具体的な入力データ検証方法の記載は省略され、セキュアプログラミング技術を採用する、といった表現に改訂されています。これはJIS Q 27000の改訂の経緯に記載されています。セキュアプログラミング技術は体系的にまとめられ普及した、とのことですが、一部の例外的組織を除き、全く普及していないと思います。。。

行動規範の内容に同意します

まず、プログラム仕様書のレベルをプログラムの内容と一致していること。
（プログラムと仕様書を同一レベルに合わせることによって、潜在バグを見つかることもある）
単体テストは、試験項目とそれに合致するデータを用いて、全てのルート（ifの判断の真偽）while、for当繰り返し項目の上限（最大、最少、中間の値）について項目を記述すること。
パターンとして、０件チェックを網羅すること。（読み込みマスタ及びトランザクションファイルが０件の場合など）、異常系にも、網羅すること。これらの順番について、一定であること（０件チェック、正常系チェック、エラーチェック、異常終了系チェックの順番に記述する。－＞漏れをなくすため）
web系でしたら、TCP/IP　セキュリティの参考書を読み、ハッカーがどのような攻撃をしてくるかの研究をしそれに対しての試験項目（エラーチェック系）を網羅しておくこと。
以上のことを注意して試験項目を記述し試験すると、自分にどのようなところに漏れがあるか分析し注意すること。これは、漏れは人それぞれの性格があり、結構人によって漏れのパターンがあります。それを自分なりに克服していくことにより漏れが少なくなってくると思います。

あと、最初は自信がないと思いますので、レビュー（試験項目レビュー　先輩と）をお願いするのも一つの手です。

投稿2018/11/10 11:31