测试代码不可以随意写

大家肯定知道测试代码是不能随意编写的，并且在编写测试代码时也不是抱着一种随意的态度，但是你编写出来的测试代码以及测试代码运行的情况却表现出了一种随意性和无序性。因为你可能并没有弄清楚测试的真正意图所在。  



本人曾经看到过有关验收测试的这样一个案例，验收测试者使用昂贵的商用测试工具对一个具有图形界面的软件进行测试。测试的方法是通过编写测试脚本驱动鼠标在图形界面上随机的点击（当然每一次的点击，都点到了图形界面上可以接收事件的区域），然后等待着被测试软件的崩溃。当然这种测试方法可以作为验收测试的一个方面，但是决不是唯一的一个方面。还有更重要的内容被忽视了。  



测试的目的是用来检验软件系统是否满足了需求。所以，你的测试代码一定要明确的表达出这一点来。就那上面的案例来说，如果测试者真正从用户的需求出发，那么他写出来的测试脚本肯定不会是那样的，而应该是每一个测试用例都清晰的刻画了一项用户的需求，然后检验系统是否实现了用户期望的功能。这样的测试才是有明确目的，才是最有效的测试。和把界面逻辑和应用逻辑隔离，采用明确表现用户需求测试用例进行测试相比，上面的测试方法不能不说是随意了一点。  



在针对类进行的单元测试中，也经常会看到一些错误的测试方法。很多的测试者往往针对类中的每个特定的实现细节进行测试。类中的特定的实现细节是很容易变化的，在快速的迭代式开发中更是如此。领测认为一旦你测试的类中的某个实现细节发生了变化，你原先的测试代码就要进行相应的更改，否则就失去了意义。这种频繁更改的代价是巨大的。类是一种抽象，它反映了更高层面的内聚性，它应该有明确的职责和定义良好的服务接口，它的职责和对外的接口相对于内部的实现细节来说要稳定的多，并且我们要验证的正是这个类是否具备了它的职责。因此，在对类进测试时，我们应该针对类的接口来验证类是否实现了它的职责而不是其他。这样写出来的测试代码要稳定的多，也有效的多。  



细想一下，造成容易陷入针对实现细节测试的原因主要是由于先实现了类，然后才去进行测试。如果先实现了类的功能，然后在去对类进行测试，潜意识中就会不由自主的想去验证已经完成的类的某种实现细节。如果能够在编写实际类前，首先编写针对该类的测试代码，情况就会有很大的不同，因为这会迫使你从类的使用者的角度去考虑问题。结果就是会把关注点放在类的易用性上，放在类的职责上面，放在类提供服务的接口上面，而不是某种实现细节。  



总之，测试代码的编写应该从被测试的对象是否满足需要的层面进行，而不是其他。  

了解软件测试服务机构请访问http://www.Ltesting.com.cn

了解网络软件培训课程请访问http://www.Ltesting.cn

了解软件测试工具请访问http://www.Ltesting.net

了解国际软件测试证书请访问http://www.Istqb.org.cn

看帖看完了至少要顶一下，还可以加入到淘帖哦！