爱情这东西，是个难养的宠物。不仅需要良好的生存空间，还需要用真情去滋养，用体谅去呵护。不然它非但不长，还可能夭折，甚至长成为害一方的畸形怪物。

谁都希望爱情能够健康成长，可是爱着爱着总是会出现些波折。波折久了，饲养爱情的两个人都会觉得累了。想放弃，不甘心。不放弃，这头爱情怪兽又折磨得人寝食难安。

爱得越来越痛苦，可无论如何也不愿意放弃，遇到这种情况应该怎么办呢？一位24岁的女孩提出了这样的问题。

大四实习时，她遇到了一个男人。大她１４岁，在一家文化公司做与书有关的事情。业务上的一些往来，让他们得以相识。女孩对他的最初感觉是，这个男人有些清高，让人很难接近的样子，有一些神秘感。可能正是这种感觉，让女孩产生了想探究他的心理。

好奇心让她与这个男人更多地接近。后来她被这个男人特有的幽默吸引了，很愿意与他呆在一起。再后来，她意识到自己有些爱上他了。

没有表白，只有默默地品味。可是，在一个月高风清的晚上，这男人突然对她说：“丫头，你已经爱上了我，搬我那里住算了。”

女孩诧异地看着这个有些老谋深算的男人：“你大我14岁呀，我会爱上你？”

男人笑：“嘴硬是吧？那我可找别的女人了。”

女孩狠狠地砸他一拳，却被他牢牢地抓住。

女孩说：“这样也太便宜你了。”

尽管对他的表白感觉有些突然，但她心理还是美滋滋的。在她看来，一个大自己14岁的男人，肯定会把自己当宝贝一样地宠着。

她 已经了解到，这个男人虽然已经奔四，但他从没结过婚。各方面条件也不算好，工作一般般，而且没房没车。一个奔四的男人混到这个份上，可以说讨个老婆都不容 易。可她却偏偏爱上了这样一个男人。凭自己年轻，凭自己美貌，凭自己所学的好专业和工作能力，找这样一个男人，应该美死他才对。

爱的力量是无穷的。女孩第二天就搬到了他那里。偷偷地与他过起了小夫妻生活。最初的一切都是美好的，女孩感受到了爱情的甜蜜和被人疼的幸福。

可是，渐渐地女孩发现，两个人经常因为一些小事争吵起来。而且他越来越不知道让着自己。女孩开始看到他身上的一些毛病。特别是由于业务上的往来，两个人的朋友有交叉，她竟然在他的同事那里打探出他曾经嫖妓。

女孩怒气冲天地将他叫回家里，大吵。

她本以为他会向自己道歉，他却偏不：“我哪里错了？谁让你不早几年出现？一个三十多岁的大男人偶尔发泄一下不可以吗？”

“三十多岁就有理由嫖妓吗？这是你的本质问题！”

女孩虽然这么说，但她也意识到，这是在认识她之前的事情。认识自己之后不是没发现他那样吗？可是，做了那样的事情，他总应该向自己做个以后不那样的保证吧？

没想到这男人的声音比她还高：“要保证得你保证，女人把男人爱得服服帖帖，男人还会去找小姐吗？”
未等女孩说话，他便摔门而去。

这件事情让两个人有了隔阂。以后的很多矛盾都是由这件事情引发出来的。但女孩从心底里还是很爱他。所以在毕业后找到正式工作之后，她并没有离开他。

可是随着日后的一些争吵，女孩渐渐地感受到自己有些委曲。一个快到四十岁的男人对小他14岁的女孩，应该宠爱，应该呵护，应该知道珍惜才对。

可他偏偏不。

后来女孩发现，自己得了滴虫性阴道炎。她怀疑是他在外面又拈花惹草了。女孩和他理论，这男人又怒了，说女孩的这种想法是最残酷的杀戮，他们的爱情将被她的劣性思维屠杀。

此后，两个人几乎每天都吵。终于有一天，那男人说话了：“丫头，你回到你父母身边去吧，你再怎么样他们也不会嫌弃你。”

女孩有些楞了，他这不是在赶自己走吗？他是嫌弃自己了？这样的一个男人都嫌弃自己了？

女孩有些不知道自己是谁了。让这样一个男人赶自己离开，她觉得自己活的实在是失败。她真的想走，可是她发现自己的心很痛，原来自己还爱得他很深。两个人最初的那种幸福，那些美妙都哪去了？两个爱得很深的人为什么会发展到总是大吵呢？而现在这样，自己又应该怎么办呢？

