首页 > 编程知识 正文

测试用例管理工具有哪些功能,测试用例设计工具

时间:2023-05-06 16:25:02 阅读:250867 作者:1908

目前市面上的测试管理工具有很多,功能基本上都大同小异,要完成一款测试用例工具的选型,首先要需求明确,就是说你要用这个测试管理工具干什么? 最终想要达到什么目标?才能进一步完成对测试管理工具的选型。

除此方法外,我们团队调研对比了当前市场上的测试用例管理工具以供参考,以及工具的选择经验供借鉴。

一、明确需求

测试管理工具大体上分俩类,一类就是面对QA的功能测试,主要是满足测试人员对用例的维护,测试计划的建立,用例的执行,以及生成测试报告等。

另一类就是面对开发人员的接口测试,功能测试,压力测试,性能测试,以及自动化测试,到最后的集成到流水线中,有的公司这块由专门的测试人员来做,而这是2种不同的使用场景,对工具的要求也大不相同,在不同的企业内,这2种场景可能都是由一个测试团队来完成,也可能是测试人员只是负责功能的实现的测试,开发人员来完成接口测试,功能测试,压力测试,性能测试,以及自动化测试,这完全取决于团队的工程化水平及人员配置。

聊到测试,有的人说用Excel就足以,通过Excel来维护测试用例,每次产品发布,按照Excel里面的用例,把产品功能过一遍,这样做也没问题,但是你想过没有,随着项目的迭代,复杂度的增加,Excel的缺点就显而易见了,工作的效率及其低下,并且不能多人合作,用例的版本维护乱七八糟的,并且无法与缺陷做到实时关联,可以说用Excel来测试的团队,是那种及其小的团队,一个测试人员而已,或者没有专门的测试人员,由产品来代劳,我们就把它称为广义测试的第一阶段吧。

而在一些稍具规模的公司,测试团队大概在20人以内的,基本上都会选择一个成熟的测试管理工具来管理整个产品的质量,达到多人协作,包括用例评审,讨论,版本,测试和需求,缺陷的关联,测试报告 以及后续的统计分析,能更好的支持反馈和跟踪,持续提高产品的质量,保证产品的稳定性,我们就称为广义测试的第二阶段吧,大多数的公司基本上也都处于这个阶段,这个阶段的工具非常多,功能也不尽相同,笔者就目前国内做的比较好的几款产品做了一些简单的功能分析,供大家参考

二、国内几款好的产品的对比分析

通过笔者的比对,目前看 PingCode 产品的 Testhub 功能是比较全面,并且用户体验非常好的,但是它在测试自动化,以及Open Api 这块基本上都不支持,这块是弱于Jira的,这就回到前面的问题了,你要用这个工具来做什么的,达到什么目的?

从这点出发,Testhub 完全能满足我的需求,还有一点让我心动的地方就是 Testhub 是支持用例自定义,这对于对扩展有情结的人来说非常重要,因为业务是多变的,多给自己留点空间,同时用例导入这块支持脑图的导入也是非常吸引我的。

Jira在测试自动化,以及OpenApi做的比较好,这是其它几个产品不具备的,但是Jira对本土化的支持不是很友好,行为习惯和国内的用户有一些差距。

禅道是开源的,用户可以自己下载搭建,但有一定的使用门槛,笔者不太喜欢它的界面风格,当然对于有代码控的人除外。

ones现在还是收费的,试用版本有诸多的限制

上图中的功能比对也是以笔者所在的公司的业务决定的,视角也可能不是很全面,需要这方面的工具的同学还是要自己亲自注册比对,做出自己最好的选择。

聊到这,除了工具的对比之外,大家会觉的测试应该还有更高级的阶段,没错,你想的是对的,性能测试,压力测试,负载测试,自动化测试,以及集成到流水线,我们把这个称为广义测试第三阶段吧,笔者目前所就职的公司基本上是处于这个阶段的,但在性能测试,压力测试这块基本上是0,也可能是目前的数据量和用户量没达到一定的级别的原因吧,也是需要持续改进的。

