一、测试用例概念：
测试用例其实就是根据需求文档，或者结合软件功能，把自己测试思路有条理的整理出来。
二、设计测试用例的优缺点
1、好处：
有效性、完整性、组织性
2、缺点：
测试用例的设计是费时费力的工作，往往设计测试用例所花费的时间比执行所花费的时间还长。
三、测试用例书写工具
1、Word
2、Excel
3、自动化编写工具PICT（本人已经研究实现）详细的细节以及实现请参考【PairWise策略设计测试用例及PICT测试用例工具安装使用（实现测试用例的自动化）】
注：大部分公司通过Excel书写测试用例，使用工具根据公司具体情况制定模版
四、测试用例书写依据
1、需求说明书
2、项目测试需求功能点
3、所属行业的业务知识掌握程度
4、测试工程师本人的理解程度（个人经验）
注：必须有需求文档，若没有需求文档，就必须对产品功能熟悉，但是两者都必须要对软件业务功能熟悉。
实际工作中，有些公司没有需求文档做参考，这时候就必须要相关人员书写文档，如果不书写文档后期很多测试工作无法开展，甚至会做很多无用功。
五、为什么编写测试用例
1、指导测试工作有序进行，使实施测试的数据有据可依
2、确保所实现的功能与预期的需求相符合
3、完善软件不同版本之间的重复性测试
4、跟踪测试进度，确定测试重点
5.评估测试结果的度量标准
6.增强软件的可信任度
7.分析缺陷的标准
六、测试用例书写目的
为测试设计人员提供测试用例编写的指导，提高编写的测试用例的可读性，可执行性、合理性。为测试执行人员更好执行测试，提高测试效率，最终提高公司整个产品的质量。
七、测试用例内容有哪些
功能模块、功能点、前置条件、操作步骤、预期结果、实际结果、备注。
1、功能模块：某一个测试的模块
2、功能点：模块的某一个功能点
3、前置条件（可选）：系统权限配置或前、后台配置描述（所有进行操作的前提条件）。
4、操作步骤：测试的操作步骤描述。
5、预期结果：预期需要达到的结果
6、备注：测试过程中遇到的问题等情况说明。
八、测试用例什么时候编写
测试用例在需求评审后，就要着手书写测试用例，测试用例编写前，还需要对文档进行评审，【需求评审】
【需求评审】参与人员：产品、程序、测试。
【需求评审】目的：为了让相关人员对功能需求文档全面了解，以便于之后开发计划制定，测试计划制定。
测试用例编写完成后需要对自己编写的测试用例进行评审。【用例评审】
评审原因
测试用例是软件测试的原则，但由于软件人员对在需求理解、设计等理解程度不同等因素的影响，首次产生的测试用例质量难以避免会有不同程度的差异，故对编写的测试用例进行评审是很有必要的，其作用是测试用例的评审过程能够起到用例结构清晰化、场景覆盖全面化以及优先用例的合理化安排等。
【用例评审】参与人员：测试、产品、程序
【用例评审】内容：相关测试点进行梳理，看是否有一些测试点遗漏，测试用例是否简洁
九、测试用例书写思路
1、可以有Xmind（或者mindmanager）思维导图工具，梳理测试点轮廓，结合这些测试轮廓再进行测试点的整理。
用例评审时：建议用思维导图进行评审，
2、测试用例书写要求？
（1）简明扼要的标题；
（2）详细的步骤；
（3）正确的预期结果。
3、测试用例设计方法：
1.等价类划分法
2.边界值分析法
3.错误推断法
4.个人经验
十、测试用例完善
测试用例评审：由测试用例设计者发起，参加的人员需包括测试负责人、项目经理、开发人员及其他相关的测试人员
测试用例完善：测试用例编写完成之后需不断完善，软件产品新增功能或更新需求后，测试用例必须配套修改更新；在测试过程中发现设计测试用例时考虑不周，需要对测试用例进行修改完善；在软件交付使用后客户反馈的软件缺陷，而缺陷又是因测试用例存在漏洞造成，也需要对测试用例进行完善
