软件测试系列思考

《软件测试系列思考》由会员分享，可在线阅读，更多相关《软件测试系列思考（12页珍藏版）》请在装配图网上搜索。

1、软件测试思考系列1：往持续交付的方向努力 测试应该朝什么方向努力，怎样做才能避免陷入泥潭？产品不稳定的原因，粗略看上去，似乎是因为测试时间不够，测试不充分导致的，但是深入进去探讨会发现没有那么简单。这一篇文章就是探讨测试应该朝着什么目标去努力，而我在这半年的实践中选择的是持续交付的方向，下面就介绍介绍持续交付。首先，如果测试不能从产品周期的一开始就参与进去，后期等产品快发布前再测试，会面临很大的问题。工作量大不谈，如果发现了BUG，开发的修复时间也不够了，更不要说可能产生严重的架构问题，或者功能和需求不符问题。其次，现在很多软件公司所面临的问题，就是“铁路警察，各管一段”的问题，推诿职责，测试

2、并不是银弹，不能解决全部问题，所以很大程度上需要责任共担。但这个东西是说起来容易做起来难的一件事情，当一个问题，你无法快速定位导致它的真正原因的时候，就无从谈起问责。想要做到快速定位，将定位问题原因的难度降低，一个很重要的原因是快速反馈，功能越早的被测试，问题就越容易被发现，也越容易被修复。做到这一点，主要就是靠持续集成，而持续集成就是持续交付的主要组成部分，原来听的比较多的也是“持续交付”，而持续交付的提出，更多的是为了解决所谓的“最后一公里”的问题，因为很多的BUG或者问题，需要延迟到用户真实的生产环境中去才能发现。很多做法，比如Alpha应用等等，都是往这个方面做得努力，就是不但要尽早的

3、得到产品，还要尽早的部署。再三，上面一篇文章中提到的反馈影响图，也要求反馈的循环速度越快，换个意思表达，也就是持续的得到反馈，而只有真正集成或者交付后，才能得到有用的反馈。持续交付的概念，我最早是从InfoQ上的一篇演讲学习到的，在这之前其实我只了解过持续集成。这个演讲(包括视频和PPT)的题目是让持续交付成为可能，不仅探讨了概念，还通过真实案例分享，与听众一起回顾某产品团队如何从传统开发走向持续交付。讨论在产品交付中如何应用DevOps原则（协作、自动化、度量和信息共享），达到快速且可靠地发布高质量的软件，同时描述过程中遇到的难题及解决方案，并进一步探讨持续交付的意义。很幸运看到这个演讲，开

4、启了我的持续交付实践之路，在这里要感谢作者，带给我很多灵感和指导方向。(当时立马将这个演讲分享给团队成员，附带一句：“看了这个视频并且理解了的家伙，不谢我绝对没人性”)关于持续交付，还有一本不得不介绍的好书，持续交付，配置管理，部署流水线等十分有用的概念，都是从这本书获得的，强烈推荐。持续交付是什么样的？软件的发布过程必须是可重复、可信赖的把几乎所有的环节都做成自动化把所有的内容都纳入版本控制让痛苦提前，并不断练习内建质量“完成”就意味着“已发布”所有人对交付负责持续改进，需要耐心持续集成借鉴了敏捷思想，打破了用户、开发和测试之间的隔阂，实现了团队的协作。而最近出现的DevOps则借鉴了敏捷思

5、想，将敏捷原则应用于运维领域，使交付团队与运维团队建立起更紧密的合作关系。所以这里如果只介绍持续交付，而不介绍敏捷思想就过意不去了。 2001年2月11日到13日，17位软件开发领域的领军人物聚集在美国犹他州的滑雪胜地雪鸟（Snowbird）雪场。经过两天的讨论，“敏捷”（Agile）这个词为全体聚会者所接受，用以概括一套全新的软件开发价值观。这套价值观，通过一份简明扼要的敏捷宣言，传递给世界，宣告了敏捷开发运动的开始。敏捷软件开发宣言我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下价值观：个体和互动 高于 流程和工具 工作的软件 高于 详尽的文档 客户合作

