私たちのチームには、テストケース管理に関する問題が提示されています。テストケース内のテストケース、賢明か悪い考えですか？
1人がテストケース内にテストケースを構築することを提案していましたが、1つのレイヤーには達しないという問題がありました。
テストケースA - テストケースB - テストケースC
これの問題は、テストケースB及びCは、静的データれなければならない、ということです。動的なデータにすることはできません。テストケースCは動的データを持つことができないので、他のテストケースのカスタムデータに対応するためにテストケースD +を構築する必要があります。
例：
テストケースCがフェイスブックにログインしています。ユーザー名とパスワード用の2つのカスタムデータフィールドを持っています
しかし、元のテストケース（A）からカスタムデータフィールドを定義することはできません。私たちはデータを静的にする必要があります。ログインする代わりに、特定の人物としてログインしてください。
だからテストケースDは、我々は、男性としてログインする必要があり、特定の人物としてログインしているので、Facebookのに行くとF.ウェルにMから自分の性別のプロフィールを更新することであると言うことができます。
ここで、この人に写真が0枚あると仮定します。しかし、User2にはテスト用の写真がたくさんあります。
ここで、ケースCをテストするために同じテストケースを作成する必要がありますが、ログインの資格情報は異なります。
これで、まったく同じことを行うが、データが異なる2つのテストケースがあります。
私はこの方法に同意しませんが、オンラインではこれがテストケースを構築する最善の方法の1つであると言われています。
私の意見では、実際のテストケースに制限されたテストステップと、ダイナミックおよびジェネリック情報を含む事前条件をすべて保持する必要があります。
したがって、テストケースAの代わりにテストケースBの事前条件があります。 私たちは、テストケースBには事前条件または「BLAHとしてのFacebookへのログイン」があります。
「ログイン」機能をテストしていないため、通常のテストステップを実行したり、余分なテストを行う必要はありません。
私たちのテストがダムであり、アプリケーションの使い方を知らないと仮定していないので、私たちは一般的なものにすることができます。
テスターが事前条件をジェネリックに見つけた場合は、詳細を調べてください。
他の人の思考とは何ですか？テストケース内のテストケースはスマートなアイデアですか？私たちの問題は、私たちのアプリケーションが巨大でスーパーダイナミックであることです。クレイジーダイナミックのように、画面上で何を見るか、置き換えられたり、完全に削除されたりすることがあります。
私たちがこの道を辿ると、私たちは1000のテストケースを見て、簡単に2000のテストケースに変わってしまいます。
思考？私はこれを考えていますか？
なぜテストケースCのデータは静的でなければならないのですか？ –