基于测试用例进行测试管理

对于产品来说,如何通过黑盒测试来保证产品的质量是一件很艰苦的事,手工测试人员一遍遍的进行测试,最大程度的发现产品中的缺陷。个人认为,在黑盒测试中,测试的核心工作

对于产品来说,如何通过黑盒测试来保证产品的质量是一件很艰苦的事,手工测试人员一遍遍的进行测试,最大程度的发现产品中的缺陷。个人认为,在黑盒测试中,测试的核心工作内容应围绕着测试用例来进行。下面为个人对“基于测试用例进行测试管理”的一些认识。

我们都知道,测试,不管是白盒,黑盒,功能或性能测试都离不开测试用例,可以怎么说,测试用例是一切测试的基础,也是测试的核心地区。测试用例设计的好与坏,完善与不完善都直接影响到测试的效果,产品的质量保证。下图为一个简单测试用例中心图,大家可以自行扩展,进行添加或删除。
  在这里插入图片描述

更多相关知识点击如下链接进行获取:
https://edu.csdn.net/lecturer/6110
https://edu.csdn.net/course/detail/32107
https://edu.csdn.net/course/detail/32047
https://edu.csdn.net/course/detail/31981
https://edu.csdn.net/course/detail/31967
https://edu.csdn.net/course/detail/31941

上图完全是与测试用例为核心进行管理,下面进行解释:

1、软件测试的几个关键过程可以通过中间一列进行表示出来,一般测试人员在进行参与项目测试时,首先应该由测试负责人根据软件需求进行测试需求提起,然后通过测试需求来确定项目测试的目标和缺陷判定标准。测试策略是根据测试需求来制定详细规划,最后分发到各个编写测试用例人员手中进行测试用例编写。在进行测试用例评审过程中,可以发现测试用例为中心管理第一点好处,测试用例编写反应出测试人员对需求的理解程度。通过“需求——测试用例”,逐渐达到熟悉软件需求和用例完善。

2、再看第二点,执行测试用例发现软件缺陷,通过图中的“软件缺陷——测试用例”,也构成一个小循环,执行人员在执行测试用例时,能发现测试人员编写用例水平情况,完善程度。而测试用例也能让软件缺陷被发现越多,提供给开发人员的缺陷描述越准确。这也就是第二点好处。

3、“软件缺陷——测试需求”可以看成一个大循环,通过对需求的理解可以设计出测试用例,通过执行测试用例可以发现软件缺陷,反过来也一样,通过软件缺陷可以反应出测试用例是否完善,也能反应出需求的不完善,促进项目产品的功能越来越完善。

4、通过编写测试用例效率,执行测试用例速度情况,都能看出一个测试人员对业务知识的掌握情况,掌握越多,编写用例肯定比较完善,执行人员也能快速执行用例发现问题。通过测试用例编写与执行情况,可以促进业务知识方面进行培训,这是第四点,“业务知识——测试用例”的循环。

5、测试用例是测试人员进行的一项测试工作,也是耗时最长,需要消耗精力最多的测试工作,如何保证后续产品能快速测试并且能保证产品质量,这就需要进行回归测试,可以使用自动化测试进行,但对于没有进行自动化测试的公司来说,从测试用例中挑选一批高质量的回归测试用例,在每次新版本中,进行快速回归测试也是一种不错的做法。

6、当然即使进行自动化测试,也还是需要进行编写自动化测试用例,开始的测试用例如果编写完善,详细的话,一些用例可以直接做为自动化用例,这样也提高了测试效率,第六点。

7、而对于测试部门来说,测试知识库的积累显的至关重要,完善的知识库,不但可以让新员工快速对公司产品测试上手,测试用例库是一个最好的积累,新员工可以通过阅读用例快速掌握产品功能,业务知识,常用的测试手段,用例书写方法等。而且对一些测试技巧也能很好的提高。

8、测试用例知识库的积累还能使迭代开发的项目,减少很多书写测试用例的时间,对于新项目,可以进行项目测试用例的迁移整理,修改。而不是重新书写新的测试用例。

9、测试绩效考核,一些公司通过编写测试用例数量,执行用例数量,发现缺陷效率等来进行,这些都和测试用例有关。所以说,测试用例的好与坏,不仅直接影响到测试效率,而且影响到测试人员的绩效效率。

上面只是介绍一些和测试用例挂钩方面,下面说一些具体做法:

测试用例编写:

在测试负责人分配测试用例编写计划后,最好由业务知识熟悉的员工进行用例编写,每周进行一次用例评审,直到测试用例编写完成。

测试用例维护:

其实基于测试用例进行测试管理的重点就在“测试用例的维护”,好的维护才能保证用例的有效性,实施性。一般测试用例维护最好在每周组织测试人员,对测试用例进行维护和更新。一般用例需要改变会有以下几种原因:

1、软件需求的改变这个应该遵循需求变更控制进行管理,相应的用例变更。 2、测试人员对需求的理解错误导致设计的用例错误 3、开发人员的设计文档进

1、软件需求的改变——这个应该遵循“需求变更控制”进行管理,相应的用例变更。

2、测试人员对需求的理解错误——导致设计的用例错误

3、开发人员的设计文档进行变动——用例修改更新

4、测试用例的遗漏——测试用例补充

5、版本发布后,用户反馈的缺陷——重现缺陷,补充或修改用例。

通过上面每周组织测试人员进行用例更新维护,用例库会在软件产品的更新中不断的完善,也就让测试用例的覆盖逐渐的完善了。最后当项目结束后,就能得到一份完善的用例库。至于用例库的管理,可以参照公司对应的“配置管理实施”。

总之,“基于测试用例进行测试管理”——关键就是测试用例的维护,要保证测试用例与产品功能一致性。

更多相关知识点击如下链接进行获取:
https://edu.csdn.net/lecturer/6110
https://edu.csdn.net/course/detail/32107
https://edu.csdn.net/course/detail/32047
https://edu.csdn.net/course/detail/31981
https://edu.csdn.net/course/detail/31967
https://edu.csdn.net/course/detail/31941

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值