我不知道这是否可行，但我们有一个应用程序，它有大量的品牌问题，其中对话框和错误消息显示我们的产品的旧名称现已更改。这些盒子遍布整个地方，许多都是从各个窗口的捕获块中调用的。为了测试一切是否按预期工作，我希望我可以创建一些可以在我的程序中引发异常的外部工具，并允许QA使用它。
我无法真正对实际代码进行更改（特别是强制异常的代码），但我想也许我制作了一个只为所有内存分配所有内存的副程序然后下一次点击我的真实应用程序抛出一个内存不足的异常。这看起来似乎有道理吗？有没有更简单的方法来实现这样的目标？
答案 0 :(得分：1)
当然，包含品牌的对话框数量有限吗？在代码库中搜索启动对话框的每个位置并进行更正。
您可以通过设置sikuli来捕获所有预期失败模式中的屏幕截图，然后搜索这些屏幕截图（使用sikuli的搜索机制）来查找您担心的品牌，从而实现测试自动化。
如果您确定这是一个会触发所有这些对话框的内存分配问题，那么编写一个RAM填充应用程序是相当简单的。只需分配不断减小的块大小，直到内存不足然后使用Sikuli单击按钮并捕获结果。您可能会发现，如果内存分配是问题，并且您正在运行接近风的测试失败。如果你有严重的内存泄漏，你应该修理它们，而不是把它交给你可怜的QA团队！