CSDN技术网摘 -- wz.csdn.net - skinapi的网摘 http://wz.csdn.com/rss/skinapi/ CSDN网摘 (http://wz.csdn.net) zh-cn CSDN网摘 包罗技术精华 http://www.manageblog.net/bjwander/archive/2006/12/02/1995.html http://www.manageblog.net/bjwander/archive/2006/12/02/1995.html 软件测试人生,软件测试 Wed, 06 Dec 2006 14:08:25 GMT 今天，做开发的同事突然问我，做什么最好？做什么将来才会有前途呢？好多人都问过或者问着这个问题，而每个人都在一步步自己的路中探索和深入着，包括自己也是，什么才是好呢？ 看网上说有人做设计的不行去做了开发，做开发的不行去做了测试，做测试不行去做了SQA，做SQA不行就去做了SCM，到底是否是这样的呢？那么如果是，那应该看起来做设计才是最好的，但是做了设计的人就一定比一个SCM做的优秀吗，就一定比SCM拿的工资高吗？或许不是，因为大家都知道，这里面最重要的不是做什么才好，而是一种什么经验才能让你在未来不至于落后，甚至于领先。但术业有专攻，其实不在于做什么才好，而在于怎么才能做好，一门做好了，那么所掌握的技能远远超过相同的从事一样职业的其他人的时候，那么谁敢说你不优秀呢，当一个SCM的工资比一个Desigher高许多时，那谁又能说做SCM没有前途呢！所以，关键不在于做什么，而在于如何做好。 我做了四年的测试，让我学到了很多东西，包括一些简单程序开发也是那时学到的，所以在这里要感谢广联达公司提供的平台，更感谢杨耀庭经理带给我的机会，让我一个中专生选择了自己的职业。开始的时候，对于软件测试一无所知，慢慢的领会到软件测试是一门学问，再到软件测试工具的学习，再进一步领会到软件测试的技术只有环境架构的支持才能发挥更大作用。从技术方面，从不懂计算机代码，到一步一步培训编程，再到自己写出程序；从测试工具一无所知，到通用测试工具的了解熟悉，再到项目中实践的经验积累，回头看看，原来从那时到现在，自己努力的不错。很多人都说做软件测试不如编码，但我却拿到的工资比编码的要高，为什么？ 测试，不仅仅是技术，包含了大量管理的思想。如果说编码是一门技术，勿庸置疑，但测试却有着大量的理论做基础，通过实践找到最佳的方式，从软件产品上给予了客观的评价，分析带来的结果是否真正有效，是否真正适合项目，是否真正符合了计划，而代码人员，不过只是从其中获得了更深的技术，而少了项目管理的思想。所以，我选择了继续做测试，但这一天直到我转入所谓更下一级 SQA的时候截至。 对于个人来说，做SQA是一种转变，从技术真正转入到了项目管理。SQA并不是想象中的那么简单，它首先需要大量的知识做基础，需要实践和灵活的项目管理方法做指导，给项目经理提出有效意见，给项目组进行适当而有效的培训。也许大家都知道，项目中许多人都是喜欢听技术课程的，对于一些非技术都是做为敷衍或者认为没用，当培训的时候也变成了一种单向的介绍会。那么为什么出现这样的情况呢，首先，你做的东西要切实解决了问题，这些问题包括技术和管理，如果你对技术了解不够透彻，那么你一定要从网上或者别人那里虚心的透彻了解后再讲解，否则，人们只会认为你不过是纸上谈兵罢了。另外，你必须有良好的心态，承受各种尖锐的问题，并能解决或者给予答复，如果你没有答复，则结果也一定会是信任程度降低，而对项目指导或者协助产生一定的困难。 所以，做SQA需要的知识是众多的，如何做好一个项目、如何进行良好的设计、如何做好编码、怎么样进行单元测试、如何进行系统测试、又如何对项目适用不同文档的情况进行裁剪的指导……，若多的这些，恐怕不是那么容易的。 所以，做什么工作不是重要的，而做好这件工作，运筹帷幄于心才是最重要的。 skinapi http://atsea666.blogspot.com/2006/11/tricks-of-software-testing.html http://atsea666.blogspot.com/2006/11/tricks-of-software-testing.html 软件测试技术,软件测试 Thu, 30 Nov 2006 14:28:03 GMT 参加了一个小培训，关于测试的。基本的理论就不多说了，其中有几个比较好的观点，列举如下： (1)群集现象： 发现问题越多的地方，隐含的缺陷也越多，需要重点处理。 佩瑞多定理：（80-20定律）许多软件现象都遵循佩瑞多分布规律：80%的贡献来自于20%的贡献者。例如20%的模块含有80%的错误。 (2)用例： 一般考虑3个方面的， 合理的，不合理的和边界的。 (3)黑盒和白盒：黑盒测试无法知道从来没有走过的分支。 (4)圈复杂度： 建议圈复杂度限制在10以内。 (5)黑盒测试的典型方法： 正交矩阵法是减少测试用例的有效方法。等价类划分的缺点是没有考虑边界。 (6)GreyBox（灰盒）：用例设计依据程序结构（白盒），用例运行按功能测试（黑盒），一种十分有效的软件测试方法。 (7)Smoke Test: 在测试中发现问题，找到了一个Bug，然后开发人员会来修复这个Bug。这时想知道这次修复是否真的解决了程序的Bug，或者是否会对其它模块造成影响，就需要针对此问题进行专门测试，这个过程就被称为Smoke Test。 (8)测试完成的标准： 要求人们用图标出某个测试阶段中单位时间查处错误的数量。通过对此图的分析，可以确定应继续测试或是结束这一测试阶段而开始下一测试分阶段。 (9) 历史数据：无论是测试还是规模度量都很重要。经常记得记下历史数据，是一个很好的习惯。要记下来，不要凭感觉。(这是我说的） (10)测试的基本过程：Plans -〉Outlines -〉Test Case generation ->Execution -> software testing Reports ->Management (11)如何有效的报告问题是很有学问的。 skinapi http://www.cnitblog.com/qiuyangzh/archive/2006/11/27/19626.html http://www.cnitblog.com/qiuyangzh/archive/2006/11/27/19626.html loadrunner,性能测试,软件测试 Tue, 28 Nov 2006 13:11:59 GMT 我们在使用LR进行性能测试的时候，经常有需要监控OS的资源使用情况的需求。对于Windows系统，这个工作进行起来很方便，直接在LR的资源监控窗口中添加需要被监控的机器名或IP即可，但对于Linux/Unix系统，则要稍微复杂一些，我在这里简单介绍一下如何在LR中监控 Linux/Unix系统的资源使用情况： Linux 对于Linux系统，要想通过LR监控Linux/Unix系统的资源使用情况，需要运行rstatd服务。如果OS没有安装rstatd（可以查找一下系统中是否存在rpc.rstatd这个文件，如果没有，则说明系统没有安装rstatd），则需要进行安装。rstatd安装步骤如下： 获得rstatd的安装介质（rstatd.tar.gz）。rstatd可以从redhat的安装CD中获得，或者从网站上下载（给出一个下载地址，sourceforge的：http://heanet.dl.sourceforge.net/sourceforge/rstatd）。 将rstatd.tar.gz拷贝到Linux系统中，解压，赋予可执行权限，进入rpc.rstatd目录，依次执行如下命令： #./configure #make #make install 结束后，运行./rpc.rstatd命令，启动服务。这个时候，你就可以在LR中监控Linux资源了。 Unix 对于Unix系统，比如Solaris，AIX或者HP UX等，它们的配置过程比较简单——在inetd.conf（在/etc目录下）文件中去掉rstatd前面的注释，然后启动rstatd服务即可。 skinapi http://alexjustin.spaces.live.com/Blog/cns!2C266FEEDB9989E7!924.entry http://alexjustin.spaces.live.com/Blog/cns!2C266FEEDB9989E7!924.entry 软件测试人生,软件测试 Sat, 25 Nov 2006 15:00:28 GMT 一个MM在IT公司的真实经历 不小心闪入这个行业已经N年了，每次别人问起我的职业的时候，我都会觉得有些尴尬。年轻人我告诉他IT业，大年纪一点儿的就说电脑。 　　不过不管是哪些人，都是类似的回答“卖电脑的？”或者“做开发的？” 　　可惜我两者皆非，我又非常不愿意解释这件事。于是就变得很尴尬。 　　我具体做什么的？我是做测试的，还兼做一些和项目管理有关的工作。按说这两者好像有点八竿子打不倒，奈何国内的行业现状就是如此。我就混在一起做了吧。 　　其实另外一个不愿意说的原因是，大部分的程序员都很瞧不起测试工程师。每次我如果说：我是测试的。知道的呢，就会一个了然的“哦～～～～”，让我不爽起来。 　　于是我只能腹诽：X，开发有什么了不起，不过是我嫌累罢了。 　　又或者，不过是我的自卑情结在作祟吧！ 　　我踏入测试这个行业已经很多年了，很幸运的是国内第一支测试团队的一员。很幸运的受到了公司的大力栽培和重视。很幸运的参与过一只高效、合作、良好互动的大团队。并非常幸运的在工作初期就获得了职场的满足感。 　　不过，那个年代已经过去了。 　　是不是因为起点高，所以对现状格外不能满足？ 　　我前后跳槽的公司加起来应该是两位数了，但是一直没有找到让我全心全意的去投入的公司，全心全意的去完成的项目。 　　优秀的Leader，合作的团队，充沛的资金，原来这些都是我之前经历的前提条件。但，却绝对不是项目成功的关键。多年以后，我终于明白了一个道理，那就是：一个项目成功与否，不需要客户多么通情达理，不需要开发人员多么出色，不需要资金多么充沛，唯一需要的，是老板的运气。 　　我的职业生涯成长最快的，要属在M公司的日子了。从一个普通的测试工程师变成一个PM。简直是三级连跳。我在M公司，得到了我最丰富的经历。也终于看懂了一些做底层职员的时候怎么也想不到和想不破的道理。进入M公司是源于一次迫不得已的跳槽。 　　软件行业竞争激烈，所以倒闭的公司很多？？亲身体验了Y公司的倒闭之后，我终于晓得了，倒闭不常常是因为竞争激烈。 　　我进入Y公司还是花费了一些精力的，在面试我的未来经理面前表现出了我最好的一面。诚如带我出师的Leader形容我的一句话“你是潜力股，可是什么时候你才能把你的潜力发挥出来呢？” 　　我想那个时候我发挥出了我的潜力。 　　Y公司的环境是非常优秀的，所有一起工作的同事也都很优质。这种优质直接提现在Y公司倒闭之后我听闻的所有同事跳槽后最低工资是6k（同组的测试工程师），网管7k，开发8k，项目经理10k等等。 　　我很喜欢Y公司的环境，我想如果它不倒闭，我会一直呆下去。 　　和那些优质同事相处很愉快，虽然有句话说：测试和开发是天敌。但端看天敌们的态度。 　　Y公司的老总是个非常有魄力的香港人，受过很高学历的教育。在管理上面有相当强的理论基础，是非分得特别明确。（我想，这也是Y公司倒闭的一个原因吧） 　　记得有一次，我的Leader在向研发部追讨相关的资料未果之后，按照规定报项目延期并且消耗了项目成本。研发部某项目经理大怒，直接找到老总。我们可爱的老总了解了一下情况，直接对这位超级资深的项目经理说“门在那里” 　　从那件事之后，所有研发部的项目经理和开发人员都会按时提交他们应该提交的东西（不是源码和执行程序） 　　我们部门每次谈到这件事情，都会双眼放光，无比崇拜我们的老总。 　　这样一个刚直的老总，可爱的老总，最后栽在和北京某著名公司的项目上。那个公司接了政府一个2000万的项目，然后300万转包给我们。却只付了3成不到的钱，于是因为现金流产生问题。我们公司直接解散裁员。 　　我们老总以为，做事就会有钱拿，显然他太～～～不了解国内市场了，欠钱不还太～～～正常了。 　　于是公司倒闭了 　　被Y公司遣散了之后，我就开始找工作。这个Y公司还是非常讲究诚信的，还会给补偿金。虽然我在该公司前后呆了不足一年。现在很多公司连工资都经常迟发，倒闭了老板就闪人不见。做为可怜的员工，什么都拿不到。 　　于是在刚离开Y公司那个月，最开心，因为先休Y公司的年假，同时在另外一家公司上班，然后还拿了遣散金。相当于我拿了双薪还多。 　　也是在那之后没有多久，我加入了M公司，本来我面试的时候完全没有想到这个公司的。因为面试时间非常短，我又在赶场（赶下一场面试），草草讲了几句就告辞了。没想到M公司通知我报道。在其它公司还没有结果的时候。 　　到了M公司是我职场非常重要的转折，周总是个非常好的Leader，给了我很多机会。把我从一个普通的测试工程师提为组长，之后又提为项目经理。而那段时间，也是我充分的将我第一个优秀的团队经验付诸实践的过程。 　　我见证过优秀团队的诞生和协作，那个时候我是其中的一分子。而今，我想见证成功是可以复制的，此时我在做PM！ 　　测试团队是很好组建的，从平台的搭建到团队默契的培养，工作习惯的建立和流程规范化，只用了一个月的时间。我完全的复制了第一份工作带我的那位Leader的全部工作。也有在做的时候才发现没有考虑周全的事情，边做边成长。 　　刚开始做了一个团队组建的计划，交给周总，周总大大表扬了我，认为写的很详细，很好。但在执行时，我才发现，还漏了很多。 　　在我的团队里，男生女生各半。各有各的优势。现在想想，当时其实没有给予他们太多测试方面的指导。因为我后来把全部的精力都投入在流程的修正上面。 　　因为项目比较大，属于多团队合作模式，不仅仅有纯粹的软件开发和软件测试，还有产品的研发。多团队不同的生命周期协调，很难。多模式的多团队沟通协作让我变得非常忙。 　　但不管有多少个不同的模式，有一个确实莫名其妙的不变的事实。 　　就是男人永远瞧不起女人，做技术的永远瞧不起不是做技术的 　　我本身是个女人，不是做技术的，在工作中找他们协作就会变得比较难。出色的技术人员毕竟是少数，有即使看不起也应该藏在心里的礼貌的人也非常少。能奉行三人行必有我师的更是绝版。 　　于是我最常看到的就是一张不屑的脸，有的干脆说“跟你说有什么用，说了你也不懂” 　　于是我只好在心里问候他家长 　　废话，你不说我能懂麽？况且我是学计算机的，又不是学你的OOXX专业的，不懂不是太正常了。 　　有句话叫做，伸手不打笑脸人。于是我经常笑得很灿烂的问他们问题。再难听的话我都当作没有听见。我的目标是把事情做好。只要你肯好好做事，你怎么说我都无所谓了。 　　建立整个团队的沟通协作模式，花了我整整四个月。 　　在那段时间，我和周总进行了无数次的流程讨论，试验性实施；再讨论，再试验性实施；一个优秀的Leader真 　　的可以激发人的潜能。优秀的Leader、充沛的资金，终于又被我碰到了。如果没有周总的大力支持，我想模式 　　的建立不会那么顺利；如果没有周总的完全信任，我不会工作得那么累却又快乐无比。 　　每天一上班都精神抖擞，走在路上好像飞一样。打开电脑的第一件事就是看今天的工作计划，然后逐项实施。 　　不知不觉工作到7点，才下班走人。 　　在那段时间我学到了很多。比如各种开发模型的流程标准都是不同的。如何即保证时间，又保证质量。不管怎 　　么说，一个很重要的原则就是：沟通是非常非常重要的。 　　在建立模式的初期，有两种类型的TeamLeader。一种就是完全的彻底的配合，并且积极训练自己的组员。和他 　　合作，非常愉快。还有一种就是完全的彻底的不予配合，并且在发生矛盾的时候对人不对事。 　　A君是合作的典范，他积极的训练自己的组员，尝试各种业内流行的一些工作模式。并且有时会和我讨论关于 　　团队建设的事情。我很佩服他，他是一个不仅源码写的很漂亮。而且文档写的也非常好的超级难得TeamLeader 　　。最难得的是他竟然在组内4个人的时候，实现代码走查流程和工作备份？！而此时的工作任务非常重。不过 　　我看他也是乐在其中。应该和我一样，难得有机会大显身手。赶紧理论联系实际试试吧～～～ 　　B君就是不合作的典范了。他虽然做TeamLeader，却完全是小作坊工作模式。既不懂得工作任务的统筹分配， 　　也不去做设计。完全让组内人员放牛吃草。于是做出来的东西是千奇百怪。此时不得不彻底佩服程序员的不逻 　　辑的逻辑思维。最有趣的是每次和我发生矛盾的时候，在周总面前争论。周总总是支持我，于是他非常愤恨：为什么周总向着你？我暗笑，周总是向着道理，我错了他也会批评我的。虽然目前为止我好像还没有给他批评我的机会。 　　在那段时间里，思考最多的，应该就是为什么优秀的团队要那么做？ 　　因为我经历过优秀的团队，我知道那么做是对的，是好的。我只是习惯性那么做，并且那么认为。直到面对这个比较糟糕的整体团队的时候，为什么那么做？成为我最常思考的一个问题。 　　我要先找到依据，证据，来说服那些没有养成良好工作习惯的同事。纠正他们的工作习惯，提高整体的工作效率。降低管理成本。和整个项目的成本。而仅仅停留在“我知道那样是好的”显然是不够的，于是我开始大量查找一些文章、理论支持依据和一些经验。并且纠正我之前的一些观念。毕竟我曾经经历的项目情况比较单纯。和目前的有很大的差别，如果生搬硬套未必会有想要的结果。 　　再八卦一下，当时公司有个非常非常帅的帅哥，帅到连公司的大内总管老男人都不得不赞说“他不去当偶像明星，来做开发真是可惜了” 　　而我可惜的是他是开发人员，很少有工作的机会和他沟通。于是我每天午休的最大乐趣就是“调戏”这个小男生，看他脸红。 　　想起若干年前的高中同学，她每次牙痛都拽耳朵，我好奇问她：这个是治牙痛的偏方吗？她说：这个叫做疼痛转移法。 　　当生活中碰到没有办法避免的痛苦的时候，最好的办法就是找事情来做。转移开你的注意力，就不会那么痛了。 　　在这四个月中，发生了很多事情，有个很优秀的TeamLeader离职；我在组内培养了一个TeamLeader，我记得陈安之好像说过，你想升迁的话，就要培养一个可以替代你的人。当然，我培养他的时候，却完全没有想到，世事无常。上层的事情，是我永远也不可能想到和预测到的。那段时间，做得再多，我也不过还是一个底层的职员而已。 　　当项目快接近尾声却还没有结束的时候，资金的问题扑面而来。之前的充沛资金和项目奖金好像是假的一样。周总的信心满满忽然变成了沉默不语。他好像承受了很多我们都不知道的压力。然后在毫无预警的情况下，我们忽然被人并购了。突然变天了。具体的细枝末节我直到现在都还无从猜测。 　　只看到我们的大内总管老男人忽然笑眯眯的坐上了领导的位置。周总却消失了。而我则被迫坐上了PM的位置，因为没有人比我更清楚项目的总体情况。据大内总管说，这是周总临走之前交待的。 　　上层变天了，我们整个团队搬到一家大公司里面去了。据说我们以后就是那家大公司下属的子公司了。工作还是照常在继续。而PM这个角色，没有发布公告，只是大家心照不宣。因为大内总管基本上对技术一窍不通，管理上更是乱七八糟。我和周总辛苦了近半年建立的模式在接下来的压力下，撑了6个月。 　　项目还未完全成熟的时候，大公司的市场部已经气势汹汹的压过来了。此时原来我们的缺陷一个不漏的暴露出来了。我们感觉良好的产品根本禁不住市场的考验。量产的质量我们根本无法控制，软件的大量数据的低效率也导致了客户直接的不满意。 　　而再不满意，项目都要马上上马。到了那家大公司，我变得比以前更忙。简直是我最忙的时候了。内部的项目会议，召开要参加。大公司的大领导关切的会议，也要参加。这个时候内部矛盾开始出来了。 　　技术人员总是对自己的产品很自信。在样品没有问题的情况下，怎样也不承认我们在市场上出现的问题。而此时市场已经大规模铺开。我一边接投诉电话接到手软，一边给各地陪笑脸，一边还要看技术人员的别扭的冷脸。 　　各种问题象大海捞针一样难查，到底是设计问题？采购问题？生产问题？运输问题？还是环境问题？ 　　销售人员疲于奔命，我则四面楚歌。技术人员永远是技术人员，有的不成熟还要被派出差。要象照顾孩子一样远程照顾他。而销售人员又是满嘴跑火车，今天说客户要看，明天就要样品，后天又要一个新功能。研发人员加班加点的完成，销售人员又无声无息了。 　　而一边是内部矛盾的激化，一边是上层领导频频起摩擦。我屡次跟大内总管参加高层会议。因为多次拿出准确的产品记录让其它子公司的人无从辩驳而变成了别人的眼中钉肉中刺。销售总监的一天一个想法，生产部经理的混乱质量。都被我的各种数据、翔实记录血淋淋的揭露出来。而我所在的这个小公司，仅仅是负责这个大项目的技术而已。 　　组织架构很清楚，总公司负责销售，一个子公司负责生产，一个子公司负责新项目技术研发（我们所在的小公司），一个子公司负责在行项目的维护和研发。 　　而我还天真的，希望用数据，用事实扭正他们的做法，使我们的项目成功。 　　有句老话,叫做不吃一堑,不长一智.我陪着大内总管参加了有三分之一的会议,另外三分之二是他独自参加的,代表我们项目的技术组.我确实是太忙了. 　　大内总管的虽然管理上有点乱七八糟,技术上也不是很在行,但很多道理还是懂.至少他和我们这个团队的一个傻傻的信念一样.就是尽全力要把事情做好. 　　但是在参加了近一个月的无休止的纯粹的磨牙会议之后,他一脸疲倦的和我说,来了这里,我终于学会了一件事,打太极.不管什么事情,就推给别人就好了,永远不要妄想你可以解决. 　　那些我参加过的三分之一会议,基本上也是毫无效率,虽然我提供的大量翔实的数据和记录,但会议的主题,目标总是没有.却有近一半的会议有我们董事长全程参与. 　　开始我觉得很感动,我觉得公司很重视这个项目,参加了几次之后,我发现高层会议的定律.1.永远的没有主题; 2.永远的没有结论; 3.永远会出现忆苦思甜的场面. 　　公司的董事长和与会的高官们都是在公司打拼了过10年的兄弟,只有我们这个项目成了格格不入的插入者.尖锐又血腥的指出与会高官们的错误.最后每次会议的结果,都变成了,没有结果. 　　通常还会有一个定律,就是,董事长总是对我们的认真仔细赞赏有嘉,对其它人毫不留情的痛批.让我这个揭发者的角色都感觉尴尬. 　　不知道是董事长太急于引进我们的管理模式,还是太急于把我们整个团队做掉.这样的一面倒向着我们,让我非常的不安. 　　人家都说女人的第六感是很准的,在项目磕磕绊绊的上马之后,虽然各种问题层出不穷,但依照我们之前创建的模式和机制可以一件件处理之后.在一个艳阳天,我被一个莫名其妙小的理由指派出差了.而且是由最高层直接指派. 　　曾经有个最重要的出差机会,我本来很想去,也没有去成.我是最最合适的人选,在最后关头被大内总管拦下来.他说,这个项目缺你不行. 　　带着疑惑,我出差了,那样的小问题,本来远程电话就可以解决的.我不明白为什么要我出差解决.而且要我见客户,这本是我工作范畴之外的... 　　按照我和大内总管的约定,我每天都会打电话给他,一面布置任务和解决问题,一面汇报我出差的情况.在我出差的第4天,我从早到晚打了多个电话找大内总管,都被告知,开会去了. 　　我当时就想,坏了！ 　　回来之后,就立刻看到了人事变动,我们整个的项目组,被拆散到另外那个负责现行项目子公司的各对应负责人下面。 　　而我下面的人直接挂在另外那个子公司的测试部.其实已经很久很久了,我都没有再负责测试工作的具体安排,进度等等.都由我培养的那个男生来做. 　　负责通知这件事的是大内总管,一看就是强颜欢笑.他,被留下了,做这个子公司新项目的研发.留了一个空壳子,底下一个兵都没有,这样的事情,实在太明显了. 　　我和总公司的销售总监还算颇熟,这位S君是典型的个人英雄主义(也许销售本就不需要什么团队?),他每年自己拿下的单光提成就可以几百万.手下的销售人员基本上是放牛吃草.而每次我开会讲的有问题的销售人员,通常都是他手下.他根本也不管,而且不知道是他太会伪装还是本来就对我颇有好感,所以莫名其妙我俩就很熟. 　　我回来之后,S君透漏了很多事情给我听,我想那个时候我的表情一定很精彩,看暗战都没有觉得那么刺激过. 　　那段频频开会之后,因为董事长的态度,其它资深元老颇觉得受威胁,于是联合了另外子公司的技术总监(就是负责现行项目维护的子公司),进行了一场叛变. 这些人,都是资深的,和董事长一起打天下的人.当年,多苦多累都一同挨过.面对如今董事长一面倒的偏向新人,新进公司不足半年的人,觉得倍受威胁.于是开始反击. 　　之间也找过这位S君,他没理,因为对他来说,哪边的技术都是一样的,按照他的话讲,再烂的东西我都可以卖.谁做的有什么关系? 　　于是这些元老们,包括了另外一家子公司的技术总监,工厂经理,几个大区的销售负责人,还有一个行政总监,一起找董事长谈判.拿了技术总监的核心资料做要挟,约谈定在一个颇知名的附近的咖啡厅. 　　场面看起来还有些宏大,加起来快10个人围了一桌.董事长在接到电话时已有预感,于是硬是靠自己的关系联系了一支队伍(不知是武警?公安?部队?还是什么),他去了之后,那只队伍随后就包围了咖啡厅. 　　具体内容不得而知,叛变队伍最后妥协,但董事长也付出了一些代价,结果就是,要进行一个名为"斩首"的行动. 　　把我们这个子公司的所有技术人员,挪到那个技术总监的旗下.而这支队伍的首领,架空.结果就是大内总管被留下做了一个XXXX总经理的空职,我被调到和技术完全不搭的部门做所谓的部门经理,只带了一个秘书过来.剩下团队的所有人,都被调到测试部下. 　　在接到调动通知时,我还是和大内总管做了一番谈话,因为我培养的人,没有正名,我不甘心他被调过去直接做别人的手下,底下那么多人的任务分配,新的经理做得来吗?于是在我和大内总管跟上面的多次沟通后,他以项目组的测试组长身份,调了过去. 　　而我们的技术秘书,却没有那么好运气,这个秘书,是我亲自招来的,工作相当的出色,如果我对她工作期望是1,她就会做到3.我本来想她调到测试部好些,但不行,最后只好跟我去了那个没什么事情做,名头听起来很大的部门. 　　于是我和她,都变得好闲 　　于是我想办法分了更多的事情给她做,我不想她看起来空闲.我知道她这个职位找工作有多难. 　　这样,过了一个月快两个月的茫然期.我每天都浑浑噩噩的.项目的事情我不再插手.新的子公司自然有他自己的规矩和模式.虽然混乱一堆,但那些元老级负责人也都不是省油的灯. 　　而且那段时间我学习到了一个道理,那就是,当你对问题视而不见的时候,他就不再是个问题. 　　这段时间,我们原来的团队走了大半,都是受不了这种和国企一样的工作方式.高科技企业的新人们,大概很难想像国企的风格吧.我也是经历了之后,才晓得. 而我带起来的团队,也走了大半.他们都认为,我不再是他们的Leader了,团队已经没有了核心了.我觉得很对不起他们. 　　带团队的时候,我给了他们多大的期望,他们现在对我的失望就有多大.有一段时间,我不敢去找他们,问问他们的近况.我怕那一双双眼睛。 　　当我觉得很迷茫的时候,公司直接给我解决了我的困惑.以一个非常莫名其妙的理由,解雇了我. 　　我本来还习惯性的争论了一下,不过来了几个家长人物一样的关切我一下之后,我就觉得,我的做法,在这个公司,实在太可笑了.在这个公司,只讲资历的,只讲人际关系的. 　　于是,他们开的条件,我豪无异议,全部接受了.于是我离开了这家公司。 　　好了,故事讲完了,^_^ 　　我的职业生涯还在继续...经验,都是经历过之后,才有的.当你还在漩涡里的时候,是很难看出什么的 skinapi http://bbs.51testing.com/viewthread.php?tid=49629 http://bbs.51testing.com/viewthread.php?tid=49629 测试经验体会,软件测试 Sat, 25 Nov 2006 14:39:01 GMT 近日，看了陈雷的文章《进销存系统的报表测试http://www.51testing.com/html/6/1871.html ，自己也在这方面接触了两年的时间，颇有同感，他的经验总结得非常到位，在此，希望能作点补充，或者是以另一种角度来讨论！ 报表的重要性，大家都知道它有举足轻重的地位，特别是成本/利润类报表、月报、年报等，这里就废话少说了！所以，它对测试条件的要求、测试覆盖率的要求、测试深度的要求都非常高，而且不是一般的测试员和新手随便就能测试的，一定是对业务和相关的法规非常熟悉，最好能有实践经验的、较强分析能力、综合能力高的测试员来做！ 总结了报表在测试时需要关注的十大特性： 一、 正确性 报表的最低要求和基本特征就是它的正确性！  1.报表格式的正确 不同的报表有不同的格式，有些是行业内默认的，有些是明文规定的，还有自定义的，按照不同条件还可以分各种各样的，如：按照货品的仓库进出情况，分入库类报表、出库类报表和仓库类报表等；按照报表的类型，分图表，固定行列报表，分栏报表、交叉报表等等！因此，报表的格式不是随便增减的，一般包括表头、表体、表尾、以及附注等，测试时需要具体问题具体分析，根据需求提供的标准格式模板！  2.报表内容的正确 这是测试的重中之重，包括数据的算法、数据的来源、数据的对应关系、小数位问题、四舍五入问题、单位换算问题、税率换算问题、明细与合计是否一致、单据的类型/状态改变后对报表的影响等！ 二、 时段性 这个很容易了解，没有那张报表在时空上的统计是漫无边际的，就算是“所有”或者“全部”，都是有它的时效！特别是财务类报表，有月报、季报、年报、甚至还有现金日记帐等，都表现出时段在报表中的必要。 三、 条件性 每个报表都是针对特定的条件而作出的输出，要想达到目的，是需要一定条件的。如：统计XX供应商XX业务员在XX时期采购XX商品的情况，在查询时就至少需要四个条件了！ 在测试查询条件时，通常采用正交的方法来增加它的测试覆盖率，但是要注意的是，测试数据的选取非常重要，我们都尽量模拟真实的、有代表性的、经过精心设计的数据！ 四、 可比性 这在报表的分析和成效的判定上，显得尤其重要，通常报表的测试，不仅只是对单张报表的测试，还需要多张同时进行比较，多张可以是指同一时期不同类型的报表、不同时期同一类型的报表、不同类型与不同类型的报表（但它们之间必然存在某种关系的）；还有什么同比的、类比的等！ 目的是找出它们之间的联系和区别，然后获得更深层次的某种规律或者业务流程的脉络。简单来说，就是从实践上升到理论！ 举个简单的例子：我们都知道财务报表的会计原则是“有借必有贷，借贷必相等”，因此，每个财务类报表都有借、贷两方；然而从销售收入报表、销售支出报表和销售利润表，显然得出：销售收入-销售支出=销售利润，这一条无人不晓的规律！ 五、 穿透性 这个也很容易理解，大多数的报表都不是孤立的，例如：从汇总表可以穿透到明细表，从明细表又可以穿透到单据，从单据甚至可以穿透到具体的产品；虽然它们的层次深度可能不一样，但它们与某某之间有着奇妙的联系！ 在测试中，一定要理清它们之间的层次、顺序，这就需要对业务的理解和知识的积累！ 六、 隐蔽性 这里不是指报表的数据或者结果隐蔽，而是指所统计的数据来源的隐蔽。例如：入库类的，除了正规的采购入库，还会有估价入库、退货入库、盘盈入库、报溢入库、拆卸入库（将组装产品或者已经打包的产品，拆卸后将元素产品重新入库）等；出库类的，除了常见的销售出库，还会有采购退货、盘亏出库、报损出库、生产领用、组装领用等。请注意的是，有些进销存系统还分有帐面库存数和实际库存数两种的！ 另一个陷阱：有些进销存系统的应收帐款是由正常的应收帐款加上预付转应收的部分组成的；同理，应付帐款是由正常的应付帐款加上预收转应付的部分组成！ 七、 时序性 上面说了时段性，现在到说说时序性，顾名思义，就是指业务发生的时间顺序。在明细报表中，每项明细都应该有记录业务发生的时间，它的先后顺序很重要。 举个简单的例子：某仓库库存量为100，三月份销售出库50，四月份采购入库也是50，如果将四月份的采购入库计入三月份的，虽然年仓库库存量还是100，没有变，但是对于月度库存量和季度库存量就影响大了！ 八、 安全性  1.这个主要体现在报表的权限控制上。因为报表是针对不同的用户设计的，特别是敏感的数据，如个人资料、产品成本、商业信息等，这就需要加强访问权限的控制，有的是只读的，不能过滤条件或者修改其他的查询条件；有的根据用户等级来分配权限等！  2. 通过用户角色和密码来控制：业务员只能看到自己的业绩报表  3.通过用户角色的等级来控制：非财务主管不能打开销售收入利润表等 九、 直观性 报表的数据、结果清晰明了，页面简洁、排版合理，不能给用户产生模糊或者引起奇异的感觉；一般合计的部分或者关键字段都需要突出显示；有的报表需要图文并茂，选择最佳的报表类型。 十、 打印 仅仅测试通过查询得到的报表，是不足够的；通过屏幕看到报表的效果，也是不能全信的，需要持有怀疑的态度，把报表打印出来，重新检查是否适合所需的效果！ 包括：打印模板的设计、套打样式、自定义模板、打印调试、打印时间等方面。 skinapi http://flyingwind-prometheus.spaces.live.com/Blog/cns!98DB77008F2FBC3A!152.entry?owner=1 http://flyingwind-prometheus.spaces.live.com/Blog/cns!98DB77008F2FBC3A!152.entry?owner=1 软件测试杂感,软件测试 Mon, 20 Nov 2006 13:42:25 GMT 测试之道 ——对于IT企业而言，bug和用户必须是躲猫猫的关系 作者：flyingwind（华府长工58264） 邮箱：flyingwind0127@hotmail.com ========================== 刚才居然在我最尊崇的网站www.51testing.com的首页看到了《测试之道》的前四篇，真是受宠若惊。 然而还是有一点需要声明：“对于IT企业而言，bug和用户必须是躲猫猫的关系”这句话是本文的中心。转载的时候删减其他都可以，但这句话务请保留。 ========================== 5、清静为天下正 《道德经》：大成若缺，其用不弊；大盈若冲，其用不穷。大直若屈，大巧若拙，大辩若讷。躁胜寒，静胜热，清静为天下正。 想必业界的同仁都会有这样的困惑：为什么我们费心尽力测试了很久的产品，在认为没有问题以后发货给用户，还是总会被用户（甚至是一些几乎连最简单的计算机操作都不会的用户）发现bug呢？换言之，为什么严重的漏测总难避免呢？ 对漏测的缺陷进行追溯，通常都会发现：漏测的总是一些特殊情况。例如输入字符串的时候没有考虑特殊字符；输入数字的时候没有考虑0或者负数；除法计算的时候没有考虑除数可能为0；修改用户的密码的时候没有尝试system或者administrator是否也能被修改；统计文件大小的时候用Byte做单位，没有考虑文件过大的时候（4G以上），超过32位2进制数的大小，可能导致溢出……。 诸如上述问题，仔细归纳一下不难发现，其实都是等价类划分不完整或者没有去边界值进行测试。“大直若屈，大巧若拙，大辩若讷。”其实根本不需要什么特别繁杂的用例，只要按部就班划分好等价类，取上点、内点、离点分别测试有效性，再取外点测试无效输入足矣，如此“以无厚入有间，恢恢乎其于游刃必有余地矣！” 清静为天下正，虽不能确保一定没有漏测，但至少做到让bug和用户躲猫猫并非不可能。 用例如剑，无剑不成侠。故不嫌赘述，以下文举例： skinapi http://blog.joycode.com/oldsidney/articles/86763.aspx http://blog.joycode.com/oldsidney/articles/86763.aspx QC,自动化测试,BusinessProcessTesting,软件测试 Sat, 18 Nov 2006 14:40:49 GMT Mercury 在 Quality Center 8.0 時就推出 Business Process Testing，到現在已經進步到 9.0 的版本了。會什麼 Mercury 發展出 Business Process Testing 呢？Business Process Testing 的好處在哪？要如何使用Business Process Testing？我將在以下的文章為大家做個介紹。 skinapi http://bbs.51testing.com/viewthread.php?tid=48985 http://bbs.51testing.com/viewthread.php?tid=48985 测试职业发展,软件测试 Sat, 18 Nov 2006 13:33:26 GMT 从去年6月底开始正式做软件测试以来，我个人经过了很多阶段。从一开始的网站功能测试，到后来开始接触ERP，做了LR性能测试，然后开始做WR的自动化，到这时候大概半年时间去掉了。之后做了2个月的C#开发，在自动化测试方面用QTP开始逐渐替代了WR。然后我调到了市区“前线”工作。开始着手做NUNIT单元测试和基于.NET开发环境下的LR压力测试代码编写及面向Oracle存储过程的性能测试。06年7月，我开始担任测试管理的角色，开始从事培训新人，安排测试任务，与开发协调测试任务方面的工作，直到今天。我写这篇总结的原因，是由于自己对测试工作的职业发展开始感到迷茫，对技术发展没有方向。 我个人认为，我上班16个月以来所走过的路，是比较合理的。这样的路建立的经过测试专业培训的基础上（个人感觉，新人接受专业培训是很有必要的），否则可能先需要在基础方面努力3个月左右。基于对测试的正确理解以及对各种测试工具的了解，在正式工作中可以快速的应用上去。 下面说下我认为“菜鸟”应有的发展路程。 测试新人应该从系统手工测试开始，首先应该对整个软件的开发流程（软件工程）有正确的认识，了解测试工作在整个开发流程中的切入点和所起的作用。就项目而言，测试是其中的一部分，想要做好系统测试，首先应该学会怎么看SRS（需求规格说明书），对需求的正确理解将直接影响你的用例设计。其次，是用例设计的方法，这包括很多种，我就不多说了。主要的一点是，看SRS所设计的用例可能不全面，在实际测试过程中，应该从系统的操作中继续发现应该测试的点。另外，对于测试用例和BUG的编写，应该规范，清晰。出色的完成你的初测。其次，当开发修改完BUG之后开始复查时，首先你需要明白一个名词，它就是：版本。然后你开始复查BUG，如果时间允许，我强烈建议你重新执行所有用例，以防万一。 当你的系统测试做的“炉火纯青”的时候，你应该开始了解配置管理，质量保证，CMM以及一些开发上的相关知识。这可以巩固你对整个项目流程各个环节的了解，让你对他们有全面正确的认识。我认为这一点，很重要！ 之后，公司的测试水平开始升华，你的经理发现，总是复查BUG是一件多么耗费时间和人力的事情啊！他开始要求做自动化测试。这时候你就应该加入其中。对于自动化测试怎么做法我就不仔细说了，东西太多，我自己目前可能处于中级应用阶段，大家可以去51testing上看相关帖子了解一下。需要说明的是，自动化虽然好，但是不可能替代手工测试。另外，它不适用于一些小项目，对于小项目来说，上自动化所带来的项目成本，将远大于手工测试。 在自动化测试过程中，你可能需要自己去写一些脚本。这就需要对编程有一定了解。在这里我想说，会编程不是测试人员必须会的技能，但是，不懂编程将不会成为一个高级测试人员，它会成为你发展的一个绊脚石。我在做程序员的2个月中，学到了很多，它会影响你对系统的认识，拓展你的测试思路，增强你对数据库的了解。在这个阶段中，我建议你有空时学习相关网络拓扑，系统架构，数据库的知识，为将来打下基础。 做到这样我可以说，这个人已经是测试方面的中高级人才了。当然，如果你想做技术全能选手，那就开始接触性能测试和白盒吧。我认为这两个是高阶的玩意。 在性能测试领域，我是只会用LR，关于怎么学我不想说，自己找资料。需要说明的是，性能测试有两个难点。第一，是对面向被测系统的认识，如何确认到底需要监控测试哪些性能点的问题。第二，是对于测试出来的结果，能否正确分析找出瓶颈的问题。这两面都需要大量的工作经验，以及对系统，网络等各方面的深刻认识。这是一个具有挑战性的工作。 在白盒测试方面，首先你要懂编程，要写过程序，其次，你要会使用相关工具实现测试过程。基于代码级的测试和系统测试在理念上是差不多的，你也需要对被测的方法或者基类设计测试用例，然后用测试代码去实现它。这是一个自己构造输入参数，执行代码并获取结果的过程，有兴趣学习的自己找资料看去吧！在每日构建方面我没有做过，所以也不好多说什么，别误导了大家，我只能说，每日构建是每天对配置库中的代码进行自动的单元测试，确保每天配置库中得下得代码是编译可通过的一个过程。 当你在技术上有了一定造诣，你得到了领导的赏识，可能你会步入测试管理的行列。强力的技术背景将成为你做领导的支柱，但不是全部。我想说的是，做测试管理和做技术完全不是一回事，管理基本关注两点，一是成本，二是进度。在确定这两点是可控的情况下，可以说你的管理工作是合格的。你的技术背景为你提供了如下的好处：第一，手下人对你的信服；第二，有利于和开发方沟通；第三，协助解决技术难题；第四，强力的自信。这一切都为实现控制成本和进度提供保障。这方面我就不多说了，我自己做这个时间也不长，大家自己摸索一下吧。 做任何事情都是没有止境的，不论是系统测试，自动化测试，性能测试，单元测试还是测试管理（当然还有做配置管理和质量控制的），都有需要继续学习的东西。目前国内没有超级牛的人带领大家在技术和发展方向上奔走，大家可能都是在爬行。当你在某个领域做到一定程度的时候，你会发现走到了瓶颈点，无法继续提高。这个是无法避免的问题，我给大家一个偏激但可行的方法，那就是跳槽。新的环境会带给你新的思路和活力。测试需要学习的东西太多太多，以上说的都是纯软件方面，我自己现在仍然不熟悉JAVA方面以及类似UNIX之类的操作系统，如果你做的是通信或其他方面的测试工作，你还需要掌握这方面的知识，实在是有的学，我相信经过3年的磨练，应该可以成为一个较为成熟的测试工程师。另外，前面提到了做CMO和SQA的方向，这个和做纯测试工作是不同的发展方向， CMO的工作我太熟悉，不过SQA实在又是一个博大而又精深的领域，据我所知，国内这方面的牛人很少，精英QA可以和PM相媲美，他对项目成功的贡献是巨大的，好像大多这类人是做了PM或系统分析员多年的人转做的。在这方面就不深入探讨了。 补充一点，公司的流程不可能像你学到的那样完美和规范，不要奢求，尽量去改善它才是你要做的。另外我想说下待遇问题，我建议新手不要太计较这个，也许你在 51testing培训花了10K（不清楚现在具体价格，只是假设），你觉得自己从那培训出来已经是个牛人了，你要马上把你的投资赚回来。其实这么做实在是想法有问题，首先，你即使培训了，其实你仍旧是菜鸟，其次，中国人太多，人力资源不值钱，除非你是高级人才。新人在第一年不应该计较工资，而应该关注对方单位将会带给你的工作环境和发展潜力。讲工资的时候，应该在2－3年以后，需要强调的是，英文实在重要，我确实的体会，只是我太懒，一直不肯好好学，大家千万别学我啊！ 以上是我个人的一些观点，大家随便看看吧，说错了我可不负责啊 ^_^ 另外，我目前对于个人职业发展也比较迷茫，哪个牛人看了对我有所建议，请不吝赐教。。。。 胡 睿 2006年11月18日星期六 P.S. 我做过的一些项目： 1．ESCALADE ERP系统自动化测试 项目描述： Escalade 是一套面向电子商务/销售型企业的 ERP 软件，已在多家公司成功实施。 Escalade采用业界通用的业务流程，业务功能灵活而且完善，包括客户管理、销售订单管理、采购订单管理、配送管理、库存管理、销售分类账管理、采购分类账管理、系统管理等各个子模块，能适应大多数电子商务/销售型企业的业务需要。 责任描述： 利用QTP录制，增强脚本，进行回归测试。 2.上海市质量监督局网站测试 项目描述：上海市质量监督局网站测试是采用MVC开发模式。所以设计该体系平台就是为了能够对开发工作做出明确的定义。服务器端软件使用HPUX、Weblogic7、Oracle9i。 责任描述：网站功能测试，利用QTP制作自动化测试脚本，进行后期回归测试。 3.MyCmm 系统开发 项目描述：MyCmm系统是我公司自主研发的一个专门用于测试管理的软件，它综合了配置管理（绑定了VSS）和QA管理。它是基于webservice架构的C/S系统，数据库使用SQL SERVER，由 C# 开发而成。 责任描述：建立表空间，增加字段，添加窗体，新增或修改功能等。 4. ESCALADE ERP白盒测试 项目描述：Escalade 是一套面向电子商务/销售型企业的 ERP 软件，已在多家公司成功实施。 Escalade采用业界通用的业务流程，业务功能灵活而且完善，包括客户管理、销售订单管理、采购订单管理、配送管理、库存管理、销售分类账管理、采购分类账管理、系统管理等各个子模块，能适应大多数电子商务/销售型企业的业务需要。 责任描述：利用NUNIT对底层代码进行白盒测试，主要针对比较重要的业务基类 5.POS支付核销系统功能及性能测试 项目描述：该系统是和银联合作的一套可以利用银联卡和IC卡支付的系统，由终端操作上传至银联和公司内部服务器，以便于核查帐目所用。 责任描述：功能测试，LR性能分析及测试计划，执行，结果分析。 说明一下，发这个帖子有两个目的。 第一，尽我的能力帮助新人快递成长。 第二，找牛人给我些建议，指条明路。 以上内容可能有些说的不对，还望大家海涵。。。。 skinapi http://bbs.51testing.com/viewthread.php?tid=48865 http://bbs.51testing.com/viewthread.php?tid=48865 测试职业发展,软件测试 Thu, 16 Nov 2006 14:09:19 GMT 在哪里能找到自己想要的软件测试职位，这段时间许多朋友加我QQ和MSN问我，以下是我总结的，希望能给大家带来一点小帮助^_^ 校园招聘。中国互联网这几年迅猛发展，一些在华的大型公司，如国外的微软, IBM ,HP等；还有国内的华为，中兴，腾讯等大型公司对人才的需求也是不断地增长，不断加大对毕业生招聘培养的投入力度，储备人才，引发的人才抢夺战大家有目共睹，软件测试这个近几年才火开的行业当然也不例外，如果你能成功通过校园招聘，很不错，不错的待遇，而且能得到相应的培训，对于一个走上社会的大学毕业生来说，很不错的！ 使用网络”工作搜索引擎”。利用几个工作搜索引擎进行快速可以方便查找一些空缺的软件测试职位，如”职友集--搜索工作 互动职业”，网站是http://www.jobui.com， 其中可以搜索到很多软件测试职位，再介绍一个给大家吧，我可没一点私心保留的，“职通车”http://so.01hr.com，也是非常不错的，而且这个网站还有个加msn机器人似的列出职位的，方便，一个字赞！ 查阅报纸和杂志。大多数大城市的报纸每周招聘版中或者计算机招聘报刊中列出一些软件测试工作。还有一些计算机和编程杂志也是找到好工作最佳途径之一，如《CSDN人才周刊》，《电脑报》，《程序员》等,现在还发展到有一些免费的电子报纸和杂志上都有一些软件测试职位，真可谓是五花八门呀！ 电话咨询。如果你够机警，头脑灵活，对软件测试很有领域很感兴趣，找到一些相关公司的网站和联系方式，电话联系并寄出个人简历,那里一般有未放在招聘广告的空缺软件测试职位，我相信机智的测试员能够在别人明白过来之前捕捉到这些机会，相信机遇会永远善待那些有准备的人！ 暑假和寒假实习寻找机会。如果在大学就读期间，能在一家软件公司做兼职测试工作，也就获得经验，对公司做出的一点贡献，如果工作很努力，还是很容易能拿到一份全职的软件测试工作。 从事临时(兼职)工作。虽然这份工作只有几个月，也许还不到一个月，但是从中可以获得有价值的经验，每次工作都会碰到一些新的问题，测试员喜欢这种工作方式，可以在同这个公司的测试人员增加交流，相信你一定能取得意想不到的收获！ “敢做吃螃蟹第一人”。大胆尝试，亲身体验，目标定位几家心意的公司，然后对XX公司的产品，整理一份测试计划，设计测试用例，寻找软件缺陷-使用电子表格记下发现的软件缺陷，然后通过邮件方式，寄送出去，让其公司的负责人看到你的能力，获得意外的工作机会！ 通过正规的培训。获得软件测试职位，目前国内我这个人认为做的比较好的有 上海51testing软件测试网：www.51testing.com 和 中国软件测试基地：www.cntesting.com，两家培训机构都提供学员推荐，以给众多进入软件测试行业的人，通过软件测试培训找到了自己的职位，一个字做的好！ 通过招聘网站。网上求职越来越流行，对于做IT行业的来讲，以成为求职的主要途径,我推荐以下几个招聘网站： 中国人才热线：www.cjol.com 前程无忧：www.51job.com 中华英才网: www.chinahr.com 智联招聘网：www.zhaopin.com/ 希望大家能多多利用以上的招聘网站，广撒网，多收获：） 通过朋友介绍。一些大型软件公司，如华为，中兴，腾讯等知名公司，内部都相应有一些内部推荐机制，推荐成功一个员工，推荐人能获得一些奖金，有的公司内部把这种奖称为”伯乐奖”，相比之下如果你有幸去那个公司工作，也就是传说中的”千里马”，可是人才耶！和其它找到软件测试工作就职相比，通过朋友介绍机率会更大点！ 通过人才市场或职业介绍所寻找工作。一定要找正规的人才市场和职业介绍中心，通常情况下人才大市场每周从周一到周六开放，如果是找工作黄金时间，如人们通常说的“金3银10”招聘会从每周的周一到周日都会开放，而且还有免费的专职招聘会，如面向计算机类，通讯类，人事类，企业工厂的，这下可以剩下一笔小的费用的，节俭中国的传统美德！ 原文出自我的blog：http://www.cnblogs.com/mayingbao/archive/2006/11/16/562950.html 分享给大家，希望对大家能有一点点小帮助！ skinapi http://www.cnblogs.com/jackei/archive/2006/11/16/561846.html http://www.cnblogs.com/jackei/archive/2006/11/16/561846.html 性能测试,软件测试 Thu, 16 Nov 2006 07:22:46 GMT 这个帖子的内容比较典型，大家有兴趣可以也思考一下。 先是楼主提出问题： 最近公司一个项目,是个门户网站,需要做性能测试,根据项目特点定出了主要测试项和测试方案 一种是测试几个常用页面能接受的最大并发数(用户名参数化,设置集合点策略) 一种是测试服务器长时间压力下,用户能否正常操作(用户名参数化,迭代运行脚本) 还有一种则需要测试服务器能否接受10万用户同时在线操作,但使用的Loadrunner的license只能支持1万用户,请问这时该如何制定该方案? 后面跟着大家的回复： 网友 xingcyx 的回复： 1、找10台电脑也没用，license仍然只支持10000个。 2、找HP支持。当然，前提是你有足够的钱。 3、测到10000用户并发。我认为，通常情况下10000用户并发，支持100000用户在线，没有问题的。 网友 jackloo 的回复： 总的来说这一类的性能指标对大多数软件来说没什么实际意义，更多的是对硬件的要求。 如果是用IIS做应用服务器的话，单台可承受的最大并发数不可能达到10万级，那就必须要使用集群，通过多台机器做负载均衡来实现； 如果是用websphere之类的应用服务器的话，单台可承受的最大并发数可以达到10万级，但为性能考虑还是必须要使用集群，通过多台机器做负载均衡来实现； 那么，你只要集群的服务器足够多，10万并发数当然可以达到了。 通常有1个简单的计算方式，1个连接产生1个session，每个session在服务器上有个内存空间大小的设置，在NT上是3M，那么10万并发就需要300G内存，当然实际使用中考虑其他程序也占用内存，所以准备的内存数量要求比这个还要多一些。 还有10万个用户同时在线，跟10万个并发数是完全不同的2个概念。这个楼上已经说了。但如何做这个转换将10万个同时在线用户转换成多少个并发数呢？ 这就必须要有大量的历史日志信息来支撑了。系统日志需要有同时在线用户数量的日志信息，还需要有用户操作次数的日志信息，这2个数据的比例就是你同时在线用户转换到并发数的比例。 另外根据经验统计，对于1个JAVA开发的WEB系统（别的我没统计过，给不出数据），一般1台双CPU、2G内存的服务器上可支持的最大并发数不超过 500个（这个状态下大部分操作都是超时报错而且服务器很容易宕机，其实没什么实际意义），可正常使用（单步非大数据量操作等待时间不超过20秒）的最大并发数不超过300个。 假设你的10万同时在线用户转换的并发数是9000个，那么你最少需要这样的机器18台，建议不少于30台。 当然，你要是买个大型服务器，里面装有200个CPU、256G的内存，千兆光纤带宽，就算是10万个并发用户，那速度，也绝对是嗖嗖的。 楼主的回复： 谢谢jackloo ! 再请问如果我想测试10000个用户同时在线做常用操作的话(每两秒加一个用户,一直加到10000),对服务器的要求有多高? 网友 jackloo 的回复： 套用1句经典台词“高，实在是高” 呵呵。另外暴寒1下，你的设置光全部进入运行状态就需要接近6个小时。 具体的你可以拿1个系统来压一下看看，可能会出现以下情况： 1。服务器宕机； 2。客户端宕机； 3。从某个时间开始服务器拒绝请求，客户端上显示的全是错误； 4。勉强测试完成，但网络堵塞或测试结果显示时间非常长。假设客户端和服务器之间百兆带宽，百兆/10000=10K，那每个用户只能得到10K，这个速度接近1个64K的MODEM上网的速度； 另外以上分析全都没考虑系统的后台，比如数据库、中间件等。 我从没遇到你说的这样的性能需求过，也只好凭感觉随便掰掰： 1。服务器方面：上面说的那样的PC SERVER需要50台； 2。网络方面：按每个用户50K，那至少5根百兆带宽独享，估计仅仅网络延迟就大概是秒一级的； 3。如果有数据库，至少是ORACLE，最好是SYSBASE，SQL SERVER是肯定顶不住的。数据库服务器至少需要10台4CPU、16G内存的机器； 4。如果有CORBA，那至少再准备10台4CPU、16G内存的机器； 再加上负载均衡、防火墙、路由器和各种软件等，总之没个1000万的资金投入，肯定搞不定。 网友 mybasswood 的回复： 如果是10万用户的话要看做些什么哈. 比如对于voip来说,假设有10万用户的话,服务器规定每个client至少要在3600秒内到服务器成功报到一次,否则就被服务器cancel掉. client是每隔60秒注册一次. 所以就要推算在3600秒内,每一个client至少成功报到一次是最少的标准.要10万用户在3600秒内被服务器吃掉才可以---这是最低要求. 最高要求是: 在60秒内所有的10万用户去注册,如果服务器在60秒可以都吃掉的话,每秒种的平均并发差不多是3334. 最低要求是:在3600秒内所有的10用户去注册,如果服务器在3600秒内都可以吃掉的话,每秒钟的平均并发用户差不多是60个.还有一过问题是客户端要在3600秒内发送至少60次,至少有一次成功.再加上这些用户分布在全球各地的话,这样数值应该还会有变化的. 下面是偶的看法： 给楼主一个建议吧。 你在公司中的测试环境是一定的，你需要做得是现在这个环境中确认一下系统在当前环境下的实际处理能力。如果还有资源，再做一下可伸缩性的测试。 然后对测试结果进行分析，对系统的处理能力和可伸缩性做一个描述。 当然，要在报告中说明你的测试环境。 另外一位网友robust 的留言： 你的意思是否想用10000个用户测试结果来推测一下10万个用户? 还是如有些老兄说的,测试一下什么伸缩性测试.然后也来个报告,无非也是想用1万个来推测10万个的情况?(评注:那样的话要你做什么性能测试,只要计算一下就可以得性能结果了.) 还是如有些老兄说的,这一类的性能指标对大多数软件来说没什么实际意义，更多的是对硬件的要求?(评注:那样的话要你做什么性能测试,做什么性能调优,只要计算一下,添加硬件就可以了.) 实际上,"实践是检验真理的唯一标准!"这句话才是硬道理.只有真实地测试过才知道.任何推测只是推测,并不能反映真实的情况. 至于性能测试工具,LR只是普及率高(市场占有率高),并不是在性能指标上有优势.世界上比它厉害的工具有不少,举个例子siprent通信公司的avalanche2500,大型计算机实验室配备的性能测试工具.支持录制/回放,测试结果分析等.它可以模拟从数据层到应用层的协议,(当然也包含http-web),单个支持100万并发连接.拿它也可以测试100万级的并发性能. 又是偶的回复： 楼上的提到的见解不错，不过对性能测试的理解有些偏差。 先抛开性能测试工具不谈，其实这个问题是讨论到一个性能测试到底该怎么做。 简单举个例子，如果你想知道一种新的疫苗对人的作用，是不是要把所有的地球人全部找来每个人打一针试试呢？当然不是，只能是通过试验和抽样，然后通过统计学的方法来计算出一个模型，通过样本的表现来估算总体的特征。这就是统计学研究的领域，。不过请注意，统计学所包含的内容并不是像楼上的老兄所说的一样：只要计算一下就可以得性能结果了。 性能测试也同样如此。 楼主提到的性能需求应该是系统上线以后可能要面临的压力，先不讨论这个需求是否准确和有效，我们先假定它是有效的。那么，既然要验证的是系统在上线以后是否有能力应对10万用户同时在线的情况，那么自然要用生产环境来测试。如果有，那么 OK，可以作这个测试。至于工具，其实可以由开发人员帮忙写一些简单的脚本负责加压，再通过其他第三方工具收集测试数据就是了。 但是如果没有生产环境，只有一台双CPU，3G内存的 2850 服务器，怎么办？这就好像上面提到的例子。可行的方法是在这台服务器上使用不同级别的负载来进行测试，并根据测试数据获得系统在这种环境下的最佳负载和最大负载，并根据测试数据对负载和资源消耗的情况进行估算，找到它们之间的关系。 一般来说，大型的门户网站不会只用一台超级超级的服务器来承担所有的负载，因为采用负载均衡和集群技术可以更好的解决这个问题，一定是多台服务器分布在不同的地方，内容通过内容分发网络同步到各台服务器上。用户在访问时，其实是被应用层或者前端设备路由到一个合适的服务器去的。所以在测试时，对于可伸缩性的测试是必需的，一定要了解到 cluster 数量增加时，系统的响应能力是否可以线性的增加，也就是说是否可以承受更大的压力，为更多的用户提供服务。 最后总结一下，对于性能测试，要作的是确认系统的响应能力，然后看系统是否可以满足性能需求。 如果大家有不同的见解，欢迎 PK 讨论 继续偶的回复： to jackloo 你所提到的对于硬件资源和软件资源的要求并不完全准确。因为实际的资源消耗要根据网站所提供的业务类型来推算。 对于大多数门户网站来说，可供访问的大多是静态页面。在用户访问时，系统只是返回一个静态页面给用户，并不需要保持 session，而且这种情况下负载主要集中在I/O和网络流量方面——这也是为什么大型门户网站都会采用分布式的方式来部署服务器。当然，如果使用了 cache，内存的使用会随着服务器运行时间的延长而增加，但是 CPU 通常不会成为关键资源。 这是门户网站同企业应用或者在线游戏的区别。 还是偶： to 楼主 上面我也提到了，你需要进一步的明确你的测试需求是否有效，合理。 性能需求需要根据网站具体提供的业务类型来作为依据进行衡量。就如同上面提到的，是只提供了静态页面的访问？还是有其他的业务？ 要区分清楚注册用户、在线用户和并发用户的区别。 另外，你最迫切需要担心的并不应该是 LR 的 license 问题，而是被测的系统能否支持的了几百或者几千并发用户，如果连这个都支持不了，就更不用考虑上万的并发访问了。 希望大家有不同的看法和意见都可以写下来，大家一起讨论，共同进步。 skinapi http://bbs.51testing.com/thread-48646-1-1.html http://bbs.51testing.com/thread-48646-1-1.html loadrunner,自动化测试,性能测试,软件测试 Wed, 15 Nov 2006 02:42:31 GMT 数据统计分析的思路与分析结果的展示方式是同样重要的，有了好的分析思路，但是却不懂得如何更好的展示分析结果和数据来印证自己的分析，就像一个人满腹经纶却不知该如何一展雄才 ^_^ 一图胜千言，所以这次我会用两张图表来说明“描述性统计”在性能测试结果分析中的其他应用。 skinapi http://flyingwind-prometheus.spaces.live.com/blog/cns!98DB77008F2FBC3A!150.entry?_c=BlogPart http://flyingwind-prometheus.spaces.live.com/blog/cns!98DB77008F2FBC3A!150.entry?_c=BlogPart 软件测试杂感,软件测试 Tue, 14 Nov 2006 05:00:26 GMT 测试之道 ——对于IT企业而言，bug和用户必须是躲猫猫的关系 作者：flyingwind（华府长工58264） 邮箱：flyingwind0127@hotmail.com 4、胡马大宛名 上回书说到TE如侠。侠客离不开剑，也离不开马。就好比郭靖有了汗血宝马，想去哪就去哪，从来不 必担心路程问题；而胡斐追捕南霸天雷老虎，没有宝马良驹，从广东一直追到北京才算完。侠客离不开马 ，尤其需要骐骥骅骝，千里良驹。 杜甫《房兵曹胡马》：胡马大宛名，锋棱瘦骨成。竹批双耳峻，风入四蹄轻。所向无空阔，真堪托死 生。骁腾有如此，万里可横行。 然则对于TE而言，能够“风入四蹄轻”的千里马何在呢？ 人的精力总是有限的，即便再伟大的TE，对于无穷无尽的测试任务，也总会有感到疲惫不堪，难以为 继的时候。这不是因为TE本身功力不够，也不是因为TE掌中剑（TC）不好，而是缺少了一匹良骥。人力有 时而尽，只有非人力的才可持久；因此这良骥便是且只能是自动化测试（Automation testing）。 虽然《荀子·劝学》有云：骐骥一跃，不能十步；驽马十驾，功在不舍。然而完全由机器所执行的自 动化测试，不论骐骥还是驽马，全都能够做到功在不舍。因此这时候TE如果只是埋头编写自动化代码便有 失明智了。 TE可以针对每一条TC编写一段测试代码，然后通过执行这段代码完成对测试目标内容的覆盖；此为驽 马的方法，虽然劳而有功，然而工程浩大，且成本不菲，后续项目的继承性也难以保证。 TE还可以先创建框架，从测试需求分析开始，与coding的CMM的流程同步，采用迭代的方法渐增完成 测试代码；“随风潜入夜，润物细无声。”当测试执行开始的时候，测试代码的架构已经完成，只需对细 节进行后续维护即可。 然而还有更可取的方式：TE不要针对每个测试例编码，而是每个STEP编写更小的一段代码。不同的测 试例有可能使用相同的STEP。这种等价于STEP的每一段小的代码（记为cell）可以用STEP的简述进行封装 。例如BS结构的web页面，第一步通常是登录，登录之后跳转到首页。可以采用如下封装： login { /*input username & password*/ input_username "xxxxxx"; input_password "xxxxxx"; /*check*/ if (get_new page "//main.htm") output "step xxx is pass" else output "step xxx is fail" } 若干个此种简易封装的函数(例如完成了login,download_source,edit_source,upload_source等)完成之 后，TE对于某个测试例（step1：登录xx网站；step2：下载xx文件；step3：编辑刚才下载的xx文件； step4：把编辑过的xx文件再上传回xx网站。）可以如下编写： login; download_source; edit_source; upload_source; 对于使用函数编写测试代码的TE而言，完全不是在编码，只是写一篇简单至极的短文。如果测试例的管理 工具足够强大，甚至可以自动组装函数。至于今后的类似项目，同样可以直接使用这些函数；如果测试例 的管理工具足够强大，甚至可以第一次编写函数之后，一切的测试代码都自动生成。 只不过到那时，说不好TE是完全被解放了，还是完全被淘汰了。就好似汽车的出现代替了千里马，而 火器的出现淘汰了剑，剑与马都失去了价值的那一天，侠客也就消失了。 skinapi http://zhaoyuanhuan.spaces.live.com/Blog/cns!DB69D255C6078B8F!214.entry http://zhaoyuanhuan.spaces.live.com/Blog/cns!DB69D255C6078B8F!214.entry 软件测试杂感,软件测试 Sun, 12 Nov 2006 13:10:20 GMT 说起来学习计算机已经有六七年了，而进入软件测试这个行业也是有两年多了。记得最开始投入到测试的目的是因为容易进大公司。我身边的同学们都很鄙视测试行业，认为没有什么技术含量，而我却有些恋上它了，而且打算就这么做下去。 什么是测试？对于测试的定义有成千上万种，而我更喜欢接受的是“测试是一种证伪的过程”这种定义。记得高中上物理课的时候老师曾经举过一个例子，说怎么证明我们的手是干净的，我们用一盆干净的水去洗手，当洗完后水还是干净的，那证明我们的手是干净的。这样讲可能是有一些绕口，换句话说就是用清水去证明我们的手是脏的。我们测试也是这样，我们是去验证它的错误，而不是证明他是一个多么高明的软件。 测试真的比开发低一等么？老实说，是的，起码在国内一些软件作坊里是这样的，他们不重视软件质量，或者根本就不愿意花那份钱去组织一个测试团队。而我对国内的一些测试人员也是很气愤的，他们往往不喜欢在测试领域站住脚，不想在这个领域有大的发展，只是因为测试人员的门槛相对比较低而投入到这一行业。而我下面给大家列出来，我认为的在测试领域的职业发展层次： 1. 手工测试人员，这一类人是测试最底层的测试人员，也是当前被coder最瞧不起的一部分人。而我要说的是，手工测试是一切测试的基础，是我们软件质量保证的关键。对手工测试人员的要求比较起来要比编码人员（这里指的是大部分的Coder）的要求高，对于最底层的开发人员来说，他们只需要学会怎么照着别人代码拷贝就可以了。而对于手工测试人员来说，这就需要一些trouble shooting的能力了。在这一个档次上来说，测试是相当锻炼人的。 2. 测试系统搭建人员，测试环境的搭建，对于我们测试来说是至关重要，它能够保证软件缺陷的重现，它能保证测试版本的计划有序。当前，在我们的测试项目组里面，测试环境的搭建和手工测试是一起做的，这对于新进入测试行业的人来说，是一个很大的提高。顺便提一句，这种人员要学会使用脚本语言,如， shell,vbScript,JScript,python,perl等 3. 脚本开发人员，首先要说的是，开发语言并不是开发人员的专有工具，一个好的测试人员，在技术上身只要超过一个好的开发人员（打气）。这种人就要学习一些自动化技术，掌握一些自动化测试框架，对测试用例有很好地了解 4. 测试设计人员，对于测试的设计是一个非常精细的活，他首先要对被测软件有深刻的理解，在我们看来，他就是架构师，对于测试用例的设计，是整个测试过程的核心。一个好的测试用例集，能够很大的降低成本，提高自动化程度 5. 测试框架开发人员，它应该是和测试设计人员是一样的档次，因为我没做过相关的工作。从我的角度来看，他们是一群高手。 6. 软件度量与评估，这下拽了，上升到纯理论了，记得曾经学过一门这样的课，感觉就是一群经验丰富的测试人员和开发人员的集合，这需要丰富的测试和开发经验 7. 解决方案风险评估顾问，老实说，写到上一个，我就开始杜撰了。 在这里再介绍一下想进入测试这行的人员的入门方式： 1. 学好一门操作系统，建议去学MCSE（当然，学费好像比较贵） 2. 学好一门编程语言，学C++吧，建议《thinking in C++》《C++ Primer》 3. 学习基本的测试术语，如冒烟测试，UI测试，单元测试 4. 想一想我要是测试我眼前的这个显示器，应该怎么写测试用例呢 Ok,写了这么多，手有点酸，该去吃饭了 skinapi http://www.cnblogs.com/jackei/archive/2006/11/10/557160.html http://www.cnblogs.com/jackei/archive/2006/11/10/557160.html JMeter,性能测试,自动化测试,软件测试 Sat, 11 Nov 2006 16:27:34 GMT JMeter是一款在国外非常流行和受欢迎的开源性能测试工具，像LoadRunner 一样，它也提供了一个利用本地Proxy Server（代理服务器）来录制生成测试脚本的功能，但是这个功能并不好用。所以在本文中介绍一个更为常用的方法——使用Badboy录制生成 JMeter 脚本。 简单的介绍一下Badboy。Badboy是一款不错的Web自动化测试工具，如果你将它用于非商业用途，或者用于商业用途但是安装Badboy 的机器数量不超过5台，你是不需要为它支付任何费用的。也许是一种推广策略，Badboy提供了将Web测试脚本直接导出生成JMeter 脚本的功能，并且这个功能非常好用，也非常简单。你可以跟着下面的试验步骤来迈出你在开源世界的第一步。 （下面的例子是以我部署在本机的Mantis为例完成的，你可以点击这里下载完整的例子文件。关于Mantis的介绍和安装配置，请参见本文最后的参考资料。） skinapi http://www.cnblogs.com/jackei/archive/2006/11/11/557972.html http://www.cnblogs.com/jackei/archive/2006/11/11/557972.html loadrunner,自动化测试,性能测试,软件测试 Sat, 11 Nov 2006 16:26:15 GMT LoadRunner中的90％响应时间是什么意思？这个值在进行性能分析时有什么作用？本文争取用最简洁的文字来解答这个问题，并引申出“描述性统计”方法在性能测试结果分析中的应用。 为什么要有90％用户响应时间？因为在评估一次测试的结果时，仅仅有平均事务响应时间是不够的。为什么这么说？你可以试着想想，是否平均事务响应时间满足了性能需求就表示系统的性能已经满足了绝大多数用户的要求？ 假如有两组测试结果，响应时间分别是 {1，3，5，10，16} 和 {5，6，7，8，9}，它们的平均值都是7，你认为哪次测试的结果更理想？ 假如有一次测试，总共有100个请求被响应，其中最小响应时间为0.02秒，最大响应时间为110秒，平均事务响应时间为4.7秒，你会不会想到最小和最大响应时间如此大的偏差是否会导致平均值本身并不可信？ 为了解答上面的疑问，我们先来看一张表： skinapi http://flyingwind-prometheus.spaces.live.com/blog/cns!98DB77008F2FBC3A!148.entry?_c=BlogPart http://flyingwind-prometheus.spaces.live.com/blog/cns!98DB77008F2FBC3A!148.entry?_c=BlogPart 软件测试杂感,软件测试 Sat, 11 Nov 2006 12:56:07 GMT 下期预告：下次发布第四篇《胡马大宛名》，如果不过分加班，预计下周末发布。 ========================= 测试之道 ——对于IT企业而言，bug和用户必须是躲猫猫的关系 作者：flyingwind（华府长工58264） 邮箱：flyingwind0127@hotmail.com 自述： 前不久看了《编程之道》一书，深受震撼。原来天下大道如一，万事万物的道理都是相通的。其实只要自己肯动动脑筋，不论测试也好，或者其他，都是一样，不需要特别的学习，你其实什么都会。 既然是写《测试之道》，就还是以测试为例吧。很多人认为测试很容易，做测试不就是用鼠标随便点点吗？真的是这样的话，测试工程师的薪水恐怕也不可能达到今天这样的数字吧。换个角度讲，做 coding不就是按照别人给你的设计文档，写一些别人让你输入什么就输入什么让你输出什么就输出什么的函数吗？然而事实非是如此简单，因此coding 是伟大的，也因此，给伟大的coding找出bug更是最伟大的。 本书通篇没有任何高深的理论，也没有很详尽的具体工作方法。授人与鱼不如授人与渔，一切测试之“道”都靠你自己去悟。还是这句话：不需要特别的学习，你其实什么都会！ ========================= 业界有一个传说，流传的广度和速度令人惊讶，如果有一天谁对我说：XX公司天花板上的老鼠也知道这个传说。我想我不会感到一点点意外。 那是long long years ago以前的事情了，传说有一个老婆婆啥也不会，却机缘巧合进了Microsoft。就像啥也不会的令狐冲学了独孤九剑就能横行天下一样，老婆婆不知道学了啥东东，虽然大家都知道她啥也不会，但据传说她一个月发现了2000多bug。我大概算了一下，俄地神啊，一个月美国20个工作日左右，那就是一天发现 100个bug，除以8小时就是1小时平均至少12个，也就是5分钟一个，还得包括写report，安装版本，参加会议，以及吃东西喝水上厕所。等于1分钟发现一个bug，30秒写一个report，再用30秒完成Regression。而且这种状态还必须保持至少一个月之久！！！传说，的确是传说中才可能出现的事。 skinapi http://flyingwind-prometheus.spaces.live.com/blog/cns!98DB77008F2FBC3A!147.entry?_c=BlogPart http://flyingwind-prometheus.spaces.live.com/blog/cns!98DB77008F2FBC3A!147.entry?_c=BlogPart 软件测试杂感,软件测试 Sat, 11 Nov 2006 12:53:56 GMT 测试之道 ——对于IT企业而言，bug和用户必须是躲猫猫的关系 作者：flyingwind（华府长工58264） 邮箱：flyingwind0127@hotmail.com 3、吴钩霜雪明 李白《侠客行》：赵客缦胡缨，吴钩霜雪明。银鞍照白马，飒沓如流星。十步杀一人，千里不留行。 事了拂衣去，深藏身与名。闲过信陵饮，脱剑膝前横。将炙啖朱亥，持觞劝侯嬴。三杯吐然诺，五岳倒为 轻。眼花耳热后，意气素霓生。救赵挥金槌，邯郸先震惊。千秋二壮士，煊赫大梁城。纵死侠骨香，不惭 世上英。谁能书閤下，白首太玄经。 各个待测试的目标系统就是世间各个芸芸众生，测试工程师(TE)就是IT业的侠客。TE离不开测试用例 (TC)就如同侠客离不开剑。无剑不成侠；无合格的测试用例没法做好测试。 测试十大原则第二条：测试用例必须有明确的预置条件、操作步骤以及与之对应的预期结果。 IT业界的人员流动，那是相当快的。A先生设计了测试方案，到写TC的时候可能A先生已经另谋高就， 换成B先生在做了，再等到测试执行的时候可能B先生也远走高飞，必须让没有任何测试经验的C同学来做 了。 这时候如果TC写的不是妇孺皆能看懂，C同学十之八九无法顺利执行。后面最有可能的结果是什么？ 不言而喻。 不良的TC导致糟糕的测试执行（C同学职业道德如果不是很好，甚至可能故意漏测一些TC，反正这些 TC具体的执行没有人懂，C同学不必承担责任），糟糕的测试执行导致三个结果：其一，不能按计划的方 案验证重要功能导致bug没有在用户面前“躲”起来，进一步企业不论经济还是声誉都受到损害；其二，C 同学为了保证发现足够的bug，于是乎一定会专心致志于寻找一些诸如单词拼写错误，界面错误之类的细 枝末节问题，给coding的工程师们带来一种印象：他们做测试的什么也不会……；其三，在版本不断更新 的过程中，TC肯定需要不断维护，不断进行相应更新，不良的TC导致C同学没有真正去运行这些TC，也就 无从发现这些TC的问题了，从而不良的TC一直被保留到产品发布，然后这些不良的TC又被下一个产品所继 承……继续这些恶性的循环。 TC如剑。十年磨一剑。花时间细致地写好TC并不是浪费时间和精力。 skinapi http://flyingwind-prometheus.spaces.live.com/blog/cns!98DB77008F2FBC3A!146.entry?_c=BlogPart http://flyingwind-prometheus.spaces.live.com/blog/cns!98DB77008F2FBC3A!146.entry?_c=BlogPart 软件测试杂感,软件测试 Sat, 11 Nov 2006 12:53:02 GMT 测试之道 ——对于IT企业而言，bug和用户必须是躲猫猫的关系 作者：flyingwind（华府长工58264） 邮箱：flyingwind0127@hotmail.com 2、大道如一，过犹不及 为了让bug不被用户发现，测试是不是用该做的越深入越好？不止门外汉会这样认为，即便测试业界 的很多一些人也会这样认为。 《论语》有言：子贡问，“师与商也孰贤？”子曰，“师也过，商也不及。”曰，“然则师愈与？” 子曰，“过犹不及。” 译为现代汉语就是： 　　子贡问曰，“子张和子夏哪个能干？”孔子说，“子张过头了些，子夏不够了些。”子贡说，“那么 是子张强一些了？”孔子说，“过分和不及，同样都不好。” 所谓大道如一，测试亦然。投入的不够，则会不能在交付给用户之前发现bug；投入的过多，则会影 响收益。过犹不及，二者都不不够好的。 然而把握这个度还是极难的，没有一个可量化的标准。通常可以做到的就是两害相权取其轻了，对于 容忍力较强的客户，使用“不及”就可以了，用户发现了bug，召回产品打个补丁再重新发布就行了。 “XX产品存在重大隐患，被XX厂商召回”这样的新闻怕是在国内并不少见吧，其他行业如此，IT业能例外 乎？对于重要的客户，就不得不采用“过”的方式了。尤其一些需要“算政治账，不要算经济账”的项目 上更是如此了。 skinapi http://flyingwind-prometheus.spaces.live.com/blog/cns!98DB77008F2FBC3A!145.entry?_c=BlogPart http://flyingwind-prometheus.spaces.live.com/blog/cns!98DB77008F2FBC3A!145.entry?_c=BlogPart 软件测试杂感,软件测试 Sat, 11 Nov 2006 12:51:07 GMT 测试之道 ——对于IT企业而言，bug和用户必须是躲猫猫的关系 作者：flyingwind（华府长工58264） 邮箱：flyingwind0127@hotmail.com 1、道可道 说到测试，无论是专业的测试专家还是对策是一无所知的门外汉，首先要提到的肯定是“测试有什么 用？”花那么多的人力物力和金钱做的测试到底是为了什么？”很多所谓的专业书籍对此讲了很多让人眼 花缭乱的理论。 然而其实很简单，测试就是为了让产品在交付给最终用户以后，在产品生存周期（或提供有效服务的 期限以内），不让最终用户发现其所不能接受的现象。只要能不让用户发现其不能接受的一切现象，至于 产品是否存在bug，用户不会关心；因此IT企业也就没有必要关心。 skinapi http://flyingwind-prometheus.spaces.live.com/blog/cns!98DB77008F2FBC3A!144.entry http://flyingwind-prometheus.spaces.live.com/blog/cns!98DB77008F2FBC3A!144.entry 自动化测试,软件测试方法,软件测试 Sat, 11 Nov 2006 12:47:50 GMT 这是我好几个月以前，刚进华为前后的那段时间写的《测试的革命》。还没写完，现在也没多少业余时间，公司又不能上外网，因此想继续写下去，却没什么时间写了。把写好的部分先贴出来，供各位测试同仁指正。 测试的革命 作者：flyingwind 联系方式：flyingwind0127@hotmail.com 第一章 绪言 瓦特发明了蒸汽机，从而引发了工业革命，率先完成了工业革命的英帝国借此成了日不落帝国。软件测试界随着各种高级语言以及自动化测试工具的诞生，“工业革命”实际上业已发生。正如同工业革命是以“用机器制造机器”为革命完成的标志，测试的革命将会以“用软件测试软件”为最终的目的和完成的标志，而能够正确开展“测试的革命”的企业也必将成为未来最具竞争力的企业。 那么，“用软件测试软件”究竟需要怎样使用软件去测试目标系统？是否需要测试员能够完成每一个测试程序的编写？ 我坚信：“用软件测试软件”并非在任何条件下都是测试方法的最佳选择；测试员根本不必对每一个测试用例（testcase）编写测试的程序。这是由下述原因决定的： 1、测试员的职责。 测试员的职责在于尽可能找出目标系统中存在的缺陷。至于找出缺陷的方法，从来没有要求，也不应该有所要求。测试员可以通过手工测试（manual），可以通过自动化测试（automation），更可以通过阅读需求文档和设计文档找出缺陷。 测试中最重要的原则就是尽早测试，尽早修改。在能够通过阅读需求/设计文档，或者只进行简单的手工测试就发现错误的情况下，“用软件测试软件”决不是聪明的选择。对于测试员而言，这时就完全没有必要编写测试程序了。 2、自动化测试的目的。 工业革命的目的不是为了使用机器制造机器而使用机器制造机器，而是为了降低制造机器的成本。自动化测试的目的与此非常的类似，企业进行自动化的测试，是为了减少总的测试成本。例如某一条testcase，如果单纯使用手工测试，每个测试版本（build）执行这条testcase一次，需要10分钟。如果系统测试阶段需要n周，每周一个版本，那么整个测试活动花在这条testcase上面的时间就是10（分钟/版本）*n（版本）=10n（分钟）。而编写自动化测试的程序需要100分钟，调试和维护自动化测试程序需要50分钟，以后每个版本执行程序进行测试，需要1分钟，那么整个测试活动中，需要的时间就是100（分钟）+50（分钟）+1（分钟/版本）*n（版本）=150+n（分钟）。显然，当n>16的时候，自动化测试能够更节约成本，并且随着n的增大，自动化测试节省的成本也随之增大。这就是为什么一些小型项目基本上以纯手工的测试方式为主，而越是大型的项目越希望能够实现高度的自动化测试。 对于中小型的项目，手工测试更为适宜。测试员如果不能保证在5n（分钟）的时间之内编写出测试程序，则以手工测试为宜。此处的“5n”，n表示总的版本数，每条规范的测试用例的执行通常需要10分钟左右，编写测试程序的时间和维护、使用测试程序的总时间基本相当，因此编写测试程序的时间应该不大于 10*n/2=5n。 此外，由于版本的变动，对于已经完成的测试脚本还存在需要维护的任务。无疑，这又是一笔额外的成本。 3、自动化测试的代价。 “用软件测试软件”是一件成本很高并且伴随有一定风险的活动，测试员编写的测试程序的可靠性和稳定性都是事先不确定的。因此在“用软件测试软件”的过程中，应该采取一些降低风险的措施。最可靠的措施无疑是使用一个已经被广泛使用过的成熟的测试程序。在自动化测试的活动中，如果可以使用成熟的测试工具的时候，使用成熟的工具是一种较为安全可靠的方法。 skinapi http://flyingwind-prometheus.spaces.live.com/blog/cns!98DB77008F2FBC3A!138.entry http://flyingwind-prometheus.spaces.live.com/blog/cns!98DB77008F2FBC3A!138.entry 软件测试人生,软件测试 Sat, 11 Nov 2006 12:34:57 GMT 我的家就是这个“风之舞”的博客。 好久没有回来看看了，好久没有和以前的朋友们联系了。很想念大家，几个月了，过得好快啊，离开MS的时候还是热热的夏天，转眼之间，今天已经要穿长袖的衣服才能出门了。不知道我的朋友们是否一切都还好，记得从深圳回来的时候买了很多的水果，本来想带给大家的，结果路上出了些意外，午夜到北京，然后就是不停地上班&&加班了。 华为的工作的确和传说中的一样，干不完的活在等着我。但是现在终于有机会全职进行自动化测试的工作了，我觉得这是软件测试的发展方向，自己能在国内的自动化测试刚起步的阶段就参与进去，无论如何，都很值得。刚开始做manual的测试的时候，总是觉得很困很累，中午睡觉总是觉得睡不够，现在做 automation的测试，居然一个月一次午觉都没睡过，也没觉得很困；有时候做的起劲，连吃饭都省了，废寝忘食原来也很简单的嘛，看来选择做这个的确适合我。更何况进华为以后还有了另外的更大的收获，呵呵。 这几个月我好像不宜坐飞机，连续六七次了，一旦坐飞机出去或者要坐飞机出去，肯定要遇到意外。第一次去深圳，因为机场高速断路施工，居然误了飞机；然后回北京的时候飞机出故障，天气又很糟，航班差点被扔到济南去；后来想去厦门，遇到了台风；十一想去普吉岛，泰国政变了；又想改去塞班，居然因为我不满25岁而要求单位开个证明信，开好信之后又来不及签证了；最后只好计划再去厦门了，结果又因为一些个人的原因取消了行程；十一在家上网，看到重庆沙坪坝一个大公交从立交桥上摔下去了，死了好几十人，恐怖，要不是这个十一有些特殊情况我肯定又去重庆了，而且住的地方肯定就在沙坪坝附近，这次要是去了，说不定已经挂掉了，呵呵。 十一这几天，一开始很无聊，只能在家。好像是三号吧，朋友说要来北京，我很惊喜。我们一起爬了慕田峪，逛了北海。这些地方我都差不多十年没去过了，这次去了感觉还是很好玩的。白居易只说“江南好”，其实北京的景色原来也是很好的哦~~，为我的故乡也骄傲一下！塞上秋来风景异，浮云落日漫山碧~~！ 明天就要上班了，到年底以前还有N多个测试用例要等着我实现自动化呢，2000多个还是3000多个？记不清了，反正都无异于天文数字，连所有的主管都不认为我们有可能完成这些了。不过还是要挑战一下自己，看看自己能创造一个什么样的成绩。我不在乎那些狗皮一样的ABCD的个人绩效，我在乎我的理想——我要做最好的测试工程师！！TEAM=testing engineers are MVPs，我们测试工程师是最伟大的！！ skinapi http://blog.csdn.net/KerryZhu/archive/2006/11/09/1375341.aspx http://blog.csdn.net/KerryZhu/archive/2006/11/09/1375341.aspx 缺陷分析,软件测试技术,软件测试 Thu, 09 Nov 2006 09:42:14 GMT 1．引言： 生产软件的企业安排很多人来测试它们的软件产品。测试的目的就是发现bug（缺陷，defect）以便修正它们。正常情况是尽快处理可能的bug，从而减少修正bug的成本。因为，众所周知，bug越早被发现并修正，所消耗的资源越少。 问题是在很多情况下，由于修正已发现的bug，测试过程不得不停顿下来。 那么，以目前正忙于软件产品测试的同样资源来促进组织长期的质量目标不是更好？为了做到这一点，我们应该尽快地提前发现可能的bug。就像克劳士比（Philip Crosby）几年前所说的那样，我们应该努力预防bug，而不仅仅是修正它们。这就是真正的质量。 2．目标：预防bug 预防的重要性 正如我们所知，bug应该尽早地在开发过程中被发现。修正处于开发阶段的产品的bug的成本远远低于修正处于QC（Quality Control，质量控制）阶段的产品的bug，而相对与修正已经发布给客户的产品的bug的成本更是可以忽略不计。原因就是当你修正一个bug的时候，相当于把你之前做的事情重做一次。因此，越晚修正bug，你所重做的事情就越多。如果bug修正是在产品测试之前，那么重做的工作只有代码实现。如果bug修是在测试阶段，那么重做的工作就包括代码实现和测试。另一个导致成本增加的因素是依赖的组件和流程（process），随着项目的进行，产品依赖的组件和流程也会随之增加。 接下来，从另一个层面来讨论这个问题。如果bug发现和修正越早，开发成本越少，那么在第一时间就避免bug引入是不是成本消耗得更少？如果bug可以被完全预防，那么在开发过程中就不会出现重复工作的情况。这个被克劳士比极力推荐的观点非常有意义，而且在很多情况下已得到严密的证实。然而，并不是所有的生产软件产品的组织都试着去避免bug。它们花费了大部分的精力在产品发布给客户之前发现和修正其中的bug。在某些情况下，软件企业并不试着去达到这样的目标。在产品发布之后，企业通过迅速修正产品中的bug来处理客户的抱怨。这是因为，这样的企业始终处于“问题解决模式”，它们并不试图发现问题的根本原因，而只是把局部的大火扑灭。 这种模式并不仅仅导致重复工作直接带来成本的增加，而且会带来一个长期效应，而这将影响企业的业务。首先，发布带有bug的产品将给企业的声誉造成影响，并可能造成对潜在客户的影响——他们在是否建立合作关系上拿不定主意。另外，由于企业需要资源来不断解决现有产品中的问题，那么开发新产品的资源势必减少。 对很多人来说，零缺陷的软件产品似乎是不切实际的。我们总是听到软件开发者说：“软件永远有bug”。产品进入QC阶段时含有bug并不奇怪，因为我们“期望”开发人员制造bug。不幸的是，发布一个包含很多bug的产品给客户仍然不令人感到惊讶。甚至连客户本身也不再感到惊讶。 事实上，每个软件企业都可以通过一些简单的方法，在不增加任何额外资源的情况下预防bug。bug预防在于一个简单的道理：最好的方法是适当借鉴我们自己的经验。 今天的发现就是明天的预防 为了能够预防bug，我们必须首先了解bug的来源。软件bug可以分为几个类别（可能相互之间有所重叠）。第一类bug可能是随机的，它们通常是因为一时的疏忽造成的。尽管这些bug可能由于其随机性很难预防，但是，适当的分析将有助于避免这些bug。 另一类的bug来自于需求的误解、开发环境的错误或者纯粹由于缺乏解决问题的相关技术。这类bug共同的特点是都来自于开发人员。除非被发现，否则这些bug将一直存在。例如，一个还不完全理解需求的开发工程师在单元测试阶段可能无法发现这些问题，只有当产品被其他组织（如QC组）测试时才会发现产品实现与需求不一致。这使得在前期避免类似问题的出现更加重要。 一个好消息是，软件中的bug往往倾向于重复出现，即使是一个随机出现的bug。软件bug的不断出现不仅表现在同一个开发人员的工作上，而且表现在一个项目甚至是企业的层面上。这当然不是说公司中的每一个开发人员都会犯同样的错误。但是，至少其中一些的错误足以成为经常性出现的问题。所以，为什么我们认为重复的错误是一个好消息？因为可以预见的bug更容易预防。事实是我们可以找到一些常见的问题，并采取相应的措施去预防它（或至少减少类似错误出现的次数）。 人为bug的子集？那么这些bug被预防的可能性更大。域bug？域bug和产品的问题域或解决方案域紧密相关。这样的bug有更大的机会重现，因为开发人员、项目组甚至企业不断地在这个域上工作。 现在的问题是如何预防各种bug的产生。基于这次讨论的目的，我建议我们设定一个更加实际的目标。让我不要考虑完全预防某个bug，而是将目标设为——预防我们已经知道有一定可能性产生的Bug。这意味着我们可以通过我们各种发现bug的活动来促进将来的bug预防。当某个bug被发现时，我们就有了一个很好的机会来阻止类似问题的发生。 前提：记录bug 前提条件是持续跟踪发现的bug并正确地记录它们，离开了这个前提条件将不能将bug发现作为一个工具来预防bug。不论你使用bug跟踪系统,还是只手写了一个报告总结测试的结果，重要的是保存这些数据以便用于后来的分析。 在分析bug时，bug记录的问题值得注意。bug的定义越广泛，bug分析的数据越有用。报告bug的测试人员应该明白这一点，并不限于狭义上的bug。可能的话，测试人员应该运用他们的经验对bug产生的原因做最初的假设。我们将稍后在阐述分析过程时讨论这个问题。 和记录bug同样重要的是bug分析的第一步。仅仅跟踪过去的bug不能预防bug的发生，因为许多不同的bug可能来源于同一个核心问题。不同于信息收集，适当地分析bug的原因对bug预防非常有用。 3．缺陷分析 目标 在上一节，我们说明了bug分析的理由。如上所述，最终目标是预防bug 而不是修正它们。然而，我们可以定义一个重要的子目标，这就使不断提高整个开发团队（包括QC组）的技能和实践经验。当然，这两个目标是息息相关的。离开了不断的知识累积，也不能实现bug预防。不过，我觉得有必要提及这个子目标以强调持续性的过程。bug预防并不是一个不切实际的目标。但是，你不能期望它在一夜之间发生。你应该为开发小组提供教育和知识，以使他们逐渐改善他们的工作。 策略 本次讨论的焦点——bug预防策略非常简单和容易实现。秘诀就是使用在大多数开发环境中已经存在的过程元素。我们不会介绍任何新的花费昂贵的活动，也不会引入一些新的角色到开发过程中。 我们的策略是发现bug，找出bug的根源，然后寻找一个方法来预防类似的bug在将来出现。因为QC过程已经用于在目前的产品中发现bug，因此该策略的大部分工作实际上已经执行，大多数开发过程缺少的正是分析在QC过程中发现的bug。正如你将看到，尽管策略的这一部分并不需要昂贵的花费，但是却带来了极大的额外价值。 分析过程 (1) Bug发现和初步分析 如前所述，bug分析的第一步是发现bug。然而，发现bug的QC工程师（注：测试工程师）不应该满足于记录bug的表面症状。QC工程师的一个重要职责就是试图发现bug的根本原因。QC小组在检验产品质量时，不应该将产品看作一个黑盒，而应该像开发人员那样了解产品的内在，包括深入源代码，理解产品的设计和实现。这些能力都是QC小组开始bug分析的基本要求。熟悉了产品的代码，QC工程师就可能推测出bug的根本原因。 我要强调是下面这个短语的本质：bug的根本原因？bug的根本原因并不是产生这bug的源代码所在，尽管这些信息可能和分析过程关系密切。但是，发现bug的根本原因意味着找到造成这些错误的原因。通过一些实例来说明这个问题可能更清楚一些。 让我们看一个普遍存在的关于线程同步的问题。假设一个多线程的应用程序需要同步地访问某个数据结构。被指派测试这个产品的QC工程师发现在某种情景下，应用程序尽管没有Crash，但是会停止响应。正常的QC过程是，这个bug被记录在bug跟踪系统中，并描述了测试情景和停止响应的实际结果。然而，如果这个QA工程师熟悉源代码，就可以进行bug产生原因的初步分析。例如，这个QC工程师可能断定这个bug产生的原因是之前的线程没有释放mutex，从而造成了冲突。这些分析可以记录在bug的详细说明中，作为bug分析的一个基础。 (2) Bug修订和进一步分析 一如既往，发现一个bug之后，开发人员应该负责处理它。但是，如果bug的发现过程包含了bug根本原因的初步分析，那么关于如何解决这个bug，开发人员可能拥有了更多的信息。虽然这不是QC工程师bug初步分析的目的，但是它可能为开发人员提供了更多的观点。 除了修正缺陷以及记录实现的具体步骤，开发人员还应该对bug进行进一步的分析。这次分析应该着眼于导致bug产生的开发情景。 在线程同步的例子中，开发人员不应该仅仅记录增加了一个调用来释放mutex（注：Mutal Exclusion = 互斥锁，保证了共享数据不会同时被多个线程访问，只向一个线程授予对共享资源的独占访问权）。反之，开发人员应该找出没有释放mutex的原因。假设分析的原因是：因为需要同步的方法超过一个的返回点，因此开发人员在某些控制路径上忘记清理代码。 这一类简单的分析实际带来了非常大的价值。不同于记录具体问题的具体解决办法，我们现在有了可以解决许多情况的经验，有些情况甚至并不涉及到线程同步和释放mutex。但是，分析过程并没有结束，我们需要进一步的分析来将收集的所有数据转换为实践，从而帮助在将来避免类似bug的发生。 (3) bug预防分析 分析的最后一步就是寻找一个预防类似错误的方法。这一方法不仅涉及到开发、QC工程师，还涉及到不直接负责代码编写的资深开发人员。 这一阶段的成果是一些有用的实践经验，开发人员可以通过这些实践预防bug而不是修正bug。这些实践不应该是某个具体问题的解决方案。在我们线程同步的例子中，可能得到这样一个实践：是否有审计范围机制来获取和释放资源？这种实践 （不一定适合所有编程语言）可以指导开发人员用一个类（class）封装资源, 这样构造(constructor)函数容易分配和而与析构(destructor) 函数释放资源。如果遵守这样的约定, 当程序结束这方法时，不管控制路径是怎样的，资源（上述例子中获得的mutex）总能被释放。 Bug预防分析是整个bug分析过程的核心。这一阶段总结出的实践可以在更广泛的范围内预防潜在的缺陷。由于分析结果的广泛应用性，分析某个具体问题的投入将很容易被收回。 非常重要的是我们前面所举的例子是一个随机性的bug。开发人员由于疏忽而忘记了释放资源。在代码实现时，这样的bug是随机产生的，但是类似bug产生的几率却非常高。所以，尽管这一类bug是随机的，但仍然可以被预见并防止发生。 (4) 发布经验 分析得出的实践经验应该被记录并发布，这样其他的开发人员就可以通过学习这些经验避免类似的错误。一个发布经验最好的办法就是知识库。这将使得新的知识在组织内流动并被相关的开发人员所学习。 如果不将分析结果传达给组织内相关的其他人员，那么分析的目的就没有达到。避免下一个bug出现的唯一办法就是让开发人员知道如何避免它，并鼓励他们这么做。 Bug分析实例 让我们研究另外一个例子，以便更好地理解bug分析的益处。在这个事例中，QC工程师进行了如下的操作：当输入一个长字符串到应用程序时造成其崩溃(crash)。这一结论本身就需要一定程度的分析，但这个QC工程师并不满足于这样的分析，进一步研究了相关的代码，发现crash的原因是输入字符串时的处理有问题。其中一个步骤是将输入的字符缓存在一个固定大小的数组中，而这个数组有时候显得太小了。 和线程同步的例子一样，QC工程师的初步分析带来了很大的价值，开发可以更容易的发现和修正这个bug。此外，记录缺陷的真正原因而不是表象，将帮助其他人避免类似的bug。 接着，开发人员开始修正这个bug。当修正的时候，她不仅记录了解决措施，并说明了导致缺陷产生的原因。在这个例子中，造成bug的原因是在操作未经处理的C/C++缓冲区时，没有经常检验缓冲区的大小是否不够。然而，这个结论甚至可以被进一步总结为更广泛应用的经验以便帮助开发人员在以后避免类似的缺陷发生。所以，在分析的最后阶段，开发人员在组内更资深的开发人员的帮助下，得到了下面的实践经验：避免使用未经处理的C/C++缓冲区，尽量使用安全的collections和strings，如标准模版数据库中提供的可用collections和strings。这样就完全可以避免前面发现的这个bug。 益处 Bug分析带来了很多的好处。第一个好处就是帮助产生错误的开发人员总结经验，并使他在将来避免类似的错误。有时，只修正一个具体的bug而不去分析它产生的原因并不会帮助在日后得到提高。在这种情况下，只有深入分析和资深开发人员的指导才能使开发人员成长和提高能力。 更广泛的好处是使得其他开发人员从同事的错误中吸取教训。分析总结的实践经验可以预防bug的产生，这样的知识在组织内的成员间共享。某个开发人员产生的bug可以帮助组织内的其他人避免类似的bug出现。 从更一般的角度来看，发布最佳实践（如bug分析总结的实践）促进了组织内成员的学习和自我提高。这样看来，Bug分析的价值还不仅仅是缺陷的预防。 另一个好处是通过从更广的角度上记录bug，组织内的其他QC工程师将知道如何发现类似的错误。除了分享组织内的测试知识和经验，bug分析过程可以促进开发更好的测试技术和工具，从而帮助发现类似的bug。所以，就算缺陷没有被完全预防，也能更容易被发现。 作为上面所有好处的结果，QC在一轮测试中将有更多的时间来测试更复杂的情景并发现更“狡猾的”bug。如果类似的bug都已经被预防而不容易产生，而且QC都有更好的技术来发现类似的bug，就有了更充裕的时间来进行更高级的测试。当然，组织所生产的产品的质量也将得到提高。 最后，我想强调的是bug分析不仅收集了执行中的问题，而且从这些问题中总结了实践经验。举例来说，导致一个bug产生的原因可能是需求不够清楚。这样，通过bug分析得到的经验提供了一种方法来预防需求不清楚。这个经验可能不会对组织中的开发人员产生效果。所以尽管QC工程师开始验证开发人员的实现结果，但是还需要改善开发流程，如需求收集、设计流程等。 4．总结 真正的质量是生产没有bug的产品。任何其他目标都使组织内的成员从思想上接受软件缺陷是正常工作流的一部分。所以，第一步就是防止相同的bug再次发生。我们可以很轻易地执行这个目标。我们可以通过某个开发人员产生的一个bug提高整个组织的实践经验。 通过深入产品分析一个bug，我们可以明白这个bug的机制：为什么会产生？如何去预防它？下一次我们如何更容易地发现它？只要花一点时间去理解我们的bug，而不是仅仅是尽快修正它，我们就可以从中得到经验。这样，因为一个缺陷所浪费的时间也可以转化为投入：确保类似的错误永远不会再发生。 skinapi http://blog.csdn.net/testwin/archive/2006/11/06/1370299.aspx http://blog.csdn.net/testwin/archive/2006/11/06/1370299.aspx 软件测试技术,软件测试 Tue, 07 Nov 2006 14:49:24 GMT 软件测试是伴随着软件的产生而产生的。早期的软件开发过程中，那时软件规模都很小、复杂程度低，软件开发的过程混乱无序、相当随意，测试的含义比较狭窄，开发人员将测试等同于“调试”，目的是纠正软件中已经知道的故障，常常由开发人员自己完成这部分的工作。对测试的投入极少，测试介入也晚，常常是等到形成代码，产品已经基本完成时才进行测试。 　　直到1957年，软件测试才开始与调试区别开来，作为一种发现软件缺陷的活动。由于一直存在着“为了让我们看到产品在工作，就得将测试工作往后推一点” 的思想，潜意识里对测试的目的就理解为“使自己确信产品能工作”。测试活动始终后于开发的活动，测试通常被做为软件生命周期中最后一项活动而进行。当时也缺乏有效的测试方法，主要依靠“错误推测 Error Guessing”来寻找软件中的缺陷。因此，大量软件交付后，仍存在很多问题，软件产品的质量无法保证。 　　到了20世纪70年代，这个阶段开发的软件仍然不复杂，但人们已开始思考软件开发流程的问题，尽管对“软件测试”的真正含义还缺乏共识，但这一词条已经频繁出现，一些软件测试的探索者们建议在软件生命周期的开始阶段就根据需求制订测试计划，这时也涌现出一批软件测试的宗师，Bill Hetzel 博士就是其中的领导者。1972年，软件测试领域的先驱Bill Hetzel博士（代表论著《The Complete Guide to Software Testing》），在美国的北卡罗来纳大学组织了历史上第一次正式的关于软件测试的会议。在1973年，他首先给软件测试一个这样的定义：“就是建立一种信心，认为程序能够按预期的设想运行。Establish confidence that a program does what it is supposed to do. ”后来在1983年他又将定义修订为：“评价一个程序和系统的特性或能力，并确定它是否达到预期的结果。软件测试就是以此为目的的任何行为。Any activities aimed at evaluating an attribute or capability of a program or system. ”在他的定义中的“设想”和“预期的结果”其实就是我们现在所说的用户需求或功能设计。他还把软件的质量定义为“符合要求”。他的思想的核心观点是：测试方法是试图验证软件是“工作的”，所谓“工作的”就是指软件的功能是按照预先的设计执行的，以正向思维，针对软件系统的所有功能点，逐个验证其正确性。软件测试业界把这种方法看作是的软件测试的第一类方法。 尽管如此，这一方法还是受到很多业界权威的质疑和挑战。代表人物是Glenford J. Myers（代表论著《The Art of Software Testing》）。他认为测试不应该着眼于验证软件是工作的，相反应该首先认定软件是有错误的，然后用逆向思维去发现尽可能多的错误。他还从人的心理学的角度论证，如果将 “验证软件是工作的”作为测试的目的，非常不利于测试人员发现软件的错误。于是他于1979年提出了他对软件测试的定义：“测试是为发现错误而执行的一个程序或者系统的过程。The process of executing a program or system with the intent of finding errors.”这个定义，也被业界所认可，经常被引用。除此之外， Myers还给出了与测试相关的三个重要观点，那就是： 1、 测试是为了证明程序有错，而不是证明程序无错误； 2、 一个好的测试用例是在于它能发现至今未发现的错误； 3、 一个成功的测试是发现了至今未发现的错误的测试； 这就是软件测试的第二类方法，简单地说就是验证软件是“不工作的”，或者说是有错误的。Myers认为，一个成功的测试必须是发现Bug的测试，不然就没有价值。这就如同一个病人（假定此人确有病），到医院做一项医疗检查，结果各项指标都正常，那说明该项医疗检查对于诊断该病人的病情是没有价值的，是失败的。Myers提出的“测试的目的是证伪”这一概念，推翻了过去“为表明软件正确而进行测试”的错误认识，为软件测试的发展指出了方向，软件测试的理论、方法在之后得到了长足的发展。第二类软件测试方法在业界也很流行，受到很多学术界专家的支持。 然而，对Glenford Myers先生“测试的目的是证伪”这一概念的理解也不能太过于片面。在很多软件工程学、软件测试方面的书籍中都提到一个概念：“测试的目的是寻找错误，并且是尽最大可能找出最多的错误”。这很容易让人们认为测试人员就是“挑毛病”的，而由此带来诸多问题。大家熟悉的Ron Patton在《软件测试》（中文版由机械工业出版社出版，此书是目前国内测试新手入门的经典教材）一书的第10页，有一个明确而简洁的定义：“软件测试人员的目标是找到软件缺陷，尽可能早一些，并确保其得以修复。”这样的定义具有一定的片面性，带来的结果是： 1、 若测试人员以发现缺陷为唯一目标，而很少去关注系统对需求的实现，测试活动往往会存在一定的随意性和盲目性； 2、 若有些软件企业接受了这样的方法，以Bug数量来做为考核测试人员业绩的唯一指标，也不太科学。 总的来说，第一类测试可以简单抽象地描述为这样的过程：在设计规定的环境下运行软件的功能，将其结果与用户需求或设计结果相比较，如果相符则测试通过，如果不相符则视为Bug。这一过程的终极目标是将软件的所有功能在所有设计规定的环境全部运行，并通过。在软件行业中一般把第一类方法奉为主流和行业标准。第一类测试方法以需求和设计为本，因此有利于界定测试工作的范畴，更便于部署测试的侧重点，加强针对性。这一点对于大型软件的测试，尤其是在有限的时间和人力资源情况下显得格外重要。 而第二类测试方法与需求和设计没有必然的关联，更强调测试人员发挥主观能动性，用逆向思维方式，不断思考开发人员理解的误区、不良的习惯、程序代码的边界、无效数据的输入以及系统各种的弱点，试图破坏系统、摧毁系统，目标就是发现系统中各种各样的问题。这种方法往往能够发现系统中存在的更多缺陷。 到了上世纪80年代初期，软件和IT行业进入了大发展，软件趋向大型化、高复杂度，软件的质量越来越重要。这个时候，一些软件测试的基础理论和实用技术开始形成，并且人们开始为软件开发设计了各种流程和管理方法，软件开发的方式也逐渐由混乱无序的开发过程过渡到结构化的开发过程，以结构化分析与设计、结构化评审、结构化程序设计以及结构化测试为特征。人们还将“质量”的概念融入其中，软件测试定义发生了改变，测试不单纯是一个发现错误的过程，而且将测试作为软件质量保证（SQA）的主要职能，包含软件质量评价的内容，Bill Hetzel在《软件测试完全指南》（Complete Guide of Software Testing）一书中指出：“测试是以评价一个程序或者系统属性为目标的任何一种活动。测试是对软件质量的度量。”这个定义至今仍被引用。软件开发人员和测试人员开始坐在一起探讨软件工程和测试问题。软件测试已有了行业标准（IEEE/ANSI ），1983年IEEE提出的软件工程术语中给软件测试下的定义是：“使用人工或自动的手段来运行或测定某个软件系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别”。这个定义明确指出：软件测试的目的是为了检验软件系统是否满足需求。它再也不是一个一次性的，而且只是开发后期的活动，而是与整个开发流程融合成一体。软件测试已成为一个专业，需要运用专门的方法和手段，需要专门人才和专家来承担。 skinapi http://www.manageblog.net/bjwander/archive/2006/11/02/1833.html http://www.manageblog.net/bjwander/archive/2006/11/02/1833.html 测试职业发展,软件测试 Thu, 02 Nov 2006 15:13:51 GMT “刁”民特点 1.喜欢反驳，任何事情都喜欢用另外一个角度思考问题，喜欢质疑问题的所在和本质 2.喜欢用数据和事实证明，从来不用一些所谓的空理论来说明问题，因为他知道空的就是空，再刁也不行 3.不喜欢浪费时间，观点直接，一步到位，绝对不允许说一大堆的废话 4.从来不给领导一点面子，为了问题而争吵的脸红在所不惜，但当解决问题时虽然领导也许已经满肚子气，他却为了解决了问题而欣喜若狂 5.承认自己的错误，对别人的有效意见会接受，并深刻的思考，形成自己的理解，并与意见提出者进行讨论和验证 6.刁民是从不教条的，会随着环境不同而认知见解不同的。 做刁民的后果很严重 做刁民是需要勇气的，而且还需要极大的勇气，这些勇气很难得，因为这对于普通人来说，实在是无法做到的。因为做了刁民，小的可以让领导不悦一下，中的让领导给你的薪水打上封条，大的可能会引起被领导解聘的危险，所以做刁民的后果，一定是很难受的。 刁民难道真的不会沟通？ 刁民是最会沟通的，只要他认为有用的知识，他甚至不睡觉都想攫取过来，纳为自己的理解，甚至可以不顾及自己的地位和颜面，而只为了一个方法或者见解。所以刁民是最会沟通的，他的沟通不仅仅在于语言，而在于行动，他用实际行动打动你的时候，甚至你感觉比任何语言都有效。 刁民的知识也是很乐意与别人分享的，因为对于一个不会知识分享的刁民，永远不会进步，如果想进步，就要听百家言，纳百家意，综合后，再次补充和反复，让自己的观点和理解更加的深入。所以，做刁民一定要无私，如果有了私心，那么这个刁民是做不成的，即使做成了，也一定会自己把自己做死。 刁民最喜欢的依然是刁民 刁民最喜欢的不是平乏无庸，胆小非常的人，刁民最喜欢的还是有思想的人，大胆提出意见、为了企业或者工作不惜余力，即使错了也能和你理论半天，这样头脑风暴的方式，在任何情况下都不会如此见效，如此刺激了人的神经的。所以刁民最喜欢的还是刁民，因为和刁民聊天，可以长了见识，也增了改进的思想，还可以了解其对工作的一些看法。如果只知道是每天工作，毫无意见的人，即使让其讲出意见，也不会说出的人，最少，我认为他们一辈子也不会成为刁民，但从他们嘴里说出的东西，刁民却一定要耐心的听，如果不听，那么这个刁民也不叫做刁民了，因为刁民吸取多家意见。 除了刁民，我还能做什么 如果说不让我做刁民，我实在做不到，虽然做刁民也并非我愿意的，但性格决定了我就是一个标准的刁民，这辈子估计也摆脱不掉了。即使有了那么多严重的后果，但依然还是做了一个刁民，刁民很难，领导很难，刁民难的是要顾及领导的情绪，领导难的是有包容心。 skinapi http://www.manageblog.net/bjwander/archive/2006/10/30/1828.html http://www.manageblog.net/bjwander/archive/2006/10/30/1828.html 测试部门管理,软件测试 Mon, 30 Oct 2006 15:36:34 GMT 沟通是啥玩意 人们都习惯了说沟通，以为说话就是沟通，以为多说几句就沟通好了，那就错了。沟通是一种互动，如果单方说，单方听，那就不是沟通，即使听众有时哼哈一下。那就是命令，那就是要求，那就是一种自愿。而有效沟通才是真正调用人的能力、激发人的想法的重要手段。 国有企业习气 1.领导和下属永远是不对称的沟通，即使领导认为那对称，也是自己一厢情愿，因为心里的壁垒没有打破。 2.沟通就是要求！大错特错，混蛋才这么认为，因为要求是命令，不得已的情况下才会使用，如果沟通是命令，让你接受，你虽然有一些更好的意见，那么你还会说吗？ 3. 沟通就是沟通，不知道啥叫有效！总是认为自己的沟通是有效的，但有效吗，做个小游戏好了，一件事情，让两个人分别去沟通，将结果反馈给提出人，提出人听取他们沟通对象的表述，看是否一致。或许，这已经千差万别，有时虽然都沟通的不错，但要看一下花费的时间，不要因为时间是自己的，自己想怎么用就怎么用。一个人已经喝上了茶水，另外一个人还在沟通，哪个更有效呢，看起来那个喝茶水的太不象话了，但是实际上，是另外一个人虽然努力，但却只是占用更多时间罢了。 消除“代沟” 沟通的差了，可能啥问题没有解决，还背上被人议论和讨厌的感觉，这样对于任何一个人实施工作都是不利的。但是不沟通却是不行的，因为必须沟通，如果不沟通，则只能凭着感觉来感知项目和人员，但沟通却又是不能避免会有一些抵触的，那该如何消除这些高墙壁垒，深渊沟壑呢？ 1.上级主动向下级沟通 这样做的好处不言而喻，因为下级总是带着畏惧心里，所以上级主动沟通一下，下级也非常开心，因为他觉得有人听他的意见了，可以施展自己的能力了。 2.不要打断下级的意见 上级要懂得下级的心里，因为当一个领导，最重要的是用好人，用好这个人，即使委屈一点也无所谓，因为用好了，大家都说好，用不好，才是领导真正的失败。 真正理解下级的意见，如果不理解就不要说话，因为说了一些没有水平的话，会被下级认为你能力差，甚至不懂就乱说，一点技术含量都没有。 所以尽量不要打断下级的意见，如果在自己讲意见或者建议时，下级打断的情况下，要委婉的说明，比如说暂时记下来，最后一起解答，而不是强硬的发布命令口气。 3.抓住重点，简明扼要 沟通一定要讲重点的，一句话可以说明的，不要用两句话，两句话的，就绝对不要用三句话，否则说的多了，说的自己都晕了，别人就更晕了，让别人从你大量的信息中抽取出你所要表达的意思，那一来是麻烦，二来是浪费别人的时间，也浪费了自己的时间。 所以，一定要简明扼要的表达思想，当别人听不懂的时候，再用实例证明，必须是实例，如果再用大的理论来说明，那这样的沟通即使通过了，时间也早就远远不止了。 4.尽量少用一些强制的字眼，比如要求、必须，多采用一些委婉的字眼，一样的事情，委婉一些或许更容易让人接受，比如你看这样是否可以、是否觉得等。比如，我觉得这样做不是很好，我还是建议按照我那样做，因为……（将好处列出） 如果你是开明的领导，一定会分析好处，然后，逐一对好处进行缺点的指出，再听取对方的意见，如果你不是开明的领导，一定会说：“没什么，都一样的"“，这个应该不是问题，不算问题”，“你同意不同意我说的”“我要考虑很多事情，不需要考虑这么多细节” 分析：以上这些话纯粹从打击别人出发，给任何人的理解都是打击，而不是一种从旁边的协助。比如说领导要考虑很多事情，想一下，考虑很多事情就逐一把要考虑的列出来，看看是否能够考虑清楚，只说永远都是说，再有些事情，领导考虑就好了，何必表达自己的意见，表达出来，也许和普通的员工没有任何的关系，和人家没有关系的事情，人家为什么要去听，难道就仅仅因为你是一个领导吗？ 5.注意聆听，少发言 不懂不说，说了就切中要害 你的沟通烦恼消除了吗？ 如果没有消除，首先考虑自己的言行吧，每个人都不是十全十美，你沟通的东西，多长时间，效果如何？用数字说话的时候，才是自己改进的时候。 skinapi http://soliya9902.spaces.live.com/blog/cns!4CBD7F2284BC0EA!455.entry?_c=BlogPart http://soliya9902.spaces.live.com/blog/cns!4CBD7F2284BC0EA!455.entry?_c=BlogPart 测试读书笔记,软件测试 Sat, 28 Oct 2006 17:13:13 GMT 对于这本活了25年的书，在研读后，更加加深了对作者的敬佩，尤其对作者在书中的一些奥妙之处还需要更加进一步的去实践和体味。读书笔记只是粗略的记录了一些书中的内容，仅是为了方便将来能让自己更好的在对这本书复习时，起到提纲携领的作用。至于，真正去体会跟运用，还是不妨要仔细的研读这本书几遍，并跟实际工作相结合的去看，收获会更多！ 　　 　　总体而言，这本书是本“顶”好的书，尤其是适合想入测试领域的人看的第一本书！（个人觉得，测试人员，人手一册比较好。^-^ 　PS:不是在打广告，只是说出自己真实的感受而已。） 　　（PS:初稿于五月，此为十月修改稿） skinapi http://soliya9902.spaces.live.com/blog/cns!4CBD7F2284BC0EA!454.entry?_c=BlogPart http://soliya9902.spaces.live.com/blog/cns!4CBD7F2284BC0EA!454.entry?_c=BlogPart 测试读书笔记,软件测试 Sat, 28 Oct 2006 17:12:49 GMT 作者在本书的最后一章粗略的讲述了有关测试因特网应用系统方面的知识。 　　作者明确了，测试基于因特网的应用系统的目标与测试传统程序并没有区别，但值得强调的是，该测试必须在程序部署到因特网之前要暴露其中存在的错误，并要追溯因特网引用系统错误的根源。值得一提的是：浏览器兼容性的测试是一挑战。 　　而因特网应用系统的测试，主导思想是：采用“分而治之”的方法。并有两个大方向的把握：内部开发的部件，需进行单元测试等；购买第三方的部件，则需要使用黑盒测试，通过测试了，再集成进入系统。 　　文尾，作者反复的强调：无论那个层次的测试，都必须在程序部署到因特网之前暴露其中存在的错误！ 　　（PS:初稿于五月，此为十月修改稿） skinapi http://soliya9902.spaces.live.com/blog/cns!4CBD7F2284BC0EA!453.entry?_c=BlogPart http://soliya9902.spaces.live.com/blog/cns!4CBD7F2284BC0EA!453.entry?_c=BlogPart 测试读书笔记,软件测试 Sat, 28 Oct 2006 17:12:25 GMT 作者一直强调XT方法尤其重视连续测试，而其目标性于传统测试一致，都是确定程序中的错误。它分两个部分：极限单元测试和验收测试。 　　极限单元测试，它具备两个简单规则：其一、所有代码模块在编码开始之前必须设计好单元测试用例；其二、在产品发布之前必须通过单元测试。由此可见XP方法的闪光点就在于前一规则。需注意：确定单元的范围；采用一个自动化的软件测试套件来减轻连续执行单元测试的负担；应将测试用例保存在一个代码库中，还要确保进行足够的备份，并具备所需的安全保密措施。 　　验收测试，首先要明确：该测试的目的是判断引用程序是否满足如功能型和易用性等其他需求。这部分，其设计/计划是由开发人员和客户来设计的，而验收测试是由客户通过使用场景来设计验收测试，且使用场景与验收测试通常是一对多的。需注意：极限测试中的验收测试可以是自动化或非自动化的；客户使用验收测试来验证应用程序是否得到了预期的结果；验收测试是回归测试的一种形式； 　　文尾，作者提示最重要的一点是：程序可能通过所有的单元测试，却不能通过验收测试。并提供给读者一种测试工具：JUnit。 　　（PS:初稿于五月，此为十月修改稿） skinapi http://soliya9902.spaces.live.com/blog/cns!4CBD7F2284BC0EA!452.entry?_c=BlogPart http://soliya9902.spaces.live.com/blog/cns!4CBD7F2284BC0EA!452.entry?_c=BlogPart 测试读书笔记,软件测试 Sat, 28 Oct 2006 17:12:01 GMT 作者在第八章着重讲述了XP与XT。它设计于20世纪90年代且于1996年进行了首次测试。目前，它依然是最流行的敏捷软件开发过程。 　　XP的目的：在短时间内开发高质量的程序，且能够支持诸如Java、Visual Basic及C#等编程语言的应用。不过，XP模型高度依赖模块的单元和验收测试。也就是说，对每个无论多小的递增的代码变更，都必须进行单元测试，以确保代码库满足其规格说明的要求。因此，XT需要首先创建单元测试和验收测试，然后才创建代码库。 　　XP更倾向于适合中小规模的软件开发：它避免了大规模项目的综合症（简单设计）；避免了编写不需要的功能。它是先生成单元测试用例，然后才编写代码通过测试。因此，XP可大致归结为：2原则（计划和测试）、4概念（不再详述）和12核心实践（不再详述）。 　　虽然XP开发起来比较敏捷，但却不适合所有的项目和机构。 o XP是一个过程，要么全做，要么什么都别做；若漏掉了一个实践，则XP应用得就不彻底，程序的质量就会受到影响。 o 在未来修改程序以增加新的功能，其代价要高于起初就将功能加入需求中并进行编码的代价。 o 一些程序员发现结对编程十分麻烦并侵犯隐私，因此，并不怎么接受XP思想。 　　文尾，作者提示：应根据项目的具体特性，仔细权衡XP方法的利弊，再做出最佳选择。 　　（PS:初稿于五月，此为十月修改稿） skinapi http://soliya9902.spaces.live.com/blog/cns!4CBD7F2284BC0EA!451.entry?_c=BlogPart http://soliya9902.spaces.live.com/blog/cns!4CBD7F2284BC0EA!451.entry?_c=BlogPart 测试读书笔记,软件测试 Sat, 28 Oct 2006 17:10:48 GMT 归纳法调试，是一个需要思考的过程。归纳，是一种特殊的思考过程，可以从细节转到全局，即：从线索除法，寻找线索之间的联系。也就意味着：从特殊到一般。归纳调试的步骤可以概括为以下一个图，在此就不再详叙。 　　演绎法调试，也是一个需要思考的过程。演绎，是从一些普遍的理论或前提除法，使用排除和精炼的过程，达到一个结论，即：错误的位置。其步骤也可以通过一个图来概述，在此就不再详叙。 　　回溯法调试，也是一个需要思考的过程。它常用于小型程序中来定位错误。它是沿着程序的逻辑结构回溯不正确的结果，直到找出程序逻辑错误的位置，即：从程序产生不正确结果的地方开始，从该处观察到的结果推断出程序变量应该是些什么值。所以使用这个过程，可以确定程序中从状态符合预期的位置点，到第一个状态不符合预期值的位置点之间的范围。 　　测试法调试，也是一个需要思考的过程。它是要使用测试用例来调试。而测试用例可分两类：供测试的测试用例；供调试的测试用例。（注意两者的不同之处。）不过，该方法不是一个完全独立的方法。它常常与归纳法一起使用，以获得进行假设和/或证明假设所需的信息；它也可以和演绎法一起使用，以排除有嫌疑的原因，提炼剩下的假设，并/或证明假设。 　　文尾，作者给予了调试的一些原则（首先是定位错误的原则；其次是修改错误的技术），及详细的错误分析。 　　（PS:初稿于五月，此为十月修改稿） skinapi http://soliya9902.spaces.live.com/blog/cns!4CBD7F2284BC0EA!450.entry?_c=BlogPart http://soliya9902.spaces.live.com/blog/cns!4CBD7F2284BC0EA!450.entry?_c=BlogPart 测试读书笔记,软件测试 Sat, 28 Oct 2006 17:09:03 GMT 作者在该书第七章着重讲述了调试的五种方法。不过有必要先明确一下调试的定义。调试，是执行一次成功的测试之后所要进行的工作。它有两个步骤：从错误定位（可解决95%的问题）；再错误修改。而对于各种方法的具体步骤及过程，都不再详叙。 　　暴力法调试，不需要过多的思考，但同时也是效率低下，即：不是很成功。它至少可被划分为三种类型：用内存信息输出来调试；根据一般的“在程序中插入打印语句”建议来调试；使用自动化的调试工具进行调试（可设置断点）。不过，该方法的主要问题在于：它忽略了思考的过程。因此，该方法的使用情况为：其它的方法都失败了；座位其它方法思考过程的补充，而不是替代方法。 　　（PS:初稿于五月，此为十月修改稿） skinapi http://soliya9902.spaces.live.com/blog/cns!4CBD7F2284BC0EA!449.entry?_c=BlogPart http://soliya9902.spaces.live.com/blog/cns!4CBD7F2284BC0EA!449.entry?_c=BlogPart 测试读书笔记,软件测试 Sat, 28 Oct 2006 17:08:39 GMT 测试结束准则，常常用到的且是没有任何作用的两个准则是： o 用完了安排的测试时间后，测试便结束； o 当执行完所有测试用例都未发现错误，测试便结束。即：当所有的测试用例不成功时便结束。 　　作者在这里给予了三类较为有用的结束准则，它们分别是： 1. 有用但不是最佳的准则，根据的是特定的测试用例技术； 2. 最有价值的准则，是以确切的数量来描述结束测试的条件； 3. 在测试过程中记录每单位时间内发现的错误数量；并通过检查统计曲线的形状，来确定是否继续或终止该阶段的测试。 　　最佳结束准则可能还是对上述三种类型的组合使用。单元测试用第一类，而其他测试，用后两类的组合使用。这种策略还是比较佳的。 　　文尾，作者谈及公司的架构中，认为测试部门应尽可能远离开发部门。事实上，最理想的是测试机构不应是同一个公司的一部分，因为如果不是这样，测试机构仍然会受到与开发部门同样的管理压力的影响。所以解决这个矛盾的一个方法就是雇佣独立的公司进行软件测试。这样以来，就可以提升了测试过程中的积极性、建立了与开发机构的良性竞争、避免了测试过程处于开发机构的管理控制之下，以及独立的测试机构带来的解决问题的专业知识。 　　（PS:初稿于五月，此为十月修改稿） skinapi http://soliya9902.spaces.live.com/Blog/cns!4CBD7F2284BC0EA!448.entry http://soliya9902.spaces.live.com/Blog/cns!4CBD7F2284BC0EA!448.entry 测试读书笔记,软件测试 Sat, 28 Oct 2006 17:08:12 GMT 验收测试，通常是由订购方（用户）来进行验收测试，并将程序的实际操作与原始合同进行对照的，其测试用例是为了尽力证明程序没有满足合同要求。所以，明智的用户首先会进行一次验收测试以判断产品是否满足其要求的。 　　安装测试，不是为了发现软件中的错误，而是为了发现在安装过程中出现的错误。错误类型主要为：用户必须选择大量的选项；必须分配并加载文件和库；必须进行有效的硬件配置；软件可能要求网络联通，以便与其他软件连接。并且，安装测试应由生产软件系统的机构来设计，作为软件的一部分来发布，在系统安装完成之后进行。此外，测试用例需要检查以确认已选的选项集合互不冲突，系统的所有部件全部存在，所有的文件已经创建并包含必须内容，硬件配置妥当等。 　　文尾，提及一下作者所讲述的测试的管理和计划。一个良好的测试计划应该包括以下几点：目标、结束准则、进度、责任、测试用例库及标准、工具、计算机时间、硬件配置、集成、跟踪步骤、调试步骤、回归测试。 　　（PS:初稿于五月，此为十月修改稿） skinapi http://soliya9902.spaces.live.com/blog/cns!4CBD7F2284BC0EA!447.entry?_c=BlogPart http://soliya9902.spaces.live.com/blog/cns!4CBD7F2284BC0EA!447.entry?_c=BlogPart 测试读书笔记,软件测试 Sat, 28 Oct 2006 06:52:53 GMT 作者从两个方面来概述一下系统测试，至于细节就不再详细叙述了。 o 对错误理解方面而言，主要是容易跟功能测试混淆。（应重点注意那些在设计外部规格说明的过程中所犯的转换错误。） o 对困难性而言，是由于要将程序与其目标进行比较，是系统测试的核心目的，可是没有说明使用什么样的测试用例设计方法。　　 　　因此，系统测试采取一种不同的测试用例设计法，共计15种的系统测试策略。（具体每个测试策略所采用的步骤就不再叙述了。）它们分别是：能力测试、容量测试、强度测试、易用性测试、安全性测试、性能测试、存储测试、配置测试、兼容性/配置/转换测试、安装测试、可靠性测试、可恢复性测试、适用性测试、文档测试、过程测试。 　　系统测试的执行，所涉及的关键是：规定了不能进行系统测试的人员及机构：一是程序员；一是负责该程序开发的机构。原因如下： o 执行系统测试的人思考问题的方式必须与最终用户相同； o 系统测试是一项“随心所欲，百无禁忌”的活动，而软件开发机构会受到心理束缚，有悖于此项活动。大多数的开发机构最为关心的是让系统测试进行得尽可能顺利并按时完成，而不会尽力证明程序不能满足其目标。系统测试至少应由很少受开发机构左右的独立人群来执行。也许最经济的执行系统测试的方法，是将测试分包给一个独立的公司来完成。 　　（PS:初稿于五月，此为十月修改稿） skinapi http://soliya9902.spaces.live.com/blog/cns!4CBD7F2284BC0EA!446.entry?_c=BlogPart http://soliya9902.spaces.live.com/blog/cns!4CBD7F2284BC0EA!446.entry?_c=BlogPart 测试读书笔记,软件测试 Sat, 28 Oct 2006 06:52:25 GMT 功能测试，作者从三个方面来概述： o 定义上：是一个试图发现程序与其外部规格说明之间存在不一致的过程。 o 方法上：通常是一项黑盒测试，即：要依赖早期的单元测试的过程来实现理想的白盒逻辑覆盖准则。 o 过程上：需要对规格说明进行分析以获取测试用例集。 　　（PS:初稿于五月，此为十月修改稿） skinapi http://soliya9902.spaces.live.com/blog/cns!4CBD7F2284BC0EA!445.entry?_c=BlogPart http://soliya9902.spaces.live.com/blog/cns!4CBD7F2284BC0EA!445.entry?_c=BlogPart 测试读书笔记,软件测试 Sat, 28 Oct 2006 06:51:58 GMT 本书第六章,主要讲的是更高级别的测试，它最适合用于软件产品。可从两个层面来概述。 o 更高级别的测试 　　当程序无法实现其最终用户要求的合理功能时，就发生了一个软件错误。因而即使完成了一次非常完美的单元测试，仍然不能保证已经找出了程序中的所有错误，所以必须有这一测试环节。 o 软件开发过程与测试过程的对应 　　软件开发过程在很大程度上是沟通有关最终程序的信息、并将信息从一种形式转换到另一种形式，因此，绝大部分软件错误都可以归因为信息沟通和转换时发生的故障。 　　现有三个补充的方法来预防或识别这些错误，它们分别是： o 可以使软件开发过程更加精密，以防其中出现很多错误； o 在每个阶段结束时，可以引入一个独立的验证过程，在进入下一个阶段之前尽可能多地发现问题； o 对不同的开发阶段采用不同的测试方法。即：将每一个测试过程都重点针对一个特定的转换步骤，从而也针对一类具体的错误。（能在开发过程和测试过程之间建立起一对一的联系，能避免没有效果的多余测试，并使我们不会遗漏掉大量的错误类型。） 　　文尾，需注明的是：测试过程顺序并不一定意味着严格的时间顺序，多种测试在时间上是可以发生部分重叠测试的。但需要说明，集成测试往往并不作为一个独立的测试步骤，而且在进行增量模块测试时，它是模块测试的隐含部分。（开发过程与测试过程的对应关系图，由于篇幅的原因，在此就不再叙述。） 　　（PS:初稿于五月，此为十月修改稿） skinapi http://soliya9902.spaces.live.com/blog/cns!4CBD7F2284BC0EA!444.entry?_c=BlogPart http://soliya9902.spaces.live.com/blog/cns!4CBD7F2284BC0EA!444.entry?_c=BlogPart 测试读书笔记,软件测试 Sat, 28 Oct 2006 06:51:27 GMT 本章，最后作者给予了单元测试的其他部分的实际测试策略。 1. 应对测试用例进行测试。当测试用例造成模块输出的实际结果与预期结果不匹配的情况时，存在两个可能的解释：要么该模块存在错误；要么预期的结果不正确（测试用例不正确），所以为了将这种混乱降低到最低程度，应在测试执行之前对测试用例集进行审核或检查。 2. 使用自动化测试工具可以使测试过程中的枯燥劳动减至最低； 3. 在准备单元测试时，要重温以下心理学和经济学原则，会有所裨益的； 4. 因为个人试图测试自己编写的程序所带来的心理学问题，也适用于模块测试。 　　（PS:初稿于五月，此为十月修改稿） skinapi http://soliya9902.spaces.live.com/blog/cns!4CBD7F2284BC0EA!443.entry?_c=BlogPart http://soliya9902.spaces.live.com/blog/cns!4CBD7F2284BC0EA!443.entry?_c=BlogPart 测试读书笔记,软件测试 Sat, 28 Oct 2006 06:48:51 GMT 自顶向下测试，是从程序的顶部或初始模块开始。 o 测试开始之后，挑选哪一个后续模块进行增量测试没有惟一正确的方法； o 惟一的原则是：要成为合乎条件的下一个模块，至少一个该模块的从属模块（调用它的模块）事先经过了测试。 o 该测试策略里边最关键的可能就是编写桩模块了。 o 它涉及到的几个关键点概括为：桩模块的返回信息一定要给予此次调用所希望的返回值，否则调用模块将会发生失效或是产生一个混乱的结果；早期，测试数据要通过其一个或多个桩模块提交给模块的。 o 需要指出一点，就是测试完一个模块后，就用一个实际的模块代替其中的一个桩模块，而该模块需要的桩模块也被添加起来。需要注意的是：不存在最佳的模块序列。但尽量让包含I/O操作的桩模块和重要的桩模块添入。 　　自底向上测试，是开始于程序的终端模块，此类模块不再调用其他任何模块。 o 测试完这些模块之后，同样没有最佳的方法来挑选要进行增量测试的下一个模块； o 惟一正确的原则是：要成为合乎条件的下一个模块，该模块所有的从属模块（它调用的模块）都已经事先经过了测试。 o 需要指出的是，如果终端模块是多个的话，既可以进行串行测试，也可以进行并行测试。且每一个模块都需要一个特殊的驱动模块，即：包含着有效的测试输入、调用被测模块且将输出显示出来（或将实际输出与预期输出作比较）的模块。 o 对于测试序列也同自顶向下测试的一样。 　　（PS:初稿于五月，此为十月修改稿） skinapi http://soliya9902.spaces.live.com/blog/cns!4CBD7F2284BC0EA!442.entry?_c=BlogPart http://soliya9902.spaces.live.com/blog/cns!4CBD7F2284BC0EA!442.entry?_c=BlogPart 测试读书笔记,软件测试 Sat, 28 Oct 2006 06:46:41 GMT 在开始概述两种增量测试方法之前，作者对几个误解给予了澄清： + 自顶向下的测试、自顶向下的开发、自顶向下的设计被常用作近义词。 　自顶向下的测试和自顶向下的开发确实是近义词，表示安排模块的编码和测试顺序的策略；而自顶向下的设计则完全不同并且是独立的概念，即：按自顶向下模块设计的程序既可使用自顶向下的方式，也可使用自底向上的方式进行增量测试。 + 自底向上的测试（或自底向上的开发）常被错误得当作非增量测试； 　 原因在于自底向上的测试的开展方式与非增量测试是相同的，即：对底层或终端模块进行测试。 　　（PS:初稿于五月，此为十月修改稿） skinapi http://soliya9902.spaces.live.com/blog/cns!4CBD7F2284BC0EA!441.entry?_c=BlogPart http://soliya9902.spaces.live.com/blog/cns!4CBD7F2284BC0EA!441.entry?_c=BlogPart 测试读书笔记,软件测试 Sat, 28 Oct 2006 06:45:53 GMT 执行单元测试过程中，有两点需考虑：其一、如何设计一个有效的测试用例集；其二、将模块组装成工作程序的方式。前者涉及的内容在上篇已叙述过，而后者，涉及模块测试用例编写的形式、可能用到的测试工具类型、模块编码和测试的顺序、生成测试用例的成本以及调试的成本等。它有两种具体实现方法：增量测试（自顶向下和自底向上的开发或测试过程）、非增量测试。 o 增量测试：将测试的模块组装到测试完成的模块集合中，再进行测试。且必须要为每个模块准备一个驱动模块，但不需要桩模块。 o 非增量测试：先要独立地测试每个模块，再将这些模块组装成完整的程序。且测试单独的模块时，需一个特殊的驱动模块和一个或多个桩模块。 1. 驱动模块：人们编写的一个小模块，用来将测试用例驱动或传输到被测模块中，也可以用测试工具替代；还必须向测试人员显示该模块的结果。 2. 桩模块：被测模块可能调用到了其他的模块，所以还必须使用一个额外的组件，即：特殊模块，用于模拟被调用模块的功能。 　　文尾，需提及一个结论：增量测试要更好一些。原因如下： + 非增量测试所需的工作量要多一些；（桩模块） + 增量测试可以较早发现模块中与之不匹配接口、不正确假设相关的编程错误； + 增量测试，调试会进行得比较容易些；（调试） + 增量测试会将测试进行得更彻底；（可能会诱发先前测试完的模块出现新缺陷，且会经受更多的检验） + 非增量测试所占用的机器时间显得少一些； + 模块测试阶段开始时，非增量测试，就会有更多的机会进行并行操作，即：所有的模块可以同时测试。 　　（PS：初稿于五月，此为十月修改稿） skinapi http://soliya9902.spaces.live.com/blog/cns!4CBD7F2284BC0EA!440.entry?_c=BlogPart http://soliya9902.spaces.live.com/blog/cns!4CBD7F2284BC0EA!440.entry?_c=BlogPart 测试读书笔记,软件测试 Sat, 28 Oct 2006 06:45:25 GMT 单元测试用例的设计，需先明确两点： o 单元测试设计测试用例时，需两种类型的信息，即：模块的规格说明、模块的源代码。 o 虽单元测试总体上是采用面向白盒测试的，但是其设计主导思想是：使用一种或多种白盒测试方法分析模块的逻辑结构，然后使用黑盒测试方法对照模块的规格说明以补充测试用例。 　　文中，作者给予了实例讲解。从中可获悉：在使用白盒测试方法前，需要列举出程序中所有的条件判断；而在使用白盒测试方法时，应在开始就使用多重条件覆盖的方法；而在使用黑盒测试方法时，最好要使用边界值分析的方法，且不要依据边界值分析的结果来重写白盒测试的测试用例，最好黑盒测试的用例再单独写出来进行补充，不改动前边已经确认过的白盒测试的测试用例。 　　文尾，须明确两个观点：其一、多重条件覆盖准则要优于其他准则；其二、任何逻辑覆盖准则尚不足以胜任作为生成模块测试用例的惟一手段。同样，无论在白盒测试中判定状态或生成测试用例时都需要利用这样一个辅助手段：列表；即，状态判定表。 　　（PS:初稿于五月，此为十月修改稿） skinapi http://soliya9902.spaces.live.com/blog/cns!4CBD7F2284BC0EA!439.entry?_c=BlogPart http://soliya9902.spaces.live.com/blog/cns!4CBD7F2284BC0EA!439.entry?_c=BlogPart 测试读书笔记,软件测试 Sat, 28 Oct 2006 06:44:51 GMT 单元测试，是本书第五章讲述的重点。它是构建大型程序（>500 lines codes）测试的第一个步骤。可从三个方面给予了概括： o 定义上：单元测试是对程序中的单个子程序、子程序或过程进行测试的过程，即：一开始并不是对整个程序进行测试，而是首先将注意力集中在对构成程序的较小模块的测试上面； o 必要性上：它是一种管理组合的测试元素的方法手段；以减轻调试（准确定位并纠正某个已知错误的过程）的难度；并提供同时测试多个模块的可能，将并行工程引入软件测试中。 o 目的上：它是将模块的功能与定义模块的功能规格说明或接口规格说明进行比较。 　　文尾，需指明：单元测试的目标不是为了说明模块符合其规格说明，而是为了揭示模块与其规格说明存在着的矛盾。 　　（PS:初稿于五月，此为十月修改稿） skinapi http://soliya9902.spaces.live.com/blog/cns!4CBD7F2284BC0EA!438.entry?_c=BlogPart http://soliya9902.spaces.live.com/blog/cns!4CBD7F2284BC0EA!438.entry?_c=BlogPart 测试读书笔记,软件测试 Sat, 28 Oct 2006 06:44:24 GMT 本章最后，作者给出了一个合理的测试策略：“测试用例涉及方法可以组合为一个整体的策略，即：每一种方法都可以提供一组具体的有用的测试用例，但是都不能单独提供一个完整的测试用例集，所以一组合理的策略为： 1. 如果规格说明中包含输入条件组合的情况，应首先使用因果图分析方法； 2. 在任何情况下都应使用边界值分析方法。应注意，是对输入和输出边界进行分析； 3. 为输入和输出确定有效和无效等价类，在必要情况下对确认的测试用例进行补充； 4. 使用错误猜测技术增加更多的测试用例； 5. 针对上述测试用例集检查程序的逻辑结构，即白盒测试的五种方法。可适当的增加足够数量的测试用例，以便覆盖准则得到满足。” 　　（PS:初稿与五月，此为十月修改稿） skinapi http://soliya9902.spaces.live.com/blog/cns!4CBD7F2284BC0EA!437.entry?_c=BlogPart http://soliya9902.spaces.live.com/blog/cns!4CBD7F2284BC0EA!437.entry?_c=BlogPart 测试读书笔记,软件测试 Sat, 28 Oct 2006 06:43:59 GMT 因果图分析法，依作者而言，是为了解决边界值分析和等价划分的一个弱点：未对输入条件的组合进行分析。而因果图恰恰有助于用一个系统的方法选择出此类高效的测试用例集，并且可以指出规格说明的不完整性和不明确之处。 　　因果图，是一种形式语言（有严格语法限制的语言，计算机语言都是形式语言），是将自然语言描述的规格说明转换为因果图。实质上，是一种数字逻辑电路（一个组合的逻辑网络），但没有使用标准的电子学符号，而是使用了稍微简单点的符号。具体有六步（涉及到的每步具体过程及图样，由于篇幅，都在此略去）： 1. 将规格说明分解为可执行的片段； 2. 确定规格说明中的因果关系； 3. 分析规格说明的语义内容，并将其转换为连接因果关系的布尔图，即：因果图； 4. 给图加上注解符号，说明由于语法或环境的限制而不能联系起来的“因”和“果”； 5. 过仔细地跟踪图中的状态变化情况，将因果图转换成一个有限项的判定表； 6. 将判定表中的列转换成测试用例。 　　（PS:初稿于五月，此为十月修改稿） skinapi http://soliya9902.spaces.live.com/blog/cns!4CBD7F2284BC0EA!436.entry?_c=BlogPart http://soliya9902.spaces.live.com/blog/cns!4CBD7F2284BC0EA!436.entry?_c=BlogPart 测试读书笔记,软件测试 Sat, 28 Oct 2006 06:43:33 GMT 边界值分析法，有较好的测试回报率。该法较简单，仅是用于考察正处于等价划分边界或在边界附近的状态。因此，只需明确边界条件这一定义即可。边界条件，是指输入和输出等价类中那些恰好处于边界、或超过边界、或在边界以下的状态。 　　错误猜测法，没有用到任何特殊的方法，只是利用直觉和经验猜测出错的可能类型，然后编写测试用例来暴露这些错误。基本思想是列举出可能犯的错误或错误易发情况的清单，然后依据清单来编写测试用例；并且在阅读规格说明时联系程序员可能做的假设来确定测试用例，也就是说规格说明中的一些内容会被忽略，要么是由于偶然因素，要么是程序员认为其显而易见。 　　文尾，需提及注意的是：边界值分析法，考虑到了结果空间的边界（因为输入范围的边界并不总是能代表输出范围的边界情况。） skinapi http://soliya9902.spaces.live.com/blog/cns!4CBD7F2284BC0EA!435.entry?_c=BlogPart http://soliya9902.spaces.live.com/blog/cns!4CBD7F2284BC0EA!435.entry?_c=BlogPart 测试读书笔记,软件测试 Sat, 28 Oct 2006 06:43:05 GMT 再概述一下黑盒测试。那么首先就是等价类划分法。 　　等价类划分，是一个最优子集的挑选过程。该子集必须具备两个特性： o 严格控制测试用例的增加，减少为达到“合理测试”的某些既定目标而必须设计的其他测试用例的数量；即：每个测试用例都必须体现尽可能多的不同的输入情况，以使最大限度地减少测试所需的全部用例的数量；（经验而言，是用于生成有效测试用例的约束。） o 覆盖了大部分其他可能的测试用例：使用或不使用这个特定的输入集合，哪些错误会被发现，哪些会被遗漏掉。即：应该尽量将程序输入范围进行划分，将其划分为有限数量的等价类，这样就可以合理地假设测试每个等价类的代表性数据等于测试该类的其他任何数据。（经验而言，是用于生成无效测试用例的约束的。） 　　具体步骤为： 1. 确定等价类：确定等价类是选取每一个输入条件，将其划分为两个或更多的组。这里可以借助表格来进行划分，并确定了两类等价类：有效等价类、无效等价类。 2. 生成测试用例。（具体三步就不再叙述了） 　　文尾，顺便提一点个人经验：依据规格说明确定输入条件时，一定要思维紧密和周全，否则会出现很大的遗漏性；且用单个测试用例覆盖无效等价类，是因为某些特定的输入错误可能会评比或取代其他输入错误检查。所以应：少而全、多而专。 　　（PS:初稿于五月，此为十月修改稿） skinapi http://soliya9902.spaces.live.com/blog/cns!4CBD7F2284BC0EA!434.entry?_c=BlogPart http://soliya9902.spaces.live.com/blog/cns!4CBD7F2284BC0EA!434.entry?_c=BlogPart 测试读书笔记,软件测试 Sat, 28 Oct 2006 06:42:10 GMT 先谈及、概括一下白盒测试。 　　 　　白盒测试，所关注的是：测试用例执行的程度或覆盖程序逻辑结构（源代码）的程度。因此，也可以认为是逻辑覆盖测试。具体方法有五个，按其逻辑覆盖的从弱到强依次列出： o 语句覆盖（面）： 将程序中的每条语句至少执行一次，但实现不太可能，该准则有很大的不足，以至于它通常没有什么用处 o 判定/分支覆盖（线）： 必须编写足够的测试用例，使得每一个判断都至少有一个为真和为假的输出结果。即：每条分支路径都必须至少遍历一次。换句话说：所有判断的每个可能结果都至少执行一次，以及将程序或子程序的每个入口点都至少执行一次。需要指出的是：该准则满足语言覆盖准则。 o 条件覆盖（点）： 　编写足够的测试用例以确保将一个判断中的每个条件的所有可能的结果至少执行一次。 o 判定/条件覆盖（点线结合）： 设计出足够的测试用例，将一个判断中的每个条件的所有可能结果至少执行一次，将每个判断的所有可能结果至少执行一次，将每个入口点都至少调用一次。需明确一点，该准则有一个极大的缺点：尽管看上去所有条件的所有结果似乎都执行到了，但由于某些特定的条件会屏蔽掉其他的条件，通常并不能全部都执行到。例如：该准则并不一定会发现逻辑表达式中的错误（与、或）。 o 多重条件覆盖（点线组合）： 　　编写足够多的测试用例，将每个判定中的所有可能的条件结果的组合，以及所有的入口点都至少执行一次。需要说明的是，满足多重条件覆盖准则的测试用例集，同样满足判定覆盖准则、条件覆盖准则以及判定/条件覆盖准则。需明确的是：在存在循环的情况下，多重条件覆盖准则所需要的测试用例的数量通常会远远小于其路径的数量。 　　文尾，作者小结了一下。 o 包含每个判断只存在一种条件的程序，最简单的测试准则就是：设计出足够数量的测试用例，将每个判断的所有结果都至少执行一次；将所有的程序入口都至少调用一次，以确保全部的语句都至少执行一次。 o 包含多重条件判断的程序，最简单的测试准则是：设计出足够数量的测试用例，将每个判断的所有可能的条件结果的组合，以及所有的入口点都至少执行一次。 （PS:初稿于五月，此为十月修改稿） skinapi http://soliya9902.spaces.live.com/blog/cns!4CBD7F2284BC0EA!433.entry?_c=BlogPart http://soliya9902.spaces.live.com/blog/cns!4CBD7F2284BC0EA!433.entry?_c=BlogPart 测试读书笔记,软件测试 Sat, 28 Oct 2006 06:41:37 GMT 本书第四章主要讲述了白盒测试和黑盒测试的原理、具体方法，及一些测试策略的思考。就经验而言，个人觉得，测试软件中最重要的因素还是要：设计和生成有效的测试用例。所以，作者在开章之处特别提及测试用例，我认为是很必要的。 　　缘由：因为测试不可能是完全的，所以最显然的测试策略就是努力使测试尽可能完全。那么，由于考虑到时间和成本的约束，则一个最关键的问题就是：在所有可能的测试用例中，哪个子集最有可能发现最多的错误。很显然，在所有的方法中效率最低的就是随机输入的测试，那么就需要提出一套思考过程，让其有助于更加睿智地选取测试数据。 　　于是，便有了一种比较合理的测试策略：先使用黑盒测试方法来设计测试用例，然后视情况需要使用白盒测试方法来设计补充测试用例。 　　（PS:初稿于五月，此为十月修改稿） skinapi http://soliya9902.spaces.live.com/blog/cns!4CBD7F2284BC0EA!430.entry?_c=BlogPart http://soliya9902.spaces.live.com/blog/cns!4CBD7F2284BC0EA!430.entry?_c=BlogPart 测试读书笔记,软件测试 Sat, 28 Oct 2006 06:40:10 GMT 在本章的最后，作者附带提了一下桌面检查和同行评分这两个方法。 　　首先，来谈下桌面检查。桌面检查可视为由单人进行的代码检查或代码走查；并由一个人阅读程序，对照错误列表检查程序，对程序推演测试数据。由此，我觉得桌面检查可以说是上述两种方法的一个内核或者说是雏形吧。所以也可知其效率是相当低的。 　　然后，看一下同行评分。需指明：其该方法与测试并无关系，因为其目标并不是为了发现错误的，只是它与代码阅读的思想有一定的关联而已。 * 定义上：同行评分是一种依据程序整体质量、可维护性、可扩展性、易用性和清晰性对匿名程序进行评价的技术。不难看出，该技术的目的是为程序员提供自我评价的手段。 * 其小组成员的构成为：一位管理员，负责担任该评分过程的管理工作；6-20名参与者，并要保持匿名性，且要具备相似的背景。 * 评分的资料：由参与者自己挑出两个由自己编写的程序以供评审，其中一个应是自认为能代表其自身能力的最好作品；另一个是自认为质量较差的作品。 　　文尾，至于具体流程，就不再详叙了。 　　（PS：初稿于五月，此为十月修改稿） skinapi http://soliya9902.spaces.live.com/blog/cns!4CBD7F2284BC0EA!429.entry?_c=BlogPart http://soliya9902.spaces.live.com/blog/cns!4CBD7F2284BC0EA!429.entry?_c=BlogPart 测试读书笔记,软件测试 Sat, 28 Oct 2006 06:33:29 GMT 说完代码检查，现在来谈谈代码走查。从定义上来讲，代码走查是以小组为单元进行代码阅读的，同样也是一系列规程和错误检查技术的集合。且代码走查也采用了持续一至两个小时的不间断会议的形式。代码走查的小组成员的构成而言，一般是由三至五人组成，其中一人扮演“协调人”；一人担任秘书角色，负责记录所有查处的错误；还有一人担任测试人员。不过最佳的组合应该是： o 一位极富经验的程序员； o 一位程序设计语言专家； o 一位程序员新手（可以给出新颖、不带偏见的观点）； o 最终将维护程序的人员； o 一位来自其他不同项目的人员； o 一位来自该软件编程小组的程序员。 　　至于测试的流程跟代码检查很类似，类似之处就不多谈，只说一下不同之处吧。稍有不同的是代码走查的任务：就是参与者“使用了计算机”。被指定为测试人员的那个人会带着一些书面的测试用例（程序或模块具有代表性的输入集及预期的输出集）来参加会议。且在会议期间，每个测试用例都在人们头脑中进行推演，即：把测试数据沿程序的逻辑结构走一遍，并把程序的状态（如变量的值）记录在纸张或白板上以供监视。 　　这里，需指出：这些书面的测试用例必须结构简单、数量较少，因为人脑执行程序的速度比计算机执行程序的速度慢上若干量级。之所以提供这些测试用例，目的不是在于其本身对测试了关键的作用，而是其提供了启动代码走查和质疑程序员逻辑思路及其设想的手段。因为，在大多数的代码走查中，很多问题是在向程序员提问的过程中发现的，而不是由测试用例本身直接发现的。 　　文尾，至于代码走查所需要从心理学角度给予提前的心理筹备、后续过程和附带的几个有益的作用，都与代码检查的类似，所以在这里就不提了。 　　（PS:初稿于五月，此为十月修改稿） skinapi