常见的面试题

Q:如果给你一个没有需求的app测试项目，你应该怎么测？
根据APP的 11大测试点
1 权限测试
2 安装、运行、卸载测试
3 UI测试
4 功能测试
5 性能测试
6 中断测试
7 兼容测试
8 安全测试
9 回归测试
10 升级更新测试
11 用户体验测试
补充根据自己的经验，制定测试计划，每天汇报自己的进度，发出测试日报。
测试过程有问题，及时上报，及时跟进bug，多和开发交流沟通，明确需求。

Q:你同时负责功能和性能，你怎么做？
先测成功能，保证功能的完成，再做性能
在提交bug后，开发还没改好时，可以准备性能测试，在工作时间很紧的情况下会主动加班

Q:给你一个模块测试，只有一个星期的时间你如何有效率地完成？
答：在有限的时间里，明确需求的情况下，制定工作计划，把每天任务细分，先保证重要功能，跟进修复情况，及时验证bug。
每天发工作日报，汇报进度，如果遇到风险，及时汇报领导

Q:如果因为你的错误导致工作发生问题，你怎么办？
1 首先要表达在过去的工作中从未发生过类似事情，因为自己工作态度还是很端正的。
2 万一因为自己的错误导致工作发生问题，首先应该把问题上报给领导，争取把问题的影响降到最低程度。

Q:你们测试用的测试环境是谁给的？linux怎么搭建测试环境？
一般开发搭建，但是我也会，我之前自己搭建过一个小项目
首次流程大概是：
1 通过winscp上传tomcat，MySQL安装包，JDK（Java开发环境工具包）到linux下
2 利用tar -zxvf解压缩包命令对jdk,tomcat，mysql进行解包、安装，再配置jdk环境变量。
3 把war包（web程序）放到tomcate指定目录webapps下，再启动服务器即可。（输入startup.sh的路径，直接回车即可运行）

Q:如果因为你的错误导致工作发生问题，你怎么办？
1 首先要表达在过去的工作中从未发生过类似事情，因为自己工作态度还是很端正的。
2 万一因为自己的错误导致工作发生问题，首先应该把问题上报给领导，争取把问题的影响降到最低程度

Q:如何查找a.log日志文件的error字符串：
cat a.log | grep error  （推荐）

 

Q:左联结和右联结的区别
左联结保留左边表的所有数据，右边表只显示符合匹配条件的数据，没匹配的以空值表示;右联结保留右表的数据，左边表只显示符合匹配条件的数据，没有匹配的以空值表示

 

Q:如何看待996：

首先强调两点：一是自身的工作效率高，二是如果因为工作进度需要，可以接受加班。

最重要的是，在面试，阐述自己观点的时候请保持自信，礼貌并且条例清楚

 

Q:搭建测试环境流程
1.安装java环境
2.配置环境变量（PATH、JAVA_HOME、CLASSPATH等），验证环境变量是否配置成功（shell终端输入java -version）
3.安装应用服务器软件，解压压缩文件到安装目录
4.安装数据库软件，修改密码，重启，新建数据库，导入脚本
5.将搭建网站的war包放入应用服务器的webapps目录下
6.启动应用服务器
7.浏览器访问所搭建网站

 

Q:a测试报告包含哪些内容？
1.测试结果摘要，分别描述各个测试需求的测试结果，产品实现了哪些功能点，哪些还没有实现
2. 缺陷分析，按照缺陷的属性分类进行分析
3. 测试需求覆盖率，原先列举的测试需求的测试覆盖率，可能一部分测试需求因为资源和优先级的因素没有进行测试，那么在这里要进行说明
4. 测试评估，从总体对项目质量进行评估
5. 测试组建议，从测试组的角度为项目组提出工作建议

 

Q:性能测试需要关注哪些点？
硬件资源指标和系统指标。
资源指标：CPU使用率、内存使用率、磁盘I/O、网络带宽。
系统指标：并发用户数、在线用户数、平均响应时间、事务成功率、超时错误率

 

Q:apache ab主要关注的是哪些性能指标？性能指标谁定的？怎么认为达标了？
1）吞吐率、并发连接数、并发用户数、用户平均请求等待时间、服务器平均请求等待时间
2）有需求文档的话需求中会写，这可能是客户方定的标准，也可能是按照行业的标准来定的。没需求文档或需求文档没写的，也就是说你根本不知道这个指标是啥的，你就压，先压10个并发量，10个没问题就压50个，逐渐增加，注意查看并记录极限值。
3）指标可以说根据项目来决定，根据目前用户的估算量进行压测，不同的项目不一样，满足日常的访问就可以算达标。或者和产品部门的同事沟通，了解客户需要达到什么样的性能指标，因为我们作出的产品最终是要满足客户需求的。

软件测试人员应在需求阶段就加入到开发过程中。
因为软件的质量问题会随着软件开发周期的不断展开而不断放大的，而更正质量问题的成本也是不断放大的，也就是说在需求阶段出现的小问题，到开发完成后缺陷可能成几何倍数放大，而修改所需要的成本也会不断的放大，
如果测试工程师能够尽早的加入其中的话可以尽早的找出问题，及时发现，避免问题最后放大到不可收拾

发现错误多的模块，残留在模块中的错误也多 （群集现象）
开发人员能力参差不齐，当发现某模块bug数越多，修改的bug越多，则引入新的bug就会越多，那么这些新的bug发现的难度要比修改前发现bug要大的多，其隐藏未发现的bug数量就越多，那么相应的模块质量也就越差。
代码复用也可能造成该模块的bug比较多。

 

测试人员避免自己修改bug
正确流程应提交错误缺陷，此时开发组人员会有记录，并修改此问题。
如果测试人员自己修改，会导致开发人员无记录，容易出现冗余系统版本，并不清楚哪个为最终版本。