?

Gavlin Pather在俄罗斯的KZN长大，在那里他学习信息技术并开始了作为一名开发者的职业生涯，后来他又成了测试领域的一名黑盒测试员，接着又转向白盒测试，最终是自动化测试。在测试专业领域近6年并在测试实验室中进行测试，自然而然地，他逐渐开始对云产生兴趣。

?

　　计算机和软件在我们的日常生活中越来越常见。现代社会中随着我们对技术越来越依赖，不可避免地就需求它们变得更快，更好。更快，更好的需求提高了，就需要更高质量的软件。要做到这一点，就不能只依靠手工测试，我们需要进入一个自动化的测试时代。
　　 通过结合自动测试和手动测试，我们就能够在较短时间内达成一套质量标准。然而，随着我们迈向一个更加技术化的（要求我们开发的软件不仅在我们的个人电脑上，且在移动设备上也能运作的）现代社会，就需要更多的云计算。拥有了更先进的软件，硬件和托管平台人们就需要有更加复杂和精密的测试方法以保持传统软件测试中达到的质量标准。
　　 云计算改变了我们提供及管理计算资源（如CPUs ，数据库和客户存储系统）的方式。 
　　 我们测试在云上运行的软件的方式可以更好地表现出该软件将如何在现实世界中运作。正如Jerry Gao等人所说，“云计算是互联网发展的下一阶段。一个典型的云必须有几个不同的属性：弹性和可扩展性，多租户，自我管理功能，服务收费和计量功能以及连接接口和技术”。此外，云支持大规模用户在各地从互联网进入。它为客户随时提供按需应用服务，并提供虚拟和/或物理设备。因此，云中的软件测试可能会更复杂，花费比预期更长的时间，这就造成手动测试一支独大。 
　　 在云计算中加入自动化测试让你能够在多个平台上运行回归测试脚本，这扩大了正在进行的测试的范围并消除了可能造成误差的人为因素，同时也减少了完成回归测试所需要的时间。由于各种软件复杂性、云的浩瀚广阔及（可能在测试过程中被发现并导致两种测试方法结合的）缺陷，手工测试不能完全消失。此外，开发人员使用单元测试可以确保一个软件上的改变对系统的影响最小，还能在部署之前检测出缺陷。 
　　 通过结合这些方法并把它们应用到云计算中（同时也要考虑云的复杂性，自动化测试的灵活性，及解决手工测试问题的能力），我们要在较短时间内在不断变化、适应和发展的软件工程和开发业完成更高质量的软件。 
?

　　云计算
　　 云计算是一个为可配置计算共享池（共享池可以被快速配置且其发布只需极少的管理或服务提供商交互）提供普遍，便捷及按需网络访问的模型。用户可在任何地方按需获取，并不是只能从本地电脑获取。运行他们自己的基础设施的公司（如亚马逊，谷歌和Facebook ）使用该模型就能时刻应对正在运行的系统及按需缩放的系统上的变化及升级了。用户或客户可用浏览器内的基于云的计算机资源提供的一项服务及执行所要求的功能和/或输出的一项服务去执行一个任务，如准备一份库存报告或执行文字处理。Jerry等人2011观察到的传统软件测试与云测试之间要注意的些微区别见表1。注意这些差异非常重要，因为这能帮助更好地理解这两个测试平台之间的差异，以及这些差异会怎样影响测试软件可能采取的方法。任何功能的云测试，如集成测试，都包含了确定一组预定义策略来设计测试用例以覆盖最大范围的用户期待需求。

　　云测试
　　 因为云测试相对而言还比较新，我们无法明确应在云系统测试实践中应用什么软件测试技术，建议，方法和工具。因此，我们对云测试还没有一个明确且被普遍接受的理解。传统的软件测试方法主要是根据测试者和标准的最佳实践而不是理论。它是由Kitchenham等人在他们的（其中既没有关于软件工程师如何找到缺陷和/或将之引入软件系统的已知理论，也没有任何提供关于测试人员如何识别这些缺陷或bugs的理论的）研究工作中提出的。在任一现存云服务测试中，最终用户的参与都更积极，更直接。这些最终用户可以是个人或企业用户，他们已成为云应用和云服务提供商的云测试团队的强大和不可缺少的一部分。由于非基于云的应用程序的硬件和软件的限制，大多数软件应用程序需要存在于主机或小型机上。评估被测软件时主要考虑三个方面，即：单元测试，自动化测试和手工测试。

表1.传统软件测试与云测试间的差异

　　单元测试
　　 为了确保开发中的云应用的更高质量，正在做测试的开发人员创建了可应用的单元测试。单元测试提供了一些好处，诸如能够无需等待其他可用单元就可进行测试，能够以更低的成本来检测和删除软件故障（比起在后期这么做）。对云应用进行单元测试的一个有效方法是使用各种基于桌面的云环境仿真器，如Microsoft Azure Compute和Storage Emulators，它们使开发人员能够在本地运行并测试他们的云应用程序，而不是部署后再进行测试。然后这些单元测试就可以用于进行回归测试了，如果该软件改变了，他们可以早点生效并最大限度地减少对系统的不利影响。通常，输入所有的可能去测试一个单元是不可行的，因为输入空间太大以至无限。因此，我们需要一个标准来决定使用什么测试输入及何时停止测试。

