スライド：
www.slideshare.net/VLDCORP/ss-33747358
パフォーマンスビデオ：
パフォーマンス計画
1.テスト設計
2.要件のテスト容易性をテストする方法
3.テストケースおよび/またはテスターなしでの要件とテスト
4.要件と変更
5.読みやすく、または書きやすい
6.テストケースはどのように配置されますか？
7.どんな困難が生じる
8.それらを克服する方法
まず、自動化に対する一般的な関心が高まっています。これはトレンドであり、これは良いことです。 しかし、 自動化されたテストスクリプトを開発するための「基盤」の必要性は高まっています。 結局のところ、そのような基盤がなければ、スクリプトの作成、使用、保守の複雑さが生じます。 彼らが何をチェックするのか、彼らがどのようにチェックするのか、それらが要件にどのように関係するのかは明確ではありません！ この状況は、これらのスクリプトを開発する人々とこれらのスクリプトを使用する人々、およびこれらのスクリプトが提供する情報を信じる人々によく知られています。
また、次の重要な点は、 テスト自動化のコンテキスト外の上記のすべての重要性です 。 自動テストに関するすべてを手動テストに置き換えれば、まったく同じ結果が得られます！
それで、何が欲しいのでしょうか？
作業を簡素化および高速化し、作業結果の信頼性を高めたい：
-テスター;
-自動テストスクリプトの開発者。
-テスト結果を分析するテストマネージャー（手動/自動）/顧客/将来のユーザーなど
私のレポートは2つの不平等な部分に分けられます。 最初に、テスト設計とは何かを思い出し、2番目にエラーを回避し、同じ「レーキ」をあまり頻繁に踏まない方法を説明します。
要件のテスト容易性をテストする方法
マントラの要件：
- 完全性
- 一貫性
- あいまいさ
- トレーサビリティ
- 実現可能性
- テスタビリティ
- ...
すべての要件を確認する必要があります。 集中する必要がある基本的な基準があります。 要件を確認するときに人がミスをする可能性があります。 したがって、それらを確実にチェックする方法を知る必要があります！ 注意してください、私は完璧なチェックを言っているわけではありません！ これは不可能です！ 少なくとも確実にチェックしてください！
方法1-初期テストケースの設計
つまり、UMLダイアグラム、ストーリー、コメント付きの数回表示されたデザインの使用を開始するとすぐに、設計を開始する必要があります。デフォルトの期間は何ですか。 これにより、テストケースの設計段階で多くのギャップを簡単に検出できます。
方法2-テストケースと要件の接続の視覚化 （この機能がチェックされる場所と方法）
3,000件のテストケースを作成したことが判明する可能性があるため、すべてが素晴らしいものですが、重要なことはチェックしませんでした。 理由は異なります。彼らは忘れていた、理解していなかった、とにかく私たちにとって「自明」だったことを考え、何かを逃しました。 私がこれを指摘しているのは、普遍的な解決策があるからではなく、私たちが毎日これをしているからです！
次の側面、 なぜ要件以外のものが必要なのですか？
比較してみましょう！ 一見したところ違いは非常に単純ですが、実際には深いです！ 要件テストが必要な理由のアイデア。
要件対 テスト中
- 要件 ：何をどのように機能させるかを決定する
- テスト ：何が機能しないか、または機能するはずの方法で機能しないかを判断する
ソフトウェア製品の要件への準拠は、次の質問に答える必要があります。
？ すべての要件が実装されていますか？
？ すべての要件は正しく実装されていますか？
？ 過剰はありませんか？
？ 診断は適切ですか？
「なぜ1000件のケースを書いているのですか。テスターを取り、テストを行うための要件をテスターに提供する方が簡単ではないでしょうか？」 そして、私はいつも違った答えをしなければなりません。 つい最近、私は同じ質問に答えました。「ここで私は1年間、深刻な複雑なプロジェクトを抱えています。要件をテストし、ケースを作成したのは2人のテスターのみです。 1年以内に、テスト担当者はテストケースと分析のおかげで新しいプロジェクトを去り、プロジェクトの本質を取り入れて作業を続けることができました。
多くの場合、彼らはテストを行うことを申し出ると聞いていますが、テストケースやテスターはいません。
テストケースおよび/またはテスターなしでの要件とテスト
-開発者によるテスト-問題はよく知られています（主観、プロジェクト全体の無知、ロジック）
-アナリストによるテスト-テストケースは不要ですか？ （興味深いアイデアですが、常に肯定的なシナリオをテストします）。 要件で機能するものだけをチェックし、正しい動作からのわずかな逸脱も考慮されません。 彼らは線形ケースをチェックしますが、一連の要件、統合テストは実行しません）
もちろん、そのような場合、 テストの質と量は大きく異なります。テストは可能な総量の20％〜30％だけで、重大なエラーは要件に含まれていません 。
私が注意を向けたいもう一つの重要な側面は、開発プロジェクトに参加していて安定したチームがあるとき、私たちは常に状況を話し、意味することです。 プロフェッショナルで協力するチームがあります。 しかし、サポートのためのプロジェクトが与えられることがあります。 別の国のまったく異なるチーム。 あなたはこれらの人々を絶対に知りません、そしてもちろん、要件に問題があります。 多くの開発作業があるため、システムの新しい要件はほとんど行われておらず、メンテナンスが増えています。 これにはすべて、多くの機能を考慮する必要があります。
要件と変更
- バインディングの変更
- サプライズチェンジ
- 変更をコミットする方法
- 要件とテストケースの関係のマトリックス（変更の実装とテストの人件費の評価）
- アプリケーション全体に対する変更の影響
ここでは、テスト設計の側面も重要です。なぜなら、プロジェクトでサポートを求められるたびに、「これまたはその変更をどのようにテストできますか？」という謎を尋ねることになるからです。 。 同時に、テスト設計の準備に関する作業は、その変更前に一度実行されると非常に役立ちます。
そして、これから終了する一般的な部分の最後から2番目の側面は、 データ駆動型テストです。
- 正しく入力されたデータに応じて、 予想される結果が表示されます。
- 要件に記録されていないデータを含む、 誤ったデータに対する適切な応答（対応するエラーメッセージ）
そしてまた：
- 等価クラス
- 境界値
テストケースには個別の手順があり、テストケースで提供されるデータは個別にあります。 データは異なる場合があり、テストケースの手順は安定しているため、多数の状況を確認できます。 テスト状況は言うまでもなく、データ依存の効果がある場合、データ駆動型は非常に重要です。
そして、私が言及したい別の側面は、要件の粒度です 。 詳細は多少詳細になります。 しかし、ここに生じるニュアンスがあります。要件が詳細である場合、維持するのは困難ですが、使いやすいです。 そして、詳細がほとんどない場合、使用するのは困難ですが、保守は簡単です。 妥当な妥協案を見つけることができます： 要件に応じた チェックリストとテストですが、よく知られているリスクが常に含まれます。
レポートの2番目の部分に移ります。
テストケースの構造はよく知られています。以下で説明しますが、人類は新しいものを思いつきません。
彼らがテストケースの構造について書いていること
テストケースには以下が含まれます。
-フォーマット;
-コンテンツ;
形式はどこでも同じです。
-ステップのシーケンス番号。
-システムへの影響。
-期待される結果。
そして覚えておいてください！ 悪魔は細部に宿っています！
フォーマットを比較すると、すべての人が同じであることがわかります。 フォーマットの分析と比較：
- 実質的に同じ：
- あなたはまだ本、インターネットで検索することができます...
- コンテンツは形式に適していますか？
ここに例を示します。
表に注意してください。シリアル番号、アクション、入力したデータ、および予想される結果があります。 そして、私たちは何を見ますか？
まず、予想される結果が間違った場所に表示され、次にアクションの誤った説明が表示されます（「ボタンが使用できない場合、クリック」-質問は、ボタンが使用可能かどうか）、予想される結果の数値が正しく表示されない（3桁の場合数、小数部など
正式には、すべての瞬間が含まれていますが、これらのアクションでは、必要なテストが欠落している可能性があるため、製品の品質に関する信頼できる情報を取得できません。
データドリブンテストとはよく知られています 。 しかし、私たちはそれをより詳細に提供します。 データ拡張が簡単
ステップをデータから分離する
1.リンク付きの個別の説明
2.データと期待される結果の関係
手順
1.テストケースを完了するためのアクション
2.ナビゲーションルール
データ
1.ユーザーが入力および/または選択および/またはクリックすること（フィールド、リスト、...）
2.期待される結果
テストケースの構造（説明） 。 形式を変更します。
- ステップ番号
- システムへの影響
- データへのリンク（必要なリンクの種類）
- 期待される結果（データやイラストへのリンクの可能性があります）
そして、そのような変更の結果として何が得られるのでしょうか？
「すべて」、「任意」、「正しい」、「期待される」などの用語の頻繁な使用に加えて、「データを入力する」ということを除いて、すべてが素晴らしいです。
テストケースの構造に関する次の提案 。 取り除く：
- 「可能性のあるすべてのデータに対して手順5〜73を繰り返す」などのループ
- タイプ「any」、「appropriate」のデザイン。 「適切」、「予想される」、必要な説明なし、例えば：
通知、他に何かありますか？
はい、これは、正しい期待される結果の確認を得るためにテスターが連絡しなければならない外部ドキュメントへのリンクです。 ここでは、レポートの名前「テスト設計：読みやすく、または書きやすい」を思い出します。
何を提案しますか？
データの準備に特別な注意を払いたいと思います。 テストケースはどのような状況でも実行できることは明らかです。 システムは特定の状態にある必要があり、この状態は満杯でなければなりません。 データを準備するために、数百のステップを含むいくつかのアクションを実行する必要がある場合があります。 したがって、使用するデータを記録することは非常に重要です。 さらに良いのは、顧客が使用するデータを正確に取得する機会がある場合です。
データ ：
1.役割、意味
2.データウェアハウスリンク（クエリ）
データ準備 ：
1.前提条件（データベースステータス）
2. SQLクエリの実行
3.テストケースの形式のアクション
提案されたソリューションは、ステップとデータセットの複雑さに関する合理的な妥協案です。 2つまたは3つの同様のテストケースを作成する価値があり、データセットの量を1桁（繰り返しのために）減らすことができます。 これにより、テスターは迷わず何かを見逃すことがなくなり、開発者はスクリプトコードからテストケースの説明へのマッピングを簡単に作成できるようになります（スクリプトの分析と保守に必要です）。
はい、私たちはテスト設計で彼らの仕事を複雑にしますが、その品質を高めます。 テスト設計はテストで最も難しいものです。 同様のテスト設計は2つありません。 ほとんどの場合、私の実践では、継続的にテスト設計を導入すると、手動および自動のテスターをテストする手間が省けます。 そしてもちろん、これには高度な資格を持つテスト設計者が必要です。 あなたはテスター、さらには開発者やトレーニングを受けて、優れたテストデザイナーを得ることができます。 それは、人が通りからこれを教えることができないということだけです。