1.テストの必須部分は、期待される結果を決定することです。
2.プログラマは、独自のプログラム（およびコードセクション）のテストを避ける必要があります。
3.プログラムを作成する組織は、独自のプログラムのテストを避ける必要があります。
4.テストプロセスには、各テストの結果の徹底的なチェックを含める必要があります。
5.正しい入力条件と予想される入力条件の両方、および誤った予測と予期しない入力の両方についてテストケースを作成する必要があります。
6.システムが本来すべきことを実行していないという事実を調べることは、戦いの半分に過ぎません。 2番目の部分は、彼女が何をするかを理解することです。
7.プログラム自体が1回限りでない場合にのみ、1回限りのテストケースを避けます。 ワンタイムプログラムのワンタイムテストケース。 他の場合には、それらは避けるべきです。
8.エラーを検出しないプリセットを使用してテストプロセスを行わないでください。
9.システムの特定の部分のエラーの確率は、ここですでに見つかったエラーの数に比例します。
10.テストは、創造力と知的能力に対する挑戦です。 テストは非常に創造的で知的活動です。
原則1：テストの必須部分-期待される結果の決定
見落とされたときに明らかになるこの原則は、テストプロセスで最も一般的なエラーの原因です。 ここでも心理学が介入します。 結果がどのように見えるかを前もって理解していない場合、真実ではなく類似した何かが正しい結果として認識されます。 結局のところ、「見たいものを見る」。 言い換えれば、テストの破壊的な性質にもかかわらず、どこか深いところで、正しい結果を確認したいという欲求がまだあります。 しかし、これは断固として戦わなければなりません。 たとえば、すべての出力と期待される結果の詳細な早期調査を奨励することにより。 これは、テストケースに2つのコンポーネントが含まれている必要があることを意味します。
-入力の説明
-指定された入力に対する正しい出力の正確な説明。
容認できる説明がなく、奇妙に見え、期待や偏見と一致しない何かに遭遇すると、問題が発生する可能性があります。 このようなものに会うとき、少なくともいくつかの一般化されたアイデアが必要です。もしあなたがそれらを持っていなければ、潜在的な問題を見逃すのは簡単だからです。 待っていません-驚きはありません。
原則2：プログラマーは、独自のプログラム（およびコードスニペット）のテストを避ける必要があります
すべての作家は、自分の作品を編集することは悪い考えであることを知っています-または知る必要があります。 たとえば、本の特定の章が正確に何を言っているかを知っているので、それが他のことを言っていることに気付かないかもしれません。 そして、どういうわけか彼らは仕事の間違いを探したくないのです。 ソフトウェア製品の作者についても同じことが言えます。
もう1つの問題は、フォーカスの変更です。 プログラマーが創造的にコードを設計および作成している間、破壊的な波への再構成は非常に困難です。
すべての住宅所有者は、壁紙の作成が非常に難しいことを知っています。 しかし、これらの壁紙も自分で掛けた場合-耐えられないほど憂鬱です。 同様に、ソフトウェアを使用する場合、ほとんどのプログラマーはプログラムを効果的にテストできません。エラーを特定するためにメンタル調整を行うことができないためです。 さらに、同僚、マネージャー、顧客、または所有者からの罰に対する潜在意識の恐怖は、間違いの回避につながる可能性があります。
そしてもう1つの問題：プログラムには、タスクまたは仕様の誤解によって引き起こされるエラーが含まれる場合があります。 その場合、テストプロセス自体にこの誤解の派生物が含まれる場合があります。
これは、プログラマーのために私たち自身のプログラムをテストするパスが閉じられていることを意味しません。 他の誰かがそれを行う方が良い（より効率的）です。 開発者は、仕様とコード自体を評価するときに、テストチームの役に立つメンバーになることができます。
その他。 これはデバッグプロセスではありません。 この場合、コードの作成者がプロセスの最も効果的な参加者です。
原則3：プログラムを作成する組織は、独自のプログラムのテストを避ける必要があります。
引数は前の原則と同じです。 多くの点で、個人としてソフトウェアを作成する組織には、心理的な問題があります。 さらに、私たちの最高の世界では、組織またはその管理者の仕事は、多くの場合、時間通りに一定のコストでプログラムを作成する能力によって判断されます。 その理由は、数量化が困難な信頼性とは対照的に、これらの数量の数量化が容易だからです。 したがって、開発組織が自社製品のテストに効果的であることは困難です。 この評価は、勤務スケジュールとコストの順守に基づいている場合があります。
ここで、自社製品のテストプロセスへの組織の参加が必ずしも無意味であるとは言えません。 ここでは、このような作業を独立した当事者が実施することが最も経済的に成功していると言います。
原則4：テストプロセスには、各テストの結果の徹底的なレビューを含める必要があります。
これは明らかですが、見落とされがちです。 出力リスト（結果）でその症状が明確に区別できる場合でも、エラーを検出できなかった多くのケースに慣れています。 別の言い方をすれば、後続のテストで見つかったエラーは、以前のテストの結果では気付かないことがよくあります。
原則5：テストケースは、正しい入力条件と期待される入力条件の両方、および誤った予期しない入力条件の両方に対して設計する必要があります。
テストプロセス中に許容できる条件に期待することは、自然で強力な傾向です。 許容できない予期しない条件を無視することも当然ですが、冷静ではありません。 ソフトウェア製品を何らかの新しい方法または予期しない方法で使用すると、多くのエラーが明らかになります。 ユーザーが製品を使用するすべてのシナリオを決定することは不可能ですが、プログラムの穏やかで馴染みのあるコースとは異なる何かが（バグを見つける際に）成功する可能性がすべてあるようです。
原則6：システムが何をしないか、何をすべきかを調べることは、戦いの半分に過ぎません。 2番目の部分は、彼女が何をするかを理解することです。
これは、以前の原則の結果です。 また、プログラムは望ましくないサードパーティの影響をチェックする必要があります。 たとえば、給与チェックを正しく発行する給与計算ソフトウェアには、存在しない従業員に対して追加の小切手を発行する場合、または個人ファイルの最初のレコードを書き換える場合、エラーが引き続き含まれます。
原則7：ワンタイムプログラムのワンタイムテストケース;それ以外の場合は、そのようなテストを避ける
この問題は、プログラムをテストするためのさまざまなシステムに現れることが多いようです。 典型的なプラクティスは、コンピューターの前に座り、その場でテストを開発し、プログラムでこれらのテストケースを実施することです。 要するに、テストケースは貴重な投資であり、特定の環境のフレームワーク内では、テストプロセスが完了するとすぐに消滅する可能性があります。 また、ソフトウェアテストを繰り返し行う必要がある場合（回帰テストまたはシステムの改善時）、テストケースには新しい開発が必要になる場合があります。 これは、テストエンジニアが回避するために選択できる追加の難しい作業である会議です。 仕事へのその後の努力は、最初の膨大で質的なものと同じくらいめったにないことがわかります。 また、たとえば、機能の変更がエラーを伴う場合、新しく開発されたテストではエラーが検出されない場合があります。
原則8：プロセスを事前にテストしないで、エラーを見つけないようにします
プロジェクトマネージャーと小さなベルでよくある間違いは、誰かがテストプロセスを誤って決定することです。 たとえば、プログラムが正しく機能していることを実証するプロセスとして。 別の定義を受け入れます（これを行わない人もいますが）。これは、エラーを見つけるという強い意図を持ってプログラムを実行するプロセスです。 完全にエラーのないソフトウェア製品を開発することは不可能であることは明らかです。 十分に実行されたテストおよびエラー修正プロセスの後でも、エラーがまだ存在すると想定するのが適切です。 まだ見つかっていないだけです。
原則9：システムの特定の部分のエラーの確率は、ここですでに見つかったエラーの数に比例します。
このことは疑わしいように思えるかもしれませんが、そのような現象は多くのプログラムで観察されています。 指では、これはその方法です。プログラムがモジュールAとBで構成されていると仮定します。モジュールAでは5つのエラーが見つかり、モジュールBでは1つのエラーしかありませんでした。 そして、モジュールAがまだ完全にテストされていない場合、原則は次のように言います。モジュールAでさらに多くのエラーを見つける確率は、モジュールBでさらに多くのエラーを見つける確率よりも高いです。
この原則を説明する別の方法は次のとおりです。エラーにはグループに参加する意思があり、典型的な場合、特定のプログラムブロックは他のプログラムブロックよりもエラーを起こしやすいです。 魔法のように見えますが、サポートされていない魔法です。 テストプロセス中にある程度の理解とフィードバックを提供するので便利です。 プログラムの一部が他の部分よりもエラーを起こしやすいと思われる場合、この現象は、ここでもう少しテストする方が良いことを示唆しています。 そして、これは投資に関する質問です。
写真さえあります：
原則10：テストは、創造力と知的能力に対する課題です。 テストは非常に創造的でインテリジェントです。
間違いなく、これはそうです。 ソフトウェア製品のテストに必要な創造的能力は、このソフトウェア製品の作成に必要な創造的能力を超えています（そうです）。 洞察力のあるテストを設計するための多くの方法と手法がありますが、あなたの創造的な努力が適用されない限り、これはすべて高いままではありません。