随着万圣节的临近，那我们看看几样对软件测试人员最具有杀伤性的武器。
加快发布周期
为了应对现今“快鱼吃慢鱼”的紧张局势，软件交付进程变得越来越紧，考虑到软件测试会阻碍软件交付的时间，所以只靠加快质量进程就想达成预定目标是不现实的。
但是要是没有足够的时间用于测试的话，这可能就意味着你们的组织文化需要大肆整顿一番了，因为文化对构建和测试软件起导向作用。毋庸置疑，我们都希望生产出高质量的软件，但是组织文化能影响决策的偏颇，而这会导致软件投放市场时产生的风险大小。
开发过程中写出的劣质代码
软件测试人员主要的工作就是执行测试，但是却无法追究于一些原本完全可以在实施过程中发现的简单错误。所以要是一个开发团队能持续应用开发测试方法，例如单元测试、静态分析和同行代码审查以确保代码在进入QA前剔除掉很多不必要的缺陷和问题，这将会大大减少QA用于发现、报告然后修复这些缺陷所需要的时间。这么做不但能提高团队的整体速度，还有助于测试人员将有限的时间全部用于执行那些艰巨的测试任务。
真实的测试数据
真实的测试数据能显著改善测试套件的有效性。良好的测试数据和测试数据管理方在提高覆盖率的同时也会增加风险，所以开发并获取测试数据可能在很长一段时间内都将是一个相当大的挑战——因为我们需要投入大量的时间和精力等等。拷贝生产数据是有风险的（并且有可能违法），而要求数据库管理员来提供必要数据的话通常又有诸多延误，要是将这任务转嫁到开发人员或者QA头上，又很可能会延误项目的其他方面，导致一些不准确或者不完整的结果。
有些团队发现仿真技术，例如虚拟化服务，可以减少对测试数据管理的恐惧。
完整的测试环境
要是有多个相关系统，那么要想建立一个完整又真实的测试环境几乎是不可能的。开发人员、测试人员和性能工程师经常要面对下面这些难题：
系统过于复杂或者不切实际以至于不能采用测试实验室的方法 区域划分或者政治方面的界限限制了我们对资源的访问 无法访问第三方/合作伙伴的系统和服务 限制了测试的调度制约 有缺失/不稳定的组件 不断变化的开发环境通过构建一个阶段性的测试环境或虚拟测试实验室的方法来试图解决测试环境的访问限制，可谓是非常昂贵的。在很多情况下，构建这样一个采用分级应用实例和虚拟测试实验室的环境是不可能的——举个例子，要是相关的应用程序是一个第三方应用程序，那么往往会由其他部门或者超越“地缘政治”界限的执行测试团体来托管其复杂系统（如大型机）。即使是在构建一个“完整的”测试环境也是可行的情况下，配置并维护所有相关的应用程序依然需要持续性的高额运营成本。
但是不幸的是：测试人员无法完成测试。最新的研究表明，由于测试环境的访问限制，64％的测试人员花费很少或者几乎没有时间来创建自动化的测试，并且只有50％的测试计划按照预期完成。
要是你想逃脱上述追杀，那么服务虚拟化或许可以为您提供一个安全避难所。