软件测试面试题集(含答案)

软件测试面试题集
一、Bug基本要素
缺陷ID，状态，类型，所属项目，所属模块，缺陷提交时间，缺陷提交人（检测者），严重程度，优先级别，缺陷描述信息，测试步骤，测试前置条件，测试数据，期望结果，实际结果。
注:Bug严重级别(Severity，Bug级别)：是指因缺陷引起的故障对软件产品的影响程度。
A- Crash 错误导致了死机、产品失败（“崩溃”）、系统悬挂无法操作；
比如：1.内存泄漏；2.严重的数值计算错误；3.系统容易崩溃；4.功能设计与需求严重不符；5.系统无法登陆；6.循坏报错，无法正常退出。
B- Major 系统的主要功能部分丧失、数据不能保存，系统的次要功能完全丧失。问题局限在本模块，导致模块功能失效或异常退出。如致命的错误声明，程序接口错误，数据库的表、业务规则、缺省值未加完整性等约束条件
C-Minor 次要功能没有完全实现但不影响使用。如提示信息不太准确，或用户界面差，操作时间长，模块功能部分失效等，打印内容、格式错误，删除操作未给出提示，数据库表中有过多的空字段等
D-Trivial 错误是表面化或微小的（提示信息不太准确友好、错别字、UI 布局或罕见故障等），对功能几乎没有影响，产品及属性仍可使用；
E-Nice to Have（建议）建设性的意见或建议。

二、http协议中get和post的区别？
1、get请求通过URL传递，post通过request body进行传递；
2、get只能进行url编码方式，但是post可以进行多种编码方式；
3、get只接受ASCll数据类型，但是post没有限制；
4、get因为参数包含在url地址上，所以并不安全；
5、get对参数的传递有有限制的，但是post没有；
6、get的请求参数会被完整的保留在浏览器的历史记录里面，但是post不会；
7、GET产生一个TCP数据包；POST产生两个TCP数据包。

三、http和https的区别？
1、安全性不同
http是超文本传输协议，它是明文传输的，如果有人截取服务器与浏览器之间的协议，就可以知道传输的信息了，https有一个ssl加密协议，所以相对来说https是安全的。
2、端口号不同
http的端口号是80；
https的端口号是443。
3、申请方式不同
http申请是免费的；
https因为是ca申请证书所以是收费的，一般很少有免费的。
4、连接方式不同
http的连接很简单，是无状态的；
https是由ssl+https协议构建的的可进行加密传输，身份认证的网络协议。

四、我现在有个程序，发现在Windows上运行得很慢，怎么判别是程序存在问题还是软硬件系统存在问题？
1、检查系统是否有中毒的特征；
2、检查软件/硬件的配置是否符合软件的推荐标准；
3、确认当前的系统是否是独立，即没有对外提供什么消耗CPU资源的服务；
4、如果是C/S或者B/S结构的软件，需要检查是不是因为与服务器的连接有问题，或者访问有问题造成的；
5、在系统没有任何负载的情况下，查看性能监视器，确认应用程序对CPU/内存的访问情况。

五、列表和元组的区分？
1、元组和列表都属于序列；
2、列表属于可变序列，它的元素可以随时修改或者删除，而元组属于不可变序列，其中的元素是不能修改的，除非整体重新赋值；
3、列表可以使用多种方法实现添加和修改列表元素，而元组没有办法，因为不能在元组中添加或修改元素，同样也不能删除元素；
4、列表可以使用切片方法访问和修改列表中的元素，元组也支持切片，但是它只支持通过切片访问元组中的元素，不支持修改；
5、元组比列表中的访问和处理速度更快，所以如果只需要对其中的元素进行访问，而不进行任何修改，建议使用元组；
6、列表不能作为字典类型中的键，而元组是可以的。

六、数据库常用聚合函数？
1、计算记录的总数
SELECT COUNT(字段名) FROM 表名；
2、计算某列的和
SELECT SUM(字段名) FROM 表名；
3、查询字段的最大最小
SELECT MAX(字段名) FROM 表名；
SELECT MIN(字段名) FROM 表名；
4、排序
SELECT 字段1，字段2，字段3 … FROM 表名 ORDER BY 字段；

七、一个问题你认为是bug，但是开发人员认为不是，你如何处理?
1、将问题提交到缺陷管理库里面进行备案。
2、要获取判断的依据和标准：
根据需求说明书、产品说明、设计文档等，确认实际结果是否与计划有不一致的地方，提供缺陷是否确认的直接依据；
如果没有文档依据，可以根据类似软件的一般特性来说明是否存在不一致的地方，来确认是否是缺陷；
根据用户的一般使用习惯，来确认是否是缺陷；
3、与设计人员、开发人员和客户代表等相关人员探讨，确认是否是缺陷；
4、合理的论述，向测试经理说明自己的判断的理由，注意客观、严谨，不参杂个人情绪。
等待测试经理做出最终决定，如果仍然存在争议，可以通过公司政策所提供的渠道，向上级反映，并有上级做出决定。

八、如果你负责的项目线上出了bug，你怎么解决？
先了解bug发生的根源，看是我理解需求要偏差还是设计用例上有疏漏。如果需求理解有偏差看是需求描述是不是描述得不够准确，如果是的话可以和需求商量定一套比较规范的需求描述文档，看怎样才能把歧义降到最少；如果需求准确但我理解出了问题，那我下次梳理需求的时候会多问，多和需求讨论，争取每个需求都理解得很透彻；如果是设计用例上有疏漏，那我会考虑疏漏这个点的原因，并把这次疏漏的点记下来，避免下次再出现这样的问题。