在我的情感热线上，女孩诉说着这些痛苦。她问：“我们真的没有爱情了吗？我们为什么会这样？”

有人把爱情比喻成手中的沙子，你握得越紧它就越容易溜掉。这让我们看到，爱情还是需要宽容的。如果处处斤斤计较，它无法在这个空间生存，自然就会离你而去了。

而 对于你所爱的人，无论是男人还是女人，都不要奢求他完美。更不要妄想把他改选成如自己的意愿。要知道，正是他原有的那些棱角，才让你有了最初的心灵萌动， 才让你的心头燃起了爱的火花。如果那些棱角真的都被磨平了，你未必会喜欢。因为那已经不再是那个当初让你心动的人了。

这个女孩说她实在是累了。我说：“累了，那就先让爱情休息。”

让两个人平静地暂且分开一段时间。给自己和对方一个机会，也给爱情一个机会。两个人都把这份爱情视作早产的婴儿，让他回到育婴箱里静养，给他时间让他有机会勃发出新的生机。

这 样可以给自己点时间，也给对方点时间。让双方都清醒地去反思，去审视，去重新评估这份爱情。并以此来预测前方的风景。如果前方还将阴雨连绵，那就不要让那 爱情复苏，就让它在静养中夭折，把它冰封在记忆的深处。如果前方将是艳阳高照，那就尽早将它唤醒，让它在双方的呵护下澎湃出幸福的声音。

爱情需要磨合。孕育爱情的过程，便是两个个体相互适应、相互修正的过程。在这个过程中，如果真的感觉到累了，那就先让爱情休息。不是在冷静后勃发出新的生机，就是在清醒后各奔东西。

