传统上,我们作为测试人员，被教导要根据功能features编写测试计划，以及那些测试计划。都慢慢转换成了测试用例。
这种感觉就是,不管是管理者还是一般人在测试的时候就觉得,一个功能一个测试用例是好的,两个测试用例是更好,和三个就更加好了....这样如此类推。
随着时间的推移，我们尝试执行了多个项目以及多个功能，所以我们慢慢收集到一定量的测试用例，就像松鼠在寒冬前收集好坚果一样。
更新:我的同事Scott
Stanton是Electric-Cloud方面的主架构师，他指出(完全正确的),测试和单元测试确实需要有一个区分了。
“…当重构代码时，大的单元测试集合就显得有很大价值……”
谢谢Scott。
现在问题就在于，一旦我们吃了我们的坚果(即执行测试用例)，测试用例不会消失。
现在你在想：“吃掉馅饼然后保留它!”
错了!
让我们回到正题。
当我们使用敏捷和使用敏捷测试时，我们需要保持灵活,我们需要能够在第一天开始做测试时，我们的团队就开始冲刺工作(“测试不仅仅是运行软件”)。
这意味着提出问题,与人交谈(开发人员、PO，有时甚至是客户)。
如果我们背负我们需要连续运行的大量库存的测试用例的重担,那么我们就需要放慢速度。
在某个时候,我们尽了很大的努力生产这些测试用例,有时候时间也可以花在在一些选择性活动上。
随着产品的发展，需要有人要来维护这些用例,并让我们不要忘记执行这些用例脚本(哪怕是完全相同的输入)时所付出的努力。
这时候你可能会说，这是没有问题的，那是因为你没有实际运行所有的测试用例。
那么，他们到底是在做些什么呢?
这其中有一个因素，就是仅仅通过大量的测试用例可能会让他们很难找到他们正在寻找的信息。如果你是这家公司正在试图遵循这种方式的测试新人，这就尤其准确了。
我之前引用到的“很难找到缺陷”,当我引用这句话时,我指的并不是我们要发现正在测试的产品的缺陷。
我指的是它很难在测试用例的前提下，找到缺陷。
如果你甚至都无法oversee，你打算怎样才能够跟得上维护你的测试用例呢?
测试用例自身也存在一些缺陷。
请联系网站客服，了解详细的优惠课程信息~
优质、权威、便捷、省心