九、缺陷的生命周期
在这里插入图片描述
十、纸杯测试？
1、功能性：用水杯装水看漏不漏;水能不能被喝到；
2、安全性：杯子有没有毒或细菌；
3、可靠性：杯子从不同高度落下的损坏程度；
4、可移植性：杯子在不同的地方、温度等环境下是否都可以正常使用；
5、兼容性：杯子是否能够容纳果汁、白水、酒精、汽油等；
6、易用性：杯子是否烫手、是否有防滑措施、是否方便饮用；
7、用户文档：使用手册是否对杯子的用法、限制、使用条件等有详细描述；
8、疲劳测试：将杯子盛上水(案例一)放24小时检查泄漏时间和情况;盛上汽油(案例二)放24小时检查泄漏时间和情况等；
9、压力测试：用根针并在针上面不断加重量，看压强多大时会穿透。

十一、如何测试一个App的登录场景？
1、页面基本元素的操作。
2、大量字符，特殊字符，边界值，必填项校验。
3、注册手机号的特殊性验证，注册邮箱的格式验证。
4、密码大小写是否敏感，密码是否加密展示，密码是否有可见按钮功能，密码框能否使用复制粘贴。
5、验证码校验：必填项，过期，错误，无网络时获取验证码，多次获取，超过获取次数，输入验证码后，修改手机号。
6、登陆时与系统的交互：锁屏，蓝牙，home，后退，横竖屏，修改字体字号。
7、逆向思维：已注册账号注册，未注册账号忘记密码，未注册账号登陆，注册过程中退出再次注册。
8、输入法交互，切换输入法，切换输入模式，手写/九宫格。
9、登陆账号的多样性：多个账号轮流登陆，同一个账号多角色登陆。
10、第三方登录验证：账号授权，信息正确，取消授权。
11、登陆页面跳转，返回，登陆成功及其他页面跳转。
12、手机兼容性测试：分辨率兼容，系统兼容，系统版本兼容，App版本兼容。
13、网络切换，网络断开，弱网
　
十二、Push消息如何测试？
1、检查Push消息是否按照指定的业务规则发送。
2、检查不接收推送消息时，用户不会在接收到Push消息。
3、如果用户设置了免打扰的时间段，检查在免打扰时间段内，用户接收不到Push。在非免打扰时间段内，用户能正常收到Push。
4、当Push消息是针对登录用户的时候，需要检查收到的Push与用户身份是否相符，没有错误的将其他人的消息推送过来。一般情况下，只对手机上最后一个登录用户进行消息推送。
5、测试Push时，在开关机、待机状态下执行推送，消息及其推送跳转的正确性。
6、push消息时，会有红点展示，推送消息阅读前后数字的变化是否正确；
7、应用在开发、未打开状态、应用启动且在后台运行的情况下时push显示和跳转是否正确。
8、多条推送的合集的显示和跳转是否正确。

十三、App的闪退通常是什么原因造成的？
1、缓存垃圾太多；
Android系统的特性，如果长时间不清理垃圾文件，会导致越来越卡，甚至闪退。
2、运行程序太多，导致内存不足；
3、应用版本兼容问题，分辨率兼容问题；
4、APP中访问网络的地方，组件能否正常下载并显示；
5、APP的sdk与手机系统不兼容；
6、系统升级后，新版本不兼容老版本的API，返回对象失败，报空指针；
7、软件权限未开放。

十四、如果应用闪退，Android 和iOS 上是分别怎么抓取日志的？
日志抓取：ios
通过iTunes Connect（Manage Your Applications - View Details - Crash Reports）获取用户的crash日志
通过Xcode从你的设备上获得崩溃日志
自己在程序中添加崩溃捕捉代码，如果应用集成第三方SDK，如百度统计
日志抓取：Android：
通过集成第三方SDK，如百度统计、友盟统计等
发版时使用加固工具，他们也会收集错误日志，如360加固
在程序中添加程序异常崩溃的捕捉代码，保存到本地文件中

十五、如何提交高质量的缺陷报告单？
1、缺陷的概要描述要清晰准确，要使相关开发负责人员能够一目了然问题是什么。
2、一个完整的缺陷报告单，必须包含其必要的元素信息，例如：概要描述，缺陷发现人，测试环境，浏览器，缺陷重现步骤，严重等级，指派人，所属功能模块等等，必要元素信息必须描述全面清楚。
3、缺陷的重现步骤必须描写清晰明了，使相关开发负责人能够根据重现步骤准确的重现所提交的缺陷，使其定位缺陷的原因所在。
4、测试数据，测试的数据作为重现缺陷的一个重要元素信息，一定要将测试时所使用的信息给描写清楚准确。让开发人员根据测试所提供的测试数据准确重现缺陷。
5、附件截图信息，附件或截图信息能让开发人员能够一目了然的清楚问题的所在。

