一、什么叫软件测试用例？
1.测试用例(Test Case)：是为项目需求而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序是否满足用户的需求。
可以总结为：每一个测试点的数据设计和步骤设计。
二、测试用例的重要性
1.测试用例是软件测试的核心：软件测试的重要性是毋需质疑的，测试用例是测试工作的指导，是软件测试质量稳定的根本保障。影响软件测试的因素很多，如软件本身的复杂程度、开发质量，测试方法和技术的运用。但有些因素是客观存在，不可避免的，如IT团队的流动、环境、情绪等。
2.评估测试结果的基准:测试用例的通过率以及错误率是测试结束的一个重要依据，用来判断该软件测试结果是否通过，能否达到上线的标准。（测试结束的基准：测试错误通过率达到98%以上）
3.保证测试的时候不遗漏测试功能点，可以在测试人员疲劳的时候起到一个牵引的作用。
4.在编写测试用例的过程中，可以熟悉需求，对系统架构或者业务流程有一个整体的、深入的了解。
5.好的测试用例不仅方便自己和别人查看，而且能帮助设计的时候考虑得更周全，因此测试用例的写作和设计一样，也是非常重要的。（执行性、指导性）
三、测试用例的八要素
1.用例编写：产品名-测试阶段（st it ut）-测试项-xxx
序号 缩写 全称 中文 测试对象
1 UT Unit testing 单元测试 模块内
2 IT Integration testing 集成测试 接口
3 ST System testing 系统测试 功能、业务
4 UAT User acceptance testing 验收测试 交付使用
2.测试项目：对应一个功能模块（细化功能）
3.测试标题：直接对测试点进行细化得出，输入内容+结果，同一功能模块标题不能重复（来自测试点）
4.重要级别：高/中/低
5.预置条件：需要满足一些前提条件，否则用例无法执行。
6.测试输入：需要加工的输入信息，根据具体情况来设计（跟步骤结合起来，一定要具有指导性意义）。
7.操作步骤：明确给出每一个步骤的描述，执行人员可以根据该步骤完成执行工作。
8.预期结果：根据预期输出对比实际结果，来判断被测对象是否符合需求。（预期结果应唯一，不能出现“是否、或者”）
四、案例小练习
写关于微信红包其中的某一条用例。
用例编号：WX_ST_HB_01(编号通常根据功能模块编写)
测试项目：微信红包
测试标题：输入正确红包金额0.01-200，红包是否发送成功
重要级别：高
预置条件：无
测试输入：0.01、200
操作步骤：
1.登录微信>点开好友聊天界面
2.点开“+”，选择红包功能
3.输入金额
4.默认红包备注
5.点击发送红包
6.选择零钱
7.输入密码
预期结果：
1.发送成功、界面显示红包
2.零钱余额对应减少相对应金额
用例编号 测试项目 测试子项目 测试标题 重要级别 预置条件 测试输入 测试步骤 预期结果
WX_ST_HB_01 微信红包 输入金额 输入正确红包金额0.01~200,红包是否发送成功 验证红包正确金额0.01~200 高 1.网络正常；2.账号正常登录；3.当前微信余额充足； 1、0.012、200 1.登录微信>点开好友聊天界面；2.点开“+”，选择红包功能；3.输入金额；4.默认红包备注；5.点击发红包；6.选择零钱；7.输入密码； 1.发送成功，界面显示红包2.零钱余额对应减少相对应金额
五、如何编写测试用例
1.对测试需求进行分析，依照不同的功能模块列出测试点；
2.选择等价类、边界值、错误推测法等测试用例设计方法，细化测试点分解为不同的测试标题，并补充对应的测试步骤及测试数据、预期结果；
3.测试用例覆盖所有的用户需求，包括单个功能及业务功能的覆盖，正面和反面用例的覆盖；
4.编写时注意测试用例编写格式要求，元素包含测试编号、测试标题、预置条件…，测试不存在冗余、重复、二义性等。
六、关于写测试用例的一些建议
1.功能划分时，一个测试用例集就只需要检查一个功能模块，否则，用例会混乱，降低可读性。
2.测试用例的划分也要单一，一个测试用例只检查功能点的一种情况。否则，会导致用例的目的不清晰，且这样不利于需求覆盖率的统计。一个功能点，我们测试了哪些情况，以及哪些功能点我们在重点测试，一目了然。
3.测试用例要有一个简单的目的描述，有助于读者对测试用例的理解。
4.测试用例要有明确的执行前提，包括环境、数据、场景。
5.测试用例的步骤描述要简单、清晰，一步就是一步。比如，第一步：用户登录；第二步：用户点击“用户信息”；第三步：用户修改姓名为‘christal’;第四步：用户点击保存，这有利于提高用例的可操作性。
6.测试用例的数据要明确，特别是前提数据和要检查的数据。比如，测试准备数据：（用户：christal、jennifer、daisy）,在排序后用例的预期结果为：（用户：jennifer、daisy、christal）。这样，用例在执行时，很清晰、有很高的可操作性，执行者对于执行结果是否正确也非常清楚。
七、用例评审的重要性
无论是初级测试工程师，还是高级测试工程师或者专家级的测试工程师，设计出来的测试用例都需要经过评审。
² 测试用例一般分配给每个人来设计，设计用例的人并不知道用例在具体执行的时候是否有问题，不能保证自己设计的用例能完全覆盖。
² 保证测试人员和开发人员对于被测功能理解的一致性。
² 需求人员参与评审，他们能帮助你找出更多的问题。测试的时候，有些细节是无法从需求文档上得知，需要频繁来和需求人员沟通。
² 有很多项目承交给项目外包或人员外包，那么完成每一项工作的第一件事就是提交客户评审，当然在提交给客户前内部团队应先评审，确保提交给客户高质量的成果。
² 按照用例数量来评估工作量，防止用例不完整，工时给少了。
八、用例评审的方式
以会议评审为主，一般在用例初步设计完成之后，先进行测试组内部的评审，测试组内部评审通过后，再进行项目组的评审。
如果是测试组内部的评审，应该着重于：
1.测试用例本身的描述是否清晰，是否存在二义性；
2.是否考虑到测试用例的执行效率，测试用例中步骤不断重复执行，验证点却不同，而且测试设计的冗余性，都造成了效率的低下；
3.是否针对需求跟踪矩阵，覆盖了所有的软件需求；
4.是否完全遵守了软件需求的规定，即使再严格的审核也会出现错误，应具体情况具体对待。
如果是项目组内部的评审，需要评审委员会来参与，角度不同，评审的标准也不同，比如：
1.收集客户需求的人员注重业务逻辑是否正确；
2.分析软件需求规格的人员注重测试用例是否跟规格要求一致；
3.开发负责人注重测试用例对程序的要求是否合理。
九、用例评审的流程
1.准备好评审材料（主要是测试用例、检查清单）；
2.提前2天发布评审通知（OA通知、邮件或者讨论组发布信息），同时将评审材料发送给评审组成员，以节约沟通成本；
主要的参与评审人员：项目经理、测试负责人、测试人员、产品经理、开发人员；
3.召开会议评审：针对评审用例检查清单，评审过程中收集相关人员的信息反馈（即问题记录清单），并在此基础上进行测试用例更新，直到评审通过；
4.结束评审后，测试负责人将测试用例评审报告给到相关人员，评审结果经项目经理同意确认。
十、附录：用例评审检查清单
1.测试用例是否按照公司定义的模板进行编写的（包括正确的名称和编号，是否标注有执行的优先级）；
2.测试用例的本身描述是否清晰，是否存在二义性；
3.测试用例内容是否正确，是否与需求目标相一致；
4.测试用例的期望结果是否正确、唯一；
5.操作步骤应是否与描述相一致；
6.测试用例包含相关的配置信息：测试环境、数据、前置测试用例，用户授权等；
7.测试用例是否覆盖了所有的需求；
8.测试设计是否存在冗余性；
9.测试用例是否具有可执行性；
10.是否从用户层面来设计用户使用场景和业务流程的测试用例；
11.场景测试用例是否覆盖最复杂的业务流程；、
12.用例设计是否包含了正面、反面的用例；
13.对于由系统自动生成的输出项是否注明了生成规则；
14.测试用例应包含对中间和后台数据的检查。
十一、测试用例的变更
由于需求变更，对于业务的不断深入了解和测试用例评审，测试用例是无法一次全部写好的，所以，测试用例在完成之后是需要不断修正的。
测试用例变更，通常包括：
1.删除一些以前版本的测试用例；
2.增加新的测试用例；
3.更新测试用例；
4.删除冗余的测试用例。
十二、笔试面试题整理
1.用例需要评审吗？紧急情况用例也需要评审吗？
2.如果被测项目很紧急，来不及写用例，怎么办？
3.遇到隐性需求如何写用例？（需求不明确）
4.用例有没有优先级？如果一定要有优先级，依据什么来测试？
5.如何编写测试用例？（以项目为基础来讲一个小模块的测试用例）
个人微信号：Cc2015123