笔者的建议是：关注“测试思想”而不是关注操作步骤。
要理解这个问题，首先要弄明白测试用例的作用。
就像用例一样，测试用例并不是用来描述具体的实现的，而是着重描述处理问题的思路——对于一项明确的测试内容进行测试的思路。作为测试用例的设计人员，如何理解基本流和备选流?如何深入分析并找到所有需要覆盖的路径和需要检查的特性?我们在测试用例中应该用容易理解的自然语言清晰的来描述我们将要如何进行测试，而不是简单的把在应用程序上如何操作的烦琐的步骤记录下来。把测试用例设计当成填写具体操作步骤的表格是人们对测试用例最大的误解。
传统的测试用例文档编写有两种方式。
一种是填写操作步骤列表：将在软件上进行的操作步骤一步一步详细的记录下来，包括所有被操作的项目和相应的值。
另一种是填写测试矩阵：将被操作项作为矩阵中的一个字段，而矩阵中的一条条记录，则是这些字段的值。
网络上对于这两种方式孰优孰劣的争论，将大家错误的引导向了两个极端：要么采用A，要么采用B。而大家却忽视了一点，对于工作方法的争论，本质上同工具的争论并不是一回事(例如曾经的VC、BCB之挣)。如果不同的方法各有优势，我们完全可以通过变通的方法，把优势的部分组合在一起来使用。
操作步骤列表的优势在于对基本流和备选流进行分析后，它可以清晰的描述您的测试思路。而测试矩阵则更适合于用来存放测试数据，特别是那些需要人工赋予一个确定的值的特性。
下面，我们来看一个例子，当然，这个例子同样是杜撰的。
需求名称：用户登录安全验证
需求描述：用户登录安全验证是为了保证所有登录到系统中的用户，都是由系统管理员预先在系统中设定的。使用系统中不存在的用户名，或者用户名输入正确，但密码输入错误情况，都无法登录到系统中。当用户使用了不存在的用户名或错误的密码时，系统应分别给出适当的提示。如果用户连续三次无法使用正确的用户名和密码登录到系统，则系统应给出适当的提示，并退出当前程序。如果用户使用正确的用户名和密码登录到系统，则退出界面，转到系统主界面。对于用户登录界面和程序主界面，请参考相应的UI设计文档。
测试需求：
01. 检查能否使用正确的用户名和密码登录到系统;
02. 检查能否使用错误的用户名或密码登录到系统;
03. 检查使用错误的用户名和密码登录失败超过三次，是否会自动退出当前程序。
测试用例：
| 序号 |
操作过程描述 |
| 1 |
输入用户名。 |
| 2 | 输入密码。 |
| 3 | 确认登录。 |
|
序号 |
用户名 |
密码 |
预期结果 |
| 1 | 正确的用户名 | 正确的密码 | 登录到系统并转到系统主界面 |
| 2 | 正确的用户名 | 错误的密码 | 无法登录到系统并提示密码错误 |
| 3 | 错误的用户名 | 正确的密码 | 无法登录到系统并提示用户名错误 |
| 4 | 错误的用户名 | 错误的密码 | 无法登录到系统并退出当前程序 |
| 5 | 空用户名 | …… | …… |
文章来源于领测软件测试网 https://www.ltesting.net/
