测试面试题汇总

给你一个全新的软件，你就是负责人，你怎么去开展测试工作
参考回答：
第一步：需求分析：我会对这个全新的软件需求进行全面分析，主要的分析点有：1.软件的版本需求合理性，是否可测试；2.项目人员配置（遇到什么问题找谁，有多少人投入测试，测试环境，硬件，软件）；3.要测试的软件的主流程，异常流程，测试重点；4。项目整体规划（发布时间

第二步：指定测试策略、测试计划和bug定义标准，这一步主要是针对需求，在已有的和可协调到的资源上做出具体的，可执行的计划，这个阶段的输出是测试计划。测试计划中明确包含测试范围，测试策略，比如功能测试，性能测试，自动化测试，可用性测试，云测，mokey等

第三步：按计划执行，编写测试用例，（编写测试用例的方法：等价类，边界值，错误猜测法，因果图，正交分解法等等）（编写测试用例需要注意的点，用例区分等级，特殊场景考虑：为空（接口空、数据空）、加载超时、网络异常、重复提交、异常中断、缓存冲突、系统兼容、流程迂回、流程中断；如果是PC，要注意浏览器（IE，chrome,火狐，苹果的），操作系统（xp,win7,win8,win10,linux,mac）的兼容,如果是手机，注意手机的品牌，操作系统，android版本，手机屏幕尺寸，手机网络等等场景），写完用例，如果有条件，就要评审测试用例

第四步：执行用例，补充场景，记录bug，回归bug（注意开发提测的需求需要冒烟测试通过）

第五步：功能合入，回归测试（各个功能点测试通过之后，再合入）

第六步：提交验收（回归测试通过之后，提交给验收人员进行验收）

第七步：发布上线（全新的软件，先是小范围内测，观察线上数据（如：crash,用户反馈，运营数据等）如果有产品认为严重的问题，则需要修复后重发，符合预期才能扩大发布）
如果你发现了bug但是开发不认为是bug，怎么办
首先找证据支持我说这个是bug，（比如需求文档这么写的，竞品这么做的等等），如果找不到足够的证据支持你的观点，那就将问题升级到小组内讨论，一级一级的上升，直到PM或者项目经理拍板定义
你觉得bug需要修改，很紧急，但是开发没时间，怎么办
这个你需要先把这个问题说清楚，问题影响范围有多大，然后给PM或者项目经理还有拉上开发一起评审，说明这个问题遗留的风险，如果PM和项目经理接受这个风险，那就可以发布，否则必须修改了才能发布，即使他们接受了，发布之后，也要注意线上的表现
面试题：如何测试登录模块
注册登录在软件测试中是基础，但也会有漏测的情况出现，尤其是对于普通账户密码登录的情况，需要考虑账户密码的长度限制、字符类型、匹配判断等等。
目前市场上常用的登录方式也有很多，账密登录里又支持邮箱、账号、手机号登录。对于同时支持多种登录方式，测试时除了考虑每种方式是否能够登录成功以外，特别需要考虑不同登录方式的优先级、对于用户习惯登录方式的设置和记忆、各种登录方式之间的切换、不同设备的不同方式登录等等。
今天我与大家一起对登录方式及测试重点进行梳理，主要关注一些特殊点，以及容易出现漏测的情况。
下面说一下测试点

功能测试
输入正确的用户名和密码登录成功
输入错误的用户名密码登录失败
用户名正确，密码错误，是否提示输入密码错误？
用户名错误，密码正常，是否提示输入用户名错误？
用户名和密码都错误，是否有相应提示？
用户名密码为空时，是否有相应提示？
如果用户未注册，提示请先注册，然后进行登录
已经注销的用户登录失败，提示信息友好？
密码框是否加密显示？
用户名是否支持中文、特殊字符？
用户名是否有长度限制？
密码是否支持中文，特殊字符？
密码是否有长度限制？
密码是否区分大小写？
密码为一些简单常用字符串时，是否提示修改？如：123456
密码存储方式？是否加密？
登录功能是否需要输入验证码？
验证码有效时间？
验证码输入错误，登录失败，提示信息是否友好？
输入过期的验证能否登录成功？
验证码是否容易识别？
验证码换一张功能是否可用？点击验证码图片是否可以更换验证码？
用户体系：比如系统分普通用户、高级用户，不同用户登录系统后可的权限不同。
如果使用第三方账号(QQ,微博账号)登录，那么第三方账号与本系统的账号体系对应关系如何保存？首次登录需要极权等