经过一段时间的调研和产品的试用,最终我们选用了PingCode TestHub测试管理工具,带着好奇心并对PingCode这个平台的其它产品做了一些研究,总之他们的产品非常全面,是一款支持研发全流程的产品,在研发的工具链,通过敏捷开发,测试管理,项目集,知识库,以及其它的多元化产品来服务研发的全流程,从而形成DevOps的闭环,持续迭代,持续发布,持续交付。

三、使用经验总结

目前笔者就对正在使用的PingCode 的 Testhub 做一些总结性的介绍

用户体验友好,界面清爽,适合国内企业的用户风格功能全面,全部支持我们定义的测试第一阶段的所有功能作为研发全流程的一环,完美实现了和其它研发产品的对接,互联互通官方的发布计划,下一步会完全支持测试自动化,对于想支持这块的用户也不用担心了

一个高质量的产品,测试是必不可少的,一个好的测试管理工具对提升研发效能也至关重要,笔者就Pingcode Testhub 产品的一些使用心得做简单的介绍

创建用例库:
用例库是用来存储所有的用例,对用例统一的管理,按照不同的项目,对应不同的用例库,在研发体系中,有一些公用的用例,我们也可以把这些用例放到一个公共的用例库里面,通过共享用例库的方式来达到公用,从而减少用例重复维护的工作量

创建测试用例:
你可以按照所测试的功能点建立对应的测试用例,书写用例步骤,设置用例的级别,维护人,用例的类型,备注等,用例的步骤支持复制,同时用例支持连续创建,这个功能点非常的爽

导入测试用例 : 支持 Excel 和脑图导入,脑图的导入这个功能很赞

用例列表的维护:含糊的橘子创建了很多用例了,就需要一个维护页面,在这个界面,可以批量设置维护人,删除用例,把用例移动,复制到其它用例库,同时还支持各种条件的搜索,功能非常的全面

用例和用户故事关联:这里支持测试用例和用户故事的关联,就是说你这个用例是测试那些用户故事的场景的,并且能很方便的去查看所关联的用户故事的信息,状态,等
新建用例评审:在有一些场景,一个测试人员写完的测试用例,并不是立马就按照所写的用例来测试的,可能会有一个评审的环节,大家通过评审,共同去梳理这些测试用例的规范以及全面性,提高测试的能力
评审结果展示:这个界面就是展示评审通过的用例,评审通过的用例是得到大家一致认可的
测试计划:用例维护好了之后,我们就可以通过测试计划来完成一次的功能测试了,也就是说,你要测那些功能,就通过一个测试计划来把所测的功能对应的用例规划进来,测试计划的建立,具体取决于每个团队的流程。
执行用例:我们按照测试计划规划好测试用例之后,就是具体的一个个的来测试功能来,填写在真实的测试过程的实际值是不是符合用例的期望值,是不是功能有缺陷,测试是否通过,等等
用例与缺陷关联:
如果你在测试的过程中发现了缺陷,你可以立马在执行用例的上面创建一个缺陷,提交到缺陷系统中,同时这个缺陷和这次的测试关联起来,做到可以追溯,开发人员修正缺陷之后,测试人员也可以进一步的回顾测试。
用例的自定义配置: 这个功能非常强,用户可以定义自己需要的任何场景的测试用例,支持定制化
用例的模板:
对于测试人员来说,有些测试用例测试步骤大体上是一样的,只是有一些细微的差别,这样用户在写完一个测试用例之后,可以把它保存称模块,在书写其他用例的时直接使用模板,然后改一改就可以了,非常节省时间,提高测试效率
输出完整的测试报告:对于一个测试团队的leader来说,他可能更关心,一次测试计划的整体报告,测试的覆盖率,缺陷的统计,以及每个测试人员测试了多少用例。

更多的使用细节,就不一一介绍了,总之好用还免费,有兴趣的同学注册PingCode,自己试用一下吧。

SSM框架配置文件是什么SSM增删改查的流程是什么

版权声明:该文观点仅代表作者本人。处理文章:请发送邮件至 三1五14八八95#扣扣.com 举报,一经查实,本站将立刻删除。