前些日子看电视时看到一条新闻：上海福利彩票因为更新系统，导致上海福利彩票的销售终端在将近3天的时间内，无法进行销售。作为一名测试，我的第一反应是，这套系统在更新前后是否做过更新前后的数据，系统等等的兼容性测试？也就是在看到这条消息没多久之后，我们部门也在提交版本时发生了意外，幸运的是这个版本在最后部署到生产环境中去的过程中，更新人员发现了问题，及时得到了修正（我要说明的一点是，版本的测试已经在测试环境中通过，问题出在了数据库的更新脚本上）。这件事发生后，我一直在思考问题到底出在什么地方？

我想讨论的是“提升从搭建测试环境开始”，可能很多人很疑惑，这个题目似乎和我开头说的有点搭不上边，而我却不是这么看待的。我问过相关人员，你是怎么看待“搭建测试环境”这个事情的，你觉得你能从中学到什么？你觉得这个对你后面的工作有帮助吗？你觉得测试环境的更新除了替换版本外还应该考虑什么问题？很多人都会这么回答，我觉得能学到很多东西，但具体说不上来，对后面的工作有帮助，但具体有哪些帮助同样说不上来，测试环境的更新，除了保证更新成功外，似乎没有什么需要再考虑的了。

一个负责搭建测试环境的人的意识，如果不得到更进一步的提高，我想，生产环境中发生任何事情就变得不奇怪了（这里不探讨系统设计本身的问题）。

从搭建测试环境，我们到底能提升什么呢？

第一，             是更进一步的了解我们的待测试项目的系统架构。现在对我们测试人来讲的大环境中，测试介入项目的时间往往是项目即将完成开发进入测试环境的阶段。很多测试在拿到项目的后往往关注的是用例，执行，以及最后的结果，似乎没有更多的时间去考虑其他。对于为什么采用这么一个框架，可能很少关注，往往就是按照要求，把环境部署完毕后，联调成功，就算完成了第一步，然后就急急忙忙的开始我们的后面的工作。在我看来，这个是非常错误的，在部署测试环境的过程中，除了能更进一步的了解各个部分采用的技术外，在这个过程中，应该更多的了解一下，为什么会采用这样的方式。说直白一点就是，采用这样的方式的优势是什么？这么说可能还是有很多人不明白，我再举一个简单一点的例子把，我们现在有些项目会做成C/S的模式，有些项目是采用B/S的模式，为什么采用这样的模式？在比如B/S模式的系统中，有些必须考虑性能测试，有些则不需要，为什么？其实，通过部署的过程，你在了解系统设计的原理，你明白了这些，最后我们的用例必然会得到更多的充实。

第二，             更新过程中是否会对原有的数据产生破坏？大家必须注意到一点，测试环境和生产环境的最大区别在于，生产环境是一个延续性的行为过程，而测试环境则没有这么一个延续性行为过程，所以，作为测试环境的部署者，在部署环境的过程中要充分考虑到这个因素，什么样的更新版本才是符合要求的。这点我想可能能解决我开头提到的两个案例。

第三，             在部署中测试环境的复用。这点也非常的关键，资源的合理应用对于任何一个公司来讲都非常的重要，如果这个过程中忽略了这个问题，测试环境可能会变得非常的臃肿，对于维护起来可能会非常的困难。

1.               软件兼容性测试

兼容性测试是指待测试项目在特定的硬件平台上，不同的应用软件之间，不同的操作系统平台上，在不同的网络等环境中能正常的运行的测试。

兼容性测试的目的：待测试项目在不同的操作系统平台上正常运行，包括待测试项目能在同一操作系统平台的不同版本上正常运行；待测试项目能与相关的其他软件或系统的“和平共处”；待测试项目能在指定的硬件环境中正常运行；待测试项目能在不同的网络环境中正常运行。

兼容性测试无法做到完全的质量保证，但对于一个项目来讲，兼容性测试是必不可少的一个步骤。

2.               Web兼容性测试的主要类型

Web兼容性测试主要是针对不同的操作系统平台，浏览器，以及分辨率进行的测试。

2.1.          操作系统兼容性测试

常见的操作系统有Windows，Unix，Linux等，对于普通用户来讲，最常用的是Windows操作系统。Windows操作系统包括Windows XP，windows 2003，vista，Win2000/NT，Windows9x等等。用户使用操作系统的类型，直接决定了我们操作系统平台兼容性测试的操作系统平台数量，进行操作系统平台的兼容性测试的主要目的就是保证我们的待测试项目在该操作系统平台下能正常运行。

对于一些特殊项目（比如定制项目），可以指定某一类型的操作系统版本，这些都应该在需求规格说明书中指明，针对这些指明的操作系统版本必须进行兼容性测试。

大部分的其他项目，是不指定操作系统版本的，针对这样的项目，我们应当针对当前的主流操作系统版本进行兼容性测试，在确保主流操作系统版本兼容性测试的前提下在对非主流操作系统版本进行测试，尽量保证项目的操作系统版本的兼容性测试的完整性。

2.2.          浏览器兼容性测试

浏览器是Web系统中对核心的组成构件，来自不同厂家的浏览器对Javascrīpt、 ActiveX或不同的HTML规格有不同的支持，即使是同一厂家的浏览器，也存在不同的版本的问题。不同的浏览器对安全性和JAVA的设置也不一样。

目前最为常用的浏览器为：IE 6.0 IE 7.0.但由于操作习惯的问题，还有相当一部分用户喜欢使用腾讯的TT，以及firefox浏览器，这些浏览器同样也存在各个版本的问题。这个对于Web系统来讲是一个相当大的挑战。

对于一些特殊项目（比如定制项目），可以指定某一类型的浏览器（包括版本），这些都必须在需求规格说明书中指明。针对这些指明的浏览器必须进行兼容性测试。但大部分的项目，是不能指定浏览器的，针对这样的项目，那么我们必须针对当前的主流浏览器（含版本），在确保主流浏览器的兼容性测试通过的前提下，再对非主流浏览器（含版本）进行测试，尽量保证项目的浏览器的兼容性测试的完整性。

2.3.          分辨率兼容性测试

分辨率的测试是为了页面版式在不同的分辨率模式下能正常显示，字体符合要求而进行的测试。

