21、.http页面返回值的含义
200 成功 400 请求错误 401 无法解析此请求 403 禁止访问 404 找不到网页500 服务器错误 502 网关错误 503 服务器不可用
22、.常见协议端口号
FTP21 SSH22 telnet23 dns53 http80 https443 Tomcat8080 orcale1521 mysql 3306
23、你在测试中发现一个界面很丑，你认为这个问题是否严重？是否可以放过？
主要看需求
不严重，如果需求就是如此那就没什么问题，看具体情况，如果项目马上就要上线，可能会因为对界面进行修改会产生更加严重的问题，所以一般都会采取放过的措施
24、数据库查询中什么是左连接，什么是右连接？left join right join
左连接：左右两张表按某个列进行关联查找，左连接以左边的表为基础表，基础表中的数据全部查找出来，右边的表如果有和左边的表条件相符的数据就查找出来，如果条件不相符就用Null显示。 右连接刚好相反
25、什么是触发器？什么是存储过程？
触发器：通过事件来触发运行的，主要是没有人工干预的情况下来完成复杂度高一些的约束条件，从而保证数据库的完整性和一致性。存储过程：在大型的数据库中，一组为了完成特定功能的SQL语句集，经编译后存储在编译过程中，用户通过指定存储过程的名字并给出参数来执行它。
26、你对自已将来有什么计划？（职业发展）定小目标，半年学习完性能或者自动化啊 一年自己独立做好性能或者自动化的测试
首先我要在我未来的工作中，通过我的努力把本职工作做好，在本职工作做好的同时呢，我要多做一些项目积累和完善项目上的经验，通过工作不断的提高我的测试技能
27、你有什么问题要问我的？什么项目哪类项目，项目进行的阶段，有木有业务方面的培训
我想知道这个公司开发现有多少人，测试有多少人，还有公司正在开发的项目的情况
28、这有一个杯子，你怎么去测？（类似这种给一个实物，你怎么去测？）
需求测试: 查看杯子使用说明书。
界面测试: 查看杯子外观。
功能度：用水杯装水看漏不漏；水能不能被喝到。
安全性：杯子有没有毒或细菌。
可靠性：杯子从不同高度落下的损坏程度。
可移植性：杯子在不同的地方、温度等环境下是否都可以正常使用。
兼容性：杯子是否能够容纳果汁、白水、酒精、汽油等。
易用性：杯子是否烫手、是否有防滑措施、是否方便饮用。
压力测试：用根针并在针上面不断加重量，看压强多大时会穿透。
29、你觉的你有哪些优点？哪些缺点？
（缺点要把优点当缺点来说）你觉得你还有哪些地方需要提升的? 性能方面的缺点就是比较大大咧咧，爱笑，优点就是比较热心
30、你了解过我们公司吗？
有了解过，收到面试通知的时候 网上或者招聘网上查询过
31、你对app测试有了解吗？什么是app测试？怎么去测(测哪些方面)？
了解，但是实际工作中没有测试过，其实使用app应用程序的时候就是在测试，只是没有app测试人员测试的那么全面细致，就是对手机应用的测试；从它的功能、界面和兼容、性能、易用性、安装、卸载、升级、与系统或其它软件的交互、耗电量、散热情况、流量的监控、免登陆功能、二次登陆
32、你对加班怎么看？
可以接受，it行业来说 加班是常态
33、你写过测试用例吗？ 写测试用例的依据是什么？
写过，用户需求为准
34、 测试报告你写过吗？ 写些什么呢？
(至少要说出写过自已所测模块的测试报告)自己所负责的模块的测试报告人力投入，用例覆盖情况，bug的分类及数量统计，遗留bug情况，测试风险，测试对象评估，测试结论，测试结果分析，测试总结。
35、测试方案
① 测试策略
② 测试资源
③ 测试进度计划
④ 风险管理
⑤ 质量标准
36、测试原则
A 所有软件测试都应追溯到用户需求；
B 尽早的和不断的进行测试；
C 完全测试时不可能的，测试需要终止；
D 无法显示软件潜在的缺陷；
E 注意群集现象；
F 避免检查自己的程序；
G 避免测试的随意性。
37、测试计划主要写些什么东西？
背景，目标，范围，方式，进度安排，测试组织，测试执行中开始与结束的标准，测试计划的审批与更改方式，测试相关的风险。
38、系统测试策略或者范围
39、工资和发展平台你怎么选择？
发展平台。
40、你怎么做需求分析的？要看是否有需求文档，先确定大的测试范围
首先是将软件开发需求中具有可测试性的需求或特征提取出来，形成原始需求然后将原始测试需求细化或者分解最后进行需求评审。
41、写过测试方案吗？都有些什么内容？没有写过
① 测试策略
② 测试资源
③ 测试进度计划
④ 风险管理
⑤ 质量标准
42、 写过测试报告吗？测试报告和版本报告的区别？
测试报告是对整个测试过程与结果的总结，而版本报告只是针对测完版本的总结。
43、需求评审都有哪些人参加？怎么做的？有什么标准？
参加人员：测试人员、开发人员、产品人员 以会议形式评审评审的标准：完整性审查：应保证测试需求能充分覆盖软件需求的各种特征，重点关注功能要求、数据定义、接口定义、性能要求、安全性要求、可靠性要求、系统约束等方面，同时还应关注是否覆盖开发人员遗漏的、系统隐含的需求；
准确性审查：应保证所描述的内容能够得到相关各方的一致理解，各项测试需求之间没有矛盾和冲突，各项测试需求在详尽程度上保持一致，每一项测试需求都可以作为测试用例设计的依据。
44、用例评审都有哪些人参加？怎么做的？有什么标准？
参加人员：测试人员、开发人员、产品人员 会议评审。
标准：
1）用例设计的结构安排是否清晰、合理，是否利于高效对需求进行覆盖。
优先极安排是否合理。
是否覆盖测试需求上的所有功能点。
用例是否具有很好可执行性。例如用例的前提条件、执行步骤、输入数据和期待结果是否清晰、正确；期待结果是否有明显的验证方法。
是否已经删除了冗余的用例。
45、描述测试活动生命周期或者软件测试流程:
需求分析—编写测试计划—设计用例设计—执行用例，提交bug—编写测试报告。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
