ソフトウェアテストの常識

ソフトウェアの開発と使用の歴史のおかげで、ソフトウェアの欠陥によって引き起こされた莫大な金銭的および物的損失から多くの教訓が得られました。これらのレッスンにより、テストエンジニアは検出されなかった隠れたソフトウェアの欠陥を検出するために強力な検出を行うことを余儀なくされました。

ソフトウェアの品質を判断するための基準として、お客様のニーズを満たすことを目的としていますが、ソフトウェアバグの具体的な意味には次のような要素があります。

•ソフトウェアが顧客の要求する機能と性能を満たしていない。

•ソフトウェアが顧客の要求を超えている。

•ソフトウェアに顧客のニーズに耐えられないエラーがある。

•ソフトウェア使用は顧客の習慣や職場環境に合いません。

設計やその他の要因を考慮すると、ソフトウェアの欠陥には仕様を満たさないソフトウェア設計も含まれる可能性があり、最適な条件（予算、範囲など）を達成できないこともあります。残念なことに、私たちの多くはソフトウェアの欠陥を実行時の問題と考える傾向があり、ソフトウェアテストはプログラムが提出された後に限られています。

現在の国内環境では、完全で正確な顧客要求仕様を見ることはほとんどできず、顧客のニーズは絶えず変化しており、完璧なテストを追求することは不可能です。したがって、優れたテスターとして、ソフトウェア品質の完成度を追求することが私たちの目的ですが、現実とソフトウェアテストの理想とのギャップ、ソフトウェアテストで選択し、与えることを学ぶことは、ソフトウェアテストに害がないことは明らかです。 。

以下はソフトウェアテストの常識であり、これらの常識を理解し適用することで、ソフトウェアをテストする際のソフトウェアテストの規模をよりよく理解することができます。

•テストが不完全（テストが不完全）

明らかに、ソフトウェア要件の不完全性、ソフトウェアロジックパスの組み合わせ、大量の入力データ、および結果の多様性が原因ですべての論理パス、すべての入力データを使い尽くし、すべての結果を検証するための非常に単純なプログラムであっても、その他の要因は非常に困難です。 2つの整数の最大公約数を見つけるなど、簡単な例を見てみましょう。その入力情報は2つの正の整数です。しかし、正の整数フィールド全体の数をその数の無限大からテストすると、そのようなテストは実際には機能しないことを証明できます。たとえ1日プログラムを使い果たしても、私は怖いです私たちと私たちの子供たちと孫は古くからあります。このため、ソフトウェアテストとしては、通常、等価クラスと境界値分析を使用して実際のソフトウェアテストを行いますが、テストの複雑さを軽減するには、最小のユースケースセットを見つけることが必要になります。

•テストは免疫性（ソフトウェアの欠陥に対する耐性）

ソフトウェアの欠陥はウイルスと同じくらいひどいものであり、テスターが使用するテストが多ければ多いほど、それらはより耐性があります。強いほど、より多くのソフトウェアの欠陥を見つけることが難しくなります。この結論は、数学的確率論から導き出すことができます。 50000行のプログラムに500のソフトウェア欠陥があり、ソフトウェアエラーが均等に分散されていると仮定すると、ソフトウェアの欠陥は1​​00行ごとに検出できます。テスターがX時間/100行でソフトウェアの欠陥を探すのに時間を費やすと仮定します。この計算に基づいて、ソフトウェアに500個の欠陥がある場合、ソフトウェア欠陥を見つけるのにX時間かかり、ソフトウェアに5個のエラーしかない場合、各ソフトウェア欠陥に対して100X時間が必要です。実際には、実際のテストプロセスは上記の想定よりも厳しいことが証明されているため、さまざまなテスト方法とテストデータを置き換える必要があります。この例では、ソフトウェアテストの1つの方法ですべてのソフトウェアの欠陥を効率的かつ完全に解決することはできないため、ソフトウェアテストはできるだけ多くの方法でテストする必要があります。

•テストは「一般的概念」（完全テスト）です。

私は、プログラムが完成した後に初めてソフトウェアテストに反対しました。プログラミング段階の後の段階が単にソフトウェアテストと呼ばれる場合、需要段階および設計段階における欠陥の増幅効果は増大するであろう。これはソフトウェアの品質にとって非常に有害です。需要の欠陥や設計上の欠陥もソフトウェアの欠陥であり、「ソフトウェアの欠陥には生殖能力がある」ことを思い出してください。ソフトウェアテストはソフトウェア開発プロセス全体に及ぶべきです。要件検証（セルフテスト）および設計検証（セルフテスト）もソフトウェアテストの1つとして数えることができます（推奨：デマンドテストおよび設計テスト）。ソフトウェアテストは、サイクルの各フェーズが禁止されていることを確認するために、ソフトウェアライフサイクル全体をカバーする一般的な概念であるべきです。同時に、テスト自体は第三者による評価（情報システム監査とソフトウェアエンジニアリングの監督）を必要とします。つまり、テスト自体の信頼性と効率性を保証するためにテスト自体もテストされるべきです。そうでなければ、それは正しくなく、人々に仕えることは困難です。

