xmind设计测试用例以及与云效平台的交互

• 为什么使用思维导图：

1. 把需求文档中的需求点整理到思维导图中，就不用一遍遍的去看文档，节省一些时间；
2. 思维导图更符合人的认知规律；
3. 在时间紧张时，思维导图可以替代用例，省去“写用例”的时间，将更多的时间放到测试执行上；
4. 利于评审。评审思维导图整理出的测试点比评审测试用例更清晰明了。对参加评审的产品和研发人员来说，看到测试点就能了解到测试覆盖是否全面，如果有的测试点不清楚输入输出，可以标出来单独提问；
5. 整理思维导图不会花费很多时间，不会因为增加了这个环节就导致测试时间不够用，况且可以把导图导出为excel格式。

• 不足：思维导图不能完全替代用例。一方面用例中会详细描述输入输出（包括一些测试数据），这对于执行他人用例时有帮助；另一方面，管理者可以根据用例更好的检查工作、评估工作量；更重要的，用例可以整理出一些测试集，结合到每次迭代中。

 

• 如何用xmind编写精简的测试用例：

   1.  一看用例名，就知道步骤及预期结果的，仅写用例名

    这里的用例名，也就是我们的测试点、需求验证点。

    这里对编写测试用例的人有个要求：语言组织能力+思维能力，尽量做到划分合理，且见名知意。

   2.  仅看用例名，不能预知操作步骤的，还须把操作步骤写出来 

   3.  仅看用例名，不能预知预期结果的，还须把预期结果写出来 

   4.  针对一些步骤比较复杂的用例，步骤和预期结果都要写出来。

    复杂情况下，一个用例包含多个操作步骤，这些操作步骤中，每个步骤可能都对应一个子测试点(预期结果)。如上，可以新增 一  个结点，填写预期结果，也可以和操作步骤写在同一个结点，以括号等不同方式进行区分。

  5.  预期结果、操作步骤有时候都可简写：直接以备注、说明、提醒点替代

 注：用例粒度可粗可细，结合时间成本考虑，做到合理的划分即可。 

 6.  技巧

  根据具体情况，可以适当做些备注(可以是一些业务逻辑、规则、需求、预期结果等)，让人看得更明白 

  为了避免模块层级过多，可以不进行模块划分就不划分，当然也可以采用其它技巧，比如模块名称写成“大模块-子模块”的形式

•   写测试用例思考的维度：

1. 每个子主题都有对应的测试点，基本需求需要覆盖；
2. 空值，最大值，异常测试点。思考异常测试点的时候，可以把这个处理过程跟业务结合起来，考虑一下每个环节出错时会出现什么问题。程序说到底就是处理数据，数据的处理方式无非是增删查改。做测试分析的时候，就是结合业务，考虑每个元素增删查改对应的是什么；
3. 以前出现的bug中，有没有需要借鉴的。有的话整理到测试点中；
4. 如果是app功能，考虑的时候也要有app相关的专项测试。
5. 作为一名测试人员，需要从多个角度考虑问题。除了从公司盈利角度考虑问题，还应该从程序员、客服、客户等人的角度去考虑问题，需要考虑这个情况在现实中是否存在，怎么处理更合适。拿客服角度来说，作为测试人员，你要考虑她们处理的那些问题中，有哪些是可以在程序层面上进行优化的，这样做好了，就可以大大减少客服的工作量，同时提升用户满意度。
6. 网上搜索一下类似的功能，看看有没有可参考的；

• xmind与云效的交互：

1.  每级主题加上步骤1，2，3，叶子节点可以省略。
2. 可以通过画布的形式，一次性导入多个xmind.会在云效以平行目录的形式显示。
3. 用Xmind编写用例，最好能合理的划分模块，然后每个画布放一个模块，具体操作如下，右键中心主题 -> 插入 -> 从主题创建新画布

 

补充：

话说，写用例、设计用例是需要时间的，而在追求速度的时代，似乎连这点时间都给不起。这不是我吹的，特别是互联网，大部分公司都采用敏捷开发模式，讲究快速，所以，时间往往是有限的，再加上很多公司对敏捷仅停留在概念阶段，以为“敏捷=快速”，把时间花在用例设计上简直就是一种浪费….这样一来，用来设计用例的时间有时候，真是少之又少。如果按传统方式，把用例写得很详细，各种前提条件，步骤，说明，预期结果，编写人，日期啥的，这个时间成本是很高的。

再说可执行性。经常看到一些人写用例写得很认真，很详细、具体，把每一步的操作都写了，还有一些人一个用例下来，十几个步骤，包含了n个验证点。这种用例的可执行性咋样呢？按我的经历来看，这种类型用例，在测试的时候，用例编写人自己都懒得看用例，完全是按自己的当前时间的想法来测试，而非用例编写人呢？同样的，他也不会完全按照上面的步骤来执行，人嘛，都喜欢按自己的方式来做事，谁会看一下用例步骤，然后操作一下呢？所以，最后的结果是，用例文档就是摆设，放在那里，没人看。

    怎么破？

    我的观点是：测试用例必须写，而且还要“精炼”：能不写的尽量不写，能“简写”的尽量简写----“精简”的思维->简而言之，当前面的部分，已经起到了足够的提醒作用时，后面部分就可以不写。这样做的好处是，不仅可以节省时间，而且还给执行用例的人留下一定的思考空间，有利于TA的成长。