java的反射和依赖注入、控制反转(spring思想):
反射：1，反射机制指的是程序在运行时能够获取自身的信息，实现动态创建对象和编译，比较灵活。缺点是对性能有影响。
2，.class-->.java
3，通过反射机制访问java对象的属性，方法。
IOC是概念，实现的是DI。 AOP也算是一种IOC
依赖注入:在运行期，由外部容器spring动态地将依赖对象注入到组件中
控制反转:spring容器初始化，创建并管理bean对象，以及销毁它
从Spring的角度看，AOP最大的用途就在于提供了事务管理的能力。事务管理就是一个关注点，你的正事就是去访问数据库，而你不想管事务（太烦），所以，Spring在你访问数据库之前，自动帮你开启事务，当你访问数据库结束之后，自动帮你提交/回滚事务！
DI其实就是IOC的另外一种说法。DI是由Martin Fowler 在2004年初的一篇论文中首次提出的。他总结：控制的什么被反转了？就是：获得依赖对象的方式反转了。
1，sql的多表联查各种方式
——内连接，左连接，右连接
2，测试计划
——分几轮测试，提测的时间节点，各个模块完成时间，
——测试内容，测试分工，测试方法和测试进度
3，测试报告
——风险点、改动内容、测试过程碰到的问题、测试点、遗留问题、建议
——项目基本情况（比如提测时间、提测次数、参与人员）
4，测试case如何写覆盖的更广（更成熟的测试用例）
——1，测试前，了解项目需求，关注可测性，列出功能划分图。
——2，根据功能的复杂程度按照每个功能；或一个功能点分多页；或多个功能点合成一页来进行用例的撰写。这是按照功能切面来说，其他方法比如说等价划分类(有效、无效)、临界值、因果图等，都是在用例编写时自然会用到的，包括正向和反向。还有后台功能，界面上不会体现的，需要了解业务的后台服务系统再去编写，最后还需要进行风险分析。保证覆盖高风险的，低风险的尽量覆盖。
5，Linux查进程，强制杀死进程、看内存、查看日志
——ps -ef e是列出所有进程 f是显示格式
——kill -9。如果还杀不掉，那就杀掉这个进程的父进程(PPID)
——top和free -m .free比较简单、占用很少的系统资源。
——grep
6，loadrunner的组件、关联函数、其他主要函数
——虚拟用户生成器、控制器、负载发生器和分析器
——关联函数web_reg_save_param
——web_custom_request, web_submit_data,web_url
7，string a = new string(“abc” )有几个对象？
——两个，一个a，一个”abc”
8，sql去重语句、两条完全重复的记录如何查询，用关键字
——delete from xxx group by x having count(x)>1
——distinct
删除一张表
——DROP TABLE
9. 在测试的过程中发现的最有趣的bug是什么？
——我们以前有个群组记账项目。从其他群组添加成员，但当前列表中列出的成员还会有当前群组的成员。这个是要排除掉的，因为选的是其他群组
(1)是怎么发现的？
——1，客户端发现选择从其他群组添加成员的时候，也显示了当前群组的成员
2，抓包看请求，/api/book/members/other，确实客户端也发了这个请求
3，看接口文档，接口文档确实也是这样写的，请求是对的
4，分析接口的参数，请求其他的群组成员什么信息都不带，只发个other请求看似是不行的
5，问服务端开发这个接口怎么定义的，探讨结果发现需要带参数booKID
10. 对这个有趣的bug是怎么处理的？
——服务端开发更新接口文档，和客户端重新联调，接口上传参数bookID
11. 为什么要做测试(我之前是做开发的)
——测试和开发是两个关注点不一样的工作。开发的目标是实现功能，测试的目标是确定功能是否能够正常运作。那么它的乐趣在于两个关键词：“发现”和“分析”。
如何发现？通过用例设计，了解项目架构去发现缺陷
如何分析？基本的原因定位，模块划分，减少开发分析bug的时间。
开发也要尽量将测试带入开发过程，让大家都知道各个功能进度的细节，这样能减少需求变更时重新设计用例的时间。
12. 谈了谈之前我做过的一些项目，印象最深的项目有哪些？并由此进行了一些交流
——
13. 之前项目中都遇到了什么困难，都是怎么解决的？
——1，需求变化太乱。让产品每次修改和产出新的需求都要发邮件或者其他方式通知相关人员。2，没有独立稳定的测试环境，开发也在同一个环境下开发。测试团队申请搭建了一个测试环境。3，自动化维护成本高。尽量地把可以复用的类和方法都封装起来，建立UI对象库。
14，robotium为什么要重签名？
——Robotium是基于Instrumentation框架的。Robotium编写的测试脚本与被测程序运行在同一个进程里面，所以这需要测试程序与被测程序拥有相同的签名
15，java的线程安全，有哪些类是
——实现了同步机制的，在多线程同时访问某一个资源的输出结果和单线程运行是一样的。StringBuffer ,vector ,hashtable。
16，Junit和testNG的区别
——结论是两者差不多，一般人用用testng就好。
原因：1.testng底层调用junit
2.历史上曾有testng优于junit的一段时期，但随后junit已更新并追赶上来
3.testng的data provider使用较方便
4.testng能做的事情junit都能做，但是有的地方会比较麻烦，例如，数据驱动，多线程并发执行测试用例。testng更便捷，自带。junit则要依靠第三方工具提供。
5.junit能做的事情testng也都能做，但junit也有更便捷的时候。比如soft assertion，junit可以直接继承jassert做，testng你要自己去实现静态类来做。
6.junit是testng的底层，灵活度上更高。testng调用junit，对测试员来说用户体验更好。
17，testNG原理
18，loadrunner响应时间在哪里看
19，如何成为一个优秀的android测试，规划是什么。
——核心工作是项目质量保障，上游包括需求评审和用例评审。检查需求是否完整，有漏洞，并且如何细化测试都要体现在用例里。下游：自动部署，灰度发布，代码review，冒烟自测，引入产品，交互在测试阶段进行UI走查。 （整理项目对应的工程和服务，部署方式，对应机器，依赖关系，责任人）
——比产品人员更了解产品的细节方面，能看懂代码，能调试源代码，能发现各种奇葩的bug。目的主要是为了提高测试的效率和开发迭代的速度，而不是为了自动化而自动化，
——理解测试流程、懂业务模型、主动补位
——然后想自己写一个接口自动化的平台。能够提高测试的效率和开发迭代的速度。
20，android底层SDK
——
21，多线程了解
——两种方式实现，继承thread类，实现runnable接口。线程安全就是实现了同步机制的，同一时间内资源只能被一个线程访问。
22，https了解
——https实际就是在TCP层与http层之间加入了SSL/TLS来为上层的安全保驾护航，主要用到对称加密、非对称加密、证书，等技术进行客户端与服务器的数据加密传输，最终达到保证整个通信的安全性。
23，320表示什么。
——重定向
24，java常见的异常。
——NullPointerException - 空指针引用异常
——ClassCastException - 类型强制转换异常。
——IndexOutOfBoundsException - 下标越界异常
——RunTimeException（运行时异常）
25，linux下通过一个字段遍历文件夹
——find grep
26，linux怎么创建软连接、linux文件里怎么删除一行。
——ln -s f1 a （a就是文件f1的软连接，ln -s）
——删除文件夹 rm -rf
——在查看模式按dd，删除光标所在的一行。(也可以用sed命令)
27，linux。直接杀掉一个java进程。改变用户组，775。chmod修改权限。
——pkill -9 java
——777， 顺序第一二三分别表示用户，用户组，其他人。
数字代表读、写、执行操作权限（二进制111代表3个操作权限）
——chmod 修改权限。 chmod g+rwx a.txt 给同组用户增加读写执行权限。
——chown 修改文件的拥有者（一般只有root权限者使用）
28，数据库端口号和tomcat冲突，怎么办。MySQL数据库默认端口是多少。
——
——3306。
29，重写的方法的权限。
——被重写的方法的访问权限不能为private
——子类的访问权限不能小于父类的访问权限
30，因果图。使用场景。
——因果图法就是从程序规格说明书的描述中找出因（输入条件）和果（输出或程序状态的改变），通过因果图转换为判定表，最后为判定表中的每一列设计一个测试用例。
——使用场景：充值金额是因，返回结果是果。
31，java多态存在的必要条件。
——1、要有继承；2、要有重写；3、父类引用指向子类对象。
32，java注解和反射？如何写。
——注解：自定义注解，跟创建java类的形式差不多。只是把class换成了@interface 例：java public @interface test
——反射:就是在运行期间，如果我们要产生某个类的对象，Java虚拟机（JVM）会检查该类型的Class对象是否已被加载。如果没有被加载，JVM会根据类的名称找到.class文件并加载它。一旦某个类型的Class对象已被加载到内存，就可以用它来产生该类型的所有对象
——Class tc = Class.forName(className)，
——employee = (Employee)tc.newInstance()
33，loadrunner关联
——设置了关联，所以无论是录制过程还是回放过程，只要是服务器返回的，都记到一个变量里面，这样一来，服务器反馈什么，脚本就记录什么，而且是动态的。
34，接口测试，测试数据、参数、期望值都可以存放在数据库里。提升效率主要体现在回归这一方面，旧的接口可以都跑一边，验证是否有问题。
——1，如果接口的返回值不一定是正确的，也可以直接验证数据库和文件系统
——2，如果接口是异步的，需要等待它执行结束。那么就需要一个逻辑轮询接口状态
35，runnable比thread好。
——1，避免点继承的局限，一个类可以实现多个接口。
——2，适合于资源的共享
36，如何保障产品质量？
—— 1，业务逻辑
2，工程/服务的关联
3，代码提交记录
4，开发设计文档
5，Case/技术评审
6，需求范围
7，多询问
8，内部评审
9，项目review
10，历史上的坑。
—— 1，建立完善的测试流程，开发自测，QA主测，产品验收。
2，bug是不可避免的，关键是不产生故障（即严重bug），以及发生线上bug后有及时的处理措施。依靠用户反馈和其他渠道，获得bug信息用于复现。
37，json解析原理
——
1.碰到[或{就new一个对象，并将对象存放到collections中去
2.碰到'\'需要转义的，得直接跳过去，并存放到扫描出来的临时变量中去。比如\{就不需要new一个对象
3.碰到"符号，就要打个标记，在下一个"出现之前，把扫描出来的都当成一个字符串放到临时变量中去。
4.碰到:符号，就要开始标记是个map的开始了，并把之后出现的字符串都存放到另一个临时变量中去。
5.碰到,符号，就要开始处理临时变量了，如果是map就把之前存的两个昨时变量，一个作为KEY，一个作为VALUE，都放到collections中对应的map中去，如果是list,则把之前存的第一个临时变量，放到collections对应的list中去。
6.碰到]或}符号，则表示一个list或map被解析完全了，则这时候要去更新index中的对应的list或map的状态了。
39，怎么自动部署
——自己写shell脚本 我用的java+svn+maven。shell执行 deploy api自动完成以下过程：
1.svn update 最新代码
2.maven进行package打包
3.将生成的war包移动到tomcat/webapps目录下，并且将tomcat restart
40，tcp/ip以及和http的关系
1，TPC/IP协议是传输层协议，主要解决数据如何在网络中传输，而HTTP是应用层协议，主要解决如何包装数据
2，get和post的区别
get是从服务器上获取数据，post是向服务器传送数据。
get传送的数据量较小，不能大于2KB。post传送的数据量较大，一般被默认为不受限制。但理论上，IIS4中最大量为80KB，IIS5中为100KB。 get安全性非常低，post安全性较高。但是执行效率却比Post方法好。
参数的传递方式不同(get用url或者cookies，post放在body里)
41，工作3年的感悟，客户端和web端的区别。
1，中断的情况（来电、短信等）
2，卸载安装
3，兼容性考虑的去web多（横竖屏、手机型号、厂家、分辨率和屏幕大小）
4，手机系统自身的限制，导致死机、重启之类的。（web端很少会有这个问题）
42，测试流程
1，需求给出并召开需求评审
2，开发根据需求给出开发计划，测试根据开发计划给出测试计划（分几轮测试，提测的时间节点，各个模块完成时间。测试内容，测试分工，测试方法和测试进度）
3，在开发提测前进行冒烟case和全部case的评审，并在提测前一天提供给开发冒烟case自测，如果不通过，打回。期间进行部分接口测试。
4，开发提供测试包后，根据测试用例执行，发现问题并提交。
5，开发修复并发出新测试版本时，需要给出releasenote（修复的问题，可能影响的地方，打包分支）
6，确认bug修复并关闭。项目上线前重复循环这个过程，（在这个过程中，我一般会去了解下工程/服务之间的关联，然后也会去看下开发的代码提交记录，进行简单的review）。最终合并代码后，进行全面的回归测试。
7，上线后进行线上验证并编写测试报告（遗留问题、风险点、建议，其他项目的基本情况，比如冒烟不通过次数，bug reopen次数）
43，专项测试
1，电量测试：收集和分析那些直接间接会影响耗电的数据。
2，内存测试：adb命令获取，adb shell dump sys memento.
Memory Monitor查看内存风险
MAT分析内存泄露
3，应用响应时间：chrome://inspect
4，弱网测试。（Charles可以设置）
5，卡顿测试。Systrace和TraceView
6，界面流畅度。GPU绘制消耗
44，UI自动化的框架搭建以及测试报告
——数据模板、配置中心、参数中心（把excel读取出来的转化为参数对象）、触发器（封装请求方式）、监听器（监听运行状态、失败重跑、超时报警、异常停止报警）、期望检查、输出报告。
——测试报告
45，你觉得自动化能做什么？
——用自动化做什么了？为什么用自动化？自动化带来多少好处。
——持续集成后每次都可稳定跑才算是一个真正的自动化
——自动化只是众多手段中的一种，最终做到更有效的质量监控才是核心
46，UI自动化的作用
——每一次的迭代的UI自动只是做一些核心业务的冒烟、回归，并不能发现什么问题，只是保证核心问题没问题
47，什么是持续集成。
——持续集成是频繁、持续的在多个团队成员的工作中进行集成，并且给与反馈。一个典型的持续集成周期包括以下几个步骤：
- 持续集成服务器不断从版本控制服务器上检查代码状态，看代码是否有更新。
- 如果发现代码有最新的提交，那么就从版本控制服务器下载最新的代码。
- 等代码完全更新以后，调用自动化编译脚本，进行代码编译。
- 运行所有的自动化测试。
- 进行代码分析。
- 产生可执行的软件，能够提供给测试人员进行测试。