称心常识网一个优秀的测试用例应该包含哪些信息？
1. 软件或项目的名称 2. 软件或项目的版本（内部版本号） 3. 功能模块名 4. 测试用例的简单描述，即该用例执行的目的或方法 5. 测试用例的参考信息（便于跟踪和参考） 6. 本测试用例与其他测试用例间的依赖关系 7. 本用例的前置条件，即执行本用例必须要满足的条件，如对数据库的访问权限 8. 用例的编号（ID），如可以是 软件名称简写-功能块简写-NO.。
9. 步骤号、操作步骤描述、测试数据描述 10.预期结果（这是最重要的）和实际结果（如果有BUG管理工具，这条可以省略） 11.开发人员（必须有）和测试人员（可有可无） 12.测试执行日期延伸阅读
如何去为一个购物网站设计测试用例？
测试用例的设计是根据需求文档或者story的基础上，归纳出测试点，然后设计成一个个小小的测试用例。
购物网站
1. 登录模块
一般的测试用例
a. 输入正确的用户名密码，期待结果
b.输入不正确的用户名密码，期待结果
c. 如果用户名不存在，期待结果
d. 密码输入框中，输入的数据要显示成*号
等等
2.搜索模块
输入商品名称后，是否出现正确的商品
3.购物车模块
添加商品到购物车后，商品是否出现在购物 车
购物车可支持添加的最大数量
4.支付模块
选着要购买的商品后，支付总额是否正确
是否减除优惠券等
点击支付后，弹出的支付模块是否正确
确认支付后，是否可以成功的支付
等等吧
具体的还要看测试需求上的要求
软件测试用例的基本要素包括哪些？
1、用例编号
由字符和数字组合成的字符串，测试用例编号应该具有唯一性、易识别。
如系统测试的用例编号格式为：产品编号-ST-系统测试项名-系统测试子项名-xxx。（备注：每个公司对于用例书写的规则不尽相同，具体细则还需要参考公司配置命名规范）。
2、所属模块
当前测试用例所在的测试大类或被测试需求、被测的模块、被测单元等。
3、用例标题
描述简洁清晰，无歧义，要用概括的语言描述出Case的关注点，且每个用例的标题不可重复。
4、重要级别，即用例优先级
一般分为高、中、低。特殊项目可以自定义优先级别，目的是用例执行人员可参照此来安排执行时间。
5、前置条件
执行当前测试用例时需要的前提条件，若不满足此前提条件，则无法执行后边的测试步骤。前置条件并不是每个用例都需要的，视情况而定。
6、输入数据
测试用例在执行过程中需要输入的外部数据。依据用例具体情况，通常包含有手工录入、文件、DB记录等。
7、操作步骤
执行当前测试用例需要的操作步骤，通常要明确的给出每个步骤的详细描述，用例执行人员需根据该步骤完成用例执行。
8、预期结果
当前用例的预期输出结果，包括返回值的内容，以及界面的响应结果，输出结果的规则符合度、数据库等存储表中的操作状态等。
什么时候写测试用例比较好？
需求文档确定后，就可以开始了。
有了详细的产品需求说明书后，在系统设计阶段就应该写系统测试方案，系统测试计划并开始详细设计测试用例了。
此时这个开始设计系统测试用例，无法编写很具体细节的用例，但是我们可以思考编写简略测试用例的要点。
设计测试用例越靠近需求阶段，我们就能越早发现需求问题，在软件开发过程问题得到越早的修正，那么所花的代价就会越小。
如何根据需求设计测试用例？
？ 从拿到需求文档不要立马开始着手写测试用例，需要仔细推敲整理需求，画出系统级、模块内流程图，并找出各种测试点，等对需求进行了头脑风暴般的整理之后，此时已对测试系统的功能很清楚了，再着手开始写测试用例。
那么编写测试用例的总体思路是什么呢？通过半年的测试用例编写经验，总结如下，如有不妥之处需改进。
1、整理分析需求文档 仔细将需求文档文档阅读一遍，记录不明白的地方及关键测试点，简单画出总体流程图。
然后再来一遍，仔细分析各个模块的功能，画出模块内流程图，找出所有功能，并列出主要测试点 2、编写用例 按照不同的业务规则可将测试用例分为四部分：场景用例、系统用例、功能用例 场景用例：按照用户的实际操作与业务逻辑设计用例，不必涉及很复杂的操作或逻辑，把用户最常用的、正常的操作流程作为一个场景设计测试用例。
系统用例：是用户场景的细化，包含正常场景、分支场景和异常场景，是两个或多个有关联的功能组合而成的场景。
功能用例：用于验证各功能点的业务规则，包括界面元素和各功能的业务规则验证。
主要针对单个功能点。
第一步：场景用例（关键字：模拟用户实际操作） 根据画出的模块内流程图，描述用户的主要业务目标，包含完整的系统级场景和模拟用户实际操作的不同场景，几个功能点的组合也算是用户场景。
第二步：系统各角色的系统用例 结合画出的模块内流程图，将系统划分多个角色，再将每个角色分解为多个任务，每个任务就是一个系统用例。
系统用例分别正常流程、异常流程，分支流程，以场景的形式描述。
第三步：功能用例 描述单点功能的逻辑规则及页面元素，分层描述逻辑规则，对逻辑规则细化可直接作为用例的操作步骤描述。
编写用例的过程中也有一些迷茫： 问题1：场景法用什么方式描述比较清楚，并且后期需求改动了易维护？ 问题2：测试用例与测试数据的关系是什么呢？如何将两者区分开来？ 3、报表类功能模块如何编写测试用例？ 报表类的模块基本没有业务流，不适用场景法。
其实报表类模块主要验证能否依据查询条件正确查询显示数据，并保证数据的正确性。
