需求分析阶段:阅读需求、理解需求,主要任务是对业务学习,分析需求点,参加需求评审会
测试计划阶段:主要任务是编写测试计划,参考项目整体计划包括测试时间、测试进度,以及对人力物力的安排,调整整体的测试策略
测试设计阶段:主要任务是参考概要、详细需求说明书编写测试用例以及用例评审
测试执行阶段:搭建测试环境进行冒烟测试,测试通过之后开始正式测试、bug跟踪和验证,以及回归测试
测试评估阶段:主要是编写测试报告,确认是否要上线
一般分两种情况:
1. 需求中没有明确规定需要实现,这种就需要找产品经理进行确认是否完善或者更改需求,商量好之后是否需要更改
2. 这是一个bug,但很少人这么去操作,首先提交bug,再和开发沟通并复现这个问题,然后在进行确认这个问题是否要修改,如果不需要修改,则需要在此bug中加上不修改的原因是什么
测试计划包含测试目标、测试范围还有测试环境的说明以及测试类型的说明,像功能、安全、性能稳定性等,另外还有测试模块的划分、测试的负责人、测试执行的时间安排、测试风险等,其中测试模块是根据测试人员对业务的熟练程度以及个人能力进行分配,测试时间则根据以往项目测试的测试经验,结合本项的需求情况进行评估
说起接口测试流程,就要对比UI测试流程来讲
UI功能测试流程是:
1. 需求分析和评审
2. 测试计划的编写
3. 测试用例的设计和评审
4. 用例的执行
5. bug的管理和回归
6.测试报告
接口测试流程的话也是类似的,其中多了接口文档的分析以及测试脚本构建;接口文档分析环节主要分析接口的请求还有响应,
请求中需要包含请求url、请求头、请求方法、请求参数;
响应需要包含响应状态码、响应的数据格式、响应信息头、响应内容和异常的返回信息以及错误码,再就是分析多个接口之间的依赖关系
测试脚本构建环节,该环节主要把接口用例脚本化,这种可以选择接口工具:postman、jmeter等
测试点和测试用例概念
测试点是测试人员在测试的时候需要关注的地方,测试用例包含前置条件、测试步骤、测试数据、测试描述和期望结果等N多个要素,关于本次测试任务的一个描述
测试用例是在测试点的基础上加工得到的,一个测试点可以延伸出多个测试用例去覆盖它,
常见的测试用例设计方法有等价类、边界值、流程图、错误推断法,
举例子发红包:自己发的红包自己能不能领取,这就是一个测试点;发送红包限制0-200元,0元能不能发,201元能不能发,包含特殊字符的能不能发,这些都是测试用例
最常见的hpps协议请求的方式是get和post他们之间有以下区别
1. get的请求参数释放到url里面的,post是放到请求体里面的
2. get的请求时可以被浏览器缓存的,post不能被浏览器缓存的
3. get请求参数是放到url里面的,url长度是受限的,最大为2048个字数,post就没有长度限制
4. get请求放到url里面安全性比较差,post的安全性相对比较好一些
5. get可以通过浏览器访问,post则不能通过浏览其访问,刷新之后数据需要重新发送
http传送的数据是未加密的,他是明文传输,因此使用http传输隐私信息是非常不安全的,为了保证这些隐私数据能够加密传输,于是就诞生的https,简单来说https是由SSL+http构建的,可以进行加密传输、身份认证的网络协议,他比http更加安全
http和https的区别呢;
1. http不需要证书,https是需要申请CA证书,市面上大部分证书都是需要收费
2. http是明文传输,https是加密传输,可以防止传输内容被篡取篡改,因此比http更加安全
3.http和https使用的是完全不同的连接方式,而且使用的端口也是不一样的,前者是80端口,后者是443端口
项目组应该快速响应并处理,记录bug产生过程,第一时间将缺陷修复,然后总结反思以及如何规避,以降低后面再次出现此类问题概率,常见的bug漏测原因:
1. 需求不明确,导致测试用例编写过于粗略
2. 需求变更,测试用例没有及时更新
3. 测试用例覆盖不全面,产生漏测
4. 没有按照测试用例执行
5.测试时间不充足,导致一些功能点在测试时被忽略
6. 测试环境或者数据受限导致缺陷漏测
7. 开发人员在修复其他bug时引入了新的bug
首先是产品,在迭代过程中产品的逻辑严谨,对于可能存在的兼容性问题、用户的升级做出预判,并尽早给出方案
其次是设计要满足产品表达的,同时要保证设计的延续性
第三开发是产品细节的实现,技术选择要严谨,要考虑到兼容性、性能、安全性等等,并且开发完成之后要充分自测
第四测试是质量保证的一关,主要验证产品逻辑和功能,站在用户角度,尽可能多的使用各种测试手段来保证测试质量
首先标题要简洁明了、步骤条理清晰、还要考虑缺陷的完备性比如说缺陷的等级、所属功能模块、所属case、版本、复现步骤、期望结果、实际结果、产生原因、报错或者日志的截图等
现在项目都是前后端分离的,后端和前端的测试进度都是不一样的,为了今早的介入测试,尽早的发现问题,在前端还没有开发完成的情况下,只要后端的接口开发完成了,我们就可以提前做接口测试了,这其实也是测试的左移,在结合自动化就可以极大的提高测试的工作效率,第二呢就是基于安全的考虑,只依赖前端测试,已经不能完全满足系统安全需求,毕竟绕过前端的验证太简单了,所以要做后端的验证,也就是说从接口层面进行验证
一个进程可以包含多个线程,一个线程只能有一个进程,、
不同进程间数据很难共享;一个进程下的线程很容易进行数据共享
进程要比线程消耗更多计算机资源、采用多个进程比单个线程更耗资源
1. DNS域名解析
2. 建立TCP连接
3. 发送http请求
4. 服务器处理请求
5. 服务器返回响应结果
6. 关闭tcp连接
7.浏览器解析HTML
8.浏览器布局渲染
内存溢出通俗点说内存不够,通常是运行大型软件的时候,比如说游戏或者是说游戏所需要申请的内存远远超过主机安装内存所承受大小
内存泄漏是指程序申请内存后,无法释放已申请的内存空间,一次的内存泄露可以忽略,但是内存泄漏堆积后果很严重,无论多少内存迟早会占光导致内存溢出
having和where和单独出现,但having使用字段必须在select子句中出现,大多数情况下having是用在group by之后的,它是对分组之后的结果做了进一步的筛选
where是在group by分组之前,根据条件在表中筛选数据,如果要同时使用的话先where》group》having
首先在现有已完成的系统里面点点点,其次多参加产品评审会,然后多找产品去沟通确认
黑河测试就是把系统当成一个黑盒子一样不需要了解系统内部的细节,只关注输入和输出,通过手动输入不同的数据来验证输出是否符合预期
白盒测试需要了解系统实现细节,通常是针对函数来进行测试的,需要并编写测试代码来调用对应的函数,通过不同参数来测试函数的返回值,是否符合预期
首先提交bug,描述当时操作环境、操作步骤、数据、并提供必要的日志,然后通过排除法、错误推断法、找规律,必要时可以找开发、项目经理一起进行定位分析,如果最后还没有解决,就需要讨论改bug是否保留
发现bug-》提交bug-》指派bug-》确认bug--》修复bug-》验证bug-》验证是否通过-》关闭bug
严重:需要立即解决的问题,比如死机、进程无响应、崩溃
高:软件的主要功能错误或者引起数据丢失的缺陷
中:影响软件功能和性能的一般缺陷
低:对软件质量影响非常轻微的缺陷,多为建议性或者ui层级的问题
客户端发送一个FIN包申请断开连接,并等待服务器确认
第二次挥手服务端回复一个ACK包,表示收到客户端关闭连接请求,但服务端不能马上关闭连接,需要检查是否有未处理完成的数据
第三次挥手服务端处理完所有数据之后,给客户端发送FIN包,表示可以断开连接
第四次挥手客户端回复ACK包表示断开连接
200:表示正常
307:重定向
401:未授权
403:服务器禁止访问
404:请求的资源没有找到
405:请求方法不允许
5开头的都是服务器内部的问题
长连接和短链接指的是客户端和服务端之间的通信机制
长连接指的是客户端和服务端建立好连接后,无论进行多少次通信,所有请求和响应数据都是在这个连接上进行的
短链接指的是客户端每一次和服务器进行通信时呢,都会重新创建一个连接,通信结束后关闭连接
之前在我们部门里面是没有开发自动化测试的,平常开发提测后,回归测试量很大,于是我自己搭建了一个自动化项目并实现回归测试的功能测试,这样每次回归的时候跑下测试用例就知道之前老功能有没有问题了,如果有问题的话我们就可以快速发现,并且反馈给开发,这样就能省掉很多时间
冒泡排序、选择排序、插入排序、快速排序、希尔排序、归并排序、堆排序、基数排序