用户使用什么模式的分辨率，对于我们来讲是未知的。通常情况下，在我们的需求规格说明书中会建议某些分辨率。对于测试来讲，必须针对需求规格说明书中建议的分辨率进行专门的测试。现在常见的分辨率是1024×768，800×600。对于需求规格说明书中规定的分辨率，测试必须保证测试通过，但对于其他分辨率，原则上也应该尽量保证，但由于这个在需求规格说明书中没有加以约束，所以在一定程度上，开发往往会拒绝进行调整。对于需求规格说明书中没有规定分辨率的项目，测试应该在完成主流分辨率的兼容性测试的前提下，尽可能进行一些非主流分辨率的兼容性测试，在一定程度上保证大部分。

开发与测试的关系似乎总是那么的微妙。“强势”的开发，“弱势”的测试，这种状态似乎一直没有转变过，也一直成为测试行业内最想扭转的一个目标。如何有效的摆脱开发的控制？

在讨论这个问题之前，我们首先来谈谈一个公司的发展。一个公司的起家模式基本都是先有开发，后有测试这么一个过程，总之一句话，就是测试不可能在开发之前成立（专门的测试公司除外）。公司的发展模式决定了开发的优越感，也因为公司发展的初期依赖的是开发，加之公司发展初期为了自身发展，“效率优先”的原则在很大程度上影响了“一代人”（一代人：指公司创业初期的元老，这代人通常都是设计领域或者开发领域的“强人”，这代人里通常不会有测试领域的“强人”），这一代人在公司初期项目中的习惯影响到了后续的项目，进而形成一个非常牢固的“外壳”，要想打破这个“外壳”，所需要花费的时间和精力是很难评估的。这就像我们从小形成的习惯，明知这个习惯相当不好，可是就是改不过来一样的道理。

公司需求发展，发展需要可靠的质量保证……，这个过程是公司向正规化方向迈进的关键一步，而测试也是在这个过程中诞生的。测试的存在，总是让一些人感觉非常的不舒服，因为开发在观念上会不由的认为测试是在为难开发（这些开发可能不是很成熟），虽然测试也一再强调我们是在协助开发完成项目，而不是为了为难开发。开发与测试是不可分离的，只是在项目中承担各自不同的职责而已。

公司的发展有一个过程，测试部的发展同样需要过程。测试部发展的初期，需要依赖开发的各种支持，但依赖开发的支持不能代表测试就应该丧失自己的原则。这个过程中，妥协的可能往往是测试，但妥协不代表就丧失了测试的原则。我常常对我们的测试人员说，做到心中有数，在适当的情况下，我们需要妥协，妥协的目的是为了把项目继续下去。

测试成立的初期，首先介入的是系统测试。这个阶段的测试主要是属于功能性测试，也就是在外人开来“这里点点，那里点点”的这么一个过程。这个过程往往被外界所轻视，但在我的眼里，这是一个测试部自我能力提升，以及完善最为关键的阶段。这个阶段直接影响到后续的发展。这个阶段测试部需要解决3个问题。第一个问题是学会整理“文档”，这个过程非常重要，文档是依据，这个阶段需要的就是不耻下问，进而形成测试的依据。第二个问题是测试环境必须独立于开发，而且必须是测试自己维护自己的测试环境。第三个问题，整理测试部的工作流程。 这个阶段是测试部最困难的阶段，因为这个过程实际在一定程度上触及到了开发的一些底线，这在任何一个人来看，都是所不能容忍的。这里我最想强调的一个就是测试环境由测试部进行维护的原则。这个是作为测试人的一个底线，如果测试连自己的环境都不能维护的话，这在我看来，测试就不能完全保证测试的质量一样的道理，举一个简单例子，测试的环境由别人在维护，作为测试，你能说我真的完成了某个版本的测试吗？如果测试无法把握自己的在测试版本，测试何以保证质量？随着测试能力的提升，集成测试就会成为测试部的发展趋势。这个过程中，测试部会逐步接触性能测试，接口测试等等这方面的测试，这个过程也是测试真正开始摆脱开发控制的一个关键。记得我们有一个项目，先前开发总认为性能上绝对不会存在任何问题，甚至在测试部提交的测试方案中，开发也是非常强硬的用“时间允许的前提下，可以考虑做一下”。这次项目测试的前期开发是主导，后期测试介入了，测试用非常有力的证据证明了开发先前的错误后，测试顺利的拿下了性能测试的权力。

测试需要逐步摆脱开发的控制，而不是一次成功。测试在自己的翅膀还不是很强硬的时候，需要“伪装”自己，需要低调，在不失原则的过程中逐步壮大自己，在悄无声息中成为基石。这其实何尝不是适合自己的发展呢？

由于工作出差的关系，很久没能在自己的博客上发表只言片语了。在出差的路上，我一直在想一个问题：“沟通的重要性”。

沟通是指信息自我传承或者不同个体间信息的有效传递与接受。沟通的方式可以包括语言沟通和非语言沟通。非语言沟通通常指通过文档，邮件等等方式进行的非面对面交流的沟通。

在实际的测试过程中，我经常能听到下面的人（这些人中有开发，有测试，还有其他）抱怨：“这需求里就是这么说的，也是这么设计的，你让我怎么办？”其实就这么简单的一句话，却暴露出了大家的沟通出现了非常严重的问题。

文档是大家进行沟通的一个基础条件，而现在很多项目的文档质量不高已经成为一个不争的事实，另一方面技术人员通常都自嘲自己“不善言语”。由于本人只要负责测试项目，我的观点大多从一名测试的角度出发，或许可以试用于其他方面。

对于测试来讲要从这质量不高的文档中去发掘“疑惑”，这个本领的练就除了“天分”外，更多的依赖你对项目的把握。举一个简单的例子：登录功能，我相信很多人都测试过，但在文档中你看到这个时，你能想到什么？登录通常都是输入用户名，密码，点击登录或者确定，进入下个流程。可能这个时候，大家觉得这个已经可以了，但作为测试，仅有这些内容，完全不够。文档中仅仅描述了登录的简单流程，并没有讲清楚各输入项的要求，如果特定的文档中也缺失了这部分的内容，那么你需要找专人去“沟通”，通过沟通，你需要确定用户名的规范是什么？密码的规范是什么？是否有易用性方面的要求等等，其实大家可以发现，这些都是作为测试在设计测试用例时考虑的东西，而这些东西如果缺乏，你的测试用例完全无法完成。

