1. 测试流程
1）测试需求分析阶段：阅读需求，理解需求，主要就是对业务的学习，分析需求点，参与需求评审会议。
2）测试计划阶段：主要任务就是编写测试计划，参考软件需求规格说明书，项目总体计划，内容包括测试范围（来自需求文档），进度安排，人力物力的分配，整体测试策略的制定。风险评估与规避措施有一个制定。
3）测试设计阶段：主要是编写测试用例，会参考需求文档（原型图），概要设计，详细设计等文档，用例编写完成之后会进行评审。
4）测试执行阶段：搭建环境，执行冒烟测试（预测试）-然后进入正式测试，bug管理直到测试结束。
5）测试评估阶段：出测试报告，确认是否可以上线。
- 测试前准备-》需求分析-》测试设计-》执行测试-》提交bug-》测试总结
2. 测试计划的编写要素
why-为什么要进行这些测试
what-测试哪些方面，不同阶段的工作内容
when-测试不同阶段的起止时间
where-相应文档，缺陷的存放位置，测试环境等
who-项目有关人员组成，安排哪些测试人员进行测试
how-如何去做，使用哪些测试工具以及测试方法进行测试
3. 测试原则
1）应当把“尽早的和不断的进行软件测试”作为软件开发者的座右铭
2）测试用例应由测试输入数据和对应的预期输出结果两部分组成
3）程序员应该避免检查自己的程序
4）在设计测试用例时，应包括合理的输入条件和不合理的输入条件
5）充分注意测试中的群集现象，经验表明，测试后程序中残有的错误数目与该程序中已发现的错误数目成正比
6）严格执行测试计划，排除测试的随意性
7）应当对每一个测试结果做全面检查
8）妥善保存测试计划，测试用例，出错统计和最终分析报告，为维护提供方便
4. 测试方法
黑盒：等价类划分法、边界分析法、因果图法和错误推测法、正交法、场景法
白盒：逻辑覆盖法、循环测试路径选择、基本路径测试
5. 测试分类
1）按阶段划分：单元测试、集成测试、系统测试、验收测试
2）按是否运行划分：静态测试、动态测试
3）按是否查看代码划分：白盒测试、黑盒测试、灰盒测试
4）其他：回归、冒烟、随机测试
5）功能测试：界面、业务逻辑功能、兼容性、易用性、安全性、安装测试
6）性能测试：性能、负载、压力、容量、并发、配置、可靠性、失败测试
6. 测试模型
7. 开发流程
需求分析-〉概要设计-〉详细设计-〉编码-〉测试-〉软件交付-〉验收-〉维护-〉升级-〉再测试-〉逐步淘汰
8. 黑盒和白盒的区别
黑盒测试：把测试对象当成一个黑盒子，测试人员完全不考虑逻辑结构和内部特性， 只依据程式的需求说明书来检查程式的功能是否满足它的功能说明。
白盒测试：把测试对象当成一个透明的盒子，允许测试人员利用程序内部逻辑结构及 相关信息，设计或选择测试用例，对程式所有逻辑路径进行测试。
9. 测试计划都有哪些
测试背景，测试目标，测试范围，测试输出文档，测试策略，测试规模，工作量分析，测试进程，测试进度及时间安排，测试资源，人力，设备，风险管理
10. 测试用例包含哪些
用例编号、所属模块、执行条件、测试输入、预期结果、实际结果、用例是否通过、测试人、版本
11. 测试用例需要详细到什么程度才是合格的
首先根据需求文档、概要设计、测试计划、测试方案细分出各功能模块的测试项，再根据各测试项，按照概要设计，详细设计以及测试方案中测试的覆盖率细分出测试子项，最后根据测试用例的设计方案来写测试方法
12. 缺陷报告包含哪些
缺陷的标题、简要描述、缺陷的类型、缺陷的详细步骤描述、缺陷的实际结果、期望结果、有的缺陷需要上传截图、日志结算、缺陷的等级、缺陷指派给开发
13. 测试评审：（评审分类 评审内容 评审结束）
1）评审分类：部门、公司、客户评审
2）评审内容：
[1]用例设计的结构安排是否清晰合理，是否利用高效对需求进行覆盖
[2]优先级安排是否合理
[3]是否覆盖测试上的所有功能点
[4]用例是否具有很好执行
[5]是否已经删除了冗余的用例
[6]是否包含充分的负面测试用例
[7]是否从用户层面来设计用户使用场景和使用流程的测试用例
[8]是否简洁 ，复用性强
3）评审结束：
在评审活动中会收集到用例的反馈信息，在此基础上进行用例更新，直接通过评审
14. 水杯 电梯 朋友圈点赞 视频播放 支付的测试用例的设计点有哪些
15. 测试发现bug开发不认为是bug的时候
说法一：
1、首先明确开发说不是bug的理由。
2、如果是需求变更， 那就找产品经理确认是否是需求变更。
3、如果开发说测试环境问题， 让他说明清楚测试环境问题是什么，按照他说的验证一遍， 如果确实如他所说， 关闭bug，但是不是他说的那样，继续激活bug给开发解决，确保产品质量。
4、如果开发说用户不存在这种使用场景， 但是我们不认可他说的，把这个bug 知会到测试经理，让测试经理去判定。
说法二：
1.告知开发bug的判断依据，同时明确开发说不是bug的理由。
2.对开发的理由进行校验，校验依据1.参照需求文档，2.跟产品经理进行沟通确认。
校验结果不是bug，关闭bug，如果是bug提交给开发进行处理，确保产品质量
16. Linux命令 15个
17. Adb命令 15个 查看日志 （日志级别）
18. Monkey命令 和日志区别
19. 查看日志的前10行后5行的命令
# head -n 10/etc/profile
# tail -n 50/etc/profile
20. Bug生命周期
发现BUG-->提交BUG-->指派BUG-->研发确认BUG-->研发去修复BUG-->回归验证BUG-->是否通过验证-->关闭BUG
如果待验的BUG在验证时没有解决好，我们需要重新打开--指派—已解决—待验，循环这个过程
21. Bug的状态和优先级
第一级（blocker）: 引起喜欢作系统“挂起”或“崩溃”的错误；
第二级（critical）: 引起软件本身“挂起”或“崩溃”的错误；
第三级（major）: 不能完成软件说明书定义的功能的错误；
第四级（normal）: 程序所完成的功能与软件说明书定义不符的错误；
第五级（minor） : 显示方面的错误；
第六级（trivial） : 其它“轻微”的错误（如文本差错）；
第七级（enhancement）：增强或者改进。
优先级：
1.立即解决（Resolve Immediately）缺陷必须被立即解决。
2.正常排队（Normal Queue）缺陷需要正常排队等待修复或列入软件发布清单。
3.不紧急（Not Urgent）缺陷可以在方便时被纠正。
