其他分享
首页 > 其他分享> > 2022.7.14学习总结

2022.7.14学习总结

作者:互联网

一,测试理论

1、测试流程

img

市场调研、需求采集>>产品经理发出需求评审的会议邀请>>产品需求设计评审>>开发设计方案,编写代码,测试同步进行编写测试计划>>编写测试方案>>依据梳理的需求点吧编写测试用例>>测试用例评审>>转测后进行冒烟测试>>冒烟测试无问题后进行测试阶段>>提交BUG以及验证BUG>>测试通过后编写测试报告,同步进行验收测试>>准备上线前的准备工作>>上线后的回归测试验证

2、测试阶段

单元测试:单元测试框架主流的有:Java(Junit,TestNG),Python(unittest,Pytest)单元测试又可以说是白盒测试;测试内容:模块接⼝测试,程序内部逻辑,路径分⽀测试,局部数据结构测试,错误处理测试,边界测试。

集成测试:核心是API测试,也就是接口测试。接口测试主流的测试工具是PostMan,JMeter。集成维度具体为①,前端与后端的集成 ②,后端与后端的集成

系统测试:(End To End Test 端到端的测试)针对一个系统的业务流程的测试,也就是说从一个流程开始一直到一个流程的结束。针对系统中各个不同模块(集成测试里面的模块)集成到一起后的测试,目的是验证各个独立的模块集成到一起后,是否能够完整的调用通系统的各个链路。其实是功能测试

验收测试:(外包型:验收测试客户到场一块验收 自研型:测试完成后,发送邮件给产品经理,产品经理这边会进行验收测试,产品经理这边验收测试完成后,会回复邮件说明验收测试已经完成,下来测试团队编写测试报告,准备产品的上线。)

3、测试策略:

黑盒测试(黑盒测试把测试的对象看成是一个黑色的盒子的,看不到里面内部的结构,是对软件的一种功能性的测试)

白盒测试(就是把测试的对象看成是一个透明的盒子,能够看见被测软件的内部结构,是单元测试的一种形式,是针对程序的内部代码的一种测试形式。)

4、测试用例方法

功能测试(等价类、边界值、因果图、正交实验分解法、判定表驱动分析方法)

非功能测试方法(错误推测法、功能图测试方法)

场景法(场景设计方法)

二,面试题

你怎么保障你设计的测试用例的测试点是全的?

1、功能测试(等价类{针对被测对象的输入数据分为有效数据和无效数据;如:如电话号码,那么有效数据就是 符合运营商电话号码的规则,无效就是不符合,如连续的11个同样的数字以及非11的数字。}、边界值{针对等价类测试用例方法的补充;如:如电话号码,需要考虑到11位,以及12位,和0位,也就是边界的情况}、因果图{在判定表的基础上,根据被测对象列出的条件,来使用排列组合的方式来验证各个不同条件下(并且以及或者关系)程序的结果情况;如:例如招聘网站上的同时选取地区、学历、薪资等出现的结果的测试。}、正交实验分解法{在因果图的基础上,使用排列组合下来的测试用例个数是非常多,导致测试用例的个数是非常多的,那么使用正交实验分解法可以优化 测试用例的个数,选择有代表性的数据来进行测试。如:招聘网站的地区过多,选择有代表性的城市进行测试}、判定表驱动分析方法{出被测对象可能存在的不同条件;如:招聘类网站筛选出的结果排序,可能会存在多个条件来筛选出结果})

2、非功能测试(错误推测法{针对被测产品的非功能性的测试用例,主要使用探索性测试的方法,来验证被测产品可能存在问题;如:在波浪式的交互过程中,一直往下滑动,可能会出现浏览器的卡死}、功能图测试方法{针对程序非功能性的测试,主要考虑的是被测程序的内部结构代码的测试})

3、场景(场景设计方法{ 主要考虑的是一个产品的完整的业务流程,从输入流开始一直到输出流;如:淘宝,从一个商品上架一直到商品的出售})

4、性能测试

5、兼容性测试

三,测试术语

冒烟测试:转测后对程序的基本功能的测试

回归测试:相当于重复性之前的测试并验证

1、测试阶段,针对昨天提交的BUG进行回归测试(对象是BUG)

2、测试阶段,需要针对系统已有功能进行的测试(对象是之前的功能)

3、上线前开发把代码合并后,进行一次系统的测试(对象是之前功能加新的功能)

4、上线后,针对系统所有功能的测试(对象是之前新加的功能)

探索性测试:发挥主观能动性、创造性思维,目的是看是否能够发现之前没发现的BUG

四,BUG问题总结

BUG流程:发现BUG,提交BUG给开发,开发这边恢复后会进行回复,然后关闭提交单。

BUG注意事项:

1、BUG步骤一定要具备可操作性。(程序员根据步骤中的信息可以复现BUG)

2、提交的BUG一定有错误的截图信息以及日志信息。

不认可BUG怎么办?

首先我会再次检查问题是否存在(也存在你测试的时候问题存在,但是开发偷偷的解决了的情况),如果问题存在,那么提交的BUG步骤一定能要非常清晰,通俗易懂,同时要在提交的BUG里面附加上错误信息的日志上下文,以及尽可能的提供错误的截图信息。首先开发不承认不是和测试作对,也不是为难测试的,可能就是反馈的问题让对方看不清楚,或者看不懂,当然也存在某些开发很差劲,但是我建议不要这样去想开发,毕竟是一个团队的,信任,认可是很重要的。这样调整后,可以再找开发,比如打扰下,麻烦看看这个问题,是否是我的姿势不对等等,总之友好沟通,让对方来解决问题 如果真的发生是问题,并且提供的信息都是非常全的,但是开发不是不承认,各种不配合,这个时候需要思考下,对方为什么不承认,难道专门为难自己还是自己的沟通方式存在问题。比如你这代码差劲的,开发大概率就会很反感,也就不会配合了。所以这个时候也自己需要反思,然后改变沟通的策略和方式方法。

印象最深的BUG(内存泄漏OOM、支付回调{银行扣费后淘宝界面仍显示待支付})

五,关于加班

你对加班怎么看?

首先承认公司加班制度,但不做无用加班。

六,测试计划

测试计划的要素:⼀个叙述了预定的测试活动的范围、途径、资源及进度安排的⽂档。它确认了 测试项、被测特征、测试任务、⼈员 安排以及任何偶发事件的⻛险。

story:敏捷的术语,译为任务

如果一个工作,实际任务量是5天,但是我让你3天干完,此时你会?

1、拿到任务,先对任务进行拆分,然后每个任务根据自己的能力以及实际情况分配时间。

2、约上你的领导,给他详细的说明为什么不是3天,而是5天。分析后果后在进行商量。

3、需要注意的是到一个团队内,你的角色以及定位是什么?

七、测试报告

你写过没?内容是什么?

写过,内容:测试概述(版本、测试时间、测试参与人、备注)、功能测试结果(新功能测试结果、系统已有功能测试结果、系统核心流程测试结果)、缺陷分析(多少BUG、解决多少、解决率多少、未解决多少、缺陷状态分布图、缺陷严重级别分布图)、测试风险分析(缺陷风险分析{BUG描述、BUG链接、BUG解决方案、解决时间、负责人、备注}、风险量化{风险描述、影响范围、解决时间、负责人{产品经理}、备注})、测试结果(本次测试结果通过,可以上线!)

标签:总结,验收,14,被测,功能测试,测试用例,测试,2022.7,BUG
来源: https://www.cnblogs.com/L2119/p/16478059.html