脑图一时爽，效能提升火葬场～
当你想度量的时候，你还是需要结构化的传统 case 数据，而且这些需要沉淀到产品文档中去，换句话说，脑图当时当事人自己看得懂，别人看或者过段时间看可能就未必看得懂了，它一种提炼信息、思路的方式，细节损耗多，测试用例肯定不能全靠他……

metersphere 的用例管理模块，印象中也支持脑图形式的？

不过我觉得你们这个推进，应该最主要的问题，还是角色和时机。开发不清楚测试的痛点，测试也不一定喜欢由开发来主推这个事情，然后就会导致没人能拍板推进落地，容易不了了之。

如果是测试觉得 metersphere 能解决自己痛点，进行主推，可能又是另一个故事了。

用例不是测试说了算吗，开发懂锤子的用例。。。

还给出没深度的结论，也是醉了，用例只有覆盖的全不全，没有什么浅显和高深之分。

1、非常好奇：“前几天有个开发想推一下 metersphere”，开发人员为啥要推 meterphere 呢，测试用例是测试内部的事，应由测试来考虑，包括评价。
2、建议：测试分析时用脑图，但细化用例时，需转化，体现关键信息，包括预设、操作步骤、预期结果，便于测试过程管理（充分性度量，与需求、代码的追溯等）
3、此处的开发，是指管理测试组的开发领导么？

解释解释什么叫深度？什么叫深。。。度。

思考，流程规范和效率到底选哪个，metersphere 界面很丑

同意@Ouroboros
用例要看覆盖的是否全面，至于深度？？？？？

当然如果能覆盖全面的基础上，让用例的可阅读理解及执行效率上做点文章，才是更优的用例。

至于为了敏捷选择脑图作为用例方式，那更考验设计者是否写的清晰了，
业务后续维护转移其他人测试时，好不好其他人理解呢？

itest work
第 1 步写脑图用例

第 2 步把脑图用例同步为标准用例，同步的时候要选一个迭代

第 3 步，在脑图上执行用例 或是在迭代下执行用例（也可以以第 4 第 5 步的方式执行更便于管理 ）

第 4 步，分配迭代下，不同的人执行不同的用例。更细化管理测试迭代，一个迭代有可以几 100 上到几 1000 用例，
按功能分配不同的人执行不同的用例

第 5 步,在迭代下以需求树执行用例，需求树进行了过滤，只显示执行人所分配的用例所对应的需求

第 6 查看迭代执行用例情况及 BUG 情况

iest work 是免费的，一个月发两到 3 版，官网及在线体验
www.itest.work

根据我对开发的观察，他们所谓的深度就是操作复杂度，比如一个 bug 在 A 情况下没问题，加上 B 情况才有问题，对他们来说就是有深度的，相反，他们对数据长度啊，输入类型啊，错别字和式样就认为是简单的。当然，我觉得这种混合场景用例的设计确实是一个值得思考的问题。

这评论区打广告的过分了啊，还这么长！
槽点过多，就挑着说。
用例不是写给自己看的，更多的是在非己方测试时作为交接文档使用的，而且详细的用例文档还可以作为回溯依据和新人学习使用，想建立成体系的测试团队和流程，详细文档产出是必要的；
用例确实谈不上深度，更多的是经验之谈的全面与否，如果你认为新增功能一个期望比对数据库数据一个期望正确查询出该数据的深度是不一致的，那就有深度吧

我倒觉得不然，itest 很务实的感觉，你要说测试用例不是给自己看的，那我觉得他的意义就不大了，毕竟你自己都不爱看的东西，指望谁会看呢？

自己不看就没意义啦？如果意义就在给自己看的话，你是选择用脑图记录还是写繁杂的 excel？
我想所有同行在最开始做的时候都会被灌输过写用例的各种注意点，比如写清楚操作步骤、写清楚具体的期望结果、写清楚操作中要输入的具体值、写清楚场景必要的前置条件、还有最普遍的一句质量要求：
你写出来的用例要让没接触过这个系统的新人小白都能够去执行！
所以在我的理解中，用例更多的是作为某些时间的共享物或者说是参照物；一篇完善全面的用例文档可以持久性的作为其功能的入手点，堪称技术人员的帮助文档

如果你认为是广告,我无力反驳。我主要是看贴主，有这块的管理问题，我简单分享一下，ITEST ，也不收费，免费用，好东西分享一下，测试人员，不应该多些好奇心，多了解一些工具么，我是本着真正敏捷测试落地的好东西和得大家分享，你无视就行。

