当前位置：
/ 如何将Bug和测试用例关联
目前提BUG的时候，没有选择测试用例的栏位。
在执行用例时，如果失败，可以自动转入BUG，但是bug不显示是关联到哪个测试用例的。
有什么方法可以把测试用例和Bug关联起来吗？
6.2.stable 源码包操作系统
Windows 7客户端浏览器
提问者： 颢炎 悬赏：5 日期：
09:46:55 ***：1 点击 1367
用例执行失败右侧操作栏会有提bug的按钮，直接点击提交即可，系统会自动进行关联，关联可以在bug的详情页面（点击bug标题会进入）进行查看，如果是 测试-bug-提bug 不能与用例进行关联。关注51Testing
怎么样的测试用例才算是好的用例
发表于： 13:16 &作者：sunmoonrili & 来源：51Testing软件测试网采编
推荐标签：
　　虽然我是一名新人，但是我自认为自己是一个很有想法的人，觉得对我来说应该不是什么问题，谁知道今天发生了一件事，让我不得不重新审验一下自己的想法，以及最重要的一点是，我要搞清楚怎么样的用例才算是好的用例。　　话说事情是这样的，这次客户有一些新的需求，比如说原来的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，他认为这不是问题，还是原来的话，只要每个功能点涉及到了就行了，不需要过于详细，他认为我写的用例过于详细了，测试点过多。　　谈话谈到这里，我已经彻底无法接受了，我认为的用例的编写方法跟我们头头完全不一样，我无法接受他的想法，更无法否认自己的做法，心底下我觉得我的用例并没有问题，而且做得很对，但是我们头头要求我按照他的想法去修改我的用例，于是我很纠结～～～
搜索风云榜
( 08:43:16)
其实这个要看场合，看这个项目是否有多个Build，测试用例是否可复用，更为关键的是你和你老大对测试用例颗粒度没有统一，其实你的每一次修改测试用例对老大来说都要承担风险，这个要沟通
( 17:37:43)
换个方式考虑问题，如果按照你的方式来处理， 有bug就需要修改用例：
1. 谁负责修改，评审，这个频率有多大，怎么执行？
2. bug分不同的重要级和优先级，有修的有不修的，是否bug都要修改用例？谁来制定这个规则？
3. 一个产品的用例量会非常多，如果某个bug涉及的cases非常多和零散，这种修改是否有意义？
考虑问题要从全局出发，有意义的bug可以成为一个单独的用例，用来启发后面测试人的思路；或者用来指导以后新测试用例的重构或编写。
当前有想法非常好，这个想法并不是一定要通过马上实现来体现出它价值的，而是对以后测试架构的完善来体现的。
( 17:19:43)
貌似我的方法和你的差不多……
( 16:43:29)
不能为了能发现BUG而修改用例是很正确的。更应该回头分析是用例本身的问题还是用例设计遗漏的问题，还是要多学习
( 21:44:44)
你头头也有道理，你也没有错。想法都是想把工作做好。其实你所说的修改点，并不多，所以两种方法都是可以，不存在影响多大的效率。但可能分场合，如果直接修改老用例可能会带来问题，如果版本比较多，老的版本需要维护，就不能直接对老用例进行修改了。要新设计用例。如果没有老版本影响，是可以直接修改老用例的。
对外，测试用例还是要比较全面才行，不能只看发现问题，回归测试的时候，要需要靠老用例的覆盖测试进行质量保证，增加对质量的信心。单个用例（少数用例）质量再高，用处不大，关键是能够对所有的需求都验证到，才是好的用例。
( 14:23:21)
我也觉得其实头头有头头的考虑。觉得是该添的添。该加的加。但是你说的那些添到旧用例就行了。
( 10:06:28)
过一段时间，慢慢的积累更多的经验，你就不会这么认为了，头头说的话是从全局出发，而且要记住，测试不是为了发现Bug而进行的工作。
( 10:48:03)
写了很多本来想说说自己的想法的，不过此网站有一个BUG：& & 网站未登陆评论应该保留，或者等待注册或者登陆成功，原先的评论语言文字保存跳转此页面，不能给与直接清空，这样给用户体念很不好，如果怕安全问题可以添加验证或者其他的操作，但是人家辛苦写文字就这样清空，是给用户很补尊重的做法。。。
( 10:30:22)
用例在使用前不找开发进行评审么？一般评审后的用例算是定了，一般不做修改的~
( 15:22:38)
小伙，有想法是好事。你这种投机取巧式的测试在这件事上可能会有点效率，但对测试整体来说危害太大，会导致测试无法控制，并且会导致很多漏测的情况。自己对测试整体不是了解很清楚前，还是要虚心学习的。
( 14:49:21)
你头头说的有道理。你应该多学着点。
51Testing官方微信
51Testing官方微博
测试知识全知道