これが可能かどうかはわかりませんが、ブランディングの問題がたくさんあるアプリがあり、ダイアログとエラーメッセージに、現在変更されている製品の古い名前が表示されます。これらのボックスはいたるところにあり、その多くはさまざまなウィンドウのキャッチブロックから呼び出されます。すべてが意図したとおりに機能していることをテストするために、プログラム内で例外をスローし、QAがそれを使用できるようにする何らかの外部ツールを作成できることを望んでいました。
実際のコード（特に例外を強制するコード）を実際に変更することはできませんが、すべてのメモリをばかげたものに割り当てるだけのサイドプログラムを作成して、実際のアプリを次にクリックすると、出力がスローされるのではないかと考えていました。メモリ例外の。これはもっともらしいと思いますか？このようなことを達成するためのより簡単な方法はありますか？
確かに、ブランディングを含むダイアログボックスの数には有限の制限がありますか？ダイアログを起動して修正するすべての場所のコードベースを検索します。
予想されるすべての障害モードでスクリーンショットをキャプチャするようにsikuliを設定し、それらのスクリーンショットを（sikuliの検索メカニズムを使用して）検索して、気になるブランドを探すことで、テストを自動化できます。
これらすべてのダイアログをトリガーするのがメモリ割り当ての問題であることが確実な場合、RAMフィルアプリケーションの作成は非常に簡単です。メモリがなくなるまでサイズが減少し続けるブロックを割り当て、Sikuliを使用してボタンをクリックし、結果をキャプチャします。メモリ割り当てが問題であり、テストが失敗するほど風の近くで実行している場合は、よくわかるかもしれません。そのような深刻なメモリリークがある場合は、貧弱なQAチームに渡さないように修正する必要があります。