一般说来,可用性测试与黑盒测试这类工作既引不起我的兴趣也算不得是我的工作责任,除了在验收时应应景以外,正常情况难得会多看一眼.而且,为了让可用性测试少出点麻烦,早就养成习惯,只要不是requirement specifics(需求规格)中的项目,千万不要多事,多做多错.(不过如果项目不规范,压根没有规格说明时就另当别论,这时我会坚持需求自已出,等于自已做用例需求分析,这也是合理的要求了,可以省许多扯皮扯不清的麻烦).在操作中真正需要操心的是白盒的单元测试,以及压力测试;这两者又偏偏是互相冲突的. 【推荐阅读:java.lang.RuntimeExc】
软件测试的概念最早是大学时从老师那里记来的两句话(其他都丢光了):开发是尽可能地让程序通过;而测试,则是尽可能地让程序通不过.两者的区别,在于选取测试实例在设计上的指导思想的不同.这句话虽然简单,但易记,自已也觉得真是收益菲浅.当时还没有什么javawindows之类的故事,所谓软件,其实是c语言与汇编,不过这个思想我却是觉得可以用到软件开发与测试的几乎方方面面.
热衷于单元测试说起来源于«艾柯卡自传»中的一句话:产品出厂前发现故障,所花费的成本是出厂后发现故障的十分一.单元组件就是我的产品,单元测试就是出厂前的测试,与其出厂后给人扯着叫回来:“你的程序出错了”,不如先自已把它测过透.所以我的习惯不知是好是坏了,不过测试是上心的,基本上每花一个manday做开发,就要花一个manday做测试,包括写测试例程,组织测试数据;(两者合起来就是测试实例);文档的时间还要另算.junit,作为单元测试的工具,我只是在ejb的环境中使用过;这还是由于ejb的测试实在不容易,平常使用的埋设断点,编写测试类的方式在ejb容器全不管用, ejb也居然没有提供针对ejb本身的类设定输出日志的功能,一有错就要满系统日志翻可能只是几十个ejb中的一个输出的错误日志.相比之下,junit 及其扩展象junitee,提供了抛开其他部分单纯测试ejb组件的功能.这其实也是junit的基本思想,对于分层开发的实现固定接口的组件,与其自已一个个写测试环境然后main,不如使用统一的测试框架.... 下一页