传统上,我们作为测试人员，被教导要根据功能features编写测试计划，以及那些测试计划。都慢慢转换成了测试用例。
这种感觉就是,不管是管理者还是一般人在测试的时候就觉得,一个功能一个测试用例是好的,两个测试用例是更好,和三个就更加好了....这样如此类推。
随着时间的推移，我们尝试执行了多个项目以及多个功能，所以我们慢慢收集到一定量的测试用例，就像松鼠在寒冬前收集好坚果一样。
更新:我的同事Scott Stanton是Electric-Cloud方面的主架构师，他指出(完全正确的),测试和单元测试确实需要有一个区分了。
“…当重构代码时，大的单元测试集合就显得有很大价值……”
谢谢Scott。
现在问题就在于，一旦我们吃了我们的坚果（即执行测试用例），测试用例不会消失。
现在你在想：“吃掉馅饼然后保留它！”
错了！
我一直在一个拥有成千上万的测试用例的team，而感到自豪，（包括自动化或手工),然而，一些人会为有成千上万的测试用例而感到尴尬。
我们已经从“丰田成产系统”了解到的是，库存的浪费。七大浪费分别是：花时间去生产库存（过度生产的浪费)、需要花费储存空间（手头库存的浪费）、它根据当前的需要来限制组织的快速生产（进度的浪费）。
但是最有趣的是第七浪费：“制造有缺陷产品的浪费”。
浪费，导致了“找缺陷是很难的”。
让我们回到正题。
当我们使用敏捷和使用敏捷测试时，我们需要保持灵活,我们需要能够在第一天开始做测试时，我们的团队就开始冲刺工作(“测试不仅仅是运行软件”)。
这意味着提出问题,与人交谈(开发人员、PO，有时甚至是客户)。
如果我们背负我们需要连续运行的大量库存的测试用例的重担,那么我们就需要放慢速度。
在某个时候,我们尽了很大的努力生产这些测试用例,有时候时间也可以花在在一些选择性活动上。
随着产品的发展，需要有人要来维护这些用例,并让我们不要忘记执行这些用例脚本（哪怕是完全相同的输入）时所付出的努力。
这时候你可能会说，这是没有问题的，那是因为你没有实际运行所有的测试用例。
那么，他们到底是在做些什么呢？
这其中有一个因素，就是仅仅通过大量的测试用例可能会让他们很难找到他们正在寻找的信息。如果你是这家公司正在试图遵循这种方式的测试新人，这就尤其准确了。
尽管现在存储空间是便宜,但这仍然是一个成本,让我们不要忘记生态的方面,存储消耗电力。
我之前引用到的“很难找到缺陷”,当我引用这句话时,我指的并不是我们要发现正在测试的产品的缺陷。
我指的是它很难在测试用例的前提下，找到缺陷。
如果你甚至都无法oversee，你打算怎样才能够跟得上维护你的测试用例呢？
测试用例自身也存在一些缺陷。
如果你淹没在这些混乱的、遗留的 脚本或测试用例堆中，你会做些什么?
你就像你做春季大扫除一样……你把那些没用的东西扔出去。
如果测试用例还没有被投入长期执行,如果没有人能说得清它们的目的是什么,如果它们没有带来任何价值(换句话说：新的信息)的话,你就会无情地把它们统统扔掉。
因为有太大的库存就等同于在多个层面上的浪费。
【英文原文：Test cases are our friends-But how large is your inventory?】
｛测试窝原创译文，作者：紫晴｝