6、 高于 合同谈判 响应变化 高于 遵循计划也就是说，尽管右项有其价值，我们更重视左项的价值。软件测试思考系列2：提交测试 对于开发活动来说，代码提交是一个很重要的事件，代码变更被提交到版本控制服务器后（成为一次revision），意味着该变更的影响范围从该开发人员自己推广到了更广阔的范围：其他开发人员将可以通过update代码将该变更合并到自己的变更中去，影响到其他开发人员的修改；测试人员将可以从版本控制服务器上通过构建并得到结果，对合并该变更后的产品进行测试；其他的试用，需求验收人员都可以看到该变更的变化和影响，如果在开发环境中看，则太麻烦了，对于不懂技术的人来说门槛太高。因为持续集成意味着

7、“完成”即“以发布”，所以这次提交的变更很有可能会影响到最终使用这个产品的用户。测试中有一个非常重要的经济学原则：产品问题或者BUG被发现的越早，其被修复的成本就越低。所以说，提交测试是一个非常重要和有价值的阶段，如果不能被充分利用起来那就太浪费了。更何况提交测试还可以为后续的其他测试需要的简单测试过的二进制的包，避免因为前置条件不满足而导致其他的测试，试用，验收活动无法展开。提交测试的特点是功能很基础，靠近开发过程容易被程序化（见下图），需要被频繁的执行，这些特点决定了提交测试必然是自动化程度很高的，在实践中一般要求接近全部自动化（除了冒烟测试可能有手动外）。按照时间顺序，提交测试由一下一些

8、部分组成： 开发环境构建CodeReview提交至SVN提交后构建（包括编译，单元测试，代码检查etc.）自动推送部署至Alpha测试场所（Alpha安装包，Update工具，Alpha FTP， Alpha应用） 每日冒烟测试 下面将按照提交测试的这些次序，介绍各项实践：一. CodeReview 持续集成一个很重要的内容就是需要很好的内建质量，软件工程中主要就是代码质量，提高代码质量的工具多种多样，比如可以利用构建中的代码检查工具，比如FindBugs， Similar Code etc.，来规范代码，发现不规范的代码，如果不通过工具检查，则最好构建失败。提高代码质量还有一种有效的方式就是

9、代码审查，即CodeReview，通过开发者之间互相评审代码提高代码质量。因为可以看到变更集，具体到哪个开发人员提交了哪些代码，有些时候甚至可以让开发者对应的测试者也可以参与到CodeReview，这样有几个好处： 让测试熟悉所测产品的业务代码，提升代码的阅读能力 提早发现代码里面的bug，低成本保障质量，防患于未然 提前预知并评估并确认测试范围，减少测试工作量 促进开发、测试间的沟通、交流和协作具体实践中的工具可以用ReviewBoard，在结合SVN的pre-commit hook，如果该次变更没有codereview过，则无法提交。 二. 自动构建 构建可以解决开发、测试、集成、验收等工

10、作的混乱，同时本身也是一种最基本的测试。在没有采用构建之前，测试的组的工作状态是，每个人更新代码，然后编译在开发环境下面测试，有时候甚至跑不起来，不是开发人员忘记上传代码无法编译，就是测试人员编译过程有遗漏，而且每个人的测试版本都不一样，测试这边有问题，结果到开发那边又没有问题，不但麻烦，而且无法快速定位问题出在哪里。这种混乱导致大部分时间浪费在了沟通上，大量的郁闷。有一个形象的对话，可以见这里。 自动构建主要包括编译，单元测试，生成二进制包等等，分为提交前开发者构建，和提交后在持续集成服务器中的构建，这边主要指后者。 最先了解构建这个概念，是从观止-微软创建NT和未来的夺命狂奔一书获得的，里