无论怎样，对于爱情，拥有是幸运，失去了也是福分。

    之前讨论过QTP和QC结合的新测试方式，BusinessProcessTest。
    这种新型的自动化测试思想的出现进一步划清了测试分析，框架勾践人员和测试实现，执行人员之间的分工。但是，新兴的东西总是有它自身的一个不断改善，优化的过程的。BPT也不列外。
    如果你是个QTP比较熟练，已经尝试过BPT测试的工程师，那么你就会发现，BPT虽然对于没有开发经验的测试执行人员来说是个比较容易上手，实施的自动化测试实现方式。但是，它的弊端也是比较明显的，首先是离不开Component开发人员的修改，完善，实施人员基本上没有多大人员去进行错误的排查和debug。
    不过，这个问题，如果在被测软件稳定的情况下基本可以忽略。
    但是，随之而来的是BPT的效率，一个Test Case如果是由多个Component组成，那么每个Component之间的衔接时间消耗是十分可观的。特别是都某些Component中还由许多Interation组成时。
    QTP不会优化BPT的执行过程，它只会在一个Component需要执行时去跟QC通信，然后下载，初始化，再执行。我测量过每个Component执行结束后到另一个Component被下载再启动执行的时间，一般可以达到5秒以上。这样如果出现n个Component的话，时间就是5（n－1）秒，再乘上Case数量，就是个十分巨大的时间损耗。
    我们会考虑，QTP能否实现多线程模式，在第一个Component执行的同时，后台自动下载下一个Component以提高效率，暂时我还没找到从使用者角度的实现方式。
    但是，从我们的角度，我们可以避开Component的前后衔接，也就是说，换一种思路，BPT结合Function的方式，进行优化。也就是说，我们原本的方式是一个业务Step一个Component，但是现在我们可以尽量减少Component，增大step的粒度，把原本某些Component用Function函数来实现，这样，在考虑业务理解粒度不至于被破坏的情况下，效率就会大大提高了。
    自然，这样会导致单个Component的Parameter数变大，但是只要有清晰的描述，这个代价还是值得的！

    软件生命周期都学过吧，发布交付前那段时间是测试工程师的噩梦啊！
   
    一般的项目开发都会拖延进度，这是一个不争的事实了，而且不管deadline怎么延后，总有那改不完的defect让开发们抛头颅，洒热血，改来改去，项目经理看不下去了，定了个死限，deadline真的要dead了，开发急了，测试估计要撞墙了。
   
    快个把月没写东西了，就是被这档子事搞的，本来还有一周的时间留给我测试，回归。一夜下来，头给了个噩耗，今天晚上，发布，要全部测完，这时候我才知道，热锅上的蚂蚁其实每一个都可以去当敢死队，显示火烧屁股，然后糊了，最后焦了，就算成灰了也达不到高质量的测试效果啊。只好把自己超频使用，那个叫疯狂啊，奔三超到双核。

    还不得不和谐掉一些费时费力的回归，午夜，总算是基本完成任务，看着天上那又大又圆的月亮，第一次感到劫后余生的快乐。

    如果上天再给我一次机会让我选个期限，我希望测试的schedule是1万年！

    现在也还没消停下来，我负责的package是见公婆去了，兄弟姐妹们的package还在难产中，到处救火，做IT的，不加班那叫没见过世面，加少了还被人看不起呢！

    Plus：加多了也没加班工资！

    有些事情还没讲完那就算了吧.每个人都是一个国王,在自己的世界里纵横跋扈,你不要听我的,但你也不要让我听你的。

    很欣赏这个信念，不过，每每到我自己，我却只有让它在脑海中成为流星的尾巴，就算闪，也是那么地微弱不可见。

    唉，我真是个老天眷顾的傻男人，莫名其妙地，我上上周逃课的事情就东窗事发了，老婆比以往成熟了很多，这次没有兴师问罪，倒是时不时给我点暗示：“小子，做了什么坏事，自己自首，坦白从宽！”

    唉，这辈子我注定做不了坏事了，不过老实说，这次是在郁闷中死亡，死后诈尸也不知道老婆咋知道那么快的，算来看我博客的人用大象的脚趾数也出不了她认识的人。

    不在沉默中死亡，就在沉默中爆发，用来形容女性也是沾点边的，对于生活而言，女性往往是秤砣，而当游码的大多是男性，起码我就是。去揣摩生活重心的所在，去平衡生活中不可避免的矛盾，化大事为小事，预测潜在的不稳定因素，防范于未然，这就是游码的生活方式。

    也挺不赖，怪不得我做来做去，最后做了自动化测试这一行。提高生活质量的测试工程师！

 

    奔三的年纪，早早地成家，算是对女性有点那么自信的小小了解了。

    女孩子比男孩单纯，普遍上，所以市面上大多是“负心男”，更多的是“怨女”，这一点从本人纯小女人的老婆身上崭露无疑。

    作为男人，你对老婆得坦白，得实事求是，得通透到让她对你放一百个心，因为女孩子最大的本事就是小事化大，以片面盖全面了，一次的小失误可以让她们当N久的呈堂证供，可以让她们在不开心的时候否定你所有的优点！

    呵呵，可能描绘过头了点，女性看客请自行降温，需要补充的是，当然也存在特善解人意，特会审时度势乖巧伶俐的男性眼中“极品”，但话说回来，真正完美的东西，可能你拥有了也就会体会到，完美也就是一种不完美，难道你一个大男人，喜欢从一个女人身上感受到“安全感”，算了，还是回忆下童年吧！一样可以找到被呵护的感觉。

    女人是水做的，恩，水柔，水不可测（限于性情）；但水也简单，0度变冰，100度变气，相对给个不漏的空间，水永远是那么点。

    这个不漏的空间，看我们怎么把握了。银婚，金婚，钻石婚，不是随随便便一张小纸片就可以成就的！

    比较认可的一点，男人别撒谎，女人对欺骗的容忍度是吹弹可破的，这一点不用多做说明，智商90以上身体健康的人基本都可以理解。

    不过有时候，男人不得不撒点小谎，善意的谎言有时比100％诚实更加能诠释生活的美好。

    就拿自己来说吧，老婆是个顶真的“小女人”，对你给予厚望，匀出家庭开支给你去充电培训，可是实在太累，2个星期重压工作之余已经完全大脑思维混乱疲惫，充不进任何东西了，直接说逃课吧，怕伤了对方心，于是呢，取了个折中之法，早上去听了半天比较喜欢的听力课，中午开始翘课，想找个舒服安静的地方好好休息一下，

    结果呢，10块钱电影票的平安信用卡今天停用，去朋友那又太唐突，得，最后只好到初中老同学的网吧去找个雅座了。

    老天估计是雌的，对我们男人就是那么苛刻，正休息得怡然自得的时候，老婆一个短信过来“我在八佰伴逛街，你什么时候下课”

    唉，看来男人想撒点小谎都那么累，只好收拾行囊，再次坐车赶回培训点，凑着时间，装着很累的样子再给老婆一个甜甜的“苦笑”。

    继续履行老公的义务，陪逛街！

    。。。。。。plus，有时候，圆一个谎，比撒一个谎累多了，善意的，善意的！

    再加一句，如果哪位看客是我老婆亲信，请告诉你自己“我什么都没看见”

    On board已经2个多月了。

    大姐头交给我一个面试任务，被面试的是一个小我两岁的女孩子，呵呵，挺新鲜的感觉，想想3个月前我还在被面试的位置上忐忑不安呢。

    早上10点，由于我前面一轮开发技术面试官临时有会议，我被提到了首轮；拿了她的简历，下一楼找到这个女孩子，带她到指定的面试会议室，嘱咐她稍等会，不用紧张，自己去拿笔记本了。

    是个腼腆的女孩，不过给人的感觉是挺容易接近的，合适做测试这行，第一感觉。

    我先给她介绍了下我的面试流程，先英语面试部分，后中文细节部分。（这是从我们大姐头面我时学来的套路）

    我让她英语介绍下自己以及参与的项目，她可能有些紧张，准备不是很充分，直接上来有些口齿不清晰，在我的引导下逐渐自然流利了很多（我善于捕捉别人想表达的隐含语义）。

    在我不时地穿插提示以及提问中，口语面试部分持续了25分钟左右，甚至结尾还和她谈到了动漫（我的最爱），呵呵，也是个爱comic的女孩子，喜欢犬夜叉！

    气氛谈开了，顺利进入了主题细节部分。

    参看她的简历，我着重问了她的测试方面理论基础，以及实际运用，流程，案例编写方法（她没答好，主要是没受过这方面培训），思路，相互交流，自动化测试技术（她还不太熟悉修改脚本）。

    顺带我过了数据库基础知识和java方面的几个小问题。（她做过java开发）

    其中有4层左右问题可能出乎她的预期了，她没有答好，又开始显得局促不安起来，搞得我反而象做了坏人一样开始强调“没关系，不用紧张，实际运用能有快速求助和解决问题的能力就行”。

    不知不觉我面了她50分钟左右，最后让她对自己的性格进行一下总结，她给了我挺诚恳的描述：

    “对投缘的人，也就是合拍的人会很热情；但不投缘的人她很被动，而且实际生活中被动的机会多！”

    再次叮嘱她不用紧张后，我把面试权移交给了开发组的小左，再给大姐头反馈了下面试过程和自己的看法，Over，顺利完工。

    （隐约感觉这女孩子可能通不过F2F面试，但还是祝她好运吧，毕竟我们组的女性资源太希缺了）

    使用QTP对报表中的webtable内容进行正确性验证。

    基本思路是：

    一：使用getcelldata（i，j）的方法遍历webtable把表格内容存入一个数组中，一般为二维数组

    二：使用数据库连接组件ADODB连接后台数据库，使用数据结果集对象保存select查询结果，也是一个二维数组

    三：此时区分是否需要验证排列顺序，如果需要，直接对两个二维数组进行一对一遍历比较

    四：不需要验证排列顺序，或者顺序无法控制的情况下，我们需要对显示内容和查询预期内容进行比较，这时候牵涉到两个结果集的数据顺序问题，如果采用单对多遍历的情况，效率会十分低。

    这时候我们换一种思路考虑，既然是验证内容，那我们就可以把二维数组的验证转换成排序一维数组比较，实现方式是，采用join方法将二维数组的每一行转换成一个字符串（内容没有变化，只加入拼接符），两个二维数组进行相同转换，成为两个一维的字符串数组。

    然后使用快速排序法对两个一维数组进行一次排序，同样的机制下，如果原本内容相同，那么排序出的内容也应该相同。然后直接进行一维数组一对一比较。

    下面是vbs的快速排序代码，合适数字和字符串数组：