沟通的目的是让别人理解你的真实想法，千万不要想当然。我遇到过这样的情况，一个项目，可能由于我自己对业务相对于其他人来讲要熟悉的多，所以当我看到某个特定的描述的时候，我自认为其他人也明白了。可用例评审的时候，我发现大家对这个特定的描述根本没有理解，我很困惑，我质问大家，可最后我发现问题出在我身上，我把自己的意愿强加在了别人的身上：我自认为别人也清楚。所以，我们任何时候都要清楚沟通就是要让别人知道你的想法或者弄清楚别人的想法。

沟通是一门非常重要的技能，无论你现在的角色是什么，记住，沟通能让你有更多的收获！

我在跟很多刚刚进入测试这个行业或者在这个行业还不是很久的测试同仁们聊天的过程中，我发现很多人都有着这样或者那样的困惑：“每天似乎没有什么事情要做，感到非常空虚”“想学很多的东西，什么新鲜想学什么，可说不清楚自己到底想要什么？”……

我们常常感叹别人为什么能走在行业的前列，我们羡慕别人的光光彩的一面，事实上我们羡慕的是别人最终收获的结果，却忽略了别人为了这个目标付出努力的过程。

“每天似乎没有什么事情要做”，如果你有这样的感觉，千万不要觉得你们现在的工作非常的安逸，其实相反，你应该感到压力。你没有什么事情要做，一来可能的确当前没有事情要做，二来可能是你的领导认为你不能胜任工作。对于第二种情况，我不想多说什么，你需要更多反省，我主要想说一下第一种情况。公司不同的发展阶段，工作不可能永远处于繁忙的过程中，总有相对闲暇的时候，这个时候是你最好的思考阶段。想清楚自己最需要提升什么，想清楚公司当前最缺什么人才，如果你非常的清楚，那就充分利用这段时间给自己充电，你会发现你不在空虚。坚信领导都是明眼人，你通过自己的努力成为公司最好的潜力股，当机会降临的那一刻，我相信你一定能非常容易的抓住。也或许领导并非明眼人，可你学到了，你提升了，你选择离开公司的那天你会发现你的路更宽了。

不要在那里等待，这是最傻的做法，也不要寄希望别人能给你多大的帮助，一切只有靠自己的努力。道理永远是那么的简单，说出来也是老生常谈，可是你真的能做到吗？

有个测试同仁让我帮她看看她的简历，看完简历后我的直觉就是“这位测试同仁两年的测试白干了”。简历是一块敲门石，但这块敲门石是什么材质的，恐怕人见人智，然而什么样的简历才能是一块金质敲门石呢，下面是我的一个些个人见解，希望能给正在或正准备寻找更好发展机会的测试同仁们有所帮助。

针对在测试行业中已经有所感悟的人－凸现项目经验优势：

l         在公司允许的范围内，把你参与的项目做一个简单的介绍。比如你参与的项目的体系结构，实现技术等等。这些东西能在一定程度上体现你对测试项目了解的程度，熟知程度，从而也能体现出你的经验到底有哪些。比如，我们可以在我们的项目介绍中告诉对方我们采用的4层架构：数据库，中间件，webservice，客户端，采用的c/s模式等等，如果你觉得可以，我们列举我们的数据库采用的是什么，中间件采用的是什么等等，在简单描述了项目之后，你可以非常坦诚的告诉你所求职的公司，在这个项目中你主要负责的部分，比如主要负责哪个层次的测试，主要负责的是测试执行还是测试涉及等等。

l         对测试能力的描述。这一块很多人喜欢一概罗列，其实在我看来这是个大忌。一概罗列通常并不能体现出一个人的能力，有些人走得是测试管理路线，他擅场的一定是流程流程方面的掌控能力，有些人是走性能测试路线，他擅场的一定是具体的某个或者某些工具的使用。千万不要把自己描述成一个无所不能的，这在我看来，往往是一个无所特长的人。

l         如果可以，请加入一些测试方面的独特见地。我非常不喜欢的就是一旦问什么，都是书上的一套东西搬出来了，其实书本与现实有时有很大的差别，适时的表现出自己的独特见地，能证明你是一个活学活用的人，这样的人在任何一个单位都非常的吃香。

针对测试新人，切记“诚实的原则”：

l         有些人可能没有吸引人眼球的学历， 毕业院校，但请你大方的写出来，大胆的告诉你求职的公司，只有你认可自己，才能希望别人认可你，如果你加入这家公司，你也可以硬气的工作。学历，毕业院校可能成为你面试过程中的一点障碍，可是学历，毕业院校只能证明你的过去，并不能代表你的未来。现在大部分公司更认可一个人的能力，学历，毕业院校只是你一点出彩的地方而已。

l         有些人明明对测试这个行业并不熟悉，却喜欢在简历中吹嘘自己的精通这，精通那，其实即使你获得了面试的机会，但面试的过程中，我自信你一定洋相百出，最终的结果依然是淘汰。所以，请你大大方方的告诉你求职的公司，你是一个新人，你现在的测试能力到底在一个什么样的程度，很多公司需要自己培养适合自己的测试工程师，你的坦诚能为你收获更多。

本文出自太极人生的51Testing软件测试博客，转载请注明出处：http://www.51testing.com/?209773

如何评估项目的测试周期？任何一个测试部门的负责人都应该具备这样的能力，在现实的工作中，评估项目的测试周期其实是非常复杂的一件事情。

大家都知道，测试的过程其实并不简简单单是测试的事情，这个过程依然包含了开发的任务（BUG的解决），也就是说测试周期必须充分评估测试时间以及开发修复的时间。一个公司，如果开发团队的能力比较强，并且有非常好的流程保障的话，在一定程度上通常开发交付测试的项目的质量就比较高，而对于测试部来讲，可以按照1：1或者2：1的模式评估测试周期，然而现实的工作状态中，这是一种理想的状态，我相信很少有公司能保障这一理想模式。大部分情况基本都是“这个项目整个周期只有2个月，开发我需要40天或者更多”在这样的情况下，大部分公司采取的行为都是压缩测试的时间。虽然我们也非常清楚这样做是多么的不合理，可是除了无奈，我们似乎别无他法。也正式因为这样，对测试周期的评估就显得更加的困难，复杂了。

