-
【文章末尾给大家留下了大量的福利】
- 软件的概念是什么?
- 定义:计算机系统中与硬件相互依存的一部分,它是包括程序,数据及其相关文档的 完整集合
- 程序:按事先设计的功能和性能要求执行的指令序列
- 数据:使程序能正常操纵信息的数据结构
- 文档:与程序开发维护和使用有关的图文资料
- 错误观点: "软件就是程序,软件开发就是编程序
- 软件测试的对象是什么?
软件需求,软件概要设计,软件源代码,软件详细设计,可运行程序,软件运行环境(提交 BUG 应注明当前环境)。
- APP 是什么架构?
通常是 C/S 架构,比如优酷客户端是 C/S,网页版 B/S。
- 什么是软件测试?软件测试目的?
软件测试定义:使用人工和自动手段来运行或测试某个系统的过程,其目的在于检验它是否 满足规定的需求或弄清预期结果和实际结果之间的差别。
软件测试目的:
-
- 为了发现程序(软件)存在的代码或业务逻辑错误。
- 为了检验产品是否符合用户需求。(功能、需求一致性)
- 为了提高用户的体验。 用户使用感受(界面+习惯性操作)+性能测试
- 你对软件测试的定义是怎么的?
- 定义:软件质量保证的一种手段
- 概念:是软件工程中的一个非常重要的环节,是开发项目整体的一部分。是有计划有 组织的,是伴随软件工程的诞生而诞生的,软件测试不是万能的,不可能发现全部缺 陷,软件测试是有局限性的。
-
- 目的:验证被测对象是否实现用户需求
- 弄清:实际结果与预期结果之间的差异
- 软件测试分类?
- 按测试技术/方法划分
① 黑盒测试:无法看到内部代码逻辑,只能关注外部功能,比如给一个输入数据, 看输出数据是否跟预期的结果相符,如果正确,则称该功能正确。(数据驱动和测试)
② 白盒测试:基于软件内部设计和程序实现的测试方法。不只是关注输入输出, 还关注程序处理问题(代码层面)
③ 灰盒测试:(介于白黑)
-
- 按被测对象是否运行划分
① 动态测试:运行中的软件测试
② 静态测试:(文档检查、代码走查)
-
- 按不同测试手段划分
① 手工测试:点点点
② 自动化测试:代替手工繁琐操作
-
- 按测试包含内容划分
① 功能测试:功能是否符合需求(黑盒)
② 界面测试(UI):布局是否合理,整体风格是否一致,文字是否正确,命名是否统一,是否美观,文字图片是否完美等。
③ 安全测试:测试系统防止非法入侵的能力。(前期工作主要是验证登录)
④ 兼容性测试:系统与其他软硬件兼容能力。
⑤ 易用性测试:主观性比较强,一般基于用户反馈。
⑥ 性能测试:指通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试
-
- 按测试执行阶段划分
① 单元测试:颗粒度最小,一般由开发小组采用白盒方式来测试,主要测试单元是否符合“设计”;是指对软件中的最小可测试单元进行检查和验证。
② 集成测试:也叫组装测试或联合测试。在单元测试的基础上将所有模块按照要求设计组装成为子系统或系统,进行集成测试。
③ 系统测试:对整个系统的测试,将硬件、软件、操作人员看作一个整体,检验它是否有不复合系统说明书的地方。系统测试可以发现系统分析和设计中的错误。
④ 验收测试:是部署软件之前的最后一个测试操作。在上述步骤完成之后,产品发布之前所进行的测试活动。验收测试是技术测试的最后一个阶段,也称交付测试。目的是确保软件准备就绪,并且可以让最终用户将其用于执行软件的既定功能和任务。
-
-
- 正式验收:
- Alpha 测试:前期用户测试,内部员工或部分用户模拟环境下测试(内侧)
- Beta 测试:后期用户测试,即将上线前,真实环境下测试(公测)
- 其他
-
① 冒烟测试:对象是新编译需要正式测试的软件版本,其目的是确认软件基本功能是否正常,之后才可以进行后续的正式测试。
② 回归测试:BUG 修正重新测试,关联其他模块测试。
③ 探索性测试/自由测试(测试思维,啥都没测试)
- 软件生命周期包括哪些阶段?你们开发的模型是什么?
问题定义、可行性研究、需求分析、概要设计、详细设计、编码和单元测试、综合测试、 软件维护。敏捷开发模型(以人为核心、迭代、循序渐进)
- 测试流程包含哪些阶段?各个阶段的输出/产出物/交付物是什么?
- 测试需求分析阶段:此阶段我们要学习业务理解需求,产品经理会召开需求评审会 议,讲解分析需求点。(文档输出)
- 测试计划阶段:这个阶段主要任务是编写测试计划,一般是我们老大负责编写,不 过我们也会参与相关的评审会议。(测试计划)
- 测试设计阶段:这个阶段主要任务是编写测试用例,之后我们会参与评审测试用例。
(测试用例)
-
- 测试执行阶段:一开始我们会在之前搭建好的环境进行冒烟测试,如果通过了,我 们会进行正式测试,发现 BUG,把 BUG 提交到禅道,进行跟踪,循环跟踪,一直到没有大 BUG,这样这个阶段的测试就告一段落了。(bug 输出)
- 测试评估阶段:出具测试报告,确认能不能上线。(测试报告)
- 你们公司的开发流程是怎样的?
- 确定软件开发的目的和是否可行,并制定总体的开发计划;
- 产品会对各个功能进行详细的分析并明确客户的需求,输出需求规格书,接着是召 开评审会议;
- 之后开发老大会把需求分析得出的结果转化为数据结构、软件结构,形成系统结构;
- 接着开发会进行概要设计,主要是架构的实现,比如说,搭建架构,表述各个模块的功能,模块接口的连接和数据传递的实现等这些事务;
- 紧接着是详细的设计,就是对概要设计进行深入的分析,其中包括数据库的设计说 明;
- 执行编码活动,开发会根据设计好的功能表编写可行性的代码;
- 之后开发提测,到我们测试组进行测试,比如接口测试,系统测试,验收测试;
- 最后是系统运维,主要是纠错性维护和改进性维护。
- 开发环境,测试环境,生产环境是什么?你在测试环境后台添加的数据和信 息,能够在生产环境看到么?
- 开发环境是程序员专门使用的服务器,配置比较随意,为了方便调试,会打开全部 错误报告。
- 测试环境是克隆生产环境的配置。
- 生产环境:是指正式提供对外服务的,一般会关掉错误报告,打开错误日志。(真实环境)
- 测试阶段里面所添加的数据和信息,不会出现在真实环境中,上线前是需要数据清 洗的。
- 遇到隐性需求怎么办?
充分熟悉软件产品业务+参考同类型已上市成熟的软件,与产品经理确认。
- 编写测试用例会用到哪些方法?你会在写用例用到吗?(结合项目)
等价类、边界值、错误推断法、场景法。我个人常用的方法就是这些。
-
- 比如充值这块,正常数据输入,非 100 的整数倍等情况,这是等价类,空的输入、0 的输入,这是边界值,超出余额的输入,这是错误推断法,还有登录投标成功, 这是场景法。
- 用例需要评审吗?紧急情况用例也要评审吗?
需要评审;公司业务用户群体达到一定基础数必须要有评审。可以进行内部召开。
- 如果被测项目很紧急,来不及写用例,怎么办?
我们会根据需求用 xmind 编写测试点,之后进行测试,测试完了,时间充足会进行用例的补充完善。
- 遇到隐性需求如何写测试用例?(需求不明确)
充分熟悉软件产品业务+参考同类型已上市成熟的软件,与产品经理确认。
-
- 隐性需求,就是真实的原始需求。
- 隐性需求,就是把习惯性思维明确化。
- 隐性需求,就是避免经验主义。
- 用例有没有优先级?如果一定要有优先级,依据是什么?
在实际测试实践中,测试用例根据重要性分成一定的等级
-
- P0:核心功能测试用例(冒烟测试),确定此版本是否可测的测试用例,此部分测试用例如果 fail 会阻碍大部分其他测试用例的验证
- P1:高优先级测试用例,最常执行保证功能性是稳定的;基本功能测试和重要的错误,边界测试
- 中优先级测试用例,更全面验证功能的各个方面,异常测试、中断、断网、容错、
UI 等测试用例
-
- 低优先级测试用例,不常被执行,性能、压力、兼容性、稳定性、安全、可用性等。
- 如何写测试用例?(以项目为基础来讲一个小模块用例设计)
比如支付、充值等;我们项目按照测试用例的顺序,先去冒烟跑一遍核心功能,然后接下来就是针对每个测试点,考虑一些异常情况,比如充值这块,非 100 的整数倍等情况, 空的输入、0 的输入、超出余额的输入,还有界面是否美观,文字是否一致,用户使用起来是否舒适。
- 有没有你印象深刻的 bug?Bug 的原因/bug 当时怎么解决?
数据库的问题:在做接口测试的时候,加标,借款的竞标天数:输入的是 3 天,数据
库里默认都是 5 天,投资和充值了,交易的流水在数据库里有异常。===我当时觉得印象深刻,主要是做功能测试,主要关注界面,做接口测试的时候呢,比较多的去关注数据库了。 所以发现数据库的很多层面的问题,虽然不是很严重的问题,但是呢我发现数据库测试这部分很重要。==对我来讲,数据库里某一个字段有问题,反映到页面,页面的展示和数据显示等,都会异常,就会影响很大一块的问题。
- Bug 的生命周期?
新建(提 bug)-->指派-->已解决(bug 已修复、不予解决、延期、不是缺陷、重复 bug)
-->待验-->关闭
- 当你开了一个 bug,但是开发不认为是 bug,如何处理?
首先确认开发环境是否跟自己测试环境一致(有时候开发是在他们已更新代码的环境上验证 bug 的,所以 bug 就没出现,但在测试环境上面会出现;还要确认缓存有无清除), 确认在测试环境能重现,如果确认是缺陷跟开发保持有效的沟通,如果是级别较低的建议性bug,可以先记录到 bug 平台,先保留沟通;如果是 bug 级别较高的问题,对应需求文档的预期结果跟开发说明,更有说服力;耐心讲解 bug 的危害,不行就找产品确认,确认是 bug 注明情况并再次指派给开发。
- 你在发现 bug 并确认 bug 的过程中,对于重现率不高的 bug 怎么处理?
评估这些 BUG 对系统的影响,根据严重等级进行处理,对于比较严重的问题,查看服务器日志协助开发查找原因。
- 小众浏览器出现问题,需不需要做兼容性测试?用户反馈在小众浏览器上的 问题?一般情况下,公司怎么处理?
我们公司没做浏览器兼容性测试;建议客户更换兼容性较好的浏览器。
- 如果一个网站分为前台访问系统、后台管理系统;是否都需要做浏览器兼容性测试?
前台可能需要,后台一般不需要,看公司项目安排。
- 软件项目成员有哪些?
- 项目经理: 驱动整个项目的运转,负责制定计划,安排人力,管理进度,协调团队,进行重大决策。
- 产品经理(需求开发人员): 和客户沟通需求,并制定产品需求
- 架构师 / 系统工程师: 技术专家,经验丰富,负责整个系统的体系架构的设计以及关键模块的设计。
- 程序员 / 开发人员: 设计、编写软件,并修复软件中的缺陷。
- 测试工程师: 负责找出软件产品存在的问题并报告。
- 资料工程师: 负责编写软件产品附带的文件和联机帮助文档
- 配置管理员: 负责管理程序员写的代码和资料工程师写的文档资料,并组合成一个软件包
- QA: 质量监管人员
- 你对软件 Bug 的概念是怎样的?
- 你怎么定义是不是 Bug?
① 软件没有实现产品的说明书所描述的功能。
② 软件实现了产品说明书描述不应有的功能。
③ 软件执行了产品说明书没讲的操作。
④ 软件没有实现产品说明书没描述但应该实现的功能(用户体验相关)。
⑤ 从软件测试员的角度来看,软件难以理解、不易使用、运行缓慢,或者最终用户
认为不对。
-
- bug 的类型都有哪些?
① Bug ,由代码编写错误导致的功能问题
② Defect 缺陷,实现与需求不一致
③ Fault 即故障,由于环境系统问题引起运行失败
④ Error 即错误,语法错误,逻辑错误,不易发现
- 软件 Bug 级别有几种?
- 微小的==》一些小问题
如:错字,文字排版不整齐等,对功能几乎没有影响,软件产品仍可使用。
-
- 一般的==》不太严重的错误
如:次要功能模块部分丧失、提示信息不够准确、用户界面差和操作运行时间长等。
-
- 严重的==》严重错误
指功能模块和特性没有实现,主要功能部分丧失,次要功能全部丧失。
-
- 致命的==》严重的致命的错误
造成系统崩溃,四级,或造成数据丢失、主要功能完全丧失等。 如:死机、宕机、黑白屏无法使用、完全卡死
- 软件 Bug 状态有哪些?
- 激活状态==》问题没解决
测试人员新报告的缺陷或者验证后缺陷仍存在。
-
- 已修正状态==》开发人员针对缺陷
修正软件后已解决问题或已通过单元测试 。
-
- 关闭状态==》测试人员经过验证后,确认缺陷不存在之后的状态 。
- 遗留状态==》此次版本升级不修改,遗留到下一版本修改。
- 非错状态==》就是此问题不是一个 Bug,开发可以直接置为关闭
- 你对软件质量是怎样定义的?
- 软件质量就是“软件与明确的和隐含的定义的需求相一致的程度”;
- 明确的需求指:软件符合明确叙述的功能和性能需求、文档中明确描述的开发标准;
- 隐含的需求指:所有专业开发的软件都应具有的隐含特征的程度,比如:符合行业 标准。
- 内部质量:软件内部的设计和静态测试是否合格
- 过程质量:关注软件的整个生产流程是否规范是否合理
- 外部质量:关注软件产品本身的功能和性能表现
- 使用质量:关注软件在使用过程中易用性满意度的表现
- 软件质量的特性有哪些? 软件质量是软件测试的依据软件质量的六大特性是什么?
- 功能性、可靠性、效率、易用性、可维护、可移植
- (一般知道六大特性是啥就够了,但是预防会追问,还是浏览一遍下面的定义)
① 功能性
-
-
- 定义:软件在指定的使用环境下,满足用户显性或隐性需求的能力 适合性:软件为指定的任务和用户目标提供一组合适功能的能力
-
准确性:软件提供具有所需精确度的正确或相符的結果或效果的能力 互操作性:软件与一个或更多个的规定系统进行交互的能力
② 可靠性
1) 定义:软件在指定的条件下使用,维持规定的性能级别的能力 成熟性:软件为避免由软件中错误而导致失控的能力,
容错性:在软件出现故障或违反指定接口的情况下,软件维持规定性能级别 的能力,
易恢复性:在失效发生的情况下软件里重建规定的件能级别并恢复受直接影响的数据的能力
可靠性依从性:软件遵循与可靠件相关的标准,约定以及法律法规的能力
③ 效率
1) 定义:在规定的条件下,相对于所用资源的数量,软件提供适当性能的能力时间特性:在规定的条件下软件执行其功能时,提供适当的响应和处理时间 以及吞吐率的能力
资源利用性:在规定的条件下软件执行其能力时,使用合适的资源数量和类 别的能力
效率依从件:软件遵循与效率相关的标准和约定的能力
④ 易用性
1) 定义:在指定的条件下使用时,软件被学习,理解,使用和吸引用户的能力
易理解性:软件的使用,用户能理解软件是否合适,以及如何将软件用于特
定的任务和使用环境的能力
易学习:软件使用户能学习其应用的能力易操作性:软件使用用户操作和控 制它的能力
吸引性:软件吸引用户的能力
易用性依从性:遭循与易用性相关的标准、约定风格指南或法规的能力
⑤ 可维护
1) 定义:软件可被修改的能力,修改可能包括修正、改进或软件对环境、需求 和功能规格说明变化的适应性
易分析性:软件诊断软件的缺陷,失效原因或识别待修改部分的能力, 易改变性:软件指定的修改可以被实现的能力
稳定性:软件避免由于软件修改而造成意外结果的能力, 易测试性:软件使已修改软件能被确认的能力
可维护依从性:遵循与维护相关标准和约定的能力,
⑥ 可移植
1) 定义:软件从一种环境迁移到另一种环境的能力适用性:软件能适用于不同的环境的能力
易安装性:软件在指定环境中被安装的能力
共存性:软件在公共环境中同与其分享公共资源的其他独立软件共存的能力
易替换性:软件在同样的环境下,替代另一个相同用途的指定软件产品的能 力
可移植性依从性:软件遵循可移植性相关的标准和约定的能力
- 软件生命周期概念是什么?
需求分析 —》可行性分析 —》概要设计 —》详细设计 —》编码实现 —》调试和测试 —》软件验收与应用 —》维护升级 —》废弃
- 软件测试原则是什么?
- 测试证明软件存在缺陷
- 不可能执行穷尽测试,基于风险的测试是必须的
- 测试应该尽早启动,尽早接入
- 缺陷存在集群现象( 80/20 原则)
- 杀虫剂悖论
- 不同的测试活动依赖不同的测试背景
- 不存在缺陷的谬论
- 基于上下文不断调整测试策略/方式
基于测试是为了寻找软件的错误与缺陷,评估与提高软件质量,因此我们提出了这样的一组测试原则,如下所示。
-
- 所有的软件测试都应追溯到用户需求。
- 应当把“尽早地和不断地进行软件测试”作为软件测试者的座右铭。
- 完全测试是不可能的,测试需要终止。
- 测试无法显示软件潜在的缺陷。
- 充分注意测试中的群集现象。
- 程序员应避免检查自己的程序。
-
- 尽量避免测试的随意性
- 如何做好测试计划
4W1H 原则:
-
- What (明确测试什么)
- Why(明确测试目标)
- When(明确项目开始时间、结束时间)
- How(明确测试方案)
- Where(明确资料的位置)
- web 测试和 APP 测试的区别?
从功能测试层面上,web 和 APP 测试在流程上没有区别,但是两者的载然不同,主要区别如下:
-
- 系统结构方面
Web 项目是 B/S 结构,基于浏览器,只需要更新服务器,客户端就会同步响应
APP 项目是 C/S 架构,服务器更新之后,客户端手动进行更新
-
- 性能方面
Web 测试需要响应时间、内存、CPU、吞吐量、并发数
APP 测试需要响应时间、内存、CPU、消耗电量、流量
-
- 兼容性方面
Web 测试主要考虑浏览器和操作系统
APP 测试主要考虑手机品牌、型号、尺寸、分辨率、版本
-
- 测试工具方面
自动化测试:web 一般用 selenium,手机用 APPnium
性能测试:web 一般用 LR,手机用 jmeter
相对 web 测试手机 APP 测试还需关注
① 干扰测试:来电,短信,通话,关机,重启
② 不同网络下的测试,网络切换的测试,无网的测试
③ 安装,卸载,更新
- 如何定位 bug?
- 检查测试环境配置是否有问题,测试数据是否有问题
- 用 fiddler 抓包,分析请求和响应数据是否存在问题
- 查看应用服务器的日志
- 然后再查看数据库的数据是否存在问题
- 需求评审流程https://www.jianshu.com/p/8fead80dd5bb
二、网络基础知识
- 如何做 get 和 post 的区别?
- GET 和 POST 有一个重大区别,简单的说:
GET 产生一个 TCP 数据包;POST 产生两个 TCP 数据包。
- 长的说:
对于 GET 方式的请求,浏览器会把 http header 和 data 一并发送出去,服务器响应 200
(返回数据);
而对于 POST,浏览器先发送 header,服务器响应 100 continue,浏览器再发送 data, 服务器响应 200 ok(返回数据)。
- 三次握手过程分析https://www.jianshu.com/p/d3725391af59
- 第一次: 客户端发送请求到服务器, 服务器知道客户端发送, 自己接收正常。
SYN=1,seq=x
- 第二次:服务器发给客户端,客户端知道自己发送、接收正常,服务器接收、发送正常。
ACK=1,ack=x+1,SYN=1,seq=y
- 第三次:客户端发给服务器:服务器知道客户端发送,接收正常,自己接收,发送也正常.seq=x+1,ACK=1,ack=y+1
上面分析过程可以看出,握手两次达不到让双方都得出自己、对方的接收、发送能力都正常 的结论的。
- 四次挥手过程分析
- 第一次:客户端请求断开 FIN,seq=u
- 第二次:服务器确认客户端的断开请求 ACK,ack=u+1,seq=v
- 第三次:服务器请求断开 FIN,seq=w,ACK,ack=u+1
- 第四次:客户端确认服务器的断开 ACK,ack=w+1,seq=u+1
- 为什么三次握手和四次挥手?
- 三次握手时,服务器同时把 ACK 和 SYN 放在一起发送到了客户端那里
- 四次挥手时,当收到对方的 FIN 报文时,仅仅表示对方不再发送数据了但是还能接收数据,己方是否现在关闭发送数据通道,需要上层应用来决定,因此,己方 ACK 和 FIN 一般都会分开发送。
- cookies 机制和 session 机制的区别
- cookies 数据保存在客户端,session 数据保存在服务器端;
- cookies 可以减轻服务器压力,但是不安全,容易进行 cookies 欺骗;
- session 较安全,但占用服务器资源
- 常见的 HTTP 状态码有哪些?
- 200 请求已成功,请求所希望的响应头或数据体将随此响应返回。
- 201 请求已经被实现,而且有一个新的资源已经依据请求的需要而建立,且其 URI
已经随 Location 头信息返回
- 202 服务器已接受请求,但尚未处理
- 301 (永久移动) 请求的网页已永久移动到新位置。 服务器返回此响应(对 GET
或 HEAD 请求的响应)时,会自动将请求者转到新位置。
- 302 (临时移动) 服务器目前从不同位置的网页响应请求,但请求者应继续使用原有位置来进行以后的请求。
- 303 (查看其他位置) 请求者应当对不同的位置使用单独的 GET 请求来检索响应时, 服务器返回此代码。
- 304 (未修改) 自从上次请求后,请求的网页未修改过。 服务器返回此响应时,不会返回网页内容。
- 305 (使用代理) 请求者只能使用代理访问请求的网页。 如果服务器返回此响应, 还表示请求者应使用代理。
- 307 (临时重定向) 服务器目前从不同位置的网页响应请求,但请求者应继续使用原有位置来进行以后的请求。
- 401 当前请求需要用户验证。如果当前请求已经包含了 Authorization 证书,那么 401
响应代表着服务器验证已经拒绝了那些证书
- 403 服务器已经理解请求,但是拒绝执行它。与 401 响应不同的是,身份验证并不能提供任何帮助,而且这个请求也不应该被重复提交
- 404 请求失败,请求所希望得到的资源未被在服务器上发现
- 500 服务器遇到了一个未曾预料的状况,导致了它无法完成对请求的处理。一般来说, 这个问题都会在服务器的程序码出错时出现。
- 501 服务器不支持当前请求所需要的某个功能。当服务器无法识别请求的方法,并且无法支持其对任何资源的请求。
- 502 作为网关或者代理工作的服务器尝试执行请求时,从上游服务器接收到无效的响应。
- 503 由于临时的服务器维护或者过载,服务器当前无法处理请求。这个状况是临时的, 并且将在一段时间以后恢复。
UDP:不需要连接成功也能发送成功数据;微信、QQ,自己账号没有登陆,别人也可以发送成功;只适合少量数据,否则容易丢失数据。
TCP:必须连接成功才能发送数据,适合大量
三、自动化测试
- 如何做接口自动化,如何做 UI 自动化?
接口项目测试流程:
-
- 测试用例,读取 Excel 里的测试用例--数据 == read_data() --done
- 发送接口请求,执行测试 == post_func() --done
- 执行结果 预期结果做对比 --断言?? --最后结果--passed/failed
- 测试结果的回写 --write_result() --done
就拿简历上的 xxx 项目来说吧,在编写脚本前,我们会对系统进行评估,确认这个系统可不可以实现 UI 自动化,如果可以的话,就筛选出能实现自动化测试的用例,一般优先把冒烟测试用例的转为成脚本。我们是用 selenium 工具来实现自动化,采用 python 脚本语言,基于 unittest 框架进行用例的编写。比如,充值这个功能的脚本,我们是这样做的:首先,我们会构建一个测试工程,测试工程包含 testcase,主要用来存放测试用例,report 用来存放测试报告,其次我们会把用例中公共的部分封装到 common 中,最后用 runAllCase 的 python 文件运行项目自动化用例,脚本调试完后,我们会用 jenkins 持续集成工具,设置脚本每天晚上 10 点跑一遍脚本,跑完后生成 html 格式的自动化测试报告并自动发送邮件。
- python 的冒泡排序是什么?
冒泡排序是最简单的排序算法,如上图所示,我们可以看到不断的从左到右进行比较两个元素的大小,如果后面的元素小于前面的元素,那么它们会交换位置,这样小的元素就会 在前面。
- 进行每一轮从左到右进行比较后,都会有 1 个最大的数字排到后面。
- 如果一个数组里有 N 个元素,那么一共需要进行 N-1 轮如上操作才会完成排序,不理解的可以弄 4 个数字在纸上画画
- 那每一轮要比较多少次,才能排好序呢?比如有 5 个元素的数组,进行第 1 轮,需要
5-1 次比较,就能把最大的数放在最后面;第 2 轮的时候,因为第一轮的原因,最后 1 个数
字不用比较,就是 5-1-1 = 3 次
def bubbleSort(arr): n = len(arr)
# 一共要进行 n-1 轮才能排好序
for i in range(n - 1):
# j 控制每一次的比较,n-i-1 是元素的范围,也就是要比较几次,这里不理解的, 自己在纸上画
for j in range(0, n - i - 1):
if arr[j] > arr[j + 1]: # 交换位置
arr[j], arr[j + 1] = arr[j + 1], arr[j]
return arr
arr = [64, 34, 25, 12, 22, 11, 90]
bubbleSort(arr) print(arr)
四、性能测试
五、必记代码
- 99 乘法表
for i in range(1,10):
for y in range(1,i+1):
msg = '{ 0}*{ 1}={ 2}'.format(i,y,i*y) print(msg,end='\t')
print()
- 冒泡排序
a = [9,2,3,1,6,7,0]
# 确定循环次数为 列表长度-1 次
times = len(a) -1
while times > 0:
for i in range(times): if a[i] < a[i+1]:
a[i],a[i+1]=a[i+1],a[i] times = times -1
print(a)
- 自动化测试用例
from selenium import webdriver from time import sleep
import unittest
class mytest(unittest.TestCase): def setUp(self):
self.d = webdriver.Chrome() self.d.get('网址')
def tearDown(self): self.d.close() self.d.quit()
def test_case_001(self):
self.d.find_element_by_css_selector('CSS 定位表达式').send_keys('username') self.d.find_element_by_xpath('Xpath 定 位 表 达 式 ').send_keys('password') self.d.find_element_by_css_selector('CSS 定位表达式').click()
sleep(1)
login_msg = self.d.find_element_by_id('ID').text self.assertIn('预期结果',login_msg)
if name == ' main ': unittest.main()
六、接口测试
- 什么时候要做接口测试?
公司有接口测试需求,接收到接口测试任务。
- 为什么要做接口测试?
- 开发代码初期,UI 和 web 页面设计还没到位,提前介入测试更早发现问题,否则底层的一个 bug 可能会引起外部多个 bug
- 处于接口安全层面考虑,前端进行限制容易绕过,需要同样测试后端的限制;另外 测试接口验证数据的加密传输,例如用户密码
- 接口测试原理?(jmeter 等工具/写代码)
模拟客户端向服务器发送请求,服务器接收请求后对相应的请求做处理并向客户端返回相应结果,客户端接收结果的一个过程。
- 后端接口测试一遍,前端也测试一遍,是不是重复测试了?没有前端界面, 已经测试后端接口了,前端出来,还要做测试么?
前后端对接 OK(跑正常功能)、前端基本校验
- 接口测试属于测试执行那一阶段?
集成测试
- 什么时候会用到使用 Fiddler?
- 做安全测试,检测敏感信息是否加密,拦截篡改数据;
- 当测试时发现缺陷,用 fiddler 抓包,定位该问题是前端还是后台的问题;
- 模拟弱网环境;
- 统计单个功能的响应时间。
- 用 fiddler 如何定位是前端还是后台的问题?
如果接口响应的数据不正确,那就很可能是后端的问题,如果请求参数不正确或者接口响应数据正确但是页面上显示不对,就是前端的问题
- Fiddler 怎么拦截篡改数据?
- 就拿充值来说吧,点击充值之前,先启动 Fiddler,按 F11 打断点,将请求拦截下来,
- 然后在 fiddler 中,对拦截下来的请求,修改其中的数据,比如将充值的金额进行修改
- 修改完成后,关闭拦截,继续请求的发送即可。
- Fiddler 怎么模拟弱网测试?
- 点击规则-->自定义规则,打开 fiddler 的脚本编辑器,找到 simulateModem
- 设置上传和下载的延时速度
- 点击规则-->性能,选模拟带宽
- fiddler 如何模拟 2g/3G 的网络?
- 2G 一般上行/下行速率约为:2.7、9.6kbs,模拟设置为:uploaded 约 2962 ms, downloaded 约 833 ms;(弱网一般指 2G 网络)
- 3G 一般上行/下行速率约为:384、2560kbs,设置为:uploaded 约 2.6 ms, downloaded 约 0.39 ms;
https://www.cnblogs.com/fighter007/p/12145205.html
- Fiddler 怎么抓 HTTPS 的包?
- 安装安全证书;
- 点击 fiddler 的 Tools-->options-->https
- 勾选上所有选项,更换证书,重启 fiddler
- Fiddler 怎么抓手机 app 的包?
- 手机与 fiddler 所的电脑连接到同一网络;
- 在 fiddler 设置监听端口,并允许远程终端连接;
- 在手机上填写代理服务器的地址和端口。
- fiddle 抓包后怎么分析的?
- 比方说怎么判断前后端 bug
- fiddler 在没有设置过滤器的时候,没有抓到任何请求信息(可能是前端页面元素没有绑定事件,或者绑定事件的元素弄错了,或者前端发生 js 错误等)
- 若抓取到的请求的返回 http code 为 500,说明服务器发生了内部错误
- 若抓取到的请求的返回 http code 为 404,说明可能是服务器根本没有这个地址的服务,也有可能是因为前台 js 提交请求的时候弄错了提交地址
- 你们是怎么进行接口测试的?
先对开发提供的接口文档做好需求分析,进行用例编写及评审,然后我们选择 jemter 做接口测试,我的习惯是把主要的接口串在一起做一个自动化批量测试,确保接口功能是正 常的,然后进行详细的测试。比如测试一个接口,添加线程组添加 http 请求,填写接口信息;如果接口与接口之间有依赖就需要添加 cookie 管理器,jdbc requests,正则表达式等元件,然后添加结果树和断言,关注响应结果是否跟预期一致,同步关注数据库字段,如果
报错查看日志定位,大致就是这样
- 常见状态码
在 HTTP 请求的返回数据包中,响应状态码分为以下 5 种。
- 1xx:消息。一般是告诉客户端,请求已经收到了,正在处理,别急……
- 2xx:处理成功。一般表示请求收悉、我明白你要的、请求已受理、已经处理完成等信息。
- 3xx:重定向到其他地方。它让客户端再发起一个请求,以完成整个处理过程。
- 4xx:处理发生错误,错误来自客户端。例如,客户端请求的是一个不存在的资源、客户端未被授权、禁止访问等。
- 5xx:处理发生错误,错误来自服务器端。例如,服务器端抛出异常、路由出错、HTTP
版本不支持等。
- http 中四种发送请求方式
HTTP 中有四种发送请求的方式:GET、POST、PUT 和 DELETE。
- GET:向特定的资源发出请求。
- POST:向指定资源提交“数据进行处理”请求(例如,提交表单或者上传文件),数据 被包含在请求体中。POST 请求可能导致新的资源的创建,以及(也可能是“或”)已有资源的修改。
- PUT:向指定资源位置上传其最新内容。
- DELETE:请求服务器执行删除操作。
在实际应用中常用的是 GET 和 POST。其他的请求方式都可以通过这两种方式间接地实现。
- get 方式和 post 方式的区别
HTTP 发送请求最主要的两个方式是 GET 和 POST,这两者有哪些区别呢?
区别一:对请求参数的处理方式不同(直观的区别)
- GET 请求:请求的数据会附加在 URL 之后,以“?”分隔 URL 和传输数据,如有多个参数则用“&”连接。URL 采用的是 ASCII 编码格式,而不是 Unicode 编码格式,即所有的非 ASCII 字符都要在编码之后再传输。
举例:https://www.v2ex.com/api/nodes/show.JSON?name=Python
- POST 请求:POST 请求会把请求的数据放置在 HTTP 请求包的 Body 数据中,数据包的形式可以是“参数名 1=参数值 1&参数名 2=参数值 2”,也可以是 JSON 格式(键值对)。当然,JSON 格式是一种通用的方式。
举例:http://192.168.1.171:8081/api/user_sign/
Body 数据:{ "time":"1499933825","sign":"deb697c7fffcca828a7a03a218b2cda5"}
区别二:传输数据的大小不同
HTTP 没有对传输数据的大小进行限制,也没有对 URL 的长度进行限制。而在实际的程序开发中,存在以下限制。
- GET:特定浏览器和服务器对 URL 的长度有限制。例如,IE 对 URL 长度的限制是 2083Byte
(2×1024Byte+35Byte)。其他浏览器(如 Netscape、FireFox 等)在理论上没有长度的限制,其限制取决于操作系统的支持。因此,在采用 GET 方式提交数据时,传输数据会受到URL 长度的限制。
- POST:由于不是通过 URL 传值,在理论上数据的大小不受限制。但实际上,各个 Web
服务器会对采用 POST 方式提交的数据的大小进行限制,例如,Apache、IIS6 都有各自的配置。
区别三:安全性不同
POST 方式的安全性比 GET 方式的安全性高。使用 GET 方式时,在地址栏里可以直接看到请求数据,采用这种方式可能受到 Cross-site request forgery 攻击。
POST 方式需要抓包才能获取到数据,变相地提高了安全性。
- 接口测试怎么测试的。
- 当我们拿到接口文档后,会先进行熟悉需求文档,了解每个接口的功能、服务器地址、 端口、请求方式、请求参数、参数的约束条件有哪些还有一些响应的字段和响应的状态码
- 之后就会开始编写测用例的,跟功能测试一样,考虑到正常异常的请求参数,还要考虑 到与之对应响应报文是否正确
- 最后就开始使用 Jmeter 执行用例了,先建立一个线程组,再添加 http 请求,填写好请求地址,端口,和请求参数,设置参数化,添加断言等,最后添加查看结果树再运行。运行完后,检查接口是否通过,如果不通过,先定位下原因,如果是请求的参数有问题, 修改后再进行测试,如果是接口本身存在 bug,就把服务器上的日志取下来,提单给开发修改,一直到接口没问题了,就放到我们搭建好的 Jmeter+Jenkins 框架上做持续集成测试。
- 这就是我们接口测试的大概流程。
- 举例说一下你的接口测试是怎么做的?
我以充值这个接口说下吧:充值这个接口用的是 http 协议,使用 post 请求方式,发送给服务器的参数有手机号,充值额度,这些参数都是必传的参数。我们是使用 Jmeter 来做接口测试的,首先,要新建一个线程组,在线程组下面添加一个 http 的请求,然后填写好服务器地址,接口路径,请求方式,请求参数。由于充值的接口依赖于登录,所以我们会先调用登录接口,从中获取 cookies 值,在充值接口中使用${ 参数名}的方式引用,接下来还要对其他参数进行参数化,构造各种正常和异常的数据,我们先在本地创建一个 txt 文档, 把参数填写到文档里面,在 Jmeter 中添加一个 csv 文件设置,填写好 txt 文档的路径,然后在请求参数中使用正则提取器把 cookies 值关联出来,然后在充值接口中使用${ 参数名} 的方式引用;接下来添加断言,检查服务器返回的结果和预期结果是不是一致的。最后,添加查看结果树查看测试结果。
重点:学习资料学习当然离不开资料,这里当然也给你们准备了600G的学习资料
需要的先关注再私我关键字【000】免费获取哦 注意关键字是:000
疑惑:为什么要先关注呢? 回:因为没关注的话私信回了你看不到
项目实战
app项目,银行项目,医药项目,电商,金融
大型电商项目
全套软件测试自动化测试教学视频
300G教程资料下载【视频教程+PPT+项目源码】
全套软件测试自动化测试大厂面经
python自动化测试++全套模板+性能测试
听说关注我并三连的铁汁都已经升职加薪暴富了哦!!!!