对测试用例的一些看法

测试用例对测试人员来说是一个避不过去的话题,现在测试人员都比较重视测试用例,也都在承认测试用例在测试过程中的用途。

今天看到一个相关的测试用例评审的帖子,就写了一些回复,大概的表达了自己对测试用例的一些看法,未必正确,仅作参考和记录。

 

原文:

如何进行测试用例评审

http://blog.csdn.net/emma_he/archive/2009/05/18/4196958.aspx

 

回帖:

其实,我个人觉得,评审更多的是看有多少的工作量。
看你文中的意思,测试用例使用的是详细用例,也就是说,尽可能的参照用例就发现问题。
这样即使一个很小的项目,测试用例数很容易就膨胀到几百上千甚至可能上万。别的不说,这个用例的管理、审查等等需要多少的人工。
评审测试用例的人,真的可以全部每条都仔细检查吗?如果不详查,只能泛泛发现一些表面问题,评审用例就失去很多的意义了。
而且测试用例既然需要评审,那么就需要一个相应的控制流程,类型比如基线,比如如果软件需求、设计变更等,用例也都需要相应的变更流程,变更后也需要重新审核等等等等。
其实我个人觉得,测试用例对测试最大的用途是推卸责任,就是说,我编写了用例,有了很多的工作量,而且开发、QA等也都参与评审了,也都认可了我的测试用例,我也用此用例发现了缺陷。那么假如在测试人员测试后,还有人(比如客户)发现了测试用例没有发现的缺陷,那么责任就大家分摊,否则评审测试用例做什么。
我个人认为,除非你用CMMI等沉重的大流程,有大量的人员和时间给测试用,前期文档、整个过程对测试也没有什么阻碍,这样才容易编写比较详细的测试用例,而且可以有相应的流程去审批测试用例,测试用例才容易产生实际的作用。
对详细测试用例我一直保持悲观的看法,我更喜欢测试检查单,提醒自己测试过程中容易遗漏的地方,而不是做详细的测试用例,这个工作量让我不寒而栗。

OA协同管理系统测试用例设计是一个关键的测试环节,它能够确保系统的正常运行和功能的正确性。以下是我对OA协同管理系统测试用例设计的几点看法: 1. 需求分析:在开始测试之前,需要对OA协同管理系统的需求进行深入的分析,确保测试用例的全面覆盖。 2. 设计用例:根据需求分析结果,设计合适的测试用例,并与开发人员协作,对测试用例进行调整和改进,确保测试的准确性和完整性。 3. 编写脚本:测试用例设计完成后,需要使用自动化测试工具编写相应的测试脚本。测试脚本能够提高测试效率和精度,减少测试过程中的人为干扰。 4. 测试执行:完成测试脚本后,根据测试计划执行测试用例。在测试执行中,需要注意测试环境的搭建和测试数据的准备,确保测试能够全面和准确地覆盖系统的功能和性能。 5. 缺陷总结:测试完成后,需要对测试结果进行总结和归纳,将存在的缺陷进行记录,并及时与开发人员沟通和修复,确保系统达到高质量的发布标准。 除了以上几个步骤,还需要注意测试用例的合理性和有效性。测试用例不应该过于杂乱和庞大,需要进行筛选和优化,使测试过程简单清晰,提高测试效率。同时,在测试用例设计中,需要不断地学习和掌握新的测试技术和方法,以适应快速变化的测试需求。
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值