确实,所以我来社区求助大家了。
好的,感谢回答,我试一下
痛点
怎样在研发每次更一个小功能,自动触发自动化测试
目的每次研发发版一个小版本,能实时感知到,然后可以跑一下自动化的冒烟测试,来判断当前版本是否可以测试
确实服务器没有想推动属实不易,往这个方向走就是得有成本支持,不然真搞不下去。不过你的半成品来看,还是很不错的。我努力靠近。
给大佬点赞,我试了一下那个根据 prd 生成测试用例的,还是挺好用的。生成用例准确度还可以
为啥推不起来哇,听你的描述感觉还不错的样子。你的 demo 和 ppt 有上传到 github 或者 gitee 吗?想学习一下。我目前打算推动一下这些在自己小组。
实际使用起来效果怎么样
您这边有使用示例吗
有出系列教程吗
好的,谢谢!
好的,您平时 web 自动化测试都是用的影刀吗?
接口自动化还好,主要是想实现 ui 自动化,通过现成的开源或者付费工具。
二开吗?部署了这个社区版的,ui 测试也仅是企业版才支持,和相关人员联系并确认了。后续并不会继续维护这个 ui 测试功能。
我实际使用了一下影刀,关于实现 webui 自动化测试有以下几方面的问题
问题一:录制的脚本不支持导出成 python 脚本,那如果录制的脚本达到上限怎么办
问题二:录制的脚本是否支持多个脚本并行执行呢
问题三:如果后续想引入 CI/CD 是否支持呢
问题四:脚本是否支持定时触发呢
大佬是否涉及这些场景呢?在实际的使用过程中
影刀那个支持本地部署吗?
关于别的大家还有了解吗?目前打算先本地部署 metersphere 开源版试用一段时间
也是比较具体的实践路线,感谢给出的建议
感谢给出比较具体的例子,我会试着按照您给出的具体方式去调整用例设计的。并且在空闲时也按照上边给出的具体方式去实践的。
我这个测试系统是有点偏向低代码,就明道云那种类型的项目。在写用例过程中也的确存在你列出的 ---- 这导致主流程下会有很多的支线流程。而写测试点容易停留在主干流程,但写成具体用例时需要覆盖各种分支场景,这导致设计时感到逻辑缠绕,因此心里没底就会产生” 奇怪 “的感觉---
虽然只有我一个人,但是我也还挺有压力的,因为感觉相比研发、产品、实施,自己存在感比较低。好像价值不大,更不能创造出很有价值的东西。自从开始测试这个项目,做的最多的也就是纯功能测试,每次一听到有人反馈 bug,就是自己内心一咯噔。虽然知道不可能有完全没 bug 的系统,但是也还是会控制不住自己。有的时候,有些 bug 确实是我没有测到。平时写用例并没有按照 -- “场景法”+“状态迁移法” ,“边界值法” 与 “异常路径” , “判定表”,用例设计分层这些具体的方法去写用例,最近写完了一个新功能的用例,我再试着去用这些方法,具体实践一下。
你可以按照这个思路去构想一下
1.首先介绍一下功能测试 - 因为是面向大家的,而这个群体可能有的对功能测试认知比较片面
2.介绍一下自己平时在功能测试过程中的步骤,可以突出强调一些自己觉得比较好的方面 - 这样可以让大家快速知道哪些是值得借鉴的点
3.以某个案例具体说一下怎样展开测试,以及问题排查,最后验证问题的解决
4.分享一些测试学习资源
我平时测试确实也比较表面化,虽然接触这个系统很久了,但是还不能完全说出它背后的流程,看来对业务这一块的熟练度还很欠缺。
好的,我按照这样的方式去实践一下。
看到大家的很多回复都是说要熟悉业务,但是我目前每次接到一个新功能的测试任务都会按照以下步骤进行,看起来我并没有过多接触业务,我是不是应该主动去寻求接触业务的可能
1.看一遍需求文档结合产品给出的文字说明结合原型图梳理出尽可能全面的测试点
2.把这个需求文档扔给 ai,让他给我梳理一下测试点
3.对比 1,2 进行查漏补缺
4.开始写用例
5.先进行第一轮自己评审,修改编写用例过程中的错别字或者是描述不合理的场景或者是错误的操作步骤或者是本期不实现的功能点
6.列出所有功能的测试重点
7.准备测试数据
8.产品二轮评审,修改用例
9.拿到可以测试的功能后,按照之前列出的重点,先冒烟测试一轮
10.评估一下当前功能的质量,决定要不要打回,大概率是不会进行打回,会继续测
10.先测试高优先级用例
11.记 bug,在提出一个 bug 的时候我会进行排查具体是什么原因,有时候自己也能提供 70% 的解决思路
12.回归修过的 bug
13.总结本版本测试过程中用例编写问题,bug 记录问题
是的,单纯只按照需求文档列出的功能点测试是不是就认为是很一般的功能测试呢?
你也是差不多的工作年限和现状吗?那考虑做个搭子吗?一起改变自己。我一个人总是半途而废。自身技术不够,又老想着拖延。
确实,同意您的说法。但我现在属于哪个都不精进。确实要按照您说的先解决痛点,然后再选定方向,一步步深耕。最后才会慢慢提升。我会按照这个建议结合自身实际慢慢对自己做出改变