11、面的大卫.卡特勒对构建十分重视，甚至分配专门的构建员，或亲自做构建。在构建这里介绍一个非常好用的持续集成工具：Hudson。有很好的定时任务管理，可以配置各种脚本Ant，BAT等等，还可以与很多其他的工具结合的非常好，有很多好用的插件，比如FishEye，SVN，邮件发送，FTP，FindBugs等等，是做自动化测试的利器。构建包括编译和单元测试，如果是Java应用，编译就可以用Ant，单元测试可以用JUnit，TDD方面有一本很好的书：测试驱动开发。软件测试思考系列3：回归测试 回归测试在百度百科上面的描述感觉还蛮准确，引用如下：回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的

12、错误或导致其他代码产生错误。自动回归测试将大幅降低系统测试、维护升级等阶段的成本。回归测试作为软件生命周期的一个组成部分，在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。在渐进和快速迭代开发中，新版本的连续发布使回归测试进行的更加频繁，而在极端编程方法中，更是要求每天都进行若干次回归测试。因此，通过选择正确的回归测试策略来改进回归测试的效率和有效性是非常有意义的。因为需求功能不断变化，产品也会跟着变，所以测试用例库则免不了需要维护工作，而维护主要也是指的增删改查（CRUD）。测试用例的收集和添加，具体实践中的一种方式是与BUG跟踪系统结合起来， 每个模块有测试

13、人员与之对应，那么在实现需求或者修复BUG的过程中，就可以添加测试用例了。基于这样一种理念，如果容易出BUG，说明那个地方就容易出问题，所以用测试用例覆盖的话价值会高一点。而新的需求，则是基于覆盖新的功能，特别是原先没有进行回归测试，功能已经比较完善的情况下，这种方式用的比较多一点。查询和搜索是肯定需要的，因为进行回归测试之前需要选择回归测试包。在软件生命周期中，即使一个得到良好维护的测试用例库也可能变得相当大，这使每次回归测试都重新运行完整的测试包变得不切实际。一个完全的回归测试包括每个基线测试用例，时间和成本约束可能阻碍运行这样一个测试，有时测试组不得不选择一个缩减的回归测试包来完成回归测

14、试。修改的情况，主要是因为需求变更，或者旧的功能被删除，则测试用例要与需求同步删除的测试用例，同上，具体实践时，可以采用增加测试用例状态D来实现，想法来源于Windows的垃圾回收箱。迭代式开发，就是以一段时间为一个周期，将一些任务打包分配并完成，当这些任务完成后再完成下面一批的打包任务，而不是像原来那样随意的抽取研发任务，迭代式开发计划性更强，更容易产生周期性的反馈。并且迭代式开发还有一个好处是，这样可以按迭代跑回归测试，至少每个迭代跑一次。 在实际工作中，回归测试需要反复进行，当测试者一次又一次地完成相同的测试时，这些回归测试将变得非常令人厌烦，而在大多数回归测试需要手工完成的时候尤其如此

15、，因此，需要通过自动测试来实现重复的和一致的回归测试。自动测试，目前实践中比较成熟的是Web自动化测试，常见的工具主要是Selenium，这个会在后面的自动测试系列文章中介绍。手动测试，这个就比较常见了，主要是基于ST（Script Based Test）。不像自动测试如单元测试只有两种状态：红（Failure），绿（Pass），手工测试的测试用例状态主要有三种： 通过（Pass）， 待测试（O），不通过（Failure）。因为手工测试从有希望知道测试用例是否通过的需要起，有很多测试用例需要很长时间才能知道测试用例是否通过，这段时间内，测试用例就是待测试O。所以，每次开始手动回归测试最基本的就