在我参与的很多项目中，项目启动初期，通常是各个部门“狮子大开口”的过程，只要开的不是那么离谱，通常都能得到保证，在这个过程中，测试部的要求也得到的很好的保证。随着项目的开展，需求的不断变更，可怕的事情开始，测试部虽然坚持，可是面对开发的“无米”状态，测试部也显得无能为力。

面对这样的现状，我在实际的工作中通常采用两套测试周期的评估方法。第一套就是按照1：1的方式评估测试周期，其实这套通常情况下是没有实际意义的，但这套评估方式能为测试部争取到一个主动的位置，如果可以的话，也可以为测试部争取更多的时间，在陈述为什么要这么多时间的时候，我们需要尽可能的把所有可能的情况都描述清楚，让项目小组觉得，测试的确是必须保证这么多的时间。当你占据这样一个有利位置的情况下，作为测试部的负责人，需要做一个事情就是测试周期底线的评估。这个过程是对测试时间，质量把控最好的一个方式。我们在第一套方案的基础上，把你认为可以提前的事情提前完成，把你在第一套方案中的“借口”划去，在这个基础上，重新制订一套测试周期评估方案，你对外争取到10天，实际你的心里底线是8天，当你在面对测试内部的人员时，你只能说是6天，这套方案实际是我们对内的方案，然而对于外界，当他们无奈中需要占用测试部的时间，压缩测试的时间时，由于他们已经理亏了，测试在后面的很多工作中能更加的顺利一些，而对于测试内部，你所有的安排其实没有被打乱，一切都依然在你的掌控中，一切进展都是那么的顺利！

在我写的上篇博客《测试团队金字塔型的发展模式》，有位朋友留言说到“好啊！ 现在的测试团队中能有几个说的算的呀！ 都是开发部牵着走”。这位朋友的留言让我想到今天这篇博客的题目就叫作《测试团队发展中的尴尬》。

任何一个团队，发展的历程都是从无到有，从弱到强的一个过程，这个过程并不是测试团队所特有的。公司的目的是盈利，公司在发展的过程中，成立一个新的团队，是因为希望这支新团队为公司带来更多的盈利。

测试团队的发展也不例外。在我面试的很多人中都这样告诉我“自己以前做开发的，后来公司成立了测试部，因为需要就去做测试了”。这样简单的回答，其实验证了一个问题，那就是这些调往测试部的一定不可能是在开发部说一说二的人（或许有些是，但我坚信很少），甚至我更坚信，可能有些人如果不去测试部会被公司辞退！公司需要测试团队，但往往成立初期都是无奈中的凑合。试想这样的一支团队，能是硬气的一支团队吗？能在短时间内成为公司力挺的一支团队吗？答案如此的显而易见，成长初期的测试团队除了受制于人，似乎别无他法！成长初期的测试团队就在经历这样的过程。

测试团队在成长，羽翼渐渐丰满，这个时候急迫的希望能挣脱来自各方的束缚，于是乎测试团队与其他团队的矛盾也在逐步的凸现。我们在这个阶段就会开始抱怨，文档不全，测试时间没法保证，凭什么你开发部说了算等等诸如此类。我们测试人的各种心情，各种心态在这个时候波动异常的激烈。虽然我们测试团队的成就在逐步获得认可，测试团队也在逐步的强大，但测试团队在这个时候依然在公司内部属于弱势，改变弱势这种状态不是一点点时间就可以的，这是一种观念的改变，更难的可能是改变领导的观念。所以这个时候，受伤的往往依然是我们测试。我带队的测试团队也同样经历着这些，需求我们参与，项目计划我们也参与，但最终决定时，就往往忽略测试团队的需求，甚至在关键时刻，测试团队依然会受到最直接的打压，可是我们需要记住，这是测试团队成长过程中需要付出的代价。当心态不在平和，当在迷茫中徘徊的时候坚持住，把这看作一种历练，坚持中不丧失原则，在失败中收获教训。

     我带队的这个测试团队3年多的时间里，我们正在经历的是“羽翼渐渐丰满，急迫的希望能挣脱来自各方的束缚”。努力让我们的测试团队流程更加的规范，努力与其他部门多多沟通，努力让我们测试团队的能力更加得强大，我相信正在经历得尴尬终将成为历史。

在我们公司测试团队的发展过程中，我一直在思考一个问题，什么样的模式适合现有我们这个测试团队的发展？

我先说说我们公司测试团队的现状，我们的测试团队与研发团队成立的时间差不多，但最初的模式是从属于研发团队，测试团队机会没有自己的独立决策权，完全被研发团队牵着鼻子走。随着测试团队的发展，测试团队优势的凸现，测试团队逐步形成了自己的工作模式，并且在整个公司的发言权，决策权也逐步掌握到了测试团队自己的手中，可以说，这个时候测试团队才真正称得上是一个真正得测试团队。

图一：项目测试过程模型

图一是一个简单的项目测试过程中的模型。一个待测试项目有测试团队负责人直接负责，每个测试团队都要面对很多的项目，所以测试团队负责人会根据测试团队的实际情况，将项目下发到测试团队内部的项目组中进行。当某个项目组接到具体任务后，会根据项目的实际情况及要求，在具体划分成各个项目小组，每个项目小组的责任各不相同。举个简单的例子：接到测试一个网上购物的项目，测试团队负责人将项目下发到了项目一组。项目一组负责人根据项目的情况，分成界面组，接口组……这里的界面组，接口组就是图中的项目小组，而每个小组的任务也相当繁杂，所以这个时候往往会在指派一名成员直接负责。

图二：测试团队模型

图二：是我整理的测试团队的另一模型，这里负责人主要职责就项目进度，人员的把控，也就是我们常说的计划以及协调。设计这里主要指的是测试用例设计，从一定程度上来讲，用例质量的高低在很大程度上决定了测试质量的高低，而能胜任用例设计这个职责的人通常在我们的眼里至少已经达到测试中级这个水平。而测试执行，往往是一个底层的枯燥乏味的工作，通常比较适合测试初级水平这样的角色。

