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