测试基础 关于 H5 测试的问题求助

朋克 · 2021年10月15日 · 最后由 朋克 回复于 2021年10月18日 · 457 次阅读

现在遇到一些问题:
1、目前 H5 是镶嵌到 APP 上的(例如:H5 改动,之前测试通过了,但是后面因为其他问题,做了一下修改,回归问题时通过,但是之前 H5 的一些页面出现了其他问题,回归时注意了改动点,但是未覆盖到影响到的其他情况,而且回归时因为是镶嵌到 APP 的所以又出现了系统兼容的问题,目前能做的就是回归主流程,后面系统兼容也看,但是没有其他好办法,测试就两个人,上线任务较多,每次回归很浪费人力,也容易遗漏,UI 自动化成本又比较高,公司也不打算做,问问大家有没有好的办法)
2、每次发布时,发布一些功能回归了,但是发现 H5 总有遗漏的地方(例如:做了一些改动,但是影响到了另外一个页面,但是本次改动不应该涉及该页面,回归时没有覆盖到,目前做法是把那个页面记下来,下次回归的时候关注到,但是感觉有点死板,而且意义也不是很大,因为不是每次改动都会涉及那个页面)

目前一些改动点的影响开发也不是能评估到,所以有什么保证这个质量的方法么?

共收到 3 条回复 时间 点赞

是我的话可能会这样去做:

  1. 确保出现过的问题不会再次出现,记录 bug 清单,尽量做成自动化,工作量不算多的
  2. 主流程回归,同样尽量自动化吧
  3. 代码 review,每次测试花一点时间看开发的代码,不说每一段代码都能看懂、看出问题,至少要对整体的技术方案、影响到的页面、组件、接口等等有所了解,合理的技术方案一般代码看起来结构都是很清晰的,让人困惑的地方往往是 bug 所在的地方。

听楼主的说明,本质问题是 “改动点的影响开发也不是能评估到” ,即代码质量失控。本质问题不解决,你能做的只是把兜底做得更完善(比如用更多的回归用例兜底,最多加点自动化减少下人力成本),没办法真正减少工作量,而且也只会越做越累。

这类问题背后有可能是因为开发新接手不熟悉,也可能是本身架构设计不好太多共用,牵一发动全身。个人想到的几个解决方向,大方向还是测试要提高代码能力,倒逼和补充开发这个地方的短板:

1、联合开发做好 bad case 收集学习。正文里提到的这些曾经遗漏到线上的问题,都进行复盘,明确直接原因(代码改动点)和根本原因(为何会产生预期外影响但开发 + 测试都评估不到),以及制定落实优化措施(代码本身耦合度高的,提技术优化任务,进行重构优化;新人不清楚的,代码里补充好注释和写好项目代码介绍文档),持续提高这些容易出问题地方的代码质量。
2、经常出问题的部分项目,要求开干前做技术方案设计,测试参与到方案评审中。通过这个来倒逼开发做好设计方案,和评估好此方案的影响范围,思考好再开始写代码,降低风险。这个要去争取开发 leader 的支持,一般他参与评审,开发才会更认真进行设计,而且他把关质量才有保障。
3、提高自己的代码能力,去 review 开发代码,做到每一行改动都明确是在干嘛,和本次需求是否有直接关系,是否有连带影响其它位置。

陈恒捷 回复

感谢,我这边与开发聊一下

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册