界面测试
布局是否合理、美观，输入框是否对齐
风格和提示信息用语是否符合语境
登录页面显示是否正常？文字和图片能否正常显示，相应的提示信息是否正确，按钮的设置和排列是否正常
页面默认焦点是否定位在用户名的输入框中
首次登录时相应的输入框是否为空？或者如果有默认文案，当点击输入框时默认方案是否消失？
相应的按钮如登录、重置等，是否可用;页面的前进、后退、刷新按钮是否可用？
快捷键Tab,Esc,Enter 等，能否控制使用
兼容性测试：不同浏览器，不同操作系统，不同分辨率下界面是否正常

性能测试
单用户登录系统的响应时间是否符合"3-5-8"原则
用户数在临界点时并发登录是否还能符合"3-5-8"原则
压力：大量并发用户登录，系统的响应时间是多少？系统会出现宕机、内存泄露、cpu饱和、无法登录吗?
稳定性： 系统能否处理并发用户数在临界点以内连续登录N个时的场景？

安全性测试
1.登录成功后生成的Cookie，是否是httponly (否则容易被脚本盗取)
2.用户名和密码是否通过加密的方式，发送给Web服务器
3.用户名和密码的验证，应该是前端验证+服务器端验证， 而不能单单是在客户端用javascript验证
4.用户名和密码的输入框，无SQL 注入攻击风险
5.用户名和密码的的输入框，不能输入脚本 （防止XSS攻击）
6.错误登录的次数限制（防止暴力破解）
7.验证码不能被轻易破解、欺骗

兼容性测试
1.主流的浏览器下能否显示正常
2.不同的操作系统是否能正常工作
3.移动设备上是否正常工作
4.不同的分辨率

易用性测试
1.根据场景，考试是否提供记住用户名密码、自动登录的功能
2.输入账号后，回车登录
连续输入3次或以上错误密码，用记是否被锁一定时间（如：15分钟）？时间内不允许登录，超出时间点是否可以继续登录。

其他测试
用户session过期后，重新登录是否还能重新返回这前session过期的页面？
用户名和密码输入框是事支持键盘快捷键？如：撤销、复制、粘贴等等
是否允许同名用户同时登录进行操作？考虑web和app同时登录
手机登录时，是否先判断网络可用？
手机登录时，是否先判断app存在新版本？
是否支持单点登录？
是否有埋点接口
支付模块的测试
链接：https://blog.csdn.net/jiangbqing/article/details/61917979
正常流程：
　　正常使用支付宝、微信、银行卡（目前使用最多的第三方支付方式）支付（正常金额的支付），功能是否正常。
　　异常流程：
　　1、支付账号和密码错误，系统如何处理；
　　2、余额不足，系统如何处理；
　　3、取消支付，系统如何处理；
　　4、重复支付，系统如何处理；
　　5、微信或支付宝账号未登录时支付，系统如何处理；
　　6、手机上没有支付宝APP时选择支付宝支付，系统如何处理；
　　7、支付期间突然断网，系统如何处理；
　　8、取消支付后再次支付，系统如何处理；
　　9、金额上：最小值金额的支付，最大值金额的支付，错误金额的支付（如金额格式的错误、不允许使用的货币等等）；
　　搜索功能的测试用例包括哪些？
功能测试