Public Function QSort(ByRef ReArr, ByVal head, ByVal tail)

'ReArr 是待排序数组， head和tail是该数组的最小下标和最大下标
Dim lef, rig
Dim pivot

If head < tail Then
 lef=head
 rig=tail
 pivot=ReArr(lef)
 While (lef <> rig)

  While (lef < rig and ReArr(rig) >= pivot)
   rig = rig-1
  Wend
  If lef <rig Then
   ReArr(lef) = ReArr(rig)
   lef = lef+1
  End If

  While (lef < rig and ReArr(lef) <= pivot)
      lef = lef+1
  Wend
  If lef <rig Then
   ReArr(rig) = ReArr(lef)
      rig = rig-1
  End If
  
 Wend

 ReArr(lef) = pivot
 call QSort(ReArr, head, lef-1)
 call QSort(ReArr, lef+1, tail)
 
End If
End Function

孩子快抓紧妈妈的手

去天堂的路太黑了

妈妈怕你碰了头

快抓紧妈妈的手

让妈妈陪你走

妈妈怕天堂的路太黑

我看不见你的手

自从倒塌的墙把阳光夺走

我再也看不见你柔情的眸

孩子你走吧

前面的路再也没有忧愁

没有读不完的课本

和爸爸的拳头

你要记住我和爸爸的摸样

