话说事情是这样的，这次客户有一些新的需求，比如说原来的merchant ID改成merchant code， TID改成终端serial_no， 在屏幕上增加VAT的输出（以前只有base amount的输出），当前时间增加秒级（之前只有日期，小时，分），金额中增加货币，如以前是1000，现在变成1000元等。
按我的想法是新需求就增加新的用例，用例中重点体现这些新加入或修改的内容是否正确，而按我们头头的想法却是在旧的用例中修改，加入这些新的内容。
先说说为什么我觉得是增加新的用例，而不是在旧内容中更改，理由一，每次测试都应该有一个测试重点，不能每次都把所有的用例全都跑一遍，这样测试人员会很累，像这次新增加或是修改的内容应该作为新的一次测试重点，测试过程中只需要测这些新增或修改的内容，以及新增或修改部分可能会影响到的功能，不相关的用例可以不跑，因此用例应该体现出测试重点来。然而我们头头的意思是在原来的用例上修改，而且用例写完了还得全部再跑一次所有的用例，因此我觉得很悲剧。目前我们的用例没有任何层次性，一个项目对应一整套用例，如果有新需求就在原来的基础上进行修改，按头头的意思是如果不对原来的用例进行修改，那么会导致后面的测试无法按照用例来跑，因为用例是旧的。
好吧，我承认我无法反驳这一点，旧的用例无法跑，或是新入职的测试人员想通过测试用例了解测试过程时可能会令他们感觉很迷茫，这些用例都不对嘛！可是我也无法说服自己每次增加一些新需求就得重新修改用例，纯粹的copy->粘贴，没有什么技术含量，感觉好浪费时间，而且最重要的是下一次测试得全部测过一遍会让我提不起干活的劲头，如果有一个很直接的目标，那么很容易让我有那种“OK，就是它了”的感觉，然后很有干劲地直奔过去处理，但是假如有N多个目标，那么这样只会让我觉得提不起劲，感觉没有了目标，因此最后的结果还是重点测一下新增或修改部分，对于其他大多敷衍了事。
理由二，在原有的用例上修改的话意味着我得从头核对一次用例，看哪些需要修改就进行修改，这样我的工作量便增大了，这让我这种以追求效率为目标的人很难受，换另一句话来说就是觉得浪费时间，按头头的想法是预算中给了你一周的时间，工作量不成问题，好吧，这点，我也没法反驳，确实，时间是足够的，但是问题在于我们不能因为预算时间足够就可以随便浪费时间，如果有多余的空闲时间我可以学习其他方面岂不是更好，不过这句话我可不敢跟头头说，人家请你来是干活的，可不是学习的。
理由三，在写旧的用例时，输出数据不是所有的数据都列出来的，而是只挑我认为的重要的项才列出来，其他数据略过，当初觉得merchant ID， TID不重要，根本就没列出来，而且当前时间也不列出来的，现在必须加入这些，那么如果在旧用例上修改的话，意味着每个相关的用例都得加上这些，又是一个copy->粘贴的过程，如果是增加新用例，我可以在一个用例中把这些信息包括进去，这样就省事多了，总的来说，还是时间问题。按我的意思是这些东西并不是那么重要的，写一个用例来查看就可以了，没必要在每个相关用例上都增加进去，就算是以后新入职的人员写用例也是将其作为不重点信息，因此用例上没有这些信息倒也不相干，既然如此，我增加一个用例来测试这些新增加/修改的内容就OK了，但是按头头的意思，写用例时不需要把所有的项都列出来，挑重点项列出来没问题，但是既然客户提需求了，就必须把提到的都列出来了，而且他认为这些新增加/修改的内容不能作为一个测试点来看待，因此不能独立成为一个用例。
我问头头为啥不能作为一个测试点，这次的测试我在测试过程中肯定要查看这些内容是否正确的呀。而头头的回答是，只有与具体某个功能相联系才能作为一个测试点，不能说你的测试点就是查看一下屏幕是否显示正确，这不是一个测试点，只是一个测试点中的一个环节，听到这里我就开始迷茫了，这跟我认为的测试用例完全不是同一回事了。
在我看来，用例是指导测试用的，那么用例就应该体现我的测试过程，测试思想什么的，比如说我测试的时候是这样的，比如测试一个报表吧，有多个查询条件，那么第一步我会先查看一下这些查询条件的显示是否正确，比如说有弹出框选择，那么选择完后在输入框中显示的内容是否跟我的选择一致，这是一个测试点，然后再是点击查询按钮查询出来的结果是不是按照我的查询条件得出的结果，这又是一个测试点，这里就包含了两个测试点，也就是说至少需要两个用例。然后按照头头的想法是报表的功能是查询功能，那么只能是以某个查询功能来写用例，像我所说的第一个用例完全没必要写，第一个用例只是整个查询过程的一个步骤，而不能作为一个测试点。
正是因为我跟头头理解的用例完全不一样，于是我们的谈话进而提升到讨论什么样的用例是一个好的用例。
我刚做测试的时候，我的确是不懂怎么写用例，于是都是按照一个功能一个功能地去写用例，就是我们头头说的那种，但是在测试过程中我就发现了一些现象，虽然每个功能都涉及到了，但是，1、有很多bug没法找到相对应的用例；2、有时候一个用例对应N多个bug；3、有时候N多个用例对应一个bug，即一个步骤错了，那么所有包含该步骤的用例都fail了。4、有些用例写得过于笼统，无法指导测试过程，也无法体现你的测试思路。于是针对各个问题，我的应付是，对于1，找不到bug的时候我就想一下这个bug是怎么发现的，为啥用例没有，大部分时候是因为缺少具体的测试点造成的，于是我就给这些bug新增测试点，对于2-4，总结了一下，大多也是因为测试点的问题，于是我把用例改了，每个用例对应一个具体的测试点，针对有些很容易出现问题的地方，增加多一些测试点，这样子把用例修改下来后，我发现无论是测试过程还是测试结果的执行都省事了，因为测试标题写的就是测试点，这样我在测试过程中不需要看用例的具体步骤，我就知道该怎么测了，就按照测试点跑一遍就OK，当然了，这需要你对系统熟悉了之后做的，如果不熟悉，还得看看步骤怎么操作的。在执行测试结果的时候也很省事，我只要对应一下哪个测试点出了问题，就给它一个fail，没问题的就给它pass。如果像之前的用例那样，如果是某个步骤错了，凡是含有该步骤的用例我都得给它一个fail，因此在执行的时候还得一个一个去看，好烦人地说。
结果我跟我们头头这么一说，这下子就出问题了，他觉得我做事的方法不对，做事不是这么做的，用例也不是这么写的，然后说了很多理由云云。
我问他说“一个好的用例不是应该是一个能发现bug的用例么？”在我看来，“不管白用例黑用例，能测出bug的用例就是好用例”，他说是，但是不能为了发现bug而修改用例，因为写用例之前是不知道哪里会出现bug的，所以只能根据功能点来写，把每个功能点涉及了就行了，你发现了bug之后再来修改用例，是因为你知道这么做会出现这个bug，但是这个过程就不对之类的云云。
针对上面测试过程中出现的4点问题，对于1，他觉得既然是因为问题出现在有些缺少的项中，那么就去修改用例，加上出现的bug的项就OK，没必要增加新的测试点；对于2-4，他认为这不是问题，还是原来的话，只要每个功能点涉及到了就行了，不需要过于详细，他认为我写的用例过于详细了，测试点过多。
谈话谈到这里，我已经彻底无法接受了，我认为的用例的编写方法跟我们头头完全不一样，我无法接受他的想法，更无法否认自己的做法，心底下我觉得我的用例并没有问题，而且做得很对，但是我们头头要求我按照他的想法去修改我的用例，于是我很纠结～～～
扫一扫
1185
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