搜索内容为空，验证系统如何处理
搜索内容为空格，查看系统如何处理
边界值验证：在允许的字符串范围内外，验证系统的处理
超长字符串输入，系统是否会截取允许的长度来检验结果
合法的字符串长度后，加空格验证检索结果
多关键字中间加入空格，逗号，tab验证系统的结果是否正确
验证每种合法的输入，结果是否正确
是否支持检索内容的复制、粘贴、编辑等操作
是否支持回车键搜索
多次输入相同的内容，查看系统的检索结果是否一致
特殊字符、转义字符、html脚本等需要做处理
敏感词汇，提示用户无权限等
输入的内容是否支持快捷键操作等
只能输入允许的字符串长度等
输入链接是否正确跳转，
搜索的历史纪录是否显示在下面
搜索内容有没有联想功能
界面测试

查看UI是否显示正确，布局是否合理
是否有错别字
搜索结果显示的布局是否美观
已查看的结果链接，链接的颜色要灰化处理，
结果数量庞大时，页面的分页布局是否合理
安全性测试

脚本的禁用
SQL的注入，检索SQL SELECT语句等
敏感内容的检索是禁止的
特殊字符的检索
被删除、加密、授权的数据，不允许被查出来，是否有安全设计控制
兼容性测试

多平台Windows，mac
移动平台android，ios
多浏览器火狐、chrome、IE等
性能测试

搜索页面的链接打开速度是否满足设计要求
搜索出结果消耗时间，是否满足设计要求

如何设计一个好的测试case
链接：http://www.sohu.com/a/247756141_165433

“好的”测试用例一定是一个完备的集合，它能够覆盖所有等价类以及各种边界值，而跟能否发现缺陷无关。
一个“好的”测试用例，必须具备以下三个特征。

1.整体完备性：“好的”测试用例一定是一个完备的整体，是有效测试用例组成的集合，能够完全覆盖测试需求。

2.等价类划分的准确性：指的是对于每个等价类都能保证只要其中一个输入测试通过，其他输入也一定测试通过。

3.等价类集合的完备性：需要保证所有可能的边界值和边界条件都已经正确识别。

做到了以上三点，就可以肯定测试是充分且完备的，即做到了完整的测试需求覆盖。
压力测试，负载测试和性能测试关系？
链接：http://www.51testing.com/html/06/n-3721106.html
性能测试是动力，负载测试载重，压力测试强度

压力测试stresstest：是在一定的负荷条件下，长时间连续运行系统给系统性能造成的影响。

负载测试Loadtest：在一定的工作负荷下，给系统造成的负荷及系统响应的时间。
测试计划都包括什么？
1.概述 1.1 编写目的 1.2 项目背景 1.3 项目质量目标 1.4 预期读者 1.5 参考资料
2.测试环境 2.1 系统架构 2.2 软硬件环境要求 2.3 测试环境部署图
3.测试规划 3.1 测试范围 3.2 测试工具 3.3 人员、角色及职责
4.测试策略 4.1 系统框测试 4.2 业务流程测试 4.3 功能点测试 4.4 UI界面测试 4.5 性能测试 4.6 兼容性测试 4.7 安全测试
5.测试进度安排
6.工作汇报
web测试和手机测试有什么区别
WEB测试和App测试从流程上来说，没有区别。都需要经历测试计划方案，用例设计，测试执行，缺陷管理，测试报告等相关活动。从技术上来说，WEB测试和APP测试其测试类型也基本相似，都需要进行功能测试、性能测试、安全性测试、GUI测试等测试类型。

他们的主要区别在于具体测试的细节和方法有区别，比如：性能测试，在WEB测试只需要测试响应时间这个要素，在App测试中还需要考虑流量测试和耗电量测试。

兼容性测试：在WEB端是兼容浏览器，在App端兼容的是手机设备。而且相对应的兼容性测试工具也不相同，WEB因为是测试兼容浏览器，所以需要使用不同的浏览器进行兼容性测试（常见的是兼容IE6，IE8，chrome，firefox）如果是手机端，那么就需要兼容不同品牌，不同分辨率，不同android版本甚至不同操作系统的兼容。（常见的兼容方式是兼容市场占用率前N位的手机即可），有时候也可以使用到兼容性测试工具，但WEB兼容性工具多用IETester等工具，而App兼容性测试会使用Testin这样的商业工具也可以做测试。

