1.功能测试流程（工作流程）
需求分析 -- 测试点分析（xmind）-- 编写测试计划/用例及评审 -- 执行测试用例（开发提交测试）-- 发现缺陷通过缺陷管理工具提交 -- 回归测试及bug验证（开发提测新版本） -- 测试报告编写及评审
测试计划
是指导整个测试过程的纲领性文件，主要回答 “为什么测、测什么、怎么测、谁来测、何时测、资源有哪些” 等宏观问题，目标是确保测试活动有序、高效地进行，覆盖项目的测试需求和质量目标。测试用例
是测试执行的具体依据，主要描述 “如何测试某个功能 / 场景”，包括输入数据、操作步骤、预期结果等，目标是验证软件是否符合需求规格。
2.常用的测试用例设计方法
- 用等价类 + 边界值覆盖输入验证；
- 用场景法覆盖业务流程；
- 用判定表处理多条件逻辑；
- 用错误推测法补充潜在缺陷。
3.项目团队多少人？测试人员几个？如何分工？
项目团队大概xx人，测试人员xx人，我们一般按照功能模块进行分工
4.最近一个项目一共写了多少条用例？发现了多少个bug?
大概写了xx条测试用例，一共xx人,编写了xx时间，在编写的过程中发现需求模糊的地方还需要和产品经理进行沟通。
一共发现了xx个bug,开始的轮次发现的缺陷会比较多一些，后面回归测试中逐渐减少，其中一般级别的bug数量最多。
5.你一天大概写多少条测试用例？
按照我目前的能力，按照系统的复杂度来看，通常一天可以写一百多条，如果是需求有模糊不清的地方或者业务比较复杂，可能写的少一些，几十条。
6.如果你发现了一个bug，但开发人员不认可，你会怎么处理？
如果我提交了一个bug，开发人员认为不是，那么我首先要再次确认下这个bug是否存在，是否影响用户的实际使用，确认后，在和开发人员进行沟通，讲清楚这个缺陷的复现步骤和对用户的影响，争取能够取得开发人员的认可。如果还是不能达成一致，那么我本着对用户负责的态度，需要将此bug的情况上报给测试经理和项目经理，由他们进行裁决。
7.一个不能复现的bug需要上报吗？
这个问题还真遇到过，一般发现的bug都需要反复求证复现的步骤，确认百分百复现后才上报，但遇到比较严重的问题，虽然不能复现，但还是有一定的出现几率，那么我们也要上报，需要提交给开发人员进行定位或者观察，但这种bug我们一般会在缺陷报告中标明出现的概率，比如 必现/大概率复现/小概率复现/仅出现一次。
8.测试工作通常是什么时候开展的？
项目的测试工作一般是在需求阶段就会介入，参与需求的讨论，需求经过评审之后，我们就开始依照需求进行测试用例的编写。
需求讨论主要是从测试人员的角度审查需求描述是否清晰，准确，是否可以编写用例进行测试。
9.项目的迭代周期一般多长时间？
项目初始时迭代周期一般长一些，大概一两个月，后面根据迭代的功能和修改的缺陷时间逐渐缩短，一般一两周一个迭代周期，项目上线前期甚至一周几个版本。每个月大概迭代十个版本。
10.使用什么管理缺陷的？
使用的pingcode/禅道，项目管理工具，可以用来管理产品的需求，项目的任务，测试用例和跟踪bug，主要用来管理测试用例和缺陷（和需求）
编写了测试用例，依照开发提交的版本进行测试用例的执行，执行的过程中发现bug会提交缺陷报告，开发修改后，进行跟踪验证。
常见的缺陷管理工具主要有以下这些：
- Jira ：由 Atlassian 开发的商业级项目与事务跟踪工具，可用于软件开发、缺陷管理、需求追踪等领域。其能创建、跟踪多种事务类型，支持自定义事务生命周期、状态，拥有丰富的报告和仪表板，并且可以与 Git、Jenkins 等工具集成，有大量插件来满足多样化需求，适合中大型开发团队，特别是对缺陷流程场景要求复杂的团队。
- PingCode ：这是国内市场占有率较高的研发项目管理工具，具备成熟的缺陷管理能力。它可以收集来自 App、web/H5 网站等渠道的 Bug 问题，支持成员、角色等设置，还能关联需求、测试任务和主流开发者工具，同时可生成缺陷平均生命周期、致命缺陷占比等丰富报表，适合汽车电子、互联网等多行业的中大型团队使用。
- Bugzilla ：由 Mozilla 公司提供的开源免费缺陷跟踪工具，能管理缺陷从提交、修复到关闭的完整生命周期，有强大的检索功能，支持自定义字段与权限管理，但安装过程较为繁琐，适合预算有限却注重流程管控的团队。
- Worktile ：属于灵活性较强的项目管理工具，虽不是专门针对缺陷管理，但国内很多中小团队会用它进行缺陷管理。其可以通过定制看板和任务列表维护缺陷管理流程，支持详尽的缺陷属性设置和丰富的数据报表，此外还能满足企业 OKR 管理、审批等多种工具化管理需求。
- Mantis ：基于 web 的 Php+Mysql 开源缺陷管理平台，安装和操作都比较方便，也有截图功能，报表功能较为强大，可通过汉化包进行汉化，适合小型到中型规模的团队。
- TestRail ：由德国 Gurock Software 公司开发，是一款领先的测试用例管理工具，能提供测试用例管理、测试执行、结果追踪和测试报告等功能，还可以与 Jira、Bugzilla 等多种第三方工具集成，使缺陷跟踪流程更加顺畅。
- 板栗看板 ：可视化缺陷协作与修复工具，通过任务卡片、看板与甘特图视图结合来展示缺陷处理状态，支持责任人指派与提醒设置，还能以进度热力图等多视角呈现，适合中小型敏捷团队以及多角色联合修复场景。
- YouTrack ：由 JetBrains 出品的专业缺陷工具，将缺陷管理和知识库、时间追踪、Scrum 板等功能集成在一起，快捷键支持强大，界面响应速度较快。
11.测试计划和测试报告一般包含哪些内容？
注：通常测试计划和测试报告是由测试组长/主管/经理编写，但测试组或测试组内的主要测试人员也会参与编写，因此所有人都需要知道测试计划和测试报告的主要内容。
参考：
测试计划一般包含测试的目的，测试的范围，测试的策略和方法，测试的软硬件环境，测试的进度安排和测试风险评估等。
测试报告是在整个项目测试完成之后进行编写，主要时统计和分析整个测试过程的活动和产生的数据，会统计测试用例的情况，比如一共编写了多少测试用例，执行了多少测试用例，通过了多少测试用例，每个测试人员编写了多少测试用例等。
还会统计和分析项目缺陷的情况，比如缺陷的状态，是否已经修改还是未修改，缺陷的严重级别，缺陷的高发点， 项目当中哪个模块发现的bug比较多，通常缺陷的分别会符合二八定理，也就是百分之二十的模块发现了百分之八十的缺陷。
12.怎么看待测试价值？
测试的核心价值是发现问题、预防问题，帮助产品质量稳步提升。它不是简单的‘点点点’，而是理解需求、模拟用户、用逻辑和策略提前发现风险。好的测试是降本增效的关键环节。
13.如何判断哪些用例适合做自动化？
优先选择操作固定、逻辑稳定、重复频次高的用例自动化。频繁变动或视觉判断类场景就不适合。