给你一个软件，你测试了一个月都没有发现bug，这说明什么？你怎么办？

看到这个题目，一时之间真不知道如何回答，因为的确没有遇到过这样的情况。我的看法是:

1.说明软件已经没有bug了.严格说应该是说明软件中残留的bug已经很少了且是隐藏比较深的.尤其是一个经过大量使用的成熟软件,但对于一个新软件来讲，很少会遇到测试了一个月都没有发现bug的情况.

2.说明测试用例设计的太少或不够好,需要补充新的测试用例.尤其需要补充一些覆盖无效等价类的测试用例.

3.测试人员需要突破思维定势,打破常规.常见的情况可能是测试人员和程序员合作一段时间后,也更容易发现程序员容易犯的错误,但随着程序员对这些常犯错误的总结逐渐成熟起来,在写代码的时候，根据以前多次修改BUG的经验，已经在自觉的规避可能出错误的代码写法，从而写出的代码更规范更可靠。若测试人员还按照惯性思维去测试，当然就不太容易再发现BUG了。这时候,测试人员就应该突破思维定势,打破常规!多和别的测试人员交流,不断学习新的测试技术和方法,积极的实践!

 Excel.Application

Excel中几个常用对象：WorkBooks,WorkSheets,Cells.可以通过Name属性标识，也可通过index标识。

 Dim ExcelApp
 Set ExcelApp = CreateObject("Excel.Application")
 ExcelApp.WorkBooks.Open "F:\RandallTest.xls"
 Dim myWorkBook
 Set myWorkBook = ExcelApp.workbooks(1)
 myWorkBook.WorkSheets("Sheet1").Activate
 Dim myWorkSheet
 Set myWorkSheet = myWorkBook.worksheets("Sheet1")
 msgbox myWorkSheet.Cells(1,1).Value
 myWorkSheet.Cells(1,1).Value = "temp"
 myWorkBook.SaveAs "C:\RandallTest.xls"
 Set ExcelApp = nothing

使用QTP录制一些脚本再回放，这不难，难的是一个测试团队共同开发脚本，并能不断的完善脚本，创建一个结构化的自动测试脚本体系。这篇文章重点讨论的是，如何管理QTP的对象仓库，以便能让对象仓库易于维护、管理。
　　如果只是简单的录制、回放脚本，可能感觉不到对象仓库的存在。但是要做到QTP脚本的结构化管理，就必须对QTP的对象仓库进行严格的管理。

　　在实际工作中我们发现，QTP脚本做好后绝不是一成不变的，而是随着需求和页面的变化，需要不断修改的。如果每次修改脚本的时候，都重新录制脚本，成本极高，所以最有效的方法是，先修改对象仓库，然后修改脚本，以适应新的系统。

　　如果对象仓库里的管理比较混乱的话，修改脚本时就会遭受地狱般的痛苦，比如n多对象全堆在一起根本理不出头绪，对象的命名不知所云，找不到自己需要的对象等等。下面我们讲一下如何管理对象仓库，避免这些问题。

先介绍一下对象仓库中的对象层次，主要分为3个层次
1、Browser浏览器
2、Page页面
3、页面中的各种对象，比如Link、Button

　　Browser对应的是已经打开的IE窗口对象，Page对应的是不同的网页，比如登录首页是一个Page，登录成功后跳转到我的淘宝页面，这就是另一个Page。而页面中的各种对象就比较好理解了，图片、按钮、链接都是对象。

　　了解了对象层次，我们再讲一下命名。如果QTP在录制过程中自动记录对象，命名是非常乱的，缺乏逻辑性，经常看到一个Browser下面有n多“淘宝网_1”、“淘宝网_2”这样的Page，这对我们以后的管理非常不利。与其修改这些命名，我们不如用一种思路更清晰的方式，手动添加对象。

　　QTP中有一个工具实现了对象仓库的管理，Object Repository Manager，我们用它来添加对象。操作很简单，直接点击toolbar中的Add Object按钮，然后在web上点击你需要添加的对象即可，添加过后再修改名称。更新对象也比较简单，先选中需要更新的对象，然后点击Update from Application即可。

　　这项工作其实可以在系统页面出来以后就开始做，我们一边进行手工测试，一边把对象添加起来，为后面的脚本开发做准备。这时暂时不制作脚本。

　　总结一下，对象仓库的管理要满足以下几个原则：
1、每个Browser下的Page不要太多，最好不要超过5个，即使我们的系统都在同一个IE窗口下（没有弹出新IE），我们也可以分几个Browser管理，把业务上关联较强的几个Page放在一个Browser下；
2、每个对象都按照所代表的业务属性命名，最好用中文，不要出现一些难理解的字符，比如abc这样的。
3、尽量避免在一个tsr文件中堆放过多的对象，最好根据业务，把对象分为几个tsr文件保存。这里没有统一标准，以每个tsr文件结构清晰为宜。

