[テスト]ソフトウェアテストの基本的な概念の基礎

テスト中に発生する問題

私は、すべての機能のより包括的なテストかどうかわかりません
テストカバレッジを測定することができません
新バージョンの繰り返しテストを実施することは困難です
冗長なテストの多くは、テスト効率の影響があります
リークテストを受けやすい、テストを繰り返し
テスターがない明確な目標、低効率

ソフトウェアのテストケースの概念

テスト環境の要素、工程、試験データ、期待される結果等：テスト（テストケース）が試験されているシステムに提供されるテスト実施形態のコレクション含むグループセットです。
（「試験」と呼ばれる）テストシーンとテストケースの塩基（または「共通テスト」と称する）：これは、一般的に、単純なテストに分けることができます。

テストケースの設計法

等価クラス
境界値
フランスのシーン
エラー外挿
原因と結果の図
状態マップ
直角に配置されました
パスカバレッジ

テストケースの設計の長所と短所

利点
- 有効
- 整合性
- 主催
短所
- テストケースのデザインは、多くの場合、それが実行にかかる時間よりも多くのテストケースを設計するために時間がかかり、時間のかかる仕事です
- メンテナンスコストが高くなりますによってもたらされたテストケースの蓄積と、徐々にメンテナンスの難しさを増加します
- テストケースの実装では効率が低いです
- 需要の変化は、書き込みテストケースが無価値になる原因

テストケースの要素

元素組成およびテストケースの役割

ユースケース番号：テストスイートの数全体でこのユースケース

表示モジュール：テストに対応するテストモジュール

ユースケースのタイトルは：明確にテストケースをテストすることです表明何の問題は（/テストオブジェクトは、テスト対象が含まれています）

手順：テストステップ中に行われます

テストデータ：テストケースの実行を使用するために必要なデータ

期待される結果：テストデータ入力、望ましい結果を得るためにどのように

テストは、テストデータ入力、実際に得られた結果：実際の結果

によって作製

書き込み時間

実行例の優先度を持つ：テスト優先

テストケースの設計の基本原則

製品の欠陥を見つけ、バグを見つけるために設計・テスト・ケースは、あなたが要求仕様をコピーすることはできません
フロントデザインのテストケースは、機能的なニーズを満たすべき要件の仕様は、カバレッジが100％でなければなりません
バックのデザイン/テスト異常、間違って、異常なテストケース

テストの役割

全体のテスト活動の基礎
に従ってテストタスクを完了するために、テストエンジニアガイド
試験結果の重要な単位であるかどうか
テスト時間節約とテスト効率を向上させます
知識移転/緩やかな改善/テストリポジトリ
テスターの進行テスター、テストスケジュールワークロード、および追跡/管理を評価または調整

テストケース管理

TAPD
禅
Jria
TestLinkの
秀でます
他の同様のツールなど

デザインのテストケースに必要な品質

試験方法
包括の問題を考えてみましょう
ビジネスの深い知識
リバース思考
テストでの豊富な経験

テストケースの更新と保守

その理由は、更新され、維持される必要があります
- 需要の変化、機能変更、テスト・ケースを更新する必要があります
- テストケースは、洗練かつ継続的に改善する必要があり、それは漸進的なプロセスであり、
- テストケースをテストすることによって証明され、追加、変更、テスト・ケースを削除
テストケースは、正式かつ効果的な審査を通過します
テストケースを管理するためのテスト・ツールを使用します

28個の原則

モジュールによるエラーが20〜80％
1. ユーザの観点から、方向から開発、実装の観点、試験焦点の主要コンポーネントの正しい選択、ないようにずれません。
テストコストの80％は、ソフトウェアモジュールの20％を費やし
1. 傾斜コアコンプレックス20％設計モジュールの場合、テストケースことにより、より効率的な設計に時間を費やす必要があります。
時間の80％は、ソフトウェアモジュールの20％をテストに費やします
1. ソフトウェアのテストプロセスの実行時間のニーズは、モジュール内の重要なテストケースで傾斜するように、より効果的なテストし、見つかったバグを修正しました。
バグの80％が常にモジュールの20％に存在します