之前面试中也有遇到过面试官问这个项目你写了多少用例，最近也遇到了问这个问题的。我那个项目是持续了两年，但是就刚开始需求多，后期更多的是在进行小的需求调整和维护。测试用例的数量不一定随着时间的流逝而直线增加，尤其是当项目的主要开发工作已经完成时，更多的是做一些回归测试和补充性的小需求。
我不吃香菜
回复
跟你说说我每个问题的目的。。。防止你看不懂
1[你工作这么久了，单人还要写这么多吗？]
我这个问题主要是验证工作经验和人力分配的合理性，
资历较深的员工，往往需要更关注测试框架设计、流程优化或团队管理，或承担有测试深度的工作，这大量的基础用例编写是不是一种资源错配的表现？。当然如果你说你公司只有你一个人，那当我没说，但是从你的回复中可以知道你也担任过面试官，那就不应该只有你一个测试。
2[项目规模和团队分工怎样？有多少个模块？]
我这个问题主要是验证实际业务需求是否需要单人 8000 条用例，
大项目、多模块的系统才可能产生大量用例，小而精的项目通常无需庞杂用例库。若模块数量少却声称用例多，可能存在虚报。团队是否分工直接影响个人工作量，若多人协作，我想知道你分到哪个模块达成这么高数量的用例？。
3【项目迭代周期怎样？】
我这个问题主要是验证是否具备时间可行性和业务合理性
迭代快的在新增用例上多是聚焦本次迭代的需求，增量小且自动化为主
迭代慢的在新增用例上以大功能模块，覆盖全场景且手动为主
4[项目有几个测试人力？]
我这个问题主要是验证用例数是否合理
如果是多人协作，假设团队有 5 人，按每人 8000 条计算，年总用例数 4 万条甚至需维护十几万条历史用例，这离谱到极致。
5[测试用例的颗粒度怎样？]
我这个问题主要是验证是否是低质量堆量
若颗粒度过细（如单个输入项拆分 10 条用例），或冗余重复（如通过数据驱动复制相似流程），看似总数量大但价值低，可能通过刻意拆条 “灌水”，那 8 千还挺正常
6【自动化用例占比多少？是否有通过数据驱动快速生成参数化用例】
我这个问题主要是验证是否包含自动化生成的 “伪用例”
自动化测试框架（如数据驱动、关键字驱动）可快速生成数百条参数化用例（例如输入不同用户类型、边界值），这类 “用例” 本质是脚本执行的参数，不依赖人工编写，本身应该也没人会去把这个记为自己写的测试用例 emmmmmmmmmm。若自动化用例占比较高（如 80%），且人为将自动化参数算作 “用例数”，则 8000 条可能更合理。
所以我才不喜欢问这种无聊的问题，正经人谁去记写过多少条测试用例？
- 我们的人员配置是 4 个常驻 1 个不稳定就是 5 个人。我是主要负责自动化等工具。其他人功能：自动化基本在 8:2，所以不可能强求他们自动化产出有多高。
- 我这边是需求和自动化并行进行的，其他人基本是自动化在需求完成之后，这就导致了其他人员的自动化产出效率不足。项目基本也是 2-3 天一个测试需求，很多时候还是 2-3 天测 2 个需求。
- 项目配置，基本 1 个人一条线，我这边是游走，所以主要负责自动化的转化。
- 你说的合理不合理问题这个就很玄了测开比基本是 1:10 以上。 5.6 合并说吧，数据驱动是肯定的根据场景进行参数化，测试用例是通过 pytest 框架编写 python 代码的。毕竟代码的继承复用和维护是平台比不了的速度就不是一个量级的只是要求会高点。