论文测试用例模板

问：写测试用例应该怎么写？我想知道具体的模式。谢谢！

1. 答：假设一下吧。现在要求你测试一下百度知道的提交回答功能。
   用例编号：提交问题001（编号通常会根据功能或模块编写）
   测试目的：验证当用户回答完问题后，可以正常提交答案。（多数是会写需求规格的说明，总之要让人看明白你这条用例是想测什么）
   测试标题：这个有时候就包含了测试目的，目的是可以不写的，但测试用例标题是必须的。
   重要级别：像提交回答这条用例，多数会被列为最高级别用例，因为是最基本的功能。往往越是基本的，级别越高。原因在于，如果基本功能都有缺陷，那根本不用测别的功能，版本直接打回。
   预制条件：1、百度知道运转正常。2、用户已登陆。3、进入了自己想要回答的问题页面。（也就是你做这条测试前必须要有的前提条件）
   操作步骤：1、将光标点入“我来帮他解答”下的输入栏。
   2、输入想提交的答案
   3、点击提交回答
   4、验证提交后答案是否能显示到当前问题下
   （输入数据多数时候是合并到操作步骤中的，比如这条里的输入数据就是“答案”）
   预期结果：1点击提交回答后，页面提示回答成功。2再次查看该问题时,刚刚的答案可以正确显示……

问：计算机毕业论文的测试用例管理系统的结果统计分析模块应该怎么写？谁帮帮我~急~~~高分

1. 答：正好我这两天再研究测试用例管理系统，虽然不是毕业论文，但是希望能帮上你的忙
   ——测试用例执行结果统计分析模块(Statistics & Analysis)
   ——测试人员在执行完整个测试用例集以后，根据测试结果模板出具测试报告（包括用例pass率/fail率、问题报告列表、测试人员感想）并自动通过E-mail发送测试报告
   ——针对fail用例，生成饼状图，主要通过fail用例追踪测试用例库中的需求关键词，饼状图主要展示每个需求关键词中fail的用例数。
   ——通过点击上述饼状图进入某个需求关键词下属的fail用例列表，并查看
   ——可以在各个模块中根据自己的需求创建柱状图，如在测试用例库模块中可定义创建者、所编写的用例被测频率；需求关键词、每个需求关键词所包含用例数；测试工具、运用此测试工具的用例数；创建日期、在此创建日期编写的用例。作为X,Y轴。如在资源分配模块中可定义每个测试人员的测试时长和测试用例数作为X,Y轴，从而自动计算出每个测试人员的测试效率；定义测试硬件、使用频率（High/Medium/Low）;如在测试用例执行问题处理模块中可定义报告者、报告问题数作为X,Y轴，从而自动计算每个人的报告问题效率；需求关键词、被关联的问题报告数；错误等级评估、每个等级的错误报告数。
   （可选）——深入分析fail的用例，查看fail用例具体出现问题的步骤，并以此步骤为关键词，搜索其他相关的用例，扩大测试范围。

问：功能测试用例怎么写

1. 答：测试用例编号
   ◇ 规则：编号具有唯一性、易识别性，由数字和字符组合成的字符串
   ◇ 约定：
   系统测试用例：产品编号-st-系统测试项名-系统测试子项名-xxx
   集成测试用例：产品编号-it-集成测试项名-集成测试子项名-xxx
   单元测试用例：产品编号-ut-单元测试项名-单元测试子项名-xxx
   ● 测试项目
   ◇ 规则：当前测试用例所属测试大类、被测需求、被测模块、被测单元等
   ◇ 约定：
   系统测试用例测试项目：软件需求项 如：测试手机在没有sim卡的情况下，可以拨打紧急电话
   集成测试用例测试项目：集成后的模块名或接口名 如：测试模块a提供的文件接口
   单元测试用例测试项目：被测试的函数名 如：测试函数int readfile(char *pszfilename)
   ● 测试标题
   规则：测试用例的概括简单的描述用例的出发点、关注点，原则上不能重复。
   ● 重要级别
   规则
   高：保证系统基本功能、核心业务、重要特性、实际使用频率高的测试用例；
   中：重要程度介于高和低之间的测试用例；
   低：实际使用频率不高、对系统业务功能影响不大的模块或功能的测试用例。
   ● 预置条件
   规则：执行当前测试用例需要的前提条件，是后续步骤的先决条件
   ● 输入
   规则：用例执行过程中需要加工的外部信息，输入、文件、数据库等
   ● 操作步骤
   规则：执行当前测试用例需要经过的操作步骤，保证操作步骤的完整性。
   ● 预期输出
   规则：当前测试用例的预期输出结果，包括返回值的内容、界面的响应结果、输出结果的规则符合度等