boss上测试面试宝典总结
测试基础
软件测试
黑盒测试和白盒测试有哪些方法
黑盒：等价类划分、边界值发现、错误推测、因果图法、场景法、判定表驱动法
白盒：逻辑覆盖、程序插桩技术、基本路径法、符号测试、错误驱动测试
在项目中如何保证软件质量
软件质量部不仅仅是某个人来保证的，应该是整个团队共同努力的结果，因此需要一个规范的项目流程
对于产品来说，保证迭代过程中的产品逻辑，对于可能的兼容、升级做出预判并给出方案
对于架构设计来说，满足产品表达的同时要注意设计的延伸性
对于开发来说，产品细节的保证，技术方案的选择都要严谨，考虑兼容，性能，开发 完成后要充分自测，严格遵循开发规范操作
测试，验证产品逻辑，站在用户角度对交互设计进行系统验证，尽可能多的使用技术手段保证测试质量；比如需求分析细化、测试计划、测试方案、测试报告等文档进行评审，使用各种技术保证软件质量，严格遵守测试规范
运维，制定严谨的上线流程和权限管控，做好生产环境监控报警，出现事故后有应急方案
软件测试的核心竞争力
测试人员的核心竞争力在于提早发现问题，并能够发现别人发现不了的问题
怎么看待软件测试的潜力和挑战
软件测试是正在快速发展，充满挑战的领域，尽管现在许多自动化测试软件的出现使得传统手工测试的方式被替代，但自动化测试工具的开发，安全测试，测试建模，精准测试，性能测试，可靠性测试等专项测试中仍需要大量具有专业节能与专业素养的测试人员，并且随着云计算，物联网，大数据的发展，传统的测试技术可能不适用，测试人员也面临挑战
软件测试的目的
证明软件有错，而不是证明软件无错
尽早发现缺陷，减少成本
保障用户更加符合客户的需求，弄清楚实际结果与预期结果的差异测试用例
测试报告里都包含哪些内容
测试标题（xx测试报告）
测试项目（xx项目）
测试版本（测试产品版本号）
测试环境（地址）
测试情况（执行了多少用例，成功多少，失败多少，产出多少，已修复多少，是否有遗留问题）
测试策略（使用到的测试方法、测试工具。测试人员数量、测试耗时）
测试范围
测试时间、上线风险、遗留问题分析、测试是否通过
如何提高用例的覆盖率、减少漏测
根据需求文档来编写用例，确保每条需求都被对应的用例覆盖
要充分理解业务，挖掘隐形需求，并编写对应的用例
除了正常的业务场景，多考虑一些异常的场景和数据
要从多个维度对软件进行测试、功能、性能、安全等各方面来考虑
多站在用户的角度考虑问题，模拟用户的使用场景
如何编写测试用例
测试人员应该尽早介入，彻底理清楚需求，这个是写好测试用例的基础
如果以前有类似的需求，可以参考类似需求的测试用例，然后还需要看类似需求的bug情况
清楚输入，输出的各种可能性，以及各种输入之间的关联，理清楚需求的执行逻辑，通过等价类、边界值、判定表等方法找出大部分测试用例
找到需求相关的一些特征，补充测试用咯
根据自己的经验分析漏测的测试场景
’ 多总结类似功能点的测试点，才能写出质量越高的测试用例
书写格式一定要清晰
做好测试用例设计工作的关键是什么
熟悉业务需求和用户使用场景
了解本次需求对其他系统的影响
了解开发技术实现和数据库设计
从不同维度编写 测试用例、功能、性能、安全、性能等
工作方法
如何确定是不是一个bug
看需求文档，是否有明确的要求
看下这个问题是否违反了正常人的行为习惯，或者行业的通用规范
可以找产品经历或者开发人员沟通确定是否为bug
对于无法发成一致的问题，可以组织相关人员开会，共同来决定是否为bug
如果想进行bug的测评，怎么去评测bug
bug的priority()和severity()是两个重要属性，通常人员在提交bug的时候，只定义severity，而将priority交给leader定义，通常severity分为四个等级，blocker,critical,major,minor，而priority分为5个等级：
怎么定位是app端还是服务端的问题
1.抓包分析，对接口进行抓包分析，如果请求里的参数出现错误，一般都是客户端Bug；如果请求正常而响应是错误的，那就是服务端的bug
2.日志分析，还可以通过查看客户端服务器的日志，分析有没有异常信息，从而确定具体原因
功能测试
功能测试用例一般包含哪些内容
测试编号、标题、所属模块、前置条件、测试步骤、预期结果、优先级、输入数据、实际结果等、（测试路径
功能测试包含哪些测试
功能测试是对整个业务功能实现的总称，所有我们拆分功能下来会包括单元测试
比如链接测试、表单测试、搜索测试、删除测试、cookie、session测试，数据库测试等部分
功能测试对产品各个功能进行验证，逐项测试检查产品能否达到用户要求的功能
接口测试
接口测试用例编写要点有哪些
入参，包含参数合法性、参数校验、参数边界值、参数为空、缺少参数等
返回值，包括各种情况下的响应内容是否正常
接口业务逻辑和功能是否正常
数据库校验
性能测试（接口tps,响应时间等）
安全性、敏感信息加密、权限控制等
为什么要做接口测试
在公司里，客户端和服务端通常由于不同的团队开发的，在项目开发过程中，客户端和服务端的进度不一样，比如服务端先开发完，这个时候可以先对服务端进行接口测试，确保服务端逻辑和返回数据是正确的，然后再测客户端。
在测试某些业务时，不能仅仅通过前端来测试，比如用户注册，前端限制了用户名不能为空，但是有些人可能通过工具绕过前端直接调用服务接口，如果服务端没有做相关的逻辑判断，就会造成数据错误。包括接口数据传输过程中是否对关键信息加密等。
在开发提测后，可以通过工具把服务端的接口测试跑一遍，确保接口测试用例都是通过的，快速判断服务端接口是否符合预期。然后再通过UI界面进行测试，否则接口有bug，前端就会也有bug
接口测试中的加密参数如何处理
先了解接口使用的加密方式（md5,rsa..)
j检查接口测试工具是否支持这种加密方式，如果支持的话，直接使用对应的功能就行了（比如jmeter支持md5)，如果加密算法是公司特有的算法，可以找开发要加解密的代码，可以在接口测试工具中调用公司的加密算法代码来实现解密
接口测试流程
分析需求文档和接口文档（URL、入参、返回值等）--除了分析接口文档，还应该去数据库熟悉对应的表设计和字段类型，方便根据对应字段参数设计测试用例
制定测试计划
根据需求文档编写接口测试用例（准备接口测试数据，要考虑不同业务场景测试）
测试用例评审
根据用例，使用接口测试工具执行测试
提交bug,跟踪解决进度，回归测试
预生产环境测试
输出接口测试报告
上线
接口测试什么时候介入（具体怎么实施接口测试详细 版）
接口测试应该在软件开发生命周期的早期就开始介入，并随着不同阶段的紧张不断深入，通过早期发现和修复问题，可以有效地减少在后期生命周期阶段的成本和风险
在需求分析阶段，接口测试可以通过审查和分析接口设计文档开始，在这个阶段，可以确认接口设计是否满足需求，是否与其他组件协同工作，以及是否有必要进行性能和安全性方面的初步评估
在设计阶段，接口测试可以编写测试用例和设计测试数据，以确保在实现阶段可以全面地覆盖接口的各种情况，此时可以进行模拟接口的测试，以验证接口设计的可行性
在开发阶段，接口测试可以进行单元测试，确保各个模块之间的接口能够按照设计规范进行通讯，这有助于在早期发现和修复可能存在的集成问题
集成测试阶段，集成测试侧重于不同组件之间的写通过工作，在该阶段，可以验证接口的稳定性，数据传递的准确性，以及接口是否符合预期的性能要求
验收阶段，接口测试确保整个系统在满足用户需求的同时，各个模块之间的接口仍能正确地工作，接口测试在验收测试中有助于发现可能影响用户体验的问题
维护阶段，接口测试有助于确保对系统的任何更改不会破坏已有的接口，并且新的功能与现有功能的接口是稳定和可靠的
接口自动化优缺点
优点：
提高回归测试的效率，可以在短时间内执行大量的测试用例
及早发现缺陷，减少集成测试风险
节约人力成本，一旦脚本写好，可以在没有人工干预的情况下自动执行
提高可靠性和一致性，不受人为因素干扰，提高测试可靠性
缺点：
前期投入成本较高
需要提前写脚本，有一定的维护成本
不能覆盖所有的测试用例和所有场景，尤其是一些复杂场景和边缘场景
一个接口请求不通（或页面无法访问）该如何排查
首先确认网络是否正常（客户端和服务端网络不通
确认接口URL是否正确、服务器地址、请求方式是否正确（ip或url写错了，服务端项目根本没有部属起来）
确认请求头信息是否正确
确认是否有防火墙或代理等拦截（如果是浏览器访问，是不是绑定错了hosts)
是否有鉴权拦截，没有访问接口的权限（缺乏token、cookie之类）
是否超过了接口的访问次数限制（如果有的话）
查看返回结果，通过响应码，状态码以及返回体等信息排查
接口测试有没有测出什么bug
接口测试中发现的bug，大多都是参数校验，代码逻辑、边界条件、数据错误方面的问题。比如，新增促销活动接口，满减金额为空也能保存成功，原因是后端代码没有对满减参数做控制判断。比如，活动列表接口，查询出来的活动数据少了一条，原因是sql中limit条件传入起始序号是1而不是0.比如，更新活动接口，接口提示更新成功，但是数据库中的update_time字段没有更新成最新时间，原因是开发忘记更新这个字段
接口文档描述不清晰，导致测试工作重复
接口不对，给的参数、类型等信息不对，接口调试报错
需求频繁变动时，前面配置好的接口测试环境都无法使用，一直要维护修改
工具-fiddler
fiddler的工作原理
fiddler其实就是在客户端和服务端之间起到了一个代理的作用，它可以监听客户端和服务端的http通讯，把请求和响应的数据都抓下来，另外还可以做请求响应拦截，修改报文，以及弱网测试等
工作中fiddler来做什么
当测试出bug时，可以通过fiddler抓包，分析bug是客户端还是服务端的问题
当做接口测试时，通过抓包获取接口的入参和返回值，包括接口之间的数据关联
当对客户做弱网测试，可以修改fiddler的网络模拟参数，模拟出不同的网络速度
当需要对客户端测试一些特殊场景，可以使用fiddler设置响应断点（bpu,bpafter)，修改服务端响应的数据，测试客户端对应的逻辑处理，比如修改服务端返回的状态为500
查看请求响应的时间，查看敏感信息是否加密，查看请求的内容，弱网测试，拦截篡改，抓手机的包
jemeter中的beanshell该如何使用
大致五类用法吧：写断言；读取数据库；读日志；生成执行日志，存储路径等；脚本健壮性，处理一些脚本报告问题、转义问题等
对比
token 是做什么用的
token就是令牌，是一个字符串，主要是用于做客户端身份认证，通常登录成功后，服务端会返回token,客户端需要把token值保存下来，后续请求其他接口时，需要在请求中携带这个token值，只有服务端对token校验通过后，才允许访问
http和https区别
http信息是明文传输的，而https是具有安全性的加密传输
http标准端口是80，而https的标准端口是443
http无需证书，而https需要认证证书
get和post区别
get请求的参数是被放在url里，post参数是放在请求体里
get请求参数放在url里，url的长度是受限的；而post接口长度没有限制
get请求参数放在url里，安全性较差；而post放在body录，安全性相对较好，
get请求可以被浏览器缓存，post请求不能被缓存
get请求可以直接通过浏览器访问，支持刷新和后退； post请求不能直接使用浏览器访问，刷新后数据要重新发送
cookie和session区别
cookie数据存放在客户端，session数据存放在服务端
cookie不是很安全，别人可以分析存放在本地的cookie并进行cookie欺骗
seesion会在一定时间内保存在服务器中，当访问增多，会比较占用你服务器的内存
单个cookie保存的数据不能超过4k,很多浏览器都限制一个站点最多保存20各cookie；而session则存储与服务端，浏览器对其没有限制
http状态码
1xx（信息性状态码）
100 continue :服务器已接收到请求头，并且客户端应该继续发送请求体
101 switching Protocols:服务器已经理解了客户端的请求，并将通过upgrade消息头通知客户端切换协议
2xx（成功状态码）
200-请求成功，一般用于get和post请求
201 :请求已经被实现，并且有一个新的资源已经被依据请求的需要而建立
204：服务器成功处理了请求，但没有返回任何内容
3xx（重定向状态码)
301：请求的资源已被永久移动到新url，将来的请求应该使用新的url
302请求的资源现在临时从不同的url响应请求
304 自从上次请求后，请求的资源未被修改过
4xx（客户端错误状态码）
400：服务器无法理解客户端的请求，通常由于客户端发送了不合法的请求
401：请求要求身份验证，需要提供有效的用户身份信息
403：服务器理解请求，但拒绝执行它
404 服务器未找到请求的资源
5xx 服务器错误状态码
500 服务器遇到一个未知的错误，无法完成请求
501 服务器不支持当前请求需要的某个功能
505 服务器目前无法处理请求，通过由于临时过载或者正在维护
web测试和app测试有什么区别
从系统架构来说，web端一般是bs架构，基于浏览器的；app是c/s架构，是有客户端的
兼容性方面，web是基于浏览器的，所以更倾向于不同的浏览器的兼容；app测试则必须依赖于手机，更关注系统的版本、分辨率、屏幕尺寸等兼容性问题（弱电量、弱网无网、返回按钮、屏幕旋转、暴力等情况进行测试）
前端更新时，web是自动同步的，而app则需要下载最新版本
除了功能测试，app海需要额外关注一些专项的测试，比如弱网测试、中断测试、安装卸载测试、流量电量的测试、移动端性能测试等
场景测试
朋友圈点赞功能进行测试
是否可以正常点赞和取消
点赞的人是否在可见分组里
点赞状态是否能及时更新显示
点赞状态是否共同好友可见
不同手机、系统显示界面如何
性能检测，网速快慢对其影响
点赞显示的是否正确
点赞是否按时间排序，头像对应的是否正确
是否能在消息列表中显示点赞人的昵称、备注
可扩展性测试、点赞后能否发表评论
是否在未登录时可查看被点赞的信息
如何对一个页面进行测试
UI测试：页面布局，页面样式检查，控件长度是否够长；显示时，是否会被截断；支持的快捷键、tab键切换焦点顺序正确性等
功能测试：页面上各类空间的测试范围，测试点。结合控件的实际作用来补充检查点；比如：密码框是否*显示，输入是否做trim处理等
安全测试:输入特殊字符，sql注入，脚本注入测试，后台验证测试，对于比较重要的表单，绕过js检验后台是否验证，数据传输是否加密，比如，请求转发，地址栏直接显示发送的字符串
兼容性测试
性能测试
原文地址：https://blog.csdn.net/m0_62410106/article/details/142839986
免责声明：本站文章内容转载自网络资源，如本站内容侵犯了原著者的合法权益，可联系本站删除。更多内容请关注自学内容网（zxcms.com）！