反问他：你记得你写过多少吗😋

好强的攻击性 黑哥牛逼

反正数量不能说太多，不然有些面试官会有一种鄙夷的眼神看着你

张口就说十几万个吧。怼他

不管你说多还是说少，只要他觉得跟他们不一样，就会觉得你有问题

是的 我有这种感觉 多和少都不行

面试必问之问了没啥用

其实面试就是这样，就算你回答的就是相对标准的答案，如果和他想要的答案不一样，他就觉得你回答的有问题，面试一定程度上就是看被面试者和面试官的契合度。

不输出情绪的话，我会这么回答，供参考：
用例的规模和组织要求的粒度，项目的紧急情况和业务的难易程度、重要程度都有关。这个项目我所负责的部分，明确的用例设计总数量没有特别进行记忆，但是规模没有超过 XXX，由于项目比较急，测试资源紧张，我倾向于的策略是用最小的测试用例总数覆盖最多的场景，但是测试功能点总体保持不变，多版本迭代的时候，能复用尽量复用，以缩减写用例的时间，保持用例的可维护性，保障项目的进度，但是不影响项目的质量。

反问他 问他觉得以电梯为题他能写多少案例，然后你说比他多一倍就行

没写，懒得写

“说写的很多” 那怀疑你写出来的用例很臃肿，“说写的很少” 又会怀疑你的测试设计能力不行或经验不足。

我可能会这么回答：优化需求 一般在原有用例上进行重构，新增用例较少。若是 新增需求 则会划分用例等级、做好用例内容分类以便后期实现自动化，这一类时会考虑多个维度，力求用例能够覆盖全面

一般人也给不出来具体的数字吧，只有绩效考评的时候才可能去统计统计

这个面试问题的目的，可能是想要知道前项目的规模吧...

给你我的客观的答案吧，一般这个问题我也会问。第一就是看一下你写了多少，量变引起质变，几百条用例的维护和几千上万条用例的维护肯定是不一样的。量级增长意味着你需要做更多可维护性提升的工作。同时面试官也可以顺着你的编写量继续聊下去。
上面回答的 “有人会记得自己吃过多少顿饭吗？ ” 更是无稽之谈，你做的自动化难道没报告吗？还是你的报告维度不客观的反应这个量级吗？还是说大家做了之后都不关注报告的结果。包括日志，运行时间，运行测试用例这些都是很明确的才对

答：

• 我只负责设计框架、做算法实现，就是用算法遍历代码穷举数据，然后灌入框架，每次随着构建自动执行，而且每次执行都会根据系统的变更而演进，不断学习……
• 具体执行多少不清楚，因为每次都不一样，反正就是数据记录也就千万级的样子吧……
• 所以从传统意义上来说我不写 case，我也不喜欢 case，我最开心的时候是我每个月写几十个 case 的时候……

好奇你们 “几百条用例的维护和几千上万条用例的维护肯定是不一样的” 具体是怎么维护的，我们不管写了多少用例，都是按功能存起来，功能发生变化才去摘出来维护，没碰到量变质变的情况

你这一点也不客观，你只是觉得就是这样，单纯功能用例谁不会写，真的需要维护的多吗又不是自动化，也可以直接在新需求写新用例，即使重复也比去维护老用例更方便更好用更好关联

@ 我不吃香菜
那你最近的项目写了多少用例呢？

按功能或者按需求等类型存，只是一个分组分类的过程。关键的当你的测试用例体量增长到 1000,2000....之后你的维护新增速度时候还是能保持 100 用例阶段的维护速度和新增速度，其中最关键的因素就是当你的用例越多你用例受到需求迭代的影响面就越广。这就涉及到你工程的数据维护（静态的动态的），工程的结构设计。以及出现异常情况比如环境数据破坏了恢复到正常状态等等情况后你的维护效率会不会受到影响。

1 年多时间 8000 多了

“数据维护”，“结构设计”，这是自动化框架的吧 ，姐姐的工作是专门维护用例 + 框架的么

你工作这么久了，单人还要写这么多吗？
项目规模和团队分工怎样？有多少个模块？
项目迭代周期怎样？
项目有几个测试人力？
测试用例的颗粒度怎样？
自动化用例占比多少？ 是否有通过数据驱动快速生成参数化用例？

你这 1 年写的用例数顶我几年的了
一年就要 8 千条用例的项目，得是大型金融系统且用例颗粒度极细的，否则我真想象不到你是在做什么？ 一条用例 40 个字好了，你就写了 32 万个字，都可以出本小说了

