感觉楼主有点矛盾啊,标题是想用 fixture,但是又不考虑 pytest, 所以是 unittest 里面可以支持 fixture 吗?
其实 unittest 转化成 pytest 还是很快的,不知道楼主是基于什么原因,一点都不考虑 pytest 呢?
我记得楼主前段时间有发一篇三十五岁之后找到一家外企工作的帖子。其实楼主的这个经历,和这篇提到的各种敏捷团队,等等,都和我现在的情况非常相似。
我是三年前入职已经广州的外企,然后去年团队原来的老大离职之后,由我接手团队的管理。上面我的每一点,都是和老板,和开发团队沟通之后的感受。在老板的眼里,是真的不会关心你做得有多累,而是看你是不是真的把你的工作做好。这个自上而下也是成立的:你也不会希望你的自动化工程师整天在忙着手工测试,没有自动化产出吧?
所以还是要学会换位思考,把自己从一个尽责的团队万金油测试,转变成为一个管理者的角度和心态。不要想着面面俱到,把什么细节都做好,不到迫不得已,也别把自己陷进去具体某个难点里面去埋头苦干。发掘团队里面合适的人,把你的想法和任务分给他们去帮你完成。如果没有合适的人,说明的也是你需要培养或者招人,把团队的短板补起来。
管理不易,承受来自各方的压力也不易。与君共勉!
我觉得楼主的问题是作为 leader,对自己团队的规划和现状都不够清晰,不知道是不是也没有和老板沟通清楚?
我都不知道你们测试团队在干嘛? 开发这么提,说明他是不清楚测试团队的目标和现状的。但是你作为测试团队的 leader,为什么也答不上来呢?如果这个问题下次是老板在和你年终考核的时候问呢? 团队可以做得不够好,可以有上升空间,但是重要的是要看到进步和未来的目标。这时候 leader 的计划与目标,总结和调整都很重要。
我都在忙线上的事情,没有那么多时间参与自动化测试这些。 其实可以想想,作为测试 leader,这个回答和产出真的 OK 吗?团队可能是真的很辛苦,你作为 leader 也很累;但是如何客观评价一个人,一个团队的工作是否合格,不是看他做得有多辛苦,而是要看他是不是把自己的职责都认识清楚和完成。如果不是在自己该尽的职责上面埋头苦干,获得的可能只是苦劳,而没有功劳。
api 测试是开发的,不能算在测试头上;你的 automation tester 只是在学习,没有产出... 这些评价,你作为测试 leader 认可和接受吗? 好像也没看到你在保护你的团队,据理力争?
个人建议你先找个时间把整个团队的计划,目标,和现状,难点什么的理清楚。长期目标是什么,短期目标先解决什么问题;落地的难点,找你的核心队友帮你解决;对外的难点,找你的老板帮你沟通。我觉得这是一个来自身边很好的提醒,好好想想自己怎么去做好这个 leader 的角色。
我也是基于这个官方教程去改造的,把保存的文件从 JSON 改成 pickle 就可以了
这不就是 selenium 常见的处理问题之一吗? 而且为什么要写死坐标,不用考虑不同浏览器和分辨率的兼容性吗?
我们的做法是做个通用处理,如果元素看不到就尝试滑动,直到元素可见或者滑动到了底部为止。
感觉还是以前一样,直接显示 匿名 直观一点,已经不是第一个人理解错了
“你写出来的用例要让没接触过这个系统的新人小白都能够去执行!”
说实话这个观点和标准在现在已经不那么适用了。特别是对复杂的系统,你敢放心把用例交给小白去执行?没有一段时间的培训和熟悉,你敢信他能正确理解你用例设计的测试目的和测试步骤?
写用例是需要时间成本的,用例步骤,期望结果写的越详细,所需要的时间成本越高,维护的成本也越高。反而如果我们是以 “对系统有一定熟悉程度,并且接受过足够的业务培训和用例交接的测试工程师” 作为你的用例编写的标准,对成熟的团队反而是更有效的方式。
正好前段时间用 pickle 和 FileLock 做了这个改造,步骤大概如下(代码暂时没办法贴上来):
指平台给商家打款吧,我理解
我理解之所以走人工审核,就是因为没有犯错空间了
思路就是封装一个登录的方法,然后把登录结果通过一个 pickle 的库,存到一个文件里面。
通过 fixture 去尝试读取这个文件,如果能拿到就返回已登录的结果;如果这个文件不存在,就说明还没有登录,就去登录一次,并且保存登录结果。
其实这种是属于硬件问题吧? 而且大概率和施工场地的地面情况有关系?
如果套用我们软件系统问题排查的方式,应该先看看正式环境上有没有 log,然后根据 log 去分析原因,再到测试环境去重现问题,验证分析结果是否正确;之后就是修复问题,测试环境验证和回归测试,部署上线然后验证问题已修复。
但是在这个场景下,一般是没办法造一个一摸一样的测试环境出来模拟的(不可能建一条一样的路出来吧?)。所以最好的方式,还得去同一条路上找问题,比如浇一遍水,走一走看那些砖会有问题;或者从工程的角度,看是否使用的材料,施工方式,排水设施是否有改进的措施,等等。
首先问个问题:为什么同一个 ID 在不同表有不同的删除状态的情况?这是特殊需求要求,还是设计缺陷或者运维错误导致的数据错误?
如果这是个很明确的需求(从数据层面看,是最新加的数据被删除了,所以最新应该取上一个版本的数据),那么可以理解是漏测,但可能很难被发现。从设计角度也很奇怪,如果一张表里有很多同一个商品 ID 的记录,而且只会有一个价格是生效的,那么应该给它加标记,而不是通过是否被删除加时间排序来筛选。就好像价格一直在波动,我可能需要把昨天新加的价格挂上来,也可能把上个月新加的价格挂上来。这种情况下是不是直接去更新这个标记更保险也更直观?
而如果是后者,我觉得把责任往测试身上推就很勉强了。
这个话题上次在广州的沙龙微信群里有讨论过,众说纷纭。
我们的做法:线上问题都会做复盘,各个角色拉到一起,把事情产生的来龙去脉弄清楚,找到哪些环节出现了问题导致了故障的出现。然后定下来针对性的改进项。
故障就代表着质量问题,那我们测试作为质量保障的重要一环,特别是最后的把关,肯定多少都会有责任。只是看这个责任的大小。
但是责任就是代表锅吗?其实未必。每个问题都会暴露流程的缺少,我们勇于承担责任把这个缺口给补上,其实就是把我们的分量和话语权提升上去了。都在讲左移右移,如果你平时得不到老板的支持,那么这些教训出现的时候你顺势提出来,说不定也能得到更多的支持。
当然,如果纯粹是测试用例少了关键场景导致的漏测,那就没什么好说的,该挨打的时候就乖乖挨打。只要态度端正,勇于认错和积极提出针对性的改进项,老板也不会怪太多。
个人的简单思路:
不知道你的 Jenkins 上执行不通过是什么表现。Jenkins 上关键也是看执行的 slave 上面是什么环境(selenium 版本,webdriver 版本等,基本上出现特殊的问题都和特定的版本有关)和你本地能执行通过的环境有什么区别。甚至说你本机也可以挂载到 Jenkins 上作为一个 slave 来做执行机。 所以你想:如果本地可以,为什么 Jenkins 上不行呢?原因大概率是环境和版本的差异。
建议你先别纠结无头模式,先把 Jenkins 上报错的原因找到和解决。
当你不知道怎么估总时间的时候,可以试下做 breakdown:把你各个测试阶段和模块拆分开来分别评估,然后汇总一个时间。比如测试方案需要多长时间准备?测试用例?数据准备?环境搭建?测试执行(拆分到每个模块分别多少时间)?回归测试? 缺陷跟踪和验证?
我觉得这个体现的是你们的数据迁移没有拿出来讨论过怎么保证质量(不完全是测试的问题)。
关键是点在于:这是否是一个明确下来,很清晰的需求?还是只是开发想当然就去做的迁移想让也没有考虑过迁移的问题,以及数据完整性?
我觉得完整的方案里面,应该包含数据库的设计是否和原来的数据是融合的,比如表结构是否一致或者旧数据能完整地插入到新表? 字段的长度是否一致?编码格式是否一致?迁移的过程是怎么操作的,是否有做过方案演练和回滚演练?数据迁移完成后怎么验证数据的准确性?是否有基于迁移的数据做过对应功能的回归测试?
如果前面这些都没人考虑过,也没有提出来过,而是直接在线上迁移然后等客户报问题,那么这整个方案都是灾难性的,测试组有责任但不应该是主要责任。
这是一个匿名,不是真的 何建雄。
原因是你回复匿名帖子的时候,默认就是以匿名回复(可能是你回复的时候没留意)。然后匿名的回复,就会随机给一个名字,何建雄就是其中一个。
这个我之前遇到过,空格有可能是编码格式不一样。空格在 ASCII 里面的有 160 和 32 两个值,所以看起来都是空格,但是实际的 ASCII 值不一样。
我的做法是,把里面的空格都转码一下(如果是 160 就替换成 32,然后再来比对:
if ord(string_list[i])== 160:
ord(string_list[i] = chr(32)
昨天也遇到了,Chrome 会报这个错, 换 edge 是可以的