写在前面
1. 本文内容来源:本文是将自己在20年里找工作的部分笔记重新整理了下,不少内容当时是查阅的知乎、博客园、书籍等(部分还能找到原帖的均附上了链接)。我自己在这一年里也是从牛客上学习了很多面经和经验帖,收获了好几家大厂offer。最近整理出来这些,希望能对找测开岗的同学们有帮助!
2. 本文内容顺序:测试基础理论、测试岗经常被问到的场景题、Linux知识点、智力题。
3. 本文阅读建议:我结合了自身的面试经历,把高频的、重要的知识点都用★标注了,★越多代表自己被问得次数越多。(当然这也只是我的面试经历,存在局限性。)
4. 叨逼叨:亲测,测试岗的面试难度相对开发岗确实低一些,不过面试的内容差别倒不是特别大,像计网、OS、数据结构、数据库、算法/刷题这些都是要准备的,并且测试岗的面试还需要你额外掌握测试相关的知识,也就是本文的大部分内容。不然你叫面试官怎么想你呢?你一点测试的理论知识都不了解,对方只会觉得你大概率是做不来开发才想着试试测试岗吧,所以你得快速支棱起自己的测试技能树,让面试官觉得你是有志于干测试开发的。这一点很重要。
5. 如果你是正在找实习,也可以参考我的另一篇关于找工作的文章:https://blog.csdn.net/feat_ct/article/details/114580315
常用自动化测试工具
1、Appium
官网: http://appium.io
AppUI自动化测试
Appium 是一个移动端自动化测试开源工具,支持iOS 和Android 平台,支持Python、Java 等语言,即同一套Java Python 脚本可以同时运行在iOS 和Android平台,Appium 是一个C/S 架构, 核心是一个 Web 服务器,它提供了一套 REST 的接口。当收到客户端的连接后,就会监听到命令,然后在移动设备上执行这些命令,最后将执行结果放在 HTTP 响应中返还给客户端。
License:免费
2、Selenium(★★)
官网: https://www.seleniumhq.org/download/
WebUI自动化测试
Selenium是一个用于Web应用程序测试的工具,Selenium已经成为Web自动化测试工程师的首选。Selenium测试直接运行在浏览器中,就像真正的用户在操作一样。支持的浏览器包括IE(7、8、9)、Mozilla Firefox、Mozilla Suite等。这个工具的主要功能包括:测试与浏览器的兼容性——测试你的应用程序看是否能够很好得工作在不同浏览器和操作系统之上。测试系统功能——创建回归测试检验软件功能和用户需求。支持自动录制动作和自动生成 .Net、Java、Perl等不同语言的测试脚本。Selenium 是ThoughtWorks专门为Web应用程序编写的一个验收测试工具。其升级版本为Webdriver。
License:免费
3、Postman(★★★)
官网: https://www.getpostman.com
接口测试
Postman 提供功能强大的 Web API 和 HTTP 请求的调试,它能够发送任何类型的HTTP 请求 (GET, POST, PUT, DELETE…),并且能附带任何数量的参数和 Headers。不仅如此,它还提供测试数据和环境配置数据的导入导出,付费的 Post Cloud 用户还能够创建自己的 Team Library 用来团队协作式的测试,并能够将自己的测试收藏夹和用例数据分享给团队。
License:免费
4、Jmeter(★★★)
接口测试,性能测试
JMeter是Apache组织的开放源代码项目,它是功能和性能测试的工具,100%的用java实现;
JMeter可以用于测试静态或者动态资源的性能(文件、Servlets、Perl脚本、java对象、数据库和查询、ftp服务器或者其他的资源)。JMeter用于模拟在服务器、网络或者其他对象上附加高负载以测试他们提供服务的受压能力,或者分析他们提供的服务在不同负载条件下的总性能情况。你可以用JMeter提供的图形化界面分析性能指标或者在高负载情况下测试服务器/脚本/对象的行为。
使用Jmeter做接口测试需要注意一点,小心使用“用户定义变量”,Jmeter组件有优先级的,如果多个线程同时执行的时候,“用户定义变量”组件定义的变量可能会乱套。
License:免费
5、Loadrunner
官网: https://software.microfocus.com/en-us/products/loadrunner-load-testing/overview
性能测试
LoadRunner,是一种预测系统行为和性能的负载测试工具。通过以模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题,LoadRunner能够对整个企业架构进行测试。企业使用LoadRunner能最大限度地缩短测试时间,优化性能和加速应用系统的发布周期。 LoadRunner可适用于各种体系架构的自动负载测试,能预测系统行为并评估系统性能。
License:商业
6、Jenkins(★★★★★)
持续集成
自动化构建 编译,部署,任务执行,测试报告,邮件通知等。
License:免费
手机兼容性测试(机型选择)
测试基础理论
https://blog.csdn.net/lim13760114815/article/details/88396681
软件测试开发流程:
1.需求分析
在测试前拿到产品需求文档,进行需求分析及需求评审前先对需求文档进行详细的阅读,对有疑问的地方进行标注。
具体可从以下进行:
a.分析产品功能点
b.产品核心竞争力
c.Kano模型、马斯洛需求分析、多问几个为什么、上下文分析法
2.制订测试用例(重要)
工欲善其事,必先利其器;对测试而言,测试用例就是器,做好了才能把好关
a.使用思维导图列举测试大纲,尽量发散,想到什么就写什么,;先放后收,对知识点进行总结和归纳,标记重点测试模块,删除冗余及重复测试点。
b.可使用边界值法、等价类划分法、错误推测法、因果图法等设计案例
c.根据测试大纲制定测试用例,需包含模块名、测试优先级、操作步骤、期望结果、测试结果、备注
3.评审测试用例
a.测试作为主导,联合开发、项目经理、PM进行测试用例评审
b.可先讲解测试大纲,让开发、项目经理、PM心中对测试用例有个大概;后再进行详细测试用例讲解
4.执行测试
a.根据测试用例执行测试
b.发现问题保留现场,记录测试方法,通知开发解决问题
c.覆盖测试用例之外若有时间可进行探索性测试
5.提交Bug并推动Bug解决
a.在Bug管理工具上提交Bug,详细记录测试步骤
b.根据Bug严重程度划分Bug等级:致命、严重、一般、提示
c.推动开发解决问题,记录问题进展,一般聊天沟通,若问题严重则需通过邮件推动解决
6.回归测试
a.对已修复的Bug进行验证
b.对Bug所在模块进行基本功能测试;整体进行冒烟测试,确保不会因为修改Bug而引起其他功能出现问题
7.编写并提交测试报告
可使用金字塔原理设计测试报告,先总后分,上级统领下级,下级推导出上级,环环相扣
a.对Bug进行汇总,筛选出各个等级的Bug存活情况
b.制订Bug发现及解决曲线图,一般版本正常应是前期多,后期收敛,存活的是级别较低的Bug
c.总结归纳版本情况,评估发布与否
软件测试方法(★★★★★)
1. 软件测试方法 :白盒测试、黑盒测试、灰盒测试、静态测试、动态测试
2. 白盒测试 :是一种测试用例设计方法,在这里盒子指的是被测试的软件,白盒,顾名思义即盒子是可视的,你可以清楚盒子内部的东西以及里面是如何运作的,因此白盒测试需要你对系统内部的结构和工作原理有一个清楚的了解,并且基于这个知识来设计你的用例。
白盒测试技术一般可被分为静态分析和动态分析两类技术。
静态分析主要有:控制流分析技术、数据流分析技术、信息流分析技术。
动态分析主要有:逻辑覆盖率测试(分支测试、路径测试等),程序插装等。
白盒测试优点:迫使测试人员去仔细的思考软件的实现;可以检测代码中的每条分支和路径;揭示隐藏在代码中的错误;对代码的测试比较彻底;最优化。
白盒测试缺点:昂贵;无法检测代码中遗漏的路径和数据敏感性错误;不验证规格的正确性。
3. 黑盒测试又叫功能测试 ,这是因为在黑盒测试中主要关注被测软件的功能实现,而不是内部逻辑。在黑盒测试中,被测对象的内部结构,运作情况对测试人员是不可见的,测试人员对被测产品的验证主要是根据其规格,验证其与规格的一致性。
在绝大多数没有用户参与的黑盒测试中,最常见的测试有:功能性测试、容量测试、安全性测试、负载测试、恢复性测试、标杆测试、稳定性测试、可靠性测试等。
4. 灰盒测试 :白盒测试和黑盒测试往往不是决然分开的,一般在白盒测试中交叉使用黑盒测试的方法,在黑盒测试中交叉使用白盒测试的方法。灰盒测试就是这类界于白盒测试和黑盒测试之间的测试。
最常见的灰盒测试是集成测试 。
5. 静态测试 :是一种不通过执行程序而进行测试的技术。它的关键功能是检查软件的表示和描述是否一致,没有冲突或者没有歧义。
6. 动态测试 :包含了程序在受控的环境下使用特定的期望结果进行正式的运行。它显示了一个系统在检查状态下是正确还是不正确。
单元测试属于白盒测试范畴;集成测试属于灰盒测试范畴;系统测试属于黑盒测试范畴 。
CI/CD理解(★★★★★)
摘自 如何理解持续集成、持续交付、持续部署? - yumminhuang的回答 - 知乎 https://www.zhihu.com/question/23444990/answer/89426003
持续集成
持续集成强调开发人员提交了新代码之后,立刻进行构建、(单元)测试。根据测试结果,我们可以确定新代码和原有代码能否正确地集成在一起。
持续交付
持续交付在持续集成的基础上,将集成后的代码部署到更贴近真实运行环境的「类生产环境」(production-like environments)中。比如,我们完成单元测试后,可以把代码部署到连接数据库的 Staging 环境中更多的测试。如果代码没有问题,可以继续手动部署到生产环境中。
持续部署
持续部署则是在持续交付的基础上ÿ