定期的な予約モデルを徹底的にブラックボックステストするには、どのテストシナリオが必要かつ十分ですか？

Question

非常に包括的なテストドライバーを作成しようとしているカレンダーの予定のジャンゴモデルがあります。定期的な予定はある時点で発生し、無限に実行するか、一定の回数繰り返すことができます。この予定は、Googleカレンダーの予定で使用できる機能を反映しています（毎月、毎年、毎週、2週間ごと、3年ごとに繰り返すことができます）。

この実装の基本を徹底的にテストする単体テストを考えています。最も基本的なテストを定義するエッジケースを探しています。

基本的なものはたくさんありますが、最も重要なケースの特定に役立つ提案を探しています。 1）単一の予定を作成する 2）毎週繰り返される予定を作成する 3）...毎月繰り返します 4）2週間ごとに繰り返す 5）2か月ごとに繰り返す 6）毎年繰り返します

Answer 1

月の最後の日、うるう年、および年が1秒余分になったときに気が狂うかどうかをテストします（これはzuneプレーヤーのドライバーにヒットします）。

テストは、年を超えてもうまく動作します。

とはいえ、フレームワークの一部である何かを再テストするかどうかを検討してください。日付ロジックのテストは非常に速くなるため、アプリケーションの一部とフレームワークの一部について線を引く必要があります。

Answer 2

うるう年の2月29日の年間再発をテストすることを忘れないでください;）

Answer 3

シナリオのガタガタを始める前に、要件の理解に基づいてテスト計画を立てる必要があります。

ユーザーベースおよび他の可能性のある/将来のユーザーベースを検討します（優先順位を下げる）。彼らは主に何のためにそれを使用し、それらのユースケースは彼らのビジネスでどれだけ価値がありますか？

理想的には、アプリのモデルを作成し、そこから始めます。

実行する予定のリスク分析を確認します。次に、機能、セキュリティ、ローカリゼーションテストなどの実行を計画します。

その後、「リスク」の程度に基づいてシナリオについて考え始めることができます。それらは（リスク分析から）です。 「リスク」の作成と実行に焦点を当てる最初のもの。

リスクの分析とそれをどのように使用するかについてのビジネスインプット（可能な場合はサインオフ）を取得します。

ランダムなシナリオを投げ捨てるのは良いテスト方法ではなく、開発者から得られるすべてのall笑に値します。テストは、より巧みに計画された演習である必要があります。路上で誰でも雇って、頭の一番上に来るシナリオを実行できます。

そうは言っても、前述のシナリオが試行され、真実であることに同意します。良いアイデア。また、夏時間のテストも実施します。別のメールクライアントを使用します。空き時間情報を公開してみてください。開発者にこの情報の公開方法を説明してもらいます。 Webサービス経由ですか？ Exchangeユーザーのみがこれを使用することを期待していますか？日付の形式が異なるさまざまな国の誰か？その後、弱点を見つけて、さらにバグを見つけることができます。

ハッピーテスト。