如何自动对 Windows 驱动程序和二进制文件进行防病毒/WSUS 补丁测试?

发布于 2024-11-11 18:50:52 字数 617 浏览 2 评论 0原文

我的(相当小的)公司开发了一款流行的 Windows 应用程序,但我们一直在努力解决的一件事是测试 - 它通常仅由开发人员在与他们开发它的系统类似的系统上进行测试,并且当推送更新时对于客户来说,我们的一部分客户群由于 Windows 补丁的一些奇怪功能而遇到问题,或者在某些偏执的防病毒应用程序的情况下(我正在看着你,Comodo 和卡巴斯基!),他​​们会错误- 对我们的应用程序持积极态度。

我们对 70% 的用户使用的内容进行手动测试,但过程缓慢且痛苦,有时还不够完整。管理层一直坚持认为我们需要做得更好,但在发布时他们一直在这个问题上押注(测试需要多长时间?只要推出它,我们就会向遇到问题的客户发布补丁!)。

我想使用虚拟机设计一个更好的自动化测试系统,但可以使用一些关于如何实现它的想法,或者如果有 COTS 产品,任何建议都会很棒。我正在编写一个Python脚本来“运行”我们产品的每个功能,但我不确定如果我们遇到Windows崩溃如何进行测试(除了检查它是否仍在进程列表中),或者更糟糕的是,如果 Comodo 出于某种愚蠢的原因标记了它。

为了最好地模拟测试环境,我试图使虚拟机尽可能保持“纯净”,并且不要在操作系统和防病毒软件以及一些常见应用程序(Acrobat Reader、Firefox 等)之外加载大量垃圾。

任何想法将不胜感激!

My (rather small) company develops a popular Windows application, but one thing we've always struggled with is testing - it frequently is only tested by the developers on a system similar to the one they developed it on, and when an update is pushed out to customers, there is a segment of our base that experiences issues due to some weird functionality with a Windows patch, or in the case of certain paranoid antivirus applications (I'm looking at you, Comodo and Kaspersky!), they will false-positive on our app.

We do manual testing on what 70% of our users use, but it's slow and painful, and sometimes isn't as complete as it should be. Management keeps insisting that we need to do better, but they keep punting on the issue when it comes time to release (testing will take HOW LONG? Just push it out and we'll issue a patch to customers who experience issues!).

I'd like to design a better system of automated testing using VMs, but could use some ideas on how to implement it, or if there's a COTS product out there, any suggestions would be great. I'm hacking a Python script together that "runs" every feature of our product, but I'm not sure how to go about testing if we get a Windows crash (besides just checking to see if it's still in the process list), or worse yet, if Comodo has flagged it for some stupid reason.

To best simulate the test environment, I'm trying to keep the VM as "pure" as possible and not load a lot of crap on it outside of the OS and the antivirus, and some common apps (Acrobat Reader, Firefox etc).

Any ideas would be most appreciated!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

滥情空心 2024-11-18 18:50:52

有趣的问题。要避免的一件事是使用防病毒 API 来检查您的应用程序是否触发它们。您希望在预期的操作系统上真正实时部署您的应用程序,并通过真正的实时 AV 安装来监控它。这样,您将触发启发式监控以及 API 使用的简单“此代码是否与校验和匹配”。

您还没有告诉我们您的应用程序是用什么编写的,但是如果您的应用程序的测试套件实际上测试了应用程序的部分内容,而不是测试单个代码路径,那么这可能是一个好的开始。理想情况下,您的集成测试套件与您用于检查部署目标上的问题的测试套件相同。您的集成测试应该验证实时环境中每个测试的输入和输出,这应该捕获崩溃等。另外,不要忘记检查是否需要比应有的时间长得多的事情,不幸的是,这是一种常见的故障模式。最重要的是,您的测试套件需要足够容易编写、更改和改进,以使其实际上与产品保持同步。没有测试所有内容的测试是没有用的,而没有运行的测试甚至更糟。如果我们有更多关于您的程序如何工作的信息,我们可以就如何实现自动化提供更好的建议。

您可能需要一套跨预期部署目标、处于各种修补(和取消修补)状态的 VM 映像。对于某些应用程序,您需要为每个 IE 变体提供一个单独的虚拟机,因为这会改变系统的其他方面。请非常小心每个虚拟机中的事物组合。一次不要测试多个 AV。在运行测试之前更新快照中的 AV。如果您的映像中有足够大的组合软件,您可能需要自动创建映像 - 获取基本系统构建,更新到最新的补丁级别,然后编写 AV 和其他应用程序组合安装的脚本。

是的,维护这个虚拟机场将是一件痛苦的事情,但是如果您编写应用程序部署脚本,并且有良好的快照以及修补和更新快照的计划,那么实际的测试套件本身应该不会花费那么长时间来运行给定适当的硬件。您需要研究 VM 解决方案,但我可能会从 VMWare 开始。

Interesting problem. One thing to avoid is using the antivirus APIs to check to see if your application triggers them. You want a real live deployment of your application, on the expected operating system, with a real live AV install monitoring it. That way you'll trigger the heuristics monitoring as well as the simple "does this code match that checksum" that the API works with.

You haven't told us what your application is written in, but if your test suite for your application actually exercises portions of the application, rather than testing single code paths, that may be a good start. Ideally, your integration test suite is the same test suite you use to check for problems on your deploy targets. Your integration testing should verify the input AND the output for each test in a live environment, which SHOULD catch crashes and the like. Also, don't forget to check for things that take much longer than they should, that's an unfortunately common failure mode. Most importantly, your test suite needs to be easy enough to write, change, and improve that it actually stays in sync with the product. Tests that don't test everything are useless, and tests that aren't run are even worse. If we had more information about how your program works, we could give better advice about how to automate that.

You'll probably want a suite of VM images across your intended deploy targets, in various states of patch (and unpatch). For some applications, you'll need a separate VM for each variant of IE, since that changes other aspects of the system. Be very careful about which combination of things you have in each VM. Don't test more than one AV at a time. Update the AVs in your snapshots before running your tests. If you have a large enough combination software in your images, you might need to automate image creation - get a base system build, update to the latest patch level, then script the installation of AV and other application combinations.

Yes, maintaining this farm of VMs will be a pain, but if you script the deploy of your application, and have good snapshots and a plan for patching and updating the snapshots, the actual test suite itself shouldn't take all that long to run given appropriate hardware. You'll need to investigate the VM solutions, but I'd probably start with VMWare.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文