以开饭馆为例浅谈功能和性能测试
本文以开饭馆经营为例，描述应用程序中功能和性能测试的定义，希望大家在funny中有所收获。听说食堂伙食不好，准备在园子附近开个饭馆赚些外快O(∩_∩)O~
有了需求，准备干活。
由于资金有限，只能开个小店，一个老板，二个服务员，二个厨师。
饭馆最重要的是要有招牌菜啊，想了想，厨子红烧肉和宫保鸡丁做的不错，好嘞，招牌菜确定！招牌菜即软件产品中的卖点功能。
厨子在做菜的过程中既是developer又是tester，先做菜（开发），做好了要看看味道咋样（功能测试）。当然也有的大厨，做好的菜一定是色香味俱全的，就像开发中的牛人，写好的程序就基本没有bug（太理想了，要是这样tester就都下岗了，哈哈）所谓的测试用例就是宫保鸡丁的味道是酸甜口味的，里面要有胡萝卜丁和黄瓜丁，厨子做完菜后应该check这几点吧。
还算不错，很快来了客人，在服务员的推荐下，customer点了宫保鸡丁，5分钟左右菜好了，这里的5分钟是上菜时间，我们可以理解为软件产品的响应时间，customer吃罢，对该菜评价甚高，而切对本店的服务质量很是满意，当即表示次日还来，老板大喜！次日，客人果然守信而且还带了team中的其他同事，这次由于人多，上菜用了8分钟，customer同样满意而归。目前为止饭店属于功能测试范围，饭店满足了客户的基本需求，菜的味道可口和服务质量上城。不难看出在客户不多的情况下，小店对客户的请求处理能力游刃有余！
不久凭借良好的口碑，来小店吃饭的人越来越多，同时问题暴露了，服务员和厨师忙不过来了，直接导致上菜的速度过慢平均需要15分钟左右，而菜的味道也由于厨师的busy大不如前，客人投诉颇多。此过程便是性能方面出现了问题，性能测试较功能测试相比，在关注功能实现的同时，更关注多用户使用软件产品时，产品的响应时间，即用户的体验。举个用户登陆hotmail邮箱的例子
功能测试用例设计如下：
步骤：
输入正确的用户名和密码
点击登陆按钮
预期结果：
登陆邮箱成功
性能测试用例设计如下：
case1 1个用户输入正确的用户名和密码
点击登陆按钮
预期结果：
在1s内登陆邮箱
case2 10个用户输入正确的用户名和密码
点击登陆按钮
预期结果：在2s内登陆邮箱
可以看出性能测试更注重多用户的体验时间，另外在性能测试中并不是覆盖所有功能测试中的功能点，性能测试关注的是用户最常用的scenario，需要cover产品的卖点功能。因为使用产品卖点功能客户的人多，所以容易造成系统性能瓶颈，另外卖点功能性能的好坏直接影响软件公司的成败。
OK发现了问题就要解决问题，小店老板在细心的observer中发现，当饭馆同时有6桌客人的时候，平均上菜的时间在10分钟左右，这个时间范围customer没有抱怨；而当同时有7桌客人的时候，平均上菜的时间就在15分钟左右，只是多出一桌，咋出现这么大的问题呢？哈哈，老板找到饭店同时就餐人数的饱和点——6桌，所谓的饱和点就是在能够承受的响应时间内，产品支持的最大用户数量。
问题发现就要开始解决，老板想出了一系列方法，比如提前准备一些customer最喜欢的菜，在繁忙时自己放下架子充当服务员等等。在软件产品中性能测试人员可以通过调试application server中的jvm，线程池的大小以及数据库中I/O大小来解决性能瓶颈的问题。往往这个过程是很复杂的，需要tester有很强的system分析能力了解db，了解applicaton server，有时发现一个性能方面bug需要几天的时间，这也是性能测试难做的原因。但是性能测试的bug一旦被开发approve，这个bug会很有value。当然对于developer来说，噩梦开
始了，第一性能测试的bug很难fix，第二性能测试的进入时间阶段要比功能测试晚，往往发现重要的performance bug 都是在项目快要到deadline的时候。因此就苦了开发了，加班加点干吧，同情ing... 另外一个项目中performance的bug通常占总bug数的10%-15%左右，这个是经验只谈，是一个很牛的大IT公司总结的。
饭店老板的一系列措施果然奏效，饭店同时服务8桌客人仍然能够保证平均上菜时间为10分钟左右，由于服务有序，厨师的压力也小了很多，因此菜的味道也很好，customer连连say good!
老板的买卖越来越好，经常出现排队等候的customer，而这部分customer往往由于等候时间过长，直接走掉。老板当然想留住这部分客户，谁怕自己的钱多啊。于是又苦思冥想，看看怎样调整能解决问题，可是这次不行了，这次的问题是出现在饭店的硬件资源上了，饭店就这么大，服务人员就这么多，要想挣更多的钱就要扩建并且增加服务员了。就像我们做软件，发现问题是使用的application server本身的处理能力不够了，DB支持的最大存储空间不足了，怎么办啊，换设备吧，把jboss换成websphere，把sql server换成db2，道理简 单，但是换设备后的成本贵啊，而且贵的离谱，此时已经超出我们tester的职责范围了，我们只需要把问题报告，然后看我们的大boss如何balance了。
饭店怎么办呢？老板还没想好！
好了，写完了，本人做过几年功能测试和性能测试，希望把自己的经验心得通过此文share给从事tester的兄弟姐妹！如果有问题，欢迎留言讨论
不错
写的不错 ，支持一下。在工作中经常想测一下性能，经常不知从何入手，还遭同事反对。 :) LZ写得很生动！ 8错8错 写的非常不错，但总感觉缺少点什么，比如Customer点了其他的菜，但并不合Customer的胃口，Customer进行投诉或者只是抱怨但不投诉，这时，老板是不是要就这种情况进行处理，这里的响应时间是否需要考虑进去？ 不错 呵呵，写得真不错，也很形象！ 谢谢分享。最后那一句“把jboss换成websphere，把sql server换成db2”在我看来也许就是性能测试最直观的效果吧。有时性能测试就是要做到对解决方案与实施能有改革的作用！！
当然有时为了性能而换了方案或设备，对开发来说是难以接受的。。 好 谢谢分享 不错 谢谢分享 好帖，果断收藏，谢楼主的耕耘了 挺不错的。谢谢了 mk 写的很生动谢谢分享 不错不错，对于新人来说很生动吖~好评！ 很有意思，直观明了 很好。学习了 写的真不错！谢谢分享！ 很形象，对于新人理解功能与性能测试很有帮助:victory: 很形象，对于新人理解功能与性能测试很有帮助:victory:
页:
[1]
2