ソフトウェアテストは、ソフトウェア製品の品質を向上させるために必要かつ十分ではない条件であることも指摘する必要がありますソフトウェアテストは、製品品質を向上させるための最も直接的かつ最短の手段ですが、決して根本的な手段ではありません。

•80-20原則

ソフトウェアの欠陥の80％は、ソフトウェアの20％のスペースに発生しています。この原則は、ソフトウェアテストを効果的にしたい場合は、リスクの高い複数の場所にアクセスすることを忘れないでください。ソフトウェアの欠陥が見つかる可能性ははるかに高いです。この原則は、ソフトウェアテスターに​​とってテスト効率と欠陥発見率を向上させる上で非常に重要です。愚かなテスターはまだ目的を持たずに検索しながら、巧妙なテスターはすぐにこの原則に基づいてより多くの欠陥を見つけるでしょう。

80-20原則のもう一つの側面は、システム分析、システム設計、システム実装段階、そしてテスト作業におけるソフトウェアの欠陥の80％を見つけて回避することができるということです。私達は残りの欠陥の80％を識別しました、そしてソフトウェア欠陥の最後の5％はシステムが広範囲の長期間の使用のために届けられた後に初めて明らかにされるかもしれません。ソフトウェアテストでは、できる限り多くのソフトウェアの欠陥を検出することだけを保証できるため、すべてのソフトウェアの欠陥が検出されるという保証はありません。

80-20ソフトウェアテストの自動化の側面にも原則を反映することができますソフトウェアの欠陥の80％は手動テストで発見でき、ソフトウェアの欠陥の20％は自動テストで発見できることが証明されています。この2つが交差しているため、他の方法で発見し修正する必要があるソフトウェアの欠陥は、まだ約5％あります。

•メリットのテスト

プロジェクトの品質と効率を向上させ、最終的にプロジェクトの全体的な有効性を向上させるためにソフトウェアテストを実施するのはなぜですか。このため、ソフトウェアテストの実装で習得すべき程度を簡単に見つけることができます。ソフトウェアテストでは、ソフトウェアテストのコストとソフトウェア品質のメリットのバランスをとる必要があります。このバランスポイントは、ソフトウェアテストを実装するときに従うべき程度です。一方的な追求は必然的にソフトウェアテストの価値と重要性を損なうでしょう。一般的に、ソフトウェアテストでは、物理学者アインシュタインの言葉で言えば、ソフトウェアテストを単純にし、ソフトウェアテストを過度に複雑にしないようにするべきです。

•欠陥の不可避性

ソフトウェアテストでは、間違った相関関係によりすべてのソフトウェアの欠陥を修正できるわけではありません。いくつかのソフトウェアの欠陥は修復することができますが、私たちは修復プロセスの間に必然的に新しいソフトウェアの欠陥を導入します。多くのソフトウェアの欠陥は矛盾しており、矛盾が消えると必然的に別の矛盾が発生します。たとえば、汎用性の欠陥を解決すると、実行効率に問題が生じることがよくあります。さらに、欠陥を修復するプロセスでは、時間とコストの制限があるため、すべてのソフトウェアの欠陥を効果的かつ完全に修復することはできません。したがって、ソフトウェアの欠陥の重要性、影響の範囲、妥協策の選択、またはソフトウェア以外の要因によるソフトウェアの欠陥の考慮（ハードウェアパフォーマンスの向上など）を評価することは、ソフトウェアの欠陥に直面しなければならないという事実です。

•ソフトウェアテストでは期待どおりの結果が得られなければなりません。

期待どおりの結果が得られないテストは不合理です。ソフトウェアの欠陥は比較から派生します。これは、測定する基準がないのと同じです。わからない場合や期待される結果がわからない場合は、テストの正確さを理解できません。多くのテスターは自分の気持ちでソフトウェアの欠陥の発生を判断することが多く、結果として妥当なものを正しい結果として判断することが多いため、誤検出が多いことがよくあります。

•ソフトウェアテストの意味 - 死後分析

ソフトウェアテストの目的は、単純に欠陥を見つけることです。それが「はい」であるならば、私は同様のソフトウェア欠陥が新しいプロジェクトの次のソフトウェアテストで起こることを保証することができます。 「歴史を知らない人は必然的に同じ過ちを繰り返すであろう」と古くからの言い方はうまくいっている。ソフトウェアテストの結果を注意深く分析しないと、欠陥の原因と対策を理解することができません。その結果、ソフトウェアの欠陥を再発見するために多くの人的資源と材料リソースを費やす必要があります。残念ながら、ほとんどのテストチームは現時点ではこれを認識しておらず、テストレポートにテスト結果の分析が欠けています。

結論：

ソフトウェアテストは「意識」を必要とするプロセスであり、テスト担当者としては落ち着いて規模を保持し、基本的に正しい理解をもってソフトウェアテストに応答します。読者がソフトウェアのテストを理解するのに役立ちます。