【背景】
千分之一的哈姆雷特作为一只测试路上走到黑的小白，实习加上工作也有两年了，对于测试方法之类的，以前也是模糊的、不在意的，认为技术是关键，后来经过工作实践，有了一些小小的矫正~ 这里记录下很初级的经验，用来勉励自己也希望将来走的更远^_^欢迎指导~
Q1.测试分类？
目前我了解到的，目前大致分成这3类：
￭功能测试：黑盒、灰盒、白盒、或者再细化到单元测试；
￭自动化测试：开发自动化工具，协助测试，提高效率，但是工具只是用来协助，重点还是通过工具发现bug，或者提高效率，不可本末倒置当然，也有一类测试开发人员，专做测试工具的开发，私以为这类算是开发哈；
￭性能测试：大多是测试服务器、系统的压力与稳定性；
其实这也算是测试进阶之路吧~ Maybe~
Q2.功能的黑盒测试简单、没有技术含量？
比起自动化、性能，从技术角度，确实不算‘高含金量’，但是一个成功的测试人员在于，他可能不懂具体实现，但绝对熟悉产品、方案，以及整套业务流程；可能关注技术点不够深入，但是有一定知识广度；基于缺陷敏感度、需求掌握、项目进度把控，可以将项目质量保证到相对较好的程度，毕竟bug永远都提不完==。
所以，个人看法是，测试经验、测试逻辑是入门基础，在掌握测试基础后，再深入，有技术逐渐加持，以后的发展方向就比较广阔啦，比如深入自动化、转行做产品、深入测性能、更甚项目经理、架构师等等~
Q3.完整的测试流程？
￭需求分析：
step1.考虑用户故事，需求合理？可行性，即目前的技术、平台是否支持？
step2.如果不支持，有什么好的解决办法？如果支持，进一步考虑细节（平台配置？部门分工明确？测试周期？项目计划？）；
！划重点：bug越早发现越好，降低风险、降低成本，所以需求分析阶段很重要哦！
￭用例设计与评审：
step1.深入了解实现方案，利用流程图、时序图、思维导图，理清逻辑，熟悉流程，覆盖场景，再写用例；
step2.评审用例，与开发和产品再次统一认知，避免偏差；
￭测试执行：
step1.有效准备数据，便于高效测试，测试过程中也有很多方法，比如借助工具、考虑边界值、测试数据多样化且不止一条（一条容易出错）；
step2.发现问题，只客观说现象，而不是先下定论，首先尝试自己定位问题，找到源头，用数据（接口、日志之类的）说话，再找开发确认，利于测试进阶总不能一直黑盒吧qaq，也有利于培养bug灵敏度；
step3.通过抓日志、adb等手段，记录下bug的复现步骤，包括环境、版本、操作步骤、偶现率等，便于开发复现bug，也便于后期我们验证bug；
￭bug跟踪与回归验证、版本交付、上线后跟踪
这个就没啥好强调的啦，有一点：在多轮迭代中，很容易出现bug反复、版本混乱、漏bug的情况，那么在流程上，一定要约束开发提交版本时，注明功能修改情况、在修复bug时，注明影响范围；而测试验证bug时，需要开动脑筋，想清楚此模块可能与其他模块耦合度较高，一并验证下相关功能（很多时候可能一个功能的入口、场景有多个，需要全部覆盖），并且在最后一个版本时，验证主功能，这样才能保证最后交付的版本质量~
Q4.如何理清楚一个功能的逻辑？
拿到一个功能，首先了解实现逻辑，而非看表面的界面展示；理解了逻辑后，再考虑各种场景。这么说有点抽象，举个栗子，搜索功能，如果单纯基于场景考虑那就是搜索入口、搜索有结果、搜索返回等等，这样子测试是很水的、不负责任的，如果能基于逻辑来，那么考虑：
起点终点：起点是点击搜索入口进入搜索页，终点是返回到搜索入口；
前提条件：平台支持配置的有哪些？搜索涉及到的接口有哪些（数据交互）？
接下来，每一步具体的动作步骤（可画图理解），基于每一个步骤再考虑场景，这里就不细说啦
Q5.如何写用例？
step1.用例等级划分，按照优先级从高到低进行测试：
A-->主入口 B-->主功能 C-->边界值、页面检查、后台配置 D-->异常、系统机型适配测试
step2.用例9元素：
用例编号、功能模块、优先级、用例名称、预置条件、具体步骤、预期效果、是否通过、备注
Q6.缺陷分类？
Q7.区分回归和冒烟测试？
冒烟：针对开发修复一个bug，验证此bug有没有彻底修复、对其他模块有没有影响；
回归：修改旧代码后重新测试；
Q8.敏捷测试和传统开发区别？
1.在传统开发模式中，开发人员和测试人员各自独立。开发人员了解到产品需求后开始开发，测试人员拿到产品需求说明书后开始编写用例，等到项目结束，测试开始对照测试用例进行测试工作。在敏捷开发模式中，人人都是测试人员，对自己的业务负责，是一种边开发边测试的模式。
2.传统开发模式的周期比较长，一般几个月到一年，敏捷开发模式的周期比较短，一般1~4周、小版本、高频率，快速迭代；
3.敏捷测试中强调测试自动化，没有自动化，也就谈不上敏捷，将团队成员从冗余的劳动中解放出来；
4.敏捷更强调沟通大于文档，效率更高；
区分敏捷测试中的TDD 和BDD：
TDD ：测试驱动开发--是让开发人员在编写功能代码之前，根据对需求的理解先设计和编写单元测试代码。先思考如何对将要实现的功能进行验证，再考虑功能的实现。然后迭代的增加新功能的单元测试和功能代码编写，直到完成全部功能的开发。
关于敏捷测试，虫师的这篇讲的很明白了：https://www.cnblogs.com/fnng/archive/2013/02/03/2891246.html
关于区分TDD 和BDD：https://www.cnblogs.com/Leo_wl/p/4780678.html
Q9.测试如何把控项目进度？
Q4.如何出一份测试计划、测试方案？
