对于Test Case的一些看法

按照软件工程瀑布模型以及其他的一些说法,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、当情况发生变化时,要及时更新。
 
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值