赞
踩
为了扩展家里领导的测试知识水平和专业知识能力提升,以及为以后更好的面试做基础,特意从众多测试相关题型整理出来,其中的答案仅供参考。
黑盒测试:已知产品的功能设计规格,可以进行测试证明每个实现了的功能是否符合要求。利用其检查功能是否符合需求说明书,能够正常使用,
白盒测试:已知产品的内部工作过程,可以进行测试证明每种内部操作是否符合设计规格要求,所有内部成分是否经过检查
利用其检查程序模块的内部逻辑走向,主要覆盖程序内的逻辑。
掌握边界值分析、等价类划分、错误推测等方法来设计测试用例
是一个完备的集合,它能够覆盖所有等价类以及各种边界值;需要从软件功能需求出发,全面地,无遗漏地识别出测试需求;最好是代码覆盖测试也全面的测试
测试用例全部跑完并且bug都已经关闭,然后业务验收后可以上线
需求分析讨论-确定测试策略-设计测试用例-测试用例评审-beta测试-uat测试-测试报告
1.没有实现需求说明书列出的功能
2.出现了需要说明书提到不应出现的事情
3.实现了需求说明书未提到的功能
4.没有实现说明书中没有提到但应该实现的功能
5.难于使用,运转速度很慢,用户认为没有达到预期
swagger 、 接口自动化脚本
接口表现与接口文档的一致性
请求参数:必选和非必选、长度、字符类型、为空、缺失、组合、重复
返回数据:正常和异常
1.做性能需求分析,挑选了用户使用最频繁的功能来做性能测试,比如:登陆,搜索,提交订单,确定性能指标,比如:事务通过率为100%,90%的事务响应时间不超过5秒,并发用户为1000人,CPU和内存的使用率为70%以下
2.性能测试计划,明确测试时间(通常在功能稳定后,如第一轮测试后进行)和测试环境和测试工具的选择
3.编写性能测试用例
4.搭建性能测试环境,准备好性能测试数据
5.通过性能测试用例,编写性能测试脚本
6.性能测试脚本进行调优,设置检查点、参数化、关联、集合点、事务,调整思考时间,删除冗余的脚本等
7.设计性能测试场景,使用nmon工具监控服务器,运行测试场景
8.分析性能测试结果,如果有问题(性能瓶颈),收集相关的日志提单给开发修改
9.开发修改好后,回归性能测试
10.编写性能测试报告
相关指标:响应时间、并发数、吞吐率、资源利用率、TPS
负载测试是模拟实际软件系统所承受的负载条件的系统负荷,通过不断加载(如逐渐增加模拟用户的数量)或其它加载方式来观察不同负载下系统的响应时间和数据吞吐量、系统占用的资源(如CPU、内存)等,以检验系统的行为和特性,以发现系统可能存在的性能瓶颈、内存泄漏、不能实时同步等问题
压力测试是在高负载情况下对系统的稳定性进行测试。是在高负载(大数据量、大量并发用户等)下的测试,观察系统在峰值使用情况下的表现,从而发现系统的功能隐患
负载测试:多用户,用户数渐增,持续同时发同一业务请求,产出最大TPS
压力测试:多用户,资源使用饱和,持续同时发同一业务请求,产出系统瓶颈或使用极限
基础监控和应用监控。
基础监控包括机器是否死机,cpu,内存,磁盘使用率等;应用监控包括日志监控、端口监控、进程数监控等。
好处:防止系统B出错引起测试错误;不会因系统B的开发进度影响测试;mock后可以快速返回结果,提高测试效率
坏处:很多情况下无法完全模拟出服务器的所有可能的返回情况,另外,mock掉了关联方之后,整个环境的连通性可能测试的不到位。
服务器内存不够、服务器超出负载、并发量太大、遇到恶意攻击
自动化适合做为回归测试的主要方式,新上线的功能一般都是用手动测试方式,一些极端和用户习惯操作还是手动测试比较方便。尽可能线上稳定的功能模块都做成自动化,提供效率
自动化主要作为回归测试,减少测试时间。UI自动化么有弄,基本找不到bug 。
主要跑的是业务流,所以跑一次需要半个小时左右
金字塔结构, 最底层UnitTest,往上接口API/集成起来的service, 最上面UI自动化
提前准备好,在代码里的yaml文件
业务不变的情况下,一般脚本都是不坏不动的
面向对象编程 就是把具有共性的事务抽象成属性和方法来进行编程
start()方法可以用来启动线程,调用该方法,会创建一个新的线程,然后内部执行run()方法;不能多次调用,否则会抛异常
直接调用run()方法,不会创建新的线程;可以进行多次调用
比如有两张表 A,B。左连接是把符合条件的所有A表的内容列出来,B表如果没有内容匹配用NULL代替。
右连接是符合条件的所有B表的内容列出来,A表如果没有内容匹配用NULL代替
索引是由表或者视图中的一列或多列生成的键,可以加快在表或者视图中检索行的速度
没有实现需求说明书列出的功能,出现了没有需求说明书提到不该出现的事情;实现了多的功能;没有实现应该实现的逻辑。
重新执行测试用例,并且针对这个缺陷影响的相关点写新的测试用例。
因为其具有挑战性和成就感,找一些系统隐藏的逻辑漏洞的时候,自己就非常的开心。并且测试需要细心和耐心,自己可以很快的分析bug的来源。
缺陷描述,缺陷的优先级,缺陷的标题,缺陷所属版本号,缺陷所属的功能模块,操作步骤,预期效果,缺陷原因,缺陷所属的开发人员.
测试用例,测试报告,测试日报
没有开发就没有测试,开发之后才开始测试,
1.跳转其他的测试流程
2.调用某个程序能绕过这个错误,继续后面的流程
兼容性测试是检查软件在不同软件平台,硬件平台上是否可以正常运行的测试。
主要查看软件在不同操作系统、浏览器、数据库中是否运行正常
参加人员:需求业务人员、产品经理、项目经理、开发人员、测试人员
目的:查看软件在未正式投入运行前是否还存在问题。对于不同软硬件平台能否正常运行,是否有与客户理解不一致的地方,同时可以对一些可以改进的地方再多加改进。
首先把自己的理由,并以需求说明书为自己的站点,如果开发人员还是不认同,可以把自己的观点和理由,提交给产品经理,由其去决定是否为一个bug
需求确认开始,因为在需求阶段,测试可以评审需求并进行静态测试,减少开发过程中的bug
做过web测试,小程序测试,H5页面测试,后台测试,接口测试。最擅长接口测试,自己给公司的业务流程写过一套自动化框架,用于回归业务流程
要求开发人员进行自测,把这些问题在开发阶段就解决好
通过缺陷管理系统对开发人员进行控制
能修复,但不一定所有的缺陷都要修复
1,非专业测试人员,没有组织性的测试工作,没有规律和针对性,会影响到测试的质量和版本更新的速度。
2,专业测试人员(但不是这个项目的测试员)这些人员不受测试计划的时候和任务约定,测试完毕后评估测试小组的工作质量,不利于bug管理。
前提条件、测试环境、操作步骤、预期结果、实际结果、严重等级、版本信息,出现概率
问题描述和操作步骤要尽可能描述详细,可以初步分析bug是客户端的问题还是服务端的问题
黑盒:
边界值分析法:如参数的范围0-128,输入128,129,0这些值,查看是否有错误等
错误推测法:导入功能时,表格为空表格,表格输入1行,表格输入10000行等
因果图方法:组合参数逻辑图
场景分析法:根据用户操作模拟用户操作
白盒:
逻辑覆盖法,基本路径测试
不一定,要看情况,如果测试用例质量高,没有发现bug,说明开发质量高。但一般程序都会有bug,如果没有发现BUG,就要思索测试场景是否有遗漏,需求是否理解没到位
产品经理,开发人员,测试人员,业务需求人员
静态测试:不运行程序,针对PRD等检查代码,审查代码,静态结构分析,分析代码质量
动态测试:运行程序进行黑盒测试和白盒测试
内存泄漏(Memory Leak)是指程序中己动态分配的堆内存由于某种原因程序未释放或无法释放,造成系统内存的浪费,导致程序运行速度减慢甚至系统崩溃等严重后果
HTTP错误率(HTTP error rate) 在选定时间段内,HTTP错误数量与请求数量的比率。
吞吐率(Throughput) 是场景运行过程中服务器每秒的吞吐量。其度量单位是字节,表示每个请求连接在任何给定的每一秒从服务器获得的数据量。
web端
当用户在2秒以内得到响应时,会感觉系统的响应很快;
当用户在2-5秒之间得到响应时,会感觉系统的响应速度还可以;
而当用户在超过8秒后仍然无法得到响应时,会感觉系统糟透了,或者认为系统已经失去响应,
场景:请求超时、页面加载失败
接口测试是测试系统组件间接口的一种测试。接口测试就是测试不同系统或模块之间资源交互是否正确
因为在大部分系统和产品中,资源数据都是核心,所以接口是需要要测试的,并且接口中大部分内容都是数据,通过数据的对比可以推测系统和产品的逻辑,测试接口就是测试逻辑。所以很必要做接口测试
1.出现bug,通过接口测试,清晰找到bug的源头,是前端还是后端的bug
2.回归测试,利用接口测试原有的接口是否正常,保证之前的业务流程没有受影响
3.接口开发完成后,可以做接口测试
soapUI、postman、jemeter、insomnia、paw
1.接口的通过性验证:数据正确输入,是否正确返回结果。测试接口的正常场景和异常场景
2.边界测试:不按照你接口文档上的要求输入参数,测试其边界情况。比如说必填的参数不填,输入整数类型的正常,超过参数取值范围等
3.参数组合:如果接口中有参数需要组合用的,两个参数是组合使用,测试其各种情况
4.异常验证:测试幂等情况,并发情况,事务测试等异常情况
5.接口安全:绕过验证,敏感信息加密等情况
6.性能测试:响应时间、并发数、吞吐量、服务器资源利用率
加分项:单元测试、功能测试、集成测试分别在web端、接口端、移动端的定义,你平时是怎么理解它们的?
单元测试:是针对程序模块来进行正确性检验的测试工作
功能测试:在单元测试的基础上,测试某一个功能点
集成测试:将所有模块按照设计要求组装成为子系统或系统,进行集成测试
web端
单元测试/功能测试:页面元素是否正确显示其有效功能,如提交的action是否正确,搜索点击是否执行
集成测试:调用了后端接口的数据是否显示正常,能否满足需求
接口端:模块/系统之前的调用,接口是否与设计相符,模块组合后是否满足需求
单元测试:某个函数/方法 写的代码是否达到编写者的预期
功能测试:为实现一个功能点,调用几个方法/函数
说明:
返回的下标值(index1 和 index2)不是从零开始的。
你可以假设每个输入只对应唯一的答案,而且你不可以重复使用相同的元素。
示例:
输入: numbers = [2, 7, 11, 15], target = 9
输出: [1,2]
解释: 2 与 7 之和等于目标数 9 。因此 index1 = 1, index2 = 2 。
## python class Solution(object): def twoSum(self, numbers, target): l=0 r=len(numbers)-1 while(l<r): if(numbers[l]+numbers[r]== target): return [l+1,r+1] if(numbers[l]+numbers[r] <target): l += 1 else: r -= 1 ## 测试用例: def test_towSum1(self): assert towSum([0,1, 1, 2, 3, 6,8], 2) == [1, 4] def test_towSum2(self): assert towSum([1,2,5,6,12], 13) == [1, 5] def test_towSum3(self): assert towSum([2, 7, 11, 15], 9) == [1, 2]
## Java
public int[] twoSum(int[] numbers, int target) {
int left =
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。