软件平台-无忧软件

全虚拟化和半虚拟化，哪一种更适合你？

找到符合企业需求的虚拟化技术取决于企业应用环境的需要和每种虚拟化体系架构的特性。很多情况下企业会发现单一的方法很难满足应用的需求，这时就需要多重虚拟化解决方案的帮助。硬件和操作系统作为两种最基础的服务器虚拟化体系架构都是根据不同的工作负载和应用环境来设计的。一些应用环境更适用于操作系统虚拟化，特别是那些能满足高性能计算或者服务器整合需求的操作系统。而那些支持多重操作系统的应用环境可能在硬件系统虚拟化中表现的更好。硬件虚拟化：这种方式是对包括硬件系统到软件堆栈等整个服务器的全面虚拟化。这种体系架构能解决在单独的物理服务器上不同计算环境整合相关的很多问题。操作系统虚拟化：操作系统虚拟化位于操作系统的顶部。这种方式能极大的提升许多计算环境的服务器整合率和资源利用率。当用户使用虚拟化产品和解决方案时，操作系统虚拟化都与层相关。层指的是虚拟化应用的级别。以应用程序为基础的硬件虚拟化解决方案包括对现有操作系统处理的层和直接在硬件顶部运行的层。这就是大家所熟悉的“裸机”。将物理硬件系统与管理程序相关联使在单独的物理主机上支持多重操作系统成为可能。这种单独的虚拟机能彼此完全独立，无需依赖其他系统就能自行处理工作负载。虚拟机的完全独立就是硬件虚拟化和复杂性管理最大的优势所在。由于虚拟机是相对独立的单元，他们就必须在物理机之外进行有效的管理。补丁程序，软件管理，资源分配和安全性也会随着虚拟机数量的增加相应的进行升级。而随着应用环境的升级会导致虚拟机的蔓延。由于每台虚拟机需要单独管理，所以与物理机相比虚拟机管理也需要付出同样的努力。对于一些操作系统虚拟化产品，服务器模板是减少与操作系统虚拟化环境升级相关的整体管理成本的另一大优势。采用这项技术，服务器模板是支持原始应用软件或操作系统的各项联接的集合体。在主机与盒子之间的联接意味着主机上的任何文件的升级都具备直接影响盒子内部的程序的能力。对主机的补丁升级能立即对所有盒子进行关联补丁升级。对主机增加应用软件和创建相应的模块能让选择的盒子里的应用软件快速升级和配置更加简单。多重解决方案是最佳之道采用一种解决方案可能并非上上之选，因为不同的虚拟化解决方案处理不同类型的工作负载表现也不尽相同。选择适合计算环境的正确技术是获取最佳结果的关键。某些应用环境可能需要不同类型的操作系统在支持网络服务方面共同协作。举例来说，采用Linux操作系统的数据库需要在Windows版本的网络服务器上运行。当服务器在单一虚拟机上运行时网络服务的性能表现的更好。在这种情况下采用诸如VMware Virtual Infrastructure或Parallels Server这种硬件虚拟机解决方案是最好的方式。再举例来说，不同的应用环境可能只支持单一的操作系统。在这种环境下服务器的独立配置可能都比较相似。比如代码的发展过程需要多重测试环境或者主机桌面系统应用环境。这些环境需要高整合率而且易于管理。这种情况下采用诸如Parallels Virtuozzo Containers这样的操作系统虚拟化可能是最佳选择。这两种技术能相互补充。尽管类似又不尽相同对于硬件和操作系统来说，一些用于性能管理的系统设置都非常类似。操作系统虚拟化和硬件虚拟化解决方案两者都具备将物理资源分配给虚拟机的能力。虚拟机能够按照需求获取相应数量的内存，处理器，网络和存储资源。然而这两种虚拟化技术之间的资源分配又是非常不同的。对于硬件虚拟化而言，与硬件虚拟化体系架构相关的局限性是指资源要被重新调配才分配给虚拟机。而对于操作系统虚拟化来说，就没有任何限制。任何主机上提供的硬件资源都能供虚拟机使用。这样就能实现可用资源的最优化和最大化的发掘资源利用的高效性。另外，使用操作系统虚拟化的资源不会对虚拟机产生影响。而使用硬件虚拟化的方式要实现同样的性能经常会需要重启虚拟机，根据对应用环境的支持需求来加强动态调配资源的能力。操作系统虚拟化高水平的资源最优化优势尤其适用于诸如电子邮件系统和数据库等需要处理繁复工作负载的系统使用。硬件虚拟化有一个在数据中心范围内对所有物理主机上的所有虚拟机进行集中化管理的界面。这种单一的标准化界面允许虚拟机进行统一管理，不管他们在那个主机上运行或者运行的是何种操作系统。这种界面的实质就是对虚拟机进行计划和脚本管理的能力。操作系统虚拟化也有与硬件虚拟化类似的功能，也可以直接对每台虚拟机的管理程序进行内部管理。最重要的是在应用操作系统虚拟化时，只需对一种操作系统进行升级和管理。虚拟化不仅是一种趋势虚拟化的趋势是对可用资源更有效的利用。计算环境的需求将决定何种虚拟化解决方案是最合适的方法。硬件虚拟化可以与单一平台上的多重操作系统相结合。操作系统虚拟化与高水平的整合和管理相结合成为平台的组成部分。这两种方式都能成功的支持虚拟机和多种类型的操作系统，包括微软公司的Windows操作系统和不同版本的Linux操作系统。最做出选择之前最重要的一点就是充分理解每种虚拟化概念的功能和特性，他们能为你的虚拟化部署和整合项目提供何种解决方案。面对多种选择，总有一款适合你。

