大家好，我是十一，引用三毛的一句话作为我们2023年的开场白：

一个人至少拥有一个梦想，有一个理由去坚强。

如果你已经坚强的走在了梦想的道路上，那么我们为自己鼓鼓掌，希望未来的道路上大家能够同行共勉！如果你还在迷茫，我希望我的知识能够帮助你！

好了，言归正传！年末最后一篇我们看了测试方案实例（戳此回看《​​测试方案之实战篇》​​​），那么这篇我们接着上篇的方案来写测试用例。

在《软件测试的工作周期》中对软件测试用例设计做如下描述

测试用例设计：

描述：主要是对测试用例和规程的设计。测试用例是根据《测试方案》和《需求说明书》来编写的，通过《测试方案》阶段，测试人员对整个系统需求有了详细的理解。这时开始编写用例才能保证用例的可执行和对需求的覆盖。测试用例需要包括测试项，用例级别，预置条件，操作步骤和预期结果。其中操作步骤和预期结果需要编写详细和明确。测试用例应该覆盖测试方案，而测试方案又覆盖了测试需求点，这样才能保证客户需求不遗漏。同样，测试用例也需要组内评审。

输出：测试用例集。一般在工具上完成（Testlink、excel等等）

概念：

测试用例是指进行测试时使用的特定输入，以及测试步骤。

重要性：

这里我们引用Ron Patton先生在《软件测试》中的一段话：

选择测试用例是软件测试员最重要的一项任务，不正确的选择可能导致测试量过大或者过小，甚至测试目标不对。准确评估风险，把无穷尽的可能性减少到可以控制的范围是软件测试成功的诀窍。

工具：

常用的工具如testlink、excel、禅道、Bugzilla、Testcenter等，每个公司根据自己的实际情况选择。

那下面根据《测试方案之实战篇》中的需求和测试方案我们来做测试用例设计吧~文章中我们只能用表格来代替工具了，在后面我们会对testlink做简单介绍，供大家参考（内容都大同小异，所以不一一介绍）。

今天我们专写密码登录模块的测试用例，大家往下看之前不妨自己想想，如果由你来测试某宝登录，你怎么测试？思考完后再往下看，看看你漏掉了哪些？

图片来源于：百度图片

还是先来说明表格头中各项定义吧：

1. 测试编号：就是测试用例的编号么，没啥好讲的
2. 测试项：测试的功能点说明
3. 前置条件：该测试用例的前提条件，比如测试cc／cc（用户名／密码）账户是否能正确登录进去，那前提cc／cc已定是注册过的
4. 测试步骤：就是测试的所有操作步骤，最好是每一个步骤应该对应一个期望结果，最少也得一个测试用例对应一个期望结果
5. 期望结果：就是希望得到的结果（正确的结果）
6. 测试结果：实际测试的结果，可选项有：通过、不通过、暂时挂起／锁定（就是暂时不测试）；
7. 对应的bug：当期望结果与实际结果不符时测试不通过，此时需要上报bug（纪录缺陷），bug需要与测试用例对应
8. 测试执行人：实际由谁来执行测试用例；也有任务分配人的选项，就是测试用例分配给哪个测试员来测试
9. 备注：做一些备注或者测试的说明

再来说明下测试项中的定义：

1. 合法用户：就是已经注册过的用户
2. 非法用户：没有注册过；注册过但是用户名／密码不匹配的；本文特指未注册过的用户

再次强调，我们本次测试对象是：密码登录，如下图

接下来为大家呈现密码登录部分的测试用例：

我们来总结下，登录需要测试的基础场景：

• 合法用户登录
• 非法用户登录
• 用户名/密码为空
• 用户名/密码带前后空格登录
• 浏览器兼容性测试
• 界面原型测试

上述测试用例基本涵盖了密码登录中的主要测试场景。你想到这些了嘛？如果你能想到这些，那你作为初级软件测试工程师就勉强合格了哦。具体为什么只能算勉强合格，那期待下篇吧～不过，我更希望你们自己能脑补脑补，脑补不行就拿纸笔比划比划，总之，一定要先自己思考！！！

图片来源：百度图片

好了，今天的内容到此结束！如有任何问题后台留言及时与我沟通，我会尽快回复大家！谢谢大家~我们下次再见！