我不会以‘一天写多少条测试用例’作为衡量工作效率的标准。因为测试用例的质量和覆盖性远比数量更重要。在实际工作中，我会根据需求文档、业务流程和边界条件来设计用例，确保每条用例都能有效验证系统功能。

我认为测试用例的数量并不是衡量效率的唯一标准，关键是要保证用例的质量和覆盖范围。在实际工作中，我更关注用例是否能够有效验证系统的功能和边界条件。例如，在一个需求明确、功能相对简单的项目中，我一天大概可以编写50到80条测试用例；而在需求复杂、逻辑较多的项目中，可能只能编写20到30条，但每条都会经过详细设计和评审，以确保其有效性。

这个问题看似简单，但其实考察的是你对测试工作的理解、工作方法、效率以及质量的平衡能力。不能只回答一个数字，而要结合实际工作场景进行解释。

影响因素包括：需求复杂度、业务逻辑的难易程度、是否需要深入分析边界情况、团队协作和评审时间等。在简单项目中一天50-80条是可能的，但复杂项目20-30条更现实，每条用例都要精心设计。

如果你有相关经验，可以补充一些具体数据或案例，例如：在上一个电商项目中，简单登录模块一天写了60条用例，覆盖正常和异常场景；而在支付模块，只写了25条，但包括了各种风险边界，确保了高覆盖率。

我的目标是：不是追求数量，而是通过高效的方法如等价类划分、边界值分析来设计用例，实现高质量覆盖。实际一天20-80条视项目而定，重点是有效性和完整性。

FAQ

Q: 为什么不能只说一个固定数字？
A: 因为不同项目复杂度不同，简单功能多写，复杂功能少写但精炼，面试官想看你懂平衡质量和效率。

Q: 简单项目一天50-80条怎么设计？
A: 基于需求文档快速列出正常流程、异常输入、边界值，确保覆盖全面但不冗余。

Q: 复杂项目20-30条够吗？
A: 够，因为每条用例设计详细，包括多场景组合，经过评审，能发现更多问题。

Q: 如何在面试中举例证明？
A: 分享真实项目，比如‘在XX模块，一天30条用例帮团队提前发现5个bug’。