テストに費やす時間を削減するには？

Question

最近ほとんど終了したプロジェクトを振り返り、非常に深刻な問題が見つかりました。私はコードのテストに多くの銀行の時間を費やし、異なる状況を再現することでコードエラーが発生する可能性があります。

テストに費やされる時間を短縮する方法を共有するためのアイデアや経験がありますか？そのため、開発がはるかにスムーズに行われますか？

私はすべてのコードに対してテストドリブンのコンセプトに従ってみましたが、これを達成することは本当に難しいことがわかりました。ここのシニアの人たちの助けが本当に必要です。

おかげ

は再：ここで上記の回答のためのすべての

おかげで、最初に私の質問は、一般的なテストに時間を短縮する方法でしたが、今、問題がダウンeffecient自動化を作成する方法にありますテストコード。

私はこの時間を短縮するためにテストスーツを書く方法について私のスキルを向上させようとします。

しかし、私はエラーを再現するために費やした時間を削減する方法はまだまだ苦労しています。例えば、標準のブログプロジェクトは、エラーを引き起こす可能性がある状況を再現しやすいでしょうが、複雑な個別システムは、 "簡単にテストすることができます、それは合理的ですか？このようなプロジェクトでどのようにテスト計画を立てるべきか、ご存じですか？

さらなる回答をいただきありがとうございます。

Answer 1

テスト駆動型設計は、テスト（品質保証）に関するものではありません。それは当初からよく知られていませんでした。

マシンの実行可能な前提条件とプログラムの動作仕様を持つことについてのことであり、プログラムの実行中にプログラマが想定していることを明確にするためです。

これらのタスクは、製品ライフサイクルのある時点で実行されなければならないため、単純に作業の移行です。それが多かれ少なかれ効率的かどうかは、別の時間の議論です。

あなたが参照しているのは、テストを呼び出さないということです。強いTDDを持っているということは、テスト段階が、テストビルドに達するずっと前に捕らえられるであろうエラーのために大きく依存している必要はないことを意味します（非TDDの良いスペックと反応性のあるステークホルダーを経験しているプログラマー環境）。

先験的なテスト（実行可能な仕様）が深刻な問題だと思うなら、開発の相対的な段階で時間と費用がかかると予想されます。

Answer 2

を生産的にテストしている場合は、多くの時間を費やすことに本質的に間違っていることはありません。テスト駆動型開発とは、（ほとんど自動化された）テストをまず書くことを意味します（これは、徹底的なテストスイートを作成する場合、合法的に長い時間がかかります）。テストの実行には時間がかかりません。

Answer 3

Subversionチームは、プロセス全体を自動化することによって、pretty good test routinesを開発しました。

新しい機能を実装する前に、というテストを書くなど、このプロセスを自分で使い始めました。それは非常にうまく動作し、プログラミングプロセス全体を通じて一貫したテストを生成します。

SQLiteには、それが完了した方法についてのvery good documentationのある適切なテストシステムもあります。

Answer 4

あなたの問題のように聞こえるのは、自動テストを行っていないということです。自動化されたユニットテストと統合テストを使用すると、テストに費やす時間を大幅に短縮できます。

Answer 5

テストドリブン開発で私の経験では、テストを書き留めた後、または少なくともベーステストケースを書いた後は、時間を節約することができます。ここで重要なことは、あなたが実際にあなたの自動テストを書く必要があるということです。あなたの質問を表現する方法は、あなたが実際に自動化されたテストを書いていないと信じさせます。あなたのテストが書かれたら、簡単に後で戻って、以前に見つけられなかったバグ（より良い回帰テストのために）をカバーするようにテストを更新し、コードを簡単かつ比較的迅速にリファクタリングすることができます。あなたが実質的にそれを変更した後も、期待どおりに動作します。

Answer 6

重要なサイズのプロジェクトについて最も難しいことの1つは、基盤となるアーキテクチャーとAPIを設計することです。このすべてはユニットテストのレベルで公開されています。テストを最初に書く場合、プログラムのロジックではなく、テストをコーディングするときにデザインのその部分が発生します。これは、コードをテスト可能にする努力を加えたものです。一度テストを受けると、プログラムのロジックはかなり明白です。

これは、地平線に面白いautomaticテストビルダーがあるようです。今行くといくつか:)

アイデアは、あなたがコードが何をすべきかを考える手助けするためのテストを使用することで、彼らは一部だ見つける -

Answer 7