　　自动化测试
　　 为了减少手动工作，测试人员或开发人员可以使用可以自动生成测试输入以实现高结构覆盖的自动化测试生成工具。由于云应用程序实际上是依靠云环境的应用程序的，所以一个云应用程序里被测单元的行为是依赖于单元输入及云环境状态的。使用存根云模型可以减轻这些问题。有了这样的模型，就可以用（能够给云API方法调用提供一些默认的或用户定义的返回值的）假/存根云环境模拟真正的云环境了。一个图形用户界面（GUI ）的自动化测试表现了在基于字符界面未被发现的显著困难;少了很多命令行界面或编程接口（APIs ）。图形用户界面往往是由复杂的组件构成，而且往往在开发过程中被不断地重新设计。发布能够识别和操作图形用户界面的测试工具取得了显著成功。Selenium与Sahi就是实例。该GUI自动化测试可以由开发人员写或具备适当技能的测试人员写。这些测试用例的深层开发是为了用户体验和正确性。这些测试用例仅表示测试用例中的被操作对象。使用这些工具，你就能通过录制和重放或通过写测试代码来创建测试用例。如果编写准确，这些测试就可以与在一个连续集成(CI)环境中创建并运行的单元测试集成起来。所写测试将可以和终端用户一样操纵一个浏览器。然而，并非所有的测试用例都可以，因为云的状态和环境不一样。从源（例如：数据库或文件）读取数据，将使得测试以几种不同的方式运行以呈现GUI，这就允许文本字段的不同输入和结果的验证，以便能够点击按钮和下拉菜单，并且还能够验证文本及屏幕上对象的位置。如果注意到任何差异，它就能够将该问题写入（可以用来验证问题已被挖掘的）日志文件中。它多样且能够在多个浏览器的Web测试中运行，这就使你能够拦截缺陷并轻松复制。自动化测试的这两个方法将能够比手动测试快得多地运行测试用例，还能够覆盖更广泛的测试环境和状态。这些测试用例运行期间挖掘的缺陷也可以在最终用户交互之前被修复和部署，从而获得更好的用户体验并减少人为错误。

　　手动测试
　　 软件测试的方法可以基于程序的形态及其实现，或两者兼有。所要求的基于形态的测试指导测试用例的选择过程，并提供一种评估测试充分性的手段。另外，基于实现的测试侧重于行使被测程序，因此充分性通常是指覆盖程序结构要素。测试可以在多个粒度级别进行组件测试，集成测试和系统测试。一个更广泛且快速增长的手工测试方法是探索性测试。在某些情况下，它可以比脚本测试更有效率。所有测试人员都会用到某种形式的探索性测试。随着企业寻求更灵活及更具成本效益的方法去开发软件，这种态度开始改变。其高度情境结构可以使它在不经意的观察中看起来没有任何结构。

　　“所以说，一段旅程要想够得上探险，必须是可信的并有困难和风险的，还必须要有新发现。就像板球一样，对外行解释起来有那么点困难。但有一个元素是绝对重要的，事实上从探索早期就开始严格地区分探索阶段并严格采用“探索”一词。很简单，这是对科学的崇敬。”——选自John Keay的《The Permanent Book of Exploration》

　　James Bach等人提到：探索性测试某种程度上来说是测试者主动控制测试设计的任一测试，因为那些测试都被执行了并使用了从通过测试设计新的更好的测试时获得的信息。手工测试仍是大多数软件开发工作的高度相关部分。这些人如测试人员的特性（包括创造力，智力，领域知识及有效识别各种问题的能力）使手动测试成为软件测试的重要部分。

　　结论
　　 总之，软件测试作为一项云计算服务是相当新颖的，要放下测试传统或常规方式去适应它，仍需要作出转变。不同类型的测试方法，例如自动化测试，手工测试和单元测试已被用来在云中进行测试时试着达到最好的效果。把这些方法结合起来并基于云中还是会留下很多可以改进的漏洞。仍然存在许多漏洞的原因是：需要获得“云测试最佳实践指南”。随着越来越多的应用程序迁移到云中，我们对于它们将如何应对在这样的环境下进行以及如何最好地测试它们，测试什么，用什么方法测试什么都会有更好地理解。要使用什么自动化工具（如果必须是自动化的），要做单元测试吗，或者它应该是纯手工测试吗，这些问题都是公司需要做出的并具有增值收益的业务决策。
　　 为了实现云计算中软件的更高质量，需要一种新的关于如何测试软件的思维方式，包括采取什么步骤以获取最佳结果。测试的传统方法已经给了测试人员和开发人员许多经验教训，并且随着我们进入一个多数应用程序随处可得的时代，确保所获知识适应且适合云计算就成了他们的责任，当然这也是利益相关者和业务管理的责任。

　　版权声明：本文出自 SPASVO泽众软件测试网：http://www.spasvo.com/news/html/201458143930.html

　　原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。