单元测试和压力测试是软件开发质量的保证

　　软件测试的概念最早是大学时从老师那里记来的两句话(其他都丢光了)：开发是尽可能地让程序通过;而测试，则是尽可能地让程序通不过。两者的区别，在于选取测试实例在设计上的指导思想的不同。这句话虽然简单，但易记，自已也觉得真是收益菲浅。当时还没有什么javawindows之类的故事，所谓软件，其实是C语言和汇编，不过这个思想我却是觉得可以用到软件开发和测试的几乎方方面面。

　　一般说来，可用性测试和黑盒测试这类工作既引不起我的兴趣也算不得是我的工作责任，除了在验收时应应景以外，正常情况难得会多看一眼。而且，为了让可用性测试少出点麻烦，早就养成习惯，只要不是requirement specifics(需求规格)中的项目，千万不要多事，多做多错。(不过如果项目不规范，压根没有规格说明时就另当别论，这时我会坚持需求自已出，等于自已做用例需求分析，这也是合理的要求了，可以省许多扯皮扯不清的麻烦)。在操作中真正需要操心的是白盒的单元测试，以及压力测试;这两者又偏偏是互相冲突的。

　　热衷于单元测试说起来源于《艾柯卡自传》中的一句话：产品出厂前发现故障，所花费的成本是出厂后发现故障的十分一。单元组件就是我的产品，单元测试就是出厂前的测试，与其出厂后给人扯着叫回来：“你的程序出错了”，不如先自已把它测过透。所以我的习惯不知是好是坏了，不过测试是上心的，基本上每花一个 ManDay做开发，就要花一个ManDay做测试，包括写测试例程，组织测试数据;(两者合起来就是测试实例);文档的时间还要另算。Junit,作为单元测试的工具，我只是在EJB的环境中使用过;这还是由于EJB的测试实在不容易，平常使用的埋设断点，编写测试类的方式在EJB容器全不管用， EJB也居然没有提供针对EJB本身的类设定输出日志的功能 ，一有错就要满系统日志翻可能只是几十个EJB中的一个输出的错误日志。相比之下，JUNIT 及其扩展象Junitee，提供了抛开其他部分单纯测试EJB组件的功能。这其实也是Junit的基本思想，对于分层开发的实现固定接口的组件，与其自已一个个写测试环境然后main，不如使用统一的测试框架。这也是高效开发不可缺少的一个部分，但对于其他的类，使用Junit我实在看不出有什么好处：类本身可以输出断点，又可以几行代码在Main中运行，还有什么比这样的单元测试更有效的吗?何必多此一举跑到Junit中呢?

　　不过，单元测试强度越大，所谓越强壮，其实就是考虑的Case越多，if-else也越多，就单元来说固然是强壮了，但实际上消耗系统资源也越多;个个组件多一点，其实加起来整个系统的负载能力就下降得很可观的。所以单元测试强度与最后的压力测试是冲突的。只不过在不短的时间里，我只要管好自已的单元不出问题，就天王老子也咬我不进;至于整体性能，既不用考虑也轮不到我考虑。直到系统性能在运行时下降我成为第一个被“咨询”的对象时，对于整体性能就不能不闻不问了。这时对于压力测试的兴趣一下子升了起来。负载测试在相当长的时间内是一个奢侈品，loadrunner不但是一个大家伙，贵，而且还不容易盗版，其中一个原因是测试毕竟不是我的主业，所以也不会专门弄一台机玩这个;反正我从来拿不到一个长时间可以使用的版本，也没有真正学会用这个玩意。另外，担心归担心，真的因为负载太重造成当机的时侯不多，而且也总有应对办法，如果不是重新处理新的项目，估计也不会再在这上面花太多的心思。

　　最初自已写一个压力测试的工具以失败告终：线程按要求展开了，也发出了http请求，但是系统却正常得仿佛没事人一般;可是一放到工作环境就出负载报警。显然，这是测试程序没有达到目的，而不是系统真的如此强健。而原因，其实到今天我也不甚了了。不但如此，这两天试用了webCt和 webrunner这两个一心想要钱的国产软件，结果和我当初写的一模一样，无论我如何设置加压，那头系统同样是风不吹草不动——可千万别以为是系统强壮。后来的办法是使用jakarta HttpClient，调用proxy，这些proxy网上一大把，只要收集下来总有相当数量;这下子测本地局域网的测不了，但测网上网站倒是可以的;也的确复制出大访问量情况下系统挂机半挂机，也可以检验出大概调用多少个proxy时达到挂机效果，要如何优化才不会挂机，变慢一会又恢复过来。勉强可能用，事实上是自已做了一个DDos攻击的工具，检查DDos应对状况;不过搜集proxy真是麻烦而且缺乏日志统计(需要另写程序啊);更加没有 session,cokkie等等，只能进行简单的网页下载，然后验证关键字，确保下载完全。而且，由于需要手工反复启动，同时代理服务器应答也有一段时间，系统极限恢复也有一段时间;所以用这个办法，把会话带上700多后就再也上不去了，后者未来前者已经终结。

原文转自：http://www.uml.org.cn/Test/200604242.htm