来生还要一起走

 

妈妈别担忧

天堂的路有些挤

有很多同学朋友

我们说不哭

哪一个人的妈妈都是我们的妈妈

哪一个孩子都是妈妈的孩子

没有我的日子

你把爱给活的孩子吧

妈妈你别哭

泪光照亮不了我们的路

让我们自己慢慢的走

妈妈

我会记住你和爸爸的模样

记住我们的约定来生一起走

    这次整理一些在整个研究过程中出现的问题。
    一、由于Business Component需要QC和QTP协同工作，所以我们没办法单独用QTP对Component进行调试，除非拷贝代码到本地Test，然后将所有Parameter部分实例化，可以进行调试；或者就是打开QC，用QTP连接QC后打开Component，但这时又涉及到锁定机制，也就是谁先开，谁锁定，后开的只能为只读方式，很麻烦。

    二、调试interation在单独Component下无法实现。

    三、由多个Component组成的Case在QC调用远程PC进行运行时效率低下，每一个Component都会在被运行前实时下载一次。一般一个10个Component的Case会在3－4分钟左右（视Component复杂度定）。

    四、最郁闷的部分，由于是QC总控，QC的Test Lab只返回粗略的结果（pass or fail），细节results部分被存在QC的数据库中，但是当我们想要用QTP打开results进行错误定位时，Results View一直时downloading状态，无法下载。
    这是QC和QTP就BPT测试的一个Bug，暂时还未解决！

    这个问题可以用Report Manager（一个第三方QTP插件）进行人为测试Log记录！

    五、使用QTP对web进行测试时，请务必保证QTP现行打开，不然会有很多对象无法识别。

    六、有时候web应用开发人员不一定会给所有html对象一个清晰明确的定位属性，比如唯一的name，唯一的html tag/id，这个时候我们可以考虑QTP的测试对象属性，即同类对象的index，结合顺序和步进，可以解决某些无法定位问题！

    待续

    我有看新闻的习惯，这几天，我看得心痛！会痛很久！

    过去3天了，灾后抢救的黄金72小时已经过去，这预示着四川还未脱险的兄弟姐妹们的生活希望越来越小，这些人中，很多都是孩子。

    初三男孩（马健）花了4小时用双手刨出了班里最小的女生（向孝廉）；幼儿园老师用自己的身体为孩子挡住了倒塌的墙壁，孩子获救了，老师永远地去了；倒塌被掩码的同学们相互鼓励，一起唱歌激励自己求生的意志（北川一中高一）；坚强的三岁小孩用自己求生的意志爬出废墟（申小玉），但她的父母已经永远离她而去；被救女孩的心声：“千万别截肢我还要养活父母呢”......

    这一幕幕让人心碎的情景，冲击着我全身上下每一段神经。

    我也有孩子，我女儿3岁了，那些孩子中小的比她还小，却毫无选择地被迫经历了这与死神搏斗的过程，他们中的很多人，已经再也不会见到给自己梳辫子的妈妈，用胡扎子闹他的爸爸。

    很多成年人，不得不经历这老送少，亲人失去亲人，失去子女的打击。

    3天了，每天早上我都会看着新闻介绍流泪。

    传媒们，这些日子，少播些娱乐搞笑的节目吧，大家没心情看的，我，去掉了我博客的热闹音乐；

    爱国青年们，这些日子暂时放下那遗传基因中的仇日情节，暂时忽略那些支持雪山狮子旗的无知国外人权组织；

    尽我们自己的每一份力，去做点什么帮助我们的兄弟姐妹。

    捐款，捐物，献血，祝福，在心中默默的祈祷，也是一种支持。

    51算是我人生中比较重要的一个驿站，我是上海26期的，如果可以，如果大家支持，我们每一期每人每个月从我们今后的工资中匀出50元、100元，去供一个灾难中失去双亲的孤儿生活，学习，直到他（她）长大成人。

    我想，这样做，不但对他们有很大的帮助，对我们自己，生活中，工作中，多一份牵挂，多一份温馨的感觉，也未尝不是件利人利己的事！   

记者10:07:29
现场简直不能看了

