Fitnesse for designer

本文探讨了在软件开发过程中,通过改进测试策略来提高产品质量的方法。重点介绍了使用Fitnesse进行回归测试和日常构建集成的功能测试,以及如何在进度压力下确保代码质量。文章还讨论了代码覆盖率的重要性,并提出了在设计阶段就考虑到测试需求的理念。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

对于design,当前我们存在这样的问题:test code够不完善,有bug不好发现,发现了不好定位,改完了可能引发其他问题而test code能够跑过。 这个想想以前定义的关于“root cause”和“code coverage improvement”的story应该可以了解。

Fitnesse用于regression testing, daily-build integration functional testing 会在一定程度保证quality的基础上提高team的效率。对于design, 写test有时比较无奈:进度压力,quality要求。 这里“进度压力”不是解释一切问题的套话。

对于design, 我们写UT、FT最终是为什么?是不是所有的source code都要用UT覆盖?这个问题不做讨论。下面的内容的前提是:source code会被覆盖,但不一定都是UT;quality会在一定程度上保障,但不一定是追求的code coverage。

我们目前使用的Fitnesse,test时会run我们对外功能接口,与我们目前在test中写的很多测试方式类似。大胆的设想一下,我们把当前test里的某些test由Fitnesse代劳会怎么样?大家肯定会有很多担心,注意我们这样做需要几个前提重要的条件:
1. code要简单易测试, 将业务逻辑code与common code区分开,定义合理的对外接口,这个接口不等同于我们目前在code中定义的抽象的interface,我们可以从TDD的角度理解为是为了run过测试写的接口;
2. 对code写“必要”的UT,构造合理的输入参数,测试各种边界条件;
3. design与test保持沟通,Fitnesse的case要保障。

当然,做到以上几点,即便不借助Fitnesse,quality也能保障,但做两次functional test需要考虑。从以往的经验来看,design与test的协同工作,出现issue的数量会小的多,其中原因大家很清楚。从当前行业状况来看,出于响应变化的考虑,严格的分阶段分过程的做法是值得商榷的,等待一切都OK再开始的做法很难操作。有点跑题了,回到design上,quality不是只体现在数据上,追求数据可能会让数据没有太多有效价值,非左即右的做法不可行,如何更好,我们一直在探索与实践。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值