下载掌阅APP，畅读海量书库
立即打开
从需求分析开始，人们就开始关注如何去验证这些需求，也就是说，当产品开发出来之后，这些用户需求都能得到验证。客户的基本需求，例如，用户登录到电子商务网站查询自己想买的商品，这容易得到验证。但是，如果将用户需求拓展开，事情就没这么简单了。例如，用户可以按多种方式登录，包括用户ID、邮件地址、手机号码等；还要让用户确定是否记住登录名、是否记住口令、是否自动登录，等等。一个用户登录就有很多的情形，用户登录后，查询商品的功能就更复杂了。这时，如果用文本方式、表格方式来表示这些需求，就很难表示清楚，更不用说，要一条不漏地列出所有的需求。这时，人们想到了一个工具——流程图。
目前流程图已被广泛使用。用在数据分析上，就有了数据流程图；用在工艺上，就有了工艺流程图。早期，人们编写程序时，通常先设计程序流程图，让编程思路一目了然，然后再写代码，这样就不容易出错。那时几乎没有测试的概念，更没有专业的测试工程师，程序员自己搞定一切，尽量一次将程序写对，这样后期进行程序调试就不会花太多时间了。
图4-3就是一个很简单的示例，先根据要实现的程序，画出右边那样的程序流程图，然后基于这个流程图，写出左边的代码，这样的确可避免出错。任何考虑不清楚的地方，很容易发现。程序流程图是非常微观的，对在代码层次上进行单元测试有很大帮助。同样在代码层次，许多工具可以自动完成测试覆盖率的衡量，被测试程序中的任何代码、任何分支没有被覆盖，直接可以从测试报告中发现。但是，在功能需求层次上，某个特定用户需求的错误实现、甚至根本没有被实现，这些问题是无法直接从代码层次上发现的，需要在业务层逻辑上发现。这就要由业务流程图来实现。
图4-3 程序源码与流程图
因此设计功能测试用例，要从业务流程图着手，把业务需求转化成流程图。在转化过程中，不仅逐渐加深了对产品特性的理解，而且也在审视每一个产品功能是否合理、是否是用户真正想要的功能。基于业务流程图，业务逻辑清晰，各项功能操作的来龙去脉也一目了然，这样就比较容易很顺畅地完成测试用例的设计。
我们先从一个非常简单的“用户登录”功能开始，看看如何用业务流程图来描述它，然后再将其转化为测试用例。业务流程图从单击“登录”按钮开始，进入如图4-4所示的界面，然后输入账号或邮件地址、密码、验证码等。就是这样一个简单的登录功能，其业务流程图就并不简单，占了整整一页纸，如图4-5所示。
图4-4 用户登录界面示例
图4-5 用户登录的流程图
根据上述的流程图来设计测试用例，需要覆盖每个分支和条件，以保证测试的覆盖率。首先分为“不能自动登录”和“自动登录”两类；其次，对于“不能自动登录”的测试，要考虑分别输入账号和邮件地址。而且要考虑不同输入项的错误，包括账号、邮件地址、口令、验证码等。这样，就可以设计出下列16个测试用例：
1） 输入错误的账号，其他各项正确。
2） 输入错误的邮件地址，其他各项正确。
3） 输入正确的账号，输入错误的口令，验证码正确。
4） 输入正确的账号和口令，输入错误的验证码。
5） 输入正确的邮件地址，输入错误的口令，验证码正确。
6） 输入正确的邮件地址和口令，输入错误的验证码。
7） 输入正确的账号、口令和验证码。
8） 输入正确的邮件地址、口令和验证码。
9） 输入正确的账号、口令和验证码，点击“看不清，换一张”。
10）输入正确的账号、口令和验证码，标记“下次自动登录”。
11）输入正确的账号、口令和验证码，去掉“输入正确的账号、口令和验证码”标记。
12）输入正确的邮件地址、口令和验证码，标记“下次自动登录”。
13）输入正确的账号，输入错误的口令，验证码正确，点击“登录”按钮，重复进行3次以上。
14）输入错误的账号，输入正确的口令和验证码，点击“登录”按钮，重复进行3次以上。
15）输入邮件地址，点击“忘记口令”，按提示进行操作。
16）什么都不输，点击“忘记口令”，按提示进行操作。
当业务功能比较复杂时，就需要逐层分解，如图4-6所示。也就是说先从功能的基本关系着手，然后对它的子功能或某个操作进行分解、细化，直到不能分解为止。
图4-6 业务流程图逐层细化示意图
对于多用户操作，需要分清不同的操作对象，这时，可以将流程图的形式做些改变，类似于UML的序列图，以一个对象为基准，以操作的时间顺序展开，从而使操作人之间的关系清晰，业务逻辑也不会乱，如图4-7所示。
图4-7 多用户流程示意图
画流程图的注意事项如下：
●画流程图之前，一定要和产品设计人员、开发人员讨论，真正理解功能特性，弄清楚谁是该功能的用户、用户又如何使用被测试的功能。
●业务流程图的绘制，不仅是为测试用例设计服务，而且还可以尽早地发现产品本身的设计问题。
●流程图由粗到细、由外到内，可以将功能框架先画出来，然后逐层分解，细化下去，深入到单个功能、单个数据流等。
●流程图要结构清晰、描述准确，能显示所有可能的业务操作路径而不漏掉任何操作的路径。如果善于分析，在设计测试用例时还可以进一步优化路径组合。
●用户事件有时会处于某个中间状态，即一个动作完成而下一个动作还没有开始，在这个状态下，接下来的事情将有很多可能性，在画流程图时要特别注意。
●当开发人员进行系统设计时，测试人员可以同步地设计业务流程图并进行测试用例的设计。开发人员和测试人员相辅相成，互相促进，使他们的产品质量能大大提高。
●也不需要对每一个功能都画出流程图，这样工作量太大。可以针对关键的业务功能或复杂功能要求绘制流程图。由于后端稳定性更为重要，测试更要充分，所以后端的逻辑流程图需要认真对待。
如果用UML活动图代替业务流程图，也是同样的道理，方法也基本属于同一种，在此就不赘述了。