2

全て、

私は開発者ですが、テストのプロセスと方法について詳しく知りたいです。これにより、テスト チームに製品を提供する前に単体テストを使用してテストできるケースが改善されるため、より堅実なコードを作成するのに役立つと思います。私は最近、ソフトウェア プロジェクトに対するテスト駆動開発と探索的テストのアプローチに注目し始めました。

これで、自分が書いたコードのテスト ケースを簡単に見つけることができます。しかし、私がテスト対象の機能の開発者ではない場合に、テスト ケースを発見する方法を知りたいと思っています。たとえば、さまざまな Web サイトで見られる基本的なユーザー登録フォームがあるとします。それをテストする人がフォームの開発者ではないと仮定すると、フォームの入力フィールドをテストするにはどうすればよいですか?あなたの戦略は何ですか? テストケースをどのように発見しますか? この種のテストは、探索的テスト アプローチの恩恵を受けると思いますが、ここでは間違っているかもしれません。

これについてのご意見をお待ちしております。

ありがとう、バイト

4

10 に答える 10

5

バグ！プロジェクトで新しいテスト ケースを追加するための私のお気に入りの出発点の 1 つは、バグ追跡システムを調べることです。既存のバグはそれ自体がテスト ケースですが、新しいテスト ケースに誘導することもできます。特定のモジュールにバグがある場合、その領域でより多くのテスト ケースを作成する必要があります。特定の開発者が特定のクラスのバグを導入していると思われる場合、その開発者による将来のプロジェクトのテストを導くことができます。

もう 1 つの有用な考慮事項は、テスト ケースよりもテスト手法に目を向けることです。登録フォームの例では、ビジネス要件の観点からどのように攻撃しますか? 安全？同時実行性? 入力の有効/無効?

于 2010-04-01T13:39:29.073 に答える
4

コンピュータソフトウェアのテストは、あらゆる種類の異なるタイプのテストを行う方法についての優れた本です。ブラックボックス、ホワイトボックス、テストケースの設計、計画、テストプロジェクトの管理、そしておそらく私が見逃した多くのこと。

あなたが与える例のために、私はこのようなことをします：

  1. フィールドごとに、有効と無効の両方で入力できる可能な値について考えます。私は境界のケースを探します。フィールドが数値の場合、下限より1小さい値を入力するとどうなりますか？下限を値として入力するとどうなりますか？等。
  2. 次に、MicrosoftのPairwise Independent Combinatorial Testing（PICT）ツールなどのツールを使用して、すべての入力フィールドのケース全体で可能な限り少ないテストシナリオを生成します。
  3. また、ランダム入力を使用してフォームを叩き、結果をキャプチャし、応答が理にかなっているかどうかを確認する自動テストを作成します（キーボードの仮想サル）。
于 2010-04-01T11:18:14.837 に答える
1

フォームの場合、入力できる内容を調べて、そこでさまざまな境界条件をテストします。たとえば、ユーザー名が指定されていない場合はどうなりますか? テストにはいくつかの異なる形式があることを思い出しました。

  1. ブラック ボックス テスト - テスト対象の内部を見ずにテストする場所です。ここでの課題は、内部を見ることができないと、有用なテストと、価値のあるさまざまなテストの数を制限するという問題が発生する可能性があることです. もちろん、これは一部のデフォルトのテストのように見えるものです。

  2. ホワイト ボックス テスト - コードを確認し、コード カバレッジなどの指標を使用して、コード ベースの一定の割合をカバーしていることを確認できます。この場合、何が行われているかについてより多くのことを知っているので、これは通常より良いです。

ロジック テストと比較したパフォーマンス テストもあり、これも注目に値します。たとえば、フォームがこれを行うだけでなく、フォームがどれだけ速く私を検証するかなどです。

于 2010-06-30T21:49:27.103 に答える
1

質問をする。疑問詞のリストを作成し、製品または機能に関する質問を考えてみてください。このようなリストは、ことわざの箱や轍から抜け出すのに役立ちます。何も思い浮かばない場合は、疑問詞に時間をかけすぎないでください。

  • 誰
  • だれの
  • 何
  • どこ
  • いつ
  • どうして
  • どのように
  • いくら

次に、それらに答えるときに、「else」の質問をします。これにより、少なくともしばらくの間、最初の結論に不信感を抱くようになります。

  • 他に誰
  • 他に誰
  • 等..

次に、「否定」の質問をします。自分の仮定を否定または反駁し、それらに異議を唱えます。

  • 誰ではないか (たとえば、この安全な機能へのアクセスを必要としないのは誰で、その理由は?)
  • 何をしないか (ユーザーが気にしないデータは? ユーザーがこのテキスト ボックスに入力しないデータは? よろしいですか?)
  • 等...

質問に対するその他の修飾子は次のとおりです。

  • その他
  • ない
  • W リスク
  • W違う
  • 2 つの質問語を組み合わせます。たとえば、Who と when です。
于 2010-06-30T21:42:31.650 に答える
1

さまざまな観点から仮定を特定します。

  • ユーザーはこれをどのように誤解する可能性がありますか?
  • なぜ私はそれがこのように行動する、または行動すべきだと思いますか?
  • このソフトウェアがどのように機能するかについて、どのような偏見を持っている可能性がありますか?
  • 要件/設計/実装が必要なものであることをどのように知ることができますか?
  • このソフトウェアの優先度、重要性、目標などについて、他にどのような視点 (ユーザー、管理者、マネージャー、開発者、法務) が存在する可能性がありますか?
  • 適切なソフトウェアが構築されていますか?
  • 有効な名前/電話番号/ID番号/住所/その他がどのように見えるか本当に知っていますか?
  • 私は何が欠けていますか？
  • （ここに名詞を挿入）についてどのように誤解される可能性がありますか？

また、ここに記載されているニーモニックとテスト リストのいずれかを使用します。

于 2010-06-30T21:24:24.517 に答える
0

整数の検証やワークフローの手順など、さまざまな種類のタスクに関する一般的な質問と問題の種類を含むテスト カタログを保持します。

于 2010-06-30T21:28:27.767 に答える
0

上部と側面に主要な機能をリストしたデータ テーブルを作成し、各ペア間の可能な相互作用を検討します。これを 3 次元で行うと、扱いにくくなる可能性があります。

于 2010-06-30T21:26:48.443 に答える
0

James BachによるExploratory Testing DynamicsとSatisfice Heuristic Test Strategy Modelを利用します。どちらも、製品についてより広く、または異なる考え方を開始するための一般的な方法を提供します。これは、テストでボックスとヒューリスティックを切り替えるのに役立ちます。

于 2010-06-30T22:33:58.033 に答える
0

グループ ブレーンストーミング セッション。（または必要に応じて非公式にペアで）

于 2010-06-30T21:18:05.743 に答える
0

テストのアイデアについて他の人と話し合う。自分のアイデアを他の人に説明するとき、アイデアを改良または拡張する方法を考える傾向があります。

于 2010-06-30T21:18:51.047 に答える