　　现在我们完成了对象仓库的整理，好，可以开始制作脚本了。可是问题来了，录制脚本的时候，QTP能不能自动和这些对象对应上呢？QTP会不会又自动添加一堆对象进来呢？别担心，不会出现这个问题，因为我们将进行一场脚本编写的革命：放弃“录制脚本”这种传统的脚本编写方法，完全手工编写脚本

我们有了一套结构清楚的对象仓库以后，我们就可以轻松的手工编写QTP脚本了。

　　这里可能有人会问，QTP的录制功能不是很强大么，为什么还要自己手写脚本，这样是不是更麻烦。我先说一下我对手写测试脚本的感受，供大家参考。首先，如果我们整理好对象仓库，再录制脚本，QTP就会又自动生成一批新的对象，命名很乱，再修改替换太费事；其次，录制脚本的过程如果出现问题，再重来，很麻烦；最后，也是最重要的，手写脚本时思路非常清楚，而且写完再运行，感觉非常好，呵呵。

　　与编写脚本相比，脚本的维护工作同样很重要，而且维护脚本一般都是直接修改脚本，并不会去重新录制，所以开始的时候就用手写的方式，维护起来就会更轻松。

　　编写QTP脚本其实是比较简单、快速的。我们首先创建一个Test，然后把所有相关对象仓库的tsr文件和vbs文件添加到这个Test里面，下面就可以开始写了。写脚本大致会遇到这么几种情况：
1、调用vbs函数
2、调用其他Test
3、打开指定的URL
4、操作页面Page上的控件
5、添加CheckPoint
6、其他逻辑运算

　　我们分别讲一下。调用vbs函数比较简单，直接Call [函数名]。如果要调用其他的Test，那么首先点击Call to Existing Test，然后在QC中选择一个可以复用的Test，例如登录。如果登录的Test有参数，那么可以这样写：
RunAction "Action1 [login]", oneIteration , "张三"

