测试用例

我们大致可以把测试用例分称三个方面，分别是功能、UI和业务流程，从这三个角度来进行设计。

1、从功能的角度，功能是每个项目测试的重点，通常在测试人员得到需求文档的时候，我们就开始设计测试用例，那么这个时候需求文档上列出都是功能以及部分一些业务逻辑等，所以在测试用例的第一阶段就是完成功能的用例设计。不过这里，肯定会让很多人疑惑，其实功能、业务还有UI，都是有关联的，而且很多时候无法分解的。这里后面我会举个例子说明哈，但绝非都是可以分类，只是谈谈如何分解的方法，最重要的就是不要遗漏就行。

2、从UI的角度，UI通常是指界面测试，这个应该不难理解，但要想与功能点进行分解，也不是那么容易区分的，所以我们来直观的说明哈。界面测试，注重样式，外观、整洁、摆放以及易用性，还包括用户体验等。

3、从业务的角度，这个相对来说，还比较好理解，业务通常是指一连串的动作所连接起来的流程，这个流程必须有行为和目标，或者说方向。业务通常是一个项目或者产品设计的核心，当下，越来越多的应用业务流程都是非常复杂，所以对于业务的用例设计，就是考验一个测试人员的业务水平如何。

下面通过一个证券交易平台上的买入和撤单业务，进行具体说明：

业务说明：买入业务包括股票代码、当前价格、买入价格，买入股票数量、确定买入按钮和取消按钮；

撤单业务包括选择撤单的未成交业务、撤单成功、撤单失败以及取消撤单按钮；

以上只是大致列举了一部分。

功能点：买入按钮、取消按钮、选择撤单、撤单按钮和取消撤单按钮等

UI界面测试：股票代码、当前价格、买入价格、买入股票数量，所有的文本框；买入成功/失败的提示框；撤单成功/失败的提示框；撤单成功/失败的业务状态等

业务测试：买入业务，从输入买入表单的数据，到提交表单，到最后买入的表单显示的位置，以及买入提交但未成交，可以撤单，完成撤单的业务，到撤单成功或者失败等，这一连串的工作组合就是一个业务流程。

其实这里就存在一个争议性的问题，对于买入和撤单，既可以作为功能点，也可以作为一个业务逻辑来设计，但从本质上来讲，功能点注重单独的操作，而业务流重的在是一个流程，还需要具体业务去甄别。功能点的设计更主要对这个买入和撤单的按钮本身进行用例设计；而业务则是需要从买入和撤单之前的输入到最后输出这样一个过程来设计。

以上也只是大概的一个简单的说明，具体的操作还得根据自己的实际流程来执行，毕竟测试用例的管理是一个长期的积累和沉淀的过程，好的方法都是总结出来的。对于测试来说，用例是基础，对于回归测试、自动化、性能等等都是根本，管理好测试用例，也就是提高测试的工作质量。