安装测试：WEB测试基本上没有客户端层面的安装测试，但是App测试是存在客户端层面的安装测试，那么就具备相关的测试点。

还有，App测试基于手机设备，还有一些手机设备的专项测试。如交叉事件测试，操作类型测试，网络测试（弱网测试，网络切换）

交叉事件测试：就是在操作某个软件的时候，来电话、来短信，电量不足提示等外部事件。

操作类型测试：如横屏测试，手势测试

网络测试：包含弱网和网络切换测试。需要测试弱网所造成的用户体验，重点要考虑回退和刷新是否会造成二次提交。弱网络的模拟，据说可以用360wifi实现设置。

从系统架构的层面，WEB测试只要更新了服务器端，客户端就会同步会更新。而且客户端是可以保证每一个用户的客户端完全一致的。但是APP端是不能够保证完全一致的，除非用户更新客户端。如果是APP下修改了服务器端，意味着客户端用户所使用的核心版本都需要进行回归测试一遍。

还有升级测试：升级测试的提醒机制，升级取消是否会影响原有功能的使用，升级后用户数据是否被清除了。

selenium 和 Appium 是怎么联系的?有什么关系?
一 、 selenium是专门做web端的自动化测试工具
Selenium与其他测试工具相比，最大好处是：

Selenium 测试直接在浏览器中运行，就像真实用户所做的一样。Selenium 测试可以在 Windows、Linux 和 Macintosh上的 Internet Explorer、Chrome和 Firefox 中运行。其他测试工具都不能覆盖如此多的平台。使用 Selenium 和在浏览器中运行测试还有很多其他好处。

下面是主要的两大好处：

通过编写模仿用户操作的 Selenium 测试脚本，可以从终端用户的角度来测试应用程序。通过在不同浏览器中运行测试，**更容易发现浏览器的不兼容性。**Selenium 的核心，也称browser bot，是用 JavaScript 编写的。这使得测试脚本可以在受支持的浏览器中运行。browser bot 负责执行从测试脚本接收到的命令，测试脚本要么是用 HTML 的表布局编写的，要么是使用一种受支持的编程语言编写的。

二 、appium是手机app端的自动化，它继承了webdriver(也就是selenium 2)
不过appium仍然需要通过selenium最后做测试工具，但是appium起到了一个连接手机端非常好的桥梁工作！可以连接到电脑上非常方便的调用selenium工具来做测试。

Selenium 1.0版包括三个部分，分别是Selenium IDE（插件，用于录屏，并转化代码）、Selenium Grid（扩展工具集）和Selenium RC（Remote Controller），其中最主要部分为Selenium RC。

但是Selenium与WebDriver合并后，Selenium2.0就等价为WebDriver了，所以学习Selenium2.0的话，相当于主要学习WebDriver API了。

3.0版本直到2016年才发布，该版本彻底移出了Selenium RC，对开发环境也有了限制（例如只支持jvav8以上版本，对不同的浏览器也有最低版本要求）。相对而言，2.0版的通用性更高
软件测试风险分析

测试策略有哪些？
链接：https://blog.csdn.net/hongfuqiang/article/details/78786187