16、是将所有的Pass改成O状态，而手工回归测试结束的简单标志就是 测试包中状态为O的测试用例数量归零。回归测试的成本效用分析 基于ST的手工回归测试有一个很大的问题就是手工测试的成本非常巨大，手工测试的成本就是人力成本，而现在的人力成本本身就很巨大，有人曾提过设想找一些实习生，像操作工人一样来测试，不谈现实的人力成本，这样做有一个严重的问题，就是再不懂需求的前提下测试相当于没有测试。并且还有另外一个很严重的问题就是ST会非常的枯燥，基本上就是按照步骤机械的操作和验证，测试者很容易感到疲劳和厌倦，测试效率随即降低。在回归测试用例库的初级阶段，大概有两千左右的测试用例脚本，实践中预测大概需要30个人

17、天。而一次回归测试的效用就是对这一次迭代带来的变更修改，验证所有其他的产品模块，效用并不理想，但是回归测试不可或缺。 所以，回归测试的关键策略在于兼顾成本和效率效用两方面，常用的有如下一些：因为测试用例之间存在依赖关系，那么就可以建立前置条件（一个测试用例是另外一个测试用例的前置），利用这种依赖，基于分层的思想，慢慢的将测试用例库进化演变成不同的层次，就像自然界有不同层次的食物链一样的。越是重要和频繁使用的测试用例，比如冒烟测试用例库，就应该被越经常的跑。有了层次，就提供了更多了信息，帮助改进测试包缩减技术。缩减技术，比如代码相依性分析、功能矩阵、基于风险的、基于严重程度的、基于主要贡献功能等

18、等。充分利用标签、分类信息充分利用测试者的经验和能力，提高测试积极性，通过ST与探索性测试（ET）结合的方式进行测试，关于ET，后面会有系列文章进行介绍。探索性测试，在一些其他的公司已经得到了实践验证，比较好的书可以看看大牛James A.Whittaker的 探索式软件测试。软件测试思考系列4：测试自动化 自动化是把以人为驱动的测试行为转化为机器执行的一种过程。通常，测试用例按照执行对象分为手动测试和自动化测试。手动测试往往面临人力消耗巨大，测试效率很低的问题。而自动化测试便是为了解决这些问题提出的概念。自动化测试相对手动测试来说有很多优点：1、充分利用时间资源。一般无论什么公司，员工的上班

19、时间只有8个小时，那么一天中除去这8个小时的其他时间，比如夜晚的时间，如果不利用起来，那简直是巨大的浪费，而机器是不需要休息的，即使半夜也可以工作，所以测试自动化可以充分的利用时间资源。2、节省人力资源即使在以人力资源占优势的中国来说，人力资源的成本也是处于不断的上升过程之中，相应的带来的也是手动测试成本的不断上升。3、从某种角度，软件本身就是为了让过程自动化，所以软件从业人员在自动化方面有知识优势。4、手动测试一般很枯燥，难逃测试效果降低厄运，而自动化测试更加可以严格的执行测试用例脚本。人的价值相对于机器来说，优势在于创造性，所以更应该将精力花在能够充分花费这一优势的地方，比如探索新测试（E

20、T），而将那些机械的测试用例脚本交给自动化测试。人的精力可以花在怎么去管理机器和创建维护脚本方面。5、持续交付的需要在做简单和机械的事情上，计算机的效率和人的效率不是一个数量级的，所以如果要满足持续交付的需要，缩短反馈的时间，需要让机器来帮助提高效率。不过，虽然自动化测试有这么多优点，但不是所有情况都适合做做自动化测试，如果不考虑好一下一些因素，轻易的自动化可能会导致陷入维护自动化脚本的泥潭，导致成本效用比很低：1）软件需求变动不频繁。测试脚本的稳定性决定了自动化测试的维护成本。如果软件需求变动过于频繁，测试人员需要根据变动的需求来更新测试用例以及相关的测试脚本，而脚本的维护本身就是一个代码开

21、发的过程，需要修改、调试，必要的时候还要修改自动化测试的框架，如果所花费的成本不低于利用其节省的测试成本，那么自动化测试便是失败的。项目中的某些模块相对稳定，而某些模块需求变动性很大。我们便可对相对稳定的模块进行自动化测试，而变动较大的仍是用手工测试。举个例子，一般来说，UI是产品中经常变化的部分，因为用户对UI的需求变化太频繁了，而不像一些核心的业务流程一般会比较稳定。所以在UI上投入太多的精力做自动化测试需要谨慎考虑。2）项目周期足够长。自动化测试需求的确定、自动化测试框架的设计、测试脚本的编写与调试均需要相当长的时间来完成，这样的过程本身就是一个测试软件的开发过程，需要较长的时间来完成。

