これはすでに行っていることですか、それとも優れたツールを知っていますか?
目標:最近のソースの変更がリスクにどのように影響するかをチームが理解し、テストの取り組みをどこに集中すべきかをチームが理解できるようにします。時間をかけてデータを提供し、それを開発サイクルの計画フェーズと範囲設定フェーズにフィードバックします。
計画: svn 変更データを clover 複雑性データと組み合わせて、複雑性または変更リスクに対する変更の影響を示すレポートを作成します (行数 x 複雑性 = リスク?)。完璧ではありませんが、チームが変更をよりよく理解するのに役立つ可能性があります。
誰もこれを試しますか？もしそうなら、どのツールを使用しましたか?また、この合図をチームに提供することはどのようにうまくいきましたか?
私の経験では、新しい機能が追加されたとき、または欠陥が修正されたときに、テストとリスクが特定されます。これはすべて、私のすべての仕事で「手動」で行われました。
あなたのアイデアは興味深いものです。基本的には、以前の欠陥の統計と変更されたファイルの複雑さの分析に基づいてテストに焦点を当てる CI サーバー タイプのプラグイン/コンポーネントです。
テストケースには明らかにコード/ファイルのマップが必要であり、その逆 (失敗したテストケースと修正のために変更されたファイル) がある場合は、その情報の一部を自動的に生成する方法があります。
「リスク」には「開発者」コンポーネントも含まれているのではないかと思います。つまり、一部の開発者は、他の開発者よりもチェックインに対して本質的に高い「リスク」を持っています。これは、一部の機能にもローカルである可能性があります...場合によっては、「開発者」が最優先コンポーネントになります。リスクを完全に軽減するか、確実にするかのいずれかです。 .