这个话题上次在广州的沙龙微信群里有讨论过,众说纷纭。
我们的做法:线上问题都会做复盘,各个角色拉到一起,把事情产生的来龙去脉弄清楚,找到哪些环节出现了问题导致了故障的出现。然后定下来针对性的改进项。
故障就代表着质量问题,那我们测试作为质量保障的重要一环,特别是最后的把关,肯定多少都会有责任。只是看这个责任的大小。
但是责任就是代表锅吗?其实未必。每个问题都会暴露流程的缺少,我们勇于承担责任把这个缺口给补上,其实就是把我们的分量和话语权提升上去了。都在讲左移右移,如果你平时得不到老板的支持,那么这些教训出现的时候你顺势提出来,说不定也能得到更多的支持。
当然,如果纯粹是测试用例少了关键场景导致的漏测,那就没什么好说的,该挨打的时候就乖乖挨打。只要态度端正,勇于认错和积极提出针对性的改进项,老板也不会怪太多。
个人的简单思路:
不知道你的 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 是可以的
因为我有点怀疑你是不是参考了我之前一个帖子里面的代码例子:
https://testerhome.com/topics/19035
第一个用例
访问百度首页并搜索 testerhome:
describe('My first test case for cypress',function(){
it('visit baidu home page and search for testerhome:',function(){
cy.visit('h
ttp://www.baidu.com') //访问url
cy.title().should('contain','百度一下,你就知道') //验证页面 title 是否正确
cy.get('#kw') //根据 css 定位搜索输入框
.type('testerhome') //输入关键字
.should('have.value','testerhome') //验证关键字自动是否展示正确
cy.get('#su').click() //根据 css 定位搜索按钮并点击
cy.url().should('include','wd=testerhome') //验证目标url 是否正确包含关键字
cy.title().should('contain','testerhome_百度搜索') //验证页面 title 是否正确
cy.get('[id="1"]')
.should('contain','TesterHome') // 验证第一个结果中是否包含TesterHome
cy.screenshot()
})
})
常见的测试准入检查项(开发提测的检查项)
正如 恒捷所说,这个算不上底层了。
这种场景就好像改 bug 一样,如果开发连 root cause 都没有找出来,然后改了一下代码发现能跑通了,你也不放心说把你的 bug 直接关掉吧?
赛普拉斯
这里的代码是忘了改吗?
触发推送,只需要 call 对应平台(google-Android 自带的推送服务, apple -iOS 自带的推送服务,还有其他推送平台)的 api 就可以了。需要指定对应设备的 token,这块需要在 APP 端打开设置,并且从平台端初始化或者更新之后收集起来放到触发的脚本里面使用。
至于 APP 端的自动化,因为这个推送有一定的滞后性(特别在国内测试 Google 的推送,很难可以收到),而且一定要真机才能收到推送,感觉做自动化不好处理,成功率也不好保证。 个人建议可以通过脚本触发后,手工验证各个设备的接受推送和推送消息的跳转。
比楼主大一岁。19 年(当时 34 岁)准备换工作的时候,收到很多电话邀约,结果都是同一家公司的不同猎头,其他公司投了简历都没有回应。
幸运的是通过其中一个猎头,只用了一次面试通过,然后在现在的外企工作到现在。
结合实际情况,选择自己适合的方案。比如楼主面临的问题,我猜测会不会是现有的系统太复杂或者历史的原因,未必能提取出来系统的接口文档,所以没办法完全用 postman 或者其他工具,用纯 api 的方式去打通?
那么在这种情况下,你用更直观的 UI 自动化去完成前置的登录步骤,也是可行的方案。比如有些系统的登录是需要依赖 SDK 的,而 SDK 里面的登录未必能完全用纯 api 的方式去 call 成功。
原因确定了吗? 是编码的问题还是其他?
建议还是把原因,解决方案说明清楚,对自己后续回顾或者别人参考都有帮助;至于代码,有时候只需要把最关键的那行贴出来就可以了。
比如我猜是设置成 utf-8 那段起效果了。那么如果不设置的话,默认的编码是什么?更改了这个默认配置,对其他有没有影响?能不能解决其他常见的文件或路径的异常情况,比如目录名称有中文或者目录里面有空格?
感谢 testerhome ,在这个测试之家的几年里,学习到很多,也成长了很多。happy birthday!
没有测试过 c 端产品,不过个人觉得 server 端差别不大,主要区别在 b 和 c :
好像之前看过了这篇。
总结得很到位,把我们之前游戏支付的逻辑都介绍得很清晰了
使用什么时区是根据业务决定的啊,比如现在需要统计巴西的用户每天的数据,就要以巴西的时区作为零点进行统计,这里就会涉及到夏令时的问题。
https://testerhome.com/topics/27557
之前有类似的帖子
找了之前记录的两个印象深刻的 bug,提交参与一下
我司对背调就非常严格。重要的是: