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