说说我对执行用例这个操作的看法：【有些地方做的还是不够好】

我们公司其中一个部门一直在用禅道管理项目

因为他们站在开发角度来说，对于项目的开发过程的管理非常方便。

能够对产品、产品下的项目、项目下的需求，以及由需求生成的各项任务的管理都很方便，也很直观

但是为什么测试管理这块渐渐被弱化了呢？

1、编写用例的时候。能关联需求，但是选择关联需求的下拉框是一个列表，并不是一棵树，这样选择起来就很麻烦。

    经常有相似名字的几条需求，选择的时候不知道该选择哪条，我觉得这里要么显示一个简单的树形结构，要么弹出一个对话框，同样加载需求的那棵树，由用户来选择。当然，这个不是必填项，选不选用户自己来决定。

2、执行用例的时候。一条用例有多条步骤，执行的时候其中某一个或者多个步骤失败了。右边有一个“实际情况”，我们就已经填写了错误的信息，执行完所有步骤，点击保存是否就应该自动生成相应的缺陷呢？这里没有。而且也没有新建缺陷的按钮（我指的是执行用例的过程没有新建缺陷的功能）。好吧，没有生成相应的缺陷就我们自己手动来创建缺陷吧，点击失败的那条用例右边的那个爬虫一样的按钮，点击生成缺陷，竟然发现这条用例所有的步骤、所有的预期结果都已经自动加载在缺陷内容里。要知道一条用例失败，可能就那么几个步骤是失败的，为什么要把所有的步骤、所有的预期结果都加载出来？用例步骤15-16个也是经常出现的，我们有时候自己都不记得是其中哪个或者哪两个步骤失败了。难道又回去点击用例的执行过程去查看吗？（注意点击用例的详细信息是什么都看不到的）

  一条用例有三个步骤失败了，我得用笔先把出错误的这三个步骤记下来，然后一条条再去提缺陷，还要和执行过程写的原因一样。。。我怎么觉得不但没有给工作带来便利，反倒造成了很多浪费的工作量呢？

3、再说说直接提交bug的操作吧。有时候点击系统的某个地方，就突然出现缺陷了，这时候并没有执行用例，但也是缺陷对不对？我们得记录下来啊。提bug的时候，竟然没有关联用例的地方，确实是没有，为什么没有这个呢？难道作者觉得没必要吗？还有缺陷关联的需求和任务，同样是列表形式，上面已经说过了，建议加载树形结构，哪怕是简单的一棵树。当然如果用户自己在需求那不维护树形结构，就不用去管他们了！

我从bugfree一直用到禅道，单纯的提bug感觉还行，缺陷处理流程也还行，但是随着项目的渐渐庞大，测试过程渐渐规范，就发现很多执行过程中不合理的地方。以上观点纯属个人意见，作者要是看到了可以选择性的采纳，荣幸之至！