ICode9

精准搜索请尝试: 精确搜索
首页 > 其他分享> 文章详细

测试理论复习

2022-01-21 22:05:03  阅读:167  来源: 互联网

标签:需求 复习 理论 反馈 评审 测试通过 测试 BUG


你是怎么理解测试的?

⾼级测试:在研发的⻆度上,测试团队的任务就是保障产品在符合市场的规范下交付给市场,给⽤户赋能,那么就 是更加具体的说,通过技术的⼿段和质量管理的策略和思想,来测试以及验证,和保障从需求点出发,到代码阶段 各个环节中,做出的东⻄是否满⾜市场的期望以及⽤户的期望。

初级测试:测试我们可以简单的把它理解成质量检测元,但是它⽐质量检测元的⼯作更加丰富,那么测试需要保障 的是从需求到代码的阶段中,测试需要验证被测产品的功能性和⾮功能性是否满⾜本次的需求。

测试的区别

过去的测试:编写测试⽤例,测试阶段验证被测产品的质量

现在的测试:需要参与端研发流程的各个环节,从需求开始⼀直到产品线上运营,那么具体的⼯作可以如下:

1、需求阶段需要协助产品,站在测试的⻆度和客户的⻆度,以及研发的⻆度,来审视本次需求设计是否合理?

A、如果合理,熟悉需求,梳理测试点

B、如果不合理,⼀定要在需求的评审阶段把不合理的地⽅,或者说⾃⼰的疑问的地⽅,反馈出来

2、现在的测试都得具备编程思维以及编程能⼒

3、需要参与到研发代码的评审以及技术⽅案的评审

4、都得具备API的测试技术能⼒

5、也得具备⾃动化测试技术的能⼒

需求评审的时候测试需要注意什么?

如果需求不合理,⼀定要在需求的评审阶段把不合理的地⽅,或者说⾃⼰的疑问的地⽅,反馈出来

编写测试⽤例的依据是什么?

产品设计需求⽂档(PRD),开发技术⽅案⽂档

测试⽤例评审谁参与?

必须包含:产品,开发,测试,其他相关的⼈

测试⽤例评审注意?

场景未考虑周全,别⼈会现场说出来,需要现场再笔记上记录

场景考虑到了,但是不对,那么也是需要现场纠正或者记录下来

后续根据别⼈的意⻅完善测试⽤例,完善后再次发出来

测试⽤例要素?

测试标题

前提条件

测试步骤描述

期望结果

测试步骤注意事项?

步骤⼀定要清晰

提交BUG注意事项?

BUG出现的步骤⼀定要⾮常清晰

最好是图⽂并茂,如果可能,最好有截图的信息

如果是后端的,最好有⽇志信息

针对涉及到数据的问题,那么最好测试的数据

BUG的称呼

缺陷,BUG,ISSUS

测试流程

产品梳理需求以及评审需求⽂档

需求评审后,开发开始编写实现产品的代码

测试这边开始编写测试计划,根据需求⽂档来梳理测试点,以及编写测试⽤例,完成后进⾏评审

开发完成后,转测给测试,测试这边先进⾏冒烟测试,冒烟测试通过后进⼊到测试阶段

测试阶段测试完成后进⾏验收测试

验收测试通过,开始准备上线,和上线后的验证

什么是冒烟测试?

就是本次产品转测正常流程的验证和测试

什么是回归测试?

针对系统已有功能的测试

⼯作评估

注意事项

1、如果能⼲6⼩时的,就说8⼩时

2、但是如果能⼲4⼩时的,就按4⼩时的来

3、尽量就是给⾃⼰多争取时间

4、时间⼀旦确定,到期没有完成,导致延误

⻛险管理

编写的⻛险必须是有事实的根据,不能凭空猜想

开发晚转测,你会怎么办?

假设预期转测时间是今天,结果开发反馈说明天转测,那么⼀定要在今天把这个⻛险反馈给相关的⼈

BUG流程

发现问题后,进⾏提交问题,然后把问题反馈给开发,开发这边会进⾏确认,如果是问题,开发修改后会再次反馈 测试,测试这边进⾏回归测试,测试通过BUG关闭,如果不通过,继续反馈给开发。