记者10:08:33
年过花甲的总理已经哭得不成样子了

记者10:10:16
刚刚挖开的地方又塌方了

记者10:11:24
这倒霉天气还在下雨，现在一线的军人已经被下达死命令，必须冒雨解救

记者10:11:30
我就在现场

记者10:11:56
我现在是在都江堰市

记者10:13:24
交通已经瘫痪了，人员和物资很难运进去

记者10:13:47
汶川现在还不让我们去

记者10:15:21
汶川的交通完全封闭了，现场到底怎么样我不知道，不过早上总理指示军队不管有多大代价，必须进城

记者10:16:03
倒霉天气在下雨，飞机几次都不能降落，伞兵马上就要起飞了

记者10:17:3
飞机在汶川空投物资了

记者10:20:06
被压在废墟下的300多学生现在很危险啊，刚才一次的营救又失败了，现在总理在现场组织再次营救。

记者10:20:47
啊 总理摔到了，

记者10:21:35
照片我正在传给北京，不经过审核的是不允许发布的

记者10:22:21
我和几个同行现在开了9台电脑，同时在传消息

记者10:22:37
还好有QQ

记者10:23:39
突击队又上了

记者10:25:04
如果你现在看见老爷子的样子，你马上就会哭的

记者10:26:40
老爷子的手臂受伤出血了，他把要给他包扎的医务人员推开了

记者10:27:09
好消息，发现一名学生了

记者10:28:00
总理跑到塌方点了，在帮忙呢

0:39:19
由于桥梁倒塌，彭州市10万群众被堵在山中，救灾人员和物资无法运入。已经出现泥石流迹象

记者10:41
总理电话里大喊，我不管你们怎么样，我只要这10万群众脱险，这是命令。他把电话摔了

记者10:41:33
头一次看见老爷子这么厉害

记者10:41:54
汶川现在还没通知去，估计情况不是很好

记者10:42:16
我现在在通讯帐篷里

记者10:43:54
汶川最新消息，雨开始小了，空投物资已经扔下去了，空降兵已经在外围机场登机了

记者10:45:19
现在所有的国外记者都在关注号称中国最精锐的特种部队首次公开亮相

记者10:46:50
总理现在和登机部队领导说话

记者10:47:41
总理说，我就一句话，是人民在养你们，你们自己看着办

是人民在养你们，你们自己看着办！

    我们使用QC、TD的时候，在一次编写完测试需求的时候，如果想要在众多项中间插入一项，这个时候就会觉得有种无从下手的感觉。

    因为QC支持的拖动是处理上下层归属的拖动，即可以从该项下层拖动项到上层使其成为同级需求项。

    QC不支持同级间的显示顺序拖动，但是利用上下层拖动我们可以间接完成我们的要求。

    比如，1－10项需求项，我们需要在第6项添加一项，后续的自动顺延一位，这个时候我们可以把7－10项用ctrl一起选中，拖动到6项下成为下层需求，然后添加需求项7，再同时选中6项下层的原7－10项，拖动到原上层需求项上，这时候QC会自动将7－10添加在新添加的需求7之后，再改动一下序号就可以达到我们的要求了。

“我不是个随便的人， 我随便起来不是人”

“秃驴， 敢跟贫道抢师太”

“我踢了你一脚，所以我飞了”

“长个包子样就别怨狗跟着”

“老太太看完黑人百米赛后,抹着眼泪说:吓死人!几个挖煤的跪成一排被枪毙,没瞄准就开了枪,娃儿们吓

得那个跑呀,绳子都拦不住哇!”

“怎样把小杯可乐变成大杯?念大悲(杯)咒”

“走别人的路,让别人无路可走”

“学问之美，在于使人一头雾水；诗歌之美，在于煽动男女出轨；女人之美，在于“蠢”得无怨无悔；男人

之美，在于说得白日见鬼”

“有一天，我对你说你是猪，你说：我是猪才怪。于是我便开始叫你猪才怪。终于有一天你忍不住在众

人面前大声宣布：我不是猪才怪！”

“他的刀是冷的，剑是冷的，心是凉的，血是冷的，靠，这人不死了吗？”

“我吃的盐比你吃的米还多呢？那是你口重；我过的桥比你走的路还多呢？那是你懒的动”

“上帝把所有人都骗了，因为地狱才是最美的！佛知道真相，所以佛说：“我不入地狱，谁入地狱？””