22、如果项目的周期比较短，没有足够的时间去支持这样一个过程，那么自动化测试便成为笑谈。3）自动化测试脚本可重复使用。如果费尽心思开发了一套近乎完美的自动化测试脚本，但是脚本的重复使用率很低，致使其间所耗费的成本大于所创造的经济价值，自动化测试便成为了测试人员的练手之作，而并非是真正可产生效益的测试手段了。另外，在手工测试无法完成，需要投入大量时间与人力时也需要考虑引入自动化测试。比如性能测试、配置测试、大数据量输入测试等。有很多自动化测试用具，比如QTP， WinRunner什么的。这篇文章着重介绍一下Web自动化测试方面的Selenium。Selenium也是一个用于Web应用程序测试的工具。S

23、elenium 测试直接运行在浏览器中，就像真正的用户在操作一样。支持的浏览器包括IE，Mozilla和Firefox等。这个工具的主要功能包括：测试与浏览器的兼容性-测试你的应用程序看是否能够很好得工作在不同浏览器和操作系统之上。测试系统功能-创建衰退测试检验软件功能和用户需求。 支持自动录制动作，和自动生成。Net、Java、Perl等不同语言的测试脚本。Selenium 是 ThoughtWorks 专门为 Web 应用程序编写的一个验收测试工具。具体的Selenium脚本的编写方面的知识就不详细介绍了，本文着重介绍一下使用Selenium进行Web自动化测试的框架，包括 Seleniu

24、m IDE， Hudson任务运行脚本， 自动推送热部署至Alpha， Selenium Grid扩展控制等等。软件测试思考系列5：非功能性测试 非功能性测试是针对非功能性需求来说的。所谓非功能性需求，是指软件产品为满足用户业务需求而必须具有且除功能需求以外的特性。软件产品的非功能性需求包括系统的性能、可靠性、可维护性、可扩充性和对技术和对业务的适应性等。下面对其中的某些指标加以说明。在这里可以看到非功能性需求涉及的范围很广，软件产品本身不是孤立存在的，还涉及到诸多外在环境的影响。非功能性需求必须考虑软件既要可用，又要易用。这篇文章主要介绍在非功能性方面的一些思考和实践，分为性能测试、兼容性测

25、试、安全性测试、易用可用性测试。性能测试性能测试主要分为性能报告和性能调优两个角度，但无论是从哪一个角度去做，最大的忌讳都是凭着感觉去猜，把90%的精力浪费在了10%不重要不是瓶颈的地方。首先需要确定用户的性能需求，比如有些功能的性能虽然很差，但是用户并不十分在意，比如定时执行任务功能等等，再比如首页页面显示功能，虽然只需要几秒就可出现，但是用户对它的要求是非常高的（=1s），这个就是用户对不同功能有着不同的性能需求。如果性能调优的时间浪费在用户没有性能需求的地方，产生的优化结果对于用户的性能体验来说并没有任何的改善。其次，一个重要的原则是，在做任何优化之前需要先profile一下性能瓶颈，切

26、忌风风火火的优化，结果发现方向错了。有很多优秀的Profiler工具，比如JProfiler和YourKit，web前端优化方面，FireBug的概况和网络功能很不错。在并发测试和疲劳强度测试方面，不得不提的工具是LoadRunner。关于LoadRunner和并发测试知识的介绍，推荐看看Jackei的LoadRunner没有告诉你的系列，尤其是里面的理发店模型，通俗易懂，性能测试入门者必看。并发测试的优化方面，关于结果缓存的优化，特别是那种执行得出结果需要较长时间的过程，Java并发包的Future.get（）是一个很不错的面向对象的概念，具体的详细介绍请参考Java Concurrency

