1 缺陷报告的组成：
①缺陷编号（Defect ID）:提交缺陷的顺序
②缺陷标题（summary）：简明扼要的描述缺陷
③缺陷的发现者（Defected By）:测试人员
④缺陷发现日期（date）：一般为当天
⑤缺陷所属的模块（subject）：在测试哪个功能模块时发现的bug.
开发组可以据此决定由谁负责修改该bug
⑥发现缺陷的版本（Defected in release）:
⑦指派给谁处理（Assigned to）:测试人员指派给开发经理，开发经理根据缺陷所在的模块，需要再次指派具体的开发人员。
⑧缺陷的状态（status）：缺陷此时所处的处理阶段或处理情况
2. 开发人员修复缺陷后如何保证不影响其他功能
当开发修复某个缺陷时，除了验收BUG是否被修复外，还应将与之关联的所有模块进行检查，防止其他受到影响
3. 压力测试和负载测试的区别：
压力测试是指在一定的网络，硬件条件下，模拟大量的用户向服务器发起请求，使服务器处于极限状态下，持续长时间的工作，来测试服务器是否能在高强度环境下稳定的工作
负载测试是 在一定的软件，网络支持下，模拟一定量的用户，测试软件性能是否在用户需求范围内，用于确定系统所能承受最大有效用户数 即不同用户数下的系统响应时间和服务器的资源利用率。如：找到在响应时间超过10秒，服务器CPU利用率低于65％时的用户数。
4. Where和having的区别
Where是在查询前的约束条件，having是查询之后过滤的操作。Where不能使用聚合函数，having可以使用聚合函数。
5. 测试环境中，如何保证测试环境和生成环境性能一致
第一种：近似推算法。类似于来说，把正式环境的资源在测试环境等比缩小；eg：pro: 8c8g，test:4g4c，那么正式就是测试的2倍，然后测试的性能指标*2 ≈≈ 正式环境的性能指标，这种只能做一种近似推算，但是不同的场景可能结果会有差异；
第二种: 全链路压测。正是由于第一种的缺陷，才会出现这种，这种性能结果就是线上环境的真实数据，但是一个不小心会造成线上事故；
6. 如何准备测试数据，防止测试污染
途径一
数据来源：直接复用开发使用的测试数据
获取方法：取的开发数据库的地址，直接拷贝数据库表数据，并将数据导入到自己的测试数据库
途径二
数据来源：直接复用线上的真实数据
获取方法：寻求开发协助，拷贝线上数据到测试数据库
注意：涉及到一些用户数据，可能会拒绝我们获取线上数据
途径三
数据来源：直接使用线上数据
获取方法：数据库连接的线上数据库
注意：该情况出现的原因可能是开发给测试人员提供的环境使用的就是线上的数据，也可能是线上直接验证。当项目不涉及修改操作时，也可能允许测试数据库连接线上的数据库。这种情况下要特别注意不要随意更改不相干的内容。
途径四
数据来源：自行手动造数据
获取方法：第一，对于没有特殊要求的可以在测试数据库中手动批量插入数据；第二，在管理后台手动填数据
途径五
数据来源：请产品或运营为我们提供数据
获取方法：请产品或运营为我们提供数据
如何防止测试污染：
一定要做到团队中工作环境的标准化和独立化，切忌采用公用的数据库做测试，避免冲突。标准化，意味减少沟通成本，这也是Maven所极力提倡的。所谓标准化，是即团队成员的工作目录，安装的程序都做到一样，如果公司层面有这种标准化的内容当然最好，如果没有项目组也可以自己定义。
独立化，就是开发机的环境不要依赖于外部的，也即要完备，如数据库，memcached等都要有，当然可以模拟的就不要安装真实的了。做过国外外包项目的朋友都会知道，一个外包项目的开发环境包含了所有需要的东西，以虚拟机文件的方式提供，打开什么都有了，用VMWare打开即可开发。
7. 如果项目周期短，测试人力匮乏，你是怎么协调的
依据代码review的结果和影响范围，对测试内容进行适当的裁剪。
借助自动化工具的支持，提高测试案例的执行效率。
调整组内任务的优先级，进行人力协调，优先投入最紧要的项目。
必要的情况下加班
8. 在微信客户端使用搜狗输入法打字，手机突然黑屏了，那些原因导致的，如何排查
(1) 其他软件和搜狗冲突，卸载其他软件测试
(2) 手机本事原因，比如太旧，换个手机
(3) 机身内存占用较高，会出现输入法不能使用，将不需要的后台全部关闭
(4) 系统与搜狗版本不兼容，换个手机系统
9. 在测试过程中发现了一个重现率低的BUG，如何处理？
发现bug之后，我们会先截图，如果确定是偶然性的问题，会将日志和截图一起提单给开发定位；
如果缺陷在当前版本无法复现，且缺陷的影响程度比较低，可以提交问题单进行跟踪，跟踪三个版本，如果后三个版本都无法复现，就可以关闭该缺陷；
如果是很严重的Bug，比如导致系统崩溃等，并且，实在没有再次出现，除了要及时反馈给上级之外，最后还要写到测试报告中，说明出现了什么现象，但无法再现！
10.测试发现一个优先级高的BUG，产品认为不着急，上线出问题了，紧急上线了一个补丁包修复，如何保证同类问题不会发生
1. 与产品人员发生分歧：
先跟开发沟通，确认系统的实际结果是不是和需求有不一致的地方；有些地方可能需求没提及，但是用户体检不好，我们也可以认为是bug。
如果开发以不影响用户使用为理由，拒绝修改，我们可以和产品经理，测试经理等人员进行讨论，确定是否要修改，如果大家都一致认为不用改，就不改。
2. 进行回归测试：
1. 全量回归：对软件的新版本测试时，重复执行上一个版本测试时使用的测试用例，防止以前没有的问题现在出问题了
部分回归：当开发修复某个bug时，我们需要去检查该bug是否被修复，还需要检查与之相关联的模块是否受到影响。
11. 写出QQ发消息所有测试用例