会持续迭代的需求都会转自动化，不持续迭代的末端业务就不写。用例多的地方主要是功能庞大所以复用了，不然一个小功能写 34 十条自动化测试用例的写一年都写不了那么多。另外你说的工作很多年还写自动化，单纯搭框架都 25 年了会缺框架吗？你不写测试用例工具上的优化能优化多少总会到头的。完全的测开工程师都是大厂并且岗位极少，我是没认识几个只写框架不写用例了。说白了还是个体力活

不是，你知道一年 8 千条用例是什么概念吗？
你的回复也跟我问的风马牛不相及，

我只是好奇你所做项目的规模和人力配置比，
你是怎么一年写了 8 千条用例的，这八千条用例到底是功能用例还是自动化用例，然后问出如下问题：

你工作这么久了，单人还要写这么多吗？
项目规模和团队分工怎样？有多少个模块？
项目迭代周期怎样？
项目有几个测试人力？
测试用例的颗粒度怎样？
自动化用例占比多少？ 是否有通过数据驱动快速生成参数化用例？

8000 除以 52，每周写 150 条用例。除去需求评审，除去用例评审，除去测试执行。感觉这 150 条用例得一两天写出来。

跟你说说我每个问题的目的。。。防止你看不懂

1[你工作这么久了，单人还要写这么多吗？]

我这个问题主要是验证工作经验和人力分配的合理性，
资历较深的员工，往往需要更关注测试框架设计、流程优化或团队管理，或承担有测试深度的工作，这大量的基础用例编写是不是一种资源错配的表现？。当然如果你说你公司只有你一个人，那当我没说，但是从你的回复中可以知道你也担任过面试官，那就不应该只有你一个测试。

2[项目规模和团队分工怎样？有多少个模块？]

我这个问题主要是验证实际业务需求是否需要单人 8000 条用例，
大项目、多模块的系统才可能产生大量用例，小而精的项目通常无需庞杂用例库。若模块数量少却声称用例多，可能存在虚报。团队是否分工直接影响个人工作量，若多人协作，我想知道你分到哪个模块达成这么高数量的用例？。

3【项目迭代周期怎样？】

我这个问题主要是验证是否具备时间可行性和业务合理性
迭代快的在新增用例上多是聚焦本次迭代的需求，增量小且自动化为主
迭代慢的在新增用例上以大功能模块，覆盖全场景且手动为主

4[项目有几个测试人力？]

我这个问题主要是验证用例数是否合理
如果是多人协作，假设团队有 5 人，按每人 8000 条计算，年总用例数 4 万条甚至需维护十几万条历史用例，这离谱到极致。

5[测试用例的颗粒度怎样？]

我这个问题主要是验证是否是低质量堆量
若颗粒度过细（如单个输入项拆分 10 条用例），或冗余重复（如通过数据驱动复制相似流程），看似总数量大但价值低，可能通过刻意拆条 “灌水”，那 8 千还挺正常

6【自动化用例占比多少？是否有通过数据驱动快速生成参数化用例】

我这个问题主要是验证是否包含自动化生成的 “伪用例”
自动化测试框架（如数据驱动、关键字驱动）可快速生成数百条参数化用例（例如输入不同用户类型、边界值），这类 “用例” 本质是脚本执行的参数，不依赖人工编写，本身应该也没人会去把这个记为自己写的测试用例 emmmmmmmmmm。若自动化用例占比较高（如 80%），且人为将自动化参数算作 “用例数”，则 8000 条可能更合理。

所以我才不喜欢问这种无聊的问题，正经人谁去记写过多少条测试用例？

1. 我们的人员配置是 4 个常驻 1 个不稳定就是 5 个人。我是主要负责自动化等工具。其他人功能：自动化基本在 8:2，所以不可能强求他们自动化产出有多高。
2. 我这边是需求和自动化并行进行的，其他人基本是自动化在需求完成之后，这就导致了其他人员的自动化产出效率不足。项目基本也是 2-3 天一个测试需求，很多时候还是 2-3 天测 2 个需求。
3. 项目配置，基本 1 个人一条线，我这边是游走，所以主要负责自动化的转化。
4. 你说的合理不合理问题这个就很玄了测开比基本是 1:10 以上。 5.6 合并说吧，数据驱动是肯定的根据场景进行参数化，测试用例是通过 pytest 框架编写 python 代码的。毕竟代码的继承复用和维护是平台比不了的速度就不是一个量级的只是要求会高点。