正在阅读一本很棒的书，《软件测试经验与教训》。几名国外的软件测试大师，以大量的测试工作实战经验为出发点，总结了深刻而精悍的两百多条经验。作者把这些经验比喻成为波尔多红酒，鼓励读者分散阅读，带入自己的工作实际情境，慢慢细品，深入思考。当然还有，不要独摊波尔多，分享给我的朋友、同事们！
《软件测试经验与教训》一书，讨论的第一个话题，就是关于测试人员的角色定位。我对这个话题讨论的个人理解是：清晰认识自己的角色定位，能够帮助测试人员明确对自己工作目标的预期。而清楚的认识测试人员的角色定位，对于公司、项目的其他成员来说，可以使他们对于测试工作的“期待”更加恰当，即使是“指责”，也更恰如其分。关于这个话题，以下是对于书中部分经验的理解或讨论。
“测试员是前灯”
研发经理和开发人员或许正开着一辆吉普，行进在盘山公路上，测试人员的职责就是做好探路的前灯，哪里是悬崖，哪里有险情，前方的路面情况如何……而产品或者项目的关键决策，都是基于这些信息的。测试人员的职责是将关于这一切的尽可能详细的信息告知公司或项目的其他成员。
是这样的角色：全面搜集、整理、报告信息
不是这样的角色：决策者
“迅速找出重要的程序问题”
测试人员很重要的一条使命就是“迅速找出重要的程序问题”。如何做好这点，书中给出了几条建议。他们看上去很简单，很质朴，似乎每个人都知道，但是在实际工作方法中有经常性地提醒自己或者潜意识中就使用这几条建议么？所谓大道至简。
*首先测试经过变更的部分，修改和更新都意味着新的风险
*首先测试核心功能，测试产品所完成的关键和常用功能，测试完成产品基本任务的功能
*首先测试能力，即每个基本功能是否能用，然后测试可靠性，即深入检查每个功能在不同条件下的表现
*首先测试常见情况，使用常用的数据和使用情境。然后测试特殊情况。
*首先测试影响重大的问题
*优先测试最需要的部分--对团队其他成员有重要意义的任何部分的任何问题
*测试人员对产品、相关软硬件、产品的最终用户越了解，就越可能更快地找出重要问题。
“Follow 开发人员”
为开发人员提供支持，这也是测试人员的一项重要使命。尽可能建立最短、最快的反馈环路--开发人员交付产品时，马上进行测试；开发人员修改变更代码后，马上测试变更的内容（trunk版本的测试即是此种情况）。在书中，几位测试大师认为，最理想的情况是，开发人员为了修改测试人员发现的缺陷而忙得团团转，是开发人员，而不是测试人员，成为项目的瓶颈。当然，老板可能不会认为这个情况理想：）
“询问一切，但不一定外露”
多提问。做测试时，遇到的情况千变万化，不可能不遇到问题。如果真的连续地进行测试工作，而没有任何问题可提，那么不妨暂停一下手上的测试工作，留给自己一些思考的空间，还是那个论断，不可能没有问题。
书中提到提问的方法，认为直白的提问就如一剂猛药，会刺激到别人，所以尽量减低剂量，或与米饭同吃（结合其他沟通形式）。这个的确是个不错的经验建议，在面对开发人员、产品需求设计人员、实施人员等同事时，可以尽量采用这样的提问方式。当然，在面对测试部门同事、主管时，个人觉得，直接提问会更有效率。
“测试人员关注缺陷，团队成员才能关注成功”
“确认程序正常”永远不可能是测试人员的使命，测试人员只能说，“就我所执行的测试来说，产品没有不正常”。测试人员是团队中唯一不直接关注成功的角色。测试人员的关注点注定只能在关注产品缺陷上，而不能在关注证明产品正常上。测试人员关注缺陷，用自己的全部的创造力、精力和技能，寻找产品客观存在的缺陷，帮助项目团队更加了解自己的技能和产品风险，将产品不断改进。否则，这块关注点，只能由客户来关注了。那么团队，也就注定失败。
是这样的角色：关注产品缺陷
不是这样的角色：关注产品的成功
“不会发现所有问题”
测试人员的任务是发现并报告重要的产品缺陷，但是不会发现所有的产品缺陷。如果测试人员觉得自己可以发现所有的产品问题，那么要么是产品非常简单，要么是测试人员想象力太差。
知道并承认自己不能做所有的事以后，学会选择如何使用和分配自己的时间。
“不要期待用测试工作来保证产品质量”
产品质量来源于构建产品的人。测试人员的测试和缺陷报告，提供的是促进产品质量保证的信息，但是这种质量保证是来自整个团队的。
是这样的角色：提供关于产品质量的信息
不是这样的角色：保证产品质量
“永远别做看门人”
测试人员不该独立拥有控制产品发布的权利。权利即是责任。独立拥有权利的后果是致使其他团队成员心理上放松，并且有了推卸责任的理由--如果产品发版后出现重要问题，就会归咎于测试人员的把关不严。而如果测试人员为了避免这样的风险，而纠结于反复的完备的测试，那就会延误产品发布的计划时间，引起诸方不满。所以，产品发布的权利，还是需要项目经理把握，或者是某种方式的集体决定。
是这样的角色：产品质量的测试者和相关信息的提供者
不是这样的角色：决定产品发布
“当心扮演过程改进的批评者角色”
测试时发现种种问题，并且频繁反复出现时，也许测试人员会厌烦地觉得，要是开发人员能够认真细致一些，或许就不会出现这么多的产品缺陷了。把产品缺陷预防在未发生的时刻，这确实很有意义。但是不一定每件有意义的事情，都是想当然的可行的。事情除了理性的一面，还有情感的一面。就像告诉你的爱人，怎么样的生活才能更有生命的意义。如果尝试一下就会知道，好的忠告并不是总能被真正接受。问题不在于是否认识到，而在于情感。测试人员可以参与到公司、团队的整体过程改进中去，但是切记，不要扮演一个“批评者的角色”。因为这涉及同事间的情感。
是这样的角色：信息提供者
不是这样的角色：批评者
文档管理，有些公司也称为知识库管理，本文还是以文档作为称呼吧。
1、先说说文档管理的历史背景和演化史吧
一般情况下，文档可以包含很多方面的内容，一个Excel表格，一个需求设计文件，一个Bug的解决方案，一个功能的描述甚至是一个有用的图片都可以成为一个文档。所以对文档的标准解释就是文档是软件开发，使用和维护中的必备资料。它能提高软件开发的效率，保证软件的质量，而且在软件的使用过程中有指导，帮助，解惑的作用，尤其在维护工作中，文档是不可或缺的资料。
当然文档不仅仅是在软件开发中需要使用，其实是在任何公司中需要用到的，甚至比如在政府单位中也都是用到的，那些法律文件，行政命令，规范纲要都是文档，前段时间经常在说无纸化办公，但是文档其实还是以电子版的形式继续存在着，所以说，文档现在是无处不在，就当前社会在说，文档是绝对不可或缺的。
既然文档是不可或缺的，必然就会涉及到一个问题，那就是文档的管理，对于文档管理的作用，简单来说就是保存，分类和检索文档。从人类发明文字以后，其实文档的管理就已经开始，从一开始的甲骨文时代到现在的电子时代，文档的管理一直在不断进行中，只是形式随着时代的变化有所变化而已。
一开始人类社会可以能是用甲骨文的形式来保存文字，一些有意义的甲骨文就成为文档，然后需要保存起来让人需要的时候再去看，但是由于甲骨文是以龟壳的形式保存，你要真的去翻看，我想还是很有难度的，所以那个时候的文档管理，纯粹是实物堆放管理，挺多知道那个相关的文档放在那个位置，要具体去找一个内容是很麻烦的。
后来的呢，人类发明用竹简开始作为文档的记录载体，但是竹简其实还是一样很笨重的，虽然比起甲骨文而言，竹简记得内容可以更多很规范点，但是要去查找内容的时候还是很麻烦。
汉朝时，终于纸横空出世了，世界上最伟大的发明之一在中国诞生了，大家记录起知识开始变得很方便，而且很便宜（之前用丝绸记录虽然也轻巧但是贵），所以文字记录自此开始几何级的增长了。很多纸叠在一起变成了书，人类为了方便查找内容，还给书做了目录，真正意义上的文档管理就开始了。
但是虽然对于主要的内容可以通过目录查找到，不过你如果想去用通过查找几个关键字的方式来查找一段具体的内容的话，电子时代到来之前，还是没法做的很好，所以当然我也很难在查查这个书库里（类似少林寺藏经楼）是否有我需要的书了，即使找也只能找到一个书名，没法通过具体一个关键字来查找书了。
到了电子时代以后，文档可以通过以0和1的方式保存在电脑中了，文档管理有了翻天覆地的变化，人类可以非常便捷地把自己想要的知识找到，而且不仅仅在一本书中，可能是在一个图书馆中的所有书中，甚至是整个世界上的大部分书中，这种阶段，已是咱们的先人根本无法想象到的。
文档管理当然也是与时俱进的，有什么样的条件就能创造什么样的文档管理，进入现代文档管理已经变得极其强大，除了最简单的保存、分类和检索以外，文档管理还是加入的安全管理，版本控制，发布控制以及在线查看，协作编写等新的功能。在进入21世纪以后，随着云计算的出现，文档管理甚至还加入了云元素。
2、DevSuite中的文档管理
文档管理在任何公司和单位中都需要，但是我想大家也清楚，文档有些公司做的好，有些公司做的不好，当然有些公司的确不需要很好的文档管理，比如一个小的施工队，只要建筑图纸保存好了就行了。但是大多数公司我觉得还是需要一个很好的文档管理的，有些做的不好的原因，我觉得有两方面原因，一方面原因当然是主观重视不够，都认为不需要怎么整理，但是一到需要的时候就急得乱找，最后可能需要重做，影响人力物力和时间；另一方面原因就是缺少一个好的文档管理系统，文档如果只在电脑上保存的话，虽然说可以查询到，但是一旦文档越来越多的话，文档管理很有可能越来越混乱，文件乱放文件夹，版本没法控制，安全性没法保证，多人同时想来看和修改的话，很难管理，类似添加评论之类的功能就更加没法实现了。
对于一个软件公司而言，可能文档管理需求可能来的更加迫切，因为软件公司有大量的需求文档，设计文档，客户文档，技术支持文档，还有一些公司内部培训，合同，制度等文档，这些文档首先需要分类，然后可以搜索，更重要是需要：
1）权限管理（有些文档不是所有人都能看到）
2）流程管理（文档需要从草稿到最终成稿需要流程控制）
3）变更管理（类似设计文档可能需要经常更改，确保每个更改能够被记录，并且应该让看过之前版本的人知道有新版本了）
4）版本管理（一个文档在不同人修改后或者不同时间修改后，需要保存不同版本，并且各个版本之间能比较差别）
主观重视还是靠公司自己来努力了，你实在不重视即使有文档管理系统也没用。对于好的文档管理系统来说，我们还是可以有选择的，市场上的工具应该挺多的，今天我只介绍一下TechExcel的DevSuite系统怎么管理文档的，因为我们公司是买了这个产品的，下面是截图。
（未完待续）
如何管理好自己的时间
时间管理，本身就是一门艺术。时间是最公平的，每个人的时间都是一样的。如何在相同的时间里，做出不同的事业，这就是个人水平的体现。
一、故事
这里先讲一个故事。故事是抄来的，我修改了其中的一部分，使其更贴近我要说的主题。
有两个和尚他们分别住在相邻的两座山上的庙里。左边的山上住着瘦和尚，右边山上住着胖和尚。这两座山之间有一条溪，于是这两个和尚每天都会在同一时间下山去溪边挑水，久而久之他么变成为了好朋友。两个和尚都喜欢游泳。胖和尚经常在挑水的时候，顺便游上那么一会儿，而瘦和尚却极少在溪水里游泳。
不知不觉五年过去了。有一天，瘦和尚竟然没有带扁担来挑水，而是直接在溪里面游泳。胖和尚很纳闷，就问瘦和尚，你今天不挑水，怎么有水喝啊。瘦和尚说，这五年来，我每天做完功课后都会抽空在庙后面挖一口井，即使有时很忙，能挖多少就算多少。如今终于让我挖出井水，我就不用再下山挑水。现在我终于可以放心的游泳了。
于是，每天瘦和尚都可以自在的游泳，而胖和尚还是只能游一会儿就得挑水回庙里。突然有一天，两座庙同时失火了。瘦和尚很快就用井水把火扑灭了。而胖和尚还得跑到溪里面去挑水灭火，结果火灭的时候，庙已经烧掉了一大半了。
接下来，胖和尚每天除了要安排时间挑水，还得花大部分时间去修补破庙。而瘦和尚在游泳之余，还潜心书画。故事完毕。
二、重要度/紧急度
故事说完了，我们再来重头分析做事情的顺序。
根据重要度和紧急度来区分事件，是一个非常常用的方法。但是，到底什么叫重要，什么叫紧急呢？
重要的事情：对以后的工作生活、对以后的发展等，会产生明显的影响的事情，对目标的达成有显著推动的事情。
紧急的事情：需要立即处理的事情。
我们按照以上的象限图，来说一下事件的重要度和紧急度。
4：即不重要，又不紧急的事情。
即不对以后会产生重要的影响，又不是立即需要处理的事情。类似于和尚的游泳事情。此类事情，一般都是些兴趣爱好，或者受人之托，或者偶然的想法。
3：紧急不重要的事情
只是立即需要处理，但是并不会对将来产生重要影响的事情。类似于和尚的挑水，每天必须做，不做不行，但是做了也就是解决当前问题
2：重要不紧急的事情
不是当前必须要立即处理的，但是对以后会产生深远影响的事情。类似于瘦和尚的挖井，不挖也没事，但是一旦挖成功了，后面就可以不挑水了。如果当前有明确的目标，这类事情可以是对目标达成有明显帮助的事情。
1：重要紧急的事情
当前必须处理，不处理会立刻造成很严重的后果。类似于和尚们的庙失火，不立刻救火，就没有住的地方了。
三、分类处理
以上的四类事件，该如何分别处理呢？
很显然，最优先做的，是做重要紧急的事情，我想这谁都知道。而且这类事件，一般都是很容易标识出来的，也是非做不可的，人们一般都不会忘掉。
但是，并不是所有的事件都是重要紧急的。重要紧急的事件，一般都是救火类的事件，也就是说，是因为工作不好，或者一些意外造成的。那么，我们的正常工作中，充满了其他三种类型的事件，又应该如何各自的时间分配呢？
同样很显然，不紧急不重要的事情，尽量不要做。但是这个说起来容易，做起来却不容易。因为这类事件既然列出来了，就会有其诱惑性。例如很多人喜欢看电视，喜欢打游戏，喜欢看小说等等。就算在工作中，这类事情也是每个人都喜欢做的事情。很多项目经理会安排自己去编码，就是因为技术出身的，往往就喜欢去编码。所以说，这类事情，需要克制住，一定要克制住自己去做不重要不紧急的事情的冲动。
那么，剩下的2和3，需要怎么处理呢？
一个很普遍也很正常的理解，就是先做紧急不重要的，再做重要不紧急的。
坦率来说，这个想法也很正常。既然事情很紧急，那么我当然需要马上处理。重要不紧急的事情，等有空再说吧。
其实，很不然！
紧急不重要的事情，往往都是些日常的工作，都是或者都是些助人为乐的工作，容易做，周期又短，对将来不会造成多大的影响。也就是说，做了最好，不做也影响不大。但是，重要不紧急的事情，一般都是对将来会造成影响的事情，这类事情，往往都是不愿意做、周期长、难做的事情。
打个比方吧。项目组的新人比较多。项目经理需要整理一份技术培训资料，给新人们集中培训。这个就是重要不紧急的。而新人们有时候碰到问题，就直接跑来找项目经理求助，项目经理需要去帮他们解决问题，这就是紧急不重要。
如果项目经理频繁的打断手头上的事情，去帮新人们解决问题，则技术培训资料迟迟无法做出来，那么新人们的问题就会层出不穷，绵绵不断。这个就是个恶性循环。
如果项目经理能够果断的先出培训资料，争取早日把培训做起来，则问题会逐渐减少，这就是个良性循环。
还有一个更生动的例子。假如你在洗澡，满身都是泡泡，这个时候听到来了一个电话。接电话就是紧急不重要的事情，如果你去做了，结果就是满地的肥皂泡泡要打扫，就造成了一堆的紧急不重要事件。
所以说，要想把时间控制在自己手上，最需要做的事情就是：
重要不紧急
这类事件，周期长，难度大，所以需要日积月累的去坚持。这才是解决问题的王道。
四、疑点分析
很多人都会说，说起来容易做起来难。我们来分析几个疑点的地方。
1、紧急不重要的事情层出不穷，怎么办？
还是用刚才那个例子，如果新人们的问题不断，我总不能放任不管吧。
其实，就算你不立即去帮他们解决问题，他们也只是郁闷一阵子而已。这种时候，可以让他们先把问题都整理出来，整理清楚，并尝试着自己解决。然后在某个固定的时间段内（例如每天下午2点到3点之间），你集中帮他们解决即可。或者可以把解决问题的事情分摊在项目的其他几个技术高手身上。
2、一下子又做不完的事情，总是没有动力去做。
这类事件，一般都不是立马见效的。需要制定一个长期的计划，每天都安排固定的时间去做。不管多少，要保证每天都有进展。
3、我喜欢做的事情，就没时间做了啊。
相信我，只有把重要不紧急的事情做完备了，才会有更多的时间去做你喜欢做的事情。瘦和尚挖井成功了，就会有更多的时间游泳了。
4、不做重要不紧急的事情，不也是一样的嘛。
防火和救火的概念。如果只是做好当前的事情，每天做好紧急不重要的事情，那么一旦出现意外，则会造成更严重的后果，以后的事情都会变成重要紧急的。如果不把时间掌握在自己手上，那么就是每天都在救火状态。
五、处理流程
以前有一种做法，是每天上午，把要做的事情都列出来，然后每天晚上再把工作都整理一下，看看哪些做了，哪些没做。现在信息化社会，每天都会面临大量临时发生的事情。所以，现在可以用“事件篮”的方式来做。
现在开始，你准备一个“篮子”。这个篮子，可以是一个便签，也可以是一个小软件。作者用的是outlook的“任务”工具，这个可以和windows mobile手机同步。其他的工具也一样，只要能随身带着就行。
一旦你接受到一个任务，或者发现要处理的事件，先扔进“事件篮”里面。这个就像编码的时候发送消息到消息队列一样，不是同步处理的，也就是说，不是立即处理，再紧急也不是立即处理。
扔进去之后，判断这个事件是不是“重要紧急”。如果是老板喊你，或者工厂失火等重要紧急的事件，那么立即放下自己手上的活，去处理。
如果不是“重要紧急”的事情，那么就先让它在“事件篮”里呆上一会儿吧，专心把你自己当前在处理的事情做完。
做完了当前的事件，回顾你的事件篮。如果还有未识别的事件，则识别一下，按重要度很紧急度标识上。然后，看看你今天的重要不紧急的事件有没有处理，如果没有处理，则优先处理重要不紧急的事情。
经常性的，例如每周，都回顾一下自己的事件篮，把各个事件的重要紧急度重新识别一下。
六、经验
好记性不如烂笔头
不要以为自己的大脑有多狠，事情一多肯定会乱掉。设置合理的提醒机制，提醒你开会等定时的事情，会让你少很多心理负担。
不要同时做两件事情
不要把自己当作CPU。同时做两件事情，结果是没有一件能做好。完整的做完一件事情之后，再去找其他事情做吧。不要总是被打断工作，有些事情不立即处理，是不会有什么坏处的。
要找出“重要不紧急”的事情
很多需要被人推着走的人，是找不到“重要不紧急”的事情的。对于项目来说，经常的去识别风险，经常去想想项目可能会碰到的问题，提前预防，这都是“重要不紧急”的事情。千万不能任其自然发展，等到出事的时候，就是到处“重要紧急”的事件了，就疲于奔命了。
认准目标
识别“重要不紧急”的事件，最重要的标志，就是对终极目标是否有利。远大的目标，永远是大于眼前目标的。如果只是看准眼前目标，那么永远找不到“重要不紧急”的事情，或者永远找不对。
相关链接：
项目经理如何分配任务
项目经理问：为什么总是只有我在加班–挂包袱现象
问题描述：
如何组建性能测试团队？
精彩答案：
会员 fatfish：
随着软件应用的越来越广泛，软件产品的规模和使用群体正在呈爆发式增长，因此性能测试越来越受到软件供应商的重视，此外在某些领域中，对应用软件的性能表现有着显著的依赖和要求，如军工、通信、金融、商超等等，这些行业的应用软件往往会因为一些性能方面的表现不达标导致项目失败或给用户带来灾难性的损失！所以性能测试逐渐成为了软件质量保障的一个重要组成部分，而相应的，如何组建一个高效的性能测试团队自然就成为了有效进行性能测试的关键。
由于历史原因和现有条件制约，软件供应商可能并没有独立的性能测试团队，性能测试往往揉进常规的测试部门的工作中了，但我想如有可能，还是尽量能形成一个独立的性能测试团队，从而可以更好的开展相关工作，下面简单谈谈我认为比较理想的性能测试团队的组织构成。
由于项目的规模大小不一，因此下文只对理想的组织架构作阐述，具体每个分支组织的人员数量要随具体情况变化：
一）LEADER团队领导
职责：
1.制定团队整体的目标、策略、计划、流程和制度等工作纲领。
2.团队日常的经营管理，如预算编制、费用控制、人事安排、资源协调等等方面。
3.对性能测试的结论以及对产品/项目的质量影响作最终的报送及评判。
要求：为了体现性能测试的客观性和重要性，此职位建议相对平行、独立于常规的功能测试部门或小组，直接向质量总监或产品/项目经理负责。
二）业务分析组
职责：挖掘产品或项目的业务需求中的对于性能表现方面的要求，与客户、需求人员、顾问等一线人员沟通细节，再结合历史用户反馈的性能问题和要求作为经验积累，分析出可能涉及性能要求的相关业务场景，据以设计出各种性能测试方案以及预期达到的相关性能要素指标，尽量达到对用户真实的、潜在的使用状态和强度进行模拟。
要求：
1、有较丰富的项目经验。
2、有很强的分析抽取和概括总结的能力。
3、对IT部署（软硬件、网络布局等）有一定认识。
4、对业务有一定理解力。
三）工具应用组
职责：
1、负责工具选型，即根据业务分析出来的性能测试方案找到适应的测试工具（如LR、RPT等）。
2、向性能测试具体执行人员进行工具应用培训及指导。
3、条件允许的话尽可能的开发创新出专用性能测试工具或对原测试工具进行有针对性的二次开发从而使工具更为贴近所测产品的实际情况。
4、不断探索学习前沿、先进的性能测试工具或技术并尝试应用于所负责的产品提高工作效率。
要求：
1、熟练掌握相关测试工具的原理及应用。
2、对相关的程序语言、系统框架、数据库等等方面有较强的把握能力。
3、良好的分享意识和知识传播的能力。
4、勇于探索和持续创新的精神。
四）测试执行组
职责：
1、白盒测试人员，利用相关工具直接对程序代码进行测试和分析，从代码层面规避一些明显的性能隐患，优点在于不必等到产品全部完成就可以执行测试，在开发过程中就可以进行，发现问题随时与相关程序员进行沟通确认。
2、性能测试经理制定相关性能测试计划。
3、性能测试工程师根据分析出来的性能测试场景和方案设计具体的测试用例。
4、性能测试人员（或辅助人员）根据用例，使用相关的测试工具编写相关的测试脚本和代码。
5、性能测试人员执行相关性能测试，对测试过程进行维护、对测试结果进行整理、分析和报告等（某些深度的分析需要相关性能测试负责人、高级或资深性能工程师完成）。
要求：
1、熟悉相关测试工具的操作。
2、对相关的程序语言、系统框架、数据库等等方面有一定的把握能力。
3、具备一定的测试技术、用例设计能力。
4、踏实肯干、严谨认真的工作态度和团队合作精神。
5、本组可细化为几种岗位，区别安置具备相应能力的人员即可。
五）环境维护组
职责：
1、保障日常性能测试进行所需要的一切软件、硬件、网络条件能够按时、按质、稳定的提供（性能测试一般对环境要求比较复杂严苛）。
2、对性能测试过程中出现的环境相关问题及时进行排除，保障工作顺畅进行，不出现长时间等待情况。
3、对性能测试过的相关历史环境、数据等及时进行整理、备份（性能测试往往是海量数据，制作一次不易，一定要作好保存工作，另外性能测试中对比多个历史版本的差异也是一项经常进行的工作，这类工作往往需要用几套完全相同的性能测试环境和数据进行，这也需要相关数据及时安全的进行保留）。
4、记录、整理、分析测试环境对相关性能测试方案中环境要求的覆盖度，确保测试环境无遗漏。
要求：
1、较强的硬件设备、操作系统、网络部署相关应用能力。
2、一定的程序语言、系统框架、日志分析、数据库优化能力。
3、工作的前瞻性和计划性强。
4、具备较强的抗压能力和耐性。
六）机动资源
某些特殊情况下，团队资源不足以支撑要进行的性能测试工作时，可能会临时把一些机动资源划归进来进行辅助工作，如性能方面的云测试等。
七）专家支持组
性能测试是一种比较深层的测试，可能涉及的技术层面很广很深，如系统框架、协议、工具、数据库等等，测试过程中各种异常、复杂的情况层出不穷，有时我们必须借助在相关领域的专家们的力量来进行支援。这些专家往往不被设置在测试团队内，但企业中一般会有这一人群，负责解决相关领域一些高精尖难题的专家，可以从上层赋予这些人支持性能测试的这一职责，使其在一定场合下临时被虚拟纳入到本团队中来。
八）过程保障组
职责：
1、对性能测试过程进行的每个关键阶段进行监控（如评审活动），对风险进行及时的预警的报告。
2、对性能测试过程中出现的工作流程、制度方面的问题及时进行处理和改进。
3、解决性能测试团队成员不了解不清楚的工作流程、制度方面的问题。
4、收集、整理性能测试相关的工作成果（分析报告等资料）。
要求：一般由整个研发团队的开发管理部门人员担任，可单独分出一个小组负责支持性能测试团队的过程保障工作。
以上所述，即构成一个比较完整、能够相对独立、高效完成性能测试任务的团队，一家之言，算是抛砖引玉吧，仅供大家参考。
前言：
关于敏捷测试这块内容，本来之前一直想写的，但是自己一直觉得还没法归纳得很好，不过最近有个客户到我们公司来拜访时，也提到了他们公司要把测试这块工作弄好的事情，谈了几个小时，相互交流了一下意见，总算双方都有点收获，所以接下来几天想结合我们公司的实际情况介绍一下敏捷测试的一些相关知识，当然咱的想法也并非很权威啦，仅供参考。
正文：
谈到敏捷测试，可能有些人不一定听到过，不过很多人应该听到过敏捷开发吧，其实从广义来讲，测试也是属于开发过程的一部分，测试完成以后开发过程才算真正完成，所以敏捷测试其实也可以算是敏捷开发的一部分，之所以大家不怎么关注，一方面国内对测试行业的关注度远远低于开发行业，第二个方面其实也跟第一个相关，就是敏捷开发先流行起来，再加上国内的开发、测试比例，所以敏捷测试这个概念就显得不怎么流行了。不过，情况也在慢慢变化，从我了解到的情况看，越来越多公司已经在关注这一块了。
大家在百度上搜索一把，可以看到敏捷测试的标准定义：
首先敏捷测试（Agile testing）是敏捷的一种，原有测试定义中通过执行被测系统发现问题，通过测试这种活动能够提供对被测系统提供度量等概念还是适用的。
敏捷测试是遵循敏捷宣言的一种测试实践：
1、强调从客户的角度，即是从使用系统的用户的角度，来测试系统。
2、重点关注持续迭代的测试新开发的功能，而不再强调传统测试过程中严格的测试阶段。
3、建议尽早开始测试，一旦系统某个层面可测，比如提供了模块功能，就要开始模块层面的单元测试，同时随着测试深入，持续进行回归测试保证之前测试过内容的正确性。
稍微研究一把，大家就会知道，虽然加个敏捷两字，其实测试还是原来的测试，以前大家在软件工程里提到各种测试方法（等价类划分法、边界值分析法等等）、测试分类（白盒、黑盒等等）还是继续适用的，所以放心，如果你是测试工程师，不懂敏捷测试理论也不会让你丢了测试工作的，你只要能发现Bug，发现好Bug，发现很多Bug就Ok了。当然对于测试主管甚至再高层就不这么想了，呵呵，为啥原因呢，下面会慢慢为您解答。
那既然测试还是原来的测试，那还要敏捷测试干嘛呢，其实跟敏捷开发一样，敏捷测试你也需要从它的发展来理解它。很久很久以前（当然，也不是太久，也就是上个世纪的事情），即使在国外也还沉醉在瀑布开发中，所以在那个时候，测试呢，就一直躲在开发过程的最后，产品开发完成了以后，就开始大规模测试，测试完成，软件就发布了，就像练功夫一样，一气呵成，打完收工。
当然，后来发生的事情，我们现在也早已知晓，（唉，历史啊历史，人就像历史长河中的一滴水，如果不能扬名，那唯一结果就是被蒸发被遗忘，悲哉！（感慨一下先！））：
一开始的软件一个软盘就能搞定，没有多少代码量，所以出问题的几率就不高，测试放在最后一点问题都没有，但是随着软件越来越庞大，大家就慢慢发现问题了，如果一开始设计有问题，或者有重要功能做错了而直接影响到其他相关功能也出错，这类事情只能在最后的测试阶段才能被发现，虽然说测试就是为了发现Bug，但是这类问题发现得太晚带来最直接的结果就是代码需要大改，时间需要延期，成本需要增加，下面这个图就可以看出来，一个Bug发现的越早修复的成本越小，为什么呢，因为你想好了，一个Bug其实也就是一些代码，刚写的时候，它可能比较独立，或者只跟少数几个其他功能有关，也相对好找，但是一旦到了中后期，这部分代码可能被其他很多功能调用，你修了这个地方，那个地方调用时可能就会出问题，所以你就得把相关地方都去看一遍，如果漏了一个地方，不好意思，可能是个大Bug，所以你需要花费大量时间，体力，财力去修复，如果你在刚做完的时候就发现了，轻车熟路马上就可以改完，五分钟的事情。
我们公司以前（大约2006年之前）也是采用瀑布模型来开发产品的，所以测试当然也是瀑布测试了，对于测试人员来说，最直接的现象就是，平常很空，开发完成的时候就忙得要死，一轮接着一轮的测试周期，所以经常连着几周都在测试，经常加班；而开发呢，开发时很忙，测试时更忙，因为一方面有大量Bug过来，另一方面很多Bug都是很早之前产生的，要修复起来特别麻烦，还得去查原来的代码，焦头烂额的，更郁闷的是，经常发现有些功能没做对，不是客户所要的。所以也许开发过程就一个月，但是测试过程却花了两个月，最后到头来，客户说，这个产品不是我们想要的。
痛定思痛，做些改变吧，奥巴马都说了，We need CHANGE，所以大家就想啊想，想出一个V模型来，什么是V模型呢，且听下回分解。
（未完待续）
由于信息ERP应用系统建设的特殊性，监理单位此阶段的重点并不在于对具体工作的检查、测试，而应该放在对承建单位的宏观监督方面。
目前国内信息ERP应用系统建设过程中，在此阶段常发生承建单位不按设计阶段制定的质量保证计划对编码工作进行约束检查，忽视开发过程的单元测试、集成测试工作等情况。上述情况会导致工程建设质量得不到保证，最终影响到工程的质量、进度与资金投入。
因此监理单位在此阶段主要监督承建单位严格按照工程设计阶段所制定的进度计划、质量保证计划、系统设计进行开发工作，检查承建单位是否按照设计中制定的规范与计划进行编码与测试。在此过程中，监理单位主要通过代码走查方式检查编码规范的执行情况，检查单元测试、集成测试和确认测试是否按计划进行并有测试与修改记录、集成测试是否按计划进行并有测试与修改记录。在此过程中需要检查测试计划是否得到落实、测试方案与规范是否合理、测试是否有详细记录并进行修改与回归测试，必要的情况下可由监理单位对测试结果进行抽检。
对于开发过程实现阶段的监理，还需要注意承建单位版本控制方面的工作是否能够正常进行，是否有专人进行版本的总体控制、开发人员是否严格按照质保人员的要求进行具体版本控制，必要的情况下需要对版本控制的工作进行抽检。但切忌由监理单位进行具体测试而取代开发方的内部测试，这种方法并不能保证工程的质量。
系统测试一般由专门委托的测试机构进行，需要对所有软硬件进行以功能为主的测试工作（必要情况下附加性能测试），需要对测试情况进行记录并进行错误的修改与回归测试，在测试完成后要根据测试全过程的情况编写正式的系统测试报告。
在系统的实施阶段，承建单位在业主单位现有条件下进行系统的实施。承建单位制定详细的实施计划，进行现场跟踪，修改实现环境运行工程中发现的问题，对用户进行培训，制定详细的维护方案。
目前国内信息ERP应用系统建设过程中，在此阶段常发生承建单位实施计划不充分、现场跟踪不到位、错误修改及更新不落实、出现异常情况无法处理、培训工作不充分、缺少应有的维护方案等情况。虽然在前几个阶段的工作可能已基本完成工程建设的主体工作，但此环节工作不到位仍然可能造成工程建设出现大的问题。
因此，在此过程监理单位需要对承建单位在现场实施的情况及培训情况进行监督，检查承建单位是否有详细的试运行计划、是否有详细的现场跟踪检验机制、是否有稳妥可行的错误修改及更新方案、是否有详细的异常情况处理办法、是否有详细的培训计划、是否有详细的培训方案、是否有完善的正式运行维护方案。
实施阶段的监理的重点是：协助业主方和承建单位处理系统实施期间出现的各项问题，并予以记录；对于一些重复出现的问题，在验收测试时给予必要的关注，督促承建单位必要的解决措施；监督检查承建单位试运行阶段的培训工作。
技术培训监理的重点是：监督承建单位按照合同和业主的要求制定培训计划；审核培训计划的可操作性，要求在培训计划中明确：培训对象、培训教材、培训时间、培训方式和培训师资；监督技术培训计划的实施，对培训教材和师资进行评估，将培训计划执行情况和效果通报给业主。
前言：本篇文章对于软件管理系统与版本控制系统将作一定介绍，然后再介绍他们之间需要做的集成。
1、先来谈谈版本控制系统吧
Version Control System，简称VCS，属于软件配置管理（SCM）的一个部分。这个系统可能对于刚毕业的大学生来说比较陌生，几年前甚至对一些企业来说也比较陌生，简单来说这个系统主要是为了更好保存并调用文件（包括文本，代码，图像等）的各个版本。那为什么需要用这个系统来保存各个版本呢？
这个就需要追述到没有版本控制系统之前的历史了，那个时候也有程序员，也要写代码，一开始大家写了代码就直接保存，后来发现一个问题，有一天代码改错了，其实前一天的代码是没问题的，但是已经保存了，没办法恢复到前一天了。怎么办呢？大家想出一个办法，你每次做了修改，就必须保存一个副本，以便以后需要。
就这样，那个问题是解决了，但是后续问题又出来了，每天至少保存一个副本，副本是越来越多，但是一旦有一次我改错了，想去找原来正确的代码，我却没法一下子找到，因为副本太多了，我怎么知道那个副本里我是主要改了什么东西呢？办法又出来了，大家每次弄副本的时候，必须再用一个Excel文档记录那个副本改了什么，而且每个副本的名字必须统一，是XXX-1，XXX-2这样子，后缀是版本号。
这个问题又解决了，但是新的问题还是不断出来，我发现之前代码没这个问题，但是现在代码有这个问题，但是代码好像没改啥，我想最好能比较一下，但是一看代码有几千行，让我怎么去比较这2个版本之间的差别啊（后来经过千辛万苦终于找到原因，原来是一个变量初值赋错了，可能是当初的笔误），好像很难解决啊！
问题继续出来，同一个文件可能我在改，别人也在改，最后出了大问题，到底是谁改坏的呢，大家都不承认，因为是同一个源文件，放在同一个地方，大家谁需要的时候就去改，最后就不了了之了，因为根本查不出来的。
问题还在出来，我在改这个文件，刚改完覆盖了服务器上的那个文件，孰不知有另外一个人也拿了这个文件改其他一个东西，我刚覆盖完，他也传上去把我的覆盖了，最后出问题了说是我的责任，妈的，我明明传上去了，谁叫他覆盖了。
问题......问题还有很多，怎么解决呢？解决方案就是咱们说的版本控制系统，它的功能主要也就是我上面需要解决的各个问题，当然远远不止这些功能啦，以后再慢慢详说。
目前流行的版本控制管理工具有Subversion，Clearcase，Perforce，AccuRev，VSS等等，其中Subversion是免费的，Perforce在美国硅谷那块用得比较多。
2、再来说说软件开发过程管理系统吧
所谓的软件开发过程管理系统，从广义上来说，需要包括整个软件工程的所有部分，包括需求分析，概要设计，编码，测试和部署与维护，不过今天我们说这个仅仅只包括开发与测试的阶段，也其实就是代码会一直改动的那段时间（做功能与修Bug）。
还是按照上面介绍版本控制管理系统的方法来介绍软件开发管理系统。
在没有这个系统之前，我们是怎样管理咱们的开发过程（包括修Bug）的呢？一般情况下，领导发给Email给你说，某某某，今天你把这个功能做了，这就完了，然后出来的问题就是，你有没有做完，他不来问他就不知道，即使你跟他说了，由于功能太多，他也忘记了。所以呢，大家就想出办法，分配任务的时候，需要用Excel文档来记录，做什么事情，负责人是谁，什么时候做好的，代码放在哪里都得记上。
这个办法的确是很好，大家都很兴奋，以为一切都控制之中了，但是渐渐地问题又来了，功能很多，Bug又很多，都记录在Excel文档上，今天发我一份，明天发我一份，我太忙了，都来不及去更新这些内容，但是每天还是有新的发过来，到最后，不知道哪一份Excel文档是最新的，这个Feature有没有做，这个Bug有没有修，我自己都忘记了。
三个臭皮匠顶个诸葛亮，大家一合计，有了解决方法，不要这么多Excel文档了，就一个吧，所有的都记在一个上面，放在一个地方，大家自己上去更新，虽然办法是好，但是有时候还是忘记去更新。不过经常有人提醒我去更新，基本上也没落下啥。
但是不久以后问题还是再次出现了，经理想看看某段时间，小张修了多少Bug，做了多少功能，算了好久愣是没算出来，一看原来是，每个开发和测试记录的时间方式都不一样，有些人喜欢用年月日，有些人喜欢再加具体时间，有些人只用月日，纵是Excel有再强的功能也没法找出来。
唉，看来还得强制大家用统一格式啊，好了，问题总算解决了，但是福无双至，祸不单行啊，不久又出问题了，做的功能和发现的Bug越来越多，但是一个功能或者修一个Bug又不一定一天能搞定，经常弄完以后想去更新Excel，发现那个条目不知道在哪里了，太多了，而且有时候运气好很快找到，想一下子把做好的几个状态改掉也没法去做，因为不是连在一起的，得一个个找到，按住Ctrl，然后再去改，太麻烦了，实在受不了了！
呵呵，问题还不止这个了，有一个功能，有两个再不同时间都做过，后来有一个人去改了状态，但是最后发现这个功能有问题，他们两个人谁也不承认是自己改的状态。
......
渐渐地，大伙儿经常忘记去更新了（唉，也没个自动提醒功能），产品质量越来越差，人心越来越差了。。。
然后呢，大伙儿都知道了，软件开发过程管理系统横空出世了，全部解决以上的所有问题，当然也是远远不止这些功能啦，还包括了那个自动提醒功能了，呵呵。
目前流行的软件开发过程管理系统主要有，DevSuite，ClearQuest，Bugzilla等等，其中TechExcel 的 DevSuite 是覆盖整个软件生命周期的，Bugzilla是免费的，DevSuite对于中小团队也是免费的
3、两者的集成使用
好了，终于介绍完了这两个系统，比较简单，大家如果想了解更多的话，可以到网上去找找。
现在开始来讲他们的集成，这里所谓的集成，大家其实一想就明白了，版本控制系统只能管理代码的各个版本的，那么它们的集成也必然是跟这个有关的，我们还是以问题的方式开始这个部分。
作为开发，我们经常做功能和修Bug，但是有件事情不知道大家有没有碰到过，你做完一个功能或者修了一个Bug后，很久以后，测试人员发现还有问题，需要你再去改，那个时候你已经忘记代码是哪一块了，所以你就吭哧吭哧去看代码，找了好久才找到。
还有件事情，有一次你修了一个Bug，后来你再次碰到一个类似的Bug，虽然你找到了当初修的那个Bug描述，但是你却还是不知道当初怎么修的，所以呢，再次吭哧吭哧去翻代码，浪费大量时间，也许你终于找到那块代码，但是却发现这块代码后来被改过好几次了，也就是有N多个版本了，你不知道哪一个版本是你改的那次，头疼啊，还是再研究研究......
在这个时候，我们就在想，现在已经有了开发管理系统，对每一个功能和Bug都有任务条进行管理的，那么在我针对这个写Code的时候，是否能把该部分Code的修改时的版本与这个任务条做关联，使得以后我只要找到这个Bug（相对Code而言，有软件开发系统，找到一个Bug是一件非常容易的事情，不管这个Bug多么久远了），就能知道当初我在哪里写的Code，而且知道是改的是那个Code文件的哪个版本。这样子对我们的开发工作是帮助很大的。
既然有这个需求，各大系统提供商当然不会坐视不管，纷纷推出自己的产品，使得代码可以跟任务相关联，例如Perforce里有Job可以跟代码关联，AccuRev 中Task可以跟代码关联，当然做的最好的还是TechExcel的VersionLink工具，可以跟主流的大多数版本管理工具集成，也就是说如果你们公司用的是Subversion，VersionLink就可以跟Subversion集成，使得Subversion里的代码与DevSuite里的任务关联，如果你们用的VSS，VersionLink可以跟VSS集成，让VSS里的代码与DevSuite里的任务做关联。
当今世界，开发相关工具是越来越多，但是独立的工具越来越没有市场地位，能够集成在一起使用的工具才是真正大家需要的，因为软件开发各个部分本来就应该是紧密结合在一起的，以前之所以有不同的产品，主要是行业还在摸索阶段，现在到了成熟阶段，要尽可能使流程流畅，所以当然是谁能有一整套的无缝集成的解决方案谁才是王者了，所以呢，各个部分的集成就变得异常重要了。
1、“云测试”简介
云测试是基于云计算的一种新型测试方案，云计算通过网络以按需、易扩展的方式向用户交付所需的资源，包括基础设施、应用平台、软件功能等服务。
云计算包含三种不同服务类型：SaaS、PaaS和IaaS。SaaS（Software as a Service，软件即服务）指的是通过浏览器，以服务形式提供给用户应用程序；PaaS （Platform as a Service，平台即服务）指的是以服务形式提供给开发人员应用程序开发及部署平台，让其利用此平台来开发、部署和管理SaaS应用程序。平台一般包含数据库、中间件及开发工具，所有都以服务形式通过互联网提供；IaaS （Infrastructure as a Service，基础架构即服务）指的是以服务形式提供服务器、存储和网络硬件。这类基础架构一般是利用网格计算架构建立虚拟化的环境，因此虚拟化、集群和动态配置软件也被涵盖在IaaS之中。
从云计算的服务类型来区分，基于云计算技术的云测试属于PaaS层。它是软件测试工具（包括功能测试工具、性能测试工具等）服务商提供一个测试平台，软件开发企业在其平台上进行相关自动化测试、不再在本地计算机上安装和使用这些工具。这种无须本地安装和配置测试环境，在远程测试平台上进行测试的方式就叫云测试。
2、“云测试”的必要性
在企业的信息化建设过程中，通常需要对软件全生命周期进行系统化的测试，确定系统过程度量和质量度量，保证企业信息系统有序可控的设计、开发和运行，并实现对软件全生命周期的质量控制和过程管理。同时许多应用系统的上线运行、升级改造、运行维护都需要进行大量且频繁的系统测试。在日常的测试工作中，出现因测试资源不足而推迟测试时间、环境工具配置复杂而延长测试周期的情况。测试任务重、成本高、时间紧、人员和软硬件资源缺乏成为当前需首要解决的问题。
针对当前存在的问题，利用云计算技术可以实现企业内多个团队的测试平台共享。在建设测试基础设施方面，云测试可实现巨大节省，将前期的高额投入分摊到多个测试用户上，无需担心大量的硬件、软件和人力资源成本。
云测试提供一整套测试环境，测试人员登录到该测试环境，就可以立即展开测试。这将软硬件安装、环境配置、环境维护的代价转移给云测试提供者，极大地减少了测试环境搭建时间，如机器和网络准备、操作系统安装、各种测试工具软件安装等，提高了测试效率；在云测试平台上进行性能测试，可以开启更多的客户端，获得更加强大的运算能力，能够尽早发现和应对意料之外的流量高峰，让测试软件获得巨大的性能改善。
云测试不但可以提供完整的测试环境，还可以提供许多附加服务，如提供测试用例、测试数据、自动测试服务等。相比提供虚拟化的测试环境，此类服务更专注于特定的业务领域，提供了稀缺的专业技能，附加值更高。
3、大型企业信息系统中的“云测试”应用
（1）选择云配置
国家标准与技术研究院（NIST）提出一套关于云的定义，该定义提出了4种不同的云配置：
公共云：公共云的云服务通常遍布整个因特网，能够服务于几乎不限数量的、拥有相同基本架构的客户。如Cloud Testing企业能提供多种浏览器的平台，一般的用户在本地用Selenium把自动化测试脚本编写好，然后上传到企业网站，就可以在其平台上运行Selenium脚本。
私有云：这种类型的云针对单个机构特别定制，例如一些金融机构或政府机构。私有云都会采用一些虚拟化操作系统和网络技术，因此能够降低使用服务器和网络设备的数量，或者使这些设备的管理更为明晰。
社区云：社区云专为一系列互不相连的、严格界定的机构而设立，如供应链或是多个政府机构的联合体等使用实例。
混合云：这种云表现为以上多种云配置的组合，数个云以某种方式整合在一起，为一些商业计划提供支持。有时用户可能需要用一套单独的证书访问多个云，有时数据可能需要在多个云之间流动，或者某个私有云的应用可能需要临时使用公共云的资源。
结合大多数企业信息系统建设的现状，从成本、应用、管理、安全性等多方面考虑。私有云在安全性、可扩展性上优于公共云，且易于管理，更加适合于企业的云配置。
（2）云测试内容
目前企业云测试的测试内容主要包括：
测试内容 | 描述 |
硬件环境 | 测试软件在不同应用场景下对硬件环境的要求 |
软件环境 | 测试软件对不同运行平台（如操作系统、数据库、浏览器等）的适应性 |
功能 | 进行软件功能的自动化测试 |
性能 | 进行软件性能和压力测试 |
安全性 | 进行漏洞扫描、访问控制等安全性测试 |
标准符合性 | 通过二次开发的方式测试软件协议、接口、数据等的标准符合性 |
随着企业业务和云计算技术的发展，为软件测试服务的各种应用亦将得到发展，云测试的测试内容也应即时得到整理和更新。
（3）构建云测试平台
依据云配置，构建适用于企业的云测试平台应分为以下四层：资源层、资源管理层、服务管理层、访问管理层。
底层是资源层，资源层是构建云测试平台的基础，它包括服务器、存储和网络设施等。资源层由资源管理层管理，负责高并发量的用户请求处理、大运算量计算处理、及云数据的存储等。
资源管理层监控和管理平台资源的使用情况，迅速反应，完成节点同步配置、负载均衡配置和资源监控等工作，确保资源能顺利分配给合适的用户，动态地部署、配置和回收资源。
服务管理层提供管理和服务，对云用户和用户选择的云测试服务进行管理。云测试服务部署在服务管理层，是平台的核心内容。
最上面一层是访问管理层，提供云用户请求服务的交互界面，根据用户请求并转发到相应的程序，是用户使用云测试平台的入口。
这四层包括硬件和软件，共同构成了云测试平台。企业可以将应用程序、测试工具部署在平台中，提高测试的效率。
（4）扩展云测试应用
除利用云测试平台进行大规模的用户模拟外，结合企业测试业务，还可开展大量的测试应用。
企业测试工具集
通过将企业现有的测试工具整合到云测试平台，可以解决工具资源不足、配置复杂等问题。若需使用企业未购买且不经常使用的测试工具，还可通过公共云进行一次性的付费测试，降低测试成本。
基于企业的测试知识库
通过测试案例、业务知识、测试技术的积累，形成具有对象性的系统化的测试知识库。此类服务更专注于企业的业务领域，可以快速提升测试人员的专业能力。
4、可能存在的问题
使用云测试平台进行测试在很大程度上可以节约企业的测试成本、提高人员的测试效率，但是云测试固有的模式决定其在以下几个方面存在着不足和缺陷，需要靠相应的技术手段来完善和规避。
安全问题（企业信息安全和网络安全）
在进行功能测试或性能测试的过程中，软件如何实现相关功能的逻辑信息和技术手段都会部分体现在测试脚本中，软件的漏洞及性能状况也将会体现在日志中，若没有足够的防护措施造成这些信息的泄漏则对企业产生不良影响。
同时云测试基于网络，对网络传输速率和稳定性有较高的要求，网络中断、网速过慢、病毒攻击等问题都会限制云测试的应用。
适应范围限制
与C/S结构软件相比，B/S应用的软件更加适用于云测试应用。C/S结构软件仍需在云测试平台中安装被测试软件，实现手段上较为复杂。
对于因保密等原因限制网络访问的软件，也不适应于云测试，需要搭建专有的测试环境进行软件测试。
在
MySQL数据库中，支持单项、异步复制。在复制过程中，一个服务器充当主服务器，而另外一台服务器充当从服务器。如下图所示。此时主服务器会将更新信息写入到一个特定的二进制文件中。并会维护文件的一个索引用来跟踪
日志循环。这个日志可以记录并发送到从服务器的更新中去。当一台从服务器连接到主服务器时，从服务器会通知主服器从服务器的日志文件中读取最后一次成功更新的位置。然后从服务器会接收从那个时刻起发生的任何更新，然后锁住并等到主服务器通知新的更新。
这就是MySQL服务器数据库复制原理的基本说明。作为数据库管理员，对于这个原理只要有几个基本的了解即可。
实惠一：实现服务器负载均衡
通过服务器复制功能，可以在主服务器和从服务器之间实现负载均衡。即可以通过在主服务器和从服务器之间切分处理客户查询的负荷，从而得到更好的客户相应时间。通常情况下，数据库管理员会有两种思路。
一是在主服务器上只实现数据的更新操作。包括数据记录的更新、删除、新建等等作业。而不关心数据的查询作业。数据库管理员将数据的查询请求全部转发到从服务器中。这在某些应用中会比较有用。如某些应用，像基金净值预测的网站。其数据的更新都是有管理员更新的，即更新的用户比较少。而查询的用户数量会非常的多。此时就可以设置一台主服务器，专门用来数据的更新。同时设置多台从服务器，用来负责用户信息的查询。将数据更新与查询分别放在不同的服务器上进行，即可以提高数据的安全性，同时也缩短应用程序的响应时间、提高系统的性能。
二是在主服务器上与从服务器切分查询的作业。在这种思路下，主服务器不单单要完成数据的更新、删除、插入等作业，同时也需要负担一部分查询作业。而从服务器的话，只负责数据的查询。当主服务器比较忙时，部分查询请求会自动发送到从服务器重，以降低主服务器的工作负荷。当然，像修改数据、插入数据、删除数据等语句仍然会发送到主服务器中，以便主服务器和从服务器数据的同步。
要在数据库之间实现负载的均衡，其关键点就是数据同步的时间。如果主服务器与从服务器之间数据的更新时间比较长，此时从主服务器中查询得到的数据就会同从从服务器中得到的数据有差异。而如果同步的时间比较短，如实现同步复制，对网络带宽、服务器设备等就有比较高的要求。
可见这个同步的时间选择直接关系到其应用的效果。那么这个同步的时间应该选择多少呢？这没有一个固定的答案。主要是看用户的需要。如用户对数据的及时性要求并不是很高，或者数据更新的频率不是很高，那么这个同步的时间可以稍微长一点。但是如果这个数据的及时性要求很高，如股票的价格等等，此时就需要能够实现同步更新。所以具体要看企业实际的应用才能够决定采用什么样的同步时间。
在采取这个应用时，需要注意MySQL数据库的复制是单向的。即只能够将数据从主服务器复制到从服务器，而不能够将数据从从服务器发生到主服务器。这也就是说，数据库管理员不能够在从服务器上更新数据，否则的话，就可能会与主服务器上的数据产生冲突。默认情况下，系统会自动利用主服务器上的数据来更新从服务器上的数据。即在从服务器上所做的任何更改，到时候都会失效。如果是用户的请求，一般不用担心。系统会自动判断用户的请求是查询请求还是数据更新请求。并自动根据请求的类型转发到不同的服务器上。主要是数据库管理员，不要手痒痒，手动去更新从服务器上的数据。否则的话，就会导致从服务器与主服务器之间数据的冲突。
在MySQL数据库中，支持单项、异步复制。在复制过程中，一个服务器充当主服务器，而另外一台服务器充当从服务器。如下图所示。此时主服务器会将更新信息写入到一个特定的二进制文件中。并会维护文件的一个索引用来跟踪日志循环。这个日志可以记录并发送到从服务器的更新中去。当一台从服务器连接到主服务器时，从服务器会通知主服器从服务器的日志文件中读取最后一次成功更新的位置。然后从服务器会接收从那个时刻起发生的任何更新，然后锁住并等到主服务器通知新的更新。
这就是MySQL服务器数据库复制原理的基本说明。作为数据库管理员，对于这个原理只要有几个基本的了解即可。
实惠一：实现服务器负载均衡
通过服务器复制功能，可以在主服务器和从服务器之间实现负载均衡。即可以通过在主服务器和从服务器之间切分处理客户查询的负荷，从而得到更好的客户相应时间。通常情况下，数据库管理员会有两种思路。
一是在主服务器上只实现数据的更新操作。包括数据记录的更新、删除、新建等等作业。而不关心数据的查询作业。数据库管理员将数据的查询请求全部转发到从服务器中。这在某些应用中会比较有用。如某些应用，像基金净值预测的网站。其数据的更新都是有管理员更新的，即更新的用户比较少。而查询的用户数量会非常的多。此时就可以设置一台主服务器，专门用来数据的更新。同时设置多台从服务器，用来负责用户信息的查询。将数据更新与查询分别放在不同的服务器上进行，即可以提高数据的安全性，同时也缩短应用程序的响应时间、提高系统的性能。
二是在主服务器上与从服务器切分查询的作业。在这种思路下，主服务器不单单要完成数据的更新、删除、插入等作业，同时也需要负担一部分查询作业。而从服务器的话，只负责数据的查询。当主服务器比较忙时，部分查询请求会自动发送到从服务器重，以降低主服务器的工作负荷。当然，像修改数据、插入数据、删除数据等语句仍然会发送到主服务器中，以便主服务器和从服务器数据的同步。
要在数据库之间实现负载的均衡，其关键点就是数据同步的时间。如果主服务器与从服务器之间数据的更新时间比较长，此时从主服务器中查询得到的数据就会同从从服务器中得到的数据有差异。而如果同步的时间比较短，如实现同步复制，对网络带宽、服务器设备等就有比较高的要求。
可见这个同步的时间选择直接关系到其应用的效果。那么这个同步的时间应该选择多少呢？这没有一个固定的答案。主要是看用户的需要。如用户对数据的及时性要求并不是很高，或者数据更新的频率不是很高，那么这个同步的时间可以稍微长一点。但是如果这个数据的及时性要求很高，如股票的价格等等，此时就需要能够实现同步更新。所以具体要看企业实际的应用才能够决定采用什么样的同步时间。
在采取这个应用时，需要注意MySQL数据库的复制是单向的。即只能够将数据从主服务器复制到从服务器，而不能够将数据从从服务器发生到主服务器。这也就是说，数据库管理员不能够在从服务器上更新数据，否则的话，就可能会与主服务器上的数据产生冲突。默认情况下，系统会自动利用主服务器上的数据来更新从服务器上的数据。即在从服务器上所做的任何更改，到时候都会失效。如果是用户的请求，一般不用担心。系统会自动判断用户的请求是查询请求还是数据更新请求。并自动根据请求的类型转发到不同的服务器上。主要是数据库管理员，不要手痒痒，手动去更新从服务器上的数据。否则的话，就会导致从服务器与主服务器之间数据的冲突。