编写测试用例时，发现USE CASE 有“问题”，如何办？

canzhu

大家好， 在根据USE CASE 写测试用例时，发现一个“问题”。 USE CASE 里是这样写的：

当A表中的某一个“用户名”被修改时，一个触发器会做以下的操作。。。

一开始分析时，我注意力放在“修改”这个动作上， 我想应该“试几种不同的修改方法”，如将“用户名加长，缩短，加特殊字符”等等。 但后来我发现主要问题不在这里。 因为“触发器”是通过程序预先设定好的。 只要“用户名”被修改， 它就一定会被引发而执行后面的动作（除非数据库系统本身有问题）。其实我们只要随便的验证一次， 就足矣，根本不用通过不同的改变，来“证明它一定可以会被引发。”

但我考虑到了一个引申的问题：“只要用户名被修改，触发器会做以下的操作”，　这样设计的逻辑是否有问题？　在我们这个系统中，“用户名”不能重复，不能为空。如果我将用户名改为另外一个已经存在的用户名，或者删为空或空格，　或者给用户名后面加一个空格，　对于触发器而言，这些都是修改，一定要引发。　但是，如果不加检查就这样执行下去，不是违法了对“用户名”的规则？

我是新手，而 USE CASE 是老家伙写的。我是否应该跟他讲？　还是不管他，只按USE CASE 写自己的测试用例就行了？

多谢各位指正病指点。　

Jackc

首先，需要弄清设计用例的人为什么这么写？除触发器的设计逻辑以外，是否有其他的原因？比如执行测试的资源不够，需要将测试重点放在其他区域。

如果在资源充足的情况下，这样书写的用例的用例是肯定存在问题的。
1、黑盒用例的用例可以参考功能设计文档，却不能完全按照按照设计文档来写。一是设计文档不能完全代替需求文档；二是因为黑盒测试本就是从上层应用功能入手，通过用户角度的考虑，发现程序中的错误，自然也包括“逻辑错误”。
所以，非节约测试资源的情况下，仅引用所谓的“开发设计逻辑”来设计黑盒用例，本身就是一个明显的错误。

2、测试的学习更多来源于交流，当你发现困惑时，应及时询问。不管结果如何，都能为你日后对测试的真正理解添砖加瓦。
再说，写用例的是个老家伙，自然别人可能会有高于你的测试思想，多多请教才是正道。

canzhu

多谢高人指教！