2

我不知道这是否可行,但我们有一个存在大量品牌问题的应用程序,其中对话框和错误消息显示我们产品的旧名称现已更改。这些盒子到处都是,许多是从各个窗口的捕获块中调用的。为了测试一切是否按预期工作,我希望我可以创建某种可以在我的程序中引发异常的外部工具,并允许 QA 使用它。

我无法真正更改实际代码(尤其是强制异常的代码),但我在想也许我制作了一个辅助程序,它只是为一些愚蠢的事情分配所有内存,然后下次点击我的真实应用程序会抛出一个内存异常。这看起来有道理吗?有没有更简单的方法来实现这样的事情?

4

1 回答 1

1

当然,包含品牌的对话框的数量是有限的吗?在代码库中搜索您启动对话框的每个位置并进行更正。

您可以通过设置sikuli以在所有预期的故障模式下捕获屏幕截图来自动化测试,然后搜索这些屏幕截图(使用 sikuli 的搜索机制)以查找您担心的品牌。

如果您确定这是一个内存分配问题会触发所有这些对话框,那么编写一个 RAM 填充应用程序是相当简单的。只需分配大小不断减小的块,直到内存不足,然后使用 Sikuli 单击按钮并捕获结果。您很可能会发现,如果内存分配是问题所在,并且您正在风中运行,那么您的测试就会失败。如果你有严重的内存泄漏,你应该修复它们,而不是把它交给你可怜的 QA 团队!

于 2012-06-19T14:30:49.587 回答