& 做软件测试工程师真的很容易吗？【转】
做软件测试工程师真的很容易吗？【转】
总结一下，要做好一名软件测试人员到底有多难····
　　1、得有一颗保持“白痴”的心：测试往往都在被丢在最后才开始进行的，作为发布前的最后一道门，就得担当起用户的角色，想着用户是怎么用的，怎么用才感觉到好用。用户往往都是很笨的（虽然他们是我们的衣食父母，但经常被很多人这么描述），找不到哪是哪，做为测试人员就得把自己想像成对面前的这个东西不认识。即使你闭着眼都知某一个按钮在哪里，你也得保持对他不认识的态度，这叫返朴归真。
　　2、不厌其烦的重复工作：开发人员提交测试的版本很少有一次测试通过的，发现的BUG，开发人员要改，改好了要继续测试，往往复复，你不能厌烦，如果厌烦了，就会有疏忽遗漏，小打小闹的BUG跑到了用户那里还好，要是影响了公司生计的BUG跑去了，最后背黑锅的肯定是你没商量。
　　3、脑子够清醒，记忆力够好：不是有了测试用例就有了保障卡了，跑完了测试用例就跑完了测试的，测试用例也是人写的，人写的就会犯错和遗漏的，很多的BUG是你在不经意间搞出来的，这个时间你就得像录像一样，能回放刚才的操作。发现了100个BUG，有99个不记得是怎么操作才出现的，那跟没发现是一样的。
　　4、清晰的逻辑思维：在测试前要写测试用例，干测试这行的都知道，可是测试用例写出来后，覆盖率能达到多少，这就不一定的，有的人的逻辑足够好，覆盖的面就足够广，有的人写来写去，最后把自己写迷糊了，他写出来的东西可想而知，有几个人能看懂了。
　　5、要有良好的书写能力：写测试相关的文档，不是写散文和小说，用简单的语句就可以，不需要太多华丽的词语，重点突出别人能看懂就行，但也得书面化一点，不能口头语大白化太多，这是要给别人看的，要存档的。
　　6、眼睛够毒，心思够细：能抓住别人容易忽略的细节，如果你是一个粗线条神经的人，你会漏掉很多美好的东西；
　　7、与人沟通的能力：没有人生活是真空的，有人的地方就得有沟通，项目延期了，要压缩测试时间，得去沟通；几个人一起测试一个项目得去互相沟通，发现BUG了；对BUG的意见与开发人员不一致，得去沟通；因为项目的需要，得借助其他项目组成员帮忙，得去沟通；有那种很讨厌的开发负责人，自己手下烂的要命，他还特别护犊子，不让你说他手下的不是，你又得去沟通。总之沟通的没完没了。
　　8、团队协作能力：每个人都是有个性的，在家你是万人宝，在外面就不一定了，不可能还是所有人都是围着你一个人转的，所以请收收你大小姐，大少爷的脾气。团队不是个人英雄主义。你帮了别人，反过来别人也会帮你的，记住这样一句话，“帮完了所有了，也就帮了你自己。”
　　9、有危机意识：如果你真的认为测试就是点点鼠标，用个这个法那个法的写个测试用例，就完了，那你也离彻底完蛋就不远了。
10、会点开发语言和对数据库有一定的了解：工作中沟通最多的是开发人员，他们有自己的一套语言，如果我不懂他们的语言，与他们沟通就会很麻烦，所以要了解他们的语言；如果你想做到你够牛，在开发人员提到你这个测试的时候，不会条件反射的想到你只是点点鼠标然后给他们找一堆麻烦的人，那你除了给他们找到麻烦外，最好还能告诉他们，他们的的麻烦在代码的哪一行，是哪个方法引起的，怎样改，他们的麻烦就解决了，这样的话，他们就把你当神一样崇拜了；做测试的时候，总免不了要写一些测试的脚本之类的，写代码是开发人员的特长，但你不能总是麻烦别人吧，如果你跟他的私人关系好，他可能会很快的帮你写，如果关系不好，他可能就不帮你写或者把你的事情排到后面，明明是公家的事，却沦为了私人交情，这也太怪异了吧。如果你愿意天天抱怨和丢下不做了，那没关系，到时候你可以去你头头那里讲你的困难和理由，还很充分的。
　　11、有点不怕死的精神：你的头有不对的地方，你合作的开发人员的头有不对的地方，除了听他们手下的人抱怨外，敢对他们去讲他们的错，你是一个旁观者，讲出来会更客观。
　　12、会除了黑盒手动功能测试外的另外一种测试：功能自动化测试、性能测试、安全测试、灰盒测试，很多，精通一样，自己就有了一种资本， 没办法，行业趋势如此，如果你对人讲你会测试，测试方案设计的很好，测试用例写的很好，别人大脑里映射的是你只会点鼠标，就连做测试的也会这样认为，只要和性能测试、自动化测试沾上边，就认为你是神了。请注意这里的会性能测试、自动化测试不是说会使用某个或某些工具，是会。工具就是给人来用的，如果你不能确认你想做的事情是不是对的，事情的方向是否正确，结果中发现的错误是什么原因引起的，那你就是不会。但是很多人就是那么肤浅，衡量一个人就是看会不会用某个工具，一些很牛X的公司在面试的时候居然也会问出某某个函数与某某个函数的区别是什么，现在的人不缺的就是google，在哪里都能google出他想要的结果，两个函数的区别，或者说在一个脚本的代码里用哪个函数比较好，只要长了脑子的都能弄出来，真搞不明白，他们还会问这种问题，对于前期准备、方案设计倒是不问。
　　13、学习能力：不进则退，大家都懂的；
　　14、整理、总结：软件测试是个很杂的活，做的越多，接触的越广，不明白的，不会的就越多，如果总是不会的就问，问完了就忘的话，早晚有一天所有人都不愿意让你去问了，因为你太笨。做不到举一反三，最起码也应该能做到问过的东西就能成为自己的东西。
　　15、分析、梳理：点点鼠标只是一个去实现的过程，在点鼠标前应该能分析出什么是对的，什么是错的，哪个方向是对的，不然选错了方向都不知道，还在闷着干活，最后的结果肯定也是错的。
　　16、有人的地方就会有权力斗争，单纯的IT也不例外，选好队，站对队，做好一个篮球，千万别做成足球；
　　17、你还得是一个好奇宝宝：以你一个人来映射千万个用户，软件的犄角旮旯就都得点到，所有不可能的操作你都得尝试去做，没点奇思妙想是做不到的。
　　18、你得懂点认知心理学：感觉是靠不住的，你说这个东西不合理，开发人员就说合理，最后只能是不了了之，有理有据的说服他才是王道。
　　19、你还得有点倔脾气：很多时候，明明是你在帮别人，可是他不领情，还阻碍你帮他，如果你还依赖着他，那你就死定了，发挥一下你的倔劲儿吧，证明一下，没有他你一样可以做好。
　　20、能屈能伸：行业的现状如此，外人小看做测试的，开发人员鄙视测试的，领导层轻视测试的，就连测试的自己都觉得自己干的活没啥技术含量，你不能每次都和人家干一场架吧，自古就有大丈夫能屈能伸，用行动证明吧，证明他们失去了你是个严重的错误。
　　21、了解你从事的行业，了解你使用的操作系统：这些最基本的，如果连你赖以生存的饭碗都不了解，还干个屁呀。
　　22、最后，不抱怨，耐得住寂寞，英雄都是这样练成的，如果有一天你觉得除了抱怨，已经无事可做了，那你离开的时候到了。
除非注明，文章为原创，欢迎转载！转载请注明本文地址，谢谢。
本文地址：
相关日志2012 年 10 月 28 日 -- 2013 年 3 月 20 日 -- 2012 年 11 月 12 日 -- 2012 年 10 月 24 日 -- 2012 年 10 月 30 日 -- 2012 年 11 月 13 日 -- 2012 年 10 月 30 日 -- 2012 年 11 月 4 日 --
- 38,952 views - 25,843 views - 23,335 views - 16,845 views - 14,777 views - 8,825 views - 8,822 views - 8,749 views - 7,339 views - 5,701 views做游戏测试员有前途吗？ - 乔布简历
做游戏测试员有前途吗？
浏览（ 10345 ）
随着现在手机终端的普及，手游产业也越发成熟起来，游戏公司因此对游戏测试员一职的需求也逐渐旺盛。或许一些想要投
给这个职位的同学会问到，做游戏测试员是否有前途，那么就让小编来为你分析一下吧。
游戏测试员是很多着迷于网络、电脑、电视游戏的人们追求的一种新职业。通过疯狂的敲击键盘检测游戏中是否会出现程序错误，又或者是通过突然断电的重复动作检测主机连接游戏服务器的速度和可能出现的程序漏洞。更多的测试员选择通过工具，内存修改，设置断点，封包修改等方法来制造游戏漏洞，然后加以修复，以免这些漏洞被外挂制作者利用。
由于游戏特别是网络游戏，是人类社会的另一种方式的体现，所以包含了人类社会的一部分特性，同时它又具有娱乐性、可玩性等独有特性，所以测试的面相当广，测试主要包括以下3个方面：
1、游戏情节的测试，主要指游戏世界中的任务系统的组成，有人也称为游戏世界的事件驱动。
2、游戏世界的平衡测试，主要表现在经济平衡、能力平衡（包含技能、属性等等），保证游戏世界竞争公平。
3、游戏文化的测试，比如整个游戏世界的风格，是中国文化主导，还是日韩风格等，大到游戏整体，小到NPC（游戏世界人物）对话，比如一个书生，他的对话就必须斯文，不可以用江湖语言。
游戏软件测试是个可以很快入门的职业，门坎不高。游戏测试员的薪水根据企业规模、城市等因素的不同有较大起伏。最低月薪仅2000元，较高的可以达到9000元。外企公司一般会提供相对较好的待遇，当然白盒对从业者的英语水平有一定的要求。从业者的经验是衡量薪水的重要指标。对于游戏测试这个职位而言，技巧及方法都需要通过实践的积累，因此从业时间越长越容易获得较高的薪水。游戏软件测试工程师在一家软件企业中担当的是“质量管理”角色，其中包含技术及管理等方面的工作，工作相对稳定，对年龄没有限制。而且随着项目经验的不断增长和对行业背景的深入了解，会越老越吃香。
在游戏产业的高速发展下，几乎每天都有新游戏出炉，这意味着需要更多的测试员投入游戏测试工作。国内的游戏测试员大多供职于游戏开发运营公司，专业的游戏测试公司发展刚刚起步，尚有不错的发展空间。不过，若是
时想要尝试游戏测试员的学生，也要做好一定的心理准备。毕竟游戏测试并不会像真的玩游戏那样给人带来愉快的体验，经常会有反复性的工作难免会感到枯燥，因此即便是游戏测试员，也必须具备一定的抗压抗枯燥的能力才行。
转载请注明出处，欢迎参与讨论，纠错和补充内容
使用量24041
使用量19290
使用量15067
使用量7700
back to top
其他用户还浏览了后使用快捷导航没有帐号？
查看: 1496|回复: 14
【转】在做自动化测试之前你需要知道的（比较长，但值得一读）
注册会员, 积分 122, 距离下一级还需 78 积分
论坛徽章:1
什么是自动化测？ 　　做测试好几年了，真正学习和实践自动化测试一年，自我感觉这一个年中收获许多。一直想动笔写一篇文章分享自动化测试实践中的一些经验。终于决定花点时间来做这件事儿。 　　首先理清自动化测试的概念，广义上来讲，自动化包括一切通过工具（程序）的方式来代替或辅助手工测试的行为都可以看做自动化，包括性能测试工具（loadrunner、jmeter）,或自己所写的一段程序，用于生成1到100个测试数据。狭义上来讲，通工具记录或编写脚本的方式模拟手工测试的过程，通过回放或运行脚本来执行测试用例，从而代替人工对系统的功能进行验证。　　当然，我们更普遍的认识把“自动化测试”看做“ 基于产品或项目UI层的自动化测试”。
分层的自动化测试
　　这个概念最近曝光度比较高，传统的自动化测试更关注的产品UI层的自动化测试，而分层的自动化测试倡导产品的不同阶段（层次）都需要自动化测试。
　　相信测试同学对上面的金字塔并不陌生，这不就是对产品开发不同阶段所对应的测试么！我们需要规范的来做单元测试同样需要相应的单元测试框架，如的Junit、testNG，C#的NUnit ，python 的unittest、pytest 等，几乎所有的主流语言，都会有其对应的单元测试框架。　　集成、接口测试对于不少测试新手来说不太容易理解，单元测试关注代码的实现逻辑，例如一个if 分支或一个for循环的实现；那么集成、接口测试关注的一是个函数、类（方法）所提供的接口是否可靠。例如，我定义一个add()函数用于计算两个参数的结果并返回，那么我需要调用add()并传参，并比较返回值是否两个参数相加。当然，接口测试也可以是url的形式进行传递。例如，我们通过get方式向服务器发送请求，那么我们发送的内容做为URL的一部分传递到服务器端。但比如 Web service 技术对外提供的一个公共接口，需要通过soapUI 等工具对其进行测试。 　　UI层的自动化测试，这个大家应该再熟悉不过了，大部分测试人员的大部分工作都是对UI层的功能进行测试。例如，我们不断重复的对一个表单提交，结果查询等功能进行测试，我们可以通过相应的自动化测试工具来模拟这些操作，从而解放重复的劳动。UI层的自动化测试工具非常多，比较主流的是QTP，Robot Framework、watir、selenium 等。　　为什么要画成一个金字塔形，则不是长方形 或倒三角形呢？ 这是为了表示不同阶段所投入自动化测试的比例。如果一个产品从没有做单元测试与接口测试，只做UI层的自动化测试是不科学的，从而很难从本质上保证产品的质量。如果你妄图实现全面的UI层的自动化测试，那更是一个劳民伤财的举动，投入了大量人力时间，最终获得的收益可能会远远低于所支付的成本。因为越往上层，其维护成本越高。尤其是UI层的元素会时常的发生改变。所以，我们应该把更多的自动化测试放在单元测试与接口测试阶段进行。　　既然UI层的自动化测试这么劳民伤财，那我们只做单元测试与接口测试好了。NO! 因为不管什么样的产品，最终呈现给用户的是UI层。所以，测试人员应该更多的精力放在UI层。那么也正是因为测试人员在UI层投入大量的精力，所以，我们有必要通过自动化的方式帮助我们“部分解放”重复的劳动。　　在自动化测试中最怕的是变化，因为变化的直接结果就是导致测试用例的运行失败，那么就需要对自动化脚本进行维护；如何控制失败，降低维护成本对自化的成败至关重要。反过来讲，一份永远都运行成功的自动化测试用例是没有价值。 　　至于在金字塔中三种测试的比例要根据实际的项目需求来划分。在《google 测试之道》一书，对于google产品，70%的投入为单元测试，20%为集成、接口测试，10% 为UI层的自动化测试。
我为什么要做自动化测试？
　　根据51testing的《中国软件测试从业人员调查报告》，手工测试占到的89% ，相对开发来说，测试的门槛底，薪资普遍较底，所要求的知识面虽然有一定广度，但缺乏深度。这是测试的普遍现状。　　正因为手功测试人门槛不高，使大量的毕业生，甚至是非专业人员涌入这个行业。从而增加了这个行业的激烈竞争。对于工作几年扔处于手工测试的人员来说都会有强列的危机感。由于工作的技术含量不高，薪资的涨幅遇到瓶颈，另一方面受到新进入者的威胁，同样的工作公司花5K招来的人就可以做，那么就不会花8K 的招。　　好吧，这个问题不应该出现讨论技术的话题中，但他的确是大多测试人员不得不面对的一个问题。所以，从测试人员自身的发展来说，我其实非常需要通过自动化技术来增加自己有竞争力。当然，做到一定年限测试人员会选择转管理或其它岗位，这又是另一个话题了。　　从测试行业的发展来说，国内产品由于产品特点，世界级的产品不多，技术含量相对不高，质量要求相对要求不高，外包国外项目，测试人力成本低廉，所以需要大量的手工测试人员。　　所以，在不远的未来，我认为纯的工手测试人员的需求是递减，公司更需要更高技术能力的测试。质量需要测试，测试行为永远不会消失，但纯的手工测试人员是否消失是有可能的。　　好吧，你可以说测试多朝阳的行业，我纯属在危言耸听。不管未来如何，我们都需要提升自身的技能对吧！
什么项目适合做自动化测试？
　　假如你已经决定要学习自动化测试了，如何学习是要面临的下一个问题？这个问题以被测试产品为出发点进行分析，假如你所学的技术不能得到应用（验证），将会使你的学习过程寸步难行。　　首先考考虑产品是否适合做自动化测试。这方法比较普遍的共识是从三个方面进行权衡。
　　软件需求变动不频繁　　测试脚本的稳定性决定了自动化测试的维护成本。如果软件需求变动过于频繁，测试人员需要根据变动的需求来更新测试用例以及相关的测试脚本，而脚本的维护本身就是一个代码开发的过程，需要修改、调试，必要的时候还要修改自动化测试的框架，如果所花费的成本不低于利用其节省的测试成本，那么自动化测试便是失败的。　　项目中的某些模块相对稳定，而某些模块需求变动性很大。我们便可对相对稳定的模块进行自动化测试，而变动较大的仍是用手工测试。
　　项目周期较长由于自动化测试需求的确定、自动化测试框架的设计、测试脚本的编写与调试均需要相当长的时间来完成。这样的过程本身就是一个测试软件的开发过程，需要较长的时间来完成。如果项目的周期比较短，没有足够的时间去支持这样一个过程，那么自动化测试便成为笑谈。
　　自动化测试脚本可重复使用　　自动化测试脚本的重复使用要从三个方面来考量，一方面所测试的项目之间是否很大的差异性（如C/S系统和B/S系统的差异）；所选择的测试工具是否适应这种差异；最后，测试人员是否有能力开发出适应这种差异的自动化测试框架。
选择什么工具进行自动化测试
　　假如你已经确认了XX 项目适合做自动化测试，那么接下来你要做的就是选测试工具了。　　首先要先确认你所测试的产品是桌面程序（C/S）还是web应用（B/S）。　　桌面程序的工具有：QTP、 AutoRunner　　web应用的工具有：QTP、AutoRunner、Robot Framework、watir、selenium　　由于B/S架构的诸多优势，早几年前大量C/S架构的应用转为B/S结构。从而也推动了web开发与测试技术的发展。假如，被测试有产品是C/S架构的，那么推荐QTP ，QTP在UI自动化测试领域占到了一半的试用率。所以，足以说明QTP在自动化领域强大，易用性等。学习主流的工具也可以使你获得更多的机会。市面上关于QTP的书籍也非常丰富。当然，要想学好QTP ，你必须要掌握VBS脚本语言。　　如果，被测产品是B/S 结构，那么推荐selenium ，为什么不是QTP 或其它工具？因为selenium 对B/S应用支持很好，更重要的一点，它支持多语言的开发，真正的试用selenium ，你所要掌握的不仅仅是一个工具而已，你还需要学习一门语言。我为什么要选择selenium？还要学一门语言，这无疑增加了我的学习成本。增加成本的同时，也增加的你的竞争力，而且，在这个过程中你不单单只是学会了一个自动化工具而已，你完全可以使用所学的语言去做更多的事情。　　好吧！假如你决定试用selenium 了之后，你又面临了一个新的问题，选择一门语言。selenium 是支持java、python、ruby、php、C#、JavaScript 。　　从语言易学性来讲，首选ruby ，python　　从语言应用广度来讲，首选java、C#、php、　　从语言相关测试技术成度（及 资料）来讲：ruby ,python ,java　　或者你可以考虑整个技术团队主流用什么语言，然后选择相应的语言。
selenium 用前须知
　　OK！经过上的过程，我相信你一定做出的相应的选择，如果你选择的是selenium 工具，那么接着往下阅读。首选你在开始selenium之前，需要花一到两个月时间去学一门语言，这里是根据没有语言基础的同学而定的。我推荐ruby ,python ,java 任意一门语言来进行学习。　　当然，已经如果有很好的语言基础略过这个环节，或者你的丰富的java编程能力，那么学习python 可能只需要几天时间或更短。　　假如，你已经搞定了一门语言的基础，接下来你需要先了解selenium ，selenium 并不是单纯的一个工具，他是一组工具的集合，而且，他还有1.0与2.0之分，当然3.0也已经到来。　　selenium 也不是简单一个工具，而是由几个工具组成，每个工具都有其特点和应用场景。
selenium IDE　　selenium IDE 是嵌入到Firefox浏览器中的一个插件，实现简单的浏览器操作的录制与回放功能。那么什么情况下用到它呢？　　快速的创建bug重现脚本，在测试人员的测试过程中，发现了bug之后可以通过IDE将重现的步骤录制下来，以帮助开发人员更容易的重现bug。　　IDE录制的脚本可以可以转换成多种语言，从而帮助我们快速的开发脚本，关于这个功能后而用到时再详细介绍。
selenium Grid　　Selenium Grid是一种自动化的测试辅助工具，Grid通过利用现有的计算机基础设施，能加快Web-app的功能测试。利用Grid，可以很方便地同时在多台机器上和异构环境中并行运行多个测试事例。其特点为：· 并行执行· 通过一个主机统一控制用例在不同环境、不同浏览器下运行。· 灵活添加变动测试机
selenium RC　　selenium RC 是selenium 家族的核心工具，selenium RC 支持多种不同的语言编写自动化测试脚本，通过selenium RC 的服务器作为代理服务器去访问应用从而达到测试的目的。　　selenium RC 使用分Client Libraries和selenium Server，Client Libraries库主要主要用于编写测试脚本，用来控制selenium Server的库。　　Selenium Server负责控制浏览器行为，总的来说，Selenium Server主要包括3个部分：Launcher、Http Proxy、Core。其中Selenium Core是被Selenium Server嵌入到浏览器页面中的。其实Selenium Core就是一堆JS函数的集合，就是通过这些JS函数，我们才可以实现用程序对浏览器进行操作。Launcher用于启动浏览器，把selnium Core加载到浏览器页面当中，并把浏览器的代理设置为Selenium Server 的Http Proxy。 selenium 2.0　　搞清了selenium 1.0 的家族关系，selenium 2.0 是把WebDriver 加入到了这个家族中；简单用公式表示为：　　selenium 2.0 = selenium 1.0 + WebDriver 　　需要强调的是，在selenium 2.0 中主推的是WebDriver ，WebDriver 是selenium RC 的替代品，因为 selenium 为了向下兼容性，所以selenium RC 并没有彻底抛弃，如果你使用selenium开发一个新自动化测试项目，强列推荐使用WebDriver 。那么selenium RC 与webdriver 主要有什么区别呢？　　selenium RC 在浏览器中运行JavaScript应用，使用浏览器内置的JavaScript 翻译器来翻译和执行selenese命令（selenese 是selenium命令集合）。　　WebDriver通过原生浏览器支持或者浏览器扩展直接控制浏览器。WebDriver针对各个浏览器而开发，取代了嵌入到被测Web应用中的JavaScript。与浏览器的紧密集成支持创建更高级的测试，避免了JavaScript安全模型导致的限制。除了来自浏览器厂商的支持，WebDriver还利用操作系统级的调用模拟用户输入。　　如果是新项目直接学习webdriver 就OK了，RC是过时技术。
selenium学习路线 　　配置你的测试环境，真对你所学习语言，来配置你相应的selenium 测试环境。selenium 好比定义的语义---“问好”，假如你使用的是中文，为了表术问好，你的写法是“你好”，假如你使用的是英语，你的写法是“hello”。 所以，同样有语义在不同的语言下会有不同的写法（语法）。 　　接着你需要熟悉webdriver API ，API就是selenium 所定义一方法，用于定位，操作页面上的各种元素。　　先学习元素的定位，selenium 提供了id、name、class name、 tag name、link text、partial link text、 xpath、css、等定位方法。xpath和css 功能强大语法稍微复杂，在这其间你可能还需要了解更多的前端知识。xml ,javascript 等。　　定位元素的目的是为了操作元素，接就要学习各种元素有操作，输入框，下拉框，按钮点击，文件上传、下载，分页，对话框，警告框...等等。　　经过一段时间的学习，你可以游刃有余的模拟手工测试来操作页面上的各种元素了。接着你需要做的就是把这些“用例”组织起来，统一来跑。　　那么你需要做的就是学习并使用单元测试框架，单元测试框架本身就解决了用例的组织与运行。　　当你写了一些“测试用例” 之后，你会发现用例中有大量重复的操作，能不能写到一个单独的文件中，需要的时候调用这些操作？当然可以，运用你的编程能力来实现这一点将非常简单。然后，你又发现每个用例中都有一些数据，这些数据也是一样的，但如果变化了修改起来非常麻烦，你也可以把他写到一个单独的文件中进行读取。　　接着你又遇到了新的疑问，我写的脚本（用例）都是流水式的，我怎么知道用例运行失败还是成功。那么就需要在脚本中加一些验证与断言。　　接着你又有了更多的想法，单元测试框架的log太简陋了，能不能生成一张漂亮的测试报告出来。我能不能定时的来跑这个脚本。能不能把每一次跑脚本的测试结果直接发到我的邮箱。能不能......　　为解决这些问题，你不得不学习更多的编程技术，然后你的“测试结构”会功能越来越强大，越来越灵活。产生了一定的通用性和移植性。一个有模有样的自动化测试框架诞生了。 　　假如，有一天你不再做UI的自动化测试了，你会发现你去做单元测试 或接口测试基本没什么难度。开发个测试工具之类的也不在话下，感谢selenium 吧！顺便也感谢一下我吧！
注册会员, 积分 131, 距离下一级还需 69 积分
论坛徽章:5
感谢分享，学习一下
注册会员, 积分 65, 距离下一级还需 135 积分
论坛徽章:3
谢谢楼主分享！
金牌会员, 积分 1514, 距离下一级还需 1486 积分
论坛徽章:7
注册会员, 积分 141, 距离下一级还需 59 积分
论坛徽章:3
感谢分享，谢谢楼主！
注册会员, 积分 100, 距离下一级还需 100 积分
论坛徽章:1
注册会员, 积分 99, 距离下一级还需 101 积分
论坛徽章:2
每次来论坛都能学习到很多知识。谢谢
新手上路, 积分 1, 距离下一级还需 49 积分
论坛徽章:0
写的很好。感谢分享！
注册会员, 积分 125, 距离下一级还需 75 积分
论坛徽章:5
总结的很好，收藏收藏!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
中级会员, 积分 264, 距离下一级还需 236 积分
论坛徽章:4
感谢楼主分享，& && && &}