経験則に基づいて、テストに必要な労力を開発に必要な労力のパーセンテージとして見積もる人はいますか？もしそうなら、あなたは何パーセントを使いますか？
131092 次
10 に答える
15
私の経験から、25％の努力が分析に費やされています。設計、開発、単体テストで50％。テスト用に残りの25％。ほとんどのプロジェクトは、プロジェクトの性質、リソースの知識、入力と出力の品質などに応じて、この経験則の+/- 10％の変動内に収まります。これらのパーセンテージ内で、または10〜15％の範囲内で頭上に頭上。
于 2013-03-20T23:55:20.067 に答える
11
Google Testing Blogは最近、この問題について議論しました：
したがって、素朴な答えは、ライティングテストには10％の税金がかかるということです。しかし、私たちは何かを返すために税金を払います。
（をちょきちょきと切る）
これらのメリットは、今日だけでなく明日も真の価値につながります。私はテストを作成します。なぜなら、私が得る追加のメリットは、10％の追加コストを相殺する以上のものだからです。長期的なメリットを含めなくても、今日のテストから得られる価値はそれだけの価値があります。テストを使用したコードの開発が速くなりました。それはコードの複雑さに依存します。構築しようとしているものが複雑になるほど（if /ループ/依存関係が増える）、テストのメリットは大きくなります。
于 2009-10-20T15:17:33.663 に答える
8
テストを見積もるときは、テストの範囲を特定する必要があります。単体テスト、機能、UAT、インターフェイス、セキュリティ、パフォーマンスストレス、およびボリュームについて話しているのでしょうか。
ウォーターフォールプロジェクトに参加している場合は、おそらくかなり一定のオーバーヘッドタスクがいくつかあります。計画文書、スケジュール、およびレポートを準備するための時間を確保してください。
機能テストフェーズ（私は「システムテスター」なので、これが私の主な参照ポイントです）については、計画を含めることを忘れないでください。多くの場合、テストケースを実行するには、要件/仕様/ユーザーストーリーから抽出するのに少なくとも同じくらいの労力が必要です。さらに、欠陥の発生/再テストのための時間を含める必要があります。大規模なチームの場合は、テスト管理（スケジューリング、レポート、会議）を考慮する必要があります。
一般的に、私の見積もりは、開発作業の割合ではなく、提供される機能の複雑さに基づいています。ただし、これには少なくとも高レベルの命令セットへのアクセスが必要です。何年にもわたってテストを行うことで、特定の複雑さのテストの準備と実行にx時間の労力がかかることを理解できます。一部のテストでは、データのセットアップに余分な労力が必要になる場合があります。一部のテストでは、外部システムとのネゴシエーションが必要になる場合があり、必要な労力をはるかに超える期間があります。
ただし、最終的には、プロジェクト全体のコンテキストでレビューする必要があります。あなたの見積もりがBAまたは開発の見積もりをはるかに上回っている場合は、基礎となる仮定に何か問題がある可能性があります。
これは古いトピックであることは知っていますが、これは私が今再検討していることであり、プロジェクトマネージャーにとって長年の関心事です。
于 2013-03-14T23:36:06.277 に答える
3
数年前、セーフティクリティカルな分野で、10行のコードを単体テストする日のようなことを聞いたことがあります。
また、開発に50％、テストに50％の労力を費やしました（単体テストだけでなく）。
于 2009-10-20T15:18:47.663 に答える
3
自動化されたユニット/統合テストまたは手動テストについて話しているのですか？
前者の場合、私の目安（測定に基づく）は開発時間に40〜50％追加されます。つまり、ユースケースの開発に10日かかる場合（QAと重大なバグ修正が発生する前）、適切なテストの作成にはさらに4〜5日かかります。 -ただし、これは開発後ではなく、開発前と開発中に行うのが最適です。
于 2009-10-20T15:19:00.907 に答える
3
テスト時間は、おそらく開発時間よりも機能範囲と密接に関連しています。また、テスト時間は開発チームのスキルと相関関係があると（おそらく物議を醸すように）主張したいと思います。
6〜9か月の開発作業では、テストするソフトウェアに精通している実際のテスター（開発チームではない）が実行する、絶対に最低2週間のテスト時間を要求します（つまり、2週間は立ち上げ時間は含まれません）。これは、最大5人の開発者がいるプロジェクト用です。
于 2009-10-20T15:19:46.660 に答える
3
テストについて話すときは、ウォーターフォールまたはアジャイルテスト開発を意味する可能性があります。アジャイル環境では、開発者は時間の50％をテストの開発と保守に費やす必要があります。
ただし、その50％の追加により、リファクタリングと手動検証の時間が来たときに時間を節約できます。
于 2009-10-20T15:28:32.953 に答える
3
2006年10月のGartnerは、テストは通常、システム統合プロジェクトの作業の10％から35％を消費すると述べています。ウォーターフォール方式にも当てはまると思います。これは非常に広い範囲ですが、標準製品のカスタマイズの量と統合するシステムの数には多くの依存関係があります。
于 2012-01-30T09:26:48.163 に答える
1
テストのために余分な時間を考慮に入れるのは、使用するテストテクノロジに慣れていない場合のみです（たとえば、Seleniumテストを初めて使用する場合）。次に、ツールの速度を上げ、テストインフラストラクチャを適切に配置するために、おそらく10〜20％を考慮に入れます。
それ以外の場合、テストは開発の本質的な部分であり、追加の見積もりを保証するものではありません。実際、私はおそらくテストなしで行われたコードの見積もりを増やすでしょう。
編集：私は通常、テストファーストでコードを書いていることに注意してください。事後にやって来て、物事を遅くする既存のコードのテストを書かなければならない場合。非常に探索的な（使い捨ての）コーディングを除いて、テストファースト開発が私を遅くすることはまったくありません。
于 2009-10-20T15:21:17.523 に答える
1
昨日の天気で判断してください。前回はどれくらいかかりましたか？トレンドは長くなっていますか、それとも短くなっていますか？お店ごとに違います。
ほとんどのアジャイルショップは、TDDのおかげで、必要な時間が大幅に短縮され、欠陥が大幅に少なくなり、それらを解決するための時間が短縮されます。それでも、ほとんどのアジャイルショップでは、テスト/QCにかなりの時間を費やしています。
これがこのアプリケーションの最初のテスト実行である場合、答えは「見てみましょう」とそれに続く試行です。それは、質問に答える速さ、-テスト可能性、-機能/機能の数-発見された欠陥の数、-問題の解決の速さ、-コードがテストを繰り返す回数、および-方法によって異なります。多くの場合、テストはバグによってブロックされます。言う方法はありません。あなたはそれを50％または175％以上と呼ぶことができます、そしてそれは間違いではありません。大まかな推測をして、円周率を掛けてみませんか？それはあなたが作ることができる他のどの答えよりもそれほど悪くはありません。
現在どのくらいの時間がかかるか、速くなっているのか遅くなっているのか、カバレッジが増加しているか減少しているのかを知る必要があります（しなければなりません）。これらの3ビットの情報を使用すると、非常によく推測できるはずです。
于 2009-10-20T23:08:14.550 に答える