　　下面的脚本要操作对象仓库了。我们先写出“Browser(”，这时就会发现，对象仓库里面的Browser对象都列了出来，然后我们选择需要的那个B对象就好。我们先从打开指定URL的脚本开始讲，打开指定的URL使用的机会比较多，特别是在Test的开始。一般我们这样写
Browser("登录").Navigate "指定的URL"

　　这里的“登录”是一个Browser对象，一般我们要选业务上符合的B对象。写完这句以后要再写：
Browser("登录").Page("登录首页").Sync

　　这句的意思是等待“登录首页”这个Page加载完毕，注意不要用Wait几秒这种方式来等待页面加载结束。

　　操作Page的对象是比较简单的，由于控件的类型太多，比如下拉菜单WebList、文本输入框WebEdit、按钮WebButton，这里就不一一说明了，大家看下面的一些例子吧：
Browser("购买直充").Page("购买直充").WebList("游戏区").Select 1
Browser("购买直充").Page("购买直充").WebEdit("PlayerName").Set "abc"
Browser("购买直充").Page("购买直充").WebEdit("PlayerNameAgain").Set "abc"
Browser("购买直充").Page("购买直充").WebEdit("CheckCode").Set "8888"
Browser("购买直充").Page("购买直充").Image("Submit").Click

　　如果遇到问题，不知道怎么写，可以先用录制的方式，生成一些脚本，然后仿照脚本写就可以了。另外在Page下面有可能会有Frame对象，这个没关系，就像这样写即可：
Browser("我的直充").Page("我的直充").Frame("直充入口").Image("立即直充").Click

　　添加CheckPoint要稍微复杂一些，比如说我们要检查Page上的一个WebElement的显示字符是否正确，那么首选要把这个WebElement完整的写在Test里面，这一句后面需要删除：
Browser("购买直充").Page("购买直充").WebElement("购买结果").Click

　　然后右击这一行脚本，选择Insert Standard CheckPoint，在弹出的CP属性窗口，设置CP的细节。确认后脚本就会自动生成一行：
Browser("购买直充").Page("购买直充").WebElement("购买结果").Check CheckPoint("购买结果")

　　最后再把上面那一行删除就可以了。

　　其他的逻辑运算，例如循环、判断，请参考vbs脚本语法，这里不说了。

　　总之，手动编写QTP脚本有很多好处，我在尝试了录制和手写两种方式之后，最终选择了手写的方式，大家不妨也试试，特别是对编码有兴趣的朋友

今天是周一，心情很沉重，干了都一年多的QA，感觉只学到了一点点地理论，其他什么都不会，在QA推进的过程中，高层表面的支持，实际上，当出现问题时，还是那么的我行我速，按照自己的意愿去做事，QA也就是在项目不紧的条件下，项目组才有时间理我们，我，26岁的男人，郁闷！

今天周二，哎，每天早上一到公司，基本上第一件事情，看有没有新的邮件，第二件事情就是上51testing，当然不是没有事情做，而是一种习惯，每次都到软件质量管理的模块去看看，看看前辈有没有新的观点，新的做事方法，看看后辈们有没有新的问题，希望能够借自己的微薄之力能帮助需要帮助的人，不过我们公司很多人都上这个网，所以我很多时候用我的马甲号发贴合回帖，哈哈

1.对QA的前途，很多人现在都说QA，都说测试，前途一片光明，把现在的阶段比作黎明前的黑暗，但是我想这个黑暗需要多少时间，中国的很多做事方法，需要多少时间能改变，如，一个非常简单的事情，我们经常搞得培训，培训完了搞反馈，然后以后改进和获得培训新的需求，但是我们的反馈是什么，中国20年的教育已经让我们忘记了真实，反馈的模式，大家参加培训前基本上都知道了，基本上都是：培训总体不错，只是----（一点没有痛痒的建议）。都是这样，好的培训结果这样，差的培训也是这样。我不知道是中国教育的失败，还是我们QA的任重道远。当然还有很多很多！这只是一个小小的点，如果说起来，将很多很多，所以我们大家都知道质量，都知道质量的重要性，但是真正去做的多少？我们还需要多少路要走？

2.模型，现在到处都是 PMP，CMMI，ISO等等，一看全是外国的，都是外国国情的东西，很多在中国根本就搞不起来，但为了过级还是浪费人力，财力的在做（我只是说有些没有用或有些对某些企业没有用，因为企业的文化也是不一样的啊）如果不是为了过级，实实在在的吸取，我想也能实实在在的改进，其次国内也没有制定出符合国内文化的品质管理的方式方法。

3.待续

问题：“有一个开发人员，水平很高，也很有热情。在开发某一功能的时候，发现只要把现有的code做很小的改动就可以顺手实现一个新的功能。这个开发人员该怎么办？”

黄雪斌的答案：“你所说的是一个非常有趣的现象。而episode的回答“schedule和spec最大”也非常精妙。

一般说来，如果在微软发生这种情况，开发人员是没有权利擅自向代码中添加额外的功能的。我们要求1. 要实现Function Spec中规定必须完成的功能；2. 不允许擅自添加额外的功能。软件产品的开发不仅仅是代码实现这么简单，每一个功能都要经过测试人员的测试，用户文档人员也必须在帮助文件中详细描述每个功能的使用。添加一个额外的功能同时也会带来其他许多额外的工作。同时，还需要验证该功能是否会对其他的功能产生影响，其易用性如何，会不会使用户感到迷惑，等等。

如何开发人员确实觉得该功能很好，可以告诉程序经理，再决定是否需要添加该功能（一般需要提交Requirement Change Request报告，再经过专门的变更管理委员会的讨论）。一般来说，在产品的Milestone1和Milestone2只会先完成必须要实现的功能(Must Have)，而一旦代码完成(CC之后)，添加任何新的代码都需要经过代码审核才行。

曾经看过一些关于优秀的开发人员在团队中的作用，其中有两条决定很有借鉴意义，在这里和大家分享：
1. 一个优秀的开发人员的工作效率会是普通人的5－10倍，要鼓励优秀的开发人员分享他们的经验，程序经理在制订Spec和Schedule时要多向他们进行咨询，请他们提出反馈意见
2. 再优秀的开发人员也只是团队的一分子，同样需要遵循整个团队的规定，按照团队的开发流程进行工作，没有例外。”

这应该是标准答案了。这里我想加一点我对这个问题在企业文化上的感受。

是的，微软强调开发团队的纪律，同时也极其鼓励员工的创造精神。但这并不意味着，你有好的创意就自然得到别人的重视而被采用。也许你很有信心的提交了报告，但最终发现被束之高阁。问题在哪里？问题在于，你不仅要有好的想法，还要能够主动把好的想法“推销”出去，让大家接受。比如说，你要主动告诉你的主管（Dev lead/manager），实现这个新的功能是多么简单，不会影响自己其他工作的进展；你要主动找项目经理(PM)，演示给他看你的新功能，让他感觉到客户一定会喜欢它；你要找有关测试人员，让他们估算测试难度和代价，告诉他们，必要时你可给予协助。
有了这些前期的工作，你的聪明才智会很容易变成产品中闪亮的光点。
所以一个优秀的员工，不仅要善于构想，还要敢于展现，更要具备团队的协作精神。这应该是微软企业文化中的一种价值取向吧。