十六、软件测试的分类有哪些？
1、按照是否执行被测试软件来分：
静态测试：是指不运行软件，测试包括代码检查、静态结构分析、代码质量度量等，主要对软件需求说明书、设计说明书、软件源代码进行检查与分析。
动态测试：指通过运行被测程序，检查运行结果与预期结果的差异，分析差异原因，并分析软件运行效率、健壮性等性能。动态测试是目前公司主要的测试方式
2、按照测试技术分为黑盒测试和白盒测试：
黑盒测试：黑盒测试又叫功能测试或数据驱动测试，在完全不考虑程序内部结构和内部特性的情况下，通过软件的外部表现来发现其缺陷和错误。
白盒测试：白盒测试也称结构测试或逻辑驱动测试，它是按照程序内部的结构进行测试程序，通过测试来检测产品内部逻辑是否按照设计规格说明书的规定正常进行，检验程序中的每条通路是否都能按预定要求正确工作。
3、按照测试手段来分，可以分为手工测试和自动化测试
4、按照过程阶段来分，可以分为单元测试、集成测试、系统测试和验收测试
单元测试：通过模块(类/方法/函数)测试，使代码达到设计要求主要目的是针对编码过程中可能存在的各种错误，例如用户输入验证过程中的边界值的错误。
集成测试：将经过单元测试的模块逐步组装成完整的程序。主要目的是检查各单元与其它程序部分之间的接口是否存在问题，各模块功能之间是否有影响。
系统测试：是将已经确认的软件、计算机硬件、外设、网络等其他元素结合在一起进行测试。系统测试是针对整个产品系统进行的测试，目的是验证系统是否满足了需求规格的定义，找出与需求规格不符或与之矛盾的地方，进行改正。
验收测试：验收测试是在软件产品完成了单元测试、集成测试和系统测试之后，产品发布之前所进行的最后一次软件测试活动，也称为交付测试。通常由业务专家或用户进行，以确认产品能真正符合用户业务上的需要。

十七、黑盒测试的测试用例常见设计方法都有哪些？
请分别以具体的例子来说明这些方法在测试用例设计工作中的应用。
1）等价类划分法：
等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就
可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类.

2）边界值分析法：
是对等价类划分方法的补充。测试工作经验告诉我,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误.使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据.

3）错误猜测法：
基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法.错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结. 还有, 输入数据和输出数据为0的情况. 输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况. 可选择这些情况下的例子作为测试用例.

4）因果图方法：
前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系, 相互组合等. 考虑输入条件之间的相互组合,可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图（逻辑模型）. 因果图方法最终生成的就是判定表.它适合于检查程序输入条件的各种组合情况.

5）正交表分析法：可能因为大量的参数的组合而引起测试用例数量上的激增，同时，这些测试用例并没有明显的优先级上的差距，而测试人员又无法完成这么多数量的测试，就可以通过正交表来进行缩减一些用例，从而达到尽量少的用例覆盖尽量大的范围的可能性。

6）场景分析方法：指根据用户场景来模拟用户的操作步骤，这个比较类似因果图，但是可能执行的深度和可行性更好。

7）状态图法：
通过输入条件和系统需求说明得到被测系统的所有状态，通过输入条件和状态得出输出条件；通过输入条件、输出条件和状态得出被测系统的测试用例。

8）大纲法：
大纲法是一种着眼于需求的方法，为了列出各种测试条件，就将需求转换为大纲的形式。大纲表示为树状结构，在根和每个叶子结点之间存在唯一的路径。大纲中的每条路径定义了一个特定的输入条件集合，用于定义测试用例。树中叶子的数目或大纲中的路径给出了测试所有功能所需测试用例的大致数量。

十八、软件的安全性应从哪几个方面去测试？
软件安全性测试包括程序、数据库安全性测试。根据系统安全指标不同测试策略也不同。
测试点：
1、跨网站脚本攻击：通过脚本语言的缺陷模拟合法用户，控制其账户，盗窃敏感数据；
2、注入攻击：通过构造查询对数据库、LDAP和其他系统进行非法查询；
3、恶意文件执行：在服务器上执行Shell 命令Execute，获取控制权；
4、伪造跨站点请求：发起Blind 请求，模拟合法用户，要求转账等请求；
5、不安全对象引用：不安全对象的引入，访问敏感文件和资源，WEB应用返回敏感文件内容；
6、被破坏的认证和Session管理：验证Session token 保护措施，防止盗窃session；
7、Session的失效时间限制：Session的失效时间设置是否过长，会造成访问风险；
8、不安全的木马存储：过于简单的加密技术导致黑客破解编密码，隐秘信息被盗窃，验证其数据加密；
9、不安全的通讯：敏感信息在不安全通道中以非加密方式传送，敏感信息被盗窃，验证其通讯的安全性；
10、URL访问限制失效：验证是否通过恶意手段访问非授权的资源链接，强行访问一些登陆网页，窃取敏感信息；
11、信息泄露和不正确错误处理测试：恶意系统检测，防止黑客用获取WEB站点的具体信息的攻击手段获取详细系统信息；
12、注册与登录测试：验证系统先注册后登录、验证登录用户名和密码匹配校验，密码长度及尝试登录次数，防止非法用户登录；
13、超时限制：验证WEB应用系统需要有是否超时的限制，当用户长时间不做任何操作的时候，需要重新登录才能使用；
14、日志文件：验证服务器上日志是否正常工作，所有事务处理是否被记录；
15、目录文件：验证WEB服务器目录访问权限或者每个目录访问时有index.htm，防止 WEB 服务器处理不适当，将整个目录暴露；
16、身份验证：验证调用者身份、数据库身份、验证是否明确服务账户要求、是否强制式试用账户管理措施；
17、授权：验证如何向最终用户授权、如何在数据库中授权应用程序，确定访问系统资源权限；
18、会话：验证如何交换会话标识符、是否限制会话生存期、如何确保会话存储状态安全；
19、配置管理：验证是否支持远程管理、是否保证配置存储安全、是否隔离管理员特权；
20、备份与恢复：为了防止系统意外崩溃造成的数据丢失，验证备份与恢复功能正常实现、备份与恢复方式是否满足Web系统安全性要求；
21、数据库关键数据是否进行加密存储，是否在网络中传递敏感数据；
22、在登录或注册功能中是否有验证码存在，防止恶意大批量注册登录的攻击；
23、Cookie文件是否进行了加密存储，防止盗用cookie内容；
24、密码强度提醒：建议对密码的规则进行加强设置；
25、密码内容禁止拷贝粘贴。

十九、你对测试最大的兴趣在哪里？为什么？
最大的兴趣就是测试有难度，有挑战性！做测试越久越能感觉到做好测试有多难。曾经在网上看到一篇文章，是关于如何做好一名测试工程师。一共罗列了 11，12 点，有部分是和人的性格有关，有部分需要后天的努力。但除了性格有关的 1，2 点我没有把握，其他点我都很有信心做好它。
刚开始进入测试行业时，对测试的认识是从网上了解到的一些资料，当时是冲着做测试需要很多技能才能做的好，虽然入门容易，但做好很难，比开发更难，虽然当时我很想做开发，但看到测试比开发更难更有挑战性，想做好测试的意志就更坚定了。我觉得做测试整个过程中有两点让我觉得很有难度（对我来说，有难度的东西我就非常感兴趣），第一是测试用例的设计，因为测试的精华就在测试用例的设计上了，要在版本出来之前，把用例写好，用什么测试方法写？（也就是测试计划或测试策略），如果你刚测试一个新任务时，你得花一定的时间去消化业务需求和技术基础，业务需求很好理解（多和产品经理和开发人员沟通就能达到目的），而技术基础可就没那么简单了，这需要你自觉的学习能力，比如说网站吧，最基本的技术知识你要知道网站内部是怎么运作的，后台是怎么响应用户请求的？测试环境如何搭建？这些都需要最早的学好。至少在开始测试之前能做好基本的准备，可能会遇到什么难题？需求细节是不是没有确定好？这些问题都能在设计用例的时候发现。第二是发现 BUG 的时候了，这应该是测试人员最基本的任务了，一般按测试用例开始测试就能发现大部分的 bug，还有一部分 bug 需要测试的过程中更了解所测版本的情况获得更多信息，补充测试用例，测试出 bug。还有如何发现 bug？这就需要在测试用例有效的情况下，通过细心和耐心去发现 bug 了，每个用例都有可能发现 bug，每个地方都有可能出错，所以测试过程中思维要清晰（测试过程数据流及结果都得看仔细了，bug 都在里面发现的）。如何描述 bug 也很有讲究，bug 在什么情况下会产生，如果条件变化一点点，就不会有这个 bug，以哪些最少的操作步骤就能重现这个bug，这个bug产生的规律是什么？如果你够厉害的话，可以帮开发人员初步定位问题。

二十、简单描述下TCP协议
1、TCP：传输控制协议，是传输层通信协议。它有面向连接、可靠、字节流传输等特点，TCP建立连接时，需要三次握手协议
2、TCP三次握手的过程如下：
(1)第一次握手：建立连接时,客户端发送syn包(syn=j)到服务器,并进入SYN_SEND状态,等待服务器确认；SYN：同步序列编号(Synchronize Sequence Numbers)；
(2)第二次握手：服务器收到syn包,必须确认客户的SYN（ack=j+1）,同时自己也发送一个SYN包（syn=k），即SYN+ACK包,此时服务器进入SYN_RECV状态；
(3)第三次握手：客户端收到服务器的SYN＋ACK包,向服务器发送确认包ACK(ack=k+1),此包发送完毕,客户端和服务器进入ESTABLISHED状态,完成三次握手。
二十一、TCP与UDP的区别？
1、TCP传输控制协议，UDP用户数据报协议；
2、TCP对资源要求比较多，UDP对资源要求比较少；
3、TCP可以保证数据的正确性，UDP有可能会丢包；
4、TCP可以保证数据的顺序，UDP不会保证。

二十二、网络7层模型是哪7层？
从下到上，物理层、数据链路层、网络层、传输层、会话层、表示层、应用层
(1)物理层：同轴电缆、接收器、发送器等
(2)数据链路层：网卡、交换机、网桥
(3)网络层：路由器、网关
(4)传输层：TCP协议、UDP协议
(5)会话层：SQL、ASP、 PHP等
(6)表示层：ASCII、JPEG、PNG、MP3等
(7)应用层：telnet、ssh、http、smtp等

二十三、移动端测试

Android手机和IOS手机，系统有什么区别？
1、两者运行机制不同：IOS采用的是沙盒运行机制，安卓采用的是虚拟机运行机制。
2、两者后台制度不同：IOS中任何第三方程序都不能在后台运行；安卓中任何程序都能在后台运行，直到没有内存才会关闭。
3、IOS中用于UI指令权限最高，安卓中数据处理指令权限最高。

Android:
1、使用灰盒进行功能测试；
2、使用fiddler或者Charles进行抓包测试；
3、兼容性测试,Android 从4.0版本的手机测试到10.0版本手机；
4、各大品牌的手机都要进行测试,参考百度流量研究院，网址：https://tongji.baidu.com/research/
5、稳定性测试: 使用monkey命令进行稳定性测试；
6、专项测试,使用腾讯专项测试工具进行,测试耗电量,流量,CPU占用率；
7、性能测试,对app的接口进行性能测试,使用工具jmeter或者loadrunner；
8、对app接口进行接口测试,使用postman或者Jmeter都行；
9、如果有时间写自动化脚本；

ios:
1、使用灰盒进行功能测试；
2、使用fiddler或者Charles进行抓包测试；
3、兼容性测试:ios版本测试从9-14,手机型号从4S测试到xmax；
4、性能测试接口和安卓的是一样的所以只需要进行一次就可以了；
5、专项测试:使用腾讯专项测试工具进行,测试耗电量,流量,CPU占用率；
6、编写自动化脚本。

二十四、web端测试
由于web端应用于用户直接相关，又通常需要承受长时间的大量操作，因此web项目的功能和性能都必须经过可靠的验证。web端测试常见的有界面测试、功能测试、性能测试、可用性（接口）测试、兼容性测试、安全性测试、链接测试。

1、界面测试
(1)界面的风格、样式、颜色是否协调;
(2)界面窗口的最大化、最小化是否能正确切换;
(3)界面布局是否整齐，协调;
(4)界面操作、提示界面是否符合人们的常规习惯;
(5)界面是否有Tab键的支持，顺序要有调理不乱跳;
(6)操作有风险的界面时，是否有确认删除等提示;
(7)界面的特殊效果显示是否正确（特殊字体效果、动画显示效果）
(8)界面在不同分辨率下是否清晰，在不同浏览器版本中是否显示;
(9)输入框的检查（日历型输入框合法性的检查）
2、功能测试
(1)搜索功能
如果支持模糊查询，搜索名称中任意一个字符是否都能搜索到；
用户进行查询操作时，一般情况是不进行查询条件的清空，除非需要特殊说明；
不同查询条件之间来回选择，是否出现页面错误；
测试多个查询条件时，要注意查询条件的组合测试，可能不全一同组合的测试会报错。
(2)增删改功能
是否支持回车键、Tab键；
不符合要求的地方是否都有错误提示；
字段唯一的是否可以重复添加，添加后是否可以修改为已存在的字段；
删除某些重要信息时是否有删除提示；
删除数据时是否能连续删除多个，当只有一条数据时，是否可以删除成功，批量删除信息时注意删除的信息是否正确；
对页面进行编辑修改时，点击保存是否可以保存成功，检查相关联的数据是否得到更新；
进行编辑的时候注意编辑项的长度设置，注意添加和修改的规则是否一致；
修改后增加数据时，要注意查询页面的数据是否及时更新，特别是在首页时要注意数据的更新；
提交数据时，连续多次点击，查看系统是否出现相同的数据或者在连续点击情况下报错。
(3)登录注册功能
检查注册成功后，页面是否会跳转到登录页面或其他页面；
注册成功后删除注册账号，检查是否注册成功；
输入框是否支持Tap和Enter键；
密码是否可以复制粘贴，密码是否是以加密符号显示；
登录时对用户名和密码进行检测判断；
登录时，当页面刷新重新输入数据，检查验证码是否更新；
对模块的具体功能进行测试时可以列出功能模块所有的功能，进行排列组合，测试所有情况
3、性能测试
(1)性能测试目的是对web端的页面进行测试以确认系统页面是否会影响系统的性能并对页面的优化提供依据与建议；
(2)减少请求和相应的往返字节，一般将所有css放到一个css文件，所有脚本放到js文件；
(3)检查js的位置。
4、可用性（接口）测试
5、兼容性测试
兼容性测试包括操作系统兼容、软件兼容、不同浏览器的兼容
6、安全性测试
(1)服务器脚本常常构成安全漏洞，要对这进行测试，测试没有经过授权就不能在服务器端放置和编辑脚本你的问题；
(2)当使用了安全套接字，还要测试加密是否正确，检查信息的完整性；
(3)为了保证web应用系统的安全性，需要测试相关信息是否写进了日志文件，是否可追踪；
(4)web页面注册登录时还要验证token，当token过期时需要诚信登录验证身份才能正常使用。
7、链接测试
链接测试主要是保证链接的可用性和正确性

二十五、APP测试
1、安装和卸载
(1)应用是否可以在IOS不同系统版本或android不同系统版本上安装（有的系统版本过低，应用不能适配）；
(2)软件安装后是否可以正常运行，安装后的文件夹及文件是否可以写到指定的目录里；
(3)安装过程中是否可以取消；
(4)安装空间不足时是否有相应提示；
(5)如果应用需要通过网络验证之类的安装，需要测试一下断网情况下是否有相应提示；
(6)是否可以删除应用（可通过桌面删除，也可以通过软件卸载安装。曾发现在IOS手相上有个应用安装时未完全安装，终止安装后，未完成安装的应用图标一直显示在手机上，并且无法成功删除）；
(7)测试卸载后文件是否全部删除所有的安装文件夹；
(8)卸载过程中出现死机，断电，重启等意外的情况，待环境恢复后是否可以正确卸载；
(9)卸载是否支持取消功能，单击取消后软件卸载情况是否正常。
2、运行
(1)APP安装完成后，是否可以正常打开软件；
(2)APP运行时，是否有加载图示；
(3)APP的速度是可以让人接受，切换是否流畅；
(4)用户登录状态太久，sessionId会过期，会出现“虽然是登录状态，系统会提示用户没有登录。
3、登录
(1)登录用户名和密码错误时，界面有提示信息；
(2)用户主动退出登录后，下次启动APP时，应该进入登录界面；
(3)对于支持自动登录的APP，数据交换时，是否能自动登录成功且数据库操作无误；
(4)密码更改后，登录时是否做到了有效数据的校验；
(5)对于未登录时一些页面的操作，是否做了控制；
(6)切换账号登录，检验登录的信息是否做到及时更新；
(7)对于多个端都进行操作时，确保数据库操作无误，且每个端可以及时看到数据的更新；
(8)对于一些软件，支持一个账号只允许登录一台机器，这时，需要检查账号登录多个手机时，是否将原用户剔除，且能够给出提示信息；
(9)APP切换到后台时，再次切换到前台的测试，如登录时，有电话打进来；
(10)对于IOS与android不同设备登录同一个账号时，对个人信息等数据进行操作后，确保数据数库操作无误，且IOS与android设备看到的数据都是最新的。
4、离线
(1)离线是应用程序在本地的客户端会缓存一部分数据以供程序下次调用；
(2)对于一些程序，需要在登录进来后，这时没有网络的情况下可以浏览本地数据；
(3)对于无网络时，刷新获取新数据时，不能获取数据且能给出友好提示；
(4)切换到后台，再次切换到前台时，可以正常查看；
(5)离线后又连上网，这时对数据有更新时，需要从服务器端获取新数据来更新客户端数据，且要更新本地缓存信息；
(6)对于一些界面的数据不提供离线查看，需要给出相应提示且界面更新后无任何数据；
(7)确认在无网情况下可以浏览本地数据；
(8)确认退出APP再开启APP时能正常浏览；
(9)确认切换到后台再切回APP应用时可以正常浏览；
(10)锁屏后再解锁回到应用前台可以正常浏览；
(11)服务端的数据有更新时有离线的提示。
5、数据更新
(1)确认有数据更新后，哪些地方需要手动刷新，哪些地方需自动刷新；
(2)确认从后台切换回前台时，哪些页面需要进行数据更新；
(3)根据需求和逻辑，确认哪些数据是从服务端请求实时响应，哪些是缓存到本地的数据。
6、消息推送开关设置
(1)默认开关应该是全打开状态；
(2)设置开关可以自由打开关闭；
(3)设置开关打开状态下，消息推送是否可正常接收（应用启用中和应用关闭时都应该可以收到）；
(4)确认后台未打开APP客户端时，手机消息栏可以接收到消息提醒。且点击可查看。点击后消息栏中消失；
(5)确认APP客户端启动时，可以收到消息提醒，且点击可查看。客户端运行时，消息不会进消息栏；
(6)设置开关关闭时，客户端接收不到消息推送。
7、软件更新
(1)当客户端有新版本时，有更新提示；
(2)软件更新一定要测，确保android软件更新可以正确更新新版本，且安装运行正确；
(3)确保IOS软件更新会有限制，只有上了商店且有版本更新时才会测试，但是如果真有问题，再发现问题有点晚，可以让开发先在测试机上模拟一个地址进行测试；
(4)用户取消版本更新时，老版本可以正常使用，但是下次启动应用时，仍出现更新提示；
(5)当有新版本时，不删除客户端的情况下，直接更新检查是否能正常更新，且更新后客户端的功能是否最新版本（正常来讲不用强制删除本地客户端可以正常更新）。
8、异常测试
(1)没有内存空间时，APP能否正确响应；
(2)APP运行中手机断电；
(3)APP运行中断开网络；
(4)反复操作某个功能，不断点击，刷新时，是否会闪退；
(5)APP运行时拔打或接听电话；
(6)APP运行时发送信息、收取邮件等；
(7)多个APP运行时；
(8)不断切换前台和后台，是否影响应用正常功能；
(9)APP运行时，启动相机功能。
９、网络环境
(1)测试２G、３Ｇ，４Ｇ，wifi 网络下应用运应的速度；
(2)内网测试时，选择到外网操作是否有异常处理；
(3)网络不好时，提交数据是否一直处理提交中，是否会有延迟，数据交换失败是否会有提醒；
(4)有网到无网再到有网环境时，数据是否可以自动恢复，正常加载。
10、其它
(1)接口测试。让开发提供一份接口文档，一定要将接口测试通。在接口测试阶段，将缺少接口，接口不完善的缺陷挖掘出来。这个需要准备充分的后台数据；
(2)导航测试。在运行APP时，不管在哪个接点，导航是否直观，精准，页面切换是否正确；
(3)图片测试。图片，按钮是否自适应；
(4)内容测试。要进行超长字符，空字符校验且校验是否有错别字；
(5)功能测试。功能是否实现；
(6)易用性测试。所开发的功能，是否让用户容易接受，是否符合大众的操作习惯；
(7)适配性测试。应用在不同设备，不同系统上是否适配；
(8)UI测试。应用的设计是否够美观。
二十六、测试计划如何编写？
5W
why，为什么要编写，编写的目的；
what，要去测试什么内容，测试的范围；
when，时间上的安排和计划，什么时候开始测试，什么时候结束测试；
who，谁来测试，具体的人力资源的安排和人员的一个计划；
where，在哪里测试，准备什么样的测试环境。

1H
how，用什么样的工具来测试，如何测试。

二十七、测试报告如何编写？
一份完整的测试报告，基本包含以下3点：
1.测试的基本情况，包括测试的时间、测试人员、测试的环境、测试用例执行的基本统计。
2.缺陷的统计和分析，包括缺陷总数的一个汇总、不同维度缺陷的分析和统计、遗留问题的汇总和分析。
3.测试的结论和建议，包括测试的风险、本次测试的结论(测试是否通过、是否达到上限的标准)。

在这里插入图片描述

二十八、为什么测接口及必要性
比如测试用户注册功能，规定用户名为6~18个字符，包含字母（区分大小写）、数字、下划线。首先功能测试时肯定会对用户名规则进行测试时，比如输入20个字符、输入特殊字符等，但这些可能只是在前端做了校验，后端可能没做校验，如果有人通过抓包绕过前端校验直接发送到后端怎么办呢？试想一下，如果用户名和密码未在后端做校验，而有人又绕过前端校验的话，那用户名和密码不就可以随便输了吗？如果是登录可能会通过SQL注入等手段来随意登录，甚至可以获取管理员权限，那这样不是很恐怖？

接口测试的必要性就体现出来了：
①可以发现很多在页面上操作发现不了的bug；
②检查系统的异常处理能力；
③检查系统的安全性、稳定性；
④前端随便变，接口测好了，后端不用变。

二十九、什么项目适合做接口自动化测试
①任务需求明确，不会频繁变动；
②项目周期较长，回归测试频繁（>=5次），开展自动化确实能提升测试效率及质量；
③产出的效益高于投入；
④测试预留的时间比较充裕。

三十、接口测试中的http状态码
每发出一个http请求之后，都会有一个响应，http本身会有一个状态码，来标示这个请求是否成功，常见的状态码有以下几种：
1、200 2开头的都表示这个请求发送成功，最常见的就是200，就代表这个请求是ok的，服务器也返回了。
2、300 3开头的代表重定向，最常见的是302，把这个请求重定向到别的地方了。
3、400 400代表客户端发送的请求有语法错误，401代表访问的页面没有授权，403表示没有权限访问这个页面，404代表没有这个页面。
4、500 5开头的代表服务器有异常，500代表服务器内部异常，504代表服务器端超时，没返回结果。

三十一、没有接口文档如何做接口测试？
没有接口文档，那还能咋办，瞎测呗！一个公司的开发流程里面，如果接口文档都没有，是无法展开接口测试的，你都不知道这个接口干什么的，也不知道具体每个字段代表什么意思，那还测啥呢？
–当然，你肯定不能回答面试官不测(心理mmp，脸上笑嘻嘻)，接下来就是扯犊子时间
1.没有接口文档，那就需要先跟开发沟通，然后整理接口文档（本来是开发写的，没办法，为了唬住面试官，先说自己整理了）
2.没有接口文档，可以抓包看接口请求参数，然后不懂的跟开发沟通

三十二、接口测试中的数据依赖
在手工接口测试或者自动化接口测试的过程中，上下游接口有数据依赖如何处理？
用一个全局变量来处理依赖的数据，比如登录后返回token,其它接口都需要这个token,那就用全局变量来传token参数。

三十三、当一个接口出现异常时候，你是如何分析异常的？
1.抓包，用fiddler工具抓包，或者浏览器上f12,app上的话，那就用fiddler设置代理，去看请求报文和返回报文了。
2.查看后端日志，xhell连上服务器，查看日志。

三十四、前后端bug区分
一个Bug出现，最简单易行的判断办法是：通过请求与响应来判断。
1、如果前端已经把数据发送给了后端，后端接到请求，而后端没有返回数据请求，则是后端出了问题；
2、如果前端在用户输入数据后，发送的请求没有带数据，则是前端的问题，或者后台已经传回了数据，但在前端显示不出来，这是前端问题。
3、当然具体问题要具体分析，可以在浏览器中debug调试中看，但大的原则就是通过请求与响应来判断。

三十五、那么需求评审时期测试到底要做什么呢？
1、需求评审前，提前进行需求熟悉阶段，逐一分析需求点，做好准备，相关需求疑问点列好清单，带着问题去参会。
2、产品宣讲时期，就算过程有问题，不要试探打断产品的宣讲，一是节约时间，二是不礼貌，等产品将一个模块宣讲完毕，开始带着你的问题，开始你的表演，分析给项目成员听，并提出改进建议。
3、当需求有问题确认需要修正，或需进一步跟业务确认再做定夺的，做好标记，并提醒产品，做好会议记录。
4、开发是个直男~一旦进入技术凯旋，那非得争的明明白白的，所以宣讲时期如果开发进入技术凯旋，在适当时期提醒产品，进行控场，有效的控制时间，接着宣讲其他模块业务流。
5、需求评审完后，项目群推送需求评审会议记录点，周知各位目前的版本的疑问点以及修改点，并提醒产品进行下次需求确认会议时间,这个会议也可以由测试主持。

三十六、web和移动端测试的区别
1、从系统架构来看的话，web测试只要更新了服务器端，客户端就会同步会更新。而且客户端是可以保证每一个用户的客户端完全一致的。但是app端是不能够保证完全一致的，除非用户更新客户端。如果是app下修改了服务端，意味着客户端用户所使用的核心版本都需要进行回归测试一遍。

2、性能方面，web页面可能只会关注响应时间，而app则还需要关心流量、电量、CPU、GPU、Memory这些了。

3、兼容方面，web是基于浏览器的，所以更倾向于浏览器和电脑硬件，电脑系统的方向的兼容，不过一般还是以浏览器的为主。而浏览器的兼容则是一般是选择不同的浏览器内核进行测试（IE、chrome、Firefox）。app的测试则必须依赖phone或者是pad，不仅要看分辨率，屏幕尺寸，还要看设备系统。系统总的来说也就分为Android和iOS，不过国内的Android的定制系统太多，也是比较容易出现问题的。

4、相比较web测试，app更是多了一些专项测试：
①一些异常场景的考虑以及弱网络测试。
这里的异常场景就是中断，来电，短信，关机，断电，重启等。
　　弱网测试是app测试中必须执行的一项测试。包含弱网和网络切换测试。需要测试弱网所造成的用户体验，重点要考虑回退和刷新是否会造成二次提交。需要测试丢包，延时的处理机制。避免用户的流失。
②安装、卸载、更新：
　　web测试是基于浏览器的所以不必考虑这些。而app是客户端的，则必须测试安装、更新、卸载。除了常规的安装、更新、卸载还要考虑到异常场景。包括安装时的中断、弱网、安装后删除安装文件，更新的强制更新与非强制更新、增量包更新、断点续传、弱网，卸载后删除app相关的文件等等。
③界面操作：
　　现在app产品的用户都是使用的触摸屏手机，所以测试的时候还要注意手势，横竖屏切换，多点触控，事件触发区域等测试。
④边界测试：
可用存储空间少、没有SD卡/双SD卡、飞行模式、系统时间有误、第三方依赖（QQ、微信登录）等。
⑤权限测试：
设置某个App是否可以获取该权限，例如是否可访问通讯录、相册、照相机等。

