组织你的测试

适用级别：初学者

在最底层，一个测试步骤(Test Step)用来验证一个单独的操作。组合若干测试步骤到测试用例，允许你验证那些被分隔出来的一个一个的功能，这些功能是应用程序所需要的。接下来，若干个测试用例可以组成一个测试套件(Test Suite)，验证其中一个交付物的完整功能，这是用户想要的。最后，组合若干测试套件到一个测试工程(Test
Project)，就能验证一个完整产品的功能了。

词语工程(Project)和套件(Suite)某些情况下可以互换使用，但是意思都差不多，包含各种范围的多重测试级别。这句话怎么理解？不能理解成传统的测试级别，传统的测试级别为组件测试，集成测试，系统测试，验收测试等。这里要结合上一段的内容，级别指的是测试步骤，测试用例，测试套件，测试工程，这个等级是这么来的，范围就是测试步骤的范围，测试用例的范围，测试套件的范围，测试工程的范围。

小的构建块

从小父母教育我们做事要从小做起，一口气吃不成一个胖子，贪得无厌没啥好下场。所以，API测试最好也从一个单独的测试步骤调用开始，然后再把他们组合进大的用户场景里，好处就是能够帮助你快速准确的定位缺陷。同时也可以让你逐层递进的了解被测程序的细枝末节、功能逻辑。被测即AUT，Application Under Test。

API通常没啥正儿八经的文档，有文档的也缺乏维护，没文档的真就没有。所以你要组织构建的测试用例就应该像堆积木，从非常小的部分开始，然后用你学到的知识在堆积其他大的部分。

当你运行测试用例并找到了一个缺陷后，开发人员通常会想办法快速识别出最小范围的受损部分。所以，如果对于你测试的单一功能的问题描述过长，那就要花费很多时间从里面找出问题乃至蛛丝马迹，不管这个过程是如何被自动化的

另外，合理有效组织你的测试用例到可管理的逻辑块，将会让你的测试用例变的更加灵活，可维护性更强。

你很可能会选择一小片功能进行测试。如果你有一个成百上千的测试用例集(Test Suite)，但是你的应用程序的一个功能仅有一个（严重的）缺陷被修复，你很可能需要快速选取跟开功能或问题相关的测试用例。几乎所有的现代测试框架都允许你创建一组测试用例或一组测试用例集，然后从该创建的组中选择一个或多个测试用例运行。

这个功能片（块）该有多小，依赖于你的被测产品。如果是你个盖房子的人，这个最小的部门可能是门、窗户、墙等等。下一个再大一点东西，你可能考虑盖一个卧室出来，一个厨房或者一个走廊等等。一个测试工程或项目就好比盖一个平房，二层小楼一样，没啥区别。（真的？）

如果你是盖房子的人的供应商，最小的部件可能就是一个门的转轴、手柄、浴室的水池、厨房洗碗的水槽、水龙头等等。再大点部件就可能是外门、内门、厨房柜子等等。一个测试工程或项目也可以类比为完整的厨房或者一个完整的浴室。

（未完待续。。。）