APP测试流程和重点,怎么避免Bug漏测?

打印 上一主题 下一主题

主题 904|帖子 904|积分 2712

媒介


一、Python编程入门到精通
二、接口自动化项目实战
三、Web自动化项目实战
四、App自动化项目实战
五、一线大厂简历
六、测试开发DevOps体系
七、常用自动化测试工具
八、JMeter性能测试
九、总结(尾部小惊喜)


分析出现缺陷漏测情况
所接纳措施
对需求评审阶段,对业务需求细节理解不明确,未深入发掘隐含拓展需求

改进措施
需求评审前,我们应该先仔细阅读prd及交互文档,先形资本身对产品的思考,通过脑图的方式列出对产品设计的疑问点,从用户或者从行业角度找生产品设计
缺陷点
需求评审会议中,带着列出的疑问点向产品、开发沟通本身对产品的疑惑和质疑点,多提几个为什么?如何实现?数据获取泉源?超出预期的数据怎么处理?缓存处理机制如何?
数据保存何处?逻辑由前端处理还是后端服务?后端服务逻辑是否跟第三方关联?
需求评审完成后,按照肯定的功能,将需求拆分成若干大模块,大模块拆分成小功能点,然后思量功能点的具体实现流程
对测试用例覆盖不全面,场景出现遗漏
改进措施
用例设计完成后构造用例评审:
1)构造开发、产品进行测试用例评审,并抛出用例设计时的疑问,通过产品实现角度、数据存储、产品体验角度对用例进行评审美满。
2)如时间充裕,构造测试组内用例评审也是非常必须的,特别是一些履历老道或者业务熟悉的老司机们,可以在用例评审上快速的帮助指出用例的遗漏点,有助于测试职员打开思路,尽可能多的覆盖用户场景。
值得注意的是用例评审上碰到不确定的,应立即纪录下来,竣事后实时找相关职员确认,避免猜测。
根据线上用户反馈缺陷美满用例:
产品测试发布上线后,对于用户反馈的缺陷,如果缺陷是因为场景设计不全引起的,我们先分析出现问题的场景是必现还是偶现,如果是必现,我们可以通过和技能接口人沟通,确认该场景的一些具体复现步调,确认引入缘故原由,办理方案。
然后进行测试用例美满:除了补充该场景case外,思量一些和该场景相关联的场景,将多种场景下测试用例实时美满、评审,增加到用例库中去。
对测试阶段未严格按照测试用例实行:
改进措施

测试用例不肯定能包管所有的场景和功能点都能覆盖到,但是严格按照测试用例实行测试,能最大程度上包管产品质量,尽量避免出现缺陷。
另外养成测试纪录风俗:对于测试壅闭用例、测试fail用例,应该重点关注并纪录,在回归测试阶段进行精准回归测试,确保修复bug导致关联功能引入的新bug也能被发现。
对测试环境、测试资源受限,导致缺陷漏测
改进措施
引入灰度发布测试

测试组在预发布环境上进行回归测试,能根本模拟真实环境实行测试环境无法测试的用例,又不影响线上用户的正常利用。
对开发职员引入的新BUG
改进措施
代码review

从代码管理层面:开发修复一个bug提交代码自测通过准备提测时,开发团队提交代码进行代码review,引入新BUG的可能性较小。
精准回归测试
从测试自我修养层面:在开发提测后,通过diff代码的方式,了解代码改动点,精准分析改动点对相关联的功能点的影响,将开发职员修复的BUG确认验证,并将相关联的功能点尽可能在app测试阶段通过遍历回归测试到。
末了

既然看到这里,在收藏的同时,也请不吝啬的点个赞呗!期待 ~
绵薄之力【资源分享】
末了感谢每一个认真阅读我文章的人,看着粉丝一起的上涨和关注,礼尚往来总是要有的,虽然不是什么很值钱的东西,如果你用得到的话可以直接拿走:

文档获取方式:
这份文档和视频资料,对于想从事【软件测试】的朋友来说应该是最全面最完备的备战仓库,这个仓库也伴随我走过了最困难的路程,希望也能帮助到你!以上均可以分享,点下方进群自行领取即可,拿走不谢。  

 

免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!更多信息从访问主页:qidao123.com:ToB企服之家,中国第一个企服评测及商务社交产业平台。

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有账号?立即注册

x
回复

使用道具 举报

0 个回复

倒序浏览

快速回复

您需要登录后才可以回帖 登录 or 立即注册

本版积分规则

郭卫东

金牌会员
这个人很懒什么都没写!

标签云

快速回复 返回顶部 返回列表