• 首先一个原则,我们是不可能覆盖市场上所有的机型和操作系统版本组合的。
    建议你整理成一个兼容性测试的方案给领导去 review:

    1. 目标是要覆盖市场上多少比例的机型和操作系统?
    2. 要达到这个比例,需要购买多少测试机? 是否考虑使用付费云测平台?
    3. 有了测试机和云测平台之后,你们的兼容性测试方案怎么和现在的回归测试策略结合起来? 需要投入多少人力去执行?
    4. 是否考虑用自动化测试来做兼容性测试?
    5. 新机型怎么定期购买?
    6. 新的操作系统版本怎么定期投入研究和兼容性测试,避免新版本发布之后对线上客户的影响?

    然后呢,有多少钱干多少活; 出了问题,这是已知的风险, 因为没投钱啊

  • 想起了脱口秀大会里小鹿讲过的一个段子: 你这个个人经验主要是太个人😅

  • 检查一下是不是配置的地址是 localhost,导致不在那天机器上就访问不了(看你的截图)

  • 我当时没有集成 iOS 的代码

  • 我理解性能测试不应该以单个业务来设计, 而是去评估每个接口分别会有多少流量,然后按比例来构造。 比如 四个接口的流量比例分别是 1:2:2:3 类似这样。
    具体的比例是多少,要么是看生产的数据统计,要么是根据业务模型去评估。

  • 我们应该要感谢一直在 “卷”,还愿意免费分享出来的同行们

  • Pyechart 我以前用的是 0.5.5 , 你看看能不能安装这个版本

  • 看你的截图,失败的是 验证 的那个步骤,也就是断言失败了。
    你可以点开旁边的截图看看具体是什么问题,有可能是你用错了关键字

  • 这三百多评论里有一般是我的回复,哈哈

  • 我了解到的,要么是直接前备份数据库里恢复(可能会有数据丢失),要么是从数据库的 log 里面找出来恢复。具体没做过。
    PS 我们那个例子好像真的是物理删除,因为 DBA 说没办法恢复

  • 看起来是你用的 selenium 版本兼容性问题。 你先试试本地直接跑 selenium 是不是能跑起来? 就随便用 python 写个 selenium 的测试脚本,能调起浏览器和打开网页就基本上没问题了

  • 不是把表给删了,而是删了表里的数据。 所以不管物理删除还是逻辑删除都可能发生吧,区别是操作一条数据还是操作多条数据?
    对业务来说,就是数据不可用了

  • 原始逻辑是真的一言难尽,我大概知道的信息是当这个 ID 包含非法字符的时候,被处理成了 null,然后删除的逻辑里面原本是根据 ID 来锁定要删除的记录,结果因为这个 null 就变成了全表删除…

  • 逻辑删除也会造成业务影响,物理删除也能通过备份之类都手段恢复,所以这不是重点;重点是这个 API 的处理是有问题的

  • 很多 bug 都不能用常理去推测的。 所以作为测试,我们要考虑的是全面的质量保障。 比如这个字段的验证,其实在不同的阶段都可以有办法去预防: 开发正确的使用字段长度的检查(或者使用对应的插件)、单元测试、接口测试、页面自动化测试,等等。
    但是如果作为测试,我们都直接帮开发说: 这个没必要测接口,我是真的没办法认同。

  • 我分享个例子: 我们最近在对某个删除的 API 有改动,然后开发用 postman 去验证这个改动的时候不小心传了一个非法的 product ID, 结果正好后台没验证处理这种情况,结果把整个表的数据都给删了… 幸好这是在测试环境发生的,要是在生产环境发生,后果不堪设想。

    所以楼上说没必要的,祝你们不会遇到类似的问题😂

  • 我有一个朋友 at February 26, 2024

    一般这种合作公司,都会有限制的,不难随便在不同的外包公司之间换来换去,也不能辞职之后马上入职为正式员工。不然外包员工的稳定性根本没办法保障,怎么长期合作呢

  • 我有一个朋友 at February 26, 2024

    各位不妨换个角度看这个问题:假如你的房子在装修,你找了个包工头,包工头请了几个工人来你家干活。你老婆(家里的领导)和你说:

    1. 别想着看哪个工人手艺好就和他说要挖过来单独给你干,包工头知道了得和你闹
    2. 要是发现哪个工人干活不好,就赶紧和包工头说,让他换人

    这样看是不是感觉没那么难听了?

  • 先说明一下你的需求? 是你的 app 里面集成了谷歌广告,显示给客户看,还是说在谷歌广告⬆️推广你的 app?

  • 只有测试背锅? at January 30, 2024
    1. 开发是否有在 run book 里面说明要重启? 如果没有,是没有识别出来这个步骤。
    2. 如果 run book 里面明确写了这个步骤,是不是运维没严格执行?
    3. 开发 lead 和运维 lead 背责,整个上线流程有问题。
    4. 一定要挑测试的问题,或者从质量最后一关的责任人来看,是不是你们的测试流程有瑕疵,或者覆盖率不够,导致不能发现问题。 虽然主要责任不在测试上,还是有优化空间。
  • 你看看其他几个 template ,哪个页面要改就改哪个 template

  • 先了解一下具体是限制了哪些地区,说不定你用的 VPN 也不给访问呢

  • 在 app/templates/uitest/test_case.html 文件,29 行这个 option 里面改成你要的名字,或者增加 option 就可以了

  • 这是你们的回归测试策略, 一般是要做改动范围和影响分析, 有改动的,需要测哪些功能;没有改动的,做什么级别的回归测试;就算什么都没改,直接重新部署,也要做基本的冒烟测试。