27、 in Practice一书的5.6章节： Building an Efficient， Scalable Result Cache。Web前端性能测试方面，也有很多优化的技巧，如果你用的是Jquery，这篇文章总结的不错，尤其是第一条， Always Descend From an #id， 在我之前的JQuery性能分析这篇文章里面有过详细介绍。兼容性测试向后兼容性指硬件和软件系统可以使用该系统的早期版本的接口和数据。向后兼容性考虑的是对接口的变更如何影响接口的现有用户（也称为服务使用者）。如果现有用户不受影响，则变更就是向后兼容的。如果现有用户受到影响，则变更不向后兼容，将需要使用策略来

28、管理变更的影响。兼容性测试的关键点在于分清楚设计成兼容和设计成不兼容，这个是测试人员主要关注的点。在有兼容性报告之前，用户经常会发现一个功能不能用了，以为是BUG，其实是设计成不兼容的，又没有相应的文档告知。就像程序员之间经常流传的一个笑话一样：Its not a bug， its a feature. 感觉上，像是测试人员给设计人员背了黑锅，明明是设计的垃圾，导致增增减减修修补补，反正设计成不兼容到最后都反馈不到设计人员头上，都认为是测试人员的问题。但实际上，测试人员本身没有责任吗，可不可以做的更多使情况往更好的方向发展？ 其实测试只需要将反馈流弥补通，将不兼容的后果反馈给设计人员，产品设计

29、也可以从用户身上学到更多，自然会对兼容性问题更谨慎一点，而测试本身通过兼容性报告也对产品发布的影响有了更多了解，还可以顺带帮文档把升级指南给做了。采用兼容性报告前后，对比各种兼容性问题造成的影响来看，兼容性报告效果明显。与兼容性相关的就是发布的版本号，兼容性可能导致的一个问题在软件管理中叫做dependency hell，随着系统越来越大，越来越复杂，这个问题会越来越严重。于是有人想出了解决办法，通过规范版本号，叫做Semantic Versioning。作者preston-werner是的创始人之一。安全性测试安全性在中国正在受到越来越多的重视，比如前段时间闹得沸沸扬扬的CSDN密码泄密门，

30、相应的安全性测试也会越来越受重视。常见的SQL注入等漏洞可以借助于AppScan这类安全性测试工具检测出来。易用可用性测试易用性测试报告除了可以对发布的产品信息了解更充分的作用外，还可以作为资料反馈给产品组，用户改进用户体验和产品易用性。测试组成员作为“产品发布前使用产品最多的人”，所以“易用性测试报告”应该成为 用户体验改进和易用性改进的重要依据。软件测试思考系列6：测试环境和配置管理自动化 同角色之间的划分往往有助于在角色的冲突中将问题暴露，实现透明，最终改进和保证质量。任何的软件开发团队都离不开两个基本角色：开发与测试。你可以没有项目经理，可以没有架构师，也可以没有设计师；但是不能没有开

31、发，否则没有人可以帮你实现产品；也不能没有测试，否则没有人可以决定你的产品是否能够交付。这就好像你往杯子里面倒水必须要用眼睛看着，没有眼睛反馈的信息，你永远不知道何时该停下来，也不知道停在那里；我们不希望水太少，更不希望水溢出来。眼睛与手的反馈循环就是我们实现倒水这一动作高质量的必要系统，而开发和测试的有效循环就是我们实现高质量软件的必须环节。但是开发和测试本身的角色的局限性造成了他们往往没有办法有效地形成循环，比如我们经常会听到这样的抱怨：测试：这个软件需要的环境太复杂，没有办法为每种情况都创建测试环境.测试：我没有办法保证测试的一致性，因为环境在不停地变化，恢复到原来的状态很麻烦.开发：你

