补充：通过审核测试用例，集思广益，发现产品设计的盲点，帮助设计优化

可以先通过自己对产品的理解进行测试，再回来看看已设计的测试用例，这样可以做到互补，如果一开始就是用别人已设计的用例去测试，反而到束缚了自己的思想扩展。

这个需要匿名？

发错地方了，很抱歉

我们现在用脑图

如果是自己设计自己执行的话推荐脑图。如果是设计出来别人执行的话，还是要规范用例的描述，尽量详细具体

脑图，记录到需要测试的最小功能点

思维导图理清测试思路，拆分测试点，含盖尽量全部的逻辑分支以及异常测试场景，为 Free Test 做基础。后续的用例设计保持新增功能的正向逻辑测试以及部分常遇到的逆向逻辑测试，为回归测试做基础

xmind

脑图，比 excel 方便。

#1 楼 @anonymous 帮你移到 测试管理 区了。

现在我们用脑图，但确实存在交接给别人测试的时候细节不够的问题。而且追溯起来没有 testlink 之类的用例管理系统那么方便。

目前也准备通过 xmind 与 git（git flow）管理测试用例，后续会支持 xmind 图与用例的互相转换 来支持测试计划的设定；

脑图

写了测试用例，但是在真正执行测试的时候不会按照测试用例去执行，因为一边看着测试用例一遍执行效率太低了，后期功能变动也不会去维护用例，因为用例维护了也不会去看，给我感觉写测试用例除了熟悉功能没啥作用，我这么想也可能是我还不知道测试用例的真正意义。以前用过 bugzilla 的 opia 插件管理过测试用例，感觉没有 excel 好管理。

#11 楼 @chenhengjie123 脑图的细节确实没法和传统的比，有利有弊。问题是现在所谓敏捷开发，扪心自问，有时间规矩的按测试案例执行的有多少？敏捷，变了味，还是我老了。。。

#15 楼 @quqing 所以敏捷里面很强调自动化和质量自建。我上次去参加敏捷之旅，好几个敏捷教练都有提到重复劳动都要用自动化来做。详细的你可以看下我那时候的笔记：https://testerhome.com/topics/3884

不过我也是刚转成这样没多久，之前做的事比较传统的软件，都是通过 testlink 来做的，用例详细到随便一个人都能执行。但现在时需要对业务有一定了解才可以，脑图只是用作思维导向，细节得靠自己对业务的熟悉来去做。所以还在适应中。

#16 楼 @chenhengjie123 要说一下先有鸡还是先有蛋的问题
其一、自动化测试如果只靠个人经验来写难免会有纰漏，也是要基于测试案例来写的；
其二、目前完全自动化还不现实，new featur 还是需要手工测试的，这也需要测试用例；
其三、非常认同你的观点 -- “脑图只是用作思维导向，细节得靠自己对业务的熟悉来去做”，如果用脑图写测试用例并非不可，但前提是对测试人员的业务要求比较高，而且即便有这个前提，人无完人，还是有质量风险的，毕竟不能靠人治，而要靠法治；何为法治，个人的理解测试用例就是质量的法治手段，它给了测试人员一个标准，什么样的产品是合格的，当然测试用例本身会不断优化和完善。
我对什么是敏捷开发的概念也一直很模糊，我所看到的要么翻译来的，要么八股文，但我觉得其精髓应该是一种思想，在合适的项目（研发飞船不适合）中恰当的使用敏捷，让管理提升效率，效率=质量 + 速度，如果片面的赶进度而丢了质量，那是捡了芝麻丢了西瓜。

测试用例难点不在写，而在于维护；

测试用例在敏捷中有一个很重要的点：可复用性。
一套好的测试用例应该跟一套好的开发代码一样，不仅能达到的测试需要，也能最大的减少因需求变动带来的工作量。
---以上内容针对创业项目无意义--
目前我们再尝试将测试工作重点前移，重点完成接口层的测试，依据需求文档和开发文档完善好接口测试用例，进行接口层持续集成测试。页面层的暂时先交给脑图吧，在项目不稳定期间它是个不错选择；

通过近几年的测试，我测试过程是这样的，产品提测后第一遍 我是脱离用例的 占用总的测试时间的 10%-20%。目的是凭经验尽快的发现主要的严重的 bug。 然后才是走测试用例，一般是用例和需求 一一对应测试。发现不一致或缺失的及时更新。然后再通过测试用例发散下。占用测试时间大约 50%。 然后是自由测试。主要是通过经验和 bug 进行发散。占用时间大约 30%。 不知道这样是否合理

#14 楼 @jennifer 我也是这个状态

快进快出的，推崇敏捷直接不要走用例，用脑图。但是弊端也比较明显，如果有 3、5 年经验的话，且长期使用脑图来实现测试执行的话可以。大多数大型团队，不可能使用脑图作为指导团队测试执行，原因在于大型团队中人员的水平、经验、个人体验等有较大的差异，要拟合这些问题需要大量的时间和培训。此外，个人觉得也不利于团队的管理，在测试活动继承等方面有较大的弊端。

所以，个人建议如下：

1. 小型团队，1~3 人可以考虑脑图，不写用例直接参与执行；经验值高的测试人员可以快速发现问题并提交大量的 bug；
2. 中大型团队，脑图只能作为工具，不是唯一的测试用例设计方法，还是需要老老实实写用例清单；首次测试的结果对一个项目来说太重要，直接决定了质量印象。

对于敏捷中的测试用例管理，有楼上的同志说是可复用性。实际在我们的项目中，除了流程用例复用外，大多数用例可能都还没有精简到可复用的地步，大多数都是采用多层迭代的方法逐步强化和完善。如果要说复用的话，可以考虑将测试工作前置来完成覆盖率来保障质量，比如接口方法测试等一些自动化技术，但是快速开发需要依赖一套相对成熟稳定的测试框架来实现。So，在此大家可以先自问下，目前你所在的团队有这方面的持续投入没有——这块是很关键的。

#20 楼 @liang 我们现在也是这样的。不完全依照测试用例，只是在某个阶段会用到用例。

#12 楼 @kinget007 想问下，您说的：xminder 图和测试用例相互转化是否已经实现？并且有用到实际项目测试中？

#25 楼 @guoguo 来到新公司，他们已经实现，但是对于用例的书写建议添加自己公司的规范，例如：可以以页面为节点（这样就可以以节点路径作为操作步骤，便于理解;）