前面有曰：
测试结果的准确性取决于
测试用例的设计，故测试
用例设计显得尤为重要。今天就好好梳理下，测试用例的相关内容.
重要性：Test Case贯穿整个测试执行过程，分两大类：数值计算类和数据处理类
概述：编写一组前提条件，输入，执行条件，预期结果的组合方案。完成对某个特定需求或目标的测试，体现测试方案，方法，技术和策略的文档。
1、什么是测试用例，为什么要编写？
测试用例就是编写一组条件，输入，执行条件，预期结果的并完成对特定需求或目标的测试，体现测试方案，方法，技术和策略的文档。
由于测试用例是把整个测试的执行过程分解为若干测试步骤，并仔细的检查，验证所编写程序的正确性。它是软件测试的核心部件，是测试环节执行的基本依据。
2、主要包含哪些内容？需要哪些资料？
通常如下内容：
测试用例的编号
测试日期
测试设计人员和测试人员
测试用例的优先级
测试标题
测试目标的描述（描述它需要实现的功能，包括性能等）
测试环境的描述（eg：硬件条件，软件条件，网络条件等）
输入数据/动作的编写（具体的执行过程）
测试的步骤（测试数据具体的执行过程）
测试的预期结果
测试审查人员
资料：
软件需求说明书
软件设计说明书
软件测试需求说明书
成熟的测试用例（案例库或财富库）
3、有什么作用？
投入小，易积累，回报大。如何在最短时间内以最少的人和资源投入发现软件自身的缺陷，完成高效率测试并交出优质产品，是每个软件公司探求的目标。因此每个项目都需要有一套完整，高效，优质的测试方案和测试方法，如果有了测试用例和测试用例库则可以预防部分或减少潜在风险的发生，另外，若公司事先要求编写测试用例和建立相关测试用例库，测试人员发生流动时，对测试和项目进度的影响就会降到最低程度。
（1）实施测试指导的作用
在实施测试时一定要严格按照测试用例规定的用例项目和测试步骤逐一测试，并把测试中的各种情况记录下来（最好用测试管理软件）。以便书写测试结果文档（建议用测试管理软件自动生成）
注意：测试用例是指导测试人员进行测试，通过用例发现更多的缺陷，而不是限定测试人员的思维。
（2）指导测试数据规划的作用
测试用例数据一般都保存在数据库中，只有进行测试用例设计时才从数据库中调出一组或若干组测试用例的数据和标准测试结果。eg：报表等一些对数据的正确性要求较高的测试，要事先对测试的数据进行规划，报表横向，纵向多少内容。表输出的格式要求等，进行规划设计要做到事先有准备，测试操作时有案可查。除了这些标准数据，有时候还需要根据测试用例设计大量边界值&越界值。
（3）指导脚本编写的作用
软件测试逐步走向人工测试和自动化测试并行发展。而自动化测试的核心就是测试脚本，自动化测试脚本编写的依据就是测试用例。
（4）作为评判基准的作用
测试工作完成后需要评估并进行定论，判断软件是否合格，然后出报告。以测试用例为依据进行评审。总结如下：
测试中检测到Bug数目
有效的Bug数目
无效的Bug数目
有争议的Bug数目等
（5）作为分析缺陷的基准的作用
测试目的就是发现Bug，测试结束后对得到的Bug进行复查，并对测试用例不断的补充，完善，最终交付给用户一个高质量的软件产品。
4、测试用例的设计流程，白盒测试用例的设计和目的？
一般流程包括：制定测试计划，编写测试用例，执行测试，跟踪测试缺陷，编写测试报告。
需注意：用例应该从系统最高级向最低级逐一展开，每个用例单独放在文档中，所有功能都应该对应到用例中，需依据需求进行设计。最好是有丰富经验的测试人员来设计。用例是多样化，复杂中简单化。
白盒测试设计方法：
逻辑覆盖：①判定覆盖②条件覆盖③判定/条件覆盖和多条件覆盖，逻辑值必须测试真，假两个分支，需要在边界值内和可操作范围内至少循环一次，并检查数据的内部结构，保证其有效的实现预定功能。
基本路径测试每个模块中的独立路径至少被执行一次
5、黑盒测试用例的设计和目的？
设计-等价类划分，边界值分析，错误推测，因果图
目的-检查功能是否实现或遗漏，交互界面是否出错，数据库读取，更新操作是否出错，性能和特性是否得到满足。
6、综合设计方法
实际操作设计测试用例一般“先黑后白”，即先采用黑盒技术设计测试用例，再用白盒技术做一些补充。
步骤：如果规格说明书中包含输入条件，则用因果图法设计；如果源码中遇到输入输出边界，则用边界值分析法；同时为输入和输出识别有效和无效等价类；使用错误推测法增加测试用例。
5点原则和注意项：
①测试用例的正确性
②测试用例的代表性
③测试结果的可判定性和可重现性
④足够详细，准确，清晰的步骤
⑤不能把测用例设计等同测试输入数据的设计
①务追求测试用例设计一步到位。
②勿将多个测试用例混在一个。
③用例中，最好不是无经验的人员设计测试用例。
7、测试用例设计需关注7大要点
（1）单元测试用例需注意
在一组单元模块设计完成后就开始的测试，单元测试以程序设计说明书为指导。测试模块范围内的主要控制路径，以揭露错误。重心放在代码审查，测试用例，测试特性，用例描述，测试总结上。后期我会对单元测试进行补充说明。
被测单元模块声明初始状态时，即此模块单元测试的开始。
正面测试：依据设计说明书设计用例，用等价划分设计用例
负面测试：错误猜测和边界值分析
覆盖率：分支覆盖/条件覆盖
（2）功能测试用例设计要点
首先考虑等价划分类，边界值共用，并用错误推测法补充；如果业务流程清晰可采用场景法设计；若程序有详细的因果关系，应该一开始就采用因果图法；如果是文件配置类型的测试，考虑功能图法
（3）集成测试用例设计要点
按详细设计说明书来设计，测试用例数据来源于UC，内部逻辑结构分析按单元测试进行。
（4）性能测试用例，需要不断的迭代完善的过程，一个完整的性能测试通常包括：预期指标性能测试，独立业务性能测试，组合业务性能测试，疲劳强度性能测试，大数据量性能测试，网络性能测试，服务器（操作系统，Web服务器，数据库服务器）性能测试，一些特殊的测试。
预期性能测试用例依据需求和设计文档明确的性能要求进行设计；
独立业务性能从单个模块功能和性能要求出发设计；
组合业务性能从需求，设计文档，现场调查，系统采集数据方面进行用例设计；
疲劳强度性能测试需要编写不同参数或者负载条件下设计测试用例；
大量数据性能需考虑数据处理能力，用边界值分析法设计用例；
网络性能测试使用工具调整网络设置；
服务器测试一定要和前面的测试结合起来进行。
（5）系统测试用例根据需求分析来检验软件是否满足功能，行为，性能，系统协调性等方面的要求。
使用的数据应具有代表性，并与真实数据的大小和复杂性相当
（6）验收测试用例设计
应该在研发阶段测试用例基础上重新编写，而不能直接拿来使用；需与客户需求相对应，面向客户；把握客户的关注点并适当展示软件的独特性。
（7）回归测试用例设计要点
不需要重复设计，只需选择以前的测试用例，针对最重要或最频繁使用的功能测试用例。
综上描述需要结合实际工作运用实践，精益求精。赶快行动吧~