32、是怎么测出这个Bug的，我怎么没法重现？测试：我忘记步骤了.其实这些问题都和测试人员本身的定位有关系，测试人员的首要目标是发现软件中的问题，要做到这一点他们往往专注于软件的反应而忽视了造成这种响应的原因，如：硬件软件环境，系统配置情况，操作一致性等等；测试用例失败有几种原因：功能缺陷BUG；测试用例本身写的有问题（ST或者ET脚本问题）；测试环境有问题；而这些正是开发人员修复Bug最需要的内容。但是测试人员不关心，或者没有更多的精力来关心这些内容，造成了非常多的“不可重现”的Bug的出现。我们可以通过持续集成以及对代码进行版本管理控制来定位变更和导致功能缺陷的原因，同样的，我们也可以对测试环境

33、的变更进行控制和版本管理。之前提到过持续集成要求对一切进行版本管理，其中也包括测试环境。初看上去，测试环境的管理是一个非常复杂的问题，之前是否遇到过下面一类问题？“要测一个什么东西，需要什么软件，然后手动安装一遍，结果发现另外一个机器上其实已经有这个软件了。” 测试环境的复用和共享问题。“有一个测试用例失败了，可是之前测试的时候一直通过的，开发人员在开发环境下测试也没有问题，测试人员费了九牛二虎之力，借助开发人员的调试帮助，结果发现是测试环境中的一个配置参数改变了。 此时，另外一个测试人员冒了一句，我之前测试另外一个问题的时候将这个参数改掉了。” 测试人员花了大量时间确定环境变更，测试环境的变

34、更控制问题。“有一个机器，你也在里面装个东西，我也在里面装个东西，结果这个机器的环境越来越乱，桌面上乱起八糟，最后谁也不记得机器里面的一些文件有什么用处了，当初是因为什么原因使用的，又不敢删除，怕其他人有用，可是又不知道会是谁。” 测试环境的管理和记录问题，好一些的会渐渐使用一些文档进行记录并共享，但是还是经常出现问题，毕竟文档也会过期。“一个测试MM突然大喊， 谁把我的模板和数据删除啦，给我出来！ 四周鸦雀无声。我小声的问一句，你上传到svn上了吗，上次不是说过一切都要版本控制吗？” 测试环境和数据的备份和删除，广义上说这个也属于变更。“我这里需要再安装针对ubuntu和suse操作系统的测

35、试，并且需要32位和64位都有，而且还要设置一大堆配置。可是现有的5台机器都安装满了，总不能重装来重装去的吧，每次重装都要了我的老命了.” 测试硬件资源的利用，和环境管理的效率问题。自动配置技术和利用虚拟化技术解决，测试环境数据化，配置化，然后才能版本控制和管理。开发人员：“我在自己机器上测试了没问题啊”， 测试人员：“可我在测试环境下面就是有问题啊。” 统一的测试环境问题。以上的这些问题，都指向了一个关键点，测试环境的管理，分而细之，又包括几个重要的因素：变更、自动化、数据化、虚拟化、共享。虚拟化技术虚拟化技术可以帮助将测试环境数据化，自动化，并借此达到重复利用的目的。虚拟化技术有很多，比较

36、优秀的有VMWare和Virtual Box。比如，很多测试环境是寄生在操作系统中的，我们可以将这些操作系统做成操作系统基线，平时不需要测试时可以不开着，要用的时候再开。这些操作系统基线可以进行版本控制，因为文件比较大，用svn之类的管理可能会遇到一些问题，可以针对性设计一些大文件版本控制软件（比如：结合SVN和FTP的优点）。配置管理自动化先后研究了几种配置管理的工具，Chef， CfEngine， puppet，最后用的比较多的是Chef。Chef比较好的一点是提供OpenSouce Chef Server，可以自己搭建服务器，也是这几个里面最先搭成功的，算是比较容易上手吧。就像一个大厨（Chef）使用刀（Knife）实验各种不同的菜单（Recipes），制成各种食谱（CookBook）一样，一个配置管理工程师就是用它来制作不同的测试环境。