模板
教程
环境
性能
功能
管理
单元测试和压力测试是软件开发质量的保证
软件测试 的概念最早是大学时从老师那里记来的两句话（其他都丢光了）： 开发 是尽可能地让程序通过；而测试，则是尽可能地让程序通不过。两者的区别，在于选取测试实例在设计上的指导思想的不同。这句话虽然简单，但易记，自已也觉得真是收益菲浅。当时还没
软件测试的概念最早是大学时从老师那里记来的两句话（其他都丢光了）：开发是尽可能地让程序通过；而测试，则是尽可能地让程序通不过。两者的区别，在于选取测试实例在设计上的指导思想的不同。这句话虽然简单，但易记，自已也觉得真是收益菲浅。当时还没有什么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多后就再也上不去了，后者未来前者已经终结。 这几天为了测试网站的负载极限，根据朋友的推荐先后使用了几个压力工具，上面的WebCT/WebRunner是其中之一， LoadRunner80我一看要装300大M就又打了退堂鼓，要知道我几年的机子一装就不用跑了。微软的WAS和Jmeter就成了试用的主要方式，这也是目前可以随便找到的轻易负载工具中比较完善的两种。WAS设置简单，运行结果也具备可重复性。不过呢，报告不直观，而且不能连续动态运行并报告；更糟的是，它没有验证请求是否正常的功能（或者是我不会用，没有找到），这样只是发出了请求，至于请求是不是完整执行还是实际上返回一个空文件，真是天知道。某种情况下，它也就是发出一大堆的request,让网页转一转而已。所以我对WAS的理解是重点不是看它本身的输出日志，而是着重于从被测试者本身在调高测试强度后是本身记录日志中检查是否有异常，以及达到极限状态下是否能够恢复上作出结果判断。 相比之下Jmeter就好一点，这东西使用上也不难，相关的文章一看就基本上会用了。它有验证请求是否正常执行的功能，也能够通过持续请求观察响应变化和背离情况，可以比较容易地发现不同的服务器设置对性能带来的细微差别；就优化服务器来说，它比WAS强。不过Jmeter似乎有BUG，反正我试过几次要启动启动不了，要关闭关闭不了的情况。 无论是使用WAS还是JMETER，都轻易把服务器会话计数打上了几千。但怪就怪在，如果使用我自已那套土装的代理服务器模拟Ddos攻击时，按请求频率，很快就会让目标靶机进入极限状态，甚至应用crash,必须重启。但用WAS/JMETER，无论如何调大负载，都只是响应变慢一点，靶机都是死不了；直到我自已的测试机死了，靶机不一会又生蹦活跳地活转过来。道理在那里，我也没有什么谱；估计与代理服务器的工作方式有关；我发现靶机方面的记录计数比我实际发出的线程请求要高出一两倍。 无论如何，如果打算长期使用一个单元测试的工具测试Web应用负载的话，Jmeter应该是一个不错的选择；另备一个WAS也不算浪费。LoadRunner和其他动不动张口要钱的主儿，暂时就免了吧。 |
