上线复盘会，你们都讨论些什么？
（上线复盘会就是产品上线之后出现一些问题，需要做的处理方式和总结）
统计一个周期内，在线上环境中，爆出的bug数量，这些bug主要在那些环境中分布、出现，以后会怎么避免，比如，这些爆出的bug，主要是开发的失误导致的，这个会议其实也是给开发打一个预防针，避免问题的再次发生，然后就是针对产生的这些bug，相应的引起了哪些消极影响，比如给公司造成了哪些损失，后续是怎么处理的。
项目验收之前还要做什么？
你们在做回归测试，一般使用什么策略呢？
回归测试我们主要是有两个策略，第一个是我们要通过开发给的影响性分析，然后去回归新开发的功能会不会影响到之前的老功能，还有一个策略是，等着所有的功能开发完之后，我们会对整个系统挑选一部分测试用例进行测试，这些挑选的测试用例主要还是开发提供的影响性分析报告，然后我们会根据他们提供的范围去筛选之前我们老的功能进行一个回归。
之前项目有没有遇到延期的？
我之前做的几个项目中，其中有一个项目有延期的。当时是因为我们项目的需求一直在整改包括测试环境一直反复的崩溃,还有开发这边拖延了。所以导致我们当时没办法按时交付。
功能测试的步骤
查看功能需求，针对这个功能点使用合适的用例设计方法编写用例，注意正面和反面用例的覆盖，然后执行用例发现缺陷后提交缺陷等待缺陷修复。修复后对缺陷进行复测关闭。编写测试报告。
编写测试分析报告
目的，背景，分析用例编写和执行情况（用例总数，执行数量，通过率），缺陷的统计分析
（缺陷的严重级别分布，缺陷的状态分布，缺陷的模块分布，缺陷的类型，缺陷的提交人， 缺陷的负责人。。。
你们项目的迭代周期一般多长时间？
项目初始时候的迭代周期一般长一些，大概一两个月，后面根据迭代的功能和修改的缺陷时间逐渐缩短，一般一两周一个迭代周期，项目上线前期甚至一周就一两个版本。我们这个项目大概迭代了10 几个版本。
请问你们的测试退出或结束的标准是什么？你们系统上线后是如何组织测试的？
我们公司的测试结束的标准是公司制定的质量标准，通常是：
1. 测试用例对需求功能点的覆盖达到 100%
2. 测试用例执行率达到 90%以上
3.发现的致命、严重级别的缺陷修复率为 100%（都得到修复）
4.发现的一般和轻微的缺陷修复率达到 90%（遗留的缺陷不能影响用户的正常使用，
可以推迟到下一个版本进行修改）
在最近一轮的回归测试中未发现致命和严重级别的缺陷。
系统上线之后就是正式的环境，一般我们会在上面做一些验证的工作，通过一个特定的账号跑一下主要流程，完成之后再把测试数据清掉。一般我们不在线上环境做太多的细致的功能测试工作，对应线上环境，我们会有一套用户验收环境（UAT 环境），软硬件环境完全模仿线上环境，如果线上环境出现 bug，我们会现在 UAT 环境和测试环境当22中进行复现，如果不能复现再考虑线上环境和UAT 环境的差异，进行排查定位
简述项目迭代测试注意事项
验证新功能,回归测试老功能,配合产品经理做好验收测试，做好应急预案,迭代上线出现问题准备预案，版本回退等
测试的整个周期（阶段）
答：初始阶段（需求分析）-计划阶段（测试计划）-设计阶段（设计测试用例，自动化测试脚本，测试工具的选用）-执行阶段（功能/性能/兼容）-总结评估阶段（报告，上线部署，文档资料手机归档）
怎么保证用例覆盖率百分百
答：百分百是不可能做到的，只能是提升更高的覆盖率。需要做到详细阅读理解需求及各测试计划书中提及的相关文档，多举正用例，反用例以及结合被测模块特点使用对应测试用例设计方法 。
你们接口测试的用例是怎么写的？
你一天大概能写多少条测试用例？
按照我目前的能力，依照系统的复杂度来看，通常一天可以写一百多条，如果是需求有模糊不清的地方或者业务比较复杂，可能写的会少一些，几十条吧。
写了多少条用例
我上一个项目，系统是两周一个版本，用例是根据需求来的，需求多的话，用例就多，需求少，用例就少。我们两周一个版本的话，一般2到3天就会进行一次用例的设计和需求的分析。是根据需求来的，用例不固定。像我一个版本写个几十条左右。（例如18页的需求分析文档，对应的用例大概在200条，发现缺陷在30个左右。一页文档一般写10条用例左右。）
10：用例写多久
我们目前是两周一个版本，一般2-3天需求的评审和用例的设计，再3天用于用例的执行。3天时间进行回归。剩下的时间就是进行上线的验证。
11：你认为做好测试用例工作的关键是什么？
需求和设计文档的理解程度，对系统的熟悉程度
12：黑盒测试的方法有哪些
答：就是用例的设计方法，有等价类划分，边界值分析，场景法，因果图法，判定表法等等
接口测试
1：API是什么
接口API文档就是接口文档 会有对相关接口的说明
2：如何利用接口批量造数据？
CSV数据参数化，JDBC数据库
3：你们接口测试的用例是怎么写的？
针对入参和出参成功的和各种异常的情景都要覆盖。
4：你们是怎么设计接口测试用例的（你们是怎么来测试接口的）
我们会依据接口文档来提取测试点，一般会从功能，业务逻辑，异常和安全方面去考虑，来编写测试用例，
功能的主要是验证接口功能的正确性
业务逻辑主要是看接口之间的业务依赖关系
异常主要是从请求参数异常以及参数值的异常来考虑，必填参数不传，参数值为空，超过规定长度，不符合类型规范，特殊字符等，安全方面主要从对接口加密参数的解析方面考虑。
5：接口测试怎么做
拿到XX模块xx接口的接口文档，查看接口说明和url地址以及http请求，继续查看入参和出参的数据类型和说明。根据业务和入参出参设计接口测试用例。使用XX工具将url地址和http请求填写到工具，填写测试用例使用的入参，模拟执行发送入参数据包。查看数据包返回值是否和预期结果相同。入参有。。。。出参有。。。
4：http 协议的组成有哪些？
HTTP 请求由三部分组成，分别是：请求行、请求消息报头、请求正文
HTTP 响应也是由三部分组成，分别是：响应行、响应消息报头、响应正文
5：怎么做压力测试
答：（老师口述我打下来的）如果需要做压力测试的话，例如我用的是jmeter，首先是要在jmeter里添加我压力测试是基于针对什么功能做的压力测试。比如说我想测的是提交订单的压力测试或者是登录的压力测试等等。那我需要的是先给我被测的程序和服务器施加一个压力。施加压力的话，是可以去取各种各样的取样器，添加线程数，增加对服务器的压力。增加压力后，就需要运行压力测试。运行压力测试之后，需要添加报告。例如接口测试，就是添加的查看结果树。如果用的是jmeter添加的就是聚合报告，聚合报告添加后，做了压力测试。可以从报告里看见我现在做的这个测试，具体响应时间，最大响应时间，最小响应时间，以及平均响应时间。包括还有并发数 吞吐量 吞吐率 丢包率 成功率 失败率 从吞吐量和吞吐率就能看出这个性能好不好了。
（这是老师给的简洁答案）jmeter 聚合报告辅助查看系统日志重启间隔时间
性能指标：并发数 响应时间 吞吐量 吞吐率 丢包率 成功率 失败率
LoadRunner controller使用目标达成场景 设定场景（压力）关注系统日志查看重启间隔时间
性能指标：analyze报告中关注 并发数 响应时间 吞吐量 吞吐率 丢包率 成功率 失败率
6：功能测试和接口测试的区别？
答：因为接口测试其实也是一种功能测试。您是想问登录界面的功能测试和登录接口测试的区别吗？
人工岗注重界面元素的正确性（需求）和数据回显（数据库）和正确的流程走向例如审核的几种分支情况下拉框
自动岗注重数据计算（重点难点）
7：如何判断接口测试的结果是否正确？
我们通常会使用Jmeter 来作为接口测试的工具，我们可以通过在 Jmeter 中使用响应断言来判断接口的返回结果是否符合我们的预期，以此来确定接口测试结果的正确性。响应断言可以判断响应码，响应信息和响应体中的信息，获取信息后与我们预期的结果做比较，一致则表明结果是正确的，不一致则判定为失败。
8：在项目当中一般什么时候开始做接口测试？
在我们的项目中，需求确定后，一般前端和后端开发人员会同时进行开发，接口开发完成并
发布后我们就开始进行接口测试，而不需要等前端页面完成，这样就可以尽早的进行软件测试，我们的接口测试完成后，前端再调用接口的时候就可以节省联调的时间。
BUG
1：bug的周期
答：提交-确认-分配-修复-复测-关闭
2：禅道怎么提交bug的
答：提交缺陷的标题/模块/软件版本/优先级/重要级别/重现步骤/预期结果/实际结果/附件。。。。
3：你印象中最深的 bug
答：1.在一次 Web 测试中，我发现页面上少了几个控件，后来才知道，只有火狐浏览器有这个 问题，换别的浏览器，就没这个问题。是一个兼容性的Bug.
2.我记得有这样一个 bug 印象比较深刻，就是做数据导出到excel的时候,其中的身份证号显示为科学记数法了，4.30E+19，后来发现主要原因是开发在导出到excel时没有对这个字段进行处理，excex中如果超过11位数字就会默认以科学记数法显示，如果显示正确，应该以文本的格式保存。
4：你提的一个bug开发不认怎么办
首先再复测重现一遍，关注测试环境版本号。拿相关截图和开发进行沟通，如果还是无法得到开发的认可，寻求业务/开发的沟通交流，循环到底是开发的理解是正确的还是测试的理解是正确的。
5：如果我有一个在不同手机出现了问题，后端也修复了，还是出现了不同型号上出现了问题，该怎么解决？
答：查看不同型号之间差别在哪里，可能问题是由于不同型号的差别引起的。并且后续版本回归测试在做兼容性测试时会加入不同手机的不同型号的组合测试。
6：如果有一个bug开发认为不是，你怎么处理
解决方法：
a.再次查看我提的bug 根据我的重现步骤 再做一遍
b.继续和开发进行沟通 看是否能发现是测试环境没有提交代码的问题
c.找到业务老师具体询问这个需求到底是偏向于开发的逻辑还是测试的逻辑
7：你曾经一天提交了最多的bug是多少
答：灵活回答，一般10个 5个 6个 10多个都有的。根据项目和模块而定的。回归测试是比较稳定的所以BUG不多。负责的模块业务需求有改变，所以测下来会多点。
8：你平常一提案正常情况下提交了多少bug
答：根据项目和模块而定的
9：如果需求文档，测试点，用例都评审过了，你个人发现了一个bug，你认为对产品有好处，你该怎么处理
答：要提，但是提交时选择优先级和重要级别都最低的缺陷。等待开发如果项目组时间有多余考虑修复
10：有一个建议性的bug，你该怎么处理
答：要提，但是提交时选择优先级和重要级别都最低的缺陷。等待开发如果项目组时间有多余考虑修复
11：如果面试官觉得之前提的bug比较多？
答：因为我们当时版本新加入的功能很多，而且还要对于一些bug进行复测，复测的过程中发现开发之前可能对需求理解的不是很到位。修复bug的时候还是有一些bug复测不通过。然后重新提bug
12：如果这个项目明天必须上线，但是他还有些bug还没修复好。怎么和用户或者甲方解释？
答：虽然我们还有一些bug没有处理，但这些bug是相关于我们下一期会加入的功能模块。本身这个模块到时候我们也是要重做的。所以这些bug我们暂时先没处理。或者答，虽然你现在还看到几个bug没解决，但这些bug本身就是我们测试员提的一些建议型的bug，它优先级别和重要级别都很比较，它是不会影响到用户使用的主流程和常用功能的。所以我们软件还是可以按时上线的。
13：一个不能复现的 bug 需要上报么？
这个问题我们还真的遇到过，一般我们发现的bug 都需要反正求证复现的步骤，确认百分
百复现之后才会上报，但如果遇到比较严重的问题，虽然不能复现，但还是有一定的出现几
率，那么我们也要进行上报，需要提交给开发人员进行定位或者观察，但这种bug 我们一
般会在缺陷报告中标明出现的频率，比如一个手机app 闪退的 bug，出现频率大概 50%。
14：在正式环境中发现了一个 bug，应该如何处理
1. 一般我们接到正式环境的 bug，会先在我们的测试环境中进行确认，如果在测试环境中
存在同样的bug，那么可能就是我们漏测，需要提交缺陷给开发人员进行修复，然后依照
bug的级别和影响由领导来判断是否需要紧急发版。
2. 如果在我们的测试环境没有发现同样的bug，那么我们就需要和 bug 的发现者沟通，看
看是在什么环境和场景下发生的bug，是否所有的线上环境都存在问题，那么可能就是兼容
性的问题，我们也需要汇报给领导来确定是否需要紧急发版解决还是在后续的版本中再解决。
3. 找到和线上发现问题相同的电脑型号，连接测试环境和正式环境都没有发现同样的问题，那
可能就是用户的电脑问题，可以让技术支持人员指导 用户进行 app 的重新安装或者重新换手机来解决
抓包
1：怎么抓包的？
web端的话，直接打开fiddler，打开过滤器，输入要抓取的ip地址，操作我想要被抓取的相应动作，这个时候fiddler就会将我要抓取的信息过滤出来。
2：怎么判断一个 bug 是前端问题还是后端问题
我们一般是通过抓包工具fiddler 来抓取数据包来定位问题到底是前端还是后端的，
1. 如果请求没有发出去或者传入的参数有问题，就是前端的问题；
2. 如果前端传入参数和请求都没问题，后端返回的响应数据有问题，那就是后端的问题；
3. 如果前端传入参数和请求是正确的，后端返回的响应数据也是正确的，那么可能就是前
端处理返回数据的问题。
首先要复测，确定是bug，
3：怎么判断一个bug是前端问题还是后端问题（F12）
1.看页面提示
2.查看前端日志
（浏览器console中查看是否有报错，有报错说明前端在处理数据时挂掉了，无报错说明前端数据正常）
3.抓包看请求响应（Fn+F12里的network或fiddler）
对照接口文档，看请求报文有没问题，有问题就是前端发的数据不对;请求报文没问题，那就看返回报文，返回的数据不对，那就是后端开发的问题
4.查看服务器日志
5.查看数据库数据
4：了解抓包工具么？说说你用抓包工具做什么？
了解，使用过抓包工具fiddler。
1. 抓包工具主要是拦截查看网络数据包内容的软件，分析页面的请求方式，请求的地址，参数,以及 cookie等，还可以用来检测页面的返回状态码设置是否正确，检测网页的跳转。
2.可以设置断点，按照我们的需要临时修改请求和响应的数据。
3.还可以通过设置请求和响应的等待时间来模拟弱网的情况。
4.我们主要用抓包工具来协助我们定位发现的 bug 是前端问题还是后端问题。
性能测试
1：压力测试怎么测
答：压力测试：在给软件施加非常大的压力后，持续关注多久服务器崩溃。关注时间。例：手机银行APP的服务器，做压力测试时使用测试工具模拟较大的并发用户数（Jmeter-线程数，LoadRunner-Vuser),观察服务器的内存CPU占用比达到80-90%，然后无需再加并发用户数持续运行服务器，观察多久服务器重启。
2：性能测试怎么测试
答：性能测试：检测软件性能指标（并发用户数，响应时间）。例：手机银行APP检测通常转账提交后，几秒得到转账结果。
负载测试：检测软件服务器最多能同时承担多少用户并发操作。例：手机银行APP检测商城抢购，最多能承担多少用户同时进行商城下单并且响应时间仍然在3秒内，成功率在90%上。
3：您认为性能测试工作的目的是什么？做好性能测试工作的关键是什么
答：性能测试工作的目的主要就是帮助我们能够检测出项目当中的服务器以及被测软件的性能瓶颈在哪里或者性能指标是怎么样的。比如说事务响应时间，同时最多可以容纳多少用户同时操作。
做好性能测试工作的关键是测试环境尽量贴近实际生产环境
4：响应时间你是怎么测试的？
使用jmeter添加线程组，设定线程数添加取样器。添加查看结果树和聚合报告，在查结果树运行测试。然后在聚合报告可以查看到响应时间
5：怎么做压力测试的，比如300人的压力测试，咋做的？
我们公司是使用jmeter做的压力测试，当时我们弄懂接口测试文档，分清post和get请求，分清哪些必填选项选填项之后，做好接口之间的上下游关系，添加合适的断言等准备工作，就修改了线程组的线程数，然后再添加一个聚合报告就可以执行了
6：性能测试会么？咋做的？
我在我们公司只是用jmeter做了一个简单的压力测试，当时当时我们弄懂接口测试文档，分清post和get请求，分清哪些必填选项选填项之后，做好接口之间的上下游关系，添加合适的断言等准备工作，就修改了线程组的线程数，然后再添加一个聚合报告就可以执行了
7：负载测试和压力测试的主要区别是什么
负载测试和压力测试，都属于性能测试的子集。
负载测试：通常描述一种特定类型的压力测试——增加用户数量以对应用程序进行压力测试。比如 实际中我们说从比较小的负载开始，逐渐增加模拟用户的数量，直到应用程序响应时间超时，就是说的负载测试。
压力测试：压力测试考察当前软硬件环境下系统所能承受的最大负荷并帮助找出系统瓶颈所在
8：比较一下性能测试工具 Jmeter 和 Loadrunner
Jmeter 是开源工具，免费，可以满足一般中小型 web 网站的性能测试，也可以通过外部插件来进行图表结果的获取，资源的监控等，缺点是java 编写，本身执行效率比较低，录制和调试脚本不太方便，对复杂的业务支持不好。
Loadrunner 是性能测试领域目前最知名和最好用的软件，可以方便的进行复杂脚本的录制，手动调试脚本，设置场景执行，监控资源，分析测试结果等，执行效率也比较高，但Loadrunner 属于商业软件，费用比较高，破解也比较困难，对投入成本预算低和对知识产权
保护意识比较强的公司一般不会采用
数据库
1：SQL语句的分组怎么写？查询出年龄和性别，用成绩分组？
答：group by 分组查询 select from 表名
2：左连接和右连接的区别
答：left join 显示出所有左表的内容，如果该内容右表没有会用null填充
right join 显示出所有右表的内容，如果该内容左表没有会用null填充
1：会oraql吗？
答：常用的是MySql,关于数据库SQL语句是互通的，如果公司需要用到Oracle相信也能很快上手。
质量
1：怎么确保软件的质量，具体怎么操作
答：首先要保证我们的测试用例执行率，通过率，缺陷的修复情况。这些都是保证软件质量的操作方法
2：BUG记录包含哪些内容？如何提交高质量的BUG记录
BUG内容包含：BUG标题，bug所属的模块，bug发现的版本号，bug的重现步骤，预期结果，实际结构，bug的重要级别，优先级，bug指派给谁，附件等等
提交高质量的BUG：需求是否明确，前提条件是否满足，输入的数据是否正确，操作步骤是否清楚，BUG是否具有唯一性，避免提交操作错误，重复的或者已知的BUG。
综合
3：您所熟悉的软件测试类型有哪些？请试看分别比较这些不同的测试类型的区别与联系
答：黑盒测试，白盒测试，单元测试，接口测试，功能测试，性能测试，兼容性测试，易用性测试，安全性测试 验收测试等等
区别和联系的：最有关联的是单元测试，集成测试，系统测试以及验收测试 这四个
单元测试是对整个软件当中最小可测单元进行测试
集成测试主要测试重点是软件之间的接口
系统测试是把我们软件当成一个完整的软件系统进行测试
验收测试就是当软件通过了系统测试后，都会做一个验收测试，一般都是让真实用户去测。
4：怎么理解测试工程师的这个岗位。
理解软件理解需求，真正的站在用户的角度知道用户的实际需求。检验检查是否开发按照需求将需求中提到的都在软件上得以实现。
5：你是怎么验证借款人信息是否正确，跟第三方平台合作的嘛？
调用公安网信息和人行征信，保证借款人身份证有效，征信情况。
题：测试数据哪里来的？
a.把需求提交给开发，让开发帮忙铺设到数据库(大银行)
b.测试组会得到数据库增删改权限，可以根据自己的需求在数据库进行数据的铺设（小银行）
6：测试时是否需要测试其他关联系统？
不需要的，测试时其他内部关联系统有测试环境版本，都是稳定的没有问题的。
7：测试时外部关联系统怎么获得数据的？
开发会根据外部关联系统接口做一个挡板模拟程序，测试时使用挡板环境。等到验收测试时用真实外部关联系统进行验收。测试数据模拟在挡板环境中。验收测试会有另外一套验收测试测试数据。
8：测试计划你看嘛？测试计划里有哪些东西？哪些和你有关的？
答：看的，会比较着重看a测试参考文档（因为会关系到我写测试用例时需要依据哪些文档来写）b测试提交文档（关乎到我以后每天工作要不要提交日报要不要提交周报）c资源（会关系到硬件环境软件环境以及人力）d测试进度（这个项目大概要做多久以及写用例是写多久）e测试人员的任务分配（要确认清晰自己主要负责的模块）f测试工具
9：什么是兼容性测试？兼容性测试侧重哪些方面？
兼容测试主要是检查软件在不同的硬件平台、软件平台上是否可以正常的运行，即是通常说的软件的可移植性。
10：我现在有个程序，发现在Windows上运行得很慢，怎么判别是程序存在问题还是软硬件系统存在问题？
1、检查系统是否有中毒的特征；
2、检查软件/硬件的配置是否符合软件的推荐标准；
3、确认当前的系统是否是独立，即没有对外提供什么消耗CPU资源的服务；
4、如果是C/S或者B/S结构的软件，需要检查是不是因为与服务器的连接有问题，或者访问有问题造成的；
5、在系统没有任何负载的情况下，查看性能监视器，确认应用程序对CPU/内存的访问情况。
11：测试的策略有哪些？
黑盒/白盒，静态/动态，手工/自动，冒烟测试，回归测试，公测（Beta测试的策略）
12：软件的评审一般由哪些人参加？其目的是什么？
人员：用户、客户或有关部门开发人员，测试人员，需求分析师都可以，就看处于评审那个阶段
在正式的会议上将软件项目的成果（包括各阶段的文档、产生的代码等）提交给用户、客户或有关部门人员对软件产品进行评审和批准。其目的是找出可能影响软件产品质量、开发过程、维护工作的适用性和环境方面的设计缺陷，并采取补救措施，以及找出在性能、安全性和经济方面的可能的改进。
13：测试活动中，如果发现需求文档不完善或者不准确，怎么处理？
测试需求分析 发现需求文档不完善或者不准确，应该立即和相关人员进行协调交流。
14：测试计划的要素
1.测试目的- 定义测试计划的重点 功能/性能/流程/数据/(易用性/恢复….)
2.测试项目简介-软件产品规格 软件产品信息 软件产品简介主要功能 项目背景 软件面向用户
3.测试参考文档-测试依据以及测试计划编写参考文档 例：需求说明书/概要设计/详细设计/数据库设计/用户手册/开发计划
4.测试提交文档 测试用例/日报周报/缺陷报告/总结报告
5.术语和定义-项目中专业术语的解释
6.测试策略 进入/退出标准
退出：是否提交该轮测试的测试报告，用例执行率，缺陷遗留情况
进入：上一轮测试退出结束
7.确定测试内容-功能/性能/安全等等测试的范围和内容
8.资源-人力资源（角色/人数/职责） 系统资源（硬件/软件）
9.测试进度-各个测试阶段对于人力和系统资源以及时间的安排
10.测试人员的任务分配 -所属模块和负责内容
11.风险和问题 -需求整改/人员流动/测试工程师对业务的了解度/软硬件环境
12.测试工具-测试过程会用到的工具
背大纲就行
1：所有的软件缺陷都能修复吗？所有的软件缺陷都要修复吗？
从技术上讲，所有的软件缺陷都是能够修复的。但不强制要求所有缺陷都要修复。例如这是一个严重型的BUG，影响到功能的使用了，那肯定是必须要修复的。那如果只是一个建议型的BUG，对用户的正常使用和操作没有影响。并且也是下一个版本需要重做的，那这种的如果开发有时间也可以进行修复，如果没时间，也是可以等到下一个版本进行修复的。当然这个还是需要测试人员、项目经理、开发共同讨论来决定是否修复，不同角色的人员从不同的角度来思考，以做出正确的决定。
2：你们的项目团队有多少人？测试人员有几个？如何分工的？
我们的项目团队大概20 多人，其中测试人员 4 个，我们一般都是按照功能模块来进行分工的
3：如何搭建测试环境？你会独立搭建测试环境么？
注：被问到测试环境的时候需要注意当时的情境，因为测试环境一般有两种理解：
一种是我们测试人员自己使用的环境，通常是在windows 下，安装和配置一些常用的软件，
比如java 环境，python 环境，eclipse，jmeter，Loadrunner 等。
还有一种是指服务端的软件运行环境，配置java 运行环境，安装 tomcat 中间件，安装 Mysql 数据库，将 web 应用的 war 包放入 webapps 目录下，解压，重新启动 tomcat 服务器，就可以通过 url 访问我们的 web 软件了。
一般回答第一种就可以了，就说我们的环境和经常用到的软件都是我们自己安装的，问到第
二种的时候就说我们服务端的环境部署有专门的运维人员来做。
4：如何查看系统日志
1. web 端的日志通常保存在数据库中，可以通过连接测试数据库通过 sql 语句来进行 log 日志的查询，有的系统也会保存在服务器端，需要连接 liunx 系统进行查询
2.手机端的如果是安卓系统可以通过 adb 命令来进行日志查看 adb logcat，也可以把日志
抓取到本地来进行查看adb logcat >c:\logcat.txt
3.如果是苹果手机 iOS 端的，需要通过开发环境 x-code 进行查询，所以如果查询苹果手机的日志需要请开发人员协助
冒烟测试
1：冒烟测试是什么？
针对每个版本或每次需求变更后，开发提交测试，在正式测试前，对产品或系统的一次简单的验证性测试，如果冒烟测试不通过，就打回重新提测。
2：冒烟测试的目的
目的是确认软件基本的功能正常，保证软件系统能跑的起来，可以进行后续的正式测试工作。
3：冒烟测试怎么做？
最好的方法，设计出自动化测试脚本，每一次版本更新后都可以去执行脚本验证一下
4：冒烟测试不通过如何通知开发人员
通过邮件的方式，将冒烟测试中发现的问题以报告的形式发给相关开发人员并抄送给领导知晓。
兼容性测试
1：介绍一下你们怎么做兼容性测试的
Web：Web 系统（B/S）主要关注软件系统在不同的浏览器下的运行状况，通常会考虑主流
的浏览器如火狐，谷歌，IE，360，QQ，搜狗等浏览器，也可以同时考虑主流浏览器的不同
版本，通常会依据项目客户提出的要求或者根据软件产品的用户所使用的浏览器，调查数据来
决定测试哪些浏览器的兼容性。我们还会考虑不同操作系统下的系统运行，比如win10，win7，mac，Linux 等
2：测试计划的目的是什么，有哪些内容？哪些文档比较重要？然后你会关注哪些内容。
1.目的是提高测试效率，提升版本质量。
2.包含内容：测试目的，测试项目简介，测试参考文档，测试提交文档，测试策略，术语与定义，资源，确定测试内容，测试进度，测试人员的分配，风险和问题，测试工具。
3.重要的文档：软件产品规格 软件产品信息 软件产品简介主要功能 项目背景 软件面向用户，需求说明书/概要设计/详细设计/数据库设计/用户手册/开发计划，测试用例/日报周报/缺陷报告/总结报告
4.测试参考文档（测试用例的参考文档），测试提交文档（日报周报，缺陷报告），资源（人力和软硬件的环境），测试人员的分配（自己所负责的模块），测试工具（测试过程需要用到的工具）。
3：项目中如何设计用例/项目中考虑哪些测试点
答：1、根据接口规范和产品需求文档来设计2、使用等价类，边界值等方法来写用例3、通过正常流和异常流等方式写测试业务逻辑的用例
主要关注：场景验证，功能组合，异常测试
4：你们是怎么设计接口测试用例的
我们会依据接口文档来提取测试点，一般会从功能，业务逻辑，异常和安全方面去考虑，来
编写测试用例，功能的主要是验证接口功能的正确性，业务逻辑主要是看接口之间的业务依
赖关系，异常主要是从请求参数异常以及参数值的异常来考虑，必填参数不传，参数值为空，
超过规定长度，不符合类型规范，特殊字符等，安全方面主要从对接口加密参数的解析方面
考虑。
5：回归测试怎么做
bug修改，关联功能，新增加功能，修改功能个数,针对bug修复的模块测试上下游,有关联关系的模块验证影响是否彻底修复
6：测试环境谁负责？测试环境会搭建吗？
运维。。。开发
7：冒烟测试跟回归测试的区别
答：冒烟测试就是在一个新版本出来的时候，将软件的全部功能过一遍，看有没有什么大问题。如果功能可以正常运行，不会影响测试进行，那么这个版本就可以真正开始测试了
回归测试就是以前版本中发现的bug在新的版本中验证是否存在且是否引发新的bug。
8：发布时谁来发布
答：测试发布,通过Jenkins发布
9：测试的占比是？
答：接口全做,功能测试占百分之六十,ui占百分之十,接口占百分之三十
10：入职之后怎样开展工作
答：熟悉公司的规章制度,快速了解工作职责,熟悉业务知识,了解业务内容的数据流,业务流，多请教团队成员如产品经理、研发、测试等
11：接口异常怎么做
用fiddler抓包修改请求和响应内容
12：发布环境有多少个？
开发环境，测试环境，生产环境。
13：项目中如何设计用例？项目中考虑哪些测试点？
答：1、根据接口规范和产品需求文档来设计
2、使用等价类，边界值等方法来写用例
3、通过正常流和异常流等方式写测试业务逻辑的用例”
主要关注:场景验证，功能组合，异常测试
14：前端，后端如何测试？如何配合进行测试？
答;1、前端注重页面、功能、兼容。后端注重接口、数据传输、业务的流程是否正确、覆盖是否全面
1、后期做ui自动化模拟真实用户操作主要流程
1：jmeter有哪些参数化
用户自定义的变量，cvs,jdbc,json提取器或者正则表达式，函数小助手，beanshell自定义生成数据
2：测试时间被压缩怎么办？
第一时间告知老大，开风险会议。其次区分被测模块的优先级，对优先级高的模块先测试。第三测试用例可以简化成测试点的分析，在以后的空窗期进行补充。
第四，每日向领导汇报工作进度，以及可能面临的风险。
第五，有空闲的员工，也可辅助测试。
接口测试
1.整理文档开始 <简要说明>
整理需求文档，API文档从需求中整理测试点，根据这些测试点整理测试用例
2. 实际操作
- Postman
根据上面整理测试点。api文档，在postman新建请求，输入对应请求参数，发送请求查看服务返回的结果。根据返回的状态码和返回数据来判断这个接口是否通过。
如果接口上下游关系，可以在Postman的tests面板添加对应js脚本来通过设置变量方式传递参数；
如果接口异常场景比较多，在postman的runner界面中添加csv文件做数据驱动。
- Jmeter
根据上面整理测试点。api文档，在jmeter新建请求，输入对应请求参数， 发送请求添加查看结果树查看服务返回的结果。根据返回的状态码和返回数据来判断这个接口是否通过。
如果接口上下游关系，可以在Jmeter中添加正则表达式提取器或者Json提取器设置变量方式传递参数；
如果接口异常场景比较多，添加csv文件做数据驱动。
也可以在每个请求上添加断言。
-Python
使用Python+Requests+Pytest+Pytest-Html+Logging+openpyxl+Jenkins
发送请求主要使用Requests，
测试用例管理主要使用pytest
测试报告使用pytest-html
断言使用assert
日志模块logging
数据驱动 将数据方式Excel文件中，通过openpyxl 库解析Excel数据文件，将文件内容解析为 list数据结构。
pytest中 pytest的装饰器 parametrize 进行参数化操作。
整个接口自动化操作完成后 将代码使用git服务管理。使用Jenkins 持续集成；
3.执行完成之后 如果有问题，提交bug
4.协助开发定位问题，并等待开发修复bug后进行bug验证，直至bug关闭
发版（打版）：一天两次银行上午9点验证bug，下午5点修复。
测试手机？
功能、性能、兼容、界面、安装下载、安全等等。
之前fiddler做弱网测试？
基本不用，实际工作中路由器一键限流，可以调网络环境，比如说多少kb。
多久更新一次？
大迭代1个月，小迭代2周。根据甲方需求。
平安面试：微服务—-接口测试。
mysql端口号：3306.
oracle端口号：1521.
mssql端口号：1433.
Linux端口号：8080.
fitt端口号：8080.
zhid
汇率：
你们用的软件版本号呢？
你为什么选择这个行业？
之前有朋友做开发的，然后说这个行业比较有前景和发展潜力。
如何看待加班？
我们之前也有加班 但是我们；有调休或者其他福利的。
一天做什么事？
昨天提交问题，1-早上去验证bug，2 在表单上更新状态（解决、未解决）3需要进行测试
简单的二三十条测试用例，复杂的可能就少点了，项目在后期，一天也就发现3-5个bug，隐性的问题。从早测到晚4点左右，然后开个会，有开发和测试，总结一下今天的工作情况，包括bug的处理情况。然后发日报，发版
VT环境，
模拟真实的环境在测试环境中的 和生产完全和生产环境一样 只是增加真实数据。
问二面通过了，可以来上班了，如何谈工资？
如果一样的工资，我换工作有什么意义呢？
我开车上下班油钱停车费都不够呢？
找小江要工资比他家高的图发给招聘。
拆分（有责工资）、不拆分（无责）。
小项目三比一。12个人，3-1个测试，其余开发，还有一个产品。
测试报告：项目简介、测试背景（项目背景和测试环境）、进度执行情况（人员安排，人员分布，测试时间）、用例执行情况（执行率和通过率）、缺陷统计情况（数量多少，重要级别）
测试结论
如果你找的bug，开发不认为是bug，怎么办？
看需求文档，先自己确认下，确认问题是否是同一个版本，找产品老师
如何确定前端和后端问题？
当数据输出请求方式为正确时，但是结果页面显示错误，一定是前端问题；
当数据输出请求已经错误时，得到的结果一定是错误的，一定是后端问题。
什么时候会用到接口测试？
一种是：后端已经开发完毕，前端还没有界面，需要用接口
二种是：前后端都已经搭建完成，需要输入和人输出值的反馈，需要用接口
测试理论知识
1. 测试计划包括什么，谁写的
1引言：目的、背景、范围、定义、参考资料
2. 测试内容：测试功能清单
3. 测试规则：进入准则，暂停/退出准则、测试方法、测试手段、测试要点、测试工具
4. 测试环境：硬件环境、软件环境、特定测试环境要求
5. 项目任务：测试规划，测试设计，测试执行准备，测试执行，测试总结
6. 实施计划：工作量估计、人员安排、进度安排、其它资源需求及安排、可交付工件
7. 风险管理
组长或者经理
2. 测试方案包括什么，谁写的
概述2.被测对象 3.应测试的特性 4.不被测试的特性 5.测试模型 6.测试需求 7.测试设计
组长或者经理
测试计划和测试方案的区别：计划偏向于项目，内容为任务、时间、人员、设备和风险；方案偏向于技术，内容为需求、分析、设计、实现。
3. 需求规格说明书包括说明，谁写的
需求规格说明书包括编写目的，适用范围，定义及关键字， 参考资料，项目流程，软件概述，软件模块，（角色），功能需求
产品经理
4. 测试大纲怎么写的
根据需求编写测试大纲
首先业务下发需求，然后进行需求研读，需求评审。
将需求划分模块，对模块从流程，业务逻辑，栏位、界面划分测试点，编写测试大纲，最后根据测试大纲编写测试案例。
5. 测试报告包括什么，谁写的
测试模块（每个模块里需要记录测试的开始时间、结束时间、测试人员,设计多少用例、通过多少、失败多少、有多少BUG、遗留多少BUG、解决多少BUG、最后对这个模块总结一下）
项目总结，汇报一下测试的大致结果。
遗留和风险，该软件还有什么遗留问题，还有什么风险，都要一一说明
最后评判该软件是否符合上线标准
组长或者经理
6. 回归测试案例谁写的，怎么写的
测试自己写的，一般都是第一轮执行的案例，时间充足就全部回归下，时间不充足就部分回归，择一些主流程案例和出现bug相关的案例
7. 案例从哪些方面去设计
首先根据需求分析，列出功能点，再根据功能点编写案例，设计案例会用到等价类划分法，边界值，场景法、错误推理法等，如果一个栏位字符为数字，会用到等价类划分法，有效等价为数字，无效等价为字母，汉字，特殊符号等，如果栏位字符为8到15个字符，会用到边界值有有效等价，分别测7，8，9，14.15.16，碰到流程类的，会用场景法，如登录流程，会用场景法或者流程图来实际，从正面流程和反面流程来设计，反面流程有用户名错误，密码错误，或者用户名密码都错误，来覆盖所有的点。
8. 案例的要素有哪些
案例包括所属产品、编号、模块名称、案例类型、案列名称、正/反例、前提条件、测试步骤、测试数据、预期结果、实际结果、执行日期、编写人、执行人、备注等
9. 缺陷的管理流程有哪些？
测试人员提交bug，此时状态为激活，流转到对应的开发，开发人员确认是bug，把bug状态改为待解决，修复后把bug状态改为已解决，流转到对应的测试，测试人员再次验证，若修复，关闭bug，若没修复，重新激活bug，直到修复为止。
提交Bug，开发没有时间修复或无法修复，要下个版本修复，延迟处理，需要跟业务确认是否可以延迟，业务同意延迟则延迟，若不同意，找开发沟通尽快修复。
10. 缺陷有哪些状态？
新建、激活，待解决，已解决，关闭
11. 缺陷单的要素有哪些？
所属产品、所属模块、所属项目、指派人、bug标题、bug步骤重现、附件截图、严重程度、优先级等。
12. 提一个缺陷开发不承认怎么办？
首先根据需求重新验证一下，如果确定是bug，再找开发沟通一下，如果开发还是不承认，找产品经理沟通，产品经理确认是bug，让产品经理和开发沟通，如果确认不是bug，让产品经理在bug单上备注一下
13. 你觉得应该如何和开发进行有效的沟通？
需要拿出bug存在的依据耐心的和他沟通，或者是直接当开发的面验证bug的存在
14. 如果业务不同意你提交的缺陷，你如何沟通？
先根据需求重现下bug，耐心讲解bug的影响
15. 需求不完整，你如何测试？
1.务进行沟通，详细了解需求
2.找开发进行沟通，询问是如何开发的，了解需求的细节（针对已经开发出来的软件）
3.查找相关资料，补充需求
4.参考同行的相同产品
5.站在用户的角度参考需要测试点
16. 工作中遇到问题，同事也没有时间帮你，你怎么做？
先自己去解决，然后百度，或者问之前有经验的同事
17. 有没有参加过评审，评审都有谁参加评审？
参加过需求评审和案例评审，一般有测试，开发，产品或业务经理
18. 测试方法有哪些，分别什么时候使用？
白盒测试，黑盒测试，灰盒测试，静态测试，动态测试，手工测试，自动化测试
白盒测试：开发自测
灰盒测试：（接口测试）sit阶段进行测试
系统测试：sit阶段进行测试
验收测试：uat阶段进行测试
自动化测试：一般用来做回归测试
19. 用的什么缺陷管理工具？
禅道，QC
20. 单元，集成，系统测试有什么区别，怎么写测试用例这些测试用例有什么区别？
单元测试是指对软件中的最小可测试单元进行检查和验证；
集成测试也叫组装测试或联合测试。在单元测试的基础上，将所有模块按照设计要求（如根据结构图）组装成为子系统或系统，进行集成测试。
系统测试将已经集成好的软件系统，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起，在实际使用环境下，对计算机系统进行一系列的组装测试和确认测试的工作。
单元测试的粒度最小。集成测试界于单元测试和系统测试之间，起到“桥梁作用”。系统测试的粒度最大，主要测试系统是否符合“需求规格说明书”。系统测试同时也是在经过以上各阶段测试确认之后，把系统完整地模拟客户环境来进行的测试
21. 测试过程中出现了问题，开发不承认，没有错误日志，这个问题也是没有什么规律出现的，没有什么办法模拟，你怎么办？
首先可以跟开发沟通说明问题的确存在，可以重复的操作看能否重现或者让别的同事操作看是否重现，如不能则周期性观察这个问题看是否重现并记录
22. 需求分析从哪些方面进行分析？
首先了解项目背景，了解项目是做什么的，其次再了解系统是做什么的，有哪些模块，测试范围是什么，每个模块之间是否有关联，有什么样的关联，系统的主流程怎么走，还有分析每个模块具体实现的功能，分析测试点，该测哪些点
23. 测试案例编写有哪些方法？
等价类划分法，边界值，场景法，流程图，错误推理法，因果法，判定表等
24. 软件测试质量的标准是什么？
软件符合明确叙述的功能、性能和安全需求，提交版本符合验收测试标准
25. 什么样的测试用例是好的测试用例？
清晰明了，简单易懂；所有测试点都被覆盖
26. 怎么上线的？
Sit测试完毕后出具测试报告，然后由业务人员进行uat测试，uat测试完毕，出具测试报告，上准生产环境测试（测试3-4天，主要测试流程，业务，准生产环境除了IP地址和生产环境不一样，其他都一致）最后由开发上线，业务验证，我们辅助配合。
27. 上线之后发现Bug怎么办？
1. 配合开发修复Bug后验证Bug，排查类似Bug
2. 查找Bug原因
3. 总结Bug原因，寻找解决方式，下次避免类似的Bug产生
跑批是什么意思？，一天跑几次批？
每家银行都要进行跑批 每家银行跑批时间和程序脚本不同 跑批主要做的事情是 清算对账 除此之外还要做的事情是清算活期定期 利息 出报表 报文
总共写了多少条案例，每天写多少？
总共写多少要看项目大小，初级40条，中级60条
28. 每天执行多少条？
要看具体项目的难易程度
面试题（Linux通关必读）
绝对路径用什么符号表示？当前目录、上层目录用什么表示？主目录用什么表示? 切换目录用什么命令？
答案：
绝对路径： 如/etc/init.d
当前目录和上层目录： ./ ../
主目录： ~/
切换目录： cd
怎么查看当前进程？怎么执行退出？怎么查看当前路径？
查看当前进程： ps
执行退出： exit
查看当前路径： pwd
怎么清屏？怎么退出当前命令？怎么执行睡眠？怎么查看当前用户 id？查看指定帮助用什么命令？
答案：
清屏： clear
退出当前命令： ctrl+c 彻底退出
执行睡眠 ： ctrl+z 挂起当前进程fg 恢复后台
查看当前用户 id： ”id“：查看显示目前登陆账户的 uid 和 gid 及所属分组及用户名
查看指定帮助： 如 man adduser 这个很全 而且有例子； adduser —help 这个告诉你一些常用参数； info adduesr；
Ls 命令执行什么功能？ 可以带哪些参数，有什么区别？
答案：
ls 执行的功能： 列出指定目录中的目录，以及文件
哪些参数以及区别： a 所有文件l 详细信息，包括大小字节数，可读可写可执行的权限等
目录创建用什么命令？创建文件用什么命令？复制文件用什么命令？
答案：
创建目录： mkdir
创建文件：典型的如 touch，vi 也可以创建文件，其实只要向一个不存在的文件输出，都会创建文件
复制文件： cp
文件权限修改用什么命令？格式是怎么样的？
答案：
文件权限修改： chmod
格式如下：
chmodu+xfile给file的属主增加执行权限chmodu+xfile给file的属主增加执行权限 chmod 751 file 给 file 的属主分配读、写、执行(7)的权限，给 file 的所在组分配读、执行(5)的权限，给其他用户分配执行(1)的权限
chmodu=rwx,g=rx,o=xfile上例的另一种形式chmodu=rwx,g=rx,o=xfile上例的另一种形式 chmod =r file 为所有用户分配读权限
chmod444file同上例chmod444file同上例 chmod a-wx,a+r file同上例
$ chmod -R u+r directory 递归地给 directory 目录下所有文件和子目录的属主分配读的权限
你在上家公司查看文件内容都用哪些命令？
答案：
vi 文件名 #编辑方式查看，可修改
cat 文件名 #显示全部文件内容
more 文件名 #分页显示文件内容
less 文件名 #与 more 相似，更好的是可以往前翻页
tail 文件名 #仅查看尾部，还可以指定行数
head 文件名 #仅查看头部,还可以指定行数
利用 ps 怎么显示所有的进程? 怎么利用 ps 查看指定进程的信息？
答案：
ps -ef (system v 输出)
ps -aux bsd 格式输出
ps -ef | grep pid
终止进程用什么命令? 带什么参数?
答案：
kill [-s <信息名称或编号>][程序] 或 kill [-l <信息编号>]
kill-9 pid
什么是Linux
Linux是一套免费使用和自由传播的类Unix操作系统，是一个基于POSIX和Unix的多用户、多任务、支持多线程和多CPU的操作系统。它能运行主要的Unix工具软件、应用程序和网络协议。它支持32位和64位硬件。Linux继承了Unix以网络为核心的设计思想，是一个性能稳定的多用户网络操作系统。
什么是 Linux 内核？
Linux 系统的核心是内核。内核控制着计算机系统上的所有硬件和软件，在必要时分配硬件，并根据需要执行软件。
1. 系统内存管理
2. 应用程序管理
3. 硬件设备管理
4. 文件系统管理
Linux的基本组件是什么？
就像任何其他典型的操作系统一样，Linux拥有所有这些组件：内核，shell和GUI，系统实用程序和应用程序。Linux比其他操作系统更具优势的是每个方面都附带其他功能，所有代码都可以免费下载。
Linux系统缺省的运行级别？
· 关机。
· 单机用户模式。
· 字符界面的多用户模式(不支持网络)。
· 字符界面的多用户模式。
· 未分配使用。
· 图形界面的多用户模式。
· 重启。
什么是交换空间？
交换空间是Linux使用的一定空间，用于临时保存一些并发运行的程序。当RAM没有足够的内存来容纳正在执行的所有程序时，就会发生这种情况。
什么是root帐户
root帐户就像一个系统管理员帐户，允许你完全控制系统。你可以在此处创建和维护用户帐户，为每个帐户分配不同的权限。每次安装Linux时都是默认帐户。
什么是LILO？
LILO是Linux的引导加载程序。它主要用于将Linux操作系统加载到主内存中，以便它可以开始运行。
什么是BASH？
BASH是Bourne Again SHell的缩写。它由Steve Bourne编写，作为原始Bourne Shell（由/ bin / sh表示）的替代品。它结合了原始版本的Bourne Shell的所有功能，以及其他功能，使其更容易使用。从那以后，它已被改编为运行Linux的大多数系统的默认shell。
什么是CLI？
命令行界面（英语：command-line interface，缩写]：CLI）是在图形用户界面得到普及之前使用最为广泛的用户界面，它通常不支持鼠标，用户通过键盘输入指令，计算机接收到指令后，予以执行。也有人称之为字符用户界面（CUI）。
通常认为，命令行界面（CLI）没有图形用户界面（GUI）那么方便用户操作。因为，命令行界面的软件通常需要用户记忆操作的命令，但是，由于其本身的特点，命令行界面要较图形用户界面节约计算机系统的资源。在熟记命令的前提下，使用命令行界面往往要较使用图形用户界面的操作速度要快。所以，图形用户界面的操作系统中，都保留着可选的命令行界面。
什么是GUI？
图形用户界面（Graphical User Interface，简称 GUI，又称图形用户接口）是指采用图形方式显示的计算机操作用户界面。
图形用户界面是一种人与计算机通信的界面显示格式，允许用户使用鼠标等输入设备操纵屏幕上的图标或菜单选项，以选择命令、调用文件、启动程序或执行其它一些日常任务。与通过键盘输入文本或字符命令来完成例行任务的字符界面相比，图形用户界面有许多优点。
简单 Linux 文件系统？
在 Linux 操作系统中，所有被操作系统管理的资源，例如网络接口卡、磁盘驱动器、打印机、输入输出设备、普通文件或是目录都被看作是一个文件。也就是说在 Linux 系统中有一个重要的概念：一切都是文件。其实这是 Unix 哲学的一个体现，而 Linux 是重写 Unix 而来，所以这个概念也就传承了下来。在 Unix 系统中，把一切资源都看作是文件，包括硬件设备。UNIX系统把每个硬件都看成是一个文件，通常称为设备文件，这样用户就可以用读写文件的方式实现对硬件的访问。
Linux 支持 5 种文件类型，如下图所示：
Linux 的目录结构是怎样的？
这个问题，一般不会问。更多是实际使用时，需要知道。
Linux 文件系统的结构层次鲜明，就像一棵倒立的树，最顶层是其根目录：
常见目录说明：
/bin： 存放二进制可执行文件(ls,cat,mkdir等)，常用命令一般都在这里；
/etc： 存放系统管理和配置文件；
/home： 存放所有用户文件的根目录，是用户主目录的基点，比如用户user的主目录就是/home/user，可以用~user表示；
/usr ： 用于存放系统应用程序；
/opt： 额外安装的可选应用程序包所放置的位置。一般情况下，我们可以把tomcat等都安装到这里；
/proc： 虚拟文件系统目录，是系统内存的映射。可直接访问这个目录来获取系统信息；
/root： 超级用户（系统管理员）的主目录（特权阶级o）；
/sbin: 存放二进制可执行文件，只有root才能访问。这里存放的是系统管理员使用的系统级别的管理命令和程序。如ifconfig等；
/dev： 用于存放设备文件；
/mnt： 系统管理员安装临时文件系统的安装点，系统提供这个目录是让用户临时挂载其他的文件系统；
/boot： 存放用于系统引导时使用的各种文件；
/lib ： 存放着和系统运行相关的库文件 ；
/tmp： 用于存放各种临时文件，是公用的临时文件存储点；
/var： 用于存放运行时需要改变数据的文件，也是某些大文件的溢出区，比方说各种服务的日志文件（系统启动日志等。）等；
/lost+found： 这个目录平时是空的，系统非正常关机而留下“无家可归”的文件（windows下叫什么.chk）就在这里。
什么是硬链接和软链接？
1）硬链接
由于 Linux 下的文件是通过索引节点(inode)来识别文件，硬链接可以认为是一个指针，指向文件索引节点的指针，系统并不为它重新分配 inode 。每添加一个一个硬链接，文件的链接数就加 1 。
不足：1）不可以在不同文件系统的文件间建立链接；2）只有超级用户才可以为目录创建硬链接。
2）软链接
软链接克服了硬链接的不足，没有任何文件系统的限制，任何用户可以创建指向目录的符号链接。因而现在更为广泛使用，它具有更大的灵活性，甚至可以跨越不同机器、不同网络对文件进行链接。
不足：因为链接文件包含有原文件的路径信息，所以当原文件从一个目录下移到其他目录中，再访问链接文件，系统就找不到了，而硬链接就没有这个缺陷，你想怎么移就怎么移；还有它要系统分配额外的空间用于建立新的索引节点和保存原文件的路径。
硬链接和软连接的区别
实际场景下，基本是使用软链接。总结区别如下：
· 硬链接不可以跨分区，软件链可以跨分区。
· 硬链接指向一个 inode 节点，而软链接则是创建一个新的 inode 节点。
· 删除硬链接文件，不会删除原文件，删除软链接文件，会把原文件删除。
请问当用户反馈网站访问慢，你会如何处理？
有哪些方面的因素会导致网站网站访问慢？
1、服务器出口带宽不够用
本身服务器购买的出口带宽比较小。一旦并发量大的话，就会造成分给每个用户的出口带宽就小，访问速度自然就会慢。跨运营商网络导致带宽缩减。例如，公司网站放在电信的网络上，那么客户这边对接是长城宽带或联通，这也可能导致带宽的缩减。
2、服务器负载过大，导致响应不过来
可以从两个方面入手分析：
分析系统负载，使用 w 命令或者 uptime 命令查看系统负载。如果负载很高，则使用 top 命令查看 CPU ，MEM 等占用情况，要么是 CPU 繁忙，要么是内存不够。如果这二者都正常，再去使用 sar 命令分析网卡流量，分析是不是遭到了攻击。一旦分析出问题的原因，采取对应的措施解决，如决定要不要杀死一些进程，或者禁止一些访问等。
3、数据库瓶颈
如果慢查询比较多。那么就要开发人员或 DBA 协助进行 SQL 语句的优化。
如果数据库响应慢，考虑可以加一个数据库缓存，如 Redis 等。然后，也可以搭建 MySQL 主从，一台 MySQL 服务器负责写，其他几台从数据库负责读。
4、网站开发代码没有优化好
例如 SQL 语句没有优化，导致数据库读写相当耗时。
针对网站访问慢，怎么去排查？
· 1、首先要确定是用户端还是服务端的问题。当接到用户反馈访问慢，那边自己立即访问网站看看，如果自己这边访问快，基本断定是用户端问题，就需要耐心跟客户解释，协助客户解决问题。
· 不要上来就看服务端的问题。一定要从源头开始，逐步逐步往下。
· 2、如果访问也慢，那么可以利用浏览器的调试功能，看看加载那一项数据消耗时间过多，是图片加载慢，还是某些数据加载慢。
· 3、针对服务器负载情况。查看服务器硬件(网络、CPU、内存)的消耗情况。如果是购买的云主机，比如阿里云，可以登录阿里云平台提供各方面的监控，比如 CPU、内存、带宽的使用情况。
· 4、如果发现硬件资源消耗都不高，那么就需要通过查日志，比如看看 MySQL慢查询的日志，看看是不是某条 SQL 语句查询慢，导致网站访问慢。
项目流程
1、市场需求产品经理会根据需求制定一个需求文档(prd) 需求文档多数以文字的形式呈现
产品经理会将需求制定成一个原型 墨刀和Axure目前市面上比较常见的原型工具文档
2、UI设计师会根据原型文档制定设计稿(给到测试的是一个蓝湖邀请地址)
3、开发编写代码 测试编写测试用例 同时在进行的工作
4、测试编写完测试用例后需要提交测试用例评审
(查缺补漏 测试用例对需求是不是覆盖100% 同步给开发测试用例的一些预期结果)
5、测试用例评审通过后等待开发提交程序进行测试
App：安卓的是一个后缀名为.apk的安装包
ios是一个后缀名为.ipa的安装包
蒲公英网址存放APP的安装包给到我们进行下载安装测试
H5：在手机浏览器打开的网址
微信小程序： 开发码和体验码进行提交测试
web端：在电脑用浏览器打开
6、进行冒烟测试(主流程走一遍 验证功能是不是完整)
7、冒烟测试通过后进行一轮测试 (对照测试用例一条一条执行 全面测试)
【测试环境】举例：xx项目有A B C D四个功能组成
第一轮测试测试：A B C D全部进行一遍测试 测试结果：A通过没有bug B C D测试出来了bug，测试
出来的缺陷需要及时记录到禅道中 测出来一个提交一个
等待开发针对测试提交的B C D模块bug进行一个修复
开发修复完成以后重新给你一个版本后你再进行二轮测试
第二轮测试开始：针对B C D测试出来的缺陷进行验证是否修复完成 B和C没问题 D有问题
针对D重新进行修复 修复完成以后再进行第三轮测试
每一轮测试的原则是不是bug在递减 针对出现bug的地方进行分析
最终进行回归测试 如果测试环境下回归成功无一二级缺陷后进行UAT环境测试，
UAT环境下进行多轮测试生产环境的测试发布到应用商店上线审核
如果开发进行版本修复请问下需要重新打包吗？
比如10：35分我给你一个安装包1.0，今天进行了bug修复 晚上5:00时给你一个修复好的2.0版本，app需要重新打包进行提测。H5 web 刷新网页即可，小程序看情况 有的时候需要重新给二维码 有的时候不需要
原型文件—产品经理
墨刀：生成是一个网址 浏览器打开
Axure：生成一个.rp为后缀名的原型文件 或者也可以是一个网址 如果给你的是一个.rp的文件
你需要下载一个Axure工具才可以打开
蓝湖—设计师提供
这个邀请地址点击以后需要登录 自己注册一个蓝湖地址即可
记住：邀请地址不要发给任何人 如果想要求助给别人看的时候你可以选择截图
蒲公英—开发提供
开发码和体验码—开发提供
来源：
开发码是开发用微信开发者工具进行生成的 开发码是有时间限制的 需要有开发者权限才可以扫
体验码是微信公众平台生成的体验码(开发往微信公众平台提交了版本才可以生成体验版本)
体验版本是没有时间限制的 需要开发者和体验者才可以扫码查看
测试环境 UAT环境 生产环境的区分
一般环境都是开发进行维护的 每一个环境代码是一样的 区别在域名不一样+服务器不一样
百度正式环境：www.baidu.com
百度UAT环境：www.uatbaidu.com
百度测试环境：www.testbaidu.com
测试环境：针对内部测试的第一个环境 用来调试程序是不是有问题 用的服务器性能一般没什么要求
UAT环境：模拟生产环境 因为生产环境出现bug后直接在生产环境上进行bug还原不是特别友好 所以使用UAT代替生产进行模拟正式环境测试
生产环境：用户使用的环境，每次版本发布都是需要服务器重启或者对于程序来说会有短暂的无法使用
若有收获，就点个赞吧
0 人点赞
