|
|
2005年5月20日
2007年7月18日，女儿出生了。
今天女儿一周岁了。
最近很活泼，说话不停，我们听不懂她说些什么。
身高超过了80厘米
牙齿4颗
一周岁要抓揪吗？现在这个时代抓些什么呢？
女儿终于在9个月刚满的时候长出了2颗牙齿！
同步长出2颗。
记录
每天下班最高兴的事情就是抱着女儿，看看她胖胖的小手，小脸，稀疏的头发。 昨天下班回去抱着女儿的时候，老婆拿了一个围兜过来(如果您不知道 围兜是什么，哈哈，就说明你还没有孩子，通俗的说，就是挡住口水往衣服上滴，要滴也要先滴到围兜上)，让我打个劫？ 我说：“什么？打个劫？打什么劫”。 她说：“你有什么可以劫的？让你把围兜打个结”
最近几天浏览器出毛病了，奇怪的以为是中了病毒。
提示错误：您正使用低版本的IE浏览器，建议您升级到Firefox。
紧接着去官方firefox官方网站下载了浏览器，安装好以后公司的首页竟然不能正常显示.
算了，卸载了。后来我升级IE7.0。这样看起来顺眼多了，这个错误还是一样的，难道真的是病毒。
用诺顿猛地查了一上午，没有发现任何可疑文件。一个同事提醒，可能是IE的Add-on功能加载了很多Dll导致的，果然看到如下的可疑东西，禁止掉。这个错误没有了。如下图：
在真正使用IE7的时候，发现不能打开新的Tab页面，不顺的时候真的什么都不顺。
改了很多设置，有人说，不在Tabs->setting那里去弄，而是在Advanced，哈，还是没有找到。然后去查找注册表，找到了对应的健值，改了2个，关掉浏览器。重新打开，这次竟然好了，然后再去看设置。发现了，原来是在控制pop-up那里的问题，正确的设置如下图
当然，一个显而易见的理由就是新开发的程序需要分配事务代码。
那么，作为sap实施顾问，关注是配置系统。
执行SAP标准事务代码时，可能需要输入一些参数，对于经常使用且参数变化不多的事务，可以自定义
一个或者多个事务代码，把参数定制为代码的预设值，不需要重复输入，从而减少数据输入量，加快输入工作。
除了SE38代码编辑器提供的Ctrl+F2提供的基本语法检查功能外，SAP的workbench还提供了更加强大的语法检查功能，可以检查引用程序或者功能模块的语法，静态断点以及子程序、功能模块和主程序之间的接口类型兼容检查。这些检查功能要通过T-Code: SLIN来进行。
步骤如下：
1．在ABAP编辑器的初始界面中输入程序名后，选择Program->check->Extended Syntax Check菜单项。
2．选择需要检查的语法选项，并单击Standard按钮。
3．系统将显示程序中的错误、警告和提示消息列表。
4．如果程序出现错误，可以双击该错误，浏览更为详细的信息。
摘要: 我们这个社会变得越来越冷漠，越来越没有人性，为什么？
近年来经常听到这样一句老话：可怜之人必有可恨之处。这样的话，在感情上很难让人接受，但只要正视现实，又不能不承认这话有几分道理。一个人生存的处境令人可怜，这已经是一种可悲的事情；处境可怜而又由于自身的毛病让人觉得可恨，实则是一种更深的悲哀。 阅读全文
假设在宇宙中存在着这样一个星球，在那里人第二次来到世上，同时还清清楚楚地记得以前在地球上的人生和在尘世间获得的所有经历。
也许还存在着另一个星球，在那里人可以第三次来到世上，带着前两次活过的人生经验。
也许还有许许多多的其他的星球，在那里人类可以不断地重生，每一次重生都会提高一个层次(也就是多一次人生经验)，日臻成熟。
这就是托马斯心目中永恒的轮回。
我们这些在地球(也就是一号星球，尚无前世经验的星球)上的人，对于其他星球上人类有可能发生的一切当然只能有个十分模糊的想法。人会更聪明一些吗？成熟之境对人来说是不是唾手可得呢？人能通过不断重生得此境界吗？
只有在这种乌托邦式的前景中，悲观和乐观的概念才具有一定的意义：凡认为人类历史在五号星球上会变得不那么血腥的，为乐观主义者。凡不这么认为的，则为悲观主义者。
《不能承受的生命之轻》米兰.昆拉
以前家里的空调，电视机，洗衣机，电冰箱等电器都是在苏宁买的，从购买、送货、安装到售后服务都感觉不错，比较贴切，比较人性化。今年五一节，又买了一台三星空调，这次去了永乐家电，也不知道为什么没有去苏宁？也许一直去苏宁买，好也不知道坏也不知道(当然不是指货物品质的好坏，而是两家的销售服务、配送流程和安装服务如何？现在这个微利时代拼的就是服务了)也算是体会一下永乐(国美收购永乐以后不知道该应该写永乐还是写国美)和苏宁的区别。
5月2号下午去永乐共康店转了转，人声鼎沸啊，人民的消费热情空前高涨。买了两节照相机的充电电池后，到了空调专柜看了看海尔，TCL，小日本的三菱、日立，然后在一款三星的空调面前停住了脚步。外观不错，价格实惠，关键还是个新型号的，我的房间不大，1P到1.5P足够。男人买东西就这样，看好了立马下订单，刷卡，走人，前后不过30分钟(刷卡排队人很多)。我本来要他们5月4号送货的，但是按照订单的意思是5月5号送空调，5月6号安装，也好，体谅体谅人家节日里安排不过来。
5月5号在家里等了一天，直到要吃晚饭了，还是没有来。吃好饭，翘首以待，望眼欲穿哪！无奈之下拨打了n遍的永乐服务热线8008207777，一直都是服务接线员忙。纳闷？生意真的这么好？一直打到晚上9点仍然没有一个"人"接电话，9点刚过，就听到了“现在是下班时间，请留言....”我现在彻底怀疑这个热线号码后边根本没有人在服务。 此时我联系了永乐的销售人员，说他也查不到货物是否发出，订单说是5号送就一定能够送到，请您耐心等待。&*&*^&^&%*&*@&^,我气愤了。永乐的物流配送可见一斑，以前在苏宁购买的时候，一般送货时间是客户来定的，而且会有经常电话联系。永乐让我等到晚上九点多都不见一个电话？我甚至怀疑我的号码他们是否写对了，认真地查看了一下发票，没有错。彻底没有语言了，大概9点45分，电话响了，是送货司机打的，说是马上过来。好吧，那就过来吧，反正都这么晚了。说不定司机师傅连晚饭还没有吃呢，我不想怪他，他也是无辜的，最终货物在晚上10点多的时候放进了我家。今天也就是5月6号，下午3点多安装的师傅来了电话，说是马上过来，看来还好，他们今天不会让我等太久。
我不大清楚像永乐、国美、苏宁内部的销售、物流配送、安装、售后服务流程是怎么走的？但是仅物流这块，从一个最终消费者的角度看，永乐做的远不如苏宁。买空调的当天，恰巧买了一本5月份的商界杂志，第一篇就是介绍“苏宁”的，文章题目是“苏宁帝国征战史”，应该算是一篇特约访谈，苏宁老板：张近东如何从南京走向全国，苏宁与南京国有八大商场的交战，以及与国美的一次正面交锋，写得有如神来。
说了这么多，还是回到主题：买电器到苏宁？买电器到苏宁!!!
离开2年了，五一节决定回归了，
聊以纪念。
Koffer
Six Thinking Hats® is a simple, effective parallel thinking process that helps people be more productive, focused, and mindfully involved. And once learned the tools can be applied immediately!
You and your team members can learn how to separate thinking into six valuable functions and roles. Each thinking role is identified with a colored symbolic "thinking hat." By mentally wearing and switching "hats," you can easily focus or redirect thoughts, the conversation, or the meeting.
· The White Hat calls for information known or needed. "The facts, just the facts."
· The Yellow Hat symbolizes brightness and optimism. Under this hat you explore the positives and probe for value and benefit
· The Black Hat is judgment - the devil's advocate or why something may not work. Spot the difficulties and dangers; where things might go wrong. Probably the most powerful and useful of the Hats but a problem if overused.
· The Red Hat signifies feelings, hunches and intuition. When using this hat you can express emotions and feelings and share fears, likes, dislikes, loves, and hates.
· The Green Hat focuses on creativity; the possibilities, alternatives, and new ideas. It's an opportunity to express new concepts and new perceptions.
· The Blue Hat is used to manage the thinking process. It's the control mechanism that ensures the Six Thinking Hats® guidelines are observed.
Edward de Bono提出的六项思考帽是一个全面思考问题的模型，<b>用以帮助人们面对复杂情境或挑战时，采取不同的思考角度和方法。 在制定战略和进行决策的场合，往往要求多角度考虑问题
六项思考帽技术能够帮助我们个人改变传统因循的思考方式，有意地去探索一些全新的思考角度。 人们通过戴上一定特殊的思考帽，扮演一个特定的角色，就“好像”他们自己就是这个角色，就像角色所要求的一样在思考。 例如，为了讨论的需要，某个人可能扮演一个吹毛求疵的角色， 这个角色要求故意找茬挑刺，提出对其他意见的不同看法， 也即总是采取一种批评的态度，找出其他观点错误的地方。
· 白帽（资料与信息）：白皮书， 中立， 集中于提供信息、客观事实，他人所需要的以及如何获取。
· 红帽（直觉与感情）：火热，温暖， 富有情感，全凭直觉， 提供不做辩解的观点。
· 黑帽（逻辑与批判）：苛于他人观点， 好做判断、 批评， 认为他人观点总是错的， 消极逻辑观。
· 黄帽（积极与乐观）：充满阳光， 乐观向上， 积极逻辑观， 总是寻找好的一面。
· 绿帽（创新与冒险）：植物的生命的颜色， 创造性思维， 积极假设并探索可能性， 酝酿新主意。
· 蓝帽（系统与控制）：天空的颜色， 给人以凉爽的感觉， 提供信息概要， 执行对流程、步骤以及对其他思考帽的控制功能， 领袖和组织者， 关于思考的思考。
资料来自 http://www.debonogroup.com/6hats.htm
http://www.12manage.com/methods_bono_six_thinking_hats_zh.html
昨天收到一个短消息：
二月二龙抬头，
幸福快乐没有头，
今后好事不断头，
万般好运找上头。
小心钞票砸伤头，
有情亲情暖心头，
合家团圆到白头，
收到短信好兆头。
以前一直以为是三月三龙抬头，收到这个短消息以后，我还跟他争论了一下，结果他让我去剪头，弄得我更加一头雾水。
今天查了一下，果然啊，我对于我国古代的这种风俗习惯就没怎么了解。
民间传说，每逢农历二月初二，是天上主管云雨的龙王抬头的日子；从此以后，雨水会逐渐增多起来。因此，这天就叫"春龙节"。 我国北方广泛的流传着"二月二，龙抬头；大仓满，小仓流。"的民谚。
每当春龙节到来，我国北方大部分地区在这天早晨家家户户打着灯笼到井边或河边挑水，回到家里便点灯、烧香、上供。旧时，人们把这种仪式叫做"引田龙"。这一天，家家户户还要吃面条、炸油糕、爆玉米花，比作为"挑龙头"、"吃龙胆"、"金豆开花，龙王升天，兴云布雨，五谷丰登"，以示吉庆。
春龙节的来源，在我国北方民间流传着这样一个神话故事。说，武则天当上皇帝，惹恼了玉皇大帝，传谕四海龙王，三年内不得向人间降雨。不久，司管天河的龙王听着民间人家的哭声，看着饿死人的惨景，担心人间生路断绝，便违抗玉帝的旨意，为人间降了一次雨。玉帝得知，把龙王打下凡间，压在一座大山下受罪，山上立碑：
龙王降雨犯天规，当受人间千秋罪；
要想重登灵霄阁，除非金豆开花时。
人们为了拯救龙王，到处找开花的金豆。到了第二年二月初二，人们正在翻晒玉米种子时，想到这玉米就像金豆，炒一炒开了花，不就是金豆开花吗？就家家户户爆玉米花，并在院子里设案焚香，供上开了花的"金豆"。龙王抬头一看，知道百姓救它，便大声向玉帝喊到："金豆开花了，快放我出去！"；玉帝一看人间家家户户院里金豆花开放，只好传谕，诏龙王回到天庭，继续给人间兴云布雨。从此，民间形成了习惯，每到二月初二这一天，人们就爆玉米花吃。
其实，在农历二月以后，"雨水"节气来临，冬季的少雨现象结束，降雨量将逐渐增多起来，这本来就是华北季风气候的特点。
很久都没有出去走走了，恰巧公司有这样的一个活动--西塘古镇一日游，也许是因为汤姆·克鲁斯与碟中碟3的关系，才让很多人开始关注西塘，这样一个幽静的古镇。就在出发前的一天晚上，又看了一遍碟中碟3，希望能够在第二天寻找到一点点的足迹。
早晨很早就出发了，所有人马兵分三路：中山公园、世纪公园和杭州三队人马开赴西塘。我是从中山公园出发的，首先到了一个叫做“枫泾”的中途停车站，公司采购了一批粽子（五芳斋），花去不少银子。
车子很快就驶入了西塘，古镇西塘位于浙江省嘉兴市嘉善县，西塘是一座已有千年历史文化的古镇。早在春秋战国时期就是吴越两国的相交之地，故有“吴根越角”和“越角人家”之称。刚进入小镇，我忽然觉得回到了某个年代，老人们在马路边的美人靠上(后边再讲为何叫做“美人靠”)晒着太阳，各式客栈林立，大街上叫卖着各式的江南小吃，臭豆腐味道飘香两岸。
看看我们的行程：张正根雕艺术管，瓦当陈列馆，烟雨长廊，西园，石皮弄，七老爷庙，王宅，纽扣博物馆，倪天增祖居，五福桥，圣堂，黄酒陈列馆，卧龙桥等等数十个景点，都包含在一张门票中60元。活动分为上午和下午两个部分，每个景点都有几个旅游公司的人检票。也许是镇子太小了，而且各条小弄、小巷子都通透，巷子口都有本地的大娘、大婶在看守，想想看增加了多少就业机会啊！
桥是西塘的一个特色，俨然是他们的重要的交通通道，从每一个桥上看过去的景色都像是碟中碟3中的场景。
这里的桥以石桥居多，房屋都是白墙黑瓦，房顶都是单面朝院子里。跨过了卧龙桥，观看了黄酒陈列馆以后，我们几个就到处乱跑，反正就是过几个桥就到了，不小心窜到了菜市场，一个同事看到这里的黄瓜不错--个个都是顶花带刺的，就忍不住买几个来吃。卖菜的大娘很朴实，我们说要洗一下，她就扔下她的菜摊跟我们去了一个有水龙头的地方。
穿过了很多民居（如果用城市的眼光看这些房屋基本属于危房：房屋的支撑木经历历史的洗礼已经要掉渣了，墙壁都是空心的，不知道是为了通风，还是节省开支），到了圣堂，有一个临水的亭子，导游说我坐的那个地方叫美人靠，大伙都在笑。其实是古代闺中女子不能轻易下楼外出，寂寞时只能倚靠在天井四周椅子上，遥望外面的世界，或窥视楼下迎来送往的应酬，故雅称此椅为“美人靠”。如下图：
过了五福桥，就到了倪天增祖居，上了点年纪的上海人都记得这位曾经的上海市副市长，1961年毕业于清华大学建筑系，主管上海市的城市建设工作。 上海人民赞誉他为"风雨市长"、"平民市长"，身居领导岗位风里来、雨里去，为人民办好事，办实事。在这里看到的是一个书香门第，宽广院落，俨然在古代也是一个大户人家。
快要离开的时候，有几个同事说，只有在这里住一晚才能真正体会江南小镇的风情，才能体会西塘古镇的热情，才能对得起脚下有灵性的石板路。为什么要对得起石板路？因为大家都习惯了城市的生活，特别是在上海，地铁通道里、马路上大家走路的节奏，似乎时间永远都不够用！忽然来到这样一个安静的与世无争的地方，细细品味地下的石板路是另外一种境界。脚下的石板路也许在无意间提醒着来到这里的游客，请用你的脚触摸到他们的每一个，这样你就有机会了解一个真正的西塘。
经常在Software Test & Performance 上看到Scott Barber，今天看了他的采访内容。很了不起的一个性能测试技术出身的CTO，先看一直困惑我的Load Test和Stress Test的区别。
Load testing is testing your application under expected load conditions to determine the overall performance.
Stress testing is testing your application under unexpected or extreme conditions to determine the failure modes so you can protect aginst them.
I think stress testing is a run-to-death test.
http://www.scottbarber.com/
Come From http://www.whatistesting.com/interviews/sbarber.htm
| 1. Scott, please tell us something about yourself. |
I was born in Woodbury, NJ USA in 1971 and grew up in a typical American small town. As a child I was very active in school, sports and Boy Scouts. Growing up, the goals I had for myself in adulthood included:
- Getting to travel and “see the world”
- Get a good college education
- Get out of small-town America
- Be recognized as a success in my career (as with most young people in the USA my specific career choice changed many times as I grew up)
- Be a father who is active in his children’s lives and activities.
- Design and build my own home.
I left “small-town America” to attend Virginia Tech on a U.S. Army ROTC Scholarship to pursue a degree in Civil Engineering. After four years, I completed a Bachelor’s of Science in Civil Engineering and started my 4-year active duty commitment in the U.S. Army as a Second Lieutenant (2LT). I later went back to school at night to earn a Master’s Degree in Information Technology. My career has taken a rather wandering, but in retrospect an extremely beneficial, path to finally land in the area of Software Testing.
I spent 4 successful, but difficult years in the U.S. Army culminating as a Company Commander for the 101st Airborne Division, Air Assault Headquarters and Headquarters Company approximately 8 years before I was technically qualified to hold the position. As a junior Captain at the end of my 4 years, I was recruited into a government consulting company to be an Information Engineer on a team that was designing and building a system to replace the computer system I most often complained about while I was on active duty. I held this position for about 1½ years while becoming increasingly more technical before I went to a small private software development company with the intent of becoming an Oracle Database Administrator, but actually ended up spending 6 months as a Configuration Manager. During that time, I learned a ton about Databases, Configuration Management, development and networking. Most importantly, I learned that none of those were what I wanted to do day in and day out. 6 months later, that company was bought by a huge, publicly traded conglomerate that resulted in a significant reduction in pay, leading me to seek a new job. This is when I was recruited into a Performance Test Consulting job by an old college friend where I spent the next 4 years. This time as a consultant is where most of my performance testing experience comes from. After 4 years of consulting, my family and I decided it was time to move. As it turned out, we moved to Florida about the same time the consulting company went through a major re-organization leading me to re-think what I wanted to do next in my career. After a long and difficult 4 months of soul searching, I ended up taking a wonderful position as a Systems Test Engineer and Software Test Manager at my current company AuthenTec, Inc.
As far as my childhood goals are concerned, I have had a chance to travel more than I ever thought I would, but have plenty left to do. I achieved my educational goals, but have a passive interest in earning a Doctorate degree someday. After living in a wide variety of places, I have finally settled in a place that feel like “home” and am very content with my career progression so far.
I have two young boys who are the greatest joy in my life. As I write this, it is with thoughts of my older boy starting school tomorrow morning and my youngest learning to talk. I guess that means that the only childhood goal I have left is to design and build that house. Luckily, I continue adding goals, so I’m far from bored. |
|
2. You specialize in performance testing. What drew you to it? How did you get started, and what led you to start writing about it? |
One Sunday evening I got a call from my manager…
“Scott, be at the Marriott Hotel Conference Room at 8am tomorrow. Our CEO has an announcement to make.”
Being a good employee, I did as I was told and went to the meeting. As it turns out, our software development company was “merging” with a huge media company. We were going to become their “development branch”. As a result, we were giving up our bonuses, overtime, and our base pay was being reduced, but we were going to get stock options.
As one might imagine, I was less than enthusiastic about this. I called my friend of 10 years before I even left the parking lot of the hotel. I told him the circumstances and asked him if he’d help me update my resume, to which he responded:
“Dude, that sucks. Send me your resume I’ll take a look, but, we need performance engineers. You’d be a perfect fit.”
I said “Performance engineer? What’s that?!?”
He replied “Don’t worry, you’ll like it.”
He was right, I’ve loved every minute of it! Since then I have dedicated my professional career to this field. It has been a wonderful ride so far.
After a few years, people started approaching me to write about what I do. I never though of myself as much of a writer, so I hesitated and stalled. (Mind you, I was the Civil Engineer in college who avoided writing classes at ALL COSTS. When they finally told me that if I didn’t take a writing course I wouldn’t graduate, I went to the smallest, least reputable, community college I could find, took the course and transferred it!) Eventually, I agreed to create the Performance Engineering section of my company’s Best Practices. Some folks thought it was good and started selling me to other companies to write their procedures. Finally, my boss talked me into trying my hand at writing articles. I really didn’t think anyone would read them, but I wrote a few anyway. As it turns out, people did read them, and liked them.
|
3. What fascinates you in performance testing?
|
Most simply, I am fascinated by the diversity of it. As my meandering career path let me to this field, I had a lot of “false starts” in other branches of software development, I learned that regardless of my degree of success in those more narrow branches, I found myself becoming easily bored. As a technical tester, specifically as a performance tester of multi-user distributed systems, I get to apply aspects of all of those branches and more in new and unique ways on every project I do. This diversity from project to project is also what led me to embrace the Context-Driven School of software Testing and ultimately become friends with such software testing thought leaders as Cem Kaner and James Bach.
|
|
4. If one wants to gain expertise in performance testing what all should one do? What are the tools, books and sites that can be helpful? |
There is very little consolidated information out there about the type of performance testing that most organizations need. There is no doubt that my site (http://www.perfetsplus.com) and articles are one of the most complete references for “Practical Performance Testing”. However, it is by no means complete. Some of the other places I have learned valuable lessons that I have applied to performance testing are:
- Everything I can find written by Alberto Savoia
- Lessons Learned in Software Testing, John Wiley & Sons, 2002 by Cem Kaner, James Bach and Brett Pettichord.
- Testing Computer Software (2nd Ed.), International Thomson Computer Press, 1993 by Cem Kaner, Jack Falk, & Hung Quoc Nguyen.
- Select Chapters from The Web Testing Handbook, STQE Publishers, 2001 by Steve Splaine and Stefan P. Jaskiel.
- Research published by performance tool vendors.
- Research published by testing and research organizations such as Nielsen//NetRatings, Keynote Systems, Inc., and IEEE
- Online forums and magazines such as StickyMinds.com, QAForums.com and stpmag.com and performancetester.com.
- Performance Engineering of Software Systems, Addison-Wesley, 1990 by Connie U. Smith, Ph.D.
- Scaling for E-Business: technologies, models, performance, and capacity planning, Prentice Hall, 2000 by Daniel A. Menascé, Ph.D.
- Speed Up Your Site, New Riders, 2003 by Andrew B. King
- Anything by Cem Kaner, James Bach, Jerry Weinburg and/or Edward Tufte.
These days, I continue learning through networking with experts, being a technical editor for new performance related publications, beta testing tools, hosting and/or attending workshops and conferences and assisting with research being led by other experts and students in the field.
To really grow your career as a performance tester, I believe there are several things you can do that will gain you largest benefit.
- Become a “Mid-Level Everything” – Developer, DBA, Network Admin, Systems Admin, Architect, Business Analyst, etc.
- Become an expert in the following – your tools, performance analysis, relevant aspects of operational research and statistics, consolidating, interpreting, sorting, and graphically presenting complex information in an intuitive format.
- Become skilled/knowledgeable in the following areas – group facilitation, product management and training.
- Find a mentor. There are several exceptional performance testers out there who believe in Jerry Weinburg’s consulting principle “Give your best work away for free.” Befriending one (or more) of them to ask questions of, share ideas and brainstorm with is amazingly useful… to everyone involved.
|
|
5. What is your opinion about the state of performance testing tools? Are there some open source or free tools available? |
Most tools on the market aren’t actually Performance Testing tools, they are Load Generation tools. No matter what the tool vendors claim, they do not make performance testing simple, they do not analyze results, and they do not pinpoint performance issues. They are virtually all grossly overpriced, and never believe the demo. That said, I have a favorite tool that I support heavily… with a long list of caveats. My favorite is my favorite because it allows me to create realistic loads by writing custom functions and procedures in C – rather than trying to guess how to make the silly GUI buttons duplicate the workload I have constructed.
The best OpenSource tool for general web based load generation is OpenSTA. As long as you are only testing websites, it is competitive with the major (pay) tools in terms of actual ability to generate load and collect data. There are plenty of other free niche tools for specific platforms and protocols, but they are only useful to small groups of people doing very specific types of testing.
|
| 6. How do you combine performance testing with load and stress testing |
Actually, I see Performance Testing as a superset of testing that includes load and stress testing. I often refer to it as “Performance Related Testing”. In general, load testing is testing your application under expected load conditions to determine the overall performance. Stress testing is testing your application under unexpected or extreme conditions to determine failure modes so you can protect against them. In my presentation “Introduction to Performance Testing; The Who, What, Where, When and Why.” (available here) I describe various components of Performance Testing, and the process in general. |
|
7. What is WOPR? How did it happen? Who all are involved in it and what is your role? |
WOPR is the Workshop On Performance and Reliability (http://www.performance-workshop.org). Ross Collard and I co-founded this workshop about a year ago with the purpose of bringing together both Performance Testing Experts and “Enthusiastic Beginners” in a forum where we can share our experiences together in a format that encourages questions, critical thinking and learning. So far, we have had three very successful workshops and plan to continue having them in the spring and fall of every year. You can find out more from the website. The workshop is limited to 20 people per meeting and is by invitation only, but you can apply for an invitation by filling out the form on the website. |
|
8. How is performance testing for consumer applications different from enterprise/server based applications? |
There is actually less difference between consumer applications and enterprise/server based applications than there can be between any two individual applications in the same category. The real difference centers around performance expectations. One of the keys to effective performance testing is the ability to collect and classify requirements and then develop tests that verify those requirements. |
|
9. Where do you think performance testing fits in the testing life cycle? Should it be done early or should it be done late? What are the pros and cons and how do you decide? |
There are actually at least 3 separate, but highly related, disciplines related to performance that should ideally be included in the Software Development Lifecycle – Software Performance Engineering (SPE), Performance Testing (what we have been talking about) and Capacity Planning. The only book I am aware of that addresses these three discipline as part of an integrated process is Improving .NET Application Performance and Scalability, Microsoft Press, 2004. In this book, Senior Author J.D. Meier does a fantastic job of taking the reader through the entire process. The only drawback is that much of the book is extremely Microsoft/.NET specific.
Performance Test planning should actually begin before the architecture has been determined or any code has been written. It is especially important to finalize performance testing planning before any machines have been configured for testing and the plan should continue to be revised as necessary until the application has reached it’s target load in production several times. Very few organizations do this. Most organizations create a plan shortly before load generation is scheduled to commence and stick to the letter of the plan regardless of the actual results or detected issues. By working this way, much of the value that can be gained through performance testing is lost.
The bottom line is this, Performance Testing late in the process alone, as most organizations do, can be highly effective, but only if all identified issues are relatively easy to resolve. Saving the testing for the end of the development cycle can be disastrous if the identified issues point back to poor architectural or design decisions.
|
| 10. You have written a lot of papers on performance testing. Do you plan to write a book on this subject? |
I have written quite a number of papers, presentations and tried to tie them all together on my website. When I started doing performance testing, I found very little written on the topic and had to learn through trial and error, seeking out mentors and applying principles from other disciplines. I became frustrated with the lack of valuable information available and found many others who were looking to improve their performance testing. As a result I tried to share what I learned through these mediums so that others will have an easier time getting started than I did.
I have tentative plans for two books. The first is simply a consolidation and expansion of my existing articles. There are two main reasons that I would like to do this. First, I’d like to retrofit the articles to be even more generally applicable, include examples and code samples for various tools since they were initially written on contract for IBM Rational. The second reason is because many readers have requested hard copies, which is unfortunately prohibitively expensive on a case-by-case basis.
While there are some very good books on performance tuning, and other performance related topics and some very good chapters in various testing books about performance testing, there is no single “good” book for practical performance testing lessons. Writing a book is much more difficult than writing a book’s worth of articles, but I keep hoping that I’ll find the time, energy, resources and support to get it done in the not too distant future. While I certainly don’t think I know everything there is to know about performance testing, I do think sharing what I do know would be helpful to many performance testers both now and in the future.
|
|
11. What are the things you are currently working on? |
Outside of the books and some “clean-up” articles, I have actually moved in a new direction with my new job. I am now in charge of testing fingerprint sensors and their associated software (API, drivers, etc) on both PC and embedded platforms. This is extremely challenging as the testing is a blend of four very different industries (Hardware, Software, Embedded/RealTime and Biometrics) that, to the best of my knowledge, has never been written about and as far as I can tell has rarely, if ever, been tried. The knowledge I have gained as a Performance Tester/Analyst has been extremely helpful in the endeavor, as has my relationships with various industry experts such as Cem Kaner, James Bach, and Alan Jorgensen, not to mention my Embedded Software Development Instructor friends at MIT.
Additionally, I am trying to take my User Community Modeling Language (UCML™) to the next level. It was created specifically to model Performance Workloads and the data associated to those workloads, but I have found it to be personally useful in modeling other application characteristics by simply adding a few symbols and thinking about it from a slightly different perspective. Soon, I hope to publish UCML™ v2.0 to see what other folks think. |
在最近的工作中，经常有同事问LoadRunner到底是怎么模拟成百上千的用户的?
现在做个简单的说明。LoadRunner里面有个概念叫做“虚拟用户Virtual User”，虚拟用户会模拟真实用户操作你的应用程序。模拟的模式有很多，例如：记录鼠标点击、键盘敲击时间的(GUI-Based)；记录客户端给服务器发送数据流的方式(Stream-Based)，等等。
要对应用程序进行一定的压力测试，LoadRunner分成两个步骤去实现
- 录制真实用户的操作过程
在录制的时候，VuGen监控客户端数据库、追踪用户发送给服务器的请求和服务器发回的响应。如下图：
- 回放模拟用户的操作过程
在回放的时候，虚拟用户脚本通过执行调用服务器API直接与服务器交互。当一个虚拟用户直接与服务器交互的时候，客户端用户界面不需要占用系统资源（意味着没有用户界面调用系统资源）。大家都知道用户界面最消耗系统资源，这样LoadRunner不通过用户界面去模拟真实的操作，使得他利用很少的几个测试机器可以模拟很多很多的虚拟用户同时访问服务器应用程序，从而给服务器增加一定的负载。如下图
最后说明一点：VuGen录制脚本的时候，不是基于安装了多少客户端软件，而是基于通讯协议的，例如：HTTP/HTML, TCP/IP, Web Service等等，另外，Mercury与SAP，PeopleSoft，Citrix等公司有合作（Alliance）关系，所以对于他们的软件有更好的支持，当时是指性能测试方面的支持。
VuGen 是 LoadRunner的一个应用程序，可以参考LoadRunner 架构概览
Auther: Linda Hayes
From: http://www.computerworld.com/developmenttopics/development/story/0,10801,106105,00.html?SKC=development-106105
November 10, 2005 (Computerworld) -- Like babies, most code is born beautiful, at least in the eye of its creator. But the only time I ever heard one programmer praise another's code was prerelease. In this newborn state, the code reflects the developer's original design, untouched by the unknown demands of future users.
But once code enters into use, this innocence is lost. Just as the wrinkles on a person's face are carved by his experiences, so do missed requirements, bug fixes and -- especially -- code being adopted by another programmer all result in additions and patches that become downright ugly. And no programmer wants to work with ugly code.
This leads to the inevitable desire to rewrite the code from scratch. The reasoning is seductive, and I have fallen for it many times: It would be easier to rewrite it than to try and fix it, because it's so messy that it's hard to understand. I've even justified it to myself on the grounds that it will increase the developer's accountability, since it's easy to blame problems on the legacy code.
There is some truth in this. If a developer doesn't understand the purpose of code written by others, he is more likely to leave it and write around it than to remove it, so the code becomes bulky and confusing. Rewriting it can serve to streamline the code, making it easier to follow and understand.
But there is also a hidden trap, as I have confirmed over and over: The problem is that the developer who wants to rewrite it doesn't understand it, which is why it needs to be rewritten.
Think about that. How can you recreate something you don't understand?
You can't, of course. So, what happens is that all of the battle scars of the code -- that is, the code added to handle unforeseen issues such as undocumented idiosyncrasies in the operating environment -- are lost, and with them the hard-won experience that required the code to begin with. The new code must literally grow up all over again, until it, too, becomes ugly.
Let me give you an example. We have a product that interacts with a browser, the Document Object Model (DOM) and the operating system. Once our first version went into production, we began to uncover an endless procession of subtleties, undocumented behaviors and outright bugs in each of these interactions. In one case, we discovered that passing a URL that was in a different domain than the one that initiated it had to be invoked in a completely different way due to security patches. This was only one small example of perhaps hundreds of minute but serious issues.
The process, frankly, took years and is still going on, since each of these components, including ours, is a moving target. The problem is that you don't know what you don't know until you find out the hard way, and the code reflects it.
Over the years, the code has become desperately ugly, and to no one's surprise, the developers want to rewrite it. It's so Byzantine, they say, that every time they touch it something else breaks. And, based on the turnaround time to get a fix, it clearly takes too long to diagnose the issue in the first place.
Se here's my dilemma. Should I resist rewriting this time because I realize the value that is represented in those wrinkles and scars? If we rewrite it, I have no doubt we will rediscover all of those same traps, with maybe a few solved but new ones added. And even though the code will be beautiful at first, I also know that won't last. It will also become ugly, and at least I generally know what the old code does and doesn't do.
Or should I give in to the rewrite? Maybe code has to be rewritten every few years to keep it fresh and up to date. Maybe code gets so bloated and ugly that it eventually collapses of its own weight.
What do you think? If you care, share your insights with me. I could use them.
担任台塑集团董事长达半世纪之久的王永庆5日卸任。目前台塑董事长由原台塑总经理李志村接任，王永庆弟弟王永在的长子王文渊接任总裁，副总裁一职则由王永庆的女儿王瑞华担任。
据台湾媒体报道，台塑公司5日举行股东会，会后宣布：台塑今后的重大决策都将由王文渊、王瑞华等七人组成的行政中心作出。会上改选出新任董事、监事，王永庆和王永在退出董事会。
有分析认为，目前台塑已进入专业经理人和王家第二代共治时代。但有“经营之神”美誉的王永庆仍是集团内最具影响力的人士。
祖籍福建安溪的王永庆1917年出生于台北，他38岁时创办台湾塑胶公司，目前台塑关系企业旗下计有台塑、南亚、台化等20余家企业，在岛内外多地设厂，是岛内最大的民营企业之一，对台湾经济发展贡献很大。据介绍，王永庆退休后将把相当一部分精力放在帮助大陆贫困学童方面。
Validation, Verification and Testing are terms of software development. From the words themselves, we may think they are similar and almost same. It is very difficult to tell the difference between them.
Here is some information. Although they are shown here, I think they are still impenetrable jargon.
- Validation. Doing the right thing:
- Checks that output deliverables satisfy the requirements specified in a previous stage’s input deliverables.
- Ensures that the work product is in scope, contributes to the intended benefits, and does not have undesirable side effects.
- Is performed by inspecting, simulating, or prototyping.
- Verification. Doing it the right way:
- Checks that a deliverable is correctly derived and internally consistent.
- Checks that output and the process conform to the standards.
- Is performed by inspecting and reviewing.
- Testing. Right things working right:
- Checks that a specification is properly implemented.
- Is performed by executing the code.
文革时有一段时间，人们出门，无论说什么话，只要一开口，就必须说一句毛主席语录，然后再说要办的事。
一天，我去供销社，进门就听到一个中学生和售货员的对话，堪称经典。
中学生：“关心群众生活－－－给我拿支钢笔。”
售货员：“为人民服务－－－你买哪一种？”
中学生：“我们都是来自五湖四海－－－多拿几支让我挑挑。”
售货员：“反对自由主义－－－不让挑，买哪支拿哪支。”
中学生：“我们的责任是向人民负责－－－你就多拿几种让我挑挑吧。”
售货员：“在路线问题上没有调和的余地－－－说不挑就是不能挑。”
中学生：“凡是敌人反对的，我们就要拥护－－－为啥不让挑?
售货员：“凡是敌人拥护的，我们就要反对－－－不为啥，不让挑就是不挑。”
中学生：“注意工作方法－－－有这样卖东西的吗？”
售货员：“一切权力归农会－－－爱买就买。”
中学生：“打倒土豪劣绅－－－你这什么工作态度？”
售货员：“友谊，还是侵略－－－咋的，你想打架？”
中学生：“凡是反动的东西，你不打他就不倒－－－你以为我怕你？”
我见两人的战争一触即发，就急忙上前调解：“要团结不要分裂－－－你们有话好好说。”
售货员：“将革命进行到底－－－我看你还能咋的？”
中学生：“人若犯我，我必犯人－－－你当个售货员啥了不起？”
我看他俩谁也不肯停止舌战，我便劝中学生一走了之：“敌进我退－－－你先走吧，明天再买。”
中学生听了，就顺势下了台阶，转身而去，他边走边说： “别了，司徒雷登－－－哼！”
售货员如得胜的将军立即回敬道：“一切反动派都是纸老虎－－－呸！”
昨天去宝山区房地产交易中心交税，本来想用信用卡刷的，谁想到都刷不出，可惜了这么多积分没有拿到！昨天还算顺利，有点小插曲，可恶的建设银行！可恶的建设银行！
晚上电视上就报道了，银联系统不联了
■不仅是上海市内，还波及其他省市■用户无法跨行刷卡、提现，部分商家生意受影响
------------------------------------------
晨报讯昨天中午时分，众多上海市民在使用银行卡跨行消费或跨行提现时，全都遇上银行卡无法使用的“尴尬”。记者从中国银联了解到，昨天10时56分起，银联系统出现故障，导致上海市内的所有银行卡跨行交易全部中断，此次故障还波及到北京、江苏、浙江、福建等省市。
据了解，由于无法跨行刷卡消费，众多商家当天的业绩均受到一定的影响。而众多不知情的消费者纷纷在ATM机前排起长队，但不少人依然无法取到现金进行消费。
昨天17时59分，银联在其网站上发布公告称，银联网络已基本恢复正常。公告表示，对由此给成员机构、商户、持卡人带来的诸多不便深表歉意，但公告并未就是否有持卡人因此蒙受损失进行说明。
一位国际卡组织人士用“比较少见”表示了对银联系统出现故障的看法。该人士认为可能有三方面的原因：一是电信运营商的线路不好导致电子支付系统出现问题；二是由于系统升级、版本改变导致网络出现短时间内的不稳定；三是由于各种原因导致的系统出错影响了网络稳定。
作者：□记者郭文 王君 邹颖琦 马伟伟
好吧，我承认，从很小的时候我就被告知，人类和动物最大的区别是人类会使用工具。工具是伟大的，看，工具使我们摆脱了茹毛饮血的生活，创造了一种叫做文明的东西。可是又有谁考虑过哪些工具是文明发展史最为举足轻重的呢？去年8月份，美国《福布斯》杂志（Forbes）为此进行了一项调查，选出人类史上20种最重要工具，排第一的是刀，其次是算盘和指南针。 《福布斯》在过去几个月访问了逾3,000名读者、杂志的编辑和一批专家，包括苹果计算机前副总裁、美国西北大学教授诺曼，美国杜克大学历史系教授彼得·罗斯基等。所选工具以手握和可携带为原则，并摒除了语言、软件这一类的抽象工具，机器也不在考虑之列。根据这个原则，有33种工具入选，让受访者投票选出20种最伟大的工具。以下便是前十种最伟大的工具。 1.刀
关键词：战
人类用刀的历史超过二百万年，可说是最古老的工具。人类的祖先就是用它来自保、狩猎。有了刀，在数百万年前，五六十公斤重的人类就能打败五六百公斤的野兽。人类最早的文明便是建造在刀锋上的文明。在后面提到的几种工具中，镰、剑和锯都由它演变而来。 福布斯杂志对这种世界上最伟大的工具的评价很简单：没有刀，没有甲壳、利爪和尖喙的人类就不会生存下来，人类不生存下来，就没有今天的文明。很粗暴残酷的一个结论。 2.算盘
关键词：算
算术在人类文明史上的贡献是巨大的，可以说是人类跨出抽象化思考的第一步。而算盘是世上最早的机械式算数工具，也是今天几乎无处不在的计算机祖先。没了它，要算数只能靠加起来才二十根的手指脚趾。 说到算盘，中国文明可以自豪一下。虽然在古希腊，人们在地上画几条杠杠，再放上几块石块，算是最早算盘的雏形，可真正改良算盘的是中国人。在公元1200年的时候，中国人把算盘改进成现在这个样子，成为当时世界上最先进的计算工具，并沿用至今。 3.指南针
关键词：游
又是中国的一项伟大发明。指南针最早作占卜之用，当发现磁针永远指向北方之后被改作引路工具。指南针的意义在于它使个人的活动范围大大增加，从而人类可以广泛地迁徙，开发更多的定居点。 我们很小的时候都听说过黄帝也是凭“指南车”战胜蚩尤，华夏民族才得以发祥的故事。而在欧洲，指南针则直至十二世纪左右才流行起来，之后航海家们用指南针发现了地球原来是圆的。 4.铅笔
关键词：写
书写是人类文明史上最杰出的发明之一，有了书写才有随后而来的历史与文化，书写将人类的生存经验代代相传下去，这是人类文明得以不断发展的精义所在。但是很遗憾，铅笔排在刀子、算盘和指南针的后面，可以看出在现代人的心目中，文科的地位不如工科、不如理科、更加不如战争…… 铅笔起源可追溯至古罗马时代，当时是以铅条写在草纸上。到十六世纪意大利人造出了石墨制铅笔并沿用至今。 5.缰绳
关键词：驯
缰绳原来已有4000年以上的历史。这是农业的起源，是人类驯服其它的动物的开始，显示出人类在所有生物中的突出地位。 缰绳的最早出现可以追溯到6000多年前，根据考古发现，当时人类已经驯服了马为自己工作。而有文字记载的缰绳的出现，则在4000年前，埃及已经开始广泛地使用马作为坐骑。最早的缰绳类似于轭，架在牲口的脖子上，但是很快，人们发现这种装置会让牲口感到呼吸困难，于是进行了改进，大致形成了现在的样子。 6.镰刀
关键词：耕
农业从游牧发展成耕种，是人类文明发展的又一里程碑。这款西方传说中“死神”的专用武器，在人类农作中起到了最大作用，镰刀是除草、收割的必需品，在农业时代，镰刀的发明使一个人可以在几天内收割好几亩地的庄稼。当然，镰刀很锋利，在刀具管制的时代，是农民防身、斗殴、甚至农民起义的主要武器。 镰刀最早出现在5000年前，当时的镰刀用岩石打磨而成，末端可供手握，顶端弯曲，弯曲部位内侧打磨锋利。冶炼铁的技术成熟后，铁制的镰刀应刃而生。镰刀的形状一直在不停被改进，现在使用的镰刀大致到12世纪至15世纪才慢慢定型。 7.莱福枪
关键词：战
在人类文明的发明过程中，武器的先进程度永远高于其它工具。火药由中国的炼金家于4世纪左右发明，之后火药不断被运用于军事中，各种铳、炮填充着火药开始将暴力扩大化。直至1747年，本雅明·罗宾发明出莱福枪，用枪管内刻的螺旋纹能提高准确度，终于将这场暴力扩大到极至。杀人于弹指之间，工具的发展终于赋于了人类这项本在传说中只有神具有的能力。人类历史上最残酷的时代到来了。 8.剑
关键词：战
仍然是战。兵乃大凶之物，圣人不得已而用之，在有史以来最伟大的十种工具之中，兵器独占三位。 剑是人类所使用过的最经典的武器。在长达几千年的历史中，无数人依剑而生，因剑而死。剑结束了无数人的生命，建立了无数帝国，改变了无数历史。福布斯杂志对剑的评价是：如果没有剑，世界会是另外一个完全不同的世界。 最初人类用的是短剑，到约5000年前，依序出现铜剑、铁剑，和经淬炼而成的钢剑。标准的剑在剑身顶端三分之一开刃，用于劈刺，未开刃部分用于隔档防御。直至今日，人类还念念不忘剑曾经带来的荣耀与影响力，奥运项目仍旧保留了传统的击剑。 9.眼镜
关键词：纠正
“纠正”是近代工具发展的一个趋势，越来越多的工具被发明出来弥补人类的各种各样的短处，并且使人类依赖上他们。比如眼镜———如果没有眼镜，这个世界上将有三分之一的人终日生活在一片迷迷糊糊当中。 在古罗马，就有许多记载在案的近视眼贵族。他们只能让奴隶为他们朗读他们想看的文字。眼镜的概念早于公元1000年左右出现，当时有人注意到曲面的玻璃可以让人看得更清楚，到1286年，人们开始制作框架试图将这些玻璃固定在脸上。此后人类试验了无数种固定方法，比如挂着、粘着。直到1780年，富兰克林造出了现代眼镜的雏形。 10.锯
关键词：建造
锯是工具史上的一个奇迹，很少有工具像锯子这样，用一个极其简单的结构解决了极其重要的问题。锯子的发明使人类可以切开几乎任何东西，改变任何物体的形状。于是才有建筑，在极早的年代就建成了极为恢宏的建筑物。 也很少有工具像锯子这样，发明来历十分神秘。根据古希腊神话，锯子是由一个叫Perdix的小男孩———他是著名发明家 Daedalus的徒弟———发明的。他从鱼骨头边缘的锯齿状部分常常割破手得到了灵感。而我们从小听到的版本则是鲁班在山里被一种边缘锯齿状的叶子划破了手从而发明了锯子。总之这样的传说非常多。但是不管是谁发明了锯子，我们从中受到的益处是无法估量的。 从古埃及人早于五千年前已懂用铜锯的历史记载至尽，锯子的样子一直没有发生多大的改变———如果要说改变，美国阿巴拉契亚山区的当地人把锯改变成乐器，到今天仍有人会演奏这种叫做“山乐”的乐器。 11-20
从第11位到第20位依次是：手表、车床、针、蜡烛、秤、锅、望远镜、水平仪、鱼钩和凿子。 摘自新闻晨报， 作者：星期日新闻晨报记者 吴飞 http://www.jfdaily.com/gb/node2/node17/node33/node83028/node83039/userobject1ai1301517.html
一个很偶然的机会，接触到了这个东西：项目遇到了巨大的性能问题，主要是网络方面的，从中国Ping美国一台Server需要256ms，而从美国Ping美国一台Server只需要5ms，这个问题的严重性直接导致了在中国的用户无法接受安装在美国Server上应用程序的反应速度。
无论是传统的CS架构还是BS架构，从服务器到客户端都有大量的数据在传输：一般就是客户端发送一个请求给服务器，然后服务器进行响应，最后把结果返回给客户端，这个应该是最典型的应用了。如果客户端和服务器端的网络不是很理想，那么大量的数据传输必然导致系统的性能无法接受，就我们测试的这个项目来看，10分钟跑4个业务，所产生的流量在10M以上。那么有没有什么方案可以避免这个传输呢？答案是肯定的，Citrix就是这个问题的解决方案。
Citrix是如何工作的呢？
是不是技术倒退到Terminal时代（终端用户），无盘工作站时代？原理上有点像，但是已经不尽然。Citrix就像一个软件平台，如果你用过VMWare或者VirtualPC就可以看到操作系统只是一个软件。Citrix也有客户端和服务器端，所有的软件都安装在服务器上，他的好处是显而易见的，例如，统一部署、版本控制、节省软件License、更加安全。Citrix最大的优点就是减少了服务器和客户端之间的网络流量，因为在操作过程中，机器之间只传递了鼠标、键盘操作和屏幕更新，没有任何的业务数据在客户端和服务器之间传递，就Citrix官方文件说，他们跟Microsoft合作在网络之间提供了一个安全的层，即使仅有的数据也采用了128位数据加密。
有一个客户案例说在服务器和客户端之间的Latency是220ms的时候，使用了Citrix架构以后，性能提高了48倍。
有些缺点也是天生的：
l 如果没有网络，系统就根本无法工作。
l 尽管减少了网络之间的流量，但是现在的任何应用程序都是依赖于网络的，网络的速度是一个问题，Citrix |