测试面试题+测试面试宝典（分类版）
测试面试宝典（分类+每周更新）
- 前言
- 一、基础类
-
- 1.1 软件测试定义
- 1.2 软件测试分类：
- 1.3 黑盒测试方法
- 1.4 白盒测试方法
- 1.5 单元测试策略
- 1.6 集成测试策略
- 1.7 系统测试策略
- 1.8 验收测试策略
- 1.9 α和β测试
- ------------分界线-------------以下是一些常用测试方法
- 1.10 兼容性测试策略
- 1.11 强度（健壮性）测试策略
- 1.12 压力测试策略
- 1.13 性能测试（强度+压力）
- 1.14 兼容性测试策略
- 1.15 测试用例设计方法
- 1.15 测试用例设计经典面试题——电梯，杯子，笔，桌子，洗衣机
- 1.16 冒烟测试用例
- 二、流程类
-
- 2.1 软件和测试生命周期
- 2.2 软件开发模型
- 2.3 测试模型
- 三、linux类
-
- 3.1列举常用的20个命令
-
- 3.1.1、cd
- 3.1.2、ls
- 3.1.3、grep
- 3.1.4、find
- 3.1.5、cp
- 3.1.6、mv
- 3.1.7、rm
- 3.1.8、ps
- 3.1.9、kill命令
- 3.1.10、killall
- 3.1.11、file
- 3.1.12、tar命令
- 3.1.13、cat命令
- 3.1.14、chgrp命令
- 3.1.15、chown命令
- 3.1.16、chmod命令
- 3.1.18、vim命令
- 3.1.19、gcc命令
- 3.1.20、time命令
- 四、常用软件和框架
- 五、计算机基础类
- 六、持续集成、敏捷等新兴类
- 总结
- 引用
每周出一篇以上内容有一定深度的文章！
前言
本文预计三个月更新完所有部分的初稿，大家可以提前收藏~
csdn中的面试宝典已经足够多了，并且耐心看下来质量都挺不错的，但是大部分的面试宝典都有以下几个缺点：
1、没有目录且篇幅过长，很难让人抓住重点。
2、思维跳跃，想到啥问题写啥问题，不成体系。
3、不及时更新，看到好的问题应该记录下来并更新自己的想法与理解。
因此，想写一本属于自己的面试宝典，写完之后尽量以每两周一次的频次进行更新，期间看到大家分享出来的好的测试面试题也可以一并整理并写出自己的一些理解供大家参考。
由于本文内容非常详细，建议大家收藏后，在面试前进行系统的复习，并且可以根据目录有选择性地来进行查阅，一次性看完不太可取。
欢迎大家在评论中留言一些问题，会持续关注哒~
PS：很多理论都有参考各地方的博文，如果博主有意见可私信我~侵删
引用在末尾。
一、基础类
1.1 软件测试定义
是使用人工或自动的手段来运行或测定某个软件系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别，贯穿整个软件开发生命周期。
简单的说，软件测试是以发现错误为目的而执行的一个程序或系统的过程。
1.2 软件测试分类：
1）按照是否执行被测试软件来分：
静态测试：是指不运行软件，测试包括代码检查、静态结构分析、代码质量度量等，主要对软件需求说明书、设计说明书、软件源代码进行检查与分析。
动态测试：指通过运行被测程序，检查运行结果与预期结果的差异，分析差异原因，并分析软件运行效率、健壮性等性能。
动态测试是目前公司主要的测试方式
2）按照测试技术分为黑盒测试和白盒测试：
黑盒测试：黑盒测试又叫功能测试或数据驱动测试，在完全不考虑程序内部结构和内部特性的情况下，通过软件的外部表现来发现其缺陷和错误。
白盒测试：白盒测试也称结构测试或逻辑驱动测试，它是按照程序内部的结构进行测试程序，通过测试来检测产品内部逻辑是否按照设计规格说明书的规定正常进行，检验程序中的每条通路是否都能按预定要求正确工作。
3）按照测试手段来分，可以分为手工测试和自动化测试
自动化测试：在预先设定的条件下运行被测程序，并分析运行结果。这种测试方法就是将以人驱动的测试行为转化为机器执行的一种过程
4）按照过程阶段来分，可以分为单元测试、集成测试、系统测试和验收测试
单元测试：通过模块(类/方法/函数)测试，使代码达到设计要求
主要目的是针对编码过程中可能存在的各种错误，例如用户输入验证过程中的边界值的错误。
；
集成测试：将经过单元测试的模块逐步组装成完整的程序。 主要目的是检查各单元与其它程序部分之间的接口是否存在问题，各模块功能之间是否有影响。
；
系统测试：是将已经确认的软件、计算机硬件、外设、网络等其他元素结合在一起进行测试。
系统测试是针对整个产品系统进行的测试，目的是验证系统是否满足了需求规格的定义，找出与需求规格不符或与之矛盾的地方 ，进行改正。
；
验收测试：验收测试是在软件产品完成了单元测试、集成测试和系统测试之后，产品发布之前所进行的最后一次软件测试活动，也称为交付测试。
通常由业务专家或用户进行，以确认产品能真正符合用户业务上的需要。
1.3 黑盒测试方法
1）等价类划分
划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.
因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不 同的情况:有效等价类和无效等价类
2）边界值分析法
边界值分析方法是对等价类划分方法的补充。测试工作经验告诉我,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测 试用例,可以查出更多的错误.
使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据, 而不是选取等价类中的典型值或任意值作为测试数据.
3）错误猜测法
基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方 法. 错误推测方法的基本思想:
列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误.以前产品测试中曾经发现的错误等, 这些就是经验的总结. 还有, 输入数据和输出数据为 0 的情况. 输入表格为空格或输入表格只有一行.
这些都是容易发生错误的情况. 可选择这些情况下 的例子作为测试用例.
4）因果图方法
前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件 之间的联系, 相互组合等.考虑输入条件之间的相互组合,可能会产生一些新的情况. 但要 检查输入条件的组合不是一件容易的事情,
即使把所有输入条件划分成等价类,他们之间的 组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个
动作的形式来考虑设计测试用例. 这就需要利用因果图（逻辑模型）. 因果图方法最终生成 的就是判定表.
它适合于检查程序输入条件的各种组合情况.
5）正交表分析法
有时候，可能因为大量的参数的组合而引起测试用例数量上的激增，同时，这些测试用例并没有明显的优先级上的差距，而测试人员又无法完成这么多数量的测试，就可以通过正交表来进行缩减一些用例，从而达到尽量少的用例覆盖尽量大的范围的可能性。
对于基本的验证功能，以及二次集成引起的缺陷，一般都能找出来；但是更深的缺陷，更复杂的缺陷，还是无能为力的；
6）场景分析方法
指根据用户场景来模拟用户的操作步骤，这个比较类似因果图，但是可能执行的深度和可行性更好。
7）状态图法
通过输入条件和系统需求说明得到被测系统的所有状态，通过输入条件和状态得出输出条 件；通过输入条件、输出条件和状态得出被测系统的测试用例。
8）大纲法
大纲法是一种着眼于需求的方法，为了列出各种测试条件，就将需求转换为大纲的形式。大纲表示为树状结构，在根和每个叶子结点之间存在唯一的路径。大纲中的每条路径定义了一个特定的输入条件集合，用于定义测试用例。树中叶子的数目或大纲中的路径给出了测试所 有功能所需测试用例的大致数量。
1.4 白盒测试方法
白盒测试方法有 语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖。
1.语句覆盖：每条语句至少执行一次。
2.判定覆盖：每个判定的每个分支至少执行一次。
3.条件覆盖：每个判定的每个条件应取到各种可能的值。
4.判定/条件覆盖：同时满足判定覆盖条件覆盖。
5.条件组合覆盖：每个判定中各条件的每一种组合至少出现一次。
6.路径覆盖：使程序中每一条可能的路径至少执行一次。
白盒测试关注重点：
1、单元接口。
2、局部数据结构。
3、独立路径。
4、出错处理。
5、边界条件
1.5 单元测试策略
单元测试这快目前还是开发自测和开发团队之间互测的多，该部分有印象即可！。
单元的常见错误一般出现在以下五个方面，因此这五个方面是单元测试应该关注的重点。
（1）模块接口测试：
模块接口测试是单元测试的基础。只有在数据能正确流入、流出模块的前提下，其他测试才有意义。模块接口测试也是集成测试的重点，这里进行的测试主要是为后面打好基础。测试接口正确与否应该考虑下列因素：
-输入的实际参数与形式参数的个数是否相同；
-输入的实际参数与形式参数的属性是否匹配；
-输入的实际参数与形式参数的量纲是否一致；
-调用其他模块时所给实际参数的个数是否与被调模块的形参个数相同；
-调用其他模块时所给实际参数的属性是否与被调模块的形参属性匹配；
-调用其他模块时所给实际参数的量纲是否与被调模块的形参量纲一致；
-调用预定义函数时所用参数的个数、属性和次序是否正确；
-是否存在与当前入口点无关的参数引用；
-是否修改了只读型参数；
-对全程变量的定义各模块是否一致；
-是否把某些约束作为参数传递。
如果模块功能包括外部输入输出，还应该考虑下列因素：
-文件属性是否正确；
-OPEN/CLOSE语句是否正确；
-格式说明与输入输出语句是否匹配；
-缓冲区大小与记录长度是否匹配；
-文件使用前是否已经打开；
-是否处理了文件尾；
-是否处理了输入/输出错误；
-输出信息中是否有文字性错误。
-局部数据结构测试；
-边界条件测试；
-模块中所有独立执行通路测试；
（2）局部数据结构测试：
检查局部数据结构是为了保证临时存储在模块内的数据在程序执行过程中完整、正确，局部功能是整个功能运行的基础。重点是一些函数是否正确执行，内部是否运行正确。局部数据结构往往是错误的根源，应仔细设计测试用例，力求发现下面几类错误：
-不合适或不相容的类型说明；
-变量无初值；
-变量初始化或省缺值有错；
-不正确的变量名（拼错或不正确地截断）；
-出现上溢、下溢和地址异常。
（3）边界条件测试：
边界条件测试是单元测试中最重要的一项任务。众所周知，软件经常在边界上失效，采用边界值分析技术，针对边界值及其左、右设计测试用例，很有可能发现新的错误。边界条件测试是一项基础测试，也是后面系统测试中的功能测试的重点，边界测试执行的较好，可以大大提高程序健壮性。
（4）模块中所有独立路径测试：
在模块中应对每一条独立执行路径进行测试，单元测试的基本任务是保证模块中每条语句至少执行一次。测试目的主要是为了发现因错误计算、不正确的比较和不适当的控制流造成的错误。具体做法就是程序员逐条调试语句。常见的错误包括：
-误解或用错了算符优先级；
-混合类型运算；
-变量初值错；
-精度不够；
-表达式符号错。
-比较判断与控制流常常紧密相关，测试时注意下列错误：
-不同数据类型的对象之间进行比较；
-错误地使用逻辑运算符或优先级；
-因计算机表示的局限性，期望理论上相等而实际上不相等的两个量相等；
-比较运算或变量出错；
-循环终止条件或不可能出现；
-迭代发散时不能退出；
-错误地修改了循环变量。
（5）模块的各条错误处理通路测试：
程序在遇到异常情况时不应该退出，好的程序应能预见各种出错条件，并预设各种出错处理通路。如果用户不按照正常操作，程序就退出或者停止工作，实际上也是一种缺陷，因此单元测试要测试各种错误处理路径。一般这种测试着重检查下列问题：
-输出的出错信息难以理解；
-记录的错误与实际遇到的错误不相符；
-在程序自定义的出错处理段运行之前，系统已介入；
-异常处理不当；
-错误陈述中未能提供足够的定位出错信息。
在单元测试时，由于单元本身不是一个独立的程序，一个完整的可运行的软件系统并没有构成，所以需要设置一些辅助测试单元，辅助测试单元有两种，一种是驱动单元，另外一种是桩单元。
1、驱动单元（Driver）:
用来模拟被测单元的上层单元，相当于被测函数的主函数，如main函数。所以驱动单元主要完成以下4个步骤：
（1）接受测试数据，包含测试用例输入和预期输出；
（2）把测试用例输入传送给被测单元，驱动被测单元测试；
（3）将被测单元的实际输出和预期输出进行比较，得到测试结果；
（4）将测试结果输出到指定位置。
2、桩单元（Stub）：用来代替被测单元工作过程中调用的子单元。
桩单元模拟的单元可能是自定义函数：这些自定义函数可能尚未编写完成，为了测试被测单元，需要构造桩单元来代替它们，可能存在错误，会影响测试结果，所以需要构造正确无误的桩单元来达到隔离的目的。
驱动单元和桩单元都是额外的开销，虽然在单元测试的时候必须写，但是并不需要作为最终的产品提供给客户。
单元测试策略
一般的单元执行策略有三种：孤立的单元测试策略（Isolation Unit Testing），自顶向下的单元测试策略（Top Down
Unit Testing）和自底向上的单元测试策略（Bottom Up Unit
Testing）。需要注意的是：在集成测试中也有自顶向下和自底向上的测试策略，但是测试对象不同。
1、孤立的单元测试策略（Isolation Unit Testing）
方法：
不考虑每个模块与其它模块之间的关系，为每个模块设计桩模块和驱动模块，每个模块进行独立的单元测试。优点：
这个方法比较简单，最容易操作，可以达到很高的结构覆盖率，可以并行开展，该方法是纯粹的单元测试。
缺点：桩函数和驱动函数工作量很大，效率低。
2、自顶向下的单元测试策略（Top Down Unit Testing）
方法：
先对最顶层的单元进行测试，把顶层所调用的单元做成桩模块，其次对第二层进行测试，使用上面已经测试过的单元做驱动模块，以此类推，直到测试完所有模块。优点：
可以节省驱动函数的开发工作，效率高。缺点：
随着被测单元一个一个被加入，测试过程将变得越来越复杂，并且开发和维护的成本将增加。
3、自底向上的单元测试策略（Bottom Up Unit Testing）
方法：
先对最底层的模块进行单元测试，将模拟调用该模块的模块设置为驱动模块，然后再对上面一层做单元测试，用下面已经测试好的模块做桩模块，以此类推，直到测试完所有模块。
优点：
可以节省桩函数的开发工作量，测试效率较高。缺点：
不是纯粹的单元测试，底层函数的测试质量对上层函数的测试将产生很大影响。
1.6 集成测试策略
集成测试有十种策略:
(1)大爆炸集成
(2)自顶向下集成
(3)自底向上集成
(4)三明治集成
(5)分层集成
(6)基干集成
(7)基于功能的集成
(8)基于消息的集成
(9)基于风险的集成
(10)基于进度的集成.
集成测试主要内容有五种
（1）在把各个模块连接起来的时候，穿越模块接口的数据是否会丢失；
（2）一个模块的功能是否会对另一个模块的功能产生不利的影响；
（3）各个子功能组合起来，能否达到预期要求的父功能；
（4）全局数据结构是否有问题；
（5）单个模块的误差累积起来，是否会放大，从而达到不能接受的程度。
1.7 系统测试策略
针对集成好的软件系统，作为整个计算机系统的一个元素,与计算机硬件外设\某些支持软件\数据和人员等其他系统元素结合在一起,要在实际的运行环境中,对计算机系统进行一系列的集成测试和确认测试.
在企业中，可以分为以下几种
功能测试；性能评测；负载测试；强度测试；容量测试；安全性和访问控制测试；故障转移和恢复测试；配置测试；安装测试；加密测试；可用性测试；版本验证测试；文档测试；数据和数据库完整性测试；用户界面测试；
1.8 验收测试策略
验收测试是最后一个阶段的测试操作，在软件产品投入正式运行前的所要进行的测试工作。和系统测试相比而言，验收测试与之的区别就只是测试人员不同，验收测试则是由用户来执行这一操作的。
验收测试的主要目标是为向用户展示所开发出来的软件符合预定的要求和有关标准，并验证软件实际工作的有效性和可靠性，确保用户能用该软件顺利完成既定的任务和功能。通过了验收测试，该产品就可进行发布。
1.9 α和β测试
作为验收测试的补充。在实际交付给用户之后，开发人员是无法预测该软件用户在实际运用过程中是如何使用该程序的，所以从用户的角度出发，测试人员还应进行Alpha测试或Beta测试这两种情形的测试。
Alpha测试是在软件开发环境下由用户进行的测试，或者模拟实际操作环境进而进行的测试。Alpha测试主要是对软件产品的功能、局域化、界面、可使用性以及性能等等方面进行评价。
Beta测试是在实际环境中由多个用户对其进行测试，并将在测试过程中发现的错误有效反馈给软件开发者。所以在测试过程中用户必须定期将所遇到的问题反馈给开发者
------------分界线-------------以下是一些常用测试方法
1.10 兼容性测试策略
兼容测试主要是检查软件在不同的硬件平台、软件平台上是否可以正常的运行，即是通常说的软件的可移植性。
兼容的类型，如果细分的话，有平台的兼容，网络兼容，数据库兼容，以及数据格式的兼容。
兼容测试的重点是，对兼容环境的分析。通常，是在运行软件的环境不是很确定的情况下，才需要做兼容。根据软件运行的需要，或者根据需求文档，一般都能够得出用户会在什么环境下使用该软件，把这些环境整理成表单，就得出做兼容测试的兼容环境了。
1.11 强度（健壮性）测试策略
强度测试是为了确定系统在最差工作环境的工作能力,也可能是用于验证在标准工作压力下的各种资源的最下限指标。
它和压力测试的目标恰好相反。压力测试是在标准工作环境下,不断增加系统负荷,最终测试出该系统能力达到的最大负荷(稳定和峰值),而强度测试则是在非标准工作环境下,甚至不断人为降低系统工作环境所需要的资源,如网络带宽,系统内存,数据锁等等,以测试系统在资源不足的情况下的工作状态,通过强度测试,可以确定本系统正常工作的最差环境.
强度测试和压力测试的测试指标相近,大多都是与时间相关的指标,如并发量(吞吐量),延迟(最大\最小\平均)以及顺序指标等
强度测试需要对系统的结构熟悉,针对系统的特征设计强度测试的方法
1.12 压力测试策略
压力测试是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。通过不断增加用户数和访问量，测试系统的极限以及在极限情况下系统的性能。
1.13 性能测试（强度+压力）
常见指标：
吞吐量：每秒钟系统能够处理的请求数、任务数。
TPS：并发数/平均响应时间
并发数： 系统同时处理的request/事务数
响应时间：服务处理一个请求或一个任务的耗时。错误率：一批请求中结果出错的请求所占比例。
内部指标：CPU、内存、服务器负载、网络、磁盘IO
性能测试这块太大了，看了很多大家的讨论，还是觉得这方面得有一个完整的团队才可以实现有效的性能测试。
性能测试团队中要有性能测试专家、性能测试工程师、数据库专家、OS专家、全栈。
写得很棒的性能测试文章
1.14 兼容性测试策略
（1）测试软件是否能在不同的操作系统平台上兼容；
（2）测试软件是否能在同一操作系统平台的不同版本上兼容；
（3）软件本身能否向前或者向后兼容；
（4）测试软件能否与其它相关的软件兼容；
（5）数据兼容性测试，主要是指数据能否共享；
1.15 测试用例设计方法
白盒测试：
语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖
黑盒测试：
边界值分析法 等价类划分 错误猜测法 因果图法 状态图法 测试大纲法 随机测试 场景法
1.15 测试用例设计经典面试题——电梯，杯子，笔，桌子，洗衣机
测试用例设计经典面试题——电梯，杯子，笔，桌子，洗衣机
1.16 冒烟测试用例
冒烟测试的主要目的是保证整体流程的畅通，在每次大版本的提测前后都需要进行一遍，并且最终的验收测试也可以参考着冒烟测试来进行。
因此冒烟测试用例的设计是非常重要的，主要的策略是对于整体流程的全覆盖，并且主要由正常情况来组成；
对于一些有特殊要求和特殊功能的模块，需要进行一些异常情况的覆盖。
二、流程类
2.1 软件和测试生命周期
软件生命周期
计划-》需求分析-》设计-》程序编写-》测试-》运行/维护
测试生命周期
测试计划-》需求分析-》测试用例-》测试用例执行-》提交bug-》回归测试
缺陷生命周期
发现BUG–>提交BUG–>指派BUG–>研发确认BUG–>研发去修复BUG–>回归验证BUG–>是否通过验证–>关闭BUG
2.2 软件开发模型
- 瀑布模型
瀑布模型中至关重要的一点是只有当一个阶段的文档已经编制好并获得SQA小组的认可才可以进入下一个阶段。这样，瀑布模型通过强制性的要求提供规约文档来确保每个阶段都能很好的完成任务。
因此，瀑布模型是一个全流程的文档驱动模型，非常复杂，需要简化。
- 快速原型模型
据客户的需要在很短的时间内解决用户最迫切需要，完成一个可以演示的产品。这个产品只是实现部分的功能（最重要的）
- 螺旋模型
将瀑布模型和快速原型模型结合，适合大型系统。
螺旋模型沿着螺线进行若干次迭代，图中的四个象限代表了以下活动：
（1） 制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件；
（2） 风险分析：分析评估所选方案，考虑如何识别和消除风险；
（3） 实施工程：实施软件开发和验证；
（4） 客户评估：评价开发工作，提出修正建议，制定下一步计划。
强调风险分析
更加适合内部超大系统开发
- 迭代式模型
在迭代式生命周期中，您需要根据主要风险列表选择要在迭代中开发的新的增量内容。每次迭代完成时都会生成一个经过测试的可执行文件，这样就可以核实是否已经降低了目标风险。"
- 敏捷开发
强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重做为软件开发中人的作用。
2.3 测试模型
1.V模型
测试在开发之后，发现错误时间晚，出错后回归测试量大、修复代价大。
2.W模型
测试伴随整个开发周期，测试与开发同步进行，有利于尽早发现问题
测试投入相对较大
三、linux类
3.1列举常用的20个命令
3.1.1、cd
这是一个非常基本，也是大家经常需要使用的命令，它用于切换当前目录，它的参数是要切换到的目录的路径，可以是绝对路径，也可以是相对路径。
3.1.2、ls
这是一个非常有用的查看文件与目录的命令，list之意，它的参数非常多，下面就列出一些常用的参数吧，如下：
-l ：列出长数据串，包含文件的属性与权限数据等
-a ：列出全部的文件，连同隐藏文件（开头为.的文件）一起列出来（常用）
-d ：仅列出目录本身，而不是列出目录的文件数据
-h ：将文件容量以较易读的方式（GB，kB等）列出来
-R ：连同子目录的内容一起列出（递归列出），等于该目录下的所有文件都会显示出来
注：这些参数也可以组合使用，下面举两个例子：
3.1.3、grep
该命令常用于分析一行的信息，若当中有我们所需要的信息，就将该行显示出来，该命令通常与管道命令一起使用，用于对一些命令的输出进行筛选加工等等，它的简单语法为
grep [-acinv] [–color=auto] ‘查找字符串’ filename
它的常用参数如下：
-a ：将binary文件以text文件的方式查找数据
-c ：计算找到‘查找字符串’的次数
-i ：忽略大小写的区别，即把大小写视为相同
-v ：反向选择，即显示出没有‘查找字符串’内容的那一行
例如：
取出文件/etc/man.config中包含MANPATH的行，并把找到的关键字加上颜色
grep --color=auto ‘MANPATH’ /etc/man.config
3.1.4、find
find是一个基于查找的功能非常强大的命令，相对而言，它的使用也相对较为复杂，参数也比较多，所以在这里将给把它们分类列出，它的基本语法如下：
find [PATH] [option] [action]
与时间有关的参数：
-mtime n : n为数字，意思为在n天之前的“一天内”被更改过的文件；
-mtime +n : 列出在n天之前（不含n天本身）被更改过的文件名；
-mtime -n : 列出在n天之内（含n天本身）被更改过的文件名；
-newer file : 列出比file还要新的文件名
例如：
find /root -mtime 0 # 在当前目录下查找今天之内有改动的文件
与用户或用户组名有关的参数：
-user name : 列出文件所有者为name的文件
-group name : 列出文件所属用户组为name的文件
-uid n : 列出文件所有者为用户ID为n的文件
-gid n : 列出文件所属用户组为用户组ID为n的文件
例如：
find /home/ljianhui -user ljianhui # 在目录/home/ljianhui中找出所有者为ljianhui的文件
与文件权限及名称有关的参数：
-name filename ：找出文件名为filename的文件
-size [±]SIZE ：找出比SIZE还要大（+）或小（-）的文件
-tpye TYPE ：查找文件的类型为TYPE的文件，TYPE的值主要有：一般文件（f)、设备文件（b、c）、
目录（d）、连接文件（l）、socket（s）、FIFO管道文件（p）；
-perm mode ：查找文件权限刚好等于mode的文件，mode用数字表示，如0755；
-perm -mode ：查找文件权限必须要全部包括mode权限的文件，mode用数字表示
-perm +mode ：查找文件权限包含任一mode的权限的文件，mode用数字表示
例如：
find / -name passwd # 查找文件名为passwd的文件
find . -perm 0755 # 查找当前目录中文件权限的0755的文件
find . -size +12k # 查找当前目录中大于12KB的文件，注意c表示byte
3.1.5、cp
该命令用于复制文件，copy之意，它还可以把多个文件一次性地复制到一个目录下， 它的常用参数如下：
-a ：将文件的特性一起复制
-p ：连同文件的属性一起复制，而非使用默认方式，与-a相似，常用于备份
-i ：若目标文件已经存在时，在覆盖时会先询问操作的进行
-r ：递归持续复制，用于目录的复制行为
-u ：目标文件与源文件有差异时才会复制
例如 ：
cp -a file1 file2 #连同文件的所有特性把文件file1复制成文件file2
cp file1 file2 file3 dir #把文件file1、file2、file3复制到目录dir中
3.1.6、mv
该命令用于移动文件、目录或更名，move之意，它的常用参数如下：
-f ：force强制的意思，如果目标文件已经存在，不会询问而直接覆盖
-i ：若目标文件已经存在，就会询问是否覆盖
-u ：若目标文件已经存在，且比目标文件新，才会更新
注：该命令可以把一个文件或多个文件一次移动一个文件夹中，但是最后一个目标文件一定要是“目录”。
例如：
mv file1 file2 file3 dir # 把文件file1、file2、file3移动到目录dir中
mv file1 file2 # 把文件file1重命名为file2
3.1.7、rm
该命令用于删除文件或目录，remove之间，它的常用参数如下：
-f ：就是force的意思，忽略不存在的文件，不会出现警告消息
-i ：互动模式，在删除前会询问用户是否操作
-r ：递归删除，最常用于目录删除，它是一个非常危险的参数
例如：
rm -i file # 删除文件file，在删除之前会询问是否进行该操作
rm -fr dir # 强制删除目录dir中的所有文件
3.1.8、ps
该命令用于将某个时间点的进程运行情况选取下来并输出，process之意，它的常用参数如下：
-A ：所有的进程均显示出来
-a ：不与terminal有关的所有进程
-u ：有效用户的相关进程
-x ：一般与a参数一起使用，可列出较完整的信息
-l ：较长，较详细地将PID的信息列出
其实我们只要记住ps一般使用的命令参数搭配即可，它们并不多，如下：
ps aux # 查看系统所有的进程数据
ps ax # 查看不与terminal有关的所有进程
ps -lA # 查看系统所有的进程数据
ps axjf # 查看连同一部分进程树状态
3.1.9、kill命令
该命令用于向某个工作（%jobnumber）或者是某个PID（数字）传送一个信号，它通常与ps和jobs命令一起使用，它的基本语法如下：
kill -signal PID
signal的常用参数如下：
注：最前面的数字为信号的代号，使用时可以用代号代替相应的信号。
1：SIGHUP，启动被终止的进程
2：SIGINT，相当于输入ctrl+c，中断一个程序的进行
9：SIGKILL，强制中断一个进程的进行
15：SIGTERM，以正常的结束进程方式来终止进程
17：SIGSTOP，相当于输入ctrl+z，暂停一个进程的进行
例如：
以正常的结束进程方式来终于第一个后台工作，可用jobs命令查看后台中的第一个工作进程
kill -SIGTERM %1
重新改动进程ID为PID的进程，PID可用ps命令通过管道命令加上grep命令进行筛选获得
kill -SIGHUP PID
3.1.10、killall
该命令用于向一个命令启动的进程发送一个信号，它的一般语法如下：
killall [-iIe] [command name]
它的参数如下：
[plain] view plain copy
-i ：交互式的意思，若需要删除时，会询问用户
-e ：表示后面接的command name要一致，但command name不能超过15个字符
-I ：命令名称忽略大小写
例如：
killall -SIGHUP syslogd # 重新启动syslogd
3.1.11、file
该命令用于判断接在file命令后的文件的基本数据，因为在Linux下文件的类型并不是以后缀为分的，所以这个命令对我们来说就很有用了，它的用法非常简单，基本语法如下：
file filename
例如：
file ./test
3.1.12、tar命令
该命令用于对文件进行打包，默认情况并不会压缩，如果指定了相应的参数，它还会调用相应的压缩程序（如gzip和bzip等）进行压缩和解压。它的常用参数如下：
-c ：新建打包文件
-t ：查看打包文件的内容含有哪些文件名
-x ：解打包或解压缩的功能，可以搭配-C（大写）指定解压的目录，注意-c,-t,-x不能同时出现在同一条命令中
-j ：通过bzip2的支持进行压缩/解压缩
-z ：通过gzip的支持进行压缩/解压缩
-v ：在压缩/解压缩过程中，将正在处理的文件名显示出来
-f filename ：filename为要处理的文件
-C dir ：指定压缩/解压缩的目录dir
上面的解说可以已经让你晕过去了，但是通常我们只需要记住下面三条命令即可：
压缩：tar -jcv -f filename.tar.bz2 要被处理的文件或目录名称
查询：tar -jtv -f filename.tar.bz2
解压：tar -jxv -f filename.tar.bz2 -C 欲解压缩的目录
注：文件名并不定要以后缀tar.bz2结尾，这里主要是为了说明使用的压缩程序为bzip2
3.1.13、cat命令
该命令用于查看文本文件的内容，后接要查看的文件名，通常可用管道与more和less一起使用，从而可以一页页地查看数据。例如：
cat text | less # 查看text文件中的内容
注：这条命令也可以使用less(从后往前翻页)或者more来代替
3.1.14、chgrp命令
该命令用于改变文件所属用户组，它的使用非常简单，它的基本用法如下：
chgrp [-R] dirname/filename
-R ：进行递归的持续对所有文件和子目录更改
例如：
chgrp users -R ./dir # 递归地把dir目录下中的所有文件和子目录下所有文件的用户组修改为users
3.1.15、chown命令
该命令用于改变文件的所有者，与chgrp命令的使用方法相同，只是修改的文件属性不同，不再详述。
3.1.16、chmod命令
该命令用于改变文件的权限，一般的用法如下：
chmod [-R] xyz 文件或目录
-R：进行递归的持续更改，即连同子目录下的所有文件都会更改
同时，chmod还可以使用u（user）、g（group）、o（other）、a（all）和+（加入）、-（删除）、=（设置）跟rwx搭配来对文件的权限进行更改。
权限分为写，读，可执行，对应权重421，所以7是代表所有权限
例如：
chmod 755 file # 把file的文件权限改变为-rxwr-xr-x
chmod g+w file # 向file的文件权限中加入用户组可写权限
3.1.18、vim命令
该命令主要用于文本编辑，它接一个或多个文件名作为参数，如果文件存在就打开，如果文件不存在就以该文件名创建一个文件。vim是一个非常好用的文本编辑器，它里面有很多非常好用的命令，在这里不再多说。你可以从这里下载 vim常用操作 的详细说明。
3.1.19、gcc命令
对于一个用Linux开发C程序的人来说，这个命令就非常重要了，它用于把C语言的源程序文件，编译成可执行程序，由于g++的很多参数跟它非常相似，所以这里只介绍gcc的参数，它的常用参数如下：
-o ：output之意，用于指定生成一个可执行文件的文件名
-c ：用于把源文件生成目标文件（.o)，并阻止编译器创建一个完整的程序
-I ：增加编译时搜索头文件的路径
-L ：增加编译时搜索静态连接库的路径
-S ：把源文件生成汇编代码文件
-lm：表示标准库的目录中名为libm.a的函数库
-lpthread ：连接NPTL实现的线程库
-std= ：用于指定把使用的C语言的版本
3.1.20、time命令
该命令用于测算一个命令（即程序）的执行时间。它的使用非常简单，就像平时输入命令一样，不过在命令的前面加入一个time即可，
例如：
time ./process
time ps aux
在程序或命令运行结束后，在最后输出了三个时间，它们分别是：
user：用户CPU时间，命令执行完成花费的用户CPU时间，即命令在用户态中执行时间总和；
system：系统CPU时间，命令执行完成花费的系统CPU时间，即命令在核心态中执行时间总和；
real：实际时间，从command命令行开始执行到运行终止的消逝时间；
四、常用软件和框架
postman，jmeter，docker，robotframework
五、计算机基础类
这一块内容非常多，需要的同学可以参考github上的内容，整理了面试常见的八股文，非常值得一看！
https://github.com/CyC2018
六、持续集成、敏捷等新兴类
等待补充
总结
想把这篇文章写得好一点全一点，因此写这篇文章的周期会长一些，可能陆陆续续要写上一个月左右~
引用
1、csdn部分
软件测试笔试面试题目完全汇总-sunny王维
软件测试常考面试题-软件测试面试宝典-MJ813
20个linux常用命令