进化的测试

关注软件测试,白盒测试,自动化测试,性能测试

Entries Tagged ‘白盒测试’

单元测试中的异常处理

最近项目不是十分多,所以大部分的学习来自于书本还有同行的博客,淘宝的QA Team博客就是一个很好博客,里面N多淘宝的工程师写,而且更新的非常频繁,质量也很好。翠翠同学以后就要加入淘宝了,以后就能看到他写的博客了。
早上来看到一篇文章,大概讲的是在单元测试中容易用到了Try…Catch语句而容易出现的一个错误,这里想说一下我对单元测试中异常处理的。记得一个牛人曾经说过(实在想不起来谁也搜不到),大概的意思就是“处理一个问题的最好的办法就是不去处理它”。我不知道当时他讲这句话的具体场景是什么,不过我觉得这句话用在单元测试的异常处理中还是比较合适的。
首先来看看两条关于异常处理的原则

如果无法处理某个异常,那么就不要捕获它
如果捕获到一个异常,那么不要胡乱处理它

单元测试的代码和开发的生产代码,虽然同是程序代码,但是他们存在的意义是不一样的。前者是验证程序的正确性,属于为程序服务的;后者是实现某种功能,属于为客户服务的。然后在看上面的两条异常处理的原则。

自动化单元测试要点

用单元测试的框架MSTEST,做单元测试,集成测试快1年了,总结一下工作中学到都东西。
单元测试,集成测试有什么用?
1. 改进产品质量
软件测试,很多时候围绕着两个问题:
Verification和Validation,常说的双V。前面的Verification就是Is the software built correctly?。后面的Validation就是Have we built the right software?
单元测试,更多的是Verification。所以有时候经过我单元测试和集成测试以后的功能模块,在交给其他同事做功能测试的时候,依然会有一些BUG,这时候开发可能会埋怨我测试得不够完全,诸如此类。但是其实很多时候,我的关注点是单个方法的功能、行为,没有站到更高的位置来测试这个模块。对于这样的问题,开发和测试应该互相体谅,我本人也会提高自身的水平。希望在单元测试和集成测试中也加入更多关于Validation的思考。

单元测试的坏味道

Martin Fowler有一本很出名的书《重构》,里面有个很出名的概念,Code Smell。前阵子我也刚发现一本很好的书,《XUnit Test Patterns》。这本书主要讲的是如何重构测试代码,这里的测试代码指的就是自动化测试的代码,再进一步细化就是单元测试为主的自动化测试代码的重构。由于此书已经让清华大学翻译烂了……所以建议大家下载英文版。
所谓的测试的坏味道,有三种:

项目(Project)
行为(Behavior)
代码(Code)

按照《重构》书中提出的坏味道的概念来看,如果说是有坏味道(Smell),那么大多数都是指代码级别的。什么的坏味道?就是程序有可能会有大问题的一种征兆(symptom)。个人理解就是不能被直接观察到的现象,可以称之为坏味道。
对于自动化测试代码来说,如果有了项目级的坏味道,通常变现就是生产环境出现了BUG。如果出现这样的情况,那么自动化测试代码就不是有味道那么简单了,而是有问题了,自动化测试的安全网没有能够抓住这个BUG。

微软ZUNE死机原因–单元测试百分百语句覆盖率是不够的

微软的30GB版本Zune在08年的最后一天出现了大规模死机的现象,原因其实就是一行代码原本应该写为大于等于,但是实际上写成了大于。下面来看看具体的代码,第5行就是导致死机的代码。
while (days > 365)
{
if (DateTime.IsLeapYear(year))
{
if (days > 366)
{
days -= 366;
year += 1;
}
}
else
{
days -= 365;
year += 1;
}
}

《Software Testing》第七章 – 白盒测试

第七章:Testing the Software with X-Ray Glasses。
Dynamic White-Box Testing(动态白盒测试)-动态,就是软件在运行;白盒,我们能看见里面怎么运行。所以就好像是带了X-光眼镜一样。它还有另外一个名字,就是结构测试(Structural Testing)。动态白盒测试通常包含了四个方面。
1.直接对底层的函数,过程,库~等进行测试。也就是对API的测试
2.站在一个比较高的层次来测试软件,而且是根据你对软件行为的认知的情况下进行,根据code具体的情况设计有针对性的case进行测试
3.验证已经设计好的case是否真的符合了当初设计的初衷。还有就是强行改变一些通过正常途径很难达到的软件的状态。这个例如说,一般软件都有很多错误的提示信息,但是要把全部错误信息通过正常渠道(用这个软件)得到,是比较困难的。不过在白盒测试里面,我们可以直接在debug器里面改相应的flag变量来达到目的
4.根据各种code coverage的结果来对已有test case的增加和修改,以达到更好的测试效果。
个人的一些体会,其实测试就是一个动态的过程,test case需要动态的维护、更新和增加,以达到好的效果。呵呵,动态可不单只是指软件运行~一语双关啊~或者说这个词被重载(Overload)了。