“”

    BPT的主旨是封装，也就是开发概念中的模块化重用，这种思想需要在我们设计Component的人员大脑中存在，我们设计Component框架的时候需要把握的就是尽可能理出同类项。

    就拿一个报表系统的filters的输入界面来说，我们假定该filters是基于web的，也就是html形式的filters，BS架构，一般此类prompts会存在多行输入选择项，例如：

    年龄段：XXXX

    节目类别：XXXX

    节目名称：XXXX

    地区：XXXX

    开始时间：XXXX

    结束时间:XXXX

    等等，在我们设计的时候，我们一般的思路是会将整个filters输入整合框作为一个Component，恩，这种思路没错，但是我们如果进一步划分同质项，我们会发现，每一个输入行可以作为一个同类别的元素，这样我们就可以考虑将一行作为一个Component，正是由于html标签的支持，使得我们可以根据innertext对每一个输入框进行定位，从而进行输入。

    估计有人会说，这样下来一个业务流程，该filters输入部分就需要多达6次component调用，是否化简为繁了。

    这时我们就可以应用到Component的一个特性interation了，我们可以在QC的test plan里面设计案例时候直接在参数输入界面里面添加interation，也就是多组参数，Component可以自动对该多组interation进行循环，类似于单机test的datatable控制，而在我举的这个例子中，就可以只用一次Component，添加6组interation就实现了整个filters的输入了，而且该种设计方法十分灵活，具有可扩展性，能适用于今后filter行数增加减少的情况，而如果整个设计成一个Component，万一filter行数改变，我们的Component也需要跟着改变了。

    flight小程序其实没有办法诠释BPT测试中Component重用、复用的精髓，因为定制性不够强。

    而当我们面对报表型工具的测试时，Component的作用就开始显现出来了。

    比如说一个带权限登陆的医院报表系统，表与表直接还存在着进一步细化的关系，我们进行业务流程测试时就需要在底层框架架构时就考虑清楚Component的划分尺度，不能太大，那样容易丧失重用性和灵活性；也不能太小，太小造成的后果就是案例的构造是否繁琐，输入参数复杂。

    一般来说，我们会把登陆单独作为一个Component；然后分析所有子表（显示表）之间的相同点和不同点，划分出几个同类项表，每一个同类项的表格基本格式一致，然后对应每个同类项表格定制一个Component；再需要分析流程路径处理，如果存在共通性，比如以相似方式进入detail表，我们就可以把该路径动作也定制为一个Component表。

    至此我们基本上已经把底层骨架搭好。Component的动态灵活性调整下一次再分析。

    最后就是案例设计了，我们只需要根据方法进行案例的理论设计，然后拖选相应Component（可以重用，用不同输入，不同开关进行控制），组成一个个case，就可以在QC中进行自动化测试了。

    由于QTP脚本中涉及到十分长的Sql语句（近30行），所以十分痛苦地觉得一行里写难看到无法容忍，遂找寻QTP脚本中的命令分行连接符。

    QTP脚本就是VB脚本，所以直接使用VB中的行尾加上“ _”（空格＋_），就可以将几行连成一个命令了。

    但是另一个问题又来了，30多行的SQL语句，由于是作为整个字符串加入脚本，所以必须在每行SQL的行首添加“ ，在行尾添加”& _，用来连接所有分句为一个完整的SQL语句。

    知道UltraEdit有列功能可以方便地修改所有列，用该功能我解决了行首的问题，但行尾我冒烟了，根本不对称啊，没办法，只好想其他招数。

    想起来文档编辑的常用招数“替换”，于是CTRL+R 调出来替换(Replace)窗口,选中"使用正则表达式".然后可以查找 ^p(或者^n,如果是Unix 文件),用”& _^p(或者”& _^n)进行"全部替换"即可.补充一点，如果是 MAC(Apple) 类型文件,则换行符号为 ^r 。

    至此，大功告成，今后的长命令连接都可以套用该思路进行格式化的优化了。

    Mercury从测试工具系列8.2就提供了BPT的测试思想和实现流程，只是我们测试人员还没有深入地对这种新型的测试思想进行过深入的探讨（当然，海龙老师和文广老师已经是先行者了）。

    由于项目需要使用BPT进行自动化测试，测试框架和底层Component建模任务就落到了我和另一个同事身上，开始对BPT进行现学现卖了。

    BPT不能算是一种新型测试方式，它只是一种新的测试思想，它将整个测试参与角色定位为两类人：

    一类是测试工程师，另一类是业务工程师。

    业务工程师不用熟悉脚本，不用去理解Component的构建（当然他也可以参与构建），他们的主要职责是使用已经建模好的所有Component，也就是被测对象的操作步骤零件，进行实际业务流程处理的案例拼接，设计完成充分，有效的案例集。

    就拿附带小程序flight来说，原本我们的登陆步骤起码需要四步骤：

    1.打开程序，出现login窗口

    2.输入用户名

    3.输入密码

    4.点击确认

    而在BPT中，我们可以把整个登陆打包成一个Component，它只需要测试案例设计人员拼接案例时拖拽进案例步骤，而后在实际运行时给予两个输入就可以执行（注意，这里注重的是重用性，也就是说，该登陆Component在今后所有的BPT案例里都可以选择复用，而不用重新录制或者写脚本）。

    BPT的执行一般正确流程是由QC远程调用QTP来运行，参数的输入在QC段点击Component上的输入参数列表就可以实时输入了。

    刚接触时，总想使用business component，但实际上对我们测试工程师来说，该对象的定制性实在太差，它只适用于很简单的对象操作，对于逻辑控制，判断等操作显得力不从心，从我的角度来看，它的存在只是为了业务工程师的Component自行设计。

    我们关注的应该是scrīpted Component，这才是可以充分发挥我们脚本定制的利器，实行的角度和粒度不同，但最后封装完毕呈现给案例设计者的其实都是同样的接口，所以我这边基本上忽略了business component，今后的研究偏重于scrīpted Component，当然，其实只要你后者熟练掌握了，前者也就无师自通了。 

    某些人就是那么讨厌，异性也不例外。

    喜欢和人作对的人到处都是，因为什么我不知道，反正让我糗的人我曾经也没放过她。

    什么事情记不清了，是个女生，后来为了报复，找了个暗恋她的哥们，拍胸脯很man地做义气状：“兄弟，痛苦吧，我帮你！”（该兄弟语文不好），于是装思考样，替他写了首“情诗”

    “你温柔的眼眸，
     是我灵魂的归宿。
     大滴的泪珠，
     便是你走后我的全部。”

    结果......哥们成了，谢了我一顿搓。

    “笨妞”！！！！！

    怎么就没看出来是藏头诗呢，哎......

    活着，很快乐。

    很奇怪的,坏的事情的影响,力量总是比好的事情强大,比如说魔教一般就一个,也足够折腾正方7帮18派了.坏消息,八卦,想封锁,它反而偏偏上头条,也总能吸引群众的眼球.

    再说人的思维,心情;一般怀心情总是占压倒性优势的,你开心了一天,忽然一个沮丧的消息袭来,马上你就腌了,而且效果显著,经久不衰,不让你郁闷个够誓不罢休;而好消息的作用,实效,往往就是那么短暂,片刻的兴奋,然后马上又开始担心这操心那.

    人,能不能让自己消停些,别自己折磨自己.思想这东西还不是自己大脑决定,所以,学会让积极,开心的心态掌控主导地位,是能让你一辈子受益的好生活方式.

    郁闷了,伤心了,别带到工作上,学习上,到了公司,到了学校,看到同事,同学,把烦心事放一放,反正这时候多想也解决不了问题.马上融入到积极,上进的工作/学习状态中去.难保,等到下班,原本烦心的事情,峰回路转了.人的社会是群居的社会,所以你遇到的问题一般不是你单单一个人就能解决的问题,别想着一个人抗,自己力挽狂澜,你没那么伟大,super man也有被困的一天.

    说起来容易,做起来难,是啊,要不然怎么还那么多社会问题呢,但反过来想想, 这也不算什么mission impossible, 都是思维方式,那个占主导又不是板上钉钉的事情.

    闲扯了那么多,下了.

    忘了推荐下好心情的俏皮歌了--

    旺福:<两个恰恰好>

    http://mosquitohappy.cn/uploads/200802/23_172816_vv.mp3

    项目熟悉到了一定程度了,大姐头让我参加了report开发部分的review会议.

    事前做了做功课,提出了许多隐性需求,也可以叫做建设性意见.大姐头先过了一遍目,比较满意.

    结果提给开发人员,那个小妮子估计已经忙到焦头烂额了,除了些鸡毛蒜皮的文档错误接受了,建设性建议一概refuse,理由么,无非是修改成本太大,进度太紧云云.

    郁闷,估计她也郁闷.

    算了,为了今后的和平相处,我知道了现今项目进度的度了,自己拿捏准确点,争取做好工作之余,不得罪人!

    还好我天性很能处人,再加上好脾气不易动怒,这点还是很占优势的.