现在我来谈谈为什么我们要采用金字塔型的发展模式。首先我们要讲一下“人”的问题，我相信很多公司的测试团队一定面临过这样的问题，“一才难求”，尤其一些特殊行业，由于对业务要求非常高，往往你具备了很强的测试方面这样那样的能力，但对于这些特殊行业，由于行业的特殊性，业务知识“0”的测试高手往往并不受欢迎，为什么？很简单，你虽然是高手，可是你在短时间内并不能为公司带来客观的效率。这样的公司往往都喜欢由自己培养“专才”试想一下，测试初级的人才相对于公司来讲非常容易招到，而这些测试初级人才经过公司一段时间的培养，既好用，由廉价。所以，测试团队的底层通常就是测试执行，也就是你在还没有更高技能的时候只要你有责任心，就往往能胜任这个任务。但从测试执行上升到测试设计，这个过程是漫长，可能有些人在做测试执行过程中也会接触这样那样的测试设计，但平心而论，这些设计并不能称得上是合格的，只是这样的设计并不会影响到项目质量，而胜任测试用例设计这个职责，在对公司业务方面，以及新技术方面的才能必须非常的突出，只有这样，才能设计出高效的测试用例。

而从金字塔型的发展模式的另一方面而言，也是不同的责任制，每一层向自己的上一层直接汇报，通过这样的方式，即锻炼了不同的人，也让工作变得简练，变得有调理。

如何进行有效的用例设计？作为任何一个测试用例设计者，这永远是一个非常难以回答的问题。这个问题至今为止也再不断的困扰我，人见人智。下面是我的一些个人见解，或许能对大家有一些启示。

第一：“明确”待测试项目的需求。对于任何一个项目，无论你接手的项目有多小，甚至可能都算不上一个项目，而仅仅是一个小工具，明确需求非常重要。可能很多人会说，公司现状，测试能看到需求文档几乎不可能；也或者公司有需求文档，但与实际的待测试项目相差甚远；也或者还有其他的各种可能情况，但无论是什么原因，明确需求是任何一名测试用例设计者必须坚持也必须执行的一条原则。如果你是测试部的负责人，在面对需求不明确的项目时，请你先收集待测试项目尽可能多的“文档”，这些文档有时并不一定需要是已经现成成稿的，其实我们可以通过“不耻下问”之后自行整理。测试负责人自己必须对待测试项目做到“胸有成竹”。

第二：“分析”待测试项目。可能很多人这个时候会非常不以为然了，为什么要经过这么一个过程？“分析”待测试项目的目的是让我们更进一步的了解待测试项目，那可能大家这个时候又会问了，了解什么？大家想想，你明确了需求，可是你知道待测试项目的体系结构是什么吗？你知道我们采用了什么技术吗？你知道这个项目蕴涵的业务知识有哪些吗？对了，我们就是要通过更进一步的分析，整理出更为详细的资料，服务于我们的测试工作。

第三：“学习”待测试项目的业务知识。这一点我相信很多人都能认同，比如你是做银行相关项目的，那你肯定要具备银行相关方面的知识，只有这样，才能非常容易的明白为什么这么设计，或者这么设计的优势在哪里？针对采用的某种实现技术，只有更进一步的学习了解，你才能明确这种技术的优势与弱势分别是什么，针对这种技术的弱势，我们测试又需要重点测试哪些地方等等。这些问题都需要在我们提升我们自身业务水平的同时得到解决。

第四：内部讨论。对于这点，我有非常切身的感受，作为项目测试负责人，一定要更自己的测试团队针对某个项目进行多次内部的讨论，通过内部讨论更进一步发现我们忽律的地方，同时也让大家的资源共享，用最短，最快的方式收获最好的效果。

JIRA是Atlassian开发，采用的是J2EE技术，随着对JIRA使用的更进一步，了解的更进一步，发现JIRA真的非常强大。

1.               J2SDK安装及设置（版本：j2sdk1.4.2）

J2SDK的安装非常简单，点击下一步下一步即可完成安装。

安装完j2sdk以后，需要对J2SDK进行设置：我的电脑->属性->高级->环境变量->系统变量中添加以下环境变量(假定你的j2sdk安装在c:\j2sdk1.4.2）：JAVA_HOME=c:\j2sdk1.4.2; classpath=.;%JAVA_HOME%\lib\dt.jar;%JAVA_HOME%\lib\tools.jar;（.;不能少，表示当前路径)；path= %JAVA_HOME%\bin; (系统里已经有了path变量，只需要在path最前面加上去即可) 。

2.               TOMCAT安装及设置（版本：tomcat5.5）

Tomcat的安装也非常简单，同样是点击下一步，下一步即可完成安装。

