组织你的测试
适用级别：初学者
在最底层，一个测试步骤(Test Step)用来验证一个单独的操作。组合若干测试步骤到测试用例，允许你验证那些被分隔出来的一个一个的功能，这些功能是应用程序所需要的。接下来，若干个测试用例可以组成一个测试套件(Test Suite)，验证其中一个交付物的完整功能，这是用户想要的。最后，组合若干测试套件到一个测试工程(Test Project)，就能验证一个完整产品的功能了。
词语工程(Project)和套件(Suite)某些情况下可以互换使用，但是意思都差不多，包含各种范围的多重测试级别。这句话怎么理解？不能理解成传统的测试级别，传统的测试级别为组件测试，集成测试，系统测试，验收测试等。这里要结合上一段的内容，级别指的是测试步骤，测试用例，测试套件，测试工程，这个等级是这么来的，范围就是测试步骤的范围，测试用例的范围，测试套件的范围，测试工程的范围。
小的构建块
从小父母教育我们做事要从小做起，一口气吃不成一个胖子，贪得无厌没啥好下场。所以，API测试最好也从一个单独的测试步骤调用开始，然后再把他们组合进大的用户场景里，好处就是能够帮助你快速准确的定位缺陷。同时也可以让你逐层递进的了解被测程序的细枝末节、功能逻辑。被测即AUT，Application Under Test。
API通常没啥正儿八经的文档，有文档的也缺乏维护，没文档的真就没有。所以你要组织构建的测试用例就应该像堆积木，从非常小的部分开始，然后用你学到的知识在堆积其他大的部分。
当你运行测试用例并找到了一个缺陷后，开发人员通常会想办法快速识别出最小范围的受损部分。所以，如果对于你测试的单一功能的问题描述过长，那就要花费很多时间从里面找出问题乃至蛛丝马迹，不管这个过程是如何被自动化的
另外，合理有效组织你的测试用例到可管理的逻辑块，将会让你的测试用例变的更加灵活，可维护性更强。
你很可能会选择一小片功能进行测试。如果你有一个成百上千的测试用例集(Test Suite)，但是你的应用程序的一个功能仅有一个（严重的）缺陷被修复，你很可能需要快速选取跟开功能或问题相关的测试用例。几乎所有的现代测试框架都允许你创建一组测试用例或一组测试用例集，然后从该创建的组中选择一个或多个测试用例运行。
这个功能片（块）该有多小，依赖于你的被测产品。如果是你个盖房子的人，这个最小的部门可能是门、窗户、墙等等。下一个再大一点东西，你可能考虑盖一个卧室出来，一个厨房或者一个走廊等等。一个测试工程或项目就好比盖一个平房，二层小楼一样，没啥区别。（真的？）
如果你是盖房子的人的供应商，最小的部件可能就是一个门的转轴、手柄、浴室的水池、厨房洗碗的水槽、水龙头等等。再大点部件就可能是外门、内门、厨房柜子等等。一个测试工程或项目也可以类比为完整的厨房或者一个完整的浴室。
冒烟测试
当你决定要关注与新的应用程序，记住冒烟测试永远都是你一开始就要实施的。一套好的、行之有效的冒烟测试用例集将会有很高的投资回报比(ROI)，说白了，这东西运用得到可以节省成本有效发现问题，对比其他类型的测试，长远来讲，冒烟测试会节省你很多不必要的麻烦。
术语，冒烟测试很可能来自于水管工程并通过电子工程传播开来。冒烟测试仅仅是验证已安装部件的基本功能，从而决定是否有任何一个地方可以进行深入验证。在水管管道工程领域，管道工人会往管道里放烟雾，来观察管道是否有泄露或存在裂缝。在电子工程领域，通过给电路板通电，观察是否由于不正确的布线导致设备冒烟。在这两种情况下，如果你观察到冒烟了，就别浪费时间进行后续的测试了，老老实实研究一下哪里出错了吧。
在软件领域，你很可能回答这样的问题：所有模块都部署并运行正确了吗？这里的冒烟测试应该检查是否有任何一个部分没有如期工作，或者干脆就没发布，甚至就没写这部分的代码（忘了还有这个功能？）。当然，我们当前讨论的是API测试，那么对于API测试来说，冒烟测试是指充分调用所有接口并获取每个接口的返回内容，确保这些API部署上去并存在且可调用就ok了。还有一些方法也很重要，它们会从数据库里面获取数据，这些行为会告诉你，对于一个n层设计的系统是否都有正确的部署并且各部分通信正确。
冒烟测试应该在每个单独版本之后运行。一个不错的经验是一整套的冒烟测试集的运行时间不应该超过30分钟，因为没什么人为了或得一个新版本等待那么长时间。另一个不错的准则是，所有冒烟测试集里的测试用例千万不要在内部互相调用，请确保你知道用外部的API，如JDBC调用。如果你是用非侵入式的冒烟测试（不需要修改任何用户数据）用例，那么它们会是很牛x的生产监控工具。
可用性测试（Sanity Test，百度百科说是可用性测试）
可用性测试在冒烟测试的基础上会增加一些更高级别的测试。可用性测试验证冒烟测试过程中返回了合理的东东。例如：多数天气预报没有小数位，但是数据库可能有。世界任何一个地方的天气预报都不应该返回超过两位数的温度（摄氏度）信息。这种情况下，具体的温度值，或者该值是整数还是负数，都不重要了。你要验证的是你的API调用能够正确的理解你输入的东西，并且正确展现给你返回的东西。
CRUD测试（Create，Read，Update，Delete）
一个API通常会都会可视化的方式展现那些存储于某个地方的对象，诚然，多数存储于数据库。每个对象都能被创建并并读取，也经常被修改和删除。
CRUD测试主要是验证对象正确的写入了数据库：创建-读取-修改-删除。在每个操作后，直接去数据库捞数据并对比字段是一个不错的主意。这么做会帮助了解数据在数据库里面的组织形式，接下来的API调用，你也会对它们所期待的返回结果增加信息。
CRUD测试的一个用途是，发现在API服务器与数据库服务器之间是否存在任何缓存问题。如果你的冒烟测试发现分别调用创建接口以及读取接口能够工作，但是连续对同一个对象实例调用创建接口和读取接口不能工作，那很有可能跟缓存问题有关。
CRUD测试还能发现另一个有问题的领域，即并发问题。如果你有5个并行的退款请求，那应该至于一个调用成功。如果多于一个调用成功了，通常是由于错误的锁（或者读写）机制造成的。
负面测试（Negative Tests)
负面测试的目的是破坏应用程序。没错，你没听错，就是要搞破坏，越坏越好。更有针对性的测试是通过执行预先定义好的负面测试用例让应用程序返回错误消息。错误小心应该准确的告诉你哪里出错了:"用户必须先登录"，或者”存款没有总金额“。很明显滴，错误消息必须要跟具体的用户场景保持一致。
对于公共的API来说，错误消息也非常重要，它们能方便开发人员跟你的API做对接和使用。对于内部的API来说，返回一些错误码是很常见的，这些错误码的列表也大多共享于不同的项目组之间（服务器开发人员，界面开发人员以及开发测试工程师们）。
边界测试（Boundary Tests)
边界测试是负面测试的一种特殊形式。如果你的应用程序有个控件仅接受一定范围的值，那么测试这个范围的边界会是一个不错的主意。例如，如果一个控件或字段接受1到10内（包括1和10）的任何整数，你可能会尝试下面的所有输入。
| VALUE | EXPECTED RESULT |
|---|---|
| 0 | Error |
| 1 | Positive |
| 2 | Positive |
| 9 | Positive |
| 10 | Positive |
| 11 | Error |
此外，尽管不是边界测试，尝试一些非常非常的大的值也是个不错的想法。在上面的例子中，你应该试试整形的最大值。边界测试通常作为数据驱动的测试用例被循环的执行，所以你可以很容易的添加新的值。增加更多更大的值，验证缓冲区一出的问题，则是安全性的考虑。
安全测试（Security Tests)
安全测试是负面测试的另一个特殊情况。这些测试包括向被测程序发送经过精心设计的输入数据，试图绕过正常的访问限制，然后诱骗应用程序返回或暴漏那些本不应该展现出来的数据或信息。安全测试是一个非常专业化的领域，与其他测试相比需要更多的时间专研和学习。有些测试工具会捆绑安全测试功能，辅助你通过最常见的攻击手段暴漏被测程序（AUT）的安全问题。不管怎样，有些安全隐患，如零天攻击，没有任何工具能够帮助，除非聘请一个该领域的专家。