在敏捷环境中用wiki高效地组织测试用例

在此我想介绍一种在wiki中组织测试用例（Testcase）的方式，遵照以下几点可以清晰地列举测试点，较立体地体现覆盖面，便于发现覆盖漏洞。在规模较小的敏捷团队中，wiki页面适合用来组织需求变化频繁的功能测试用例，避免设计改变导致的频繁更新。随着需求和功能趋于稳定，就可以把用例转移到更利于跟踪和管理工具中，例如基于Jira的Zephyr、TestLink等。

用表格来组织case是常用做法，能否高效地利用页面空间展现case内容会直接影响日后进行测试时效率——设想表格宽度由于存在很多列而超出浏览器显示宽度，那么执行时总要来回拖拽会很闹心的。所以，设计列是一门学问。做过测试的都知道，测试用例通常包括以下内容：序号，标题，测试点描述，预设条件和测试数据，测试步骤以及预期结果6大元素。经过很多的操练，我发现标题和描述是可以合并在一起的，只要能清楚写明用例的测试点即可，这样可以少一列，列就叫测试点（Test Point）。预设条件和测试数据(Preconditions/Test Data)可以写在一起，因为他们都是执行之前需要准备好的。另外我习惯把每一步的预期结果(Expectation)用步骤编号标明。

在此我想特别强调序号，为什么呢？因为它是用来有效组织的索引，也是可以在别的case中引用的对象。首先，如果你体会过添加新用例会导致序号需要重排这种痛，不妨把用例分类，每个大类用序列号1,2,3……标识，然后在每个大类下添加case，用x.1,x.2……标识。这样再加新用例不会影响其他类别下的case序号。其次，预设条件经常是前面的某个case执行结果，与其把前面的case抄一遍，不如直接把case序号写在预设条件里，简洁明了，如下用例1.2所示。

示例#测试点预设条件/测试数据测试步骤预期结果1UI测试这一整行应该合并，可惜这编辑器太简陋这一整行应该合并，可惜这编辑器太简陋这一整行应该合并，可惜这编辑器太简陋1.1主屏界面布局 1
2
31
2
31.2主屏界面内容1.11
21
22Action测试   2.1开始按钮   3其他测试   3.1……   

分类组织用例的好处不止方便重排序号，而且利于检查覆盖面。拿安卓应用的测试为例，通常需要测试UI布局，内容正确性，业务流程正确性和合理性，安装升级，流畅度等主要方面，缺失任何一项很容易发现。另外更重要的是，确定了分类也就确定了每一类用例的测试点覆盖角度。什么意思呢？我们经常发现某个功能测试用例写了不少，但是到处是重复和交叉，导致用例冗长，不易读，一会儿测内容，一会儿测色彩，一会儿又可能跑去别的功能，功能用例里考量性能，性能用例里考量后向兼容性——这就是测试角度不确定的结果。多角度地思考问题是好事，但落实到用例上则需要非常明确而统一。

高效的下一步是简化语句。这可是简约而不简单的功夫，比如我们总把预期结果写作Expected Result，而我建议用Expectation，因为少一个词);再比如有人在标题中总写上“测试什么什么”，在我看“测试”那俩字不写也罢，谁不知道你是要测试呢？每个用例都多俩字，总共要浪费多少空间和测试阅读时间呢？还有重要的一点是：wiki的排版不如word等出版工具灵活，空间容易有损耗，这就更要求我们语言精炼，少写废话。一些通用约定俗成的条件或步骤大可写在最前面，在每个用例的格子里引用。

如果需要迁移到用例管理工具了，那么可以这么办：产品模块名+序号+测试点作为标题，其他列对应工具的列，导入即可，测试数据通常是添加附件链接，需要单独处理。

综上所述，精炼设计表格列，把握思维角度，分类管理用例，文词准确简洁——构成了高效组织测试用例的要素。