-
短小笑话
2008-05-16 14:36:06
校长的讲话
从前一个校长当着全校同学的面做报告~正准备说~突然一阵风刮来~把稿子全吹落在地~校长说我的话讲完了……
酷似唐僧的老师
高中有一老师姓江，酷似罗家英(演大话西游唐僧的)，我去问他问题，脱口而出：“唐老师，这题……”
蚂蚁怎么说？小明上完厕所回到教室跟老师说：“厕所有好多蚂蚁。”
老师忽然想到蚂蚁的英文ant这个单词，于是测试小明：“蚂蚁怎么说？”
小明一脸茫然……说：“蚂蚁他……什么也没说……”
Link URL: http://www.cnblogs.com/tester2test/archive/2008/01/02/1022711.html -
写段QTP脚本与大家一起分享
2008-05-16 14:36:06
Dim b,c
ic=datatable.GetSheet("Action1").GetRowCount
For i=1 to ic
Browser("新浪邮箱").Page("新浪邮箱").WebEdit("u").Set DataTable("user", dtLocalSheet)
Browser("新浪邮箱").Page("新浪邮箱").WebEdit("psw").Set DataTable("pass", dtLocalSheet)
Browser("新浪邮箱").Page("新浪邮箱").WebButton("登 录").Click
Browser("新浪邮箱").Page("经典再现_新浪邮箱").Link("这里").Click
a = Browser("新浪邮箱").Page("经典再现_新浪邮箱").Check (CheckPoint("jdzytony"))
b=abs(a)
c=abs(DataTable("result", dtLocalSheet))
If (b=c) Then reporter.ReportEvent micdone ,"成功:","执行与预期一致！"
Else reporter.ReportEvent micFail ,"错误：","第"&i&"个用例实际执行结果与预期不一致！"
End If
Browser("新浪邮箱").Page("新浪邮箱_2").WebButton("收邮件").Click
Browser("新浪邮箱").Page("新浪邮箱_2").Image("btQuit.gif").Click
DataTable.GetSheet("Action1").SetNextRow
Next
Link URL: http://www.cnblogs.com/tester2test/archive/2008/03/12/1101876.html -
团队管理101招〔转载〕
2008-05-16 14:36:06
转自：http://info.china.alibaba.com/news/detail/v5003013-d5382694.html 团队管理101招 时间：2004-09-01 07:00 来源： 管理社区 文字选择：大 中 小不论你是单一团队的领导者还是多个团队的管理人，团队管理工作都是你职权范围内一个重要的组成部分。在今日，集多重技术于一身的工作方法已逐渐取代阶层式的、缺乏弹性的传统工作体制，团队合作因而很快就成为了一种很受欢迎的工作方式。对于每一位参与团队管理工作的人而言，《团队管理》是一本不可或缺的重要读物。它向你提供了达成计划所需的技巧、建立团队成员间的信任、激发团队最大的潜能等方面的知识，为你能专业化地管理好你的团队创造了有利条件。另外，全书还散布了101条简明提示，为你提供重要而实用的讯息。后半部分有个自我评估练习，使你能正确地评估自己的领导能力，并针对自己的不足加以改进。 了解团队运作 团队合作是所有成功管理的根基。无论你是新手还是资深管理人，对你而言，管理好团队都是重要且具激励性的挑战。 1.切记：每位成员都能为团队作出一些贡献。 2.谨慎地设定团队目标，且认真严肃地对待它们。 3.切记成员间要彼此扶持。 4.将长程目标打散成许多短程计划。 5.为每个计划设定明确的期限。 6.尽早决定何种形态的团队适合你的目标。 7.努力与其它团队的成员建立强有力的紧密关系。 8.找一位可提升团队工作士气的重量级人物。 9.时时提醒团队成员：他们都是团队的一份子。 10.将团队的注意力集中在固定可衡量的目标上。 11.利用友谊的强大力量强化团队。 12.选择领导者时要把握用人唯才原则。 13.领导者需具备强烈的团队使命感。 14.奖赏优异的表现，但绝不姑息错误。 15.记住每位团队成员看事情的角度都不一样。 16.征召团队成员时，应注重他们的成长潜能。 17.密切注意团队成员缺少的相关经验。 18.应使不适任的成员退出团队。 19.找到能将人际关系处理得很好的人，并培养他们。 设立一支团队 成立一支团队是领导者的主要工作。确保你的团队有清楚明确的目的和足够达成目标的资源。要以开放和公正无私的态度对待团队成员。 20.设定具挑战性的目标须根据限期来考量是否合理。 21.设定目标时，考量个别成员的工作目标。 22.划的失败危及整体计划的成功。 23.坚持得到信息技术支持，它能为你提供确实需要的东西。 24.对待团队外的顾问要如同对待团队成员一般。 25.让团队的赞助者随时知道工作进展情形。 26.除非你确定没有人能够胜任，否则应避免“事必躬亲”。 27.不要委托不必要的工作，最好将其去除掉。 28.赋予团队自己作决策的权力。 29.鼓励团队成员正面积极的贡献。 30.肯定、宣扬和庆祝团队每次的成功。 31.找到易于让成员及团队了解每日工作进度的展现方式。 32.鼓励成员之间建立工作上的伙伴关系。 33.鼓励天生具有领导才能的人，并引导和培养他们的领导技巧。 34.绝对不能没有解释就驳回团队的意见，与此相反，解释要坦白，理由要充分。 35.确定团队和客户经常保持联系。 36.以自信肯定的态度让团队知道谁当家，但要预防予人来势汹汹的感觉。 37.想办法给新团队留下一个实时的好印象，但切忌操之过急。 38.倘若你要求别人的建议，抱持的心态不能只是欢迎就行了，也要依循建议有所行动。 提升团队效率 团队要达到应有的效率，唯一的条件是每个成员都要学会集中力量。你必须了解团队的能力，以确保团队的成功。 39.协助团队找出方法以改变有碍任务推展的团体行为。 40.找出可建设性地利用冲突的方法。 41.记住要在工作中穿插安排娱乐调剂身心──这是每个人应得的福利。 42.若有计划出错，一定要作全面性、公开化的分析。 43.如果你希望团队成员有问题时能毫不犹疑地找你谈，就要实施“开门政策”。 44.要求提出问题的人解决问题。 45.安排正式的和非正式的会面，讨论团队的工作进展。 46.使用不带感情只问事实的态度，是化解纷争的最好方法。 47.保持团队成员间的熟稔，以易于沟通。 48.设立交谊场所，让团队成员可作非正式的碰面交谈。 49.鼓励同事间自由的沟通活动。 50.建立最适合的通讯科技系统，并经常更新。 51.实施会议主席轮流制，让每个人都有机会主持会议。 52.尽可能多地授权给团队成员。 53.事先于会前发出议程，预留时间给与会者准备。 54.培养所有对团队有益的关系。 55.努力保持团队内外关系的均衡与平稳。 56.确定所有相关人士都能听到、了解好消息。 57.倘有麻烦在团队关系中发酵蕴酿，要尽快处理。 58.安排团队与机构的其它部门作社交联谊。 59.找出你与“大佬”保持联系的最佳通讯科技。 60.要对你在团队或办公室外接触过的重要人士作联系记录。 61.谨慎分派角色以避免任务重复。 62.找寻建议中的精华，且绝不在公开场合批评任何建议。 63.一定要找有经验的人解决问题。 64.分析团队成员每个人所扮演的角色。 65.脑力激发出的意见，就算不采用，亦不得轻视。否则，会打击人的积极性，创意的流动也会因此停止。 66.公平对待每个成员才能避免怨恨。 67.确定团队成员真正有错之前，都须视他们没有错。 68.告诉同事他们做得很好，这有助于激励团队士气。 69.尊重每一位成员，包括那些给你制造麻烦的人。 70.避免和团队成员有直接的冲突。 71.记住采用对事不对人的处事态度。 72.确定整个团队都能够从解决问题中学习经验。 73.先选择完成一些规模大的、可快速达成及有成就感的任务，以激励成员再接再励。 74.确信团队成员皆了解团队中的其它角色。 75.计算品质的成本之前，先计算失败的成本。 76.针对每笔预算及每项团队行动计划，设定重大的改进目标。 为未来努力 为团队设定新的、更高的挑战目标是团队工作中最令人兴奋的事情之一。可运用一些适当的技巧，推动团队向更大、更好的目标前进。 77.告知团队每位成员，在设定的标准中有哪些评量的项目。 78.确定所有改善措施及新订目标都持续进行着。 79.召开检讨会议前传阅所有相关资料及资料。 80.开检讨会时一定要避讳人身攻击。 81.记住关系会随时间改变。 82.避开低估或忽视坏消息的陷井。 83.每天结束时自问团队今天是否又向前跨出了一步。 84.倾听受训者关于训练课程的回馈意见。 85.找到有最好设备的最佳训练场所。 86.聘请顾问设立公司内部的训练课程。 87.利用移地训练时的用餐时间作非正式的计划。 88.每位团队成员都必须参与设定目标的工作，以促进团队合作及达成共识。 89.允许团队自行决定达成目标的方法，可激励团队努力工作。 90.确定目标能激发团队的斗志，如果不行，请改变目标。 91.一支没有“严峻”目标的团队，工作表现将不如接受过此类考验的团队。 92.设定奖励标准时，允许团队成员有发言权。 93.避免使用名次表，因为落后的团队成员将会感到自尊心受创。 94.指定某人监视市场上每一个相关变化。 95.随时准备作改变，甚至计划的根本要素亦包含在改变的范围内。 96.记住有某些人很害怕变革。 97.寻找能推动改革的团队成员。 98.每隔一段时间作一次生涯发展的评量。 99.记住：鼓励团队成员即是在帮助团队。 100.与团队同事就生涯规划达成一致意见，并给他们提供必要的协助。 101.团队解散后仍旧要与团队成员保持联系，因为你可能还会与他们再次合作。
Link URL: http://www.cnblogs.com/tester2test/archive/2008/03/16/1108774.html -
楼市十大卖楼花招曝光〔转载〕
2008-05-16 14:36:06
原文：http://bbs.house.sina.com.cn/tableforum/App/view.php?bbsid=271&subid=1&fid=1272&tbid=6870 1.楼盘报价 可疑的“起”字 “均价10000元/m2，现在推出30套保留单位，特惠价8000元/m2起。”这样的价格无疑是相当诱人的，问题是当有兴趣的买家到了销售现场时，往往就会被销售人员告知：“8000元/m2的单位只有两套，已经卖完了，但我们还有9000元/m2以上的单位，既然都来了，还是看看吧。” 还有一种方式是把“滞销房”包装成“珍藏版”，明明是长期卖不动的房子，一旦打出“珍藏、限量优惠发售”这样的口号，消费者便会乐呵呵地还以为自己拣了大便宜，没想到却是陈年旧货了。有关人士提醒消费者，看到“珍藏、限量版”这样的宣传时，一定要以电话询问的方式问清楚到底是新货还是旧盘，这样就能少跑些冤枉路，减少损失。 2.装修标准 “灌水”严重 目前标榜“随楼附送每平方米数千元超豪华装修”的楼盘比比皆是，到底是不是货真价实呢？相信不少买家都不甚了解。不过，当你宁愿放弃这高档装修而以毛坯收楼时，发展商是死活不肯照装修价减免其中的楼价的，顶多也就减个1000元/m2。可见装修标准“价值灌水”相当严重。 购买了某大型小区的张小姐担心地提出，在与发展商签订的购房合同附件里，没有明确标明装修标准，比如所用材料的品牌、规格、等级等，也没有明确说明装修标准参考的是哪一套样板房的交付标准。事实上，张小姐的担心是可以理解的。对此，有专家建议，买楼时不妨将样板房的装修标准细节都进行拍照，同时记录下所用材料的品牌、规格等，即使开发商到时以“发展商有权以同等标准之建筑材料及设备替代”作为搪塞，但买家自己握有证据，更有利于保障自己的权益。 3.距离10分钟？开车！ “地铁上盖”、“到天河只需5分钟”这些描述楼盘交通便捷的用词，相信不少消费者都耳熟能详，而楼盘的位置图也会把附近的标志性建筑物标示出来，让人感觉到楼盘离繁华市区或者交通枢纽相当近，但至于实际距离是多少，则大部分楼盘的销售人员都不会告知你一个真实的数字。当消费者按图索骥前往地铁站或者市中心时，往往“10分钟的距离”走了30分钟还未见到地铁口的影子。这就是所谓的“距离谎言”。 据了解，尽可能在语言和图示上缩短物业与市中心的实际距离，这种表述近年来经历了三个阶段的变化：开始是使用不实的里程误导客户，明明是10公里，楼书上却写成5公里；后来随着广告监管严厉了，就开始使用含糊的时间概念，譬如“10分钟车程到某地”；到最近，有些楼盘创造了一种“米计量表述法”，比如某项目距离地铁站是3公里距离，还是挺远的，但发展商会巧妙地转换计量单位，说成是“仅3000米”，买家一听，哗，真的“近在咫尺喔！” 为避免被误导，买家一定要记住“耳听为虚眼见为实”，最好进行一番实地察看，这样，楼盘的交通是否真方便就能了然于胸了。 记者 王荔珏 4.配套承诺 拍完胸口不兑现 许先生居住的小区已经交楼很多年了，但小区篮球场比标准篮球场小了至少1/4，这与当初楼盘销售时称“配有标准篮球场”的宣传严重不符。还有一些小区标榜有“园林泳池”，但实际上建成后却没有；说社区内配套有小学，但入住三年了小学还没开建…… 社区配套设施是买家购房的重要参考因素，所以大多数开发商都在宣传上作出很多承诺。专家提醒消费者，发展商对于小区配套设施的宣传单张及口头承诺都是没有法律效力的。如果买家很看重某项小区配套，必须在签订认购书之前，先看合同中有无关于此项配套的约定。如果没有，可要求发展商以书面形式写下来，以备日后有理有据维权。 5.公布业绩 开盘必“售罄” 一些开发商在报业绩的时候，往往喜欢用“开盘即售罄”、“开盘销售逾九成”的字眼，这在楼价涨势猛烈的时候表现得尤其明显，以至于不少买家一看销售数字，就生怕自己只能挑“货尾”了，于是买房简直如同“抢房”。当然这也不排除确实有楼盘卖得非常红火，但也有一些开发商刻意制造成交活跃的气氛给买家进行心理加压。 在如今市场成交比较清淡的时期，开发商的报业绩措辞仍会出现“九成”、“售罄”这样的字眼，但细心的人会发现，这和之前已大不相同，在“九成”或“售罄”的前面都会严谨地冠以“本次推货量”或者是“首批推货量”，意思是“我所指的并不是所有货量啊”。从这点改变看，也算是楼市信息披露中的一个进步吧。 6.“优惠”名目多 真假难辨 某大盘举行推盘优惠活动，但张小姐因为外出错过了时机。半月后，她惊喜地发现，优惠时间延长了，于是她赶紧下了定。但又过了一个月，她发现优惠还有，甚至比自己买的时候更便宜。她非常困惑：“这到底是什么‘优惠’呀？真的还是假的？” 在楼市前景不太明朗的现在，楼盘优惠可谓“一年四季都有”。不仅优惠时间延长了，优惠的品种也琳琅满目：有“倒计时的优惠、附送豪华装修、一口价、前N名买家可享受一定程度的折扣”等等。到底用何种方式买楼才最“着数”？事实上，即使买家不太符合某种优惠折扣的条件，但只要表现出足够的诚意，销售人员也可“顺利申请到应得的优惠”。就像“有机会获送10年管理费”的优惠，到底谁有“机会”？怎么才能获取？买家可谓一头雾水，恐怕只有发展商心里最明白。 7.销控表 红色的诱惑 楼盘在销售时都会贴出销控表，表上用红色圆点标明该套商品房已售。若购房者看到表上红彤彤一片时，往往会感到该楼盘的销售形势真是一片红火啊，能选择的商品房已不多了，只能欲购从速了。而实际上，销控表的红点也是有“水分”的，一些开发商有意将其中的一些商品房做了“销售控制”，将未售出的单位也标为“已售”，造成销售形势大好的假象，迫使购房者赶快下单。但同时也会留出一部分单位作为“未售”，以免买家失望而归。 8.手机短信广告 看上去很“抵” 时下，各种群发的楼市手机短信十分泛滥，其中不少短信广告存在着虚假成分。这些虚假的短信广告有个共同的特点，就是价格水分太大或者夸大优惠力度。楼盘通过这种价格低廉的广告手段来吸引消费者，根本无需为广告的真实性负责。而当消费者去到楼盘现场时，销售人员往往以“不知情”或者“优惠已结束”来搪塞。 9.“前10位” 永远的“幸运儿” “推出××套特惠单位”、“前10位购房者享受××折”也是目前楼盘销售惯用的促销手法。不过，这些所谓的“限量优惠”经常是“大众优惠”而已。例如“特价单位”几乎所有都是，其目的在于吸引消费者前来看楼。而经常看到的“前10位购房者享受××折”，其实只要购房的都会享受到折扣，不知情的消费者还以为捡了便宜呢。 10.Sales说：“有人也想要这套” “逼”买家下定的方法有很多，比如不给他们有充分考虑权衡的时间，让其匆匆购房；在与客户洽谈的时间里，售楼人员互相配合着打“假电话”，或假装成顾客，假装有很多人都想要这套单位的样子；或是在客户稍微犹豫的时候，马上把房子介绍给另外的购房者，营造紧张气氛，进行“逼购”，让购房者尽快下单。
Link URL: http://www.cnblogs.com/tester2test/archive/2008/03/19/1112534.html -
彭祖 [转载]
2008-05-16 14:36:06
原文：http://www.baidu.com/s?wd=%C5%ED%D7%E6 彭祖 开放分类： 神话传说、历史人物、寿星、隐士、道人 彭祖，传说中的养生家。据古代典籍记载，彭祖是颛顼的玄孙，相传他历经唐虞夏商等代，活了八百多岁。彭祖精于养生，《庄子��刻意》曾把他作为导引养形之人的代表人物，《楚辞��天问》还说他善于食疗。不过，一人享寿竟至八百余岁，显然是不可能的。据《史记��楚世家》载：“彭祖氏，殷之时尝为侯伯，殷之末世灭彭祖氏。”“氏”在上古多用作宗族的称号。可见，彭祖实际上是以其命名的一氏族，《史记》还记载了个彭姓氏族被封国于大彭等地。清人孔广森在注《列子��力命篇》“彭祖之智不出尧舜之上而寿八百”之句时说：“彭祖者，彭姓之祖也。彭姓诸国：大彭、豕韦、诸稽。大彭历事虞夏，于商为伯，武丁之世灭之，故曰彭祖八百岁，谓彭国八百年而亡，非实��不死也。”就明确说明了这种情况。但对于彭祖善于养生的种种传说历代并无异议，可以推想，由于彭祖这个氏族精于养生，族中长寿之人辈出，并以此而名闻于世，于是逐渐产出彭祖享寿八百这类的传说并流布于后世。故彭祖这个氏族可以说是上古时代一个有代表性的著名长寿家族。 详细资料���� 彭祖，一作彭铿，或云姓卅（jian）名铿，传以长寿见称。原系先秦传说中的仙人，后道教奉为仙真。彭祖姓卅名铿，于六月六日出生，其父亲陆终，母亲女馈，彭祖是是上古帝王颛顼的孙子(黄帝的第八代孙)。 帝尧的时候，他因为进献雉羹，尧便把彭城封给他，所以后世称他为彭祖，舜的时候，他从师尹寿子，学得真道，遂隐居武夷山。 到商代末年，已有767岁(或说有800余岁，古时60天为一岁，即今130岁)。尽管这么大年纪，可他仍不显衰老。他自幼喜好恬静，不追求名誉，不汲汲于世事，不刻意打扮自己，终日以养生修身为事。商王请他作大夫，他推托不了，只好应诺，却常常以有病为由，不上朝听政。他精通补导之术;常常服用水桂、云母粉、麋角散。平日沉默寡言，从不夸耀自己有道，也从不作一些诡惑变化鬼怪之事，以博取名誉。 他也常常四处周游，从不乘车马，即使要出外周游百日、数十日，也不带干粮，回来之后，衣食与平常也没什么两样。他也善于导引行气，经常从早到晚闭气内息，之后，揉擦眼睛，按摩身体，舐唇咽唾，才站起身来。有时身体疲乏不适，他就导引闭气，攻治患处，便其九窍、五脏、四肢以至毛发都气流通畅，身体又舒服如初。商王听说后，便亲自来向他问道，他闭口不语；给他数万金，他如数收下，全分给贫穷的百姓。 【相关传说】 传说，彭祖活到七百六十七岁，仍无衰老迹象，耳不聋，眼不花，背不弯，腰腿不疼。商朝君王派彩女询问彭祖长寿秘诀，彭祖回答：“欲举行登天，上补仙宫，当用金丹。其次，养精神，服草药，可以长生。”彩女又问他的身世，彭祖唉声叹气地说：“吾遗腹而生，三岁丧母，又逢战乱，流落西域，几百余年。”又说“他一生丧四十九妻，亡五十四子，屡遭忧患。”谁知又过了七十来年，有人发现他还在流沙国游玩，直至八百多岁才死。彭祖为啥能活八百多岁，而且能葬在彭村?还有一段有趣的神话传说。 当时，有一个叫采女的女子，也是个得道之人，懂得养生的方法，虽然有二百六七十岁，仍然象四五十岁的样子。 商王把她请到宫里，特意建了一所紫阁华屋，装饰上金玉，让采女居住。商王见彭祖不肯传道，就让采女前往，希望由此得知一二。采女便来请教彭祖延年益寿的方法。 彭祖告诉她:"若想登天升仙，需要吃金丹，这是太乙白日升所用的办法，但这个方法君王不能用。其次应该爱养精神，服用草药，可以长生，但却不能役使宠神��乘虚飞行。而如果不知交按二道，即使服药，也不能长生。我3岁盯，就失去母亲，又遭遇犬戎之乱，流浪西域，长达100多年，到现在已死去49个妻子，54个儿子。数遭忧患，和气已被拆伤，恐不久于少世。所闻浅薄，不足宣传。听说大宛山中有一位青精先生，已活了1000多岁，仍面如童子，日行500里"采女忙问，"青精先生是什么仙人呢？” 彭祖说。"他不是仙人，仅是一位得道者。所谓仙人，或能竦身入云，无翅而飞;或者驾龙乘云，上达天阶;或者化作鸟兽，游浮青云;或者潜行江海，遨翔名山。他们食元气，吃芝草，出入人间，而人却不知道，从不与俗流交接。他们虽能长生不死，但却远离人情荣乐，与麻雀化成蛤蟆没什么两样，都失去了自己的本真.我倒觉着,服吃甘脂，通阴阳，骨节坚硬，颜色和泽，老而不衰，延年久视，长存世间，不被寒温风湿所伤，不被鬼神众精冒犯，五岳百虫不来伤害身体，也不为喜怒所连累，这是最好不过的了。” 之后，又教给她房中之术。采女一一领受，回来又教授商王，商王一试，非常灵验。商王就想使此术为自己独家所有。便下令。传彭祖之术的人全部杀死，又想加害彭祖。彭祖便逃走了，不知去向，商王行彭谊之术，活到300多岁，面相气力如50岁的人。后来商王得到一个美丽的郑女这女子非常淫乱，商王淫荡过度，失道而死。 原来彭祖和陈抟老祖两人，都在天宫玉皇大帝身边主事。一个管着诸神的生死簿，一个管着功德簿。有一天，陈抟对彭祖说：“我劳累过度，想好好睡一觉。如有要紧事，你把我叫醒。”彭祖答：“好，你尽管放心睡觉去吧!”彭祖一见陈抟去睡觉，想乘此机会到凡间游玩一番。有一天，他代陈抟更换生死簿名单，发现他的名字也在上面。彭祖一想：不好，如果我到凡间被玉帝发现了，就会很快派人把我召回。他灵机一动，把生死簿上写有“彭祖”名字的那一页纸撕了下来，捻成纸绳订在本子上，从此，这个生死簿上，再也找不到彭祖的名字，他才放心地下凡去了。 彭祖流落人间，作了商朝士大夫。他先后娶了四十九个妻子，生了五十四个儿子，都一一衰老死亡，而彭祖依然年轻力壮，行动洒脱。当他娶了第五十个妻子后，就辞官不作，到处游山玩景，直到这第五十位妻子由当年的黄花闺女变成老太婆时，才定居到宜君县一个小山村。这时彭祖已八百岁了。有天晚上，夫妻俩睡在床上拉话，妻子问他：“我是快死的人了，我死后你再娶妻不娶?”彭祖毫不介意地说：“当然还要娶，不然谁陪伴我！”妻子又问：“你为哈一直不会衰老呢?难道生死簿上没有你的名字吗?”彭祖哈哈大笑：“我永远不会死的!生死簿上有我的名字，他们就是找不着。”妻子接着问：“那你的名字在什么地方?”彭祖一时得意说出了实情。妻子这才明白彭祖一直不死的奥秘。 这位妻子死后，脱下凡胎肉体回到天宫，向玉皇大帝诉说了此事。玉帝听后恍然大悟，命差神赶快去叫陈抟老祖。谁知陈抟这时还没有睡醒，玉帝只好另派二位差神下凡去找彭祖。 由于年代久远，派下来的差神根本不认得彭祖，找寻许久毫无音讯。这两位差神不敢轻易地回到天宫交差，只好遍跑人间，四处打问。一天，二位差神来到宜君县彭村，乘木匠吃饭之机，偷走解板大锯，到打麦场上使劲地锯一个碌碡，一下招来很多乡亲围着看稀奇。这时，彭祖也前来观看。人们七嘴八舌，议论纷纷，彭祖也因自己年事高，经历广，趁机讥笑说：“我彭祖活了八百岁，没见过有人锯碌碡。”话音刚落，二位差使把锯一扔，当场就锁住了彭祖。这天夜里，彭祖就去世了，享年八百余岁。 【厨行的祖师爷】 彭祖因为善于调制味道鲜美的雉羹(野鸡汤)，献给帝尧食用，被帝 尧封于大彭(今江苏省徐州市)。我国爱国主义诗人屈原在(楚辞��天问)中写道：“彭铿斟雉，帝何飨?受寿永多，夫何久长?” 这艺术地反映了彭祖在推动我国饮食文化进步方面所作出的卓越贡献。汉代楚辞专 家王逸注曰： “彭铿，彭祖也。好和滋味，善斟雉羹，能事帝尧,帝尧美而飨食之也”。宋代洪兴祖补注曰：“彭祖姓钱名铿，帝颛顼玄孙，善养气， 能调鼎，进雉羹于尧，封于彭城”。 彭铿是彭部族的始祖，以后子孙繁衍，主要是他的“雉羹之道”可祖，便尊称他为彭祖，他的后裔就叫彭祖氏。彭祖的“雉羹之道”逐步发展成为“烹饪之道”，雉羹是我国典籍中 记载最早的名馔，被誉为“天下第一羹”。中国烹饪史略9中称彭祖“是我国第一位著名的职业厨师”，而且是“寿命最长的厨师”，至今被尊为厨行的祖师爷。 【徐州和彭祖】 彭祖系黄帝之第八代孙，陆终之第三子。传说陆终娶鬼方国女蚩为妻，女蚩只有一乳，怀孕三年，孩子总生不下来。陆终只好剖开其左胁下，取出三个儿子，又剖开右胁取出三个儿子。其中第三个子��铿封于大彭国����彭城（今徐州市）。 徐州系中国历史文化名城之一，彭祖的事迹、遗迹甚多，城中4.6米高的彭祖塑像，白发银须、神采奕奕。还有彭园、彭祖祠、彭祖庙、彭祖、彭婆墓和彭祖井等遗迹。徐州作为历史文化名城，历代都是中原地区政治、经济、文化中心，与彭祖的经营，功不可没。历史上对于彭祖事迹的传说甚多，其中众所周知的是长寿，赢得八百长寿之声誉。后世之人都把彭祖作为幸福长寿的象征。 【史料记载】 关于彭祖的平生阅历，有如下史料可以说明。王逸著《史记 �� 五帝本纪》中云：老彭为尧臣，商武丁43 年已亥（公元前1282年距今3281年）大彭国亡。唐宰相系表云：颛顼帝玄孙大彭为夏伯，少康中兴（夏六代王）封其孙元哲于豕韦（今滑州韦城）至周郝王 时失国。由此可知，元哲之后代世袭韦侯至周止，历夏、商、周三朝。 又《大戴礼纪 �� 虞载德篇》云：老彭与仲傀并列，为商初之功臣，以一说彭祖802岁，商初已有672岁，至商七代中宗（即大戍王）时逝世。又一说彭祖逝世于二十四世孙之时 （跨入安世系彭文彬时），若一代平均以33年计算，二十四世则为入812年，但不足二十四世，享年802岁并非没有根据。至于彭祖一生不求功名利禄，只求 逍遥自在的事例不少。相传公元前4600年，彭祖和他的两个儿子彭武、彭夷隐居福建名山碧水之间，住于幔亭峰下，茹芝饮瀑，遁迹养生。 据《武夷山志》记 载：彭武、彭夷一生下地就成长起来，一陈春风吹过，他们就能呼喊爹娘，二遍春风吹过送来春雨浇洒，就能站立。彭祖用三片自己种的春茶泡水给他们饮，就能下 地奔跑。从各方资料推断，他们是一对弈生兄弟，系福建彭族始祖。后人便把此山命名为武夷山，直延用至今。相传彭祖隐居武夷山时，教人开垦荒地，种植粮棉、 花果、茶叶，挖井取水。据说他种的茶叶味道香淳，引来七仙 �� 钟离权、吕洞滨、曹国舅、何仙姑、李铁拐、韩湘子、蓝采娥。他们一致商定赐他寿享880岁。福建武夷山脉，毗邻江西省，主峰黄岗山，海拔 2158 米，是福建省第一高峰。彭祖与儿子的遗迹尚存，有坟墓和石碑，其中存放武夷山宫中的一座石碑上还可以看到彭武、彭夷的名字。现在的武夷山已成为国家级的旅 游圣地。在当年彭祖居住过的幔亭峰下建起了一座现代化的“武夷山庄“，有花园、曲径、亭台楼阁。据传说彭祖隐居于闽，后为避战乱，再度隐居四川名山（今彭 山县）至仙逝。后人将其居住的山命名为长寿山（也叫彭山）。为纪念这位杰出的彭族始祖也不知那个朝代在此设立彭山县。彭山遗迹有彭祖墓园、彭祖墓、彭祖 祠、彭祖仙室，室外内有石雕的寿星彭祖肖像，室外陈列八挂图案，历历在目。四川省彭山县人民上至政府官员下至一般百姓历年都到此庆祝彭祖寿星节。从上述遗 迹证明彭祖确实仙逝于四川彭山。而彭祖故乡徐州原先只有彭婆墓，没有彭祖墓，这也说明彭祖归老于四川彭山。至于后来的彭祖墓在徐州出现也许是后人为纪念他 而建的。 据《彭城志》记载：大彭由在徐州市城西三十公里，是古大彭人居住地。山北以称大彭村，大彭国都城在大彭由下。大彭由今称为义安山，海拔 262 米，今山北三里处大彭村以称大彭集，属铜山县夹河乡管辖。以据出土文物考证，大彭国应该是在龙山文化时期部落联盟的基础上建立起来的。大彭国最初的政治中 心可能在大彭村一带。随着人口的增加和经济发展，便迁移到环境更为优越的徐州市中心，建起原始村寨和城堡，作为政治活动中心，并且迅速发展，国力强盛。先 后助夏平定西河武观判乱，助商剿平邳人反判。根据目前发现的文物资料证实，徐州是大彭国的发祥地，而大彭村则是大彭国的诞生地。彭祖祠原来位于徐州城东北 隅，又叫彭祖楼或彭祖庙。北魏时徐州刺史元延明将它迁建于城垣东北角上。此楼恰好在汴（ 开封市） 泗之交汇处。 《神仙传》上的说法，这位卅铿“少好恬静，不恤世务，不营名誉，不饰车服，惟从养生沾身为事。” 郦道元的《水经注��泗水》曾有这样记载：“耸望川原，极目清野，斯为佳处也”。彭祖楼下有彭祖墓。至于彭祖祠内的彭祖井是带有传奇色彩的古 迹，相传此井泉如玉液，常饮此泉可以长寿。明朝一诗人马惠曾为“彭祖井”赋诗一首。 古井城边不记年，名留彭祖世相传。 玉沉汲虎人何在，金鼎蟠龙客已仙。 秋石苔浸秋雨积，梧桐叶落晚风旋。 谁能更把寒泉浚，一饮须教寿八千。 彭祖井旁竖立着十丈高的石碑，上书“彭祖井”三字，落款署名已看不清。现此碑已移到徐州博物馆的碑园内。有关彭祖井传闻很广，在北京的国子监内，有一块明 朝万历丁丑年（1577年）镌刻的“彭祖观井图”上面刻有彭祖观井的画像。彭祖腰系缆绳连着柳树，由书童扶持躬身观井，其战战战兢兢，如临深渊，如履薄水，图左上方有宋陈端题铭，赞扬彭祖处事小心谨慎，希望后世效法彭祖。现在，彭祖的遗迹已不是往日的模样。重修的彭园、彭祖祠、彭祖井在徐州市人民政府的 保护下，焕然一新。给旅游观光的海内外彭姓族人及其他旅游者留下的印象颇深。 《列仙传》载："彭祖者，殷大夫也，姓��名铿，帝颛顼之孙、陆终氏之中子，历夏至殷末寿八百余岁。常食桂芝，善导引行气。历阳有彭祖仙室，前世祷请风雨，莫不辄应。常有两虎在祠左右，祠讫，地即有虎迹云。后升仙而去。" 【彭祖的延年益寿养生法】 彭祖的延年益寿养生法大致有如下三个方面： 其一，注意锻炼身体。每日凌晨即起、端坐、揉目、按摩、砥唇咽液、意守丹田、吸气数十遍；然后起身、熊径鸟伸、运气发功等，他是气功的最早创始人，这套健身法，被后人写成《彭祖引导法》。 其二，是思想修养，他从不计较名利得失，不追求物质享受，情绪恬静而达观。殷王赠其万金，他用来接济贫困，自己无所留。不受“慎喜毁誉”所累，经常保持良好的精神状态。 其三，是生活习惯，他坚持顺乎自然，不伤害身体，冬天注意保暖，夏季时常纳凉，顺应四时节气，使身体舒适安康，重视劳逸结合，用脑切忌过度，衣着求适不求华髦，男女生活饮食合理调节，并说：“凡此之类，譬犹之水，用之过当反为害也。” 彭祖之死 古时人们祈望长寿，但又无法抗拒生老病死的自然规律，于是就虚拟出一个彭祖的神话。山西省长治市黎城的西井镇有个村子传为彭祖所居，且有彭祖庙，故得名彭庄。彭祖是中国的传说人物，据说活了八百多岁，妻子就娶了一百多个，仍然红光满面，精神焕发。他的最后一任妻子很想知道其中原因，就对彭祖撒娇说：“我虽然年轻，但身体却不如你好，请你把长寿的秘密告诉我吧，我们也好长世相守。”彭祖看着如花似玉的爱妻，一时高兴，就说：“告诉你也没用，是阎王爷不小心把我的名字从生死薄上撕下，做了纸捻子，所以我才活到现在。”其实，阎王早就在注意彭祖了，只是怎么也找不到他的名字，于是，就派了两个小鬼到彭祖所住村子的河里去洗炭。正好彭祖的妻子下河洗衣服，见有俩人在洗炭，嘴里还念念有词：“洗黑炭，洗黑炭，洗白黑炭去卖钱。”彭祖的妻子说：“我家相公活了八百八，也没听说黑炭能洗白。”俩个小鬼就说不信，于是，彭祖的妻子就把彭祖长寿的秘密告诉了这俩个小鬼，小鬼立刻报告了阎王，阎王找见了那根纸捻子，就派勾魂鬼把彭祖勾走了。老百姓大概对此也十分惋惜，就传开了一句顺口溜：“彭祖活了八百八，有话不该对妻子说”。 如果您认为本词条还有待完善，需要补充新内容或修改错误内容，请 编辑词条 参考资料： 1.http://www.ztdec.com/old/culture/xzzj/1qi/dxl/g/pz.htm 2.http://cn.netor.com/m/box200505/m50307.asp?BoardID=50307# 3.www.pengzu.org/ 4.http://www.39.net/zhongyi/diangu/150169.html 5.http://www.cctv.com.cn/program/xbxw/topic/west/C12405/20040914/102131.shtml
Link URL: http://www.cnblogs.com/tester2test/archive/2008/04/05/1137941.html -
我讨厌测试的10件事〔转载〕
2008-05-16 14:36:06
-
WINRAR 命令行语法[转载]
2008-05-16 14:36:06
WINRAR 命令行语法
[ 2006-10-13 23:33:44 | 作者: 碳酸氢钠 ]语法:RAR <命令> [-<开关>] <压缩包> <@文件列表...> [<文件...>] [<解压缩路径\>]
命令行选项(命令及开关)提供 RAR 创建及管理控制压缩包的控制。命令是一个字串(或单一字母)，命令 RAR 运行相对的操作。开关则设计来做修改RAR 运行的操作。其他的参数则为压缩包名称及要压缩的文件或要从压缩包解开的文件.
a 添加文件到压缩包。
示例:创建或更新现存的压缩包 myarch，添加当前目录中的所有文件
rar a myarch
c 添加压缩包注释。注释会在处理压缩包时显示。注释长度被限制为62000 字节
示例:
rar c distrib.rar
注释也可以从文件添加:
rar c -zinfo.txt dummy
cf 添加文件注释。文件注释会在给予命令 'v' 的时候才显示。文件注解的长度限制为 32767 字节。
示例:
rar cf bigarch *.txt
cw 写入压缩包注释到指定的文件。
示例:
rar cw oldarch comment.txt
d 从压缩包删除文件。请注意，如果此命令的结果是移去压缩包里的所有文件，则空的压缩包也会被移去。
e 解压缩文件到当前目录。
f 整理压缩包中的文件。仅压缩包中的文件比添加的还旧时才更新此命令不会添加新文件到压缩包中
k 锁住压缩包。任何会修改压缩包的命令将会忽略。
示例:
rar k final.rar
l[t] 列出压缩包的内容 [技术性的]。文件如同下 'v' 命令一样列出来，但排除文件路径。例如仅显示文件名。选择性的技术性信息仅在使用 't' 修正元时才会显示。
m[f] 移动到压缩包 [仅文件]。文件移动及目录结果，而该目录及文件在成功完成包装操作之后便删除。如果应用 'f' 以及或者加入 '-ed'开关，则目录不会移去。
p 打印文件到标准输出设备。
r 修复压缩包。压缩包修复由二个阶段所组成。首先，损坏的压缩包会扫描恢复记录(参阅 'rr' 命令)。如果压缩包包含先前添加的撤消记录，而且损坏的数据部分是连续性的，并低于 N*512 字节，N 代表置入压缩包内恢复扇区的数目，压缩包成功重建的机会是非常高的。当此阶段完成时，新的压缩包将会创建，叫做 _recover.rar。
如果损坏的压缩包不包含恢复记录，或者如果压缩包由于严重的损坏，而不能够完全地恢复时，第二阶段开始。在此阶段期间，仅有压缩包结构的重建，而要恢复失败 CRC 验证的文件是不可能，但是它尽可能的从损坏的压缩包架构中，可访问的部位来恢复未损坏的文件。通常这对固实的压缩包是有用的，在损坏的固实压缩包，经常，仅第一个文件可能在第二个阶段期间被恢复的。当此阶段完成时，新的压缩包将会创建，叫做 _reconst.rar。当恢复程序操作时，当可疑的文件出现的时候，RAR 会提示用户加以协助。
可疑的项目
名称: <可能的文件名>
大小: <大小> 包装后: <压缩过的大小>
将它添加到压缩包: Yes/No/All
输入“Y”把此项目添加文件 _recover.rar。
示例:
rar r buggy.rar
rr[N] 选择性的，多余的信息(恢复记录)可添加到压缩包中，也会造成压缩包大小些微增大，但在软盘失败或者其他数据流失的例子时，可以帮助恢复压缩包。
恢复记录可包含最多 32768 个恢复扇区。扇区的数量也可以直接以“rr”命令(N = 1, 2 .. 32768)指定。如果用户未指定，则将以压缩包大小自动的选择记录区值:恢复信息的大小大约是压缩文件大小总计的 1% ，通常允许恢复压缩包连续受损数据总计大小最多达 0.6%。也可以将它指定为压缩包大小的百分比，只要在命令参数后面附加百分比符号，
例如:rar rr3% arcname
如果受损的数据是连续性的，然后每一个恢复扇区都可以恢复受损信息的 512 个字节，然而在多重受损范围时，此值将会降低。
恢复记录大小的概算公式为 :<压缩包大小> / 256 + <恢复扇区数量> * 512 字节。
s[名称] 转换压缩包成为自解压缩包类型。结合自解模块的压缩包。
(使用默认模块 default.sfx 或在开关指定)。根据默认，WinRAR 使用在RAR 压缩包的 SFX 模块文件为 default.sfx，它必须与 winrar.exe存在于相同的文件夹中以及，Unix - 在用户的 Home 目录。
s- 从现有的自解压缩包移去 SFX 模块。
RAR 会创建不含自解模块的新压缩包，而原有的自解压缩包并不会删除。
t 测试压缩包。为了验证指定的文件，此命令会运行虚拟文件解压缩，但不会写入输出数据流。
示例:测试在当前目录的压缩包:
rar t *
或在 Unix 时:
rar t '*'
以当前目录开始，测试全部的子目录压缩包:
rar t -r *
或在 Unix 时:
rar t -r '*'
u 仅在如果压缩包中的文件比被添加的还旧时才更新。
v[t] 冗长式的压缩包内容列表 [技术性的]。
文件会以下列格式列出: 完整路径名称，文件注释，原始及压缩后大小，压缩率，上次更新日期及时间，属性，CRC，压缩方式以及解压缩所需的最低版号。当使用 't' 时，选择性的技术信息将会显示。
要列出全部压缩分卷的内容，使用通配符('*')来置于压缩包扩展
名，或者使用 '-v' 开关
示例:直接将压缩包内容列表(技术性的)导向文件
rar vt bambam >bambam.lst
x 以完整路径名称从压缩包解开压缩
示例:rar x -av- -c- dime 10cents.txt
从压缩包解开到当前文件夹，关闭 AV 检查及注释显示
开关(与命令结合使用):
-? 显示命令及开关的帮助。当未输入或者输入无效的命令行选项时也会显示。
-- 停止扫描开关
此开关会告知 RAR 在命令行已没有其他的开关了。它是使用在，
如果压缩包的名称或文件名是从“-”字符开始的时候。没有“--”
开关时，则会将此类名称当成开关来处理。
示例:
从当前文件夹添加所有文件到固实压缩包 -StrangeName
RAR a -s -- -StrangeName
-ac 压缩之后文件的“存档”属性将会被清除
(仅 Windows 版本有效)。
-ag[格式] 以当前日期产生压缩包名
当创建压缩包时，以格式“YYYYMMDDHHMMSS”附加到当前日期字串，
这对于每日的备份是有用的。
附加字串是由“格式”参数所定义，或者如果不存在时，使用
“YYYYMMDDHHMMSS”。格式字串可以包含下列的字符:
Y - 年
M - 月
MMM - 文本式的月份名称(Jan, Feb, 等)
W - 星期(文本)(星期起点为星期一)
A - 星期(数字)(星期一为 1, 星期日为 - 7)
D - 日
H - 时
M - 分(如果接续在时后面，则视为分看待)
S - 秒
所有其他添加压缩包的字符则不会更改。
示例:
1)使用默认的 YYYYMMDDHHMMSS 格式
winrar a -ag backup
2)使用 DD-MMM-YY 格式
winrar a -agDD-MMM-YY backup
3)使用 YYYYMMDDHHMM 格式
winrar a -agYYYYMMDDHHMM backup
4)使用 YYYY-WW-A 格式
rar a -agYYYY-WW-A backup
-ao 添加有存档属性设置的
(仅 Windows 版本有效)。
示例:
添加驱动器 C: 具有设置“存档”属性的所有文件到“f:backup”并
清除文件的“存档”属性
rar a -r -ac -ao f:backup c:\*.*
-ap 设置内部压缩包路径。当添加文件到压缩包，以及当解压缩时从文件
夹名移去时，将会使用与此开关结合的路径
举例来说，如果您希望添加文件 readme.txt 到压缩包 release 的
文件夹 DOCS\ENG，您可以运行:
rar a -apDOCS\ENG release readme.txt
或解压缩 ENG 到当前文件夹:
rar x -apDOCS release DOCS\ENG\*.*
-as 同步压缩包内容
如果此开关使用于压缩时，在当前添加的文件列表中不存在的压缩后
文件，将会从压缩包中删除。它可以很方便的与 -u 开关结合，用来
同步化压缩包及压缩的文件夹的内容。
举例来说，在下面命令之后:
rar a -u -as backup sources\*.cpp
压缩包 backup.rar 将只会包含源文件夹的 *.cpp 文件，其他的所
有文件将会从压缩包中删除。它看起来就好像创建新压缩包，但有
个重要的例外: 如果从上次备份后没有修改过的文件，这项操作会比
创建新压缩包的操作快上许多。
-av 放置原封装证书(注册版才有效)。
RAR 将会放置在每一个新建及更新的压缩包，关于创建者，最后的
更新时间和压缩包名称信息。
如果压缩包包含原封装证书，而且已被修改，而开关未指定时，原
封装证书信息将会被移去。
当解压缩，测试，列出或更新的时候和有 '-av' 开关的压缩包，RAR
将会运行完整的验证并且显示信息:
正在检验认证信息 ...
在成功的原封装证书情况，信息 'OK'，创建者名称和最后的更新资
讯将会被显示。在原封装证书失败的情况，信息 'FAILED' 将会被
显示。
此原封装证书的特色，强烈建议使用 '-av,' 于软件散布环境。
为了要使原封装证书特色启用，程序必须注册。请联系您当地的销
售地点或WWW 互联网散布中心。
-av- 停用检查或添加原封装证书。
-cfg- 关闭读取配置设置及环境变量。
-cl 将文件名转换成为小写。
-cu 将文件名转换成为大写。
-c- 不启动注释显示。
-df 压缩后删除压缩包。
文件移动到压缩包。此开关结合命令 a 运行时的操作相同于命令 m。
-dh 打开共享的文件。
允许处理由其他应用程序打开来写入的文件。
此开关是有危险性的，因为它允许添加文件到压缩包，而文件可能
正由其他应用程序进行修改中。使用时请小心。
-ds 在固实压缩包时不排序压缩的文件。
-ed 不添加空白的目录
此开关指示，如果目录是空的，不要将它添加压缩包。
-ep 从名称中排除路径。包含此开关时，文件在添加压缩包时不会包含路
径信息。这可能会有在压缩包中，存在数个相重名称的结果。
-ep1 从名称排除基本目录，不存储在命令行输入的路径
示例:
全部在目录 tmp 的文件及目录将会添加到压缩包 'test'，但不包
含路径 'tmp\'
rar a -ep1 -r test 'tmp\*'
这相当于命令:
cd tmp
rar a -r ..\test
cd ..
-ep2 扩大成完整路径。当压缩时存储完整文件路径(除了驱动器号和前
缀的分隔符)。
-e指定文件排除属性。 是十进制，八进制(以 '0' 前缀)
或十六进制(以 '0x' 前缀)的数字格式。如果 bitwise 的结果及
在和文件之间属性不为 0, 那么文件将不会被添加到压缩包。
在 Windows 版本，也可以使用代替数字的掩码符号 D, S, H, 及
R 指示目录及文件的系统，隐藏，和只读属性。给予的属性顺序并不
重要。
-f 整理文件。可使用于压缩包解压缩或者创建时。命令字串“a -f”
对等于命令 f。您也可以使用开关“-f”于命令 m。假如开关“-f”
使用于命令 x 或 e，此时仅旧文件会被从压缩包解开的新版本给取
代。压缩后的文件，没有符合的未包装文件，则不会解压缩。
-idp 显示百分比指示。
当重定向输出程文件时，可能相当有用。
-ierr 发送所有的错误到 stderr。
-ilog 记录错误到文件(注册版才有效)。
-inul 关闭全部的信息。
-isnd 启用声音提示。
-k 锁住压缩包，任何会更改压缩包的命令一律忽略。
-kb 保留损坏的解压缩文件。
RAR 在默认的时候，解压缩有 CRC 错误的文件会予删除，开关 -kb
则指定有 CRC 错误时不删除。
-m设置压缩方式:
-m0 存储 添加文件到压缩包但是不压缩
-m1 最快 最快速的方法(最低的压缩)
-m2 快速 快速压缩法
-m3 常规 常规(默认)压缩方法
-m4 良好 良好的压缩方法(较高的压缩)
-m5 最优 最优的压缩方法(最高压缩但速度最慢)
在 RAR 的默认是使用“-m3”方式(常规压缩)。
-md此开关允许以 Kb 来选择字典大小。 必须是 64、128、
256、512 或 1024 或映射字母“a”、“b”、“c”、“d”或“e”。
滑准法字典，是供压缩运算法使用的特殊内存区域。如果正在压缩的
(或在固实压缩包，总计文件大小的例子)文件大小比字典还大，此时
增加字典大小通常会增加压缩比，降低包装的速度，和增加内存需求。
默认的 RAR 滑动字典大小是 1024 Kb。在 Windows，Unix 和 OS/2 的
RAR 的版本，可从五个不同的大小中选用一个: 64、128、256、512 或
1024 Kb。不像压缩时一样，解压缩速度是不受字典大小所影响的。虽
然 RAR 的 DOS 版提供解压缩源自大的字典文件的文件的能力，在 DOS
的 RAR 的版本，滑动字典大小被固定等于 64 Kb。但是 DOS 版仍然可
从使用大字典的压缩包中解压缩文件。
RAR 创建 RAR 压缩包时，需求的内存数量可以计算为
5 * <字典大小> + 2560Kb。
解压缩时大约需要 1 MB，而更新固实压缩包时需要
5 * <字典大小> + 3084Kb。
DOS 版的 RAR 能够使用常规内存，EMS 和磁盘内存，从大型字
典压缩包解压缩。如果没有 EMS 或磁盘缓存可用，操作可能严重地
减缓。DOS 版的 RAR 不能够用默认的 SFX 模块来转换大型字典压缩
文件成 SFX，而且不能够更新如此类的固实压缩包。
示例:
RAR a -s -mdd sources *.asm
或
RAR a -s -md512 sources *.asm
将会创建固实压缩包并使用 512 Kb 字典。
-mm[f] 多媒体压缩 [强制]。启用特殊的多媒体压缩运算法。这主要目标是
用于当压缩如 WAV 原生的数码音频数据成四个 8 位或二个 16 位
元通道的时候，但是对于真彩色(24 位)位图也有良好的成效。压缩
率的增进，最大可达 30%，可以预期超过常规的压缩方式。多媒体
压缩也只能使用于 RAR 压缩包。
在压缩文件期间，在多媒体模式下，RAR 会聪明的运行数据分析，并
且在不同的部分根据最适合的演算法，分别使用常规或者多媒体运算
法。当不同的数据类型存在相同的文件时(此典型例子是 STM 及 MOD
文件)，如此的分析允许有优化的性能。
开关 -m[设置压缩方式] 及 -s [创建固实压缩包] 也可以使用多
媒体压缩，但它们只能影响以常规压缩演算的部分。如果 -mm 应用的
数据并不是多媒体，压缩率通常不会更改，但是由于多媒体分析的吃
重，总是会减低速度。所以并不建议使用 -mm 于非多媒体的数据。
示例:
rar a -m5 -s -mm All_My_Songs.rar *.wav
以机灵的分析为特别的数据判断该使用紧密的压缩方法，固实压缩
和多媒体压缩的哪一种方式:
-ol 存储符号链接当成文件的替代链接。
只在 Unix 版本有效。
-ow 当压缩存储文件安全信息及解压缩还原它的时候，使用此开关。
Unix 与 BeOS 的 RAR 版本在使用此开关时则存储文件拥有者、群
组，文件访问权及审查信息，但只在您有必须的权利范围下有效。
注意，这仅在 Windows 下的 NTFS 文件系统支持的安全下有效。
-os 存储 NTFS 数据流，只在 Win32 版本有效。
此开关意味著只能在 Windows NT 的 NTFS 文件系统下使用，并允许
存储与文件相关联的交替数据流。在像是使用来维持某些文件描述
所依据的串流，在 Windows 2000 底下尤其重要。如果您使用 RAR
来备份您的 NTFS 磁盘时，建议您指定此参数。
-o+ 覆盖现存的文件。
-o- 不覆盖现存的文件。
-p在压缩或解开加密的压缩文件期间，设置密码 <密码> 给加密的文件。
密码的大小写必须吻合。在命令行时，如果您省略了密码，您将会被
提示输入它。
示例:
rar a -pmyhoney secret1 *.txt
添加文件 *.txt 并以密码 "myhoney" 加密。
-p- 不询问密码
-r 启用子文件夹的递回，可使用于命令: a、u、f、m、x、e、t、k、
rr、c 及 s。
当使用于命令 a、u、f 或 m 时，不但仅当前工作的文件夹，且在
全部子文件夹的文件将会一并处理。
当使用于命令 x、e、t、k、rr、c 或 s 时，不但仅当前工作的资
料夹，且在全部子文件夹的压缩包将会一并处理。
-r0 类似于 开关 -r，但是与命令 a、u、f、m 合用时，只会递回包含万
用字符“*”及“?”的子文件夹名称。
-ri[:
]
设置优先级及停顿时间。这只可用于 Windows 的 RAR 。
此开关让 RAR 在多工环境下时，使用来管理系统载入负荷。可用
任务优先级数值是从 0 到 15。当等于 0 时，则使用默认的任
务优先级。1 表示最低的任务优先级，15 - 最高。
停顿时间是数值从 0 到 1000 (毫秒)。这是在包装或解开包装
操作期间，每次读取後或写入时 RAR 回到系统的周期时间。停顿时
间设定是有用於当有相同的优先次序的数个任务，正在系统运行的时
候。
示例:
运行 RAR 以默认优先级及每次读取或写入后停顿 10 ms(毫秒)
rar a -r -sfx -ri0:10 backup *.*
-rr[N] 添加数据恢复记录。此开关使用于，当创建或修改压缩包时，加
入数据恢复记录到压缩包。
请参阅 rr[N] 命令获取详细帮助
-s 创建固实压缩包。固实压缩是一种特殊的压缩方式，请参阅附加索引
"词汇表" 章节来获取功能的信息。
示例:
创建固实压缩包 sources.rar 使用 512 Kb 字典，递回全部目录，只
添加 .asm 文件:
rar a -s -md512 sources.rar *.asm -r
-s以文件数量创建固实组
类似于 -s，但在压缩个文件之后重置固实统计数据。通常这样
会减低压缩率，但也可以在固实压缩包损坏的例子时减少数据的流失。
-sd 创建从属的固实分卷压缩
类似 -s，但共用分卷压缩之间的固实统计数据。如果使用于创建非
固实压缩时则忽略。
根据默认，当开始新分卷压缩时使用此开关，RAR 会试著尽快的重置
固实统计数据。这代表会增加压缩率，但也因而如果在分卷集的某个
固实分卷遗失或损坏时，将减少解压缩部分数据的机会。
-se 以文件扩展名创建固实组
类似于 -s，但扩展名更改时重置固实统计数据。通常这样会减低压
缩率，但也可以在固实压缩包损坏的例子时减少数据的流失。
-s- 停用固实压缩法
-sfx[名称]
创建自解压缩包。如果创建新压缩包的时候使用此开关，自解压缩包
(使用文件 default.sfx 模块或在开关中指定的)将会被创建。
在 Windows 版本的 default.sfx 应该被放与 rar.exe 相同的目录内
，在 Unix 与 BeOS - 于用户的 home 目录，
/usr/lib 或 /usr/local/lib。
示例:
rar a -sfxwincon.sfx myinst
使用 wincon.sfx 自解压缩模块创建自解压缩包
-tk 维持原有的压缩包时间。当压缩包改变时，防止 RAR 修改压缩包时
间。
-tl 以最新的文件设置压缩包时间。强制 WinRAR 以在压缩包中最新的文件
时间修改压缩包时间。
-tn<时间> 使用此开关时，只处理比指定时间还新的那些文件，时间字串的格
式为:
[d][ h][ m][ s]
例如，使用开关 -tn15d 可处理文件较新近 15 天的，以及
-tn2h30m 则处理文件较新于 2 小时 30 分的。
-to<时间> 使用此开关时，只处理比指定时间还旧的那些文件，时间字串的格
式与 -tn<时间> 相同。
-u 更新文件。这可与压缩包解压及创建时合用。命令字串 a -u 是对等
于命令 u。您也可以使用开关“-u”于命令 m。如果开关“-u”使用
于命令 x 或 e，这时从压缩包解压缩，有最近使用的文件，仅在旧
文件有新版本时才会替换。这不像 -f 一样，如果压缩包没有符合的
未包装文件，它将会被解压缩。
-v<大小>[k|b|f]
创建分卷压缩及大小=*1000 [*1024 | *1]。
根据默认，此开关使用作为一千个(1000)字节(非 1024 x 字节)。
您也可以输入符号“k”来表示千字节的大小，或者符号“b”表示字
节，在百万字节表示法为 - “m”，而一百万个字节则是 - “M”，
或者使用符号“f”从数个预先定义的数值中选择一个。 预先定义的
数值有 360、720、1200、1440 或 2880 并会替换成一致的软盘大小。
如果省略了大小，将会使用自动检测。
如果分卷在相同的磁盘上被创建当成暂存的文件(默认为当前磁盘，
但是可能与开关 '-w' 一起改变)，自动检测大小会变成无意义。在
这情况下，分卷大小必须明确地定义。
如果分卷创建在抽取式媒体，在创建第一个分卷之后，用户将会被
提示:
创建下一个分卷吗? : Yes/No/All/Quit
在此时间里，您可以抽换软盘。回答“A”则会创建全部的分卷而
不会暂停。
在多盘分卷的第一个分卷所设置的扩展名为 .rar，以下的分卷则结合
数字从 .R00 到 .R99。
当解压缩或测试多盘的分卷压缩包时，您只能使用第一个分卷的名称
(*.rar)。如果下一个分卷不在驱动器时，用户会被提示:
请插入软盘 <下一个分卷名>。
这时请插入正确的分卷并按下任何键
当解压缩的时候，未找到下一个分卷时，RAR 将会中止并显示错误讯
息:
未找到 <分卷名>
压缩包分卷是无法修改的。命令 d、f、u 或 s 也不能使用于多盘的
分卷压缩包。命令 a 只可以在创建新的多盘分卷压缩时使用。
这是可能的，虽然不像在多盘分卷中文件的大小一样，但可能大于未
压缩的大小。此事实的缘由是“存储”(如果大小增加时不压缩)不能
在多盘的分卷压缩中启用。
压缩包分卷可以是自解压缩包，此类压缩包创建时可使用 '-v' 及 '-sfx'
开关的任一种。
示例:
以固定分卷大小创建压缩包:
rar a -s -v1440 floparch.rar *.*
将会创建 1440000 字节的固实分卷压缩。
-vd 创建分卷压缩前清除软盘内容
当使用“-vd”时，在开始压缩操作之前，全部在目标软盘的文件及
文件夹将会先清除。如果您创建分卷压缩，在创建每一个分卷之前，
都将先运行清除操作，以让您可以放入非空白的软盘，但您必须注意
在软盘上不包含任何的有用信息。
-vp 每次分卷之前暂停
根据默认，RAR 仅在可移动磁盘创建，或解压缩下一个分卷之前才会
询问确认。
此开关强制始终作如此的确认。如果磁盘空间有限，并且您希望在建
立之后立即复制每一个分卷到另外的媒体时，这会相当有用。
-w以
分配工作目录。此开关可用以为临时文件分配目录
-x排除指定的文件 ,可以使用通配符。在相同命令行，您可以指定
开关 -x 数次:
示例:
rar a -r -x*.bak -x*.rar rawfiles
*.bak 及 *.rar 文件将不会添加到 rawfiles
-x@使用指定的列表文件来排除文件。
示例:
rar a -x@exlist.txt arch *.exe
-y 假设全部的询问回应皆为“Yes”。
-z从文件 读取压缩包注释。
Link URL: http://www.cnblogs.com/tester2test/archive/2008/04/16/1156076.html -
>可以订购了
2008-05-16 14:36:06
有很多朋友和学员对这本书已经期待很久了，今天可以幸福的告诉大家这本书，您可以在China-pub上订购了（订购的链接：http://www.china-pub.com/39876）。
下面是专业人事的书评内容：
LoadRunner是性能测试领域中应用较为普遍的商业测试工具，具有强大的功能，也比较容易入门。但大部分LoadRunner的初学者在掌握了简单的录制/回放技术后，想要进一步使用LoadRunner完成复杂任务的时候，都会发现自己对LoadRunner中复杂的参数设置、脚本语言的高级用法等不能很快掌握。而目前市面上又缺乏一本系统介绍LoadRunner进阶用法的书。.
本书的出现恰逢其时，在本书的第一部分中，作者介绍了LoadRunner的基本使用，包括协议的选择、脚本的参数化、关联和脚本调试技术；在本书的第二部分中，则突出了LoadRunner的高级应用，在这部分内容的编排上，作者独具匠心地提炼出了使用LoadRunner过程中遇到的具有代表性的问题，并针对具体的问题给出了解决思路和示例代码。因此，本书既可以作为读者进一步了解LoadRunner的学习教材，也可以被当成LoadRunner应用的速查手册，读者可以直接在书中找到自己想要解决问题的答案。
另外，贯穿在本书中的还有不少作者在实际工作中得到的真知灼见，和处理具体问题的技巧，这些都会帮助读者提高测试技能。
����段念 Google（谷歌）TestLeader
本书是一本LoadRunner实践和技巧性很强的作品，为软件测试人员快速掌握并运用LoadRunner提供了所需要的知识。作者于涌是一位从事软件测试和培训多年的资深测试人员，本书是作者多年工作经验的总结，向读者提供了使用LoadRunner解决性能测试问题的宝贵经验。
����朴春龙 北京51Testing软件测试社区 总经理
随着网络应用的普及和发展，系统的性能评价被提到了前所未有的高度，性能测试技术是个综合的技能，本书作者根据自己丰富的经验，以实际的案例结合工具应用，向读者展示了不同的性能测试技术和技巧，希望为同业者提供有益的指导。
����贺�� 测试时代 站长 北京慧灵科技有限公司 总经理
“工欲善其事，必先利其器”，LoadRunner无疑是性能测试工具中的翘楚，掌握了此工具无疑会简化性能测试过程中的复杂工作，从技术层面上提升性能测试工作的效率，降低性能测试工作的难度。我此次有幸先拜读了于涌先生的书籍，本以为是一本以介绍LoadRunner为主的工具书，而于先生却以自己深厚的性能测试功底，从性能测试过程的各个角度出发，对各种类型的性能测试技术的应用进行了诠释，并巧妙地结合LoadRunner的各个知识点来讲解如何去有效地实施性能测试。使得读者在学习过程中不仅掌握了工具的使用，更关键地是学习到了性能测试过程中的各种方法。这无疑是一本非常好的性能测试参考书籍！
����张斌 3aTesting社区创始人
前段时间一直为招聘不到合适的性能测试工程师而发愁。的确，软件测试在国内发展时间不是太长，而优秀的性能测试工程师更是凤毛麟角，一位性能测试工程师要具备广泛的计算机知识，同时还需要有丰富的性能测试经验。而在不久前有幸阅读了本书的部分章节，深深地感受到了作者深厚的性能测试技术和项目经验功底，是国内在性能测试领域难得的一部参考书籍，尤其对于想在性能测试发展的测试工程师来说，阅读本书对于提高自己性能测试技能是非常有益的。
����曹向志 吉贝克软件测试 经理
在笔者深厚的开发经验基础之上，加上对性能测试及工具的深刻理解，着力打造的经验之谈。由浅入深的知识讲解，由易到难的层层解析，让读者很容易地掌握工具的使用技巧和性能测试技术，在现有的性能测试书籍中，本书有着自己的特点，能使学习LoadRunner的读者能力得以稳步提升，且没有杂乱的理论影响。
51Testing Zee版主
接下来给大家介绍一下本书的主要内容：
本书主要是为目前正在使用或者学习LoadRunner工具答疑解惑，结合作者学习、应用LoadRunner工具的过程，实例讲解作者的学习的经验体会、应用中遇到的问题及其解决方法等。全书共分为三大部分：“基础篇”描述了典型的性能测试场景、工具的安装、性能测试的基础概念、介绍了脚本的调试技术、以多个B/S、C/S的实例讲解了多个协议、事务、集合点、检查点、思考时间、关联、IP欺骗、多机联合测试等技术在工具中应用。“实战篇”则分别对数据库、邮件协议、FTP协议以及.NET 2003 插件在开发环境进行了详细的讲解，同时提供几十个大家经常问道的问题进行详细的讲解。最后，根据作者近十年的工作经验总结出做好软件测试工作需要了解的必备知识、性能测试策略以及规范化的软件测试相关文档。
“基础篇”包括本书的第1章～第3章的全部内容。
在第1章中，本书介绍了典型的性能测试场景、性能测试的概念以及分类、详细介绍了工具及其样例程序的安装过程，重点介绍了工具的运行机制及其工具组成部分，同时结合生动的生活场景深入浅出的解释了工具中集合点、事务、检查点、思考时间等重要概念。
在第2章中，介绍了协议的类型、协议理解误区、协议选择的方法、同时以C/S、B/S两种构架的应用作为实例，详细讲解协议的选择和脚本的录制、详细介绍了参数化的方法及其应用技巧，以及数据分配方式和更新方法，结合实例进行了详细的描述；又以一个Web样例程序作为实例，将工具的VuGen 、Controller、Analysis三者有机的结合起来，在此实例中集合点、事务、检查点等概念、以及参数化等技术运用于该实例。深入了解脚本录制、负载（场景设计、执行）、结果分析。对脚本的断点设置、单步跟踪、日志输出等调试技术进行详细讲解。最后，剖析了LoadRunner内部结构，对主要文件进行介绍。
在第3章中，介绍了关联概念、结合两个实例详细讲解了简单和复杂关联的应用。实例讲解用户自定义动态连接库、系统动态连接库应用。应该注意的系统函数示例，自定义函数及其自定义函数复用进行了详细介绍，最后，对IP Wizard和多机联合进行负载测试技术进行了详细描述。
第4章和第5章是本书的重点讲解章节。第4章，讲解了测试人员最关心的数据库、邮件协议（SMTP）、文件传输协议(FTP)脚本的开发进行了详细的介绍，为大家提供了广阔的性能测试丝路。同时还为.NET开发和测试人员提供了另一种面向代码进行性能测试手段，详细讲解了.NET插件的应用。
第5章，结合作者学习、工作经验、学员以及网上论坛经常提出的问题，总结了关于工具设置、工具使用、结果分析等方面的问题，对提出问题进行了描述，同时提供了详细的解决方案，旨在起到了举一反三的作用，指导读者实际应用于工作当中。
第6章，详细介绍了HTTP协议基础知识、AT命令和计划知识、HTTP状态代码含义以及内存、处理器、磁盘、数据库等计数器指标，这些知识对测试人员从事性能测试工作是必备的知识，通过学习这些内容能够提高对性能测试工作深入理解和工作效率。
第7章，介绍了如何结合企业的特点量体裁衣定制性能测试策略、开发人员如何和测试人员协同做好基于.NET集成开发环境的性能测试、以及性能测试场景、用例设计、执行策略和系统调优内容进行了详细的介绍。
附件部分，提供一些对测试工作来说非常重要的模板文件，包括：测试计划、测试总结、测试日志、功能测试用例及性能测试用例等模板样例文档以及性能测试经常需要考虑的若干问题。
本书阅读建议
本书按照循序渐进的整体设计思路安排内容，无论您是有经验的性能测试人员、开发人员、系统管理人员还是刚参加工作的测试人员，建议您最好按照书目进行阅读。因为全书是按照概念解析、实践应用、问题解答的顺序来编写，不仅仅在实践和问题解答部分提供了很多真实、详细的案例，在进行概念解析的同时也给出了很多非常重要的经验，这对于读者深入理解相关概念和少走弯路都是不无裨益的。当然，您也可以依据自己的需要选择自己关心的内容进行阅读。
本书图文结合，同时提供了书籍中应用的样例程序和脚本代码。希望读者在阅读本书的同时，能够边看边实践，深入理解脚本，这样可以减少您学习、掌握工具使用的周期，尽快将LoadRunner 工具应用于实际性能测试工作中。测试必备知识、策略和相关模板文件很重要，它可以为您做好测试工作提供一种良好的思路，指导您做好测试工作。
Link URL: http://www.cnblogs.com/tester2test/archive/2008/05/12/1194082.html -
测试经理和高级测试工程师招聘信息
2008-05-16 14:36:06
公司信息介绍
长春吉大正元信息技术股份有限公司是中国领先的信息安全专业服务提供商，成立于1992年2月。在北京市中关村和长春市高新技术产业开发区设有两个产品研发中心，运营中心位于北京中关村；设有上海子公司，并控股山西省数字证书认证中心，参股吉林省数字证书认证中心、内蒙古数字证书认证中心。公司是国家密码管理委员会办公室认定的首批商用密码定点生产单位和销售许可单位，国家规划局内的重点软件企业，国家火炬计划软件产业基地骨干企业，具有国家保密局颁发的涉及国家秘密的计算机信息系统集成资质。公司主要从事信息安全产品的研发、生产、销售，并提供安全咨询、安全评估和安全集成等服务。主要产品有JIT SRQ05数字证书认证系统、JITPMS授权管理系统、JITSmart Office通用办公资源与业务管理系统、JIT Keeper网络文件监控系统等数十种。
公司承担建设了十余个国家部委数字证书认证中心、十几个省级数字证书认证中心和数十个企业数字证书认证系统，在数字证书认证领域处于主导地位，市场占有率在70%以上。
公司一贯坚持“用市场培育开发，用开发推动市场”的理念，在市场推广取得成功的同时，加大科研开发力度，先后承担了多项国家重点项目：国家密码管理委员会办公室“电子证书及其标准研究”、国家纪委高技术产业化示范工程“企业团体贸易电子商务系统B2B产业化”和“WPKI关键技术及产品产业化”、国家科技部“十五”计划“863”计划项目“交叉认证技术的研究与开发”、信息产业部国家移动通讯产品研究开发专项部分“WPKI网关平台于移动终端WAP软件专项研究项目”、科技部中小企业技术创新基金“具有安全机制的电子商务系统”和“挂号电子邮局系统”、信息产业部电子工业基金项目“电子证书认证系统”、“基于智能卡的数字认证体系”及“NC电子政务平台项目”等。
公司的战略发展目标是以数字证书技术为核心，研发和生产信息安全相关产品，秉承创新精神，强化科学管理，把公司建设成中国规模最大、技术最优、产品最好、服务最佳的信息安全产业集团。公司网站： http://www.jit.com.cn/
测试部经理（1名 工作地点：北京）
职位描述：
工作职责：
1. 组织管理测试人员编写产品测试方案，制定测试计划，对测试过程实施管理和控制；
2. 持续改进测试流程和技术，不断提高产品测试效率和质量；
基本要求：
1. 熟悉测试管理工作，能够带领测试团队不断提升测试技术、改进测试流程；
2. 熟悉各种常用测试工具（TestDirector、LoadRunner、QTP、WinRunner等），擅长通过工具使用提高测试效率和质量；
3. 熟悉B/S和C/S软件形态测试，熟悉java、C等常用开发语言；
4. 工作积极，有热情，能承担工作压力，擅长与产品开发部门协调沟通；
5. 计算机及相关专业毕业，本科以上学历，5年以上工作经验；
高级测试工程师 （3名 工作地点：北京）
职位描述：
工作职责：
1.本科以上学历，3年以上软件测试、或者测试开发工作经验；
2.精通常用的软件测试工具，做过2个以上应用LoadRunner，QTP，Winrunner等性能、功能自动化工具的项目；
3.熟悉软件测试过程，对软件功能测试和系统性能测试有深入的理解；
4.精通常用操作系统应用（如：Windows、Linux等操作系统）；
5.工作积极主动，有热情，善于发现问题和解决问题；
6.具有团队合作精神，良好的沟通、表达能力和技巧，有管理工作经验者或用户现场测试工作经验者优先考虑；
7.有网络信息安全方面工作经验者，优先考虑；
Link URL: http://www.cnblogs.com/tester2test/archive/2008/05/15/1198368.html -
LoadRunner特殊函数应用注意事项
2008-05-16 14:36:06
网上订购地址： http://www.china-pub.com/39876
转载请注明：作者 及其 原文链接特殊函数应用注意事项
在进行测试脚本编写时可能遇到一些问题，函数使用后没有按照我们预先的想法执行，而影响结果的正确性。我在做一个实际测试的项目中，有这样的一个案例：一个进销存管理系统，要测试进货总额计算是否正确，已知进货商品名称、数量和单价，请参见下表：
序号
商品名称
进货数量
进货单价
1
电视机
2
1380.00
2
电冰箱
2
859.80
3
微波炉
4
450.00
表３－３：商品进货列表
从上面的数据可知，进货总额应为2*1380.00+2*859.80+4*450.00＝6279.60，从页面取得进货总额数据信息转换成浮点数以后与6279.60对比，如果相等则说明系统关于进货总额部分的处理是正确的，如果不等，说明统计错误。从页面上得到的数值为6279.60，脚本的计算结果也为6279.60，为什么系统反馈的提示始终是“预期结果与实际结果不等!”？。下面我们来看这段脚本，在此仅列出关键部分代码。
相应脚本代码：
#include "web_api.h"
//double atof ( const char *string );
Action()
{
char totalprice[64]="6279.60";
float price[3]={1380.00,859.80,450.00};
int quantity[3]={2,2,4};
char strtmpres[64];
float ftotalprice=0;
int i;
for (i=0;i<=2;i++)
{
ftotalprice=ftotalprice+price[i]*quantity[i];
}
lr_output_message("用atof格式化输出totalprice＝%f",atof(totalprice));
lr_output_message("浮点数取的是近似值请看函数的输出结果：%f",ftotalprice);
sprintf(strtmpres,"%.2f",ftotalprice);
lr_output_message("保留两位小数格式化的浮点数为：%s ",strtmpres);
if (*strtmpres==*totalprice)
{
lr_output_message("预期结果与实际结果相等!");
}
else
{
lr_output_message("预期结果与实际结果不等!");
}
return 0;
}
首先，看看在不声明函数atof时，运行结果如图3－19。大家可以看到脚本
lr_output_message("用atof格式化输出totalprice＝%f",atof(totalprice));
在未声明函数atof函数时，输出结果为
用atof格式化输出totalprice＝0.000000
显然这不是期望的结果。
然后，再看看声明函数atof后，运行结果如图3－20，相应脚本的输出结果为
用atof格式化输出totalprice＝6279.600000
那么为什么会出现这样的结果呢？
图3－19：未声明atof函数运行结果
图3－20：声明atof函数后运行结果
脚本解析：
首先，我们声明了atof函数，但为了演示不声明函数会出现的问题，我们先将这部分代码注释掉。
//double atof ( const char *string );
然后，在Action部分，初始化和声明了一些变量。
char totalprice[64]="6279.60"; //期望进货总额数值
float price[3]={1380.00,859.80,450.00}; //进货商品单价数组
int quantity[3]={2,2,4}; //进货商品数量数组
char strtmpres[64]; //存放格式化浮点字符串的临时变量
float ftotalprice=0; //存放计算进货总额变量，初始化为0
int i; //临时整型变量
将三组进货单价*进货数量相加，并将结果存放到ftotalprice。
for (i=0;i<=2;i++)
{
ftotalprice=ftotalprice+price[i]*quantity[i];
}
在未声明atof函数时，应用atof函数，输出atof(totalprice)，即：将"6279.60"转换成浮点数，但我们发现运行结果输出“0.000000”，而声明函数后运行结果输出为“6279.600000”。
lr_output_message("用atof格式化输出totalprice＝%f",atof(totalprice));
为什么会这样？
LoadRunner的函数联机帮助原文描述如下：
图3－21：atof函数联机帮助
红色区域的注释信息为：“Note: The function atof, as with all functions that do not return an integer, must be explicitly declared in Vugen scripts.”，这句话的含义就是“注释：atof函数以及所有非返回整型数值的函数，必须在脚本生成器中明确指出。”，所以在应用函数时一定要看看联机帮助有无注释部分，正确应用函数。
浮点数的取值是近似值，计算可以得到1380.00*2+859.80*2+450.00*4=6279.60，而实际结果输出却是6279.600098，从而说明浮点数取的是近似值。所以不能拿两个浮点数进行比较。如：拿6279.60和6279.600098比较判断其是否相等，而应该将浮点数格式化成相同精度的字符串再进行比较，这样可以防止出现意外情况的发生。
lr_output_message("浮点数取的是近似值请看函数的输出结果：%f",ftotalprice);
格式化ftotalprice取小数点后两位，并将结果字符串存放到strtmpres，目的就是和totalprice字符串进行相同精度的比较，格式化后，输出strtmpres为“6279.60”。
sprintf(strtmpres,"%.2f",ftotalprice);
lr_output_message("保留两位小数格式化的浮点数为：%s ",strtmpres);
最后，加入逻辑控制，如果strtmpres和totalprice的内容相同，则输出“预期结果与实际结果相等!”，否则输出“预期结果与实际结果不等!”，因为两者内容相同，则输出结果为“预期结果与实际结果相等!”。
if (*strtmpres==*totalprice)
{
lr_output_message("预期结果与实际结果相等!");
}
else
{
lr_output_message("预期结果与实际结果不等!");
}
【作者提示】
1. 在应用函数时应仔细阅读函数的联机说明和示例，要特别注意有无注释，如果函数事先需要声明，则在应用之前必须先声明后使用。
2. 浮点数的取值是近似值，所以在进行等值判断时，必须取相同的精度，最好转换为字符串后再进行等值比较。
Link URL: http://www.cnblogs.com/tester2test/archive/2008/05/16/1200051.html -
运用LOADRUNNER .NET ADD-IN 写的性能测试脚本
2007-07-12 12:18:22
using System;
using System.Runtime.InteropServices;
using System.Data.OleDb;
using System.Data;namespace LoadRunnerUser1
{
///
/// Summary description for VuserClass.
///
[ClassInterface(ClassInterfaceType.AutoDual)]
public class VuserClass
{
LoadRunner.LrApi lr;public VuserClass()
{
// LoadRunner Standard API Interface :: DO NOT REMOVE!!!
lr = new LoadRunner.LrApi();
}// ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
public int Initialize()
{
// TO DO: Add virtual user's initialization routines
lr.message("Initialize部分，我只执行一次哦！");
return lr.PASS;
}// ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
public int Actions()
{
// TO DO: Add virtual user's business process actions
lr.message("Actions部分，我可以重复执行（在设置迭代情况下）！");
try
{
//设置连接字符串开始
string strConnection="Provider=Microsoft.Jet.OleDb.4.0;";
strConnection+=@"Data Source=C:\\test.mdb";
//设置连接字符串结束//插入一个集合点开始
lr.rendezvous("集合点");
//插入一个集合点结束//事务开始
lr.start_transaction("SQL语句性能");//建立OleDbConnection和OleDbCommand，并指定要运行的Sql语句开始
System.Data.OleDb.OleDbConnection conn=new
System.Data.OleDb.OleDbConnection(strConnection);
System.Data.OleDb.OleDbCommand cmd = new System.Data.OleDb.OleDbCommand();
cmd.Connection = conn;
cmd.CommandText = "select * from testdb";
//建立OleDbConnection和OleDbCommand，并指定要运行的Sql语句结束//插入一个日志开始
lr.log_message("LOG: Sql语句开始执行了,Sql="+cmd.CommandText);
//插入一个日志结束//将查询结果填充到DataTable开始
DataTable dt = new DataTable();
System.Data.OleDb.OleDbDataAdapter oleDA = new
System.Data.OleDb.OleDbDataAdapter();
oleDA.SelectCommand = cmd;
oleDA.Fill(dt);
//将查询结果填充到DataTable结束//插入一个日志开始
lr.log_message("LOG: Sql语句执行完成,Sql="+cmd.CommandText);
//插入一个日志结束//取得结果集的记录数
int iCountRec=Convert.ToInt32(dt.Rows.Count.ToString());
conn.Close();//关闭连接
//如果记录数大于0，完整这个事务，否则标识事务失败
if(iCountRec>0)
lr.end_transaction("SQL语句性能",lr.PASS);
else
lr.end_transaction("SQL语句性能",lr.FAIL);//再来一个参数化的示例开始
lr.output_message("Welcome "+lr.eval_string("")+"!"); //再来一个参数化的示例结束
//Thinktime 的应用,就是模拟手工操作的延时，在这里我们延时3秒钟
lr.think_time(3);
}catch(Exception ex)
{
conn.Close();//关闭连接
string error = ex.Message;
}return lr.PASS;
}// ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
public int Terminate()
{
// TO DO: Add virtual user's termination routines
lr.message("Terminate部分，我只执行一次哦！");
return lr.PASS;
}}
}
Link URL: http://www.cnblogs.com/tester2test/archive/2006/07/10/447353.html -
Application Center Test知识点滴积累
2007-07-12 12:18:22
Application Center Test 在测试运行中自动监视 HTTP 性能统计信息，但性能计数器必须在测试运行之前明确进行配置。
请检查 ACTTrace.log 文件和报告，并确保不存在以下错误：
脚本错误
DNS 错误
套接字连接错误
HTTP 错误
如有必要，请在重新运行测试之前改正其中的错误。
dcomcnfg.exe 启动 DCOM 配置工具
计算页面性能的公式
以下公式通过测量每个请求所需的处理器周期数来量化 Web 应用程序的性能。该公式用所消耗的周期数除以所处理的请求数。(sum of processor speed x processor use)
________________________________________ = cost, in cycles/request (or Hz/rps)
number of requests per second
例如，在应力测试中，ASP 页面的最大容量可达每秒 800 个请求，同时 Web 服务器的处理器使用率为 85%。如果 Web 服务器的处理器频率为 700 MHz（每秒 700,000,000 周期），可以使用以下公式来计算页面的成本：((4 x 700 000 000 cycles/s) x 0.85)
___________________________________ = 2 975 000 cycles/request
800 requests/s
计算页面性能的 VBScript 代码
使用以下 VBScript 函数计算成本：
'''''''''''''''''''''''''''''''''''''''''''''''''''''''
' Function to return the cost of a page, based on
' stress test values and Web server/cluster hardware.
'
' Returns: page cost, in millions of cycles per request
'
Function GetPageCost(iSumOfProcessorSpeeds, _
fAverageProcessorUse, iAverageRPS)
Dim iSpentCyclesPerSecond' calculate the number of cycles used over the testing period
iSpentCyclesPerSecond = iSumOfProcessorSpeeds _
* fAverageProcessorUse' calculate the amount of work performed by the Web server
If (iAverageRPS > 0) Then
GetPageCost = iSpentCyclesPerSecond / iAverageRPS
Else
GetPageCost = 0
End If
End Function
使用页面成本的示例
了解页面成本有许多用途。最显而易见的用途是比较两个不同页面的性能，或者比较同一页面在调整前后的成本。
特别是当测试对站点中的所有页面进行请求时，可以通过成本初步估计是否需要随着要处理的通信量的增加、CPU 使用率的更改（或者同时处理两者）添加附加硬件。
在前面的示例中，需要多大的处理器速度才能保证处理两倍的站点通信量，同时使处理器的使用率保持在 40% 左右，以便可以轻松处理至少达到 3200 rp 的临时负载增长？
以下计算表明需要的处理器速度大约为 11900 MHz：
page cost x target RPS
estimated processor speed = ______________________
processor use2 975 000 cycles/request x 1600 requests/s
estimated processor speed = __________________________________________
0.40estimated processor speed = 11 900 000 000 cycles/s
number of 700 MHz processors needed = 11 900 MHz / 700 MHz = 17
新的性能目标要求 Web 服务器群集中有大约 17 个处理器，而原来只需 4 个。再次强调，这些估计仅当处理器速度是限制 Web 应用程序性能的因素时才有意义。
Link URL: http://www.cnblogs.com/tester2test/archive/2006/07/13/449809.html -
界面设计与测试规则
2007-07-12 12:18:22
界面是软件与用户交互的最直接的层，界面的好坏决定用户对软件的第一印象。而且设计良好的界面能够引导用户自己完成相应的操作，起到向导的作用。同时界面如同人的面孔，具有吸引用户的直接优势。设计合理的界面能给用户带来轻松愉悦的感受和成功的感觉，相反由于界面设计的失败，让用户有挫败感，再实用强大的功能都可能在用户的畏惧与放弃中付诸东流。目前界面的设计引起软件设计人员的重视的程度还远远不够，直到最近网页制作的兴起，才受到专家的青睐。
目前流行的界面风格有三种基本方式：多窗体、单窗体以及资源管理器风格，无论那种风格，以下规则是应该被重视的。1：易用性：
按钮名称应该易懂，用词准确，屏弃摸棱两可的字眼，要与同一界面上的其他按钮易于区分，能望文知意最好。理想的情况是用户不用查阅帮助就能知道该界面的功能并进行相关的正确操作。
易用性细则：
1):完成相同或相近功能的按钮用Frame框起来，常用按钮要支持快捷方式。
2):完成同一功能或任务的元素放在集中位置，减少鼠标移动的距离。
3):按功能将界面划分局域块，用Frame框括起来,并要有功能说明或标题。
4):界面要支持键盘自动浏览按钮功能，即按Tab键的自动切换功能。
5):界面上首先应输入的和重要信息的控件在Tab顺序中应当靠前,位置也应放在窗口上较醒目的位置。
6):同一界面上的控件数最好不要超过10个，多于10个时可以考虑使用分页界面显示。
7):分页界面要支持在页面间的快捷切换，常用组合快捷键Ctrl+Tab
8):默认按钮要支持Enter及选操作，即按Enter后自动执行默认按钮对应操作。
9):可写控件检测到非法输入后应给出说明并能自动获得焦点。
10):Tab键的顺序与控件排列顺序要一致，目前流行总体从上到下，同时行间从左到右的方式。
11):复选框和选项框按选择几率的高底而先后排列。
12):复选框和选项框要有默认选项，并支持Tab选择。
13):选项数相同时多用选项框而不用下拉列表框。
14):界面空间较小时使用下拉框而不用选项框。
15):选项数较少时使用选项框，相反使用下拉列表框。
16):专业性强的软件要使用相关的专业术语，通用性界面则提倡使用通用性词眼。
2： 规范性：
通常界面设计都按Windows界面的规范来设计，即包含“菜单条、工具栏、工具厢、状态栏、滚动条、右键快捷菜单”的标准格式，可以说：界面遵循规范化的程度越高，则易用性相应的就越好。小型软件一般不提供工具箱。
规范性细则：
1):常用菜单要有命令快捷方式。
2):完成相同或相近功能的菜单用横线隔开放在同一位置。
3):菜单前的图标能直观的代表要完成的操作。
4):菜单深度一般要求最多控制在三层以内。
5):工具栏要求可以根据用户的要求自己选择定制。
6):相同或相近功能的工具栏放在一起。
7):工具栏中的每一个按钮要有及时提示信息。
8):一条工具栏的长度最长不能超出屏幕宽度。
9):工具栏的图标能直观的代表要完成的操作。
10):系统常用的工具栏设置默认放置位置。
11):工具栏太多时可以考虑使用工具箱。
12):工具箱要具有可增减性，由用户自己根据需求定制。
13):工具箱的默认总宽度不要超过屏幕宽度的1/5。
14):状态条要能显示用户切实需要的信息，常用的有：
目前的操作、系统状态、用户位置、用户信息、提示信息、错误信息等，
如果某一操作需要的时间较长，还应该显示进度条和进程提示。
15):滚动条的长度要根据显示信息的长度或宽度能及时变换，以利于用户了解显示信息的位置和百分比。
16):状态条的高度以放置5号字为宜，滚动条的宽度比状态条的略窄。
17):菜单和工具栏要有清楚的界限;菜单要求凸出显示，这样在移走工具栏时仍有立体感。
18):菜单和状态条中通常使用5号字体。工具栏一般比菜单要宽，但不要宽的太多，否则看起来很不协调。
19):右键快捷菜单采用与菜单相同的准则。
3：帮助设施：
系统应该提供详尽而可靠的帮助文档，在用户使用产生迷惑时可以自己寻求解决方法。
帮助设施细则：
1):帮助文档中的性能介绍与说明要与系统性能配套一致。(我们的系统帮助文档都是系统的祖先时期的说明，让人困惑)。
2):打包新系统时，对作了修改的地方在帮助文档中要做相应的修改。
3):操作时要提供及时调用系统帮助的功能。常用F1。
4):在界面上调用帮助时应该能够及时定位到与该操作相对的帮助位置。也就是说帮助要有即时针对性。
5):最好提供目前流行的联机帮助格式或HTML帮助格式。
6):用户可以用关键词在帮助索引中搜索所要的帮助，当然也应该提供帮助主题词。
7):如果没有提供书面的帮助文档的话，最好有打印帮助的功能。
8):在帮助中应该提供我们的技术支持方式，一旦用户难以自己解决可以方便的寻求新的帮助方式。
4：合理性：
屏幕对角线相交的位置是用户直视的地方，正上方四分之一处为易吸引用户注意力的位置，在放置窗体时要注意利用这两个位置。
合理性细则：
1):父窗体或主窗体的中心位置应该在对角线焦点附近。
2):子窗体位置应该在主窗体的左上角或正中。
3):多个子窗体弹出时应该依次向右下方偏移，以显示窗体出标题为宜。
4):重要的命令按钮与使用较频繁的按钮要放在界面上注目的位置。(默认界面应该只显示目标用户最常使用的功能，至于不常用到的高级功能，可以“隐藏”起来，比如说，放到菜单里，不要都做成按钮摆到界面上。果真需要需要这些高级功能的话，用户自然会到菜单里去找的。 )
5):错误使用容易引起界面退出或关闭的按钮不应该放在易点位置。横排开头或最后与竖排最后为易点位置。
6):与正在进行的操作无关的按钮应该加以屏蔽(Windows中用灰色显示，没法使用该按钮)。
7):对可能造成数据无法恢复的操作必须提供确认信息,给用户放弃选择的机会。
8):非法的输入或操作应有足够的提示说明。
9):对运行过程中出现问题而引起错误的地方要有提示，让用户明白错误出处，避免形成无限期的等待。
10):提示、警告、或错误说明应该清楚、明了、恰当。
5：美观与协调性：
界面应该大小适合美学观点，感觉协调舒适，能在有效的范围内吸引用户的注意力。美观与协调性细则：
1):长宽接近黄金点比例，切忌长宽比例失调、或宽度超过长度。
2):布局要合理,不宜过于密集，也不能过于空旷，合理的利用空间。
3):按钮大小基本相近，忌用太长的名称，免得占用过多的界面位置。
4):按钮的大小要与界面的大小和空间要协调。
5):避免空旷的界面上放置很大的按钮。
6):放置完控件后界面不应有很大的空缺位置。
7):字体的大小要与界面的大小比例协调, 通常使用的字体中宋体9-12较为美观，很少使用超过12号的字体。
8):前景与背景色搭配合理协调，反差不宜太大，最好少用深色，如大红、大绿等。蓝色文字以白色背景容易识别，而在红色背景则不易分辨，原因是红色和蓝色没有足够反差，而蓝色和白色反差很大。除非特殊场合，杜绝使用对比强烈，让人产生憎恶感的颜色。常用色考虑使用Windows界面色调。
9):整个界面色彩尽量少的使用类别不同的颜色。统一色调，针对软件类型以及用户工作环境选择恰当色调:如：安全软件，根据工业标准，可以选取黄色，绿色体现环保，蓝色表现时尚、紫色表现浪漫等等，淡色可以使人舒适，暗色做背景使人不觉得累等
10):如果使用其他颜色，主色要柔和，具有亲和力与磁力，坚决杜绝刺目的颜色。
11):大型系统常用的主色有"#E1E1E1"、"#EFEFEF"、"#C0C0C0"等。
12):界面风格要保持一致，字的大小、颜色、字体要相同，除非是需要艺术处理或有特殊要求的地方。
13):如果窗体支持最小化和最大化或放大时，窗体上的控件也要随着窗体而缩放；切忌只放大窗体而忽略控件的缩放。
14):对于含有按钮的界面一般不应该支持缩放，即右上角只有关闭功能。
15):通常父窗体支持缩放时，子窗体没有必要缩放。
16):如果能给用户提供自定义界面风格则更好，由用户自己选择颜色、字体等。
6：菜单位置：
菜单是界面上最重要的元素，菜单位置按照按功能来组织。
菜单位置细则：
1):菜单通常采用“常用--主要--次要--工具--帮助”的位置排列，符合流行的Windows风格。
2):常用的有“文件”、“编辑”，“查看”等，几乎每个系统都有这些选项，当然要根据不同的系统有所取舍。
3):下拉菜单要根据菜单选项的含义进行分组，并切按照一定的规则进行排列，用横线隔开。
4):一组菜单的使用有先后要求或有向导作用时，应该按先后次序排列。
5):没有顺序要求的菜单项按使用频率和重要性排列，常用的放在开头， 不常用的靠后放置；重要的放在开头，次要的放在后边。
6):如果菜单选项较多，应该采用加长菜单的长度而减少深度的原则排列。
7):菜单深度一般要求最多控制在三层以内。
8):对常用的菜单要有快捷命令方式，组合原则见8。
9):对与进行的操作无关的菜单要用屏蔽的方式加以处理，如果采用动态加载方式����即只有需要的菜单才显示����最好。
10):菜单前的图标不宜太大，与字高保持一直最好。
11):主菜单的宽度要接近，字数不应多于四个，每个菜单的字数能相同最好。
12):主菜单数目不应太多，最好为单排布置。
7：独特性：
如果一味的遵循业界的界面标准，则会丧失自己的个性.在框架符合以上规范的情况下，设计具有自己独特风格的界面尤为重要。尤其在商业软件流通中有着很好的迁移默化的广告效用。独特性细则：
1):安装界面上应有单位介绍或产品介绍，并有自己的图标。
2):主界面，最好是大多数界面上要有公司图标。
3):登录界面上要有本产品的标志，同时包含公司图标。
4):帮助菜单的“关于”中应有版权和产品信息。
5):公司的系列产品要保持一直的界面风格，如背景色、字体、菜单排列方式、图标、安装过程、按钮用语等应该大体一致。
8：快捷方式的组合
在菜单及按钮中使用快捷键可以让喜欢使用键盘的用户操作得更快一些。在西文Windows及其应用软件中快捷键的使用大多是一致的。
菜单中：
1):面向事务的组合有:
Ctrl-D 删除
Ctrl-F 寻找
Ctrl-H 替换
Ctrl-I 插入
Ctrl-N 新建
Ctrl-S 保存
Ctrl-O 打开
2):列表:
Ctrl-R 刷新
Ctrl-G 定位
Ctrl-Tab 下一分页窗口或反序浏览同一页面控件
3):编辑:
Ctrl-A 全选
Ctrl-C 拷贝
Ctrl-V 粘贴
Ctrl-X 剪切
Ctrl-Z 撤消操作
Ctrl-Y 恢复操作
4):文件操作:
Ctrl-P 打印
Ctrl-W 关闭
5):系统菜单
Alt-A 文件
Alt-E 编辑
Alt-T 工具
Alt-W 窗口
Alt-H 帮助
6):MS Windows保留键:
Ctrl-Esc 任务列表
Ctrl-F4 关闭窗口
Alt-F4 结束当前程序
Alt-Tab 切换当前程序
Enter 缺省按钮/确认操作
Esc 取消按钮/取消操作
Shift-F1 上下文相关帮助按钮中：
可以根据系统需要而调节，以下只是常用的组合。
Alt-Y 确定(是)
Alt-C 取消
Alt-N 否
Alt-D 删除
Alt-Q 退出
Alt-A 添加
Alt-E 编辑
Alt-B 浏览
Alt-R 读
Alt-W 写
这些快捷键也可以作为开发中文应用软件的标准,但亦可使用汉语拼音的开头字母（不推荐）。
9:安全性考虑：
在界面上通过下列方式来控制出错几率，会大大减少系统因用户人为的错误引起的破坏。开发者应当尽量周全地考虑到各种可能发生的问题,使出错的可能降至最小。
如应用出现保护性错误而退出系统,这种错误最容易使用户对软件失去信心。因为这意味着用户要中断思路,并费时费力地重新登录,而且已进行的操作也会因没有存盘而全部丢失。
安全性细则：
1):最重要的是排除可能会使应用非正常中止的错误。
2):应当注意尽可能避免用户无意录入无效的数据。
3):采用相关控件限制用户输入值的种类。
4):当用户作出选择的可能性只有两个时,可以采用单选框。
5):当选择的可能再多一些时,可以采用复选框,每一种选择都是有效的,用户不可能输入任何一种无效的选择。
6):当选项特别多时，可以采用列表框，下拉式列表框。
7):在一个应用系统中,开发者应当避免用户作出未经授权或没有意义的操作。
8):对可能引起致命错误或系统出错的输入字符或动作要加限制或屏蔽。
9):对可能发生严重后果的操作要有补救措施。通过补救措施用户可以回到原来的正确状态。
10):对一些特殊符号的输入、与系统使用的符号相冲突的字符等进行判断并阻止用户输入该字符。
11):对错误操作最好支持可逆性处理，如取消系列操作。
12):在输入有效性字符之前应该阻止用户进行只有输入之后才可进行的操作。
13):对可能造成等待时间较长的操作应该提供取消功能。
14):特殊字符常有；;’”><,｀‘：“［”｛、\|｝］+=)-(_*&&^%$#@!,.。?/还有空格。（此外，还要注意全角和半角符号的区别）
15):与系统采用的保留字符冲突的要加以限制。
16):在读入用户所输入的信息时，根据需要选择是否去掉前后空格。
17):有些读入数据库的字段不支持中间有空格，但用户切实需要输入中间空格，这时要在程序中加以处理。
10:多窗口的应用与系统资源：
设计良好的软件不仅要有完备的功能，而且要尽可能的占用最底限度的资源。
应用细则：
1):在多窗口系统中，有些界面要求必须保持在最顶层，避免用户在打开多个窗口时，不停的切换甚至最小化其他窗口来显示该窗口。
2):显示多个窗口时，窗口的名称是否被适当地表示？
3):活动窗口是否被适当地加亮？
4):如果使用多任务，是否所有的窗口被实时更新？
5):在主界面载入完毕后自动卸出内存，让出所占用的WINDOWS系统资源。
6):关闭所有窗体，系统退出后要释放所占的所有系统资源 ，除非是需要后台运行的系统。
4):尽量防止对系统的独占使用。美丽的事物常常会让人无法抗拒。这就是为什么产品出色的外观设计对于电脑、汽车、日用品、家具、食品、服装等等几乎所有商品的销售与推广，都有着举足轻重的作用的原因。
同样的道理，对于软件公司来说，软件产品就是他们的商品，而软件界面就是他们产品的外观，界面的美观与否，直接关系到了软件产品的营销成败。
我们可以清楚地看到，微软公司对软件界面设计的重视。请回想一下您在第一次见到win2000时的情景，与nt4.0相比是否惊叹他界面的美观性与易用性？而您如果使用过xp系统，则会被其令人神奇的感官概念而震惊折服！金山公司的金山词霸就是国内软件成功的例子了，从金山词霸3.0到金山词霸2001 的变化堪称经典。著名的网页动画制作软件flash从3.0到4.0，仅仅修改了图标和窗体，立即大为增色…
现今世界上成功的软件公司都非常重视软件界面的美化设计工作，因为他们深刻地知道，在激烈的市场竞争中，仅仅有强大的功能是远远不够的，不足以战胜强劲的对手。我们可以相象一下，您在挑选手机的时候，如果有两款手机，性能相同，而第一款比第二款要美观很多，那么您将选择哪一款呢？当然是美观的那一款了。试想，您的客户，也会拿您和您竞争对手的软件做这样的比较的。
现在的软件企业都知道，广告和市场推销活动对市场营销的作用是多么的重要，并不遗余力地打广告、做活动、做推广。但我们知道，这些活动的最终目的，是为了让用户购买并使用软件产品，而用户最终使用的也是您的产品，那么为什么不在软件界面的美观性上多下些工夫呢？在诸如家用电器、汽车、电脑等成熟的市场中，用非常精美的广告去推广一种功能强大却丑陋无比的产品，是一种笑话。然而，这样的笑话在软件行业里却屡见不鲜。这也是像中国足球一样，中国软件业与国外相比较存在的一个很大的差距。
作者： lwfwind
Link URL: http://www.cnblogs.com/tester2test/archive/2006/07/15/451597.html -
QTP关于验证码的应用解决方法之一
2007-07-12 12:18:22
Dim Input
Input = InputBox("Enter your pic no:")Browser("调查博客").Page("调查博客").WebEdit("ident_code").Set Input
Link URL: http://www.cnblogs.com/tester2test/archive/2006/07/16/452448.html -
持续集成
2007-07-12 12:18:22
英文原文版权由Martin Fowler拥有Original text is copyrighted by Martin Fowler
原文链接：http://martinfowler.com/articles/continuousIntegration.html
Martin Fowler Chief Scientist, ThoughtWorks译者语：
由于这是Fowler先生送给全体中国软件开发者的礼物，所以我绝对不敢独占。任何人都可以在任何地方随意转载本文，但是在转载时请保持本文完整性--包括标题、版权声明、原文链接、译者语……总之，请不要在转载的时候做任何改动或增删。另外，如果能在转载的时候顺手给我一个mail，我会更加高兴。
下面，请开始欣赏这篇精彩的文章。
在任何软件开发过程中都有一个重要的部分：得到可靠的软件创建（build）版本。尽管知道创建的重要性，但是我们仍然会经常因为创建失败而惊讶不已。在这篇文章里，我们将讨论Matt（Matthew Foemmel）在ThoughtWorks的一个重要项目中实施的过程，这个过程在我们的公司里日益受到重视。它强调完全自动化的、可重复的创建过程，其中包括每天运行多次的自动化测试。它让开发者可以每天进行系统集成，从而减少了集成中的问题。ThoughtWorks公司已经开放了CruiseControl软件的源代码，这是一个自动化持续集成的工具。此外，我们还提供CruiseControl、Ant和持续集成方面的顾问服务。如果需要更多的信息，请与Josh Mackenzie（jmackenz@ThoughtWorks.com）联系。
本文有以下主要内容：
持续集成的优点
集成越频繁，效果越好
一次成功的创建是什么样的？
单一代码源
自动化创建脚本
自测试的代码
主创建
代码归还
总结在软件开发的领域里有各种各样的"最佳实践"，它们经常被人们谈起，但是似乎很少有真正得到实现的。这些实践最基本、最有价值的就是：都有一个完全自动化的创建、测试过程，让开发团队可以每天多次创建他们的软件。"日创建"也是人们经常讨论的一个观点，McConnell在他的《快速软件开发》中将日创建作为一个最佳实践来推荐，同时日创建也是微软很出名的一项开发方法。但是，我们更支持XP社群的观点：日创建只是最低要求。一个完全自动化的过程让你可以每天完成多次创建，这是可以做到的，也是完全值得的。
在这里，我们使用了"持续集成（Continuous Integration）"这个术语，这个术语来自于XP（极限编程）的一个实践。但是我们认为：这个实践早就存在，并且很多并没有考虑XP的人也在使用着它。只不过我们一直用XP作为软件开发过程的标准，XP也对我们的术语和实践产生了深远的影响。尽管如此，你还是可以只使用持续集成，而不必使用XP的任何其他部分--实际上，我们认为：对于任何切实可行的软件开发活动，持续集成都是很基本的组成部分。
实现自动化日创建需要做以下几部分的工作：
将所有的源代码保存在单一的地点，让所有人都能从这里获取最新的源代码（以及以前的版本）。
使创建过程完全自动化，让任何人都可以只输入一条命令就完成系统的创建。
使测试完全自动化，让任何人都可以只输入一条命令就运行一套完整的系统测试。
确保所有人都可以得到最新、最好的可执行文件。
所有这些都必须得到制度的保证。我们发现，向一个项目中引入这些制度需要耗费相当大的精力。但是，我们也发现，一旦制度建立起来，保持它的正常运转就不需要花多少力气了。
持续集成的优点
描述持续集成最大的难点在于：它从根本上改变了整个开发模式。如果没有在持续集成的实践环境中工作过，你很难理解它的开发模式。实际上，在单独工作的时候，绝大多数人都能感觉到这种气氛--因为他们只需要与自己的系统相集成。对于许多人来说，"团队开发"这个词总让他们想起软件工程领域中的一些难题。持续集成减少了这些难题的数量，代之以一定的制度。
持续集成最基本的优点就是：它完全避免了开发者们的"除虫会议"--以前开发者们经常需要开这样的会，因为某个人在工作的时候踩进了别人的领域、影响了别人的代码，而被影响的人还不知道发生了什么，于是bug就出现了。这种bug是最难查的，因为问题不是出在某一个人的领域里，而是出在两个人的交流上面。随着时间的推移，问题会逐渐恶化。通常，在集成阶段出现的bug早在几周甚至几个月之前就已经存在了。结果，开发者需要在集成阶段耗费大量的时间和精力来寻找这些bug的根源。
如果使用持续集成，这样的bug绝大多数都可以在引入的同一天就被发现。而且，由于一天之中发生变动的部分并不多，所以可以很快找到出错的位置。如果找不到bug究竟在哪里，你也可以不把这些讨厌的代码集成到产品中去。所以，即使在最坏的情况下，你也只是不添加引起bug的特性而已。（当然，可能你对新特性的要求胜过了对bug的憎恨，不过至少你可以多一种选择。）
到现在为止，持续集成还不能保证你抓到所有集成时出现的bug。持续集成的排错能力取决于测试技术，众所周知，测试无法证明已经找到了所有的错误。关键是在于：持续集成可以及时抓到足够多的bug，这就已经值回它的开销了。
所以，持续集成可以减少集成阶段"捉虫"消耗的时间，从而最终提高生产力。尽管现在还不知道是否有人对这种方法进行过科学研究，但是作为一种实践性的方法，很明显它是相当有效的。持续集成可以大幅减少耗费在"集成地狱"中的时间，实际上，它可以把地狱变成小菜一碟。
集成越频繁，效果越好
持续集成有一个与直觉相悖的基本要点：经常性的集成比很少集成要好。对于持续集成的实践者来说，这是很自然的；但是对于从未实践过持续集成的人来说，这是与直观印象相矛盾的。
如果你的集成不是经常进行的（少于每天一次），那么集成就是一件痛苦的事情，会耗费你大量的时间与精力。我们经常听见有人说："在一个大型的项目中，不能应用日创建"，实际上这是一种十分愚蠢的观点。
不过，还是有很多项目实践着持续集成。在一个五十人的团队、二十万行代码的项目中，我们每天要集成二十多次。微软在上千万行代码的项目中仍然坚持日创建。
持续集成之所以可行，原因在于集成的工作量是与两次集成间隔时间的平方成正比的。尽管我们还没有具体的衡量数据，但是可以大概估计出来：每周集成一次所需的工作量绝对不是每天集成的5倍，而是大约25倍。所以，如果集成让你感到痛苦，也许就说明你应该更频繁地进行集成。如果方法正确，更频繁的集成应该能减少你的痛苦，让你节约大量时间。
持续集成的关键是自动化。绝大多数的集成都可以而且应该自动完成。读取源代码、编译、连接、测试，这些都可以自动完成。最后，你应该得到一条简单的信息，告诉你这次创建是否成功："yes"或"no"。如果成功，本次集成到此为止；如果失败，你应该可以很简单地撤消最后一次的修改，回到前一次成功的创建。在整个创建过程中，完全不需要你动脑子。
如果有了这样一套自动化过程，你随便想多频繁进行创建都可以。唯一的局限性就是创建过程本身也会消耗一定的时间。（译注：不过与捉虫所需的时间比起来，这点时间是微不足道的。）
一次成功的创建是什么样的？
有一件重要的事需要确定：怎样的创建才算是成功的？看上去很简单，但是如此简单的事情有时却会变得一团糟，这是值得注意的。有一次，Martin Fowler去检查一个项目。他问这个项目是否执行日创建，得到了肯定的回答。幸亏Ron Jeffries也在场，他又提了一个问题："你们如何处理创建错误？"回答是："我们给相关的人发一个e-mail。"实际上，这个项目已经好几个月没有得到成功的创建了。这不是日创建，这只是日创建的尝试。
对于下列"成功创建"的标准，我们还是相当自信的：
所有最新的源代码都被配置管理系统验证合格
所有文件都通过重新编译
得到的目标文件（在我们这里就是Java的class文件）都通过连接，得到可执行文件
系统开始运行，针对系统的测试套件（在我们这里大概有150个测试类）开始运行
如果所有的步骤都没有错误、没有人为干涉，所有的测试也都通过了，我们就得到了一个成功的创建
绝大多数人都认为"编译+连接=创建"。至少我们认为：创建还应该包括启动应用程序、针对应用程序运行简单测试（McConnell称之为"冒烟测试"：打开开关让软件运行，看它是否会"冒烟"）。运行更详尽的测试集可以大大提高持续集成的价值，所以我们会首选更详尽的测试。
单一代码源
为了实现每日集成，任何开发者都需要能够很容易地获取全部最新的源代码。以前，如果要做一次集成，我们就必须跑遍整个开发中心，询问每一个程序员有没有新的代码，然后把这些新代码拷贝过来，再找到合适的插入位置……没有什么比这更糟糕的了。
办法很简单。任何人都应该可以带一台干净的机器过来，连上局域网，然后用一条命令就得到所有的源文件，马上开始系统的创建。
最简单的解决方案就是：用一套配置管理（源代码控制）系统作为所有代码的来源。配置管理系统通常都设计有网络功能，并且带有让开发者轻松获取源代码的工具。而且，它们还提供版本管理工具，这样你可以很轻松地找到文件以前的版本。成本就更不成问题了，CVS就是一套出色的开放源代码的配置管理工具。
所有的源文件都应该保存在配置管理系统中。我说的这个"所有"常常比人们想到的还要多，它还包括创建脚本、属性文件、数据库调度DLL、安装脚本、以及在一台干净的机器上开始创建所需的其他一切东西。经常都能看到这样的情况：代码得到了控制，但是其他一些重要的文件却找不到了。
尽量确保所有的东西都保存在配置管理系统的同一棵代码源树中。有时候为了得到不同的组件，人们会使用配置管理系统中不同的项目。这带来的麻烦就是：人们不得不记住哪个组件的哪个版本使用了其他组件的哪些版本。在某些情况下，你必须将代码源分开，但是这种情况出现的几率比你想象的要小得多。你可以在从一棵代码源树创建多个组件，上面那些问题可以通过创建脚本来解决，而不必改变存储结构。
自动化创建脚本
如果你编写的是一个小程序，只有十几个文件，那么应用程序的创建可能只是一行命令的事：javac *.java。更大的项目就需要更多的创建工作：你可能把文件放在许多目录里面，需要确保得到的目标代码都在适当的位置；除了编译，可能还有连接的步骤；你可能还从别的文件中生成了代码，在编译之前需要先生成；测试也需要自动运行。
大规模的创建经常会耗费一些时间，如果只做了一点小小的改动，当然你不会希望重新做所有这些步骤。所以好的创建工具会自动分析需要改变的部分，常见的方法就是检查源文件和目标文件的修改日期，只有当源文件的修改日期迟于目标文件时，才会重新编译。于是，文件之间的依赖就需要一点技巧了：如果一个目标文件发生了变化，那么只有那些依赖它的目标文件才会重新编译。编译器可能会处理这类事情，也可能不会。
取决于自己的需要，你可以选择不同的创建类型：你创建的系统可以有测试代码，也可以没有，甚至还可以选择不同的测试集；一些组件可以单独创建。创建脚本应该让你可以根据不同的情况选择不同的创建目标。
你输入一行简单的命令之后，帮你挑起这副重担常常是脚本。你使用的可能是shell脚本，也可能是更复杂的脚本语言（例如Perl或Python）。但是很快你就会发现一个专门设计的创建环境是很有用的，例如Unix下的make工具。
在我们的Java开发中，我们很快就发现需要一个更复杂的解决方案。Matt用了相当多的时间开发了一个用于企业级Java开发的创建工具，叫做Jinx。但是，最近我们已经转而使用开放源代码的创建工具Ant（http://jakarta.apache.org/ant/index.html）。Ant的设计与Jinx非常相似，也支持Java文件编译和Jar封装。同时，编写Ant的扩展也很容易，这让我们可以在创建过程中完成更多的任务。
许多人都使用IDE，绝大多数的IDE中都包含了创建管理的功能。但是，这些文件都依赖于特定的IDE，而且经常比较脆弱，而且还需要在IDE中才能工作。IDE的用户可以建立自己的项目文件，并且在自己的单独开发中使用它们。但是我们的主创建过程用Ant建立，并且在一台使用Ant的服务器上运行。
自测试的代码
只让程序通过编译还是远远不够的。尽管强类型语言的编译器可以指出许多问题，但是即使成功通过了编译，程序中仍然可能留下很多错误。为了帮助跟踪这些错误，我们非常强调自动化测试--这也是XP提倡的另一个实践。
XP将测试分为两类：单元测试和容纳测试（也叫功能测试）。单元测试是由开发者自己编写的，通常只测试一个类或一小组类。容纳测试通常是由客户或外部的测试组在开发者的帮助下编写的，对整个系统进行端到端的测试。这两种测试我们都会用到，并且尽量提高测试的自动化程度。
作为创建的一部分，我们需要运行一组被称为"BVT"（Build Verification Tests，创建确认测试）的测试。BVT中所有的测试都必须通过，然后我们才能宣布得到了一个成功的创建。所有XP风格的单元测试都属于BVT。由于本文是关于创建过程的，所以我们所说的"测试"基本上都是指BVT。请记住，除了BVT之外，还有一条测试线存在（译注：指功能测试），所以不要把BVT和整体测试、QA等混为一谈。实际上，我们的QA小组根本不会看到没有通过BVT的代码，因为他们只对成功的创建进行测试。
有一条基本的原则：在编写代码的同时，开发者也应该编写相应的测试。完成任务之后，他们不但要归还（check in）产品代码，而且还要归还这些代码的测试。这也跟XP的"测试第一"的编程风格很相似：在编写完相应的测试、并看到测试失败之前，你不应该编写任何代码。所以，如果想给系统添加新特性，你首先应该编写一个测试。只有当新的特性已经实现了以后，这个测试才可能通过。然后，你的工作就是让这个测试能够通过。
我们用Java编写这些测试，与开发使用同样的语言，所以编写测试与编写代码没有太大的区别。我们使用JUnit（http://www.junit.org/）来作为组织、编写测试的框架。JUnit是一个简单的框架，让我们可以快速编写测试、将测试组织为套件、并以交互或批处理的模式来运行测试套件。（JUnit是xUnit家族的Java版本--xUnit包括了几乎所有语言的测试框架。）
在编写软件的过程中，在每一次的编译之后，开发者通常都会运行一部分单元测试。这实际上提高了开发者的工作效率，因为这些单元测试可以帮助你发现代码中的逻辑错误。然后，你就没必要去调试查错，只需要注意最后一次运行测试之后修改的代码就行了。这个修改的范围应该很小，所以寻找bug也就容易多了。
并非所有的人都严格遵循XP"测试第一"的风格，但是在第一时间编写测试的好处是显而易见的。它们不但让每个人的工作效率更高，而且由这些测试构成的BVT更能捕捉到系统中的错误。因为BVT每天要运行好几次，所以BVT检查出的任何问题都是比较容易改正的，原因很简单：我们只做了相当小范围的修改，所以我们可以在这个范围内寻找bug。在修改过的一小块代码中排错当然比跟踪整个系统来排错要有效多了。
当然，你不能指望测试帮你找到所有的问题。就象人们常说的：测试不能证明系统中不存在错误。但是，尽善尽美不是我们唯一的要求。不够完美的测试只要经常运行，也比永远写不出来的"完美测试"要好得多。
另一个相关的问题就是：开发者们为自己的代码编写测试。我们经常听人说：开发者不应该测试自己的代码，因为他们很容易忽视自己工作中的错误。尽管这也是事实，但是自测试过程需要快速将测试转入代码基础中。这种快速转换的价值超过独立测试者的价值。所以，我们还是用开发者自己编写的测试来构造BVT，但是仍然有独立编写的容纳测试。
自测试另一个很重要的部分就是它通过反馈--XP的一项核心价值--来提高测试的质量。这里的反馈来自于从BVT中逃脱的bug。自测试的规则是：除非你在BVT中加入了相应的测试，否则就不能修正任何错误。这样，每当要修正某个错误的时候，你都必须添加相应的测试，以确保BVT不会再把错误放过去。而且，这个测试应该引导你去考虑更多的测试、编写更多的测试来加强BVT。
主创建
创建过程的自动化对于单个开发者来说很有意义，但是它真正发光的，还是在整个系统的主创建（master build）的生成。我们发现，主创建过程能让整个团队走到一起来，让他们及早发现集成中的问题。
第一步是要选择运行主创建的机器。我们选择了一台叫做"投石车"的计算机（我们经常玩"帝国时代"J），这是一台装有四个CPU的服务器，非常适合专门用来做创建。（由于完整的创建需要相当长的时间，所以这种马力是必须的。）
创建进程是在一个随时保持运行的Java类中进行的。如果没有创建任务，创建进程就一直循环等待，每过几分钟去检查一下代码仓库。如果在最后的创建之后没有人归还任何代码，进程就继续等待。如果代码仓库中有了新的代码，就开始创建。
创建的第一阶段是完全提取仓库中的代码。Starteam已经为我们提供了相当好的Java API，所以切入代码仓库也很容易。守护进程（daemon）会观察五分钟以前的仓库，看最近五分钟里面有没有人归还了代码。如果有，守护进程就会考虑等五分钟再提取代码（以免在别人归还代码的过程中提取）。
守护进程将全部代码提取到投石机的一个目录中。提取完成之后，守护进程就会在这个目录里调用Ant脚本。然后，Ant会接管整个创建过程，对所有源代码做一次完整的创建。Ant脚本会负责整个编译过程，并把得到的class文件放进六个jar包里，发布到EJB服务器上。
当Ant完成了编译和发布的工作之后，创建守护进程就会在EJB服务器上开始运行新的jar，同时开始运行BVT测试套件。如果所有的测试都能正常运行通过，我们就得到了一个成功的创建。然后创建守护进程就会回到Starteam，将所有提取出的源代码标记上创建号。然后，守护进程会观察创建过程中是否还有人归还了代码。如果有，就再开始一次创建；如果没有，守护进程就回到它的循环中，等待下一次的归还。
创建结束之后，创建守护进程会给所有向最新一次创建归还了代码的开发者发一个e-mail，汇报创建的情况。如果把创建留在代码归还之后去做，而又不用e-mail向开发者通报创建的情况，我们通常认为这是不好的组织形式。
守护进程将所有的步骤都写在XML格式的日志文件里面。投石车上会运行一个servlet，允许任何人通过它检查日志，以观察创建的状态。（见图1）
屏幕上会显示出创建是否正在运行、开始运行的时间。在左边有所有创建的历史记录，成功的、失败的都记录在案。点击其中的某一条记录，就会显示出这次创建的详细信息：编译是否通过、测试的结果、发生了哪些变化……
我们发现很多开发者都经常看看这个页面，因为它让他们看到项目发展的方向，看到随着人们不断归还代码而发生的变化。有时我们也会在这个页面上放一些其他的项目新闻，但是需要把握好尺度。要让开发者能在自己的本地机器上模拟主创建过程，这是很重要的。这样，如果集成错误出现了，开发者可以在自己的机器上研究、调试，而不必真的执行主创建过程。而且，开发者也可以在归还代码之前先在本地执行创建，从而降低了主创建失败的可能性。
这里有一个比较重要的问题：主创建应该是干净的创建（完全从源代码开始）还是增量创建？增量创建会快得多，但是也增大了引入错误的风险，因为有些部分是没有编译的。而且我们还有无法重新创建的风险。我们的创建速度相当快（20万行代码约15分钟），所以我们乐于每次都做干净的创建。但是，有些团队喜欢在大多数时候做增量创建，但是当那些奇怪的问题突然出现时，也经常性地做干净的创建（至少每天一次）。
图1：运行在投石车上的servlet代码归还（Check in）
使用自动化创建就意味着开发者应该遵循某种节奏来开发软件，最重要的就是他们应该经常集成。我们曾经见过一些组织，他们也做日创建，但是其中的开发者却不经常归还代码。如果开发者几周才归还一次代码，那么日创建又有什么意义呢？我们遵循的原则是：每个开发者至少每天要归还一次代码。
在开始新的任务之前，开发者应该首先与配置管理系统同步。也就是说，他们应该首先更新本地机器上的源代码。在旧的代码基础上编写代码，这只会带来麻烦和混乱。
然后，开发者要随时保持文件的更新。开发者可以在一段任务完成之后将代码集成到整个系统中，也可以在任务的中途集成，但是在集成的时候必须保证所有的测试都能通过。
集成的第一步是要再次使开发者的本地文件与代码仓库同步。代码仓库中所有新近有改动的文件都要拷贝到开发者的工作目录中来，当文件发生冲突时，配置管理系统会向开发者提出警告。然后，开发者需要对同步后的工作集进行创建，对这些文件运行BVT，并得到正确的结果。
现在，开发者可以把新的文件提交到代码仓库中。提交完成之后，开发者就需要等待主创建。如果主创建成功，那么这次归还也是成功的。如果主创建失败了，开发者可以在本地修改。如果修改很简单，就可以直接提交；如果修改比较复杂，开发者就需要放弃这次修改，重新同步自己的工作目录，然后继续在本地开发、调试，然后再次提交。
某些系统强制要求归还进程逐个进行。在这种情况下，系统中会有一个创建令牌，同一时间只有一个开发者能拿到令牌。开发者获取创建令牌，再次同步文件，提交修改，然后释放令牌。这就确保创建过程中，最多只能有一个开发者在更新代码仓库。不过我们发现，即使没有创建令牌，我们也很少遇到麻烦，所以我们也不用这种方法。经常会有多个人同时向同一个主创建提交代码的情况，但是这很少造成创建失败，而且这样的错误也很容易修复。
同时，我们还让开发者自己来决定归还过程中的小心程度。这反映出开发者对集成错误出现几率的评估。如果她觉得很有可能出现集成错误，那么她就会在归还之前先做一次本地创建；如果她觉得根本不可能出现集成错误，那么她可以直接归还。如果犯了错误，在主创建运行时她立刻就会发现，然后她就必须放弃自己的修改，找到出错的地方。如果错误很容易发现、很容易修补，那么这种错误也是可以接受的。
总结
发展一个制度严密的自动化创建过程对于项目的控制是很重要的。许多软件先贤都这样说，但是我们发现，这样的过程在软件开发领域中仍然罕见。
关键是要让所有的事情都完全自动化，并且要经常进行集成，这样才能尽快发现错误。然后，人们可以随时修改需要修改的东西，因为他们知道：如果他们做的修改引起了集成错误，那也是很容易发现和修补的。一旦获得了这些利益，你会发现自己再也无法放下它们。
Link URL: http://www.cnblogs.com/tester2test/archive/2006/07/17/452905.html -
QTP知识点滴积累
2007-07-12 12:18:22
1. dos命令的执行
Dim oShell
Set oShell = CreateObject ("WSCript.shell")
oShell.run "cmd /K CD C:\ & Dir"
Set oShell = Nothing
2.使用可选步骤
OptionalStep.Browser("browser_name").Page("page_name").Link("link_name")默认可选步骤
默认情况下，QuickTest 将打开下列对话框的步骤视为可选：
3. 处理运行错误对话框标题栏
自动完成文件下载Internet ExplorerNetscape输入网络密码错误安全警报安全信息安全警告所需的用户名和密码
- 停止 - 停止运行会话。
如果 QuickTest 配置为在运行后显示测试结果，则会显示测试结果。 - 重试 - QuickTest 尝试再次执行该步骤。
如果该步骤成功，则运行会继续。 - 跳过 - QuickTest 跳过引发错误的步骤，然后从下一步骤继续运行。
- 调试 - QuickTest 暂停运行以便对测试或组件进行调试。
可以执行本章描述的任何调试操作。在调试之后，可以从测试或组件停止的那一步开始继续运行会话，也可以使用单步命令来控制运行会话的其余部分。 - 帮助 - 对于显示的错误消息，打开 QuickTest 故障排除帮助。在查看“帮助”主题之后，可以在错误消息框中选择另一个按钮。
- 详细信息 - 将消息框扩展为显示其他有关错误的信息。
4.
下列语句指示 QuickTest 等待打开“航班表”对话框时最多等待 20 秒。blnDone=Window("Flight Reservation").Dialog("Flights Table").Exist
counter=1
While Not blnDone
Wait (2)
blnDone=Window("Flight Reservation").Dialog("Flights Table").Exist
counter=counter+1
If counter=10 then
blnDone=True
End if
Wend
5. ExecuteFile "c:\test.vbs"
6. msgbox Environment.Value("home")
7.请教不将测试结果记录到日志的语句。
对于已知是错误的验证点，在测试报告中能否记录通过，或者根本不记录呢？Reporter.Filter = NewMode
The mode can be one of the following values:
Mode
Description0 or
rfEnableAll Default. All reported events are displayed in the Test Results.
1 or rfEnableErrorsAndWarnings Only event with a warning or fail status are displayed in the Test Results.
2 or
rfEnableErrorsOnly Only events with a fail status are displayed in the Test Results.
3 or
rfDisableAll No events are displayed in the Test Results.
8.库中不需要有对象存在也可执行：
Dim aaa,bbb
aaa="Login"
bbb="OK"
Dialog("Title:="&aaa).Activate
Dialog("Title:="&aaa).WinButton("text:="&bbb).Click
9.setting的应用举例
If Setting.Exists("Tester Name") Then
Setting.Remove ( "Tester Name")
End IfSetting.Add "Tester Name", "Mark Train"
Setting("Tester Name") ="hello"
MsgBox Setting("Tester Name")
10.qtp 关键字头＋空格（技巧）
Link URL: http://www.cnblogs.com/tester2test/archive/2006/07/20/455425.html - 停止 - 停止运行会话。
-
国外软件测试工程师考试试题
2007-07-12 12:18:22
摘要: 1. 在关于用例（use case）的描述中，错误的是a)用例将系统的功能范围分解成许多小的系统功能陈述b)一个用例代表了系统的一个单一的目标c)用例是一个行为上相关的步骤序列d)用例描述了系统与用户的交互 2.下述说法错误的是a)单元测试又称为模块测试，是针对软件测试的最小单位－程序模块进行正确性检验的测试工作。b)集成测试也叫做组装测试，通常在编码完成的基础上，将所有的程序模块进行有序的、递... 阅读全文
Link URL: http://www.cnblogs.com/tester2test/archive/2006/07/22/457274.html -
Rational Performance Tester与LoadRunner测试结果比对报告
2007-07-12 12:18:22
Rational Performance Tester与LoadRunner测试结果比对报告
为了对比Rational Performance Tester与LoadRunner的测试效果，我对XX系统的登录和A流程这两个测试点，分别用Rational Performance Tester和LoadRunner进行脚本录制，并进行测试执行。下面将二者的测试结果和使用方面进行对比。
1 测试结果对比
注：因为Rational Performance Tester试用版只有5个用户许可证，所以下面的并发用户数以5个为上限。
1.1 登录
测试场景：
模拟不同数量的并发用户登录系统。每个脚本按不同的用户数进行，循环1次。
以下测试结果是在没有工作流数据的前提下进行测试得到的。
测试结果中记录的平均响应时间是包括下载资源（如图片）的时间。
并发用户数
平均响应时间（秒）
LoadRunner
Rational Performance Tester
1
4.8
2.4
3
4.8
3.1
5
5.6
5.6
1.2 A流程
测试场景：
在系统中没有待处理流程的前提下，模拟不同数量的并发用户登录系统。每个脚本按不同的用户数进行，循环1次。
每次执行A流程前，都将数据库的工作流数据清空。
并发用户数
平均响应时间（秒）
LoadRunner
Rational Performance Tester
1
0.8
1.1
3
1.1
1.5
5
1.7
2.6
2 使用对比
对比项
LoadRunner
Rational Performance Tester
界面友好性
纯英文界面
中文界面，系统基于Eclipse平台，界面易于理解。
资源占用情况
进程占用
进程占用的虚拟内存随着测试运行的延续而增加，占用的虚拟内存维持在
测试录制过程
可在录制过程中添加集合点、事务等操作。
登录、退出等只操作一次的部分可放在不同部分（vuser_init，vuser_end）。
在录制过程中不能进行添加事务等操作。
系统没有集合点的概念。
登录退出等只操作一次的步骤和迭代循环的部分录制在一起。
测试执行过程
执行过程中的性能情况可以通过监控界面看到，且信息直观。
执行过程中能看到具体步骤的性能数据，步骤是按照函数来分的。
执行速度稳定，不同次数执行测试所需的时间差距不大。
执行过程中可以通过不同的Tab页面查看性能数据。
执行过程中可以看到阶段的性能数据。阶段划分颗粒较大，是按照HTTP页来划分的。
执行过程不稳定，时快时慢。
测试执行结果
相对较稳定，正常情况下几次执行的测试数据偏差不大。
执行结果的数据差距比较大。
下载资源所需响应时间的隔离
较麻烦
可以通过创建事务的方法来区分提交请求与下载资源的所需时间。
事务的定位
容易
事务准确定位比较不方便，需要对系统有一定的熟悉才能准确定位。如果定位不准确，会导致测试结果有较大偏差。
对客户端要求
较低
较高。现有笔记本配置，随着执行时间的延长，机器会运行越来越慢。必须重启RPT方可继续执行测试。
3 小结
对比上述Rational Performance Tester和LoadRunner的测试数据，差距不是很大。但是由于Rational Performance Tester的事务设置不如LoadRunner直观和易于操作，事务的定位对测试结果的准确性影响很大。例如：5个用户发起A流程时，如果事务没有设置好，得到的平均响应时间是14.2秒；经过重定位得到的平均响应时间是2.6秒。另外，测试时，资源耗费较大，对测试客户机也是一个挑战。
Link URL: http://www.cnblogs.com/tester2test/archive/2006/07/28/461819.html -
使用 Windows 命令行删除结果
2007-07-12 12:18:22
使用 Windows 命令行删除结果
使用 Windows 命令行可以指示测试结果删除工具根据指定的条件删除测试结果。例如，您总是可以删除早于特定日期或超过最小文件大小的测试结果。
从命令行运行测试结果删除工具：
打开 Windows 命令提示符并键入
\ bin\TestResultsDeletionTool.exe ，然后键入空格并键入要使用的命令行选项。有关详细信息，请参阅命令行选项。注意：如果使用 -Silent 命令行选项运行测试结果删除工具，则将删除所有满足指定条件的测试结果。否则，将打开“删除测试结果”窗口。
命令行选项
使用命令行选项可以为要删除的测试结果指定条件。以下是每个命令行选项的描述。
注意：如果添加包含空格的命令行选项，则必须在引号内指定该选项，例如：
TestResultsDeletionTool.exe -Test "F:\Tests\Keep\web objects"
-Domain Quality_Center_domain_name
指定要连接到的 Quality Center 域的名称。此选项应该与 -Server、-Project、
-User 和 -Password 选项结合使用。-FromDate results_creation_date
删除指定日期后创建的测试结果。不删除在此日期或之前创建的结果。日期的格式为 MM/DD/YYYY。
以下示例删除 2002 年 11 月 1 日之后创建的所有结果。
TestResultsDeletionTool.exe -Silent -Test "C:\tests\test1" -FromDate "11/1/2002"
-Log log_file_path
创建一个日志文件，其中，指定文件夹或测试中的每个测试结果文件都包含一个条目。日志文件指示哪些结果已删除，以及没有删除其他结果的原因。例如，如果结果小于指定的最小文件大小，则不会删除它们。
可以指定文件路径和名称，或使用默认路径和名称。如果没有指定文件名，则默认的日志文件名为 TestResultsDeletionTool.log，位于测试结果删除工具所在的文件夹中。
以下示例创建一个 C:\temp\Log.txt 日志文件。
TestResultsDeletionTool.exe -Silent -Log "C:\temp\Log.txt" -Test "C:\tests\test1"
以下示例在测试结果删除工具所在的文件夹中创建一个名为 TestResultsDeletionTool.log 的日志文件。
TestResultsDeletionTool.exe -Silent -Log -Test "C:\tests\test1"
-MinSize minimum_file_size
删除大于或等于指定最小文件大小的测试结果。按字节指定大小。
注意：-MinSize 选项只适用于文件系统中的测试结果。在 Quality Center 中使用测试时该复选框不受支持。
以下示例删除大于等于 10000 字节的所有结果。不删除小于 10000 字节的结果。
TestResultsDeletionTool.exe -Silent -Test "C:\tests\test1" -MinSize "10000"
-Name result_file_name
指定要删除的结果文件的名称。将只删除指定名称的结果。
使用正则表达式可以为要删除的结果文件指定条件。有关正则表达式和正则表达式语法的详细信息，请参阅了解和使用正则表达式。
以下示例删除名为 Res1 的结果。
TestResultsDeletionTool.exe -Silent -Test "C:\tests\test1" -Name "Res1"
以下示例删除名称以 Res 开头并加上另一个字符的所有结果。（例如，将删除 Res1 和 ResD，但不删除 ResDD。）
TestResultsDeletionTool.exe -Silent -Test "C:\tests\test1" -Name "Res."
-Password Quality_Center_password
指定 Quality Center 用户名的密码。此选项应该与 -Domain、-Server、-Project 和 -User 选项结合使用。
以下示例使用 http://QCServer/qcbin 上的服务器、名为 Quality Center_Demo 的项目、以及 Admin 用户名和 PassAdmin 密码，连接到 Default Quality Center 域。
TestResultsDeletionTool.exe -Domain "Default" -Server "http://QCServer/qcbin" -Project "Quality Center_Demo" -User "Admin" -Password "PassAdmin"
-Project Quality_Center_project_name
指定要连接到的 Quality Center 项目的名称。此选项应该与 -Domain、
-Server、-User 和 -Password 选项结合使用。-Recursive
从指定文件夹及其子文件夹中的所有测试中删除测试结果。使用 -Recursive 选项时，-Test 选项应包含要删除的测试结果所在的文件夹路径（而不是特定测试的路径）。
以下示例删除 F:\Tests 文件夹及其所有子文件夹中的所有结果。
TestResultsDeletionTool.exe -Test "F:\Tests" -Recursive
注意：-Recursive 选项只适用于文件系统中的文件夹。在 Quality Center 中使用测试时该复选框不受支持。
-Server Quality_Center_server_path
指定要连接到的 Quality Center 服务器的完整路径。此选项应该与
-Domain、-Project、-User 和 -Password 选项结合使用。-Silent
指示测试结果删除工具在后台运行，而不显示用户界面。
以下示例指示测试结果删除工具在后台运行，并删除 C:\tests\test1 中的所有结果。
TestResultsDeletionTool.exe -Silent -Test "C:\tests\test1"
-Test test_or_folder_path
设置测试结果删除工具将从中删除测试结果的测试或测试路径。可以指定测试名和路径、文件系统路径或完整的 Quality Center 路径。
此选项必须与 -Silent 选项结合使用。
注意：必须使用 -Domain、-Server、-Project、-User 和 -Password 选项连接到 Quality Center。
以下示例删除 F:\Tests\Keep\webobjects 测试中的所有结果。
TestResultsDeletionTool.exe -Test "F:\Tests\Keep\webobjects"
以下示例删除 Quality Center Tests\webobjects 测试中的所有结果：
TestResultsDeletionTool.exe -Domain "Default" -Server "http://QCServer/qcbin" -Project "Quality Center_Demo592" -User "Admin" -Password "PassAdmin" -Test "Subject\Tests\webobjects"
注意：-Test 选项可以与 -Recursive 选项结合使用以删除指定文件夹及其子文件夹中的所有测试结果。
-UntilDate results_creation_date
删除指定日期前创建的测试结果。不删除在此日期或之后创建的结果。日期的格式为 MM/DD/YYYY。
此选项必须与 -Silent 选项结合使用。
以下示例删除 2002 年 11 月 1 日之前创建的所有结果。
TestResultsDeletionTool.exe -Silent -Test "C:\tests\test1" -UntilDate "11/1/2002"
-User Quality_Center_user_name
指定要连接到的 Quality Center 项目的用户名。此选项应该与 -Domain、
-Server、-Project 和 -Password 选项结合使用。此选项必须与 -Silent 选项结合使用。
Link URL: http://www.cnblogs.com/tester2test/archive/2006/07/28/462238.html -
国内软件测试中文书籍大全
2007-07-12 12:18:22
标题搜索
我的存档
数据统计
- 访问量: 271495
- 日志数: 689
- 建立时间: 2006-12-05
- 更新时间: 2009-04-15
