有没有使用前后工作效率对比?
无论是单点执行还是并发执行,测试结果的验证都是测试用例必要的要素
selenium 定位下拉框元素,不区分是"封装在接口里面的"还是"直接写在代码中的"
做事前要先思考,解决这个问题用管理手段和技术手段,哪样更好?
1.需要经常给团队中进行质量赋能,让大家都知道测试都在做什么,让大家的认知达到统一,从质量内建的角度告诉大家质量应该提升起来,就比如说要防止生病,比治疗更重要一样
不发表看法了,听起来像近来流行的废话文学
2.测试效率方面 测试人员必须适应当代社会效率增长的变化,提升自己的能力,保证测试效率增加的情况下,价值会逐步的体现
既然提到"价值",就得拎出马克思主义经济学那套了,里面讲的是劳动效率增加,单位劳动时间减少,价值降低
3.从各方面专业的测试分析报告中体现出来,就好像病人需要看到很多数据才能相信自己得病了一样 对 bug 进行分析,分析其避免的损失,以及在开发的过程中,预防的问题所带来的好处,逐步让管理者认可测试在过程管理中的价值
有点困了,算认同吧
优秀团队就得有优秀团队该有的样子!
优秀 lead 就得有优秀 lead 该有的样子!
宁要蹦天猴儿,不要老实头儿
马德华?
建议查阅官方说明文档,或直接问其技术支持人员。
这是对显式等待的滥用。
去掉显式等待试试看吧。
怎么选中下拉框数据,这是 selenium 定位元素基本操作,加那么多定语干嘛
还可以自动化
自动化测试产生的什么数据?
测试用例评审,不能让开发人员参与。
比如运维负责环境搭建,然后测开说 :我也会搭建环境,你 k8s 里的一个参数改成 20,系统性能会更好~,然后留下运维表面佩服内心 mmp
作为运维,正确的姿势是:k8s 里这么设定参数是基于系统整体运维方面的考虑,而不是局部。你能给出建议说明你也具备一定的运维技能,但如果想在这个领域有更多成就的话,推荐你先看完这几本书,《运维从入门到精通》、《21 天入门运维》……,建议仔细研读,有看不懂的地方可以来问我或 Jeffrey,共同探讨共同进步。
比如拿着代码对开发说:你这么写在高并发下回产生死锁,赶紧给我改,不改好不许下班。
作为开发,正确的姿势是:这么写是基于系统开发整体方面的考虑,而不是局部。你能给出建议说明你也具备一定的开发技能,但如果想在这个领域有更多成就的话,推荐你先看完这几本书,《编程从入门到精通》、《21 天入门编程》……,建议仔细研读,有看不懂的地方可以来问我或 Jeffrey,共同探讨共同进步。
“核心字段” 的定义和分类,若来自引用,建议注明出处,若仅为个人理解,建议备注说明,避免造成误导。
我们还必须记住,自动化测试不是自动的。开发人员在确定所需的一组标准后,仍会创建测试脚本和工作流。这些测试可能会被重用,但仅限于共享相同标准和需求的软件。
看来手工测试还没做到足够好,先搞定手工吧
为什么开发人员不喜欢自测,不做单元测试的根本原因就是因为他们理所应当的认为有测试进行把关,所以不用太过早担心质量问题!
感谢认可和肯定,呵呵😊
若是转发,请注明出处
先手工测着,等产品稳定了,再考虑自动化
你好,不能这么理解的。
实际上,这个并没有确切定义。
辛苦