对于Test Case的一些看法

本文探讨了在软件测试过程中,测试案例(TestCase)并非一次性完成的现实情况。文章提出了一个更为实际的测试案例开发流程,包括在Alpha版本前制定框架、随测试深入逐步完善案例等步骤。
按照软件工程瀑布模型以及其他的一些说法,Test Case应该是以SPEC等文档为依据,在具体测试开始之前就应当完成的。测试中按照Test Plan,Test Case进性测试,并在后续的各种版本中验证Bug,进行相应的回归测试,Test Case似乎不用在做什么改动。但是这更多的只是一种理想状态,实际上很难达到这种流程。原因太多:
1、需求的变化。
2、测试初期对软件的理解其实往往是比较肤浅,随着测试的深入,理解才慢慢深刻起来。这时才会发现其实有
很多的Case还需要增加。
3、SPEC 以及需求文档等等往往也是不全面的,所有的设计并非天衣无缝,往往到了实现阶段才发现问题。
所以我认为Test Plan,Test Case从来就不是一次完成的。从各方面的角度考虑,觉得如下的步骤比较容易实现。
1、Alpha版本之前,也就是测试的第一版之前,对于Test Case不要过早深入细节,首先根据SPEC实现一个合理的Test Case的框架。
A、对于一些共有功能可以参考其他相关AP的Test Case,比如Installer的测试。OCR功能的测试等等。
B、着重于AP的基本功能实现,指明测试的方向。
C、要便于以后添加新的用例。
2、随着测试的深入逐步增加并展开。这里依然要注意以下几点。
A、Test Case并非越多越细越好,关键是在于要广,帮助测试人员开拓思路。
B、Test Case应当对测试有指导意义,留有适当的空间让测试人员去发挥.
C、当情况发生变化时,要及时更新。
 
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值