软件性能测试之 测试时间

我们经常理解的系统的性能就是“能稳定运行多少天，而不出任何故障”，这个指标我怀疑是从传统工业产品中直接生吞活剥过来的，如很多家用电器，还有一些服务器，就经常打出这样的宣传广告。这个指标虽然来路有点不是很明白，但不影响软件测试人员对它套用在软件产品性能上的诠释。在计算机硬件能达到像现在这个运行速度的今天，除非你的运行环境配置是非常离谱的不合理，同时软件系统的代码也是写的超级糟糕，数据库相关表的记录数以T为基本单位来计算，否则运行一个即使是很冗长的测试用例最长也不会超过30分钟。要实现“能稳定运行多少天”的目的的话，或许你很容易就可以猜到，能让应用系统带“负载”运行多少天的基本方法就是－重复，多次的重才能构成应用系统长时间的运行的条件。
测试执行的重复就是一遍又一遍毫不间断地执行某个操作或功能，让系统在处理完一个请求后马上就处理新的请求。系统刚处理完一个请求，可能还没有来得及释放刚才那个请求所占用的资源，马上又接到新的请求的话，还能不能正常释放上一个请求所占用的资源。应用系统在这样的条件下会不会在响应时间变慢甚至功能上发生混乱。
比如执行一个脚本一遍需要30秒，如果想让系统执行12个小时，就在该测试用例的测试“场景”上设置让该测试用例重复执行1440遍。如果要让这个系统运行多少天，运行的遍数如此类推就可以了。这个所谓的重复虽然简单，却是发现问题的最有效的方法之一，因为在一个应用系统投入运营之后，它也是这样重复的接受用户的请求的。接连不断重复的次数多，才能完成数量的积累，才能发现隐藏的比较深的问题，如许多隐蔽的代码错误、系统连接数被消耗殆尽、线程泄漏、内存泄漏等等。
在这里我们将这个问题稍微扩展一下。简单重复能发现问题是真实不虚的，但针对不同的测试用例，在执行之前，应该评估一下执行多少遍或多长时间已经足够暴露系统可能存在的问题。免得但不是特别重要的测试用例，浪费了宝贵的执行时间。例如对一个B/S系统进行压力测试的时候，首先执行的一般是网站首页，同时这个首页的页面是静态网页的话，这样的测试用例就可以不用运行这么多天，或许有几个小时的重复负载测试就可以了。对比较复杂业务逻辑的测试用例，倒是可以将时间安排的稍微长一些。如何安排这些测试用例的执行时间，应该在测试方案中就规划好。

如需转载，请跟作者联系。johannes_zhu@yahoo.com。
广州易标软件技术有限公司为您提供高质量的软件测试服务。
欢迎访问：http://www.3rdtest.com。