テストをテストするポストテストでは 、ロジックを別のモデルの形式で複製し、それと比較することにより、プログラムの検証に関する私の見解を説明しました。 単体テストは特別なケースとして実行されました。
今回は、提示されたアイデアに基づいて、ソフトウェア検証のレベルを評価する一般的なアプローチを策定しようとします。
はじめに
ソフトウェアを開発する際、実際、特定のサブジェクト領域の形式化に取り組んでおり、その結果、それを記述するモデルが出現します。
モデルの実装の精度は、モデルの外部の例と比較することによってのみ確認できます。
- 元のサブジェクトエリア-操作用のソフトウェアを起動する。
- 同じサブジェクトエリア用に開発された別のモデル。
もちろん、モデルを比較するとき、「同期」ほど関係するのは検証ではありません。違いが検出されると、2つのモデルのどちらにエラーがあるかを明確に言うことができないためです。
ロジックの複製が機能する理由
させてください：
- モデル1を開発するとき、エラーの確率はp1です。
- モデル2を開発する場合、同じエラーを起こす確率はp2です。
次に：
- 2つのモデルで同時にこの間違いを犯す確率はp1 * p2です（テキストを短くするために、これらは独立したイベントであると想定しています）。
- これは通常、最初の確率よりはるかに少ないです。
このグラフは、2つのモデルで同じエラーが発生する確率の変化を表示し、記事に重みを追加するように設計されています。
これらの考慮事項から、同じ間違いをする確率が異なるように、異なる原則に基づいて組織されたモデルを選択することが望ましいということになります。 それ以外の場合、検証はエラーのクラス全体をスキップし、このタイプのモデルの確率は1になる傾向があります。
テストモデルが元のモデルの機能の一部のみを対象とする場合、コンポーネントごとに検討するのが合理的です。テストモデルがコンポーネント全体を閉じるかしないかです。
一般的な検証方法
ソフトウェアの品質を改善するための最も一般的な方法を見て、それぞれが個別のドメインモデルの形成とその主要なモデルとの比較に基づいていることを示しましょう。
これを行うには、メソッドが異なる場合があるプロパティを定義します。
- 実装方法-複製モデルの実装方法。
- 検証方法-モデルの比較方法。
テスト（自動、半自動、手動）
実装方法：環境の作成を実装し、ターゲットモデルの結果を検証するコード（または人間の行動のアルゴリズム）。
検証方法：テストまたはテスターの手作業でプログラムコードを呼び出します。
静的解析
実装方法：モデルは、テストソフトウェア内のルール、たとえば、コンパイラ、パイリント、PVS-Studioによって指定されます。 特別な場合、追加の仕様が存在する場合があります。たとえば、タイプの説明、アルゴリズムの拡張仕様（例： habrahabr.ru/post/251751 ）。
検証方法：外部検証者を呼び出して、ターゲットモデルのコードを分析します。
ペアプログラミングとコードレビュー
実装方法：モデルはパートナーの頭にあります。
検証方法：モデルと記述内容のコンパニオンコンパニオン。
完全なシステム複製
実装方法：別のチームによって開発されたターゲットモデルの完全な類似物。
検証方法： 2つのモデルの状態とそれらの機能の結果を比較します。
タイピングに関するいくつかの言葉
私の意見では、それは別の検証方法とは考えられませんが、より正確に以下に起因します：
- 静的分析（静的な場合）;
- 動的かどうかをテストします。
したがって、タイピングには、対応するメソッドのすべての機能があります。
これらの考慮事項はどのように使用できますか？
テストプロセスを整理する際の議論を強化し、プロジェクトの「検証」のためのもっともらしいメトリックを取得できます。
指標
頭に浮かぶ最も単純なメトリックは、ターゲットシステムの複製によるカバレッジのレベルです。 つまり、元のシステムの各機能が繰り返すテストモデルの数。
- 最小カバレッジ-元のモデルの機能ごとのモデルの最小数。
- 平均カバレッジ-機能ごとのモデルの平均数。 たとえば、元のシステムをコンポーネントに分割し、各コンポーネントのカバレッジをカウントして平均を計算することができます。
テストプロセスの構成
プロジェクトとチームの機能を知っていれば、私たちにとって便利な方法で品質管理の種類を選択できます。
たとえば、最小カバレッジを1にすることを確立できます。 機能ごとに少なくとも1つの複製モデル。
この要件に基づいて、テスト部門のすべてのリソースを100％UIテストに導き、内部コンポーネントについては、単体テストを作成する開発者を選択します。
別の方法として、プロジェクト全体でテスト部門の取り組みを塗りつぶし、0.5モデル（専門家評価）のカバレッジを取得しますが、特に重要なコンポーネント（カバレッジは1.5に等しくなります）のペアプログラミングに余分な人を送ることで開発者の労力を節約します。
まとめ
もちろん、この記事では、発見の主張はありません。 しかし、ソフトウェア開発を整理するプロセスにより多くの形式と妥当性を追加する試みがあります。