职业经验 # 每日一道面试题 # 请问你一般如何做测试分析？
面试过很多人，有些人不知道测试分析是什么。简单来说，就是你写测试用例和执行测试的指导思路。一般来说是在开发做系统分析之后，那么如果你做测试分析，你一般会怎么做？有哪些方面？
@Innocence 的答复比较完整，这个其实算是经验之谈了。一般做过完整项目的同学应该都能回答出来。这个就是考验大家平时是不是会总结流程。
作为一名 QA，目前的做法是：
1.明确需求
需求文档分析，是否有需求遗漏、需求模糊、需求错误等项目，发现问题及时和产品沟通
2.回忆成年老坑
一个需求过来，有些模块或者部分内容和之前的一致，而在之前的版本中出现过事故、特殊规则、注意事项等等内容，及时和开发回顾和讨论解决方案（尤其是新手开发上手的时候）
3.确定开发提测日期
没什么好说的，为了版本上线顺利，工作时间能均匀分配（别每次都是前几天闲死，后几天忙成狗）
4.拆解模块
根据需求内容和开发大概的系统分析，拆解各个模块
5.编写测试用例
先按各模块级别，最后集成
6.提测版本测试
7.执行测试、疯狂提 bug、bug 修复验证
8.根据开发人员水平，需求复杂度等等等 重复 6-7 N 次
9.最后回归，测试开发产品三方验收
拉上产品的目的是因为 有些需求会改到产品 TM 都不认识了，提前给他看看，否者你说谁背锅
、、、、、、
一般会画一个流程图，然后罗列出测试点。
不知道这个理解对么。
作为一名 QA，目前的做法是：
1.明确需求
需求文档分析，是否有需求遗漏、需求模糊、需求错误等项目，发现问题及时和产品沟通
2.回忆成年老坑
一个需求过来，有些模块或者部分内容和之前的一致，而在之前的版本中出现过事故、特殊规则、注意事项等等内容，及时和开发回顾和讨论解决方案（尤其是新手开发上手的时候）
3.确定开发提测日期
没什么好说的，为了版本上线顺利，工作时间能均匀分配（别每次都是前几天闲死，后几天忙成狗）
4.拆解模块
根据需求内容和开发大概的系统分析，拆解各个模块
5.编写测试用例
先按各模块级别，最后集成
6.提测版本测试
7.执行测试、疯狂提 bug、bug 修复验证
8.根据开发人员水平，需求复杂度等等等 重复 6-7 N 次
9.最后回归，测试开发产品三方验收
拉上产品的目的是因为 有些需求会改到产品 TM 都不认识了，提前给他看看，否者你说谁背锅
、、、、、、
1.需求分析
2.结合实现逻辑写用例 (包括测试力度，范围)
3.与有关人员 review 用例
游戏这边比较好的方案。
1.拿到系统，需求分析后，任何分解，写测试点-->扩展用例（测试用例是测试点子集，修改时做映射关系）
2.测试用例书写，条件判断法->等价类，异常路径，标记主路径（用于后续冒烟）
3.考虑接口和测试代码（污染不污染无所谓的，可以做标记或者沙箱运行），取决业务是否可以先前后分离。可分离，则无前端，光后端就可以开始测试。
4.根据测试反馈情况（阻断条目，缺陷分布），判断需要几轮
5.单系统经过 1-2 轮完整覆盖回归缩小测试范围，取决粒度和范围。
6.提测书写本次测试报告，记录剩余问题总数，权重值，激活区域，总体缺陷密度和偶发必现和不可复现问题场景。
测试分析：
1、对需求进行通读，熟悉该需求的目的以及大概的功能；
2、进行制定测试计划，此次测试需要几个阶段，每个阶段做哪些类型的测试，如：功能测试、UI 测试、兼容性测试、稳定性测试、性能测试等；
3、对需求进行第一次详细分析，并制作出需求功能测试点，可以借助流程图等来辅助分析；
4、对功能测试点转化成详细的测试用例；
5、对需求进行第二次详细分析，分析其非功能测试点，例如是否需要做兼容性测试、稳定性测试、性能测试等，给出测试策略；
6、与开发、产品讨论分析得出其影响范围，制定影响测试用例；
陈子昂
回复
说的很全面，但第一条不是很理解，是一个测试点对应多个测试用例吗？
那比如当前这个页面（https://testerhome.com/topics/10382），回复是一个功能点，上传图片是其中一个测试点，那其中正向测试用例是不是：上传符合要求的图片成功。我这个理解对吗？