这些是我觉得会问道，但不限于所有的，我列出一些，但并不是所有，软件测试是一个漫长的过程，这需要我们有耐心，和细心，还有一个好学习和认真的态度去进行，小伙伴们可以通过背诵然后结合自己的陈述去进行完善和结果专业知识去进行解答
具体需求：
有一个登录页面，有一个账号和一个密码输入框, 一个提交按钮。此题的考察目的：
测试需求分析完成后，开始用例设计，主要可以从以下几个方面考虑： 功能测试(Function Test)
1、输入正确的账号和密码，点击提交按钮，验证是否能正确登录。（正常输入）
2、输入错误的账号或者密码, 验证登录会失败，并且提示相应的错误信息。（错误校验）
3、登录成功后能否跳转到正确的页面（低）
4、账号和密码，如果太短或者太长，应该怎么处理（安全性，密码太短时是否有提示）
5、账号和密码，中有特殊字符（比如空格），和其他非英文的情况（是否做了过滤）
6、记住账号的功能
7、登录失败后，不能记录密码的功能
8、账号和密码前后有空格的处理
9、密码是否加密显示（星号圆点等）
10、牵扯到验证码的，还要考虑文字是否扭曲过度导致辨认难度大，考虑颜色（色盲使用者），刷新或换一个按钮是否好用
11、登录页面中的注册、忘记密码，登出用另一帐号登录等链接是否正确
12、输入密码的时候，大写键盘开启的时候要有提示信息。
13、什么都不输入，点击提交按钮，看提示信息。（非空检查） 界面测试(UI Test)
需要完整版面试题文档，可以加入最下方小卡片！！！
1、布局是否合理，2 个Testbox 和一个按钮是否对齐
2、Testbox 和按钮的长度，高度是否复合要求
3、界面的设计风格是否与 UI 的设计风格统一
4、界面中的文字简洁易懂，没有错别字。性能测试(Performance Test)
1、打开登录页面，需要几秒
2 、输入正确的账号和密码后，登录成功跳转到新页面，不超过 5 秒安全性测试(Security Test)
1、登录成功后生成的Cookie 是否有HttpOnly(降低脚本盗取风险)
2、账号和密码是否通过加密的方式，发送给 Web 服务器
3、账号和密码的验证，应该是用服务器端验证，而不能单单是在客户端用javaScript 验证
4、账号和密码的输入框，应该屏蔽SQL 注入攻击
5、账号和密码的的输入框，应该禁止输入脚本（防止 XSS 攻击）
6、错误登录的次数限制（防止暴力破解）
7、考虑是否支持多用户在同一机器上登录；
8、考虑一用户在多台机器上登录可用性测试(Usability Test)
1、是否可以全用键盘操作，是否有快捷键
2、输入账号，密码后按回车，是否可以登录
3、输入框是否可以以 Tab 键切换兼容性测试（Compatibility Test）
1、主流的浏览器下能否显示正常已经功能正常（IE6~11, FireFox, Chrome, Safari 等 ）
2、不同的平台是否能正常工作，比如 Windows, Mac
3、移动设备上是否正常工作，比如iPhone, Android
4、不同的分辨率
本地化测试 （Localization Test）
不同语言环境下，页面的显示是否正确。软件辅助性测试 （Accessibility Test）
软件辅助功能测试是指测试软件是否向残疾用户提供足够的辅助功能1、高对比度下能否显示正常（视力不好的人使用）
（有点多具体大概能说到相应的点就可以了）
首先区分什么阶段，比如项目集成阶段，我们采用黑白盒两种方法相结合，做接口测试。
如果是系统测试阶段，一般采用黑盒测试
测试测试用例时：
不管是传统行业的web测试，还是APP测试，都离不开测试的基础知识。即不管怎么变，测试的原理依然会融入在这两者当中。
Web测试和APP测试相同点
不同点
相对于web测试，手机软件测试，除了要考虑基本的功能测试、性能等，还要考虑手机本身固有的属性特征。所以对比web测试和手机测试，手机测试过程中还需要注意如下几个方面特性：
手机作为通信工具，来电、去电、接收短信等操作都会对APP应用程序产生影响，所以APP测试第一个要考虑的属性特征是：中断测试。
1）中断测试又分为中断、新任务中断以及意外中断等几种情况，主要从以下几个方面进行验证：
2）手机用户对app产品的安装卸载操作：从上一个版本/上两个版本直接升级到最新版本。
全新安装新版本
新版本覆盖旧版本安装
卸载旧版本，安装新版本
卸载新版本，安装新版本
3）web自动化测试使用的工具较常用的是selenium，而android手机自动化测试工具比较常用的是monkey、appuim。 兼容性测试，web的比较常用考虑到是不同分辨率的电脑、不同浏览器。app考虑的是不同手机型号、厂家、分辨率和屏幕大小等。（这个本人补充一下，还有网络，兼容，分辨率，屏幕，和操作系统的不一致）
首先，我不会和开发人员进行争执我会将
将问题提交到缺陷管理库里面进行备案。然后，要获取判断的依据和标准：
根据需求说明书、产品说明、设计文档等，确认实际结果是否与计划有不一致的地方，提供缺陷是否确认的直接依据；
如果没有文档依据，可以根据类似软件的一般特性来说明是否存在不一致的地方，来确认是否是缺陷；
根据用户的一般使用习惯，来确认是否是缺陷；
与设计人员、开发人员和客户代表等相关人员探讨，确认是否是缺陷；
合理的论述，向测试经理说明自己的判断的理由，注意客观、严谨，不参杂个人情绪。
等待测试经理做出最终决定，如果仍然存在争议，可以通过公司政策所提供的渠道，向上级反映，并有上级做出决定。
应当把“尽早地和不断地进行软件测试”作为软件开发者的座右铭。
测试用例应由测试输入数据和对应的预期输出结果这两部分组成。
程序员应避免检查自己的程序。
在设计测试用例时，应包括合理的输入条件和不合理的输入条件。
软件测试的原则
充分注意测试中的群集现象。 经验表明，测试后程序中残存的错误数目与该程序中已发现的错误数目成正比。
严格执行测试计划，排除测试的随意性。
应当对每一个测试结果做全面检查。
妥善保存测试计划，测试用例，出错统计和最终分析报告，为维护提供方便。
（补充，软件测试证明软件存在缺陷，某些测试依赖特殊的环境，杀虫剂现象）
测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。
测试用例的基本元素： 测试编号，用例级别，测试环境，预置条件，输入数据，操作步骤，预期结果，实际结果等。
那么接下来又会详细问道
首先根据需求文档、概要设计、测试计划、测试方案细分出各功能模块的测试项
再根据各测试项，按照概要设计、详细设计以及测试方案中测试的覆盖率细分出测试子项
最后按照测试子项、根据测试用例的设计方法（因果图、边界值、等价类等的设计方法）书写测试用例。注意
选用适合的用例管理工具（如word，excel）
用例一定要及时更新（补充新的想法，删除过时的需求）
做好用例分级
做好用例评审，写用例之前可以征询相关人员的意见，如果评审通过可以参考其执行测试，如果未通过， 需要继续修改直到通过为止。
可以考虑结对编写，这个是不错的主意。
要全面，包括功能、性能、兼容性、安全性、易用性、容错性等等
注意把握适当的颗粒度
黑盒测试：把测试对象当成一个黑盒子，测试人员完全不考虑逻辑结构和内部特性， 只依据程式的需求说明书来检查程式的功能是否满足它的功能说明。
白盒测试：把测试对象当成一个透明的盒子，允许测试人员利用程序内部逻辑结构及 相关信息，设计或选择测试用例，对程式所有逻辑路径进行测试。
单元测试：白盒测试的一种，对软件设计中的单元模块进行测试。
集成测试：在单元测试的基础上，对单元模块之间的连接和组装进行测试。系统测试：在所有都考虑的情况下，对系统进行测试。
验收测试：由客户方或第三方为主导进行的确认软件满足需求的测试。包括阿尔法测试，bata测试和正式验收
（白盒测试又叫结构测试，逻辑驱动测试，黑盒测试又叫功能测试，和数据驱动测试）
那么根据白灰黑面试官又会让你对比一下他们的优缺点
黑盒测试的优点有：
比较简单，不需要了解程序内部的代码及实现；
与软件的内部实现无关；
从用户角度出发，能很容易的知道用户会用到哪些功能，会遇到哪些问题；
基于软件开发文档，所以也能知道软件实现了文档中的哪些功能；
在做软件自动化测试时较为方便。
黑盒测试的缺点有：
1. 不可能覆盖所有的代码，覆盖率较低，大概只能达到总代码量的 30%；
2. 自动化测试的复用性较低。
白盒测试的优点有：
帮助软件测试人员增大代码的覆盖率，提高代码的质量，发现代码中隐藏的问题。
白盒测试的缺点有：
程序运行会有很多不同的路径，不可能测试所有的运行路径；测试基于代码，只能测试开发人员做的对不对，而不能知道设计的正确与否，可能会漏掉一些功能需求；系统庞大时，测试开销会非常大。（总的来说黑盒测试不需要看内部代码，不需要了解内部逻辑，只要知道输入的数据和输出结果是是否正确，但覆盖率比较低，白盒测试就是需要看代码，来验证内部的逻辑和内部特性）
那么就会有黑盒测试的测试方法和白盒测试的测试方法
一般情况下，黑盒测试使用等价类边界值，因果图判定表，正交试验和错误推断法
白盒测试就是有逻辑覆盖，路径覆盖，逻辑覆盖有语句，分支，判定，判定组合，条件，条件组合等
大型通用软件，在正式发布前，通常需要执行 Alpha 和 Beta 测试，目的是从实际终端用户的使用角度，对软件的功能和性能进行测试，以发现可能只有最终用户才能发现的错误。
Alpha 测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试，Alpha 测试不能由程序员或测试员完成。Alpha 测试发现的错误，可以在测试现场立刻反馈给开发人员，由开发人员及时分析和处理。目的是评价软件产品的功能、可使用性、可靠性、性能和支持。尤其注重产品的界面和特色。Alpha 测试可以从软件产品编码结束之后开始，或在模块（子系统）测试完成后开始，也可以在确认测试过程中产品达到一定的稳定和可靠程度之后再开始。有关的手册（草稿）等应该在 Alpha 测试前准备好。
Beta 测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场，Beta 测试不能由程序员或测试员完成。因而，Beta 测试是在开发者无法控制的环境下进行的软件现场应用。在 Beta 测试中，由用户记下遇到的所有问题，包括真实的以及主管认定的，定期向开发者报告，开发者在综合用户的报告后， 做出修改，最后将软件产品交付给全体用户使用。Beta 测试着重于产品的支持性，包括文档、客户培训和支持产品的生产能力。只有当Alpha 测试达到一定的可靠程度后，才能开始Beta 测试。由于Beta 测试的主要目标是测试可支持性，所以Beta 测试应该尽可能由主持产品发行的人员来管理。
打包： tar -zcvf 打包文件名.tar.gz 需要打包的目录或文件
解包： tar –zxvf 包文件名.tar.gz
压缩：gzip -c 源文件 > 压缩文件名.gz
解压：gzip -d 源文件包
cd .. 进入上一级目录
cd ~ 进入用户主目录
cd - 进入上一次进入的路径
cat: 普通查看文件内容， cat –f 动态查看文件内容
less: 可随意查看，可设置行，查找等，可上下翻动，适合查看大文件，启动时是一页一页加载，这个和more是不一样的。
more: 也是查看大文件的一种方法，只能一页一页看，按回车或空格键翻页。并且只能往后看，不能往前翻页。More命令启动时就会加载整个文件
head 从头查看
tail 从尾查看
2.6.1 如何查看内存信息？
cat /proc/meminfo
2.6.2 如何查看CPU信息
cat /proc/cpuinfo
2.6.3 如何查看ip地址?
Ifconfig
2.6.4 如何查看进程？
ps –ef
2.10 如何关闭，打开，查看防火墙？
1.启动防火墙 systemctl start firewalld
2.禁用防火墙 systemctl stop firewalld
3.设置开机启动 systemctl enable firewalld
4.停止并禁用开机启动 sytemctl disable firewalld
Linux的权限分为可读r (4)，可写: w (2) 可执行：x (1)
修改文件权限 chmod :
修改文件时可以使用数字，或字母进行表示
修改文件群组权限: chgrp
修改文件所有者： chown关系型数据库是由多张能互相联接的二维行列表格组成的数据库
主关键字(primary key)是表中的一个或多个字段，它的值用于唯一地标识表中的某一条记录
外键表示了两个关系之间的相关联系。以另一个关系的外键作主关键字的表被称为主表，具有此外键的表被称为主表的从表。外键又称作外关键字
在关系数据库中，索引是一种单独的、物理的对数据库表中一列或多列的值进行排序的一种存储结构，它是某个表中一列或若干列值的集合和相应的指向表中物理标识这些值的数据页的逻辑指针清单
索引就是提高查询效率嘛
储存过程是一个可编程的函数，它在数据库中创建并保存。它可以有 SQL 语句和一些特殊的控制结构组成。当希望在不同的应用程序或平台上执行相同的函数，或者封装特定功能时，存储过程是非常有用的。数据库中的存储过程可以看做是对编程中面向对象方法的模拟。它允许控制数据的访问方式。存储过程通常有以下优点：
1、存储过程能实现较快的执行速度
2、存储过程允许标准组件是编程。
3、存储过程可以用流程控制语句编写，有很强的灵活性，可以完成复杂的判断和较复杂的运算。
4、存储过程可被作为一种安全机制来充分利用。
5、存储过程能够减少网络流量
1、原子性(Atomicity)：事务中的全部操作在数据库中是不可分割的，要么全部完成，要么均不执行。
2、一致性(Consistency)：几个并行执行的事务，其执行结果必须与按某一顺序串行执行的结果相一致。
3、隔离性(Isolation)：事务的执行不受其他事务的干扰，事务执行的中间结果对其他事务必须是透明的。
4、持久性(Durability)：对于任意已提交事务，系统必须保证该事务对数据库的改变不被丢失，即使数据库出现故障
1.读未提交（Read uncommitted）：
这种事务隔离级别下，select语句不加锁。
此时，可能读取到不一致的数据，即“读脏 ”。这是并发最高，一致性最差的隔离级别。
2.读已提交（Read committed）：
可避免 脏读 的发生。
在互联网大数据量，高并发量的场景下，几乎 不会使用 上述两种隔离级别。
3.可重复读（Repeatable read）：
MySql默认隔离级别。
可避免 脏读 、不可重复读 的发生。
4.串行化（Serializable ）：
可避免 脏读、不可重复读、幻读 的发生。
主要 MyISAM 与 InnoDB 两个引擎，其主要区别如下：InnoDB 支持事务，MyISAM 不支持，这一点是非常之重要。事务是一种高级的处理方式，如在一些列增删改中只要哪个出错还可以回滚还原，而 MyISAM 就不可以了；
MyISAM 适合查询以及插入为主的应用，InnoDB 适合频繁修改以及涉及到安全性较高的应用； InnoDB 支持外键，MyISAM 不支持；
MyISAM 是默认引擎，InnoDB 需要指定； InnoDB 不支持FULLTEXT 类型的索引；
InnoDB 中不保存表的行数，如 select count() from table 时，InnoDB；需要扫描一遍整个表来计算有多少行，但是 MyISAM 只要简单的读出保存好的行数即可。注意的是，当 count()语句包含 where 条件时 MyISAM 也需要扫描整个表；
对于自增长的字段，InnoDB 中必须包含只有该字段的索引，但是在MyISAM 表中可以和其他字段一起建立联合索引；清空整个表时，InnoDB 是一行一行的删除，效率非常慢。MyISAM 则会重建表； InnoDB 支持行锁（某些情况下还是锁整表，如 update table set a=1 where user like '%lee%'
还有视图啊触发器啊很多，不能全部列出，软件测试是一个偏向于文科的技术，所有我们要背很多很多，一些软件测试的基础理论，白灰黑，单元，集成，系统，验收测试分别是怎么进行的，还有他们的优缺点，还有测试模型VWH，一些BUG的bug但还有怎么提交一个高质量的BUG，缺陷的生命周期，软件的生命周期，缺陷报告单包含什么，测试用例包含什么，我们软件测试人员最重要的就是会使用各种测试方法和测试工具去编写和执行测试用例，测试用例不能乱写，要有覆盖性，而且要根据方法去进行编写，比如拿到一个项目可以先用场景法走一下基本的业务流程，然后因果图把条件之间有联系的进行覆盖，用等价类边界值做更加详细的覆盖，最后基于自己在测试里面的经验设计测试用例，测试用例里面有包含了那样元素，又没注意可以设计一个好的完整的测试用例，如果开发想创造世界，那么我们软件测试就是让世界变的更加的美好，在项目立项开始就开始去进行测试，从需求文档，评审，计划，报告都需要进行参与，更关注于公司的主体业务也客户的整体需求，满足客户的需求为主体！
下方这份完整的软件测试视频学习教程已经整理上传完成，朋友们如果需要可以自行免费领取【保证100%免费】
这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你！
我们学习必然是为了找到高薪的工作，下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料，并且有字节大佬给出了权威的解答，刷完这一套面试资料相信大家都能找到满意的工作。
