四个对测试者有意义的故事

达人认为;下面的四个故事也体现了一个合格的测试人员应具备的几个职业素养，所以贴出来供大家参考

故事一：

92年海湾战争的时候美国的爱国者导弹因多次成功拦截飞***腿导弹而大获好评，但是其中有一枚落在了多哈地区炸死了二十多名美国大兵，事故的原因后来查明是因为软件中一个很小的系统时钟错误，每次的几秒延迟在累积以后达到了几十小时，所以这枚本该飞向敌阵的导弹反而落在了本方阵营。这些倒霉的士兵怎么也想不到自己死在Bug手上，这也许是历史上后果最为严重的Bug之一。

故事二：

参加微软培训时听来的这个故事，微软在进军电子表格市场的时候把目标定位在创造世界上最快的表格系统，可是后来发现怎样也实现不了这个目标，因为他们始终无法超越Borland公司的表格系统处理速度，Borland公司在编译技术方面拥有不可动摇的实力，微软于是改变了策略，提出新的口号，要创造世界上最易于使用的表格系统。紧接着微软对市场作了广泛的深入调查，分析了大量OL（Office Lady）的使用习惯，终于有了Excel的诞生。时至今日，Excel已经成为了市场的主导者，而Borland公司的电子表格系统早已销声匿迹。这个故事告诉我们，虽然产品定位不是测试员的本职工作，但是有责任提出自己的看法和见解，如果产品方向错误的话，再好的技术到了最后也是白搭，没有市场的软件和垃圾没有什么区别。

故事三：

曾经有一家电信公司实施业务系统，其中有个功能是前台收费。以前用人工的方式收费效率很低，每次缴费处都是排起了长龙，软件上线以后，开发人员兴高采烈跑去参观，心想这下缴费肯定很方便了，可是没想到的是等候的队伍比以前还要长，原来是系统的一个“确认”功能无法用键盘完成，而必须使用鼠标去点击，所以业务员在输入数据后都必须停下来换到鼠标上确定，[注：为了提高效率业务员一般在操作中只用到小键盘，大家去银行的时候都应该看到过]，当时那个程序员很惭愧，回去以后马上添加了键盘直接确认的功能[注：实现起来其实很容易]，第二天他再去的时候发现人潮少了很多，一个看似微不足道的改动带来的却是使用效果上质的飞跃。程序员思维与用户看法有很大不同，程序员都不重视界面问题，可是对于实际使用者来说他们所接触和关心的重点却正是UI，作为测试员有必要随时提醒开发人员。

故事四：

国内一家银行的业务系统上线以后几周死掉了，原因是应用存在内存泄漏问题，最妙的是每次泄漏量都很小，而服务器的内存通常都很大，所以系统在几周以后才当掉。这个故事和第一个故事很相似，告诉我们缺陷的放大和扩散是多么可怕，原本很小很小的一个错误在多次反复调用执行以后就会产生极为严重的后果，而要发现这些隐蔽的问题必须有反复多次的测试才可以。