备注：

　　●“测试用例名称”可以是不涉及到具体模块的功能描述，如“日期格式”，“非空检验”等。

　　●“输入说明”是功能模块接受的数据或各种操作描述，如“输入非法的日期格式”等。

　　●“期望结果”是模块接受输入后应有的正常输出描述，如“提示用户修改”等，期望结果应与输入说明一一对应。

　　●测试用例用于指导执行操作，但某些意外操作也可导致程序错误，这些操作称为非预期性操作，可以先有执行报告，再后补用例。

　　●测试用例的设计应考虑通用性和简洁明了。

　　2 、执行测试用例

　　●此报告用于记录执行上一步设计的测试用例的过程及结果。

　　●“步骤”应填入详细的操作，如“点增加 -> 输入日期 -> 保存”。“输入数据”填入具体数据，如“ 2002/12/12 ”。

　　●“期望输出”即测试用例中的“期望结果”，但描述应更具体，如“弹出提示对话框，提示用户日期格式错误”。

　　●“实际输出”是操作的真实结果，必须详细、清晰，便于开发人员理解。

　　●如“实际输出”与“期望输出”不符，则结果为 F （ False ），若相符则结果为 T(True) 。

　　3 、用例模板

　　软件功能性测试用例模板

　　一、功能检查

　　1 、功能是否齐全，例如：增加、删除、修改

　　2 、功能是否多余

　　3 、功能是否可以合并

　　4 、功能是否可以再细分

　　5 、软件流程与实际业务流程是否一致

　　6 、软件流程能否顺利完成

　　7 、各个操作之间的逻辑关系是否清晰

　　8 、各个流程数据传递是否正确

　　9 、模块功能是否与需求分析及概要设计相符

　　二、面向用户的考虑

　　1 、操作方便性，如：按键次数是否少

　　2 、易用性，面对用户的操作是否简单易学

　　3 、智能化考虑

　　4 、提示信息是否模糊不清或有误导作用

　　5 、要求用户进行的操作是否多余，能否由系统替代

　　6 、能否记忆操作的初始环境，无需用户每次都进行初始化设置

　　7 、是否不经确认对系统或数据进行重大修改

　　8 、能否及时反映或显示用户操作结果

　　9 、操作是否符合用户习惯，比如：热键

　　10 、各种选项的可用及禁用是否及时合理

　　11 、某些相似的操作能否做成通用模块