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会提交缺陷报告，开发修改后，进行跟踪验证。

常见的缺陷管理工具主要有以下这些：

1. Jira ：由 Atlassian 开发的商业级项目与事务跟踪工具，可用于软件开发、缺陷管理、需求追踪等领域。其能创建、跟踪多种事务类型，支持自定义事务生命周期、状态，拥有丰富的报告和仪表板，并且可以与 Git、Jenkins 等工具集成，有大量插件来满足多样化需求，适合中大型开发团队，特别是对缺陷流程场景要求复杂的团队。
2. PingCode ：这是国内市场占有率较高的研发项目管理工具，具备成熟的缺陷管理能力。它可以收集来自 App、web/H5 网站等渠道的 Bug 问题，支持成员、角色等设置，还能关联需求、测试任务和主流开发者工具，同时可生成缺陷平均生命周期、致命缺陷占比等丰富报表，适合汽车电子、互联网等多行业的中大型团队使用。
3. Bugzilla ：由 Mozilla 公司提供的开源免费缺陷跟踪工具，能管理缺陷从提交、修复到关闭的完整生命周期，有强大的检索功能，支持自定义字段与权限管理，但安装过程较为繁琐，适合预算有限却注重流程管控的团队。
4. Worktile ：属于灵活性较强的项目管理工具，虽不是专门针对缺陷管理，但国内很多中小团队会用它进行缺陷管理。其可以通过定制看板和任务列表维护缺陷管理流程，支持详尽的缺陷属性设置和丰富的数据报表，此外还能满足企业 OKR 管理、审批等多种工具化管理需求。
5. Mantis ：基于 web 的 Php+Mysql 开源缺陷管理平台，安装和操作都比较方便，也有截图功能，报表功能较为强大，可通过汉化包进行汉化，适合小型到中型规模的团队。
6. TestRail ：由德国 Gurock Software 公司开发，是一款领先的测试用例管理工具，能提供测试用例管理、测试执行、结果追踪和测试报告等功能，还可以与 Jira、Bugzilla 等多种第三方工具集成，使缺陷跟踪流程更加顺畅。
7. 板栗看板 ：可视化缺陷协作与修复工具，通过任务卡片、看板与甘特图视图结合来展示缺陷处理状态，支持责任人指派与提醒设置，还能以进度热力图等多视角呈现，适合中小型敏捷团队以及多角色联合修复场景。
8. YouTrack ：由 JetBrains 出品的专业缺陷工具，将缺陷管理和知识库、时间追踪、Scrum 板等功能集成在一起，快捷键支持强大，界面响应速度较快。

11.测试计划和测试报告一般包含哪些内容？

注：通常测试计划和测试报告是由测试组长/主管/经理编写，但测试组或测试组内的主要测试人员也会参与编写，因此所有人都需要知道测试计划和测试报告的主要内容。

参考：

测试计划一般包含测试的目的，测试的范围，测试的策略和方法，测试的软硬件环境，测试的进度安排和测试风险评估等。

测试报告是在整个项目测试完成之后进行编写，主要时统计和分析整个测试过程的活动和产生的数据，会统计测试用例的情况，比如一共编写了多少测试用例，执行了多少测试用例，通过了多少测试用例，每个测试人员编写了多少测试用例等。

还会统计和分析项目缺陷的情况，比如缺陷的状态，是否已经修改还是未修改，缺陷的严重级别，缺陷的高发点， 项目当中哪个模块发现的bug比较多，通常缺陷的分别会符合二八定理，也就是百分之二十的模块发现了百分之八十的缺陷。

12.怎么看待测试价值？

测试的核心价值是发现问题、预防问题，帮助产品质量稳步提升。它不是简单的‘点点点’，而是理解需求、模拟用户、用逻辑和策略提前发现风险。好的测试是降本增效的关键环节。

13.如何判断哪些用例适合做自动化？

优先选择操作固定、逻辑稳定、重复频次高的用例自动化。频繁变动或视觉判断类场景就不适合。

14.项目马上要上线了，突然发现一个bug，做为测试要如何做？

如果项目马上要上线时发现了bug,我会立即确认并复现，把复现步骤、环境、日志、截图/录屏记录清楚；然后迅速评估严重性：若影响核心流程、数据或安全就判为阻塞，必须暂停上线并修复，否则评估是否可以做临时规避或记录为已知问题后上线。接着第一时间同步项目、开发，提供影响分析和处理建议（延迟上线/热修复/上线后修复并写明风险）；如果决定修复，我会配合开发定位并在修复后立即验证并做针对性回归，上线时执行冒烟测试验证并准备回滚预案。最后上线后做问题根因分析，补充用例和优化预发布流程，避免复发。