不是给自己看的 == 自己都不爱看？
这啥逻辑？

“你写出来的用例要让没接触过这个系统的新人小白都能够去执行！”

说实话这个观点和标准在现在已经不那么适用了。特别是对复杂的系统，你敢放心把用例交给小白去执行？没有一段时间的培训和熟悉，你敢信他能正确理解你用例设计的测试目的和测试步骤？

写用例是需要时间成本的，用例步骤，期望结果写的越详细，所需要的时间成本越高，维护的成本也越高。反而如果我们是以 “对系统有一定熟悉程度，并且接受过足够的业务培训和用例交接的测试工程师” 作为你的用例编写的标准，对成熟的团队反而是更有效的方式。

只是开玩笑。我这就去学习下；
请问只是用例管理版本管理的功能吗，类似 tapd 之类的？执行是手动修改用例状态，不是脚本啥的吧？

首先这句话不在于目标，而在与共享和交接；不在标准之类的，而在用例文档存在与否对产品和团队的不同影响。
如你后面所言，一份恰当适用的用例对成熟的团队在工作交接等方面是很有效的方式

个人看法，如果是这种用例，思维导图是可以，如果是进入用例库，我这边是不过关的，都没有实例化，比如空格，直接在步骤中写明输入 3 个空格等等，数据清晰，操作明了。设计用例，耗费脑细胞，执行用例就直接看着用例执行就好了，而且给别人执行也没有问题，这才对吧~

这就是脑图的本真用法，没有前置也没有步骤和预期；想要标准用例，转为标准时可以改 或是用这个第三方开源插件
https://testerhome.com/topics/34094 ，这就是别人写的用脑图写标准用例，转为 itest excel 导入模板的格式，再导入到 ITEST 中

感谢分享，第一次知道还有这玩意~

就是一个开发组长，不是管测试的，我感觉他的意见完全是他对应的测试人员相互配合的不好，我们 100 多的开发人员从来没人说过用例的事。

现在系统成熟，人员变动也小，我们这个业务的测试我待了 11 年了，其他测试人员也五年以上，开发人员变动也不大，所以我们的用例基本上就没那么细致了，要说细致的也写过，阅读起来太费劲，还不如一个流程图直观，流程了解了才去了解小分支。

1、这个工具可以标识大家有没有阅读用例，两个开发同时执行时，能看到哪个人执行了哪部分必免重复
2、用例可以看标明前置条件，步骤，结果
3、用例评审方便

直接 xmind 就行了，搞那么复杂，要么一键导入 xmind。
一个一个的用例，还不如思维导图清晰。
看问题：1. 整体；2. 局部；3. 微观；4. 细节；

1. 开发分工问题。即便同时操作一个，也势必有强依赖。
2. 给他自测用例。
3. 脑图评审更清晰，功能模块归类更容易让人懂。

手工测试是 要手工去改用例状态，只是我们是以敏捷测试的方式一个一个迭代的来执行；
自动执行是接口测试，可定时执行 也可通过 jenkins 触发执行，他可以手动一键执行一个场景下的所有接口用例

你们实际可以沉淀出用例库，某个迭代测试时，导入相关产品用例库用例到项目中，然后以脑图模式显示就行
新的改动先用脑图写用例， 空了再基于脑图转 EXCEL 把细节补充进去 (不空的话，业务稳定直接用脑图来执行也 O K)，再导入到用例库中，这样的话，就算人员流失，造成的损失最小

目前也有这个困惑，因为我一直都是习惯编写标准用例。
目前算是带 2 个组员吧，测试经验都是一年多，他们毕业以来的习惯都是使用脑图，跟我之后我要求都写标准用例。项目更多是活动类型，活动过了就过了。但是后续可能会有相似的形式，我是觉得标准用例也是有复用意义的。现在有人提出标准用例写得太乱了，希望用脑图更直观简单。虽然理解，因为这种一次过的形式我就让他去尝试，但是这种用例写出来在我看来就像一个测试点，就是熟悉业务的人能看明白。对于一些耦合、递归、循环的场景相互之间的关系，人觉得不能表达得很好，但是每次测试结果过去了就过去了，没有什么大问题也不会有人在意。

我的想法跟你有点像耶，我目前看过的脑图用例都是很多内容都被忽略，输入、前提都需要是对业务熟悉的人才能读懂，再要求写详细就不如写标准用例了