自动化测试脚本

概述　　软件自动化测试自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。通常，在设计了测试用例并通过评审之后，由测试人员根据测试用例中描述的规程一步步执行测试，得到实际结果与期望结果的比较。在此过程中，为了节省人力、时间或硬件资源，提高测试效率，便引入了自动化测试的概念。 [编辑本段]前提条件　　实施自动化测试之前需要对软件开发过程进行分析，以观察其是否适合使用自动化测试。通常需要同时满足以下条件：　　1) 软件需求变动不频繁。　　测试脚本的稳定性决定了自动化测试的维护成本。如果软件需求变动过于频繁，测试人员需要根据变动的需求来更新测试用例以及相关的测试脚本，而脚本的维护本身就是一个代码开发的过程，需要修改、调试，必要的时候还要修改自动化测试的框架，如果所花费的成本不低于利用其节省的测试成本，那么自动化测试便是失败的。　　项目中的某些模块相对稳定，而某些模块需求变动性很大。我们便可对相对稳定的模块进行自动化测试，而变动较大的仍是用手工测试。　　2) 项目周期足够长。　　由于自动化测试需求的确定、自动化测试框架的设计、测试脚本的编写与调试均需要相当长的时间来完成。这样的过程本身就是一个测试软件的开发过程，需要较长的时间来完成。如果项目的周期比较短，没有足够的时间去支持这样一个过程，那么自动化测试便成为笑谈。　　3) 自动化测试脚本可重复使用。　　如果费尽心思开发了一套近乎完美的自动化测试脚本，但是脚本的重复使用率很低，致使其间所耗费的成本大于所创造的经济价值，自动化测试便成为了测试人员的练手之作，而并非是真正可产生效益的测试手段了。　　另外，在手工测试无法完成，需要投入大量时间与人力时也需要考虑引入自动化测试。比如性能测试、配置测试、大数据量输入测试等。 [编辑本段]适用场合　　通常适合于软件测试自动化的场合：　　(1)回归测试，重复单一的数据录入或是击键等测试操作造成了不必要的时间浪费和人力浪费；　　(2)此外测试人员对程序的理解和对设计文档的验证通常也要借助于测试自动化工具；　　(3)采用自动化测试工具有利于测试报告文档的生成和版本的连贯性；　　(4)自动化工具能够确定测试用例的覆盖路径，确定测试用例集对程序逻辑流程和控制流程的覆盖；　　随着测试流程的不断规范以及软件测试技术的进一步细化，软件测试自动化已经日益成为一支不可忽视的力量。能否借助于这支外在力量以及如何借助于这支力量来规范企业测试流程、提高特定测试活动的效率，正是本期所要讨论的话题。　　目前，软件测试自动化的研究领域主要集中在软件测试流程的自动化管理以及动态测试的自动化（如单元测试、功能测试以及性能测试方面）。在这两个领域，与手工测试相比，测试自动化的优势是明显的。首先自动化测试可以提高测试效率，使测试人员更加专注于新的测试模块的建立和开发，从而提高测试覆盖率;其次，自动化测试更便于测试资产的数字化管理，使得测试资产在整个测试生命周期内可以得到复用，这个特点在功能测试和回归测试中尤其具有意义;此外，测试流程自动化管理可以使机构的测试活动开展更加过程化，这很符合CMMI过程改进的思想。根据OppenheimerFunds的调查，在2001年前后的3年中，全球范围内由于采用了测试自动化手段所实现的投资回报率高达1500％。 [编辑本段]方案选型六大原则　　然而存在优势是否就一定意味着选择自动化测试方案都能为企业带来效益回报呢？也不尽然，任何一种产品化的测试自动化工具，都可能存在与某具体项目不甚贴切的地方。再加上，在企业内部通常存在许多不同种类的应用平台，应用开发技术也不尽相同，甚至在一个应用中可能就跨越了多种平台;或同一应用的不同版本之间存在技术差异。所以选择软件测试自动化方案必须深刻理解这一选择可能带来的变动、来自诸多方面的风险和成本开销。　　以下笔者给出企业用户进行软件测试自动化方案选型的参考性原则，这些原则是从笔者实际工作中凝练而成的，它包括以下六个方面的建议: 　　●选择尽可能少的自动化产品覆盖尽可能多的平台，以降低产品投资和团队的学习成本; 　　●测试流程管理自动化通常应该优先考虑，以满足为企业测试团队提供流程管理支持的需求; 　　●在投资有限的情况下，性能测试自动化产品将优先于功能测试自动化被考虑; 　　●在考虑产品性价比的同时，应充分关注产品的支持服务和售后服务的完善性; 　　●尽量选择趋于主流的产品，以便通过行业间交流甚至网络等方式获得更为广泛的经验和支持; 　　●应对测试自动化方案的可扩展性提出要求，以满足企业不断发展的技术和业务需求。 [编辑本段]过程　　自动化测试与软件开发过程从本质上来讲是一样的，无非是利用自动化测试工具（相当于软件开发工具），经过对测试需求的分析（软件过程中的需求分析），设计出自动化测试用例（软件过程中的需求规格），从而搭建自动化测试的框架（软件过程中的概要设计），设计与编写自动化脚本（详细设计与编码），测试脚本的正确性，从而完成该套测试脚本（即主要功能为测试的应用软件）。　　1) 自动化测试需求分析。　　当测试项目满足了自动化的前提条件，并确定在该项目中需要使用自动化测试时，我们便开始进行自动化测试需求分析。此过程需要确定自动化测试的范围以及相应的测试用例、测试数据，并形成详细的文档，以便于自动化测试框架的建立。　　2) 自动化测试框架的搭建。　　所谓自动化测试框架便是像软件架构一般，定义了在使用该套脚本时需要调用哪些文件、结构，调用的过程，以及文件结构如何划分。　　而根据自动化测试用例，我们很容易能够定位出自动化测试框架的典型要素：　　a. 公用的对象。　　不同的测试用例会有一些相同的对象被重复使用，比如窗口、按钮、页面等。这些公用的对象可被抽取出来，在编写脚本时随时调用。当这些对象的属性因为需求的变更而改变时，只需要修改该对象属性即可，而无需修改所有相关的测试脚本。　　b. 公用的环境。　　各测试用例也会用到相同的测试环境，将该测试环境独立封装，在各个测试用例中灵活调用，也能增强脚本的可维护性。　　c. 公用的方法。　　当测试工具没有需要的方法时，而该方法又会被经常使用，我们便需要自己编写该方法，以方便脚本的调用。　　d. 测试数据。　　也许一个测试用例需要执行很多个测试数据，我们便可将测试数据放在一个独立的文件中，由测试脚本执行到该用例时读取数据文件，从而达到数据覆盖的目的。　　在该框架中需要将这些典型要素考虑进去，在测试用例中抽取出公用的元素放入已定义的文件，设定好调用的过程。 [编辑本段]脚本的编写　　该编写过程便是具体的测试用例的脚本转化。初学的自动化测试人员均会使用录制脚本到修改脚本的过程。但专业化的建议是以录制为参考,以编写脚本为主要行为，以避免录制脚本带来的冗余、公用元素的不可调用、脚本的调试复杂等问题。 [编辑本段]脚本的测试与试运行　　事实上，当每一个测试用例所形成的脚本通过测试后，并不意味着执行多个甚至所有的测试用例就不会出错。输入数据以及测试环境的改变，都会导致测试结果受到影响甚至失败。而如果只是一个个执行测试用例，也仅能被称作是半自动化测试，这会极大的影响自动化测试的效率，甚至不能满足夜间自动执行的特殊要求。　　因此，脚本的测试与试运行极为重要，它需要祥查多个脚本不能依计划执行的原因，并保证其得到修复。同时他也需要经过多轮的脚本试运行，以保证测试结果得一致性与精确性。　　自动化测试引入的原因是就把软件测试人员从枯燥乏味的机械性手工测试劳动中解放出来，以自动化测试工具取而代之，使测试人员的精力真正花在提高软件产品质量本身。 [编辑本段]实施中的注意事项　　首先，一个企业实施测试自动化，绝对不是拍脑袋说干就能干好的，它不仅涉及测试工作本身流程上、组织结构上的调整与改进，甚至也包括需求、设计、开发、维护及配置管理等其他方面的配合。如果对这些必要的因素没有考虑周全的话，必然在实施过程中处处碰壁，既定的实施方案也无法开展。其次，尽管自动化测试可以降低人工测试的工作量，但并不能完全取代手工测试。100％的自动化测试只是一个理想目标，根据笔者的经验，即便一些如SAP、OracleERP等测试库规划十分完善的套件，其测试自动化率也不会超过70％。所以一味追求测试自动化只会给企业带来运作成本的急剧上升。再次，实施测试自动化需要企业有相对规模的投入，对企业运作来说，投入回报率将是决定是否实施软件测试自动化的最终指挥棒，笔者建议企业在决定实施软件测试自动化之前，必须要做量化的投资回报分析。此外，实施软件测试自动化并不意味着必须采购强大的自动化软件测试工具或自动化管理平台，毕竟软件质量的保证不是依靠产品或技术，更多的因素在于高素质的人员和合理有效的流程。 [编辑本段]实战模拟　　1．公司背景介绍　　A公司是一家大型保险公司，拥有近20个城市的分公司，并在其中5个城市建立了IT支持中心。平均每年的上线应用数量在20个左右（新业务系统和原有业务系统的主要版本发布）。目前A公司的专职测试团队人数不足30人，而且测试团队的测试人员技能参差不齐，目前测试只是作为项目上线前的一道工序而已。在测试团队内部也几乎没有自动化的手段，主要依靠手工测试。由于已上线应用系统的问题，开发团队必须分出一部分资源去维护和修复上线应用，而同时测试团队的测试成果和效率却无法和这些应用质量挂钩，也更无从谈起对软件质量的控制。所以，A公司决定在软件质量和测试方面进行投入，他们考虑以下几方面: 　　●引进软件测试流程管理的自动化，提高软件测试过程的管理水平，使软件测试和软件开发一样可被评估、被衡量。　　●实现性能测试自动化，所有应用上线之前必须有应用性能风险评估报告和相关部门的确认　　●逐步实现功能测试的自动化，在目前人员配置的情况下，把部分手工测试变成自动化测试，提高测试可信度，降低人为错误。　　●通过软件测试自动化，管理软件测试中的案例、缺陷、报告等资产，进一步提升软件测试的效率并建立测试基础库。　　●在规划中，将来的2～3年内使所有的应用系统上线都必须有数字化的测试数据作为依据。　　2．公司应用系统的情况　　由于保险公司的业务种类繁多，同时在经过了几十年的经营后，公司内的应用系统从早期的终端方式到现代的J2EE和.NET等应有尽有，鱼龙混杂。IT部门已经建立的3年规划，即在未来的3年时间内将所有终端和C/S方式的应用转换成B/S架构，但当前仍然需要对这些旧应用系统进行维护，以保证业务的顺利进行。对于开发部门来说，目前新应用开发基本上已经以B/S架构为主，主要是基于J2EE架构的WebHTTP应用和部分Window.NETForm的应用。　　3．公司软件测试现状　　企业机构在做测试自动化选型时一定要考虑清楚企业内部哪些部分可以实施自动化、哪些部分暂不实施自动化、哪些部分仅在某几个项目做自动化试点。切忌匆忙上马或盲目否定，缺乏实事求是的理性思考。　　测试部门目前仅负责系统测试和对用户验证测试进行管理，对于之前的单元测试和集成测试主要由开发团队中划分出的一部分临时测试人员完成。由于缺乏监测手段，测试部门也无法收集和确定集成测试和单元测试的完成情况，在整个软件测试过程中，业务需求是由开发部门通过RationalRequisitePro进行管理，但测试需求目前尚没有提出要求，测试案例主要通过在公司公用的文件服务器中的目录管理方式管理，对测试中缺陷流程等管理主要依靠邮件的流转进行处理。目前90％以上的测试是通过Excel和Word等测试案例文档来完成，测试人员对软件测试自动化的认识仅停留在“记录＋回放”的认识上。　　4．可供选择的方案　　方案A:A公司可以采用美科利（Mercury）公司产品为主的软件测试自动化方案。　　●依照原先的邮件流转过程配置TestDirector缺陷管理流程，为每个保险业务的开发小组和测试团队分配相应的用户许可证，取消原有邮件方式。　　●部署MercuryQuickTestProfessional，以便完成应用程序相关功能测试。　　●部署MercuryLoad-Runner。从测试团队中分化出专职的性能测试自动化工程师和小组，和业务部门协调，建立A公司应用系统上线性能指标，通过LoadRunner给出测试指标。　　●建议A公司成立专门的质量控制部门，对TestDirector中的数据定期进行分析，建立相关质量模型，以便于企业量化管理和过程改进。　　方案B:A公司也可以采用IBMRational产品为主的软件测试自动化方案。　　●采用RationalTestmanager来进行整个测试流程的管理，为相关开发和测试小组成员分配相应权限，改变以前通过邮件以及Word、Excel文档管理测试的工作方式。　　●部署RationalRobot，用它来完成功能相关的测试工作以及新版本发布时的冒烟测试。此外，RationalRobot也能较好地完成性能相关测试。统一的操作方式降低了工具的学习周期和培训带来的大笔开销。　　●部署RationalPurifyplus，使测试工作前移到开发阶段。由于Purifyplus能较好地支持白盒测试，编程人员在编码阶段引入的错误能尽早被检测到，这大幅降低了后期测试的开销。　　●建议A公司成立专门的质量控制部门，对Testmanager中的数据定期进行分析，建立相关质量模型，以便于企业量化管理和过程改进。　　方案C:A公司也可以采用开源软件为主的软件测试自动化方案。　　●采用Bugzilla来进行Bug跟踪管理，采用BugzillaTestRunner进行测试用例管理，采用CVS进行测试资源的配置管理。　　●采用MaxQ和WebInject对B/S结构的应用系统进行功能测试。　　●采用DBMonster、Open－STA、LoadSim进行性能相关测试。　　●可采用Xunit架构的开源工具对不同语言的程序单元进行单元测试。　　●建议A公司成立专门的开源软件维护小组，以解决可能会碰到的工具维护工作。　　●建议A公司成立专门的质量控制部门，对Bugzilla、TestRunner、CVS中的数据定期进行分析，建立相关质量模型，以便于企业量化管理和过程改进。　　5．方案评价　　由于不同客户在组织架构、员工素质以及流程管理水平等方面的不同，我们很难用一个实例、一两句话来说明不同解决方案的适用性。在上面的例子中，笔者给出了3种可行的方案，具体选择哪一个，需要仔细权衡。这里笔者给出一般性的意见，对于不想受制于某个测试自动化厂家的企业，开源绝对是一个理想的选择。此外，它不需要支付成本，工具的源代码可以随意修改，因而具有较好的灵活性。但开源工具的弊端也是明显的:缺乏使用培训和技术支持，工具的用户界面一般也较为粗糙。而对于那些比较看重培训和售后支持的企业，笔者建议选择IBMRational或Mercury或其他厂家的产品。这样虽然需要支付一部分费用，但省去了工具维护所需要的大量工作。至于具体选择哪个厂家的产品为好，笔者尚无结论性意见。相信读者朋友都有一些见仁见智的看法，不妨来信交流。