线上出问题怎么办?

先在测试环境验证是否存在该问题,如果存在,就说明该问题测试没有测试出来,需要版本回退

A、确认到底是代码问题还是环境问题,如果是存在,那么就是代码问题

B、如果不存在,那么就是环境配置的问题,这个时候开发需要检查这部分

复盘

A、如果是测试的问题,怎么解决?你的解决⽅案是什么?

1、如果是测试场景,那么需要在评审,以及分析的时候,需要加强

2、技术性问题,那么思考怎么使⽤技术问题来解决

B、如果是环境配置问题

1、每次上线梳理上线的checklist(上线步骤 检查配置)

如果提交⼀个BUG,开发不承认?

1、再次完善该问题的步骤信息

2、你可以出现,对⽅不出现,把对⽅叫到你这边,给对⽅演示问题出现的情况

3、给对⽅演示了,还是不承认进行多次测试用结果继续反馈

什么时候可以找leader?

1、⼼情郁闷了,不想⼲了,想离职了,找对⽅反馈离职的事

2、⻛险反馈

3、⼯作反馈

4、⼯作推动不了

什么是⿊盒测试?什么是⽩盒测试?

⿊盒测试:主要是功能测试的⼀种形式,我们把被测试的程序看成⼀个⿊⾊的盒⼦,看不⻅⾥⾯内部的结构

⽩盒测试:主要指的是基于代码的形式,⽐如单元测试,我们把被测试的程序看现成⼀个⽩⾊的盒⼦,可以看⻅⾥ ⾯内部的结构

测试阶段?

单元测试:函数或者⼀个⽅法级别的测试

集成测试

研发⻆度:

1、前后端联调

2、后端与后端联调

测试⻆度:

模块与模块之间的测试

所以说开发给测试的转测标准是什么?

1、前后端都完成

2、冒烟测试通过

系统测试

端到端的测试,就是针对系统业务流程的完整测试

验收测试

外包:验收测试的时候参与⼈是甲⽅的客户

⾃研: 1、测试测试完成后,发送邮件让产品进⾏验收测试

2、产品验收测试完成后,产品恢复邮件,确认验收测试通过

3、在产品验收测试通过的基础上,开始⾛上线流程

按照代码分类

功能测试

⾃动化测试

1、UI⾃动化测试

2、API⾃动化测试

3、性能测试

测试⽤例设计⽅法

等价类

1、有效的数据

2、⽆效的测试

边界值

是针对等价类的补充

因果图

输⼊的数据是多个条件的组合,来推导出⼀个结论

正交实验分解法

针对因果图的⼀种优化,因为按照因果图的理论,设计出来的测试⽤例的个数是⾮常多,但是了测试资源(时间和 ⼈)是有限的,那么就需要考虑优先级了,⽽正交实验分解法就可以解决这个问题,也就是说我们测试的时候只选 择有代表性的数据。

错误推测法

针对产品⾮功能的考虑和测试。因为在⼯作⾥⾯,我们针对产品的测试,必须考虑如下⼏点:

1、正常的功能

2、异常的测试

3、⾮功能性的

A、浏览器的兼容性

B、性能测试

C、安全测试

D、稳定性的保障

⾼可⽤的建设质量体系的保障

场景法

 

标签:需求,复习,理论,反馈,评审,测试通过,测试,BUG
来源: https://www.cnblogs.com/010709jjw/p/15831919.html

本站声明: 1. iCode9 技术分享网(下文简称本站)提供的所有内容,仅供技术学习、探讨和分享;
2. 关于本站的所有留言、评论、转载及引用,纯属内容发起人的个人观点,与本站观点和立场无关;
3. 关于本站的所有言论和文字,纯属内容发起人的个人观点,与本站观点和立场无关;
4. 本站文章均是网友提供,不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属;如您发现该文章侵犯了您的权益,可联系我们第一时间进行删除;
5. 本站为非盈利性的个人网站,所有内容不会用来进行牟利,也不会利用任何形式的广告来间接获益,纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

专注分享技术,共同学习,共同进步。侵权联系[81616952@qq.com]

Copyright (C)ICode9.com, All Rights Reserved.

ICode9版权所有