三十七、逻辑题—取最值(有可能结合代码考查)
一楼到十楼的每层电梯门口都放着一颗钻石，钻石大小不一。你乘坐电梯从一楼到十楼，每层楼电梯门都会打开一次，只能拿一次钻石，问怎样才能取到最大的一颗？

只能拿一次钻石，我觉得有歧义，是每个电梯门口都能拿一次还是总共只能拿一次。如果是前者，那就是冒泡排序思想，拿走第一层的钻石，以后在每层楼交换较大的那颗到手里。如果是后者，总共只能出手一次，那么将无法确定拿到的一定是最大的钻石，可先在前5层辨别各个的大小，后5层中如果出现接近最大的那颗的话，就出手吧。

三十八、内链接、左右链接的区别
　左（外）连接（LEFT JOIN），以左表为基准，查询出左表所有的数据和右表中连接字段相等的记录，如果右表中没有对应数据，则在左表记录后显示为空（NULL）.如果把两个表分别看成一个集合的话，则显示的结果为JOIN左边的集合。(以左表为准，去右边找匹配数据，找不到匹配，用NULL补齐。)
　右（外）连接(RIGHT JOIN )是以右表为基准，查询出右表所有的数据和左表中连接字段相等的记录，如果左表没有对应数据则在右表对应数据行显示为空（NULL）.如果把两个表分别看成一个集合的话，则显示的结果为JOIN右边的集合。
　内连接(INNER JOIN )是查询出两个表对应的数据，如果把两个表分别看成一个集合的话，内连接的结果即为两个表的交集。

三十九、如何做好回归测试
回归测试（Regression testing）是指代码在发生修改之后重新测试之前的测试以保证修改的正确性。理论上，软件产生新版本，都需要进行回归测试，验证以前发现和修复的缺陷是否在软件新版本上再次出现。
关于如何做好回归测试，大体上是先验证bug，然后回归和本次修改相关的地方。
1、和项目中的DEV以及项目负责人沟通确认
这是一个很关键的环节，好的开发人员在提交测试时就会注明可能影响的地方。
2、关键点的测试
就是很重要的部分，即使看着和本次修改无太直接关联，也最好能走一下基本流程。因为这是客户最关心的地方点，也是盈利的所在。
3、测试的重点
bug修改，关联功能，新增加功能，修改功能，上一轮测试bug多的功能。（测试人员要了解开发在这一轮修改了哪些bug，要注意关注我们的bug管理工具上的变化。）

四十、测试过程中遇到app出现crash或者ANR，你会怎么处理？
可以先把日志过滤出来： adb logcat | findstr xxxxx(过滤日志信息) ，然后再搜索其中的关键字，比如：exception、crash，看看是那些方法或者异常导致了问题的发送，初步定位问题原因后，可以交给开发人员去具体查找深层原因并修复。

四十一、selenium中显示等待和隐式等待区别？
显式等待

element = WebDriverWait(driver,5,0.5).until(EC.presence_of_element_located(By.ID,‘kw’))
element.sendkeys("xxx")

显示等待是单独针对某个元素，设置一个等待时间如5秒，每隔0.5秒检查一次是否出现，如果在5秒之前任何时候出现，则继续向下，超过5秒尚未出现则抛异常。显示等待与隐式等待相对，显示等待必须在每个需要等待的元素前面进行声明。
隐式等待

driver.implicitly_wait(10)

隐式等待是全局的是针对所有元素，设置等待时间如10秒，如果10秒内出现，则继续向下，否则抛异常。可以理解为在10秒以内，不停刷新看元素是否加载出来。

四十二、简述测试流程？
1、阅读相关技术文档（如产品PRD、UI设计、产品流程图等）。
2、参加需求评审会议。
3、根据最终确定的需求文档编写测试计划。
4、编写测试用例（等价类划分法、边界值分析法等）。
5、用例评审(主要参与人员：开发、测试、产品、测试leader)。
6、开发提交代码至SVN或者GIT ，配管搭建测试环境。
7、执行测试用例，记录发现的问题。
8、验证bug与回归测试。
9、编写测试报告。
10、产品上线。

四十三、Alpha和Beta测试
Alpha测试就是由开发者“指导”用户在开发环境下进行的测试。Alpha测试是在受控的环境中进行的。
Beta测试就是由软件的最终用户们在一个或多个实际生产环境下进行的测试。开发者通常不在Beta测试的现场，因此，Beta测试是软件在开发者不能控制的环境中的“真实”应用。

四十四、为什么做测试,觉得自己做测试有哪些优势？
我觉得我个人的性格比较适合做测试。
1、比较细心耐心，考虑事情比较全面，这样对于我在设计测试用例时很有帮助；
2、我能够很好的与人协调沟通，当我们测试和开发发生沟通上的矛盾时我也能很好的解决；
3、平常喜欢刷微博、知乎看热门评论，喜欢考究大众心理，这有助于我站在用户角度设计测试点。

四十五、优秀测试人员应具备的素质
1、沟通能力与表达能力
2、好奇心与怀疑精神
3、责任感与抗压能力
4、自信心，坚持自己的观点
5、耐心与细心
6、逆向思维的能力
7、善于学习与总结
8、团队协作精神
9、文档编写能力

四十六、优秀测试人员应具备的技能
1、精通业务知识
2、具备软件编程能力，比如C,C++,JAVA等。
3、可以用脚本语言编写小测试工具
4、主流操作系统应用与网络知识，可以搭建测试环境
5、熟练掌握各种数据库知识
6、精通软件测试理论与方法
7、掌握常用测试与开发工具的使用
8、优秀的文档编写能力