设计系统测试需要参考的项目文档
软件测试计划
软件需求规范
迭代计划
测试过程中输出的文档
测试计划，测试文档，测试用例，测试日志，bug报告，测试总结报告
软件质量评估指标
1、功能性的质量指标
　　功能的正确性：系统功能和用户的实际需求、已定义的产品规范一致。
　　功能的准确性：系统产生的结果在精度允许的误差范围内。
　　功能的完整性：所有功能及其定义清楚、可用。
　　2、可用性的质量指标
　　可操作性：容易使用和操作，包括理解用户界面、适应一些特殊用户的可选项等。
　　通用性：数据显示、网络通信接口和用户界面等都遵守已有的软件标准。
　　一致性：在软件开发整个生命周期内建立和使用相同的标准，保证全局变量、数据类型、出错处理的命名和使用一致。
　　3、可靠性的质量指标
　　自我恢复能力：当系统的某个功能失效发生时，系统在当前环境下能实现故障自动转移，重新自动配置、继续执行的能力，软件系统具有自我检测、容错、备份等机制，尽量做到独立于硬件的编码、硬件设备之间的通信协议一致等。
　　健壮性：各种恶劣环境（大数据量、大用户量）下系统能正常工作。
　　分布性：软件系统的某些子功能或子系统被定位于不同的处理主机、存储设备。
　　4、性能的质量指标
　　有效性：系统在通信、处理、存储等方面占有很少资源或者对所使用的资源进行了优化。
　　完整性：系统具有良好的安全管理，能防止不安全存取系统、防止数据丢失病毒入侵等。
　　易存取性：对系统的存取权限设置清楚，存取操作方便，存取操作有记录。
　　5、可维护性的质量指标
　　模块化：指讲一个复杂的软件系统分解为分别命名并具备最小耦合性、很强凝聚性、结构化的组件。
　　灵活性：容易为系统增加一个新功能或者新的数据而不需要进行大量的代码修改或者设计修改。
　　可测试性：测试软件组件或者集成产品时查找缺陷的简易程度。
　　可追溯性：对一个特殊需求容易找出相应的代码，反之，也可以根据代码找出特定的需求。
　　兼容性：软件、硬件、通信系统之间协调及兼容其他系统的能力。
　　可解释性：相关文档齐全、符合标准、逻辑清晰、描述准确、用词恰当，容易理解和定位。
　　6、可移植性质量指标
　　适应性：系统不依赖于环境，即系统不做修改或作很少的修改即可运行在其他环境下。
　　易安装性：与在指定的环境下安装软件所需努力有关的软件属性。如在线更新、安装包自动生成等。
　　可重用性：一个软件组件除了在最初开发的系统之外应用于其他系统的能力。
　　互操作性：软件系统与其他系统交换数据和服务的难易程度。
　　可替换性：与软件在该环境中用来替代指定的其他软件的机会和努力有关的软件属性。

测试用例的维护
软件产品的版本是随着软件的升级而不断变化的，而每一次版本的变化都会对测试用例集产生影响，所以测试用例集也需要不断地变更和维护，使之与产品的变化保持一致。以下原因可能导致测试用例变更：

1）软件需求变更：软件需求变更可能导致软件功能的增加、删除、修改等变化，应遵循需求变更控制管理方法，同样变更的测试用例也需要执行变更管理流程。

2）测试需求的遗漏和误解：由于测试需求分析不到位，可能导致测试需求遗漏或者误解，相应的测试用力也要进行变更。特别是对于软件隐性需求，在测试需求分析阶段容易遗漏，而在测试执行过程中被发现，这时需要补充测试用例。

3）测试用例遗漏：在测试过程中，发现测试用例未覆盖全部需求，需要补充相应的测试用例。

4）软件发布后，用户反馈的缺陷：表明测试不全面，存在尚未发现的缺陷，需要补充或者修改测试用例。

对于提供软件服务的产品，其多个版本常常共存，而对应的测试用例也是共存的，而且测试用例需要专人定期维护，并遵循以下原则：

1）及时删除过时的测试用例

需求变更可能导致原有部分测试用例不再适合新的需求要求。例如，删除了某个功能，那么针对该功能的测试用例也不再需要。所以随着需求的每一次变更，都要删除那些不再使用的测试用例。

2）及时删除冗余的测试用例

在设计测试用例时，可能存在两个或者多个用例测试相同内容，降低回归测试效率，所以要定期整理测试用例集，及时删除冗余的测试用例。

3）增加新的测试用例

由于需求变更、用例遗漏或者版本发布后发现缺陷等原因，原有的测试用例集没有完全覆盖软件需求，需要增加新的测试用例。

