测试用例附实例
一、测试用例的概念测试用例是测试过程中很重要的一类文档，它是测试工作的核心，是一组在测试时输入和输出的标准，是软件需求的具体对照。
二、测试用例的作用检验软件是否满足客户需求测试人员的工作量的一种体现展示测试用例的设计思路三、测试用例的内容测试用例八个基本项是：测试用例编号、测试项目、测试标题、重要级别、预置条件、输入、操作步骤、预期输出
（不同公司的测试用例内容不尽相同）下面是更为详尽的测试用例内容
用例编码，用例名称/标题，测试背景，前置条件，优先级，重要级，测试数据，测试步骤，预期结果，实际结果，测试人员，测试时间，备注
四、测试用例的编写流程需求分析-->提取测试点-->测试用例设计-->测试用例评审
五、测试用例的常用方法方法备注例子等价类划分法在每个等价类中选取一定数目的值作为代表。等价类分为有效等价类和无效等价类，输入符合条件的值对功能进行检验，输入无效等价类的值可以帮助找出程序错误的地方
在注册时，密码规定为6--18位英文字母或数字及下划线，那么小于6位或大于18位的一串字符就是一个等价类，在6-18位的包含处英文字母和数字及下划线之外的字符是另外一种等价类
边界值分析法边界值分析法是对输入输出的边界值进行测试一种的黑盒测试方法，是对等价类分析法的补充在注册时，密码规定为6-18位，则5,19都是边界值 场景法通过运用场景来对系统的功能点或业务流程的描述，从而提升测试效果。场景法一般分为基本流（又称正确流，模拟用户正确的操作流程）和备用流（又称错误流：模拟用户错误的操作流程）1、根据需求，找到基本流和备选流（找出正确的操作流程和可能出错的环节） （1）基本流—正确取款 ①插入银行卡：客户将银行卡插入ATM机的读卡器 ②验证银行卡：ATM机从银行卡的词条中读取账号代码，并检查它是否属于可以接收的银行卡 ③输入密码：ATM机要求输入密码 ④验证密码：验证该密码是否正确 ⑤进入ATM机主界面：ATM显示在本机中可用的各种选项 ⑥取款并选择金额：客户选择“取款”，并选择取款金额 ⑦ATM机验证：ATM机进行验证账户余额是否满足以及总取款金额是否满足要求，验证ATM机内现金是否够用 ⑧更新账户余额、出钞：验证成功，更新账户余额，输出现金，提示用户收取现金 ⑨返回主界面 （2）备选流—出错环节 ①银行卡错误 ②密码错误 ③密码3次错误 ④卡内余额不足 ⑤超出当日可取 ⑥ATM余额不足此外还有因果图法、错误推测法、判定表驱动法等，这里暂时不一一介绍，后续我会专门整理一篇博文介绍
六、测试用例的设计方法和编写6.1测试用例设计对各个功能模块进行测试点分析提取测试点在对测试点用例进行详细的编写
6.2例子：以PC端QQ登录为例正常登录账号为空时点击登录密码为空时点击登录账号和密码为空时点击登录账号错误时点击登录密码错误时点击登录记住密码功能是否有效自动登录功能是否有效找回密码功能是否有效注册账号功能是否有效七、测试用例评审用例评审主要是产品、开发和测试人员针对测试用例能否用于项目的测试而做的工作。
评审包括同行评审，小组评审，部门评审和第三方评审
八、评审的意义通过评审发现用例的不足方便测试人员改进用例达到在测试时提高测试质量的目的九、实例CSDNWeb端的登录界面截图（部分）
可参考原文 https://blog.csdn.net/sdr_zd/article/details/70453027
更多项目实战测试用例和缺陷报告的编写可以看一下我的这篇 测试用例和缺陷报告（项目实战案例）
注意：
测试用例的编号有一定的规则，比如系统测试用例的编号这样定义规则：ProjectName-ST-001，其命名规则为“项目名称-测试阶段类型-编号”。合理定义测试用例编号，可以更方便地查找测试用例。便于测试用例跟踪。
测试用例，怎么写
做测试好几年了，测试用例这块核心的知识从来没有好好总结过，拿到需求就分析，分析结束就着手，感觉是一种手到擒来的东西，也没有真正总结经验下来
书读了无数，没有吸取养分等于没读
事做了无数，没有总结等于劳力
写测试用例前，我们需要提炼出功能点，那什么是功能点。功能点就是一个功能包含的所有功能，比如登录功能
图片发自简书App功能点可以分为：
账号输入手机号
账号输入邮箱
输入密码，长度格式为xxx
输入验证码
点击登录跳转进入首页
根据列出来的细分功能点进行用例编写，编写用例就通过拆分各个细分功能点的细节进行。用上测试用例分析方法：划分有效类、确定边界值、使用因果图、判定表、错误推测等等，这些都是用来确定测试数据的
编写用例需要有一个表格，有个通用的模版
图片发自简书App每个用例都需要有一个唯一的编号；一个通俗易懂，一读就明白该条用例的目的的标题；预置条件用来存放一些已知的测试步骤；测试数据，就是我们分析出来的进行测试的数据；测试步骤，引导测试的步骤；预期结果，判断用例的执行结果，用来与实际结果相比较
1.其中标题的编写需要通俗易懂，没有歧异，表明目的。具体怎么写可以引用《测试架构师修炼之道：从测试工程师到测试架构师》的说法就是
图片发自简书App比如上面的登录功能中：账号输入手机号
标题可以写成：登录账号输入11位有效的手机号校验账号的正确性
2.在测试用例中的“测试数据”单独列出来的目的是，我们在写边界值呀、等价类取值的时候，可以直接写在测试数据里，不用相同的用例写N遍，也是为了阅读、执行者方便阅读、操作
3.测试步骤中，不需要写得太具体，以防界面有修改的时候，修改用例改到气馁。而且步骤不可以太多，写的人烦躁，读的人也腻歪，解决办法就是把其他用例验证的步骤置于预置条件中，如：用户已登录
4.预期结果，大部分人写的测试用例中，每步测试步骤对应一个预期结果，但是如果出现没有预期结果的步骤怎么办呢？一种解决办法是，把有预期结果的步骤写在同一步骤中，这样有可能一个步骤其实是操作了两步或者三步；另一种解决办法是测试步骤中用【check1】or【check2】标注，然后在预期结果中直接写【check1】是什么，【check2】是什么
输出测试用例文档不算难，但是如何获取不同的测试数据，如何操作可能出现bug这都是需要经验积累的。测试用例是一种结果，需要不同的测试方法支撑这个结果的输出，所以才会有一种测试方法叫：错误推测法-在测试程序时，人们可以根据经验或直觉推测程序中可能存在的各种错误，从而有针对性地编写检查这些错误的测试用例的方法（来自百度百科）。