我们先要进行软件测试用例的分析和设计，然后写出软件测试的内容，最后按照软件测试写作方法，落实到文档中，写的好的测试用例不仅方便自己和别人查看，而且能帮助设计的时候考虑的更周全，因此测试用例的写作和测试用例的设计一样，也是非常重要的。
如何编写测试用例？——测试用例的内容
一、通用测试用例十要素
1、用例编号；
2、测试日期；
3、测试用例设计人员和测试人员；
4、测试的优先级；
5、测试标题；
6、测试目标；不仅要测试功能，还要测试性能
7、测试环境；
8、测试输入；
9、操作步骤；
10、预期结果。
二、具体分析通用测试用例十要素
1、用例编号
一般是数字和字符组合成的字符串，可以包括（下划线、单词缩写、数字等等），但是需要注意的是，尽量不要写汉语拼音，因为拼音的意义可能有好几种，有可能会导致乱码；
用例编号具有唯一性和易识别性。（ 比如说我们唯一标识一个人：中国-上海市-xx区xx号-xx楼--xx室-xxx.这样标识的话就具有唯一性了。)
不同阶段的测试用例的用例编号有不同的规则：
（1）系统测试用例：产品编号-ST-系统测试项名-系统测试子项名-XXX
（2）集成测试用例：产品编号-IT-系统测试项名-系统测试子项名-XXX
（3）单元测试用例：产品编号-UT-系统测试项名-系统测试子项名-XXX
**其中产品编号也叫项目标识，每个公司都有若干不同的项目或者产品，如何来区分它们呢？这就需要有产品编号了，每个公司都有自己的一套定义产品编号的规则，并且每个现有产品的编号已经制定好了，直接拿过来用就可以了。
**产品编号后的ST、IT、UT分别对应系统测试阶段、集成测试阶段、单元测试阶段。实际工作中有些公司会将产品编号以及测试阶段省略。
**测试阶段后面就是测试项目名了，对应的是较大较系统的测试点。
**测试项目名后面就是测试子项目名，有些测试是没有子项目名的，只有当测试项力度比较大的时候才会有成都市子项 （比如说：我们要测试用户能否成功登录这个功能，那我们就可以分为很多个子项，qq登录、邮箱登录等等）。
**测试子项名后面就是具体的用例编号了，可以是数字：01、001、002等等。
2、测试项目
测试项目对应的就是测试用例中的子项名。
（1）系统测试用例：对应一个功能点（功能测试）、性能指标（性能测试）、界面中控件（GUI测试）等等。
（2）集成测试用例：对应集成后的模块功能或者接口功能。
（3）单元测试用例：对应函数名。
3、测试标题
测试标题考虑的是如何来完成测试项目，或者说从哪个角度来对测试项目进行测试，有的公司也取名为测试目的。
测试标题一定要简单、概要；体现测试的出发点和关注点。
4、重要级别
用例的重要级别一般分成三个级别：高、中、低。
高级别：对应保证系统基本功能、核心业务、重要特性、实际使用频率比较高的用例；
中级别：对应重要程度介于高和低之间的测试用例；
低级别：对应实际使用频率不高，对系统业务功能影响比较大的模块或功能的测试用例。
**举个手机的例子：**
（1）高级别需求：正常通话功能、短信功能；
（2）中级别需求：拍照、联系人、MP3；
（3）低级别需求：计步、收音机等等。
还需注意的是：针对**正常情况**的测试用例的重要级别比针对**异常情况**的测试用例的重要级别要高。
5、预置条件
测试用例在执行前需要满足一些前提条件，否则测试用例是无法执行的，这些前提条件就是预置条件。
预置条件分为两种情况：
（1）环境的设置。
例如：测试word打开文件的功能，预置条件就是：需要提前准备被打开的文件；
例如：登录成功的预置条件就是：该用户名已经注册过了。
例如：购买商品成功的预置条件就是：后台已经配置好商品、发货区域、以及支付方式了。
（2）先要运行的其他用例，有些操作系统会比较复杂，如果都是从最开始的操作开始会导致用例写起来比较麻烦，这样可以在预置条件中设定要先运行的测试用例，后面的用例只需要写后续的操作就可以了。
例如：对自动取款机进行测试，有针对的输入账户信息的测试，有对输入取钱金额的测试，后者的预置条件就可以写成输入正确账户信息的测试用例。
注：具体预置条件的设置不同的公司会有自己的规定，比如有的公司是不允许第二种情况出现的。
6、测试输入
用例执行过程中需要加工的外部信息，根据软件测试用例的具体情况，有手工输入、文件、数据库记录等。
禁止过多描述性语言，若为文件，会有提示选择路径，最好写具体，让别人易懂易操作。
7、操作步骤
明确描述测试执行过程中具体的操作步骤，以方便测试执行人员可以根据该操作步骤完成测试用例执行。
8、预期输出
预期输出是测试用例中非常重要的一部分，预期输出可以检验被测对象是否正常工作，如果我们的预期输出写的不完整不全面，整个测试用例就会受到影响。
我们在写预期输出的时候可以从以下三个方面来考虑：
（1）界面显示：在操作步骤完成之后，界面会有显示；比如说我们测试用户登录功能，界面可能会显示登录成功或者登录失败。
（2）数据库的变化：在操作步骤完成之后，数据库中的记录会发生相应的变化，比如删除功能的测试，点击删除后，数据库中该记录会被删除。
（3）相关信息的变化：在操作步骤执行完成后，一些和被测对象相关的信息会发生变化，比如：注销功能的测试，点击注销后，以前能访问的页面将无法再访问。
测试用例注意事项：
1使用最有可能发现错误的用例
2用例不重复、不冗余
3选取一组相似测试用例中最有效的
4灵活运用测试用例模板
如何执行测试用例？
1、清晰且准确理解用例，不带半点含糊
2、执行用例不能走样
3、执行用例要看实际结果与预期输出是否一致
4、测试过程还要保持整体观察
5、执行测试用例中，收集好发现的bug,不能有遗漏
测试用例
什么是测试用例？
【测试用例（Test Case）是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求，是软件测试人员需要具备的基础能力。】
定义：
（1）Test case是为特定目的而设计的一组测试输入、执行条件和预期结果
（2）通过大量的测试用例来检验软件 的运行效果，它是指导测试工作进行的依据
编写测试用例的根本目的？
目的： 是有效找出软可能存在的缺欠，为达到这个目的，需要分享被测试软件的特征，运用有效的测试方法，使用较少的测试用例，同时满足合理的测试需求覆盖，达到少花时间多办事的效果
设计测试用例的基本准则？
定义：
（1）测试用例的代表性
能代表病覆盖各种合理的和不合理的，合法与非法，边界和越界的，以及极限的输入数据，操作和环境设置等
（2）测试结果的可判定性
测试结果的正确性是可以判定的，每个测试用例都有对应的期望结果
（3）测试结果的可再现性
对同样的测试用例，系统的执行结果是相同的
好用例的标准：
/是否可以发现Bug
/是否够高效
/是否够经济
/是否有足够的扩展性
——————————————————————————————————————————————————————
测试用例的意义 测什么？如何测?如何衡量？
/理清思路，避免遗漏
/跟踪测试进展
/历史参考
/重复性
测试用例的优点
/组织性
/重复性
/功能覆盖
/跟踪
/测试确认
测试用例的用途
/核实需求
/监督过程
/评估结果
/准确回归
/防止遗漏
/提高效率
/缩短周期
测试用例的设计依据
/需求文档
/设计文档
/遗留系统相关文档
/与相关人员讨论
/探索式测试 把产品当做产品说明书来对待
测试用例更新与维护
/需求变更，功能变化，测试用例需要更新
/测试用例需要细化和不断完善
/通过测试实践检验测试用例并添加、修改、删除测试用例
测试用例要经过正式、有效的评审
利用工具来维护测试用例
————————————————————————————————————————————————————
测试用例开始设计最优时间
当根据客户的需求整理出项目需求分析文档时，我们就可以根据需求文档来编写测试用例了。但是，一般我们（国内大多小公司）项目需求文档都非常“简陋”，所以，很难根据需求文档设计测试用例。
我们只有等到项目开发人员把项目开发出来，给我们系统文档、部署环境、数据库结构（如果系统牵涉到数据库的话），我们根据这些文档来设计测试用例。
融入探索性测试思维
完全的执行测试用例时一件非常枯燥的事情，个人在执行测试用例时会做一些，其它的非常规性的操作，看系统是否会有相应的处理和提示。
测试优先级的划分：
1、测试时间和资源有限，可能无法执行所有的测试用例，穷尽 测试是不可能的
2、首先执行最重要的测试用例或优先测试用户最需要的功能，尽快尽早发现可能多的bug
3、测试用例优先级的划分和测试执行顺序的确定，取决于项目的特征，应用领域和客户的要求
4、即使测试过早结束，也要保证在时刻测试工作能达到最好的效果
二、测试优先级的划分细则
1、使用频率或失效的概率
2、失效的风险
3、失效的可见性
4、需求的优先级
5、质量特性
6、开发人员的角度
7、测试对象的复杂性
8、高项目风险的失效
9、缺陷的集群效应