生命周期半年的项目需求是否有必要写用例？（2009-2-9 ）获奖名单已公布

jessies

必须要写，不写用例，你何以保证你的测试是满足需求的？何必保证你的执行过程是正确的？
对于需求经常变的项目，为什么不让需求进入到稍微稳定的阶段再进入用例的编写？需求变更是不可避免的，但是有时候，需求变更的频率是我们可以控制的。
用例天天修改可能会浪费一些时间，但是对于整个项目来说还是有必要的，可以用一种简单的方式来写用例，保证前后可追溯。

jessies

原帖由 ahu201 于 2009-2-10 10:21 发表
下面我提出我方观点:
1. 对于需求变动比较频繁,或者软件生命周期比较短的, 我们测试的依据可以适当进行调整,譬如:i, 最新的需求个功能列表. ii, 公司软件规范要求列表. iii, 软件需求变化跟踪列表.
2. 对于需求变动比较频繁,或者软件生命周期比较短的, 我们测试重点不是测试用例编写, 而是如何快速准确的定位客户的最新需求, 在软件生命周期中可开发协调工作,保证最优的实现, 将项目代价降低到最低,避免重复冗余的劳动.

对于ahu201的回答，我有一个疑问，变更后的需求，快速定位了之后，你怎么保证在多个测试人员的团队内，每一个人对这个变更之后的需求都是理解一致的？
或者提一个场景来说，如果用户提出了一个新的需求，项目组做了变更，也修改了功能列表，那么真正执行这部分功能的测试人员是否知道这个变更呢？或者说，他是否已经领会了这个变更的真正意思？他的测试是否真的遵循了变更后的列表？测试负责人要如何衡量如何保证？
测试人员的测试执行是否正确，这个又如何保证？也许他执行的过程和实际需求有出入呢？你又如何去把握？
其实我觉得这个辩题可能没有完全的描述好真正的场景，在软件测试过程中，个人认为，如果测试组是一个小团队的话，那么就需要描述清楚完整的用例场景，但是如何测试人员是熟练的或者说，测试人员就一个或者两个，那么沟通不成问题的情况，可以写比较简单的用例。
但是用例是必要的，简单的功能列表我觉得也是用例的一种，用例不一定非要标准到步骤输入输出，特殊情况下，用例可以简化，当然这个视项目组成员的能力以及项目规模和时间来决定。
对于较复杂的项目，我支持写用例，维护的成本可能比较高。但是如果项目到最后发现最后测试的功能其实是和需求有偏差的，那么这种修改带来的代价可能更加大。

jessies

原帖由 pupu840323 于 2009-2-10 15:17 发表
开门见山的说，我认为不需要写测试用例，但我们需要简化版的功能覆盖点。

三、解决方法
    为了解决测试用例的意义所带来的效益，测试用例适用性所带来的缺陷，我认为应该引入功能覆盖点来平衡这两方面因素。
    功能覆盖点是对所测试项目功能点的一个简要概括，编写功能覆盖点可以让我们去熟悉业务系统，平且将功能点，关联点等简单罗列，让我们纵观测试的广度和深度。在需求变动情况大的情况下，维护功能覆盖点的成本要远远小于测试用例，他所带来的效用是实效而灵活的。

    综上所述，测试用例在需求变动大的项目中，是不需要引入的，而应该引入更为实效的功能覆盖点，辅助测试工作的开展和考察

支付你的解决办法，但是在我们这里，我们可能会使用简化版的测试用例来代替，同你提出的功能覆盖点。