4）改进测试用例

随着开发工作进行，测试用例不断增加，某些用例随着系统输入和当前状态的变化而变得不再适用，这些用例难以重用，影响回归测试的效率，需要进行改进，使之可重用可控制。

总之，测试用例的维护是一个长期的过程，也是一个不断改进和完善的过程。
生命周期阶段：
软件计划与可行性分析
需求分析
软件设计
编码
软件测试
运行与维护
简述什么是静态测试、动态测试、黑盒测试、白盒测试、α测试 β测试
静态测试是不运行程序本身而寻找程序代码中可能存在的错误或评估程序代码的过程。
动态测试是实际运行被测程序，输入相应的测试实例，检查运行结果与预期结果的差异，判定执行结果是否符合要求，从而检验程序的正确性、可靠性和有效性，并分析系统运行效率和健壮性等性能。
黑盒测试一般用来确认软件功能的正确性和可操作性,目的是检测软件的各个功能是否能得以实现,把被测试的程序当作一个黑盒,不考虑其内部结构,在知道该程序的输入和输出之间的关系或程序功能的情况下,依靠软件规格说明书来确定测试用例和推断测试结果的正确性。
白盒测试根据软件内部的逻辑结构分析来进行测试,是基于代码的测试，测试人员通过阅读程序代码或者通过使用开发工具中的单步调试来判断软件的质量，一般黑盒测试由项目经理在程序员开发中来实现。
α测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试，Alpha测试不能由程序员或测试员完成。
β测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场，Beta测试不能由程序员或测试员完成。
软件测试分为几个阶段 各阶段的测试策略和要求是什么?
测试过程会依次经历单元测试、集成测试、系统测试、验收测试
如何测试一个纸杯？
功能度：用水杯装水看漏不漏；水能不能被喝到
安全性：杯子有没有毒或细菌
可靠性：杯子从不同高度落下的损坏程度
可移植性：杯子在不同的地方、温度等环境下是否都可以正常使用
兼容性：杯子是否能够容纳果汁、白水、酒精、汽油等
易用性：杯子是否烫手、是否有防滑措施、是否方便饮用
用户文档：使用手册是否对杯子的用法、限制、使用条件等有详细描述
疲劳测试：将杯子盛上水（案例一）放24小时检查泄漏时间和情况；盛上汽油（案例二）放24小时检查泄漏时间和情况等
压力测试：用根针并在针上面不断加重量，看压强多大时会穿透
测试计划编写6要素（5W1H）：
why——为什么要进行这些测试；
what—测试哪些方面，不同阶段的工作内容；
when—测试不同阶段的起止时间；
where—相应文档，缺陷的存放位置，测试环境等；
who—项目有关人员组成，安排哪些测试人员进行测试；
how—如何去做，使用哪些测试工具以及测试方法进行测试
一套完整的测试应该由哪些阶段组成？
可行性分析、需求分析、概要设计、详细设计、编码、单元测试、集成测试、系统测试、验收测试
性能测试的流程
1.测试需求分析
2.测试计划制定与评审
3.测试用例设计与开发
4.测试执行与监控
5.分析测试结果
6.编写性能测试报告
7.测试经验总结
您认为性能测试工作的目的是什么?做好性能测试工作的关键是什么?
关键是测试脚本的录制，测试时候测试环境的干净。
自我介绍
面试官您好！我叫xx，做软件测试工作快3年了，在之前的项目当中主要涉及的是功能测试、兼容性测试、接口测试和简单的压力测试，对linux、数据库、fiddle、jmeter的使用比较熟悉，了解一点python语言，今天来贵公司面试的是软件测试的岗位，希望能有机会，谢谢！
离职原因：
我原来在的公司是属于外包公司，现在项目做完了，要把我们调到别的项目组去，但这个项目组不在南京，我又想在南京发展，所以就离职了。
薪资要求：
我对薪资没有硬性要求，我注重的是找工作的机会，所以只要条件公平，我不会计较太多。