まず、それはあなたが助けを必要とすることを認識することが良いことですあなたのデザインの時間。

また、コードの総所有コストについて考える必要があります。最初に修正されるのではなく、生産に至るバグの費用はいくらですか？あなたが銀行にいる場合、数字を間違えることに重大な影響がありますか？時には、適切なものはちょうど時間がかかります。

Answer 8

ご理解いただけると思います。開発者テストレベルの上には、顧客テストレベルがあります。そのレベルでは、多くのバグを見つけているようです。

あなたが見つけたすべてのバグに対して、テストハットを取り除き、再現帽子をかけて正確な再現戦略を見つけなければなりません。その後、バグを文書化する必要があります。おそらくそれをバグ追跡システムに入れる必要があります。その後、テストハットを置く必要があります。その間、あなたが作業していた設定を失ってしまい、あなたが行っていたテスト計画がどこにあったのか分からなくなりました。

今、それが起こらなければならない場合 - バグが非常に少ない場合は、テスト中に右に詰めることができますか？

GUI駆動テストの自動化がこの問題の解決に役立つかどうかは疑問です。テストの記録と保守に多大な時間を費やすことになり、その回帰テストに投資を返すのにかなりの時間がかかります。最初は、GUIを使用した顧客対応テストではるかに遅くなります。

本当に助けになるものは、開発活動から生じる高次/初期/コードの品質です。元の意味での開発者テストまたはテストドリブン開発とも呼ばれるマイクロテストは、これを本当に助けるかもしれません。助けになる別のものはペアプログラミングです。

あなたが他の人とペアを組むことができないとすれば、私はあなたのバグ追跡システムを見て1時間を費やすでしょう。私は過去100の欠陥を見て、それらを根本原因に分類しようとします。 "トレーニングの問題"は原因ではありませんが、 "1つのエラーでオフ"かもしれません。

分類して数えたら、スプレッドシートに入れて並べ替えます。どのような根本的な原因が発生したとしても、あなたが最初に防ぐ根本的な原因が最も多い。あなたが本当に空想を得たい場合は、根本的な原因にそれが引き起こす痛みの量であるいくつかの数を掛けます。 （例：100個のバグには、簡単に修正できるメニューと30個の再現できないJavaScriptエラーがあります）。それらの根本的な原因のそれぞれにいくつかの魔法の「修正」を適用しますが、それは一撃の価値があります。例：IE6の透過アイコンは、IE6が.pngファイルを簡単に処理できないためです。したがって、チェックイン時に.gifを拒否するバージョンコントロールトリガがあり、問題は修正されています。

私は役立つことを願っています。

Answer 9

はあなたが書いた：

「感謝をここに上記の回答のために、 最初に私の質問は、一般的なテスト、 に時間を短縮 する方法でしたが、今、問題が書き留め する方法にあります効率的な自動テスト コード。

複数の実験的研究で試験効率を最大にするために非常によく働くことが実証された1つの方法は、コンビナトリアル試験である。このアプローチでは、テスト担当者はテスト対象の種類を特定し（簡単なツールに入力します）、ツールはアプリケーションのテスト方法を特定します。具体的には、ツールは、どのテストスクリプトで実行されるべきテスト条件の組み合わせを指定するテストケースを生成し、各テストスクリプトを実行する順序を指定します。

たとえば、August, 2009 IEEE Computer article I co-wrote with Dr. Rick Kuhn, Dr. Raghu Kacker, and Dr. Jeff Leiでは、私はあるテスターのグループが標準的なテスト設計方法を使用し、同じアプリケーションをテストする第2のテスターグループを使用し、コンビナトリアルテストケースジェネレーターを使用してテストケースを特定しました。コンビナトリアルテストケースジェネレータを使用しているチームは、平均して、テスタ時間当たり2倍以上の欠陥を発見しました。それが効率性の強い証拠です。さらに、コンビナトリアルテスターは全体で13％多くの欠陥を発見しました。それは品質/徹底性の強い証拠です。

これらの結果は珍しいことではありません。このアプローチに関する追加情報はhttp://www.combinatorialtesting.com/clear-introductions-1とツールの概要hereにあります。これには、スクリーンショットと、カバレッジを最大限にするテストのサブセットを特定することによって、ツールがより効率的にテストを行う方法の説明が含まれています。

また、当社のHexawiseテストケース生成器の無料版は、あなたの答えのためのwww.hexawise.com/users/new