1

開発サイクルの終わり近くにプロジェクトに参加するとします。このプロジェクトは多くのチームに受け継がれ、全体的に自由に利用でき、テストは一切行われていません。このチームの他のメンバーはテストの知識がなく（恥ずかしいです！）、各メソッドの単体テストは現時点では実行不可能のようです。

この時点で、ユーザビリティテスト以外に、製品をテストするための推奨戦略は何でしょうか。これは通常、手動のポイントアンドクリックで期待される出力/実際の出力作業で立ち往生しているポイントですか？

4

5 に答える 5

2

私は通常、テストにボトムアップのアプローチを取りますが、この場合はトップダウンにしたいと思います。単体テストをラップできる最大のコンポーネントをテストし、それらがどのように失敗するかを確認します。これらの失敗は、どのサブコンポーネントが独自のテストを必要とするかを示しているはずです。これを行うと、かなりむらのあるテストスイートができますが、これは始まりです。

于 2009-05-21T14:05:06.643 に答える
2

予算がある場合は、テスト自動化スイートを入手してください。HP / Mercury QuickTestはこの分野のリーダーですが、非常に高価です。アイデアは、ユースケースを通じてGUIを駆動することにより、マクロのようなテストケースを記録することです。フォーム（web、.net、swing、ほとんどすべての種類のGUI）に入力を入力すると、エンジンはフォーム要素の名前を学習します。次に、GUIとデータベースで期待される出力を確認できます。次に、失敗するはずの無効なケースを含むさまざまなテスト入力の表またはスプレッドシートをプラグインして、必要に応じて数百のシナリオを実行できます。テストが記録されたら、生成されたスクリプトを編集してカスタマイズすることもできます。それはあなたのために最終的に何が失敗したかを正確に示すきちんとしたレポートを作成します。

ほぼ同じことを実行するが機能が少ない、安価で無料のGUI自動化テストスイートもいくつかあります。一般に、スイートの価格が高いほど、手動でのカスタマイズは少なくて済みます。このリストをチェックしてください：http ：//www.testingfaqs.org/t-gui.html

于 2009-05-21T14:32:21.470 に答える
0

これが優れた品質保証テストの出番だと思います。昔ながらのテストケースを書き、チームの複数の人に渡してテストします。

于 2009-05-21T14:02:13.793 に答える
0

この時点で、ユーザビリティテスト以外に、製品をテストするための推奨戦略は何でしょうか。

製品の機能仕様を知っている（または開発できる）人/人によるコード検査をお勧めします。

極端で純粋な言い方をすれば、「テストは一切行われず、全体的に自由である」ため、既存のテストでも、コードでも、開発者も、開発プロセスも、管理も、プロジェクトについては何もありません。さらに、テストによってソフトウェアの品質が向上することはありません（品質は開発プロセスの一部として組み込まれている必要があります）。高品質の製品を手に入れる唯一の方法は、高品質の製品を作ることです。この製品のビルドには品質がなかったため、再構築する必要があります。

  • 既存のソースコードを使い捨てのプロトタイプまたはドキュメントとして扱います
  • オプションで古いソースコードの適切なフラグメント（存在する場合）を組み込んで、新しい製品を1つずつ作成します。

ただし、コード検査を実行する（およびコード検査で見つかった欠陥を修正する）方が速い場合があります。これは、機能テストに追加されるものです。

テストするだけでなく、自動テストの開発に余分な時間を費やすかどうかは、ソフトウェアを保守する（つまり、将来、何らかの方法でソフトウェアを変更してから再テストする）かどうかによって異なります。それ）。

また、次のものが必要です。

  • また：
    • 機能仕様（および非機能仕様）の知識
    • 手がかりを持つ開発者および/またはQAの人々
  • または：
    • 小さくてシンプルな商品
    • 忍耐強く、寛容なエンドユーザー
    • 製品納品後の継続的な技術サポート
于 2009-05-21T15:12:29.130 に答える
0

ライフサイクルのこの時点でプロジェクトに参加するときに開発プラクティスに組み込む1つの手法は、欠陥が報告されたときに単体テストを追加することです（QAまたはエンドユーザーによって）。既存のコードベースの完全なコードカバレッジを取得することはできませんが、少なくともこの方法で、将来の開発を推進し、テストによって文書化することができます。また、この方法では、実装に取り​​組む前にテストが失敗することを確認する必要があります。テストを作成しても失敗しない場合は、テストに問題があります。

さらに、システムに新しい機能を追加するときは、少なくともそれらのサブシステムがテストされるように、テストでそれらを開始します。新しいシステムが既存のシステムと相互作用するので、古い境界層の周りにテストを追加してみて、時間をかけて作業してください。これらは単体テストではありませんが、これらの統合テストは何もないよりはましです。

Refactoring is yet another prime target for testing. Refactoring without tests is like walking a tight rope without a net. You may get to the other side successfully, but is the risk worth the reward?

于 2012-09-04T18:57:44.180 に答える