软件测试面试过程中常见的问题
1自我介绍：
从业时间 教育背景，工作经验，擅长技能，你的性格
实例 你好，我叫xxx，19年从xxxx大学毕业，18年六月至今在xxx有限公司从事软件测试工作。
主要负责过两个项目：1xxxapp 通过人工智能发现每个人自己喜欢的视频，并可以帮助视频创作人轻松地向全世界分享自己的视频作品
2xxx 利用现有流量，广告资源，精准投放给贷款用户，并推荐贷款超市中的产品
在项目中我负责包括测试用例设计，接口测试，功能测试等；
可以使用Python 编写基本的自动化脚本
（我是一个自律，热爱学习人，有信心做好测试工作）
一 ： 现在软件有一个登录模块，有用户名和密码，以及登录按钮，请你来设计测试用例；*
一般从 用户界面，功能，安全，性能，兼容性方面去考虑；
1：功能测试
1、输入正确的账号和密码，点击提交按钮，验证是否能正确登录。（正常输入）
2、输入错误的账号或者密码, 验证登录会失败，并且提示相应的错误信息。（错误校验）
3、登录成功后能否跳转到正确的页面（低）
4、账号和密码，如果太短或者太长，应该怎么处理（安全性，密码太短时是否有提示）
5、账号和密码，中有特殊字符（比如空格），和其他非英文的情况（是否做了过滤）
6、记住账号的功能
7、登录失败后，不能记录密码的功能
8、账号和密码前后有空格的处理
9、密码是否加密显示（星号圆点等）
10、牵扯到验证码的，还要考虑文字是否扭曲过度导致辨认难度大，考虑颜色（色盲使用者），刷新或换一个按钮是否好用
11、登录页面中的注册、忘记密码，登出用另一帐号登录等链接是否正确
12、输入密码的时候，大写键盘开启的时候要有提示信息。
13、什么都不输入，点击提交按钮，看提示信息。（非空检查）
** 2 界面测试(UI Test)**
1、布局是否合理，2个Testbox 和一个按钮是否对齐
2、Testbox和按钮的长度，高度是否复合要求
3、界面的设计风格是否与UI的设计风格统一
4、界面中的文字简洁易懂，没有错别字。
5、不同的浏览器窗口大小，下面，界面和功能是否正常
3 性能测试(Performance Test)
1、打开登录页面，需要几秒
2 、输入正确的账号和密码后，登录成功跳转到新页面，不超过5秒
** 4 安全性测试(Security Test)**
1、登录成功后生成的Cookie是否有HttpOnly(降低脚本盗取风险)
2、账号和密码是否通过加密的方式，发送给Web服务器
3、账号和密码的验证，应该是用服务器端验证，而不能单单是在客户端用javaScript验证
4、账号和密码的输入框，应该屏蔽SQL注入攻击
5、账号和密码的的输入框，应该禁止输入脚本（防止XSS攻击）
6、错误登录的次数限制（防止暴力破解）
7、考虑是否支持多用户在同一机器上登录；
8、考虑一用户在多台机器上登录
** 5 可用性测试(Usability Test)**
1、是否可以全用键盘操作，是否有快捷键
2、输入账号，密码后按回车，是否可以登录
3、输入框是否可以以Tab键切换
7 兼容性测试（Compatibility Test）
1、主流的浏览器下能否显示正常已经功能正常（IE6~11, FireFox, Chrome, Safari 等 ）
2、不同的平台是否能正常工作，比如Windows, Mac
3、移动设备上是否正常工作，比如iPhone, Android
4、不同的分辨率
** 8 本地化测试 （Localization Test）**
1、不同语言环境下，页面的显示是否正确。
** 9软件辅助性测试 （Accessibility Test）**
软件辅助功能测试是指测试软件是否向残疾用户提供足够的辅助功能
1、高对比度下能否显示正常（视力不好的人使用）
二: linux常用命令有哪些？
cd命令：切换到某个目录
ls命令：列出当前目录的所有文件、文件夹
pwd命令：列出当前目录的路径
cp命令：复制
mv命令：剪切
grep命令：管道
find命令：查找
rm命令：删除
ps命令：查看进程
kill命令：杀掉某个进程
cat命令：查看某文件
tar命令：打包
chmod命令：赋权限
chown命令：改变文件的所有者
vim命令：文本编辑
三 测试过程中遇到app出现crash或者ANR，你会怎么处理？
参考答案：可以先把日志过滤出来： adb logcat | findstr xxxxx(过滤日志信息) ，然后再搜索其中的关键字，比如：exception、crash，看看是那些方法或者异常导致了问题的发送，初步定位问题原因后，可以交给开发人员去具体查找深层原因并修复。
四 你觉得app的性能测试，即专项测试，需要重点关注那些方面？
参考答案：内存、cpu占用、耗电量、流量、流畅度等
五 工作这些年，你印象最深的BUG是什么？
之前遇到过一个，在win7系统下每个主流浏览器都是正常的，但是线上有用户反馈提交不了，我们每个人测试都是可以的，，后来才发现，是系统不兼容，，他是在xp系统下，在后来在后面的测试中，我的计算机里面都会安装一个虚拟机，里面装各种版本的系统（win7 32，64，xp，win10 32，64等）
六 某个用户反馈，图片加载不出来，你的定位思路?
1、第一时间先在线上复现下，看能否复现，如果能复现该抓包的抓包，该查日志的查日志。
2、如果1里面不能解决的，需要让客服去搜集下这个用户所处的环境，例如是手机的话，问下他的手机是什么型号的，如果是APP的话，问下安装的APP是哪个版本的，还有一些唯一标识，可以让我们查到这个用户信息的东西，例如用户ID什么的。曾经发现过类似的问题，用户手机是小米手机，小米自带的浏览器把我们分享的图片当成广告给屏蔽了，然后把小米手机浏览器屏蔽广告的功能关闭就好了，但是根本的原因是图片的链接带了铭感词被检测到了，后来更换了链接就解决了这个问题
3、如果1和2都不能解决，大部分的情况其实还是和网络有关系，模拟下弱网络的情况（可以通过抓包工具修改网络请求的时间），看是不是这个原因，如果是的话可以先建议用户换成更好的网络环境试试，然后再通知开发研究下这个地方如何去优化。
4、如果上述还不能解决的话还要具体问题具体去排查，整体思路就是如上的思路，尽可能找出必现路径，有时候可能遇到多了就有经验了，一下就能排查到原因了
七 介绍公司的测试流程？
分析需求，分解需求→制定测试计划→设计测试用例→执行测试用例→提交bug→验证bug→测试报告→测试总结、
首先会召开需求分析会议，参加人员有产品、开发和测试，主要是探讨需求主要的一些功能点；然后开发就排期进行开发，主管开始编写测试计划，对我们进行任务分配。
我们参考需求规格说明书及原型图编写测试用例，写完之后会进行用例评审，有评审修改的就修改整理形成最终的用例版本；开发人员版本编译完成后，我们会先进行预测，主要对主功能业务进行测试，如果主业务流程不通过，直接返回给开发进行修改。预测通过，依据测试用例进行系统测试。测试过程中，提交bug，跟踪bug，进行回归测试直至不存在严重bug，满足用户需求，测试完后编写测试报告；产品发布上线后，关注web是否正常运行，要进行常规的维护性测试。
八 公司的bug管理流程
发现bug→确认是否是bug→定位bug→提交bug→验证bug→测试报告→bug总结
九 测试用例通常包括那些内容？
不同结构的用例包括的不一样。（版本、编号、项目、设计人员、设计日期、输入、预期输出„„）
软件测试用例的基本要素包括测试用例编号、测试标题、重要级别、测试输入、操作步骤、预期结果。
编号、模块名称、重要级别、日期、操作步骤（说明）、输入数据、预期结果，编写人，等。
十 测试项目：杯子
需求测试:查看杯子使用说明书
界面测试:查看杯子外观
功能度：用水杯装水看漏不漏；水能不能被喝到
安全性：杯子有没有毒或细菌
可靠性：杯子从不同高度落下的损坏程度
可移植性：杯子再不同的地方、温度等环境下是否都可以正常使用
兼容性：杯子是否能够容纳果汁、白水、酒精、汽油等
易用性：杯子是否烫手、是否有防滑措施、是否方便饮用
用户文档：使用手册是否对杯子的用法、限制、使用条件等有详细描述
疲劳测试：将杯子盛上水（案例一）放24小时检查泄漏时间和情况；
盛上汽油（案例二）放24小时检查泄漏时间和情况等
压力测试：用根针并在针上面不断加重量，看压强多大时会穿透
跌落测试:？？ 杯子加包装(有填充物)，在多高的情况摔下不破损
震动测试: 杯子加包装(有填充物)，六面震动，检查产品是否能应对恶劣的铁路\公路\航空运输
测试数据：
测试数据具体编写此处略（最讨厌写测试数据了）。其中应用到：场景法、等价类划分法、因果图法、错误推测法、边界值法等方法
期望输出：
该期望输出需查阅国标、行标以及使用用户的需求
说明书测试: 检查说明书书写准确性
、写过测试计划或者是测试报告么？测试计划包括哪些主要步骤和信息？测试报告包括哪些内容？
测试报告交付文档有哪些？
答：写过；1、测试计划包括：项目信息、参与文档、测试范围、测试策略、测试时间人员安排、测试环境；2、测试报告包含：项目背景、参考资料、测试范围、测试结果及缺陷分析、测试结论与建议，风险评估； 3、交付文档：主要是测试用例、测试计划、测试报告
1、软件质量特征可以从5个方面描述，分别是哪些方面？
1）.功能性：当软件在指定条件下使用时，软件产品提供满足明确和隐含需要的功能的能力
2）.可靠性：在指定条件下使用时，软件产品维持规定的性能级别的能力
3）.易用性：在指定条件下使用时，软件产品被理解、学习、使用和吸引用户的能力
4）.效率：在规定 条件下，相对于多用资源的数量，软件产品可 提供适当性能的能力
5）.可维护性：软件产品可被修改的能力，修改可能包括纠正、改进或软件对环境、需求和功能规约变化的适应程度
6).可移植性：软件产品从一种环境迁移到另一种环境的能力。
2、测试的依据主要有哪些？
需求说明书，概要设计，详细设计
测试的种类有哪些？
答:功能测试，性能测试，兼容性测试，安全性测试，易用性测试，接口测试，web测试，APP测试
.web测试和app测试的区别？
1.1web项目，一般都是b/s架构，基于浏览器的，而app则是c/s的，必须要有客户端。
1.2系统架构来看的话，web测试只要更新了服务器端，客户端就会同步会更新。而且客户端是可以保证每一个用户的客户端完全一致的。但是app端是不能够保证完全一致的，除非用户更新客户端。如果是app下修改了服务端，意味着客户端用户所使用的核心版本都需要进行回归测试一遍。
1.3性能方面，web页面可能只会关注响应时间，而app则还需要关心流量、电量、CPU、GPU、Memory。FPS，内存泄露，内存溢出等
1.3性能方面，web页面可能只会关注响应时间，而app则还需要关心流量、电量、CPU、GPU、Memory。FPS，内存泄露，内存溢出等。
1.4兼容方面，web是基于浏览器的，所以更倾向于浏览器和电脑硬件，电脑系统的方向的兼容，不过一般还是以浏览器的为主。而浏览器的兼容则是一般是选择不同的浏览器内核进行测试（IE、chrome、Firefox），目前web测试也要考虑在手机浏览器的兼容性。app的测试则必须依赖phone或者是pad，不仅要看分辨率，屏幕尺寸，还要看设备系统。系统总的来说也就分为Android和iOS，不过国内的Android的定制系统太多，也是比较容易出现问题的。一般app的兼容测试三种方法，云测试，请团队测试，真机测试真机的选择。首先要选择主流的机型，其次要选择不同的分辨率，尺寸，然后就是不同的操作系统。
1.5相比较web测试，app更是多了一些专项测试：
1.5.1健壮性测试：
一些异常场景的考虑以及弱网络测试。这里的异常场景就是中断，来电，短信，关机，重启等。
而弱网测试是app测试中必须执行的一项测试。包含弱网和网络切换测试。需要测试弱网所造成的用户体验，重点要考虑回退和刷新是否会造成二次提交。需要测试丢包，延时的处理机制。避免用户的流失。这些在前面的弱网测试那篇已经讲过，这里不再讲了。
1.5.2安装、卸载、更新：
web测试是基于浏览器的所以不必考虑这些。而app是客户端的，则必须测试安装、更新、卸载。除了常规的安装、更新、卸载还要考虑到异常场景。包括安装时的中断、弱网、安装后删除安装文件，更新的强制更新与非强制更新、增量包更新、断点续传、弱网，卸载后删除app相关的文件等等。这里讲起来的话太多了，如果有疑问的同学可以评论或者给我留言。
1.5.3界面操作：
现在app产品的用户都是使用的触摸屏手机，所以测试的时候还要注意手势，横竖屏切换，多点触控，事件触发区域等测试
1.6自动化来讲，web大多用的selenium、webdriver，而app则是appium。
1.7性能使用的工具web则是LR，app使用Jmeter要多一点。
1.8 安全测试，app 安装包是否可反编译代码、安装包是否签名、权限设置，用户名等是否进行了隐藏等。web则要关注，sql注入，xss攻击等。
1.9 边界测试，app测试比如sd不足，飞行模式等。web则不需要考虑这些
1.10权限测试，app需要获取用户的很多权限，但是web获取了用户极少数的权限就可以等等。
.如何跟踪线上用户反馈bug？
1.首先收到 bug，确认是否是bug，复现bug
2.确认是bug要对bug进行记录，
3.通知产品，告知开发，商量解决方案
4.协助运维去查看日志
5.解决bug，测试环境验证，集成验证
6.告知用户，体验解决
7.和产品运营等确认是否需要给用户赔偿
8.记录bug处理过程，分析原因，组织相关人员进行回顾
9.思考测试过程中不足，总结经验教训。
可能影响压力测试的因素
1、网络带宽
在压力测试中，有时候要模拟大量的用户请求，如果单位时间内传递的数据包过大，超过了带宽的传输能力，那么就会造成网络资源竞争，间接导致服务端接收到的请求数达不到服务端的处理能力上限。
2、连接池
可用的连接数太少，造成请求等待。连接池一般分为服务器连接池（比如Tomcat）和数据库连接池（或者理解为最大允许连接数也行）。（关于连接池的具体内容，可参考之前的博客：性能测试：连接池和线程）
3、垃圾回收机制
从常见的应用服务器来说，比如Tomcat，因为java的的堆栈内存是动态分配，具体的回收机制是基于算法，如果新生代的Eden和Survivor区频繁的进行Minor GC，老年代的full GC也回收较频繁，那么对TPS 也是有一定影响的，因为垃圾回收其本身就会占用一定的资源。
4、数据库配置
高并发情况下，如果请求数据需要写入数据库，且需要写入多个表的时候，如果数据库的最大连接数不够，或者写入数据的SQL没有索引没有绑定变量，抑或没有主从分离、读写分离等，就会导致数据库事务处理过慢，影响到TPS。
5、通信连接机制
串行、并行、长连接、管道连接等，不同的连接情况，也间接的会对TPS造成影响。（关于协议的连接，可参考之前的博客：HTTP协议进阶：连接管理）
6、硬件资源(服务器 和 压测机)
包括CPU（配置、使用率等）、内存（占用率等）、磁盘（I/O、页交换等）。
7、压力机
比如jmeter，单机负载能力有限，如果需要模拟的用户请求数超过其负载极限，也会间接影响TPS（这个时候就需要进行分布式压测来解决其单机负载的问题）。
8、压测脚本
还是以jemter举个例子，之前工作中同事遇到的，进行阶梯式加压测试，最大的模拟请求数超过了设置的线程数，导致线程不足。
提到这个原因，想表达意思是：有时候测试脚本参数配置等原因，也会影响测试结果。
9、业务逻辑
业务解耦度较低，较为复杂，整个事务处理线被拉长导致的问题。
10、系统架构
比如是否有缓存服务，缓存服务器配置，缓存命中率、缓存穿透以及缓存过期等，都会影响到测试结果。
无头浏览器的应用场景
无头浏览器即headless browser，是一种没有界面的浏览器。既然是浏览器那么浏览器该有的东西它都应该有，只是看不到界面而已
网络爬虫，GUI 自动化功能测试， 页面监控
做并发的聚合点
右键点击 step1---->定时器---->Synchronizing Timer。（集合够多少用户开始访问）
软件测试过程中，测试数据准备的痛点有哪些
On-the-fly 测试数据准备的时间消耗 ，2 Out-of-box 测试数据的“脏数据”
3 测试数据本身组合的复杂性和多样性
4 性能测试数据准备的时间消耗
5微服务化后，跨多个微服务的数据准备缺乏完整的知识体系
6微服务化后，测试数据准备的环境依赖性
如果有一个登录接口需要服务端返回参数，再带着这个参数去请求才能完成登录，请问jmeter怎么做？
新建线程组—新建http请求–添加后置处理器–添加正则表达式提取token----新建登录http请求—参数引用token
如何做接口测试
接口测试常见问题
（1）传入参数处理不当，导致程序异常；
（2）类型溢出，导致数据读出和写入不一致；
（3）因对象权限未进行校验，可以访问其他用户敏感信息；
（4）状态处理不当，导致逻辑出现错乱；
（5）逻辑校验不完善，可利用漏洞获取非正当利益等
接口测试场景设计
- 接口文档的规范性检查
- 接口前置的检查
- 接口逻辑实现功能的检查
- 请求参数合法性的检查
- 请求参数属性的检查
- 请求参数异常处理的检查
- 响应体的结构性检查
- 响应数据的正确性检查
- 异常响应的检查
- 响应图片的检查
- 对旧版本的兼容性检查
- 业务逻辑中的角色权限检查
- 业务逻辑中的参数依赖性检查
接口用例设计
一个接口通常是有输入输出的，输入就是我们常见的入参，输出则时有时无。调用相关接口，接口会执行相关处理逻辑。
接口测试的用例设计，主要从输入和接口处理两方面考虑：
1）针对输入，可按照参数类型进行设计；
2）针对接口处理，可按照逻辑进行用例设计；
3）针对输出，可根据结果进行分析设计