6

何百ものユーザー アクションが考えられるアプリケーションがあり、メモリ リーク テストをどのように強化するかを考えます。

ソフトウェアを手動でテストするときに、アプリケーションがメモリを消費しすぎているように見える場合は、メモリ ツールを使用して原因を特定し、修正します。これはかなり遅く、効率の悪いプロセスです。問題が発見されるのが遅く、1 人の開発者の善意に依存しています。

どうすればそれを改善できますか?

  • 一部のアクション（「ファイルを閉じる」など）がメモリを回復してログに記録することを内部的に確認しますか？
  • 単体テスト内のメモリ状態をアサートします (ただし、これは面倒な作業になるようです) ?
  • 時々手動で定期的にチェックしますか？
  • 新しいユーザー ストーリーが実装されるたびにそのチェックを含めますか?
4

5 に答える 5

3

防御の最前線:

  • 開発者向けの一般的なメモリ割り当て関連エラーのチェック リスト
  • コーディングのガイドライン

第二の防衛線:

  • コードレビュー
  • 静的コード分析 (ビルド プロセスの一部として)
  • メモリ プロファイリング ツール

アンマネージ言語 (C/C++ など) を使用している場合は、メモリ管理関数をハイジャックすることで、ほとんどのメモリ リークを効率的に発見できます。たとえば、すべてのメモリ割り当て/割り当て解除を追跡できます。

于 2009-01-07T15:18:40.023 に答える
1

問題の核心は、メモリリークをいつテストするかを知ることほど、メモリリークを見つけることではないように思われます。あなたはたくさんのユーザーアクションがあると言いますが、どのユーザーアクションのシーケンスが意味があるのか​​は言いません。意味のあるシーケンスをランダムに生成できるのであれば、ランダムテストについては一生懸命議論したいと思います。ランダムテストでは、

  • コードカバレッジ（gcovまたはvalgrind）
  • メモリ使用量（とvalgrind）
  • ユーザーアクション自体のカバレッジ

「ユーザーアクションの範囲」とは、次のようなステートメントを意味します。

  • アクションAとBのすべてのペアについて、Aの直後にBが続く意味のある一連のアクションがある場合は、そのようなシーケンスをテストしました。

それが当てはまらない場合は、ペアAとBのどの部分が当てはまるかを尋ねることができます。

CPUサイクルに余裕がある場合はvalgrind、ソースコードリポジトリへのすべてのコミット前またはナイトリービルド中に、実行または別のメモリチェックツールを使用することもおそらくメリットがあります。

自動化！

于 2009-01-08T00:13:21.927 に答える
0

newとdeleteをカスタム バージョンに置き換え、割り当て/割り当て解除のすべての行為をログに記録します。

一般的に言えば (テストについてではなく、問題の発生源と戦うためです)、スマートポインターはこの問題を回避するのに役立ちます。幸いなことに、C++11 標準では、新しい便利なスマート ポインター クラス ( shared_ptr、unique_ptr) が提供されています。

于 2013-09-29T17:25:37.963 に答える