测试用例是否应该完全参照需求文档
我是软件测试的菜鸟，最近，公司第一次让我负责一个web系统的缴费模块的测试用例设计，这是一个没有支付功能，单纯的记录缴费，并更新用户缴费状态的模块。输入项最重要的是两项，缴费月份数，缴费金额我的用例，有很多被组长pass，我大都能够接收，但是有一个用例被pass让我十分纠结。是关于缴费月份数的测试用例。
我设计了一个输入缴费月份数超过拖欠月份数，点击缴费查看状态的用例，预期结果是弹出警告窗，不允许
但是被组长pass，因为他说缴费模块并不涉及实际支付，需求文档中没有提到这样的判断需求。
我的疑问有两个，这个用例是否真的多余？需求文档中没提到的需求，真的就不用测试？ 虽然不太明白功能的总体设计及需求，但是作为测试人员要站在客户的角度来思考问题，如果你感觉应该加这个判断对于用户来说更方便他操作了解系统，那么这个case就是必要的！如果这种警告给用户带来了困扰那么就不应该这样设计！ 要是系统允许预存费用，name缴费月份数是可以超过拖欠月份数的啊，嘿嘿，不知道支付的部分是否有预存的功能。 不知道支付的部分是否有预存的功能。
要是系统允许预存费用，那么缴费月份数是可以超过拖欠月份数的啊。 这个应该具体问题具体分析吧。如果你对业务很熟练了，可以肯定这个功能确实与支付无关，我认为用例可以去掉。但如果有可能相关，而开发或设计人员对你说的任何承诺你都需要去验证一下，也就是说编一条用例去验证，仅仅是一条而已。
在编用例的过程中，也需要和需求设计人员多沟通，这样可以更深入的了解系统，也可以在早起发现设计方面的遗漏或隐患。我们在项目初期编用例时，经常发现需求考虑不周到或不合理的地方，每天日报时都会总结出“需求疑惑”来给需求的boss，共同讨论，每条“需求疑惑”必须给出解释。这样对大家都有利。
页:
[1]
