この記事では、生年月日(DOB)機能のテス
この機能は多くの用途を持っているので非常に重要です。
これらの用途の中には、セキュリティや識別などの分野が含まれています。
テストケースを自由に使用し、ニーズに合わせて修正してください。
続行する前に、テストケースの作成についてもっと学びたいと思うかもしれません。
目次
生年月日の機能をテストする必要がある重要なものは何ですか？
生年月日は一つのフィールドだけです。
しかし、私の意見では、ユーザーのプロフィールを登録する際に最も重要なフィールドの一つです。
要素を分解してみましょう;
- 日(テキストフィールド)
- 月(テキストフィールド)
- 年(テキストフィールド)
- すべての要素が有効ですか?
生年月日機能を使用するシナリオ
- アカウント/ユーザー登録
- 製品またはサービスに登録するときのユーザーの年齢の確認
- ユーザーが一連のセキ8645>
上記のシナリオについて詳しく説明しましょう
シナリオ1:生年月日のテストケース–ユーザーの年齢の検証
年齢検証は非常に多くの異なるプラット 以下は、考慮する必要があるいくつかのテストシナリオです。
- ユーザーはソーシャルメディア/電子メールアカウントを作成したいと考えており、13歳以上である必要があります。
- ユーザーは英国の暫定運転免許証を申請しています。 最低年齢は17歳です。
- 制限された製品またはサービスをオンラインで購入する。 たとえば、年齢チェックを行う必要がある制限されたYouTubeの動画を見ています。
シナリオ2: 生年月日のテストケース-ユーザーが
- を忘れたときのログイン資格情報のリセットユーザーが資格情報を忘れたとき、システムはユーザーの身元を証明するた
シナリオ3:生年月日のテストケース–システムの管理者ユーザーが一連のセキュリティ質問の一部としてDOBに尋ねる
- ただし、上記のシナリオと同様 このシナリオでは、アプリケーション管理者ユーザーが、呼び出し元のユーザーが実際に自分が誰であるかを確認し、DOBが一連のセキュリティ検証質問の一部で
ビジネス要件と機能要件
テストが高品質になる場合は、常にいくつかの要件を試してみる必要があります。
私はいつも私の非テストの同僚に、仕様ベースのテスターとして、私たちは私たちが持っている要件と同じくらい良いことを伝えます。
私のビジネスアナリストの友人に注意してください。
私があなたのために作成したいくつかの例の要件を分解してみましょう。
私は詳細にしようとしましたが、船外に行きたくありません。
可能であれば、常にすべてのプロジェクト要件を保存できる要件トレーサビリティマトリックス(RTM)を作成してみてください。
要件ID 要件の説明 メモ REQ-DOB-0001 システムは生年月日をキャプチャする必要があります。 REQ-DOB-0002 生年月日は英国形式でなければなりません。
たとえば、フィールドの日付形式は以下の順序でなければなりません。
DD/MM/YYYY
D=日（数値形式）M=月（数値形式）Y=年（数値形式）ドロップダウンオプションが必要な場合、UIは13歳の最小開始日を更新して表示できます。
手動入力も可能です。REQ-DOB-0003 手動DOBフォーム入力
システムは、生年月日を手動で入力するオプションをユーザーに与える必要がありますこの要件を拡張して、日付/カレンダ制御オプ
ただし、簡単にするためにmanual formオプションを使用します。
ユーザビリティの観点から見ると、日付ピッカーは退屈ではなく、検証の問題が発生する傾向が少なくなります。REQ-DOB-0004 ユーザー年齢制限
最低ユーザー年齢は13歳です。
システムは、現在の日付から13歳未満のユーザーを自動的に拒否する必要があります。REQ-DOB-0005 日フィールド検証
日フィールドは、1から31までの有効な数値でなければなりません。
DFBR1–Day Fieldビジネスルール1
システムは、1未満および31を超える値を拒否する必要があります。REQ-DOB-0006 Monthフィールド検証
有効なmonthフィールドは、1から12までの数値になります。
月1は1月を表し、月12は12月を表します。
MFBR1–Monthフィールドビジネスルール1
ユーザーが月を数値として入力すると、システムは日の値が正しいかどうかを検証する必要があります。REQ-DOB-0007 Yearフィールド検証
yearフィールドは4文字の数値で、現在の年から125年以内に戻る必要があります。
たとえば、今日が2021年9月1日の場合、システムが最も早い日付は1896年9月1日です。110歳以上の生きている人がたくさんいるので、結果として私はaを追加しましたが、より多くの不測の事態を追加しました。 REQ-DOB-0008 うるう年の検証
人がうるう年に生まれた場合、システムは検証する必要があります。
生まれた年は実際にはうるう年でした。
うるう年以外では誕生日を3月1日にデフォルトします。
入力した年が正しくない場合は、エラーメッセージが表示されます。注:一部の国では、うるう年を2月28日に不履行にすることは違法とみなされています。
この場合、3月1日を使用するという英国の法的観点を使用する。REQ-DOB-0009 正しい日付の検証
ユーザーが生年月日全体を入力すると、システムはその有効性をチェックする必要があります。
ビジネスルール1:
日が正しい月に準拠していることを検証します。REQ-DOB-0010 生年月日計算 User Journey
テストケースには、通常、正と負の検証が含まれます。 次のようになります;
- ユーザーが登録ページに移動します
- プロンプトが表示されると、ユーザーが無効な生年月日を入力します
- ユーザーが有効な生年月日を入力します（誤って13歳未満）
- 13歳未満の場合に登録できないというエラーメッセージが表示されます
- ユーザーが正しい生年月日を入力します出生(13歳以上)
- システムは日付を処理し、正しいものとして検証します。
生年月日のテストケースの例
ステップ番号 テストステップ 要件ID 期待される結果 実際の結果 ステータス（合格/不合格） 正/負のテスト 1 テスト対象アプリケーション（AUT）のユーザー登録フォームページにアクセス) ユーザーはユーザー登録ページに移動します。 + 2 生年月日フィールドをスキップし、フォームの残りの部分に有効なデータを入力します 有効なデータは、生年月日フィールドを除くすべてのフィールドに入力されます。 + 3 否定的なテストシナリオ
‘day’フィールドに=>32などの無効な数値を入力します。日フィールドには無効なエントリが入力されます。例:32/MM/YYY
注:32/MM/YYY
注:32/MM/YYY
注: 要件の記述方法に応じて、この時点で、またはすべての日付フィールドが入力されると、アプリケーションでエラーメッセージが表示されることがあります。– 4 ‘month’フィールドには、ユーザーは有効な数値を入力します。 有効な数値が入力されます + 5 「年」フィールドに、ユーザーは正しい値を入力します。 正しい生年が入力されます。 + 6 ユーザーは”送信”をクリックします’ “日”フィールドが正しくないことを警告するエラーメッセージが表示されます。
注:ユーザーが修正できるように、すべてのフィールドには手動で入力されたデータが入力されます。
フィールドはまだ編集可能です。.+ 7 否定的なテストケース
日フィールドに、ユーザーは空白を入力します。他のすべてのフィールドはまだ入力され、日フィールドは空白のまま更新されます – 8 ユーザーが送信をクリック “日”フィールドが正しくないことを警告するエラーメッセージが表示されます。
すべてのフィールドには、ユーザーが修正を行うことができるように、入力された手動データが入力されます。.+ 9 ビジネスルール
のテスト’日’フィールドに、ユーザーは値’31’を入力します。値’31’が日フィールドに入力されます。 – 10 monthフィールドに、ユーザーは値09
を入力します注:9=September値’09’はMonthフィールドに入力されます。 11 [年]フィールドに、ユーザーは正しい値を入力します。
. 1985‘Year’フィールドに正しい値が入力されます。 12 ユーザーは”送信”をクリックします’ ‘useful’エラーメッセージが表示されます。
このメッセージは、9月に31日がないことをユーザーに通知します。
それに応じて修正してください。13 ユーザーは日の値を次のように修正します30 日のフィールドは”30″でpopulagtedです。 14 ユーザーは”送信”をクリックします’ システム;
a)フォームを処理します
b)生年月日を検証します
c)ビジネスルールに対して検証します
ユーザーを登録確認ページにリダイレクトします。私はこのテストケースをあまりにも長くしたくありませんでしたが、いくつかのテストステップを追加して確実にすることもできます;
- ユーザーが13歳以上である
- 2月29日に生まれたユーザーは、生年月日として1月にデフォルト設定されています（うるう年を除く）。
- 年が現在の日付から125年を超えていないことを検証します。
calendarコントロールがある場合、マウスで日付を選択する”もの”は、これをテストする方がはるかに簡単です。
これは、機能テストが少なく、準備するテストデータが少ないためです。
登録プロセスの一環として、パスワード変更機能のテストケースも検討することができます。
境界値分析
以下は、あなたが考えたいと思うかもしれないいくつかの境界値です。
境界1 境界2 0 -13 13 > 等価パーティション
このテストの一部としていくつかのパーティションがあります。
Age
パーティション1 パーティション2 0-12 >13 あなたの回帰テストスイートに素晴らしい追加
私はこのような詳細な機能テストが大好きです。 どうして？
私は回帰テストパックに追加することができますので。
すべての複雑な詳細を取得したら、文字通りこれらのテストを必要なときに実行できます。
手動テストか自動テストかにかかわらず。
要約
うまくいけば、上記は生年月日の機能テストのための良いテストケースでなければなりません。
私は私のキャリアの中で多くをやって覚えているように、私は絶対にブラックボックステスト技術のこれらのタイプが大好きです。
日付フィールドのテストに遭遇したことがある場合は、カレンダーアプリケーションのテストケースを書くことにも興味があるかもしれません。
品質保証の分野で働くことは容易ではありませんが、これはソフトウェアテスターであることの多くの課題の一つです。