锁定老帖子 主题:完善测试案例省心又省力
精华帖 (0) :: 良好帖 (3) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
---|---|
作者 | 正文 |
发表时间:2010-06-26
hgq0011 写道 首先,非常感谢mock1234的回复 mock1234 写道 编程人员基于传统的单元测试的书本知识来写测试是作用很有限的。当你花很长时间(比如2天)写下功能代码,然后再考虑写单元测试,这时候写出的所谓单元测试往往是限于你的编程思路中,其实是重复无用的东西。传统的测试只好纠缠于所谓覆盖率问题,让人难以自拔。 这是因为传统的单元测试思路的所谓“单元”,纠缠于个别功能代码,而不是反映需求。 我觉得我们的项目不是简单的单元测试。应该也包括功能测试,集成测试,回归测试。 由于当前只是满足业务部门,对功能进行调整,也就是修改原有代码。单元的测试时间不会间隔那么长时间的,每前进一点就会测试的。我想请问的是关于用例覆盖率,怎样才能够做好测试,做好案例覆盖,您有什么好的见解呢?我个人觉得回归测试就是要每一个每一功能都要测试,每一个案例都要覆盖到,才能够保障软件的可用。 mock1234 写道 敏捷开发强调是先写测试,用测试来驱动出设计思路,测试代码是针对设计而不是针对你的实现代码!这是非常关键的。由于是比较高层次的测试思路(即根本不考虑你的实现代码),当你写30个纯粹为了驱动出设计才写的测试,并且每10分钟之内就回归一次(每一次自动随机产生测试数据),那么这些测试之间相互牵制就会发现大量深层次bug。特别是,要打乱测试顺序、并且可能的话开100个线程并发测试,可以发现大量深层次bug。 您说的测试驱动设计,来指导开发。当然非常好。但是,我们的系统不是简单的可以模拟随机数,就可以测试的。系统要和第三方的设备通讯,所以测试比较复杂。我觉得您说的“当你写30个纯粹为了驱动出设计才写的测试”也是测试案例的一种体现。如果你所说的30个为测试驱动设计的测试,能够把所有的情况考虑到,那么把它转换成测试人员的测试案例,那么也能够保障软件是可用的。 mock1234 写道 核心的观念是:1.测试不是用来证明你的实现代码的,测试应该驱动设计的。2. 测试应该每1~10分钟进行一次(你可以选择大部分时间仅执行最近7天的测试,但是每天也要至少进行5次全面回归测试)。3. 在有任何编程想法前都坚持先写测试然后才实现,而不是相反。4. 你编程每一个1个小时都应该写下一个测试,而不是2、3天才写一个测试。5.一个项目的测试驱动必须达到一定强度,也许100也许3000,总之不会很少。 真正的测试驱动开发,轻松、自然、有趣,你会有勇气去修改自己的代码,有勇气让别人随时修改你自己的代码,有勇气随时(闲时)重构系统结构。看似摸着石头过河,实则永远追求统一。你不再盲目纠缠于理论,不再简单地靠过分纠缠理论的是是非非来“保证”你的代码的正确性。 不但对于功能代码,对于GUI也要自动化测试。一个基本的原则是:如果你的代码注释掉了之后仍然可以让自动测试程序通过,那么就说明这些未经测试驱动的代码就是有毒的代码早就应该删掉。 要想进行测试驱动开发,首先要抛开传统的单元测试观念。 您所在的公司都是这样开发的?那真的很羡慕,很幸福。 能请教你们怎样实现自动化测试?我觉得非常的有难度。 其实很难,特别是实施起来。TDD太消耗时间咯 |
|
返回顶楼 | |
发表时间:2010-06-26
t42dw 写道 看了这么多有关测试的东东小弟十在郁闷,做了2年开发了从没像各位说的那样测试过,之前做华为外包开发时间很紧且需求变动很大,如果想测试做充分的话怕是项目不能按期交付。 时间相对宽松才行,关键是看上级的素质,有些根本就不懂,认为开发+测试=开发。 |
|
返回顶楼 | |