我们在考虑测试用例管理的时候，其实不能单纯考虑测试用管理，因为你的测试用例是需要和需求关联起来的，是需要和 bug 关联起来的。在有些行业，比如汽车、医药，不仅要对需求进行测试，还需要对架构设计、详细设计进行测试，而且他们之间必须建立追溯性。即使是在一般的软件开发行业，这种追溯性也是有必要的，因为它有利于团队确定，某个测试计划，是否覆盖了本次发布的所有功能，或者本次修复的所有 bug 。
有些团队可能选择线下的 Excel 来管理测试用例。假如说他选择了另外一款线上的需求管理工具，就要考虑线下的 Excel 怎么和线上的需求管理工具打通，或者他选择了一款线上的需求管理工具，测试管理选用了另外一款工具，那就得考虑怎么把需求管理工具和测试用例管理工具打通。在测试的过程中，还需要创建 bug，还需要考虑如何关联bug。打通的过程往往涉及到二开，而且难以保证比较好的使用体验。
这就是为什么我们在考虑测试用例管理的时候，一定要考虑这款工具是否支持需求管理和bug管理的原因。
基于这个考虑，我们团队非常推荐 MappingSpace 这样一款工具，它是用思维导图的方式来管理研发过程中的所有任务的，包括需求、开发任务、测试用例、bug等等，全部是用思维导图来编写的。注意是编写，而不是像有些工具那样，仅仅是导入。
那么测试用例用思维导图来管理有什么好处呢？
首先，在创建需求时，产品工程师会依据他对于产品的理解，从一个点出发逐渐地扩散。使用思维导图，是一种非常快速地书写需求的方式。我们可以看到越来越多的产品工程师使用思维导图来输出他的需求。同样的，测试工程师在思考测试用例的时候，也是基于产品工程师的思路，来设计测试用例的。如果测试用例本身也用思维导图编写，就可以非常容易地跟上产品工程师的设计思路。而且他写出来的测试用例，一定会更全面，因为他需要覆盖产品工程师的每一处分支。有了这样的需求和测试用例之后，又可以在系统中比较好的建立关联。
其次，不仅测试用例是基于思维导图来创建的，也可以直接在思维导图的模式下，来执行它。
这个过程也会非常方便。以往我们执行条目化的测试用例，比如说 Excel ，或者线上的一些其他工具如Jira，测试用例都是条目化的。在执行测试用例的过程中，测试工程师的思路和设计的时候的思路是没有联系的，比如设计测试用例的时候，可能要考虑测试A、B、C3个模块，A需要先测1、再测2、最后测3，但在执行的时候，我们可能是先执行B3、再执行A2。显然测试用例的设计思路，和测试用例的执行思路不匹配，这样必然造成执行时间长，或者执行过程中出现遗漏。这种方式是不利于提高测试效率和准确性的，也不利于执行工程师发现测试用例的设计缺陷。
在MappingSpace里，我们是直接在思维导图的模式下，来执行测试用例的。而且在执行的过程中，还能看到每一条测试用例的前置条件、测试步骤、预期结果。在思维导图页面，我还可以一次选择多条测试用例，然后执行，一次执行N条测试用例，执行效率大大提高。
而且由于需求和测试用例之间建立了追溯性，也可以非常方便地查看覆盖度报告等。
MappingSpace 这款工具还和另一款 API 测试管理工具eolink 做了打通。假如我们使用eolink来做API接口管理和自动化测试，可以直接在MappingSpace中，看到API接口的完成情况，以及API测试报告。
MappingSpace也支持云端和私有化部署，云端版本10人以下的团队永久免费，强烈推荐大家去试用一下。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