安装Tomcat后，同样需要进行Tomcat的配置：我的电脑->属性->高级->环境变量->系统变量中添加以下环境变量(假定你的tomcat安装在c:\tomcat5.5）：

CATALINA_HOME=c:\tomcat5.5; CATALINA_BASE=c:\tomcat5.5; 然后修改环境变量中的classpath，把tomat安装目录下的common\lib下的servlet-api.jar(此文件在tomcat5以前名为：servlet.jar)追加到classpath中去，修改后的classpath如下：

classpath=.;%JAVA_HOME%\lib\dt.jar;%JAVA_HOME%\lib\tools.jar;%CATALINA_HOME%\common\lib\servlet-api.jar;

最好再拷贝到:C:\j2sdk1.4.2\jre\lib\ext目录下，接着可以启动tomcat，在IE中访问http://localhost:8080，如果看到tomcat的欢迎页面的话说明安装成功了。这里的8080端口是可以进行修改的，但通常都采用默认的8080端口。

TOMCAT的端口号可以在TOMCAT的安装目录的conf/service.xml进行修改，如果启动TOMCAT无法启动，可以进入TOMCAT的安装目录的LOG下查看相关日志，进行确认。

3.               数据库的安装及配置

JIRA平台支持外部数据库，最常用的是是ORACLE和SQL SERVER。

我们公司选择的是ORACLE10G服务端数据库。假设我们创建了提供给JIRA使用的数据库JIRADB，用户为JIRA，角色：Connect、 Exp_Full_Database、Imp_Full_Database、Resource，系统权限：Create Any Table、Create Table、 Select Any Dictionary、Unlimited Tablespace，我们需要让此用户可以连接到此数据库，以及能创建库表。此处不做详细介绍。数据库的安装配置不做详细介绍，大家可以参考ORACLE方面的资料。

4.               JIRA部署

4.1.          JIRA配置

l         版本：

atlassian-jira-enterprise-3.6.2.zip（enterprise ear/war）

在安装根目录下建立一个空目录JIRASVC（比如d:/jirasvc），把atlassian-jira-enterprise-3.6.2.zip解压到当前文件夹。

l         修改:

D:/jirasvc/atlassian-jira-enterprise-3.6.2/edit_webapp/WEB-INF/classes/entityengine.xml

修改内容如下：

修改<datasource> Field-type-name=”oracle10g”【此处需要依据各自的后台的数据库】

（第94行<datasource name="defaultDS" field-type-name="oracle10g" ）

修改完成后，把此文件拷贝到下列目录下

D:/jirasvc/atlassian-jira-enterprise-3.6.2/webapp/WEB-INF / classes

l         编译war：

双击执行D:/svc/atlassian-jira-enterprise-3.6.2/build.bat批处理命令即可。如果修改了edit_webapp和webapp下的文件，必须重新执行编译动作。

4.2.          tomcat配置

l         copy文件：

D:/jirasvc/atlassian-jira-enterprise-3.6.2/dist-tomcat\tomcat-5.5\jira.xml――》c:\timcat5.5\conf\catalina\localhost

l         修改文件1：

c:\timcat5.5\conf\catalina\localhost\jira.xml

修改内容如下：

<datasource name="defaultDS" field-type-name="oracle10g" helper-class="org.ofbiz.core.entity.GenericHelperDAO" check-on-start="true" use-foreign-keys="false" 。。。。。。注意：去掉schema-name="PUBLIC"，无论用的是oracle9i还是10g，field-type-name都配置成oracle10g

l         修改文件2：

C:\tomcat5.5\conf\server.xml

修改内容如下：

Resource name="jdbc/JiraDS" auth="Container" type="javax.sql.DataSource"  username="jira" password="jira" driverClassName="oracle.jdbc.driver.OracleDriver" url="jdbc:oracle:thin:@192.168.1.19:1521" connectionProperties="SetBigStringTryClob=true" maxActive="20"/>

更新TOMCAT的库文件

将jira-jars-tomcat5.zip解压后的jar文件拷贝到Tomcat’s common/lib目录下

将oracle10g的JDBC驱动（ojdbc14.jar）拷贝到Tomcat’s common/lib目录下

4.3.          启动Tomcat

l         开始－程序－Apache Tomcat5.5－Start Tomcat

l         我的电脑－管理－服务和应用程序－服务－Apache Tomcat

l         启动中，可以查看C:\tomcat5.5\log，这个可以帮助问题定位

4.4.          JIRA应用

l         在IE中输入http:/jira安装机器的IP地址：端口号/jira即可启动JIRA

l         端口可以在 C:\tomcat5.5\conf\server.xml找到，如果端口冲突，也可以在这里进行修改

这些年，随着公司的不断壮大，新部门成立的时候，都会从测试部门调走一定的人员，而这些被调走的人员往往到了新的部门也就承担起一个部门负责人的职责。我不是很清楚其他公司是否也有同样的情况，但至少我们公司是这样。当这些人从测试部门被调走的时候，其实这些人员也已经偏离了测试行业，比如有些人转做了技术支持，有些人转做了需求，还有人……诸如此类。

我问过我们测试团队的很多人：“你们有自己的职业发展规划吗？”其中不乏有非常清晰的，但大部分人是相对比较模糊的。

首先我们要弄清楚，进入了测试行业，这个行业的优势有哪些？测试人员最拿手的是对业务知识的了解，对系统的掌握熟练程度。很多公司的很多业务都是具有延续性的，那么业务知识的了解能帮助你非常快速的进入另一个新项目的工作，并且能很快找到突破口。测试人员的沟通能力也是不容忽视的，如果一个测试人员没有很好的沟通能力，很难想想如何做好测试，毕竟国内的行情就是开发是大拿，测试相对来讲是弱势群体，然而也恰恰是这个，却让测试在工作中成长。我们清楚了我们这些优势，剩下的就是我们要弄清楚我们适合做什么？其实这点在一定程度上很难，但我们必须弄清楚我们自身的优势在哪里，只有明白了这些，那么在你的这也规划上才能很好的帮助自己决定。

在我看来，当你进入了测试这个行业，工作一段时间之后，就要开始进行自己的职业规划，有些人喜欢专注于业务能力的培养，那么这些人在后续可以考虑转做技术支持，需求，有些人的沟通能力很强，同时业务能力也相当突出，这些人在一定程度上可以往管理方向发展，还有一些人，喜欢技术方向的专研，那么这些人我建议依然走测试这个大方向而不要偏离。如果你选择了测试这个大方向，你依然需要想清楚自己适合往这个方向的那个支走，有些人本身喜欢开发，不妨给自己订个目标，自动化测试方向。有些人本身并不喜欢开发，那不妨走方案设计等等方向，总之一句，测试这个行业当你进入后，你会发现其实他的枝枝馒蔓，设置一不小心又离开了这个行业，但不管怎样，决定了，跨出了，就要坚持，而不是放弃！

一个公司在成立初期，由于公司名气等等的原因，在招人上往往不会太在意学历这个问题，通常只要能招到合适的人即可，而随着公司逐步进入正轨，在招聘时学历就会成为一道门槛，对于一些比较牛气的公司来讲，不但会考虑学历，还会考虑学校是否为重点学校。对于测试这个行业来讲，更显得的混乱。正规大学中开设软件测试这个专业的非常鲜有，而部分开设这个专业的民办学校也有着自己的无奈，师资怎样？教学怎样？

测试行业中到底是怎么看待一个人的学历与能力的呢？对于大部分公司来讲，首先看重的的确是能力，但是学历的高低，学校的好坏在不同程度上会影响到公司对这个人的评价。我相信大部分公司在招人是往往都会说我们公司更看重一个人的工作能力，这的确没错，但往往看到你的学历的时候，招聘工作人员会在主观上对你的个人能力打上一个标签，如果是在同等能力条件下的竞争，学历的高低，学校的好坏在最后就会成为评判的标准。尤其在当前这个情况下，测试行业内部本身就是鱼目混杂的情况，有很多人只是为了找到一份相对体面的工作，参加社会上的各种培训，在包装之后就踏入了测试这个行业，在这些人中不乏有突出的，公司对于录用的任何一个人也在不同程度上承担着各种各样的风险，对于公司来讲，招到一个合适的人才相当的困难，试想一下，面试一次，两次，公司又怎么能非常客观的来评价一个人呢？

在一些特殊行业，由于行业的特殊性，对于一些能力比较强的人来讲，有时并非受到公司上层领导的青睐。为什么这么说呢？大家都知道，要想做好测试，对业务知识的掌握非常的重要，而对于一些特殊行业来讲，任何一个进入这个行业要做测试的人，首先都要过业务这一关，虽然有些人就本身的测试能力上来讲可能已经非常突出，但是对于这些特殊行业来讲，也是一个新人，公司并不希望自己高薪聘请的人在一段时间内看不到成效，所以在这个时候，这些特殊行业的公司宁愿选择新人，甚至可能是测试行业内毫无经验者。

我个人看来，学历高的，毕业院校好的能增加一个人获得面试机会，但这仅仅是你获得的机会多一些而已，真正决定你能否适合这份工作的，依然是你的能力，最后就是你的个性，我们常说不是一家人，不进一家门，其实在很多情况下，个性适合一个公司发展的，同样也会增加你个人的魅力，为你争取到更多的机会。

测试流程是一个老话题，然而由于测试行业的现状，很多公司的测试部门本身还非常的不完善，更别谈什么测试流程了。我与一些朋友沟通过，朋友公司的测试部门通常情况就是开发让干什么就干什么，完全隶属于开发。我们公司这点还不错，从有开发部门的第一天起，测试部门也就随之建立了，但在测试部门成立初期，也是在开发让你干什么你就只能干什么，与开发一起在项目初期就介入项目几乎不可能，而且在测试环境的维护上，开发基本不同意由测试部门接手，随着测试部门的逐步强大，如今测试部门基本达到了项目启动即介入项目（虽然介入的测试人员有限），测试环境完全由测试部门接管。今天我把我们公司的测试流程拿出来和大家探讨探讨，看看是否还有改进的地方。

状态图(Statechart Diagram)是描述一个实体基于事件反应的动态行为，显示了该实体如何根据当前所处的状态对不同的时间做出反应的。状态机由状态组成，各状态由转移链接在一起。状态是对象执行某项活动或等待某个事件时的条件，转移是两个状态之间的关系，它由某个事件触发，然后执行特定的操作或评估并导致特定的结束状态。

起始状态表述如下： ，起始状态表示开始；最终状态表述如下： ，最终状态表示结束；状态表述如下：，比如点击登录就是一种状态，通常会触发一种行为的发生。状态图就是对各种行为状态的描述。通俗点来讲，状态图有点类似于我们在学校学习到的流程图。

我们写测试用例的时候通常发现有些东西我们很难描述，这个时候我建议大家可以考虑用图的思想来解决这个问题。下面我还是以邮箱登录为例。

就这样简简单单一个状态图，已经涵盖了测试“登录”过程中所有的情况，，对于用户名，密码该如何设计，对于大部分测试工程师来讲已经是非常简单的事情了，在这里，只要关注系统报错的类型，就能把测试用例准备完善。在实际运用中，我跟我们测试团队的人讲，如果你觉得你无法用语言描述，那你就画上一张状态图，其实用例就是让大家明白，不要拘泥于某一特定形态。

这个时候可能很多人会有疑问了，这个图大部分运用在需求分析和设计阶段，跟测试有什么关系呢？然而我个人的经验却告诉我，通过用例图，我能在最短的时间内掌握系统的基本构成，了解系统的需求，为后续完成高质量的测试用例打下一个好的基础。

测试介入项目无论是在什么阶段，首先要做的就是尽快了解项目的组织架构以及构成。介入阶段的不同，完成的详尽程度也不同，但最关键的一步就是我们要了解项目的用户（参与者），项目的功能需求（用例），以及最基本的构成（用例图：用例描述）。由于本人参与的实际项目不能对外，这里我举一个我们常用的工具为例：

    通过上图，大家可以知道此工具只划分一个用户，各用例实际就是这个工具的功能模块，此用例图非常清晰的描述了这个工具具有7个大的功能模块（或者也可以认为是7个子系统）。通过同样的方式，我们可以把这个工具的功能模块进行细分这里以“常用配置”－“查杀流行木马”－“选择扫描方式”为例，细分情况如下：

大家可以发现，通过这种方式，在非常快速的了解待测试的项目的同时，也为我们后面测试用例划分了最细一节的功能点。

个人对用例图的“忠爱”主要源于我可以非常清晰的把我需要与我的测试团队描述清楚的项目用这种方式简单的实现了，虽然这种方式仅仅达到一个基本目的，但任何事情都是循序渐进的。我也很清楚有很多人并不喜欢这种方式，我跟我的测试团队的人说了这样一句话：“图，人见人智，只要你能表述清楚，你可以采用任何一种方式，图只是手段之一而已！”

上面的工具可能过于复杂，而且可能还有很多人并不清楚，这里我就举我们最常用的“登录”为例。登录通常需要用户名，密码，以及最后的触发（通常是点击登录按钮）：

通过上面这张用例图，大家清晰的知道“登录”是我们的一个功能，且“登录”已经是最细一层了，不能再进行细分，使用登录可以有两种类型的用户：管理员用户，普通用户。这里我暂且不讲用户名，密码，以及触发登录行为的作用，在后面的状态图一节我会详细为大家讲解。通过这么简单的方式，大家就把用户，功能都简单描述清楚了，至于后面进一步的描述就需要通过其他的方式了。

第一次尝试的把自己的经验写出来，发现还不是那么容易表达，请大家谅解！如果大家觉得还有哪里不够，需要我再解释清楚一些，可以给我留言，如果觉得不足，也请多提宝贵意见。

UML（Unified Modeling Language）即统一建模语言，非常广泛的运用于系统分析阶段。我个人认为用例图（USE-CASE）是UML建模中最为基础的一部分内容。用例图可以非常轻松的表示系统的功能或者最原始的行为，将用户需求逐步转换成最基础的计算机语言。

用例图中最基础的元素为用户（大部分地方也叫参与者，Actor），用例，以及各种表示形式的箭头。

用户（参与者）并不是特指某一类型的人，而是指本系统之外的使用本系统或者与本系统交互中的某个特定的角色。这个用户（参与者）可以是某一类型的人，也可以是其他系统，还可以是其它事物。就目前我所参与的各个项目情况来看，用户（参与者）大部分都是特指某一类型的人或者其他系统。用户（参与者）在用户图的表现形式为：

用例是对包含变量在内的一组行为的描述，系统执行这些用例即可达到预期的目标。对于大部分初学者来讲，可以把这些用例想象成系统所要达到的某一功能。举个简单的例子，我相信我们中的大部分人都有自己的邮箱，当我们要进入我们的邮箱时我们首先需要完成一个登录邮箱的行为，那么此时我们就可以把“登录”看作是我们的一个用例，而登入邮箱通常需要用户名，密码，这些其实就是一组变量。用例的表现形式：

用例图则是将基础元素组合起来，形成了对系统最基本的描述：

UML对于开发来讲，应该是比较熟悉的，但对于测试来讲可能比较陌生。我第一次接触这个东西的时候仅仅是为了学分而已，并没有意识到这个东西在我后来的测试生涯中居然是那么的有意义。

UML中我认为对测试最有帮助的是用例图，状态图，以及序列图这3类图。图的思想可以帮助我们找到项目的主线，找到用文字无法表达的用例描述，并且可以非常方便的架起与开发沟通的桥梁。

首先是用例图，最为常见的用例图如下：

主角1可以理解为用户，用户有很多种，但任何一套系统的用户在设定之初已经确定，不同的用户他所使用的用例也不同。用例1（用例X）可以理解为功能模块，也可以理解为子系统（可以针对子系统单独进行用例图的划分）。通过这样简单的方式，我们能非常方便快速的整理出系统的各个功能模块以及各功能模块的使用者，从而完成测试中关键的第一步。

其次是状态图，大家都非常清楚，由于系统庞大，对于测试来讲如何写出有效的测试用例就显得非常关键了，而文字有时并不能非常方便的表述出你所想要表述的，在这种情况下，状态图就能显现威力了。状态图能把测试流程贯穿其中，通过状态图加上文字的方式，轻松有效的完成测试用例的编写。

最后是序列图，在实际使用中，序列图更多的使用在了接口测试过程中，系统的复杂，调用接口的繁杂，通过序列图却能很好的将这一问题解决。

先简单介绍一下，后续会将各个图思想与实际的小工具结合起来，以便大家理解！

作为测试部负责人，我前前后后面试过很多人，面试过程中我通常会问来面试的人一个问题：为什么要选择做测试？其实这个问题也是我当初决定要做测试时反复问自己的一个问题。大家不妨在看到这个问题的时候也反问一下自己为什么要选择做测试。

在我看来选择测试，最关键的一个因素必须是喜欢测试，也就是兴趣所在。只有你真的喜欢测试，你才能在测试这条艰辛的道路上真的有所作为。在参加面试的人中，有很多人给我的回答是因为觉得测试简单，测试的门槛比较低，可以比较方便的找到一份工作；还有一部分人是因为听信了社会上这样那样培训班的宣扬，真的把测试当作了“黄金行业”。针对社会上对测试认知上的误区，有时让我觉得有些无能为力，这些即将或者有可能成为测试家庭中一员的人对测试都是这样的一种意识状态，你还能怎么要求圈外的那些人呢？而也正是因为这一切，似乎更意味着这个行业的路不那么好走！我不知道为什么那么多的人都认为测试的门槛低，在我看来，那仅仅是一种假相而已。也许任何一个人都能非常轻松的站在门口看着门里的一切，但即使门槛很低，要想跨过去依然是那么的困难。

当你真的选择要做测试，除了喜欢，还有一点也是非常重要的，那就是必须忍受委屈，耐住寂寞。也许很多人会问我，这是什么意思？我不知道大家是否清楚测试在一个公司中的地位，我们公司对测试部门从表象上来看“很重视”，可往往关键时刻，测试部门就必须让步，而且是毫无理由的原则。美其铭曰是为了公司的大局，而最终的原因就是对测试部门不够重视，公司永远需要保证开发的时间，却可以忽略测试的时间的保证。测试部一次一次的抗争，在一些非关键事情上似乎总有突破，可是但凡是关键问题，受伤的总是测试部！

除了上面的几点，还有一点也是非常重要的，那就是测试必须具备韧劲！很多开发都会把测试看作是“胡搅蛮缠，不讲道理”，其实在我看来，测试如果不是坚持这点，更多的问题将会随着产品的上线而暴露。我非常害怕的就是测试被开发说服，当然测试被说服有一个重要原因是能力上不足的一个体现，但关键是不要轻易被说服，在遇上这类问题时，一定要多沟通，多方面验证，不要轻易的就放弃！当然作为测试部的负责人，必须在关键问题的处理上非常好的把握，既保证产品的质量，又能非常好的解决测试部门与开发部门之间的矛盾！

测试的工作是枯燥乏味的，那也是充满着乐趣的，只要你真的喜欢，那就坚持，不要轻易放弃。在这条路上走下去，也许你会发现其实这条路也没有想象中的那么困难！

也许是自己的坚持，也许是自己的努力，在这4年中，我得到了很多，也失去了很多。

迷茫过，兴奋过，成功过，失败过……当给自己一个空间思考时，我发现我这4年的经历也许可以给更多在测试这条路上坚持努力的同仁们一些参考，一些帮助！

4年前我发誓成为这个行业中的佼佼者，4年里我在努力，并一度让我似乎看到希望，当希望一次一次破灭，我明白了一个道理，技术之外还有更为难以逾越的障碍－人

当再次审视自己走过的四年，作为行业中人，我希望借助这个平台和大家一起分享！

测试知识，测试平台，测试流程……