主测试环境-应该是通用操作系统还是未来的操作系统?

肯定是主环境。

你不应该假设,因为你的应用程序在Windows7上运行良好,所以它将在XP上运行。这两个操作系统版本之间有无限多的更改,可能会中断。理想情况下,您应该在您支持的每个操作系统上进行测试,这可能是不可能的,但主要的是要确保它在您的主要目标上工作。

测试您支持的内容。在那之后,测试您在不久的将来需要支持什么,最后,让开发人员测试“尖端”的/beta/rtm/alpha操作系统。

例如,如果你支持XP,那么它是测试的主要操作系统,如果做得好,测试该操作系统的资源应该是最少的,如果你的下一个版本支持Vista,那么,将Vista引入测试循环,并将其作为优先权。

是时候把“PowerBuilder 1和Windows测试版”的老故事抹去了。记住:我不在那里,这是口述历史,我已经足够大了,我的记忆开始修饰我自己的故事,更不用说别人的了。

Powersoft获得了这个重要的营销分数。他们与微软合作,在新发布的Windows(3.0)的同一天发布他们的新产品PowerBuilder。微软试图证明他们构建的这个平台适用于定制业务线应用程序,而不仅仅是图形程序和扫雷器。因此,Powersoft从微软获得了最后一个候选版本,他们彻底击败了PowerBuilder。他们很满意。在发布当天,商务人士一手拿着Windows,一手拿着PowerBuilder走出电脑商店。然后电话开始打进来。PowerBuilder严重损坏,这是显而易见的。微软在候选版本和通用版本之间做了一些改变(大概是为了修复一个bug),这让PowerBuilder屈服了。Powersoft很快做出了修复,但在修复后的很多天里,都出现了许多红脸。

全部的 当 真实的 Windows7船舶。

祝你好运

特里。

Windows版本通常在前两个service Pack发布之前都不稳定。现在跳起来意味着你不仅仅是在测试你的软件,而且你还在一个未经测试的系统上测试。如果有bug,你怎么知道是你的程序还是新的操作系统?

您的客户将在未来一段时间内使用XP(多亏了Vista,它仍然很流行)。按照你所知道的去做。

冒着听起来油嘴滑舌的风险,两种方法都要测试。请容忍我。

从拥有一个自动化的构建过程开始,这个过程可以从源代码管理(你有源代码管理,对吧?)中对你的软件进行干净的构建。添加自动测试。这包括从低级单元测试到集成测试,再到使用类似 TestComplete SmarteScript . 现在,由于您现在可以在没有任何人机交互的情况下测试整个产品(或至少是关键部件),因此您可以随时运行这些测试。

创建一个干净的虚拟机来代表一台典型的客户端PC。您的开发箱可能不是一个很好的例子。作为自动化构建过程的一部分,您可以为虚拟机(至少是VMWare和VPC)编写脚本,从已知良好的快照开始,安装软件的最新构建,运行自动化测试并发布结果。

听起来你好像在添加大量的过程。实际上,你正在做的是把所有可以(因此也应该)自动化的东西从你手中拿走,让你有更多的时间做更有趣(如何推销给自己)和有利可图(如何推销给老板)的事情。

否则,只需针对大多数客户使用的操作系统进行测试,并附上免责声明。