0
点赞
收藏
分享

微信扫一扫

day12:栈的最小值

1.背景

随着业务的快速迭代,开发自测需求与QA测试的需求比例相当,对于开发自测的需求,需求质量我们无法把控,并且随着自测需求的增多,QA对业务的熟悉程度也会出现断层;

部分业务整体已趋于稳定,迭代较少,但线上偶尔会出现一些历史遗留问题,导致运营同学在使用相关功能时需要找开发同学临时高优处理一下;

随着业务单量的不断增加,我们也越来越重视NPS,体验类的问题会严重影响用户的使用体验和拉低NPS,而良好的交互体验更有利于提升NPS和留存用户;

基于以上的问题,我们会定期组织开发同学一起进行业务巡检,希望通过业务巡检来解决这些问题,提高系统的可用性,减少线上问题;通过巡检可以让大家从用户的角度来了解业务,体验业务,从而提升用户体验;最后,也希望通过巡检来提高大家的质量意识,大家共同为质量负责!

2.巡检方式

在组织巡检之前,我们一直在思考两个问题,那就是如何让大家更加积极地参与巡检以及如何能提升巡检的效率?俗话说得好,适合自己的才是最好的,最终我们决定基于不同的业务特征,来组织不同形式的巡检。所以在介绍巡检方式之前先简单地介绍一下我负责的两个业务,以下分别以A业务和B业务代称。

2.1.A业务

1)业务流程
图片

2)业务特点

业务流程相对简短单一,前端交互类功能较多。

3)业务现状

整体业务已趋于稳定,主要以运营为主,项目迭代相对较少,整体功能改动较小。

2.2.B业务

1)业务流程

图片

3)业务特点

流程复杂多样,每条分支都是单独的业务逻辑

4)业务现状

业务处于快速发展阶段,迭代周期短,功能改动频繁。

综上,根据二者业务特点,考虑到A业务流程相对简单,并且case有时会限制住大家的思维,所以最终确定采取自由巡检的方式,这样能更好地模拟用户的使用习惯,去发现问题。B业务流程比较复杂,如果自由巡检,可能无法覆盖全部流程,所以最终采取提供case的方式,通过case来引导大家尽可能覆盖更多的场景,能更好的从业务角度去发现问题。

3.关注点

本次巡检主要从功能、页面、交互等方面为关注点进行的

  • 功能:各功能的完整性
  • 页面:展示完整,无遮挡
  • 交互:页面、功能之间的交互,站在用户角度,是否可接受,是否有可优化的空间

4.巡检计划

4.1.明确巡检范围

首先需要保证主流程的准确性,再按照业务模块进行划分,梳理巡检范围,然后再根据模块,细化需要关注的功能模块的各实现效果。

以下是划分的业务模块,巡检需要覆盖的范围:

图片

模块划分后,则进行具体的模块整理,针对不同的巡检方式,分别进行了不同的整理。

4.2.提前进行业务梳理

A业务:

A业务虽然采取自由巡检的方式,但是大家对各个模块并不是完全熟悉,所以提前梳理业务流程,巡检前进行分享,以便在巡检前能先熟悉业务,更深入地走查业务流程。

B业务:

提前整理B业务的巡检case,在巡检前分别给大家创建不同的巡检case的测试计划,在巡检过程中提供参考,并逐条验证。

4.3.巡检频率

每周安排一次集中巡检,时长1~2小时,QA、RD、FE共同参与。

4.4.QA的职责

每次巡检会安排2个值班QA,主要负责解答case和记录巡检问题,巡检结束后针对提交的问题进行跟踪解决及验证。

5.问题记录

问题记录:以bug形式记录,提给对应开发同学。

问题跟进:关注问题的解决进展,验证回归。

问题总结:定期汇总问题类型,分析原因,总结经验,方便后续类似功能实现时,清楚需要重点关注的点有哪些,避免同样的坑重复踩多次。

通过对问题的汇总,问题主要集中在编码错误、用户体验、产品设计、系统兼容上,而用户体验的问题主要集中在小程序上。因此,后续在评审阶段,会更加关注产品设计的合理性,在避免日常工作中,会加强对小程序端的验证,以此减少体验类问题的产生。

6.收获

巡检中,最大的收获就是角色的转换,首先作为一名QA同学,需要保证各功能的准确性,完整性。其次,我们也是用户,需要站在用户的角度去考虑产品的合理性。对于业务巡检这件事后续我们也会坚持去做,不轻易放过任何一个线上问题,把好产品的最后一道质量关。

最后: 为了回馈铁杆粉丝们,我给大家整理了完整的软件测试视频学习教程,朋友们 如果需要可以自行免费领取 【保证100%免费】
在这里插 入图片描述

软件测试面试文档

我们学习必然是为了找到高薪的工作,下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料,并且有字节大佬给出了权威的解答,刷完这一套面试资料相信大家都能找到满意的工作。

在这里插入图片描述
在这里插入图片描述

举报

相关推荐

0 条评论