测试用例应该怎么写( 二 )


操作步骤:1、将光标点入“我来帮他解答”下的输入栏 。
2、输入想提交的答案
3、点击提交回答
4、验证提交后答案是否能显示到当前问题下
(输入数据多数时候是合并到操作步骤中的,比如这条里的输入数据就是“答案”)
预期结果:1点击提交回答后,页面提示回答成功 。2再次查看该问题时,刚刚的答案可以正确显示……
3.软件测试的测试用例怎么写● 测试用例编号
◇ 规则:编号具有唯一性、易识别性,由数字和字符组合成的字符串
◇ 约定:
系统测试用例:产品编号-ST-系统测试项名-系统测试子项名-XXX
集成测试用例:产品编号-IT-集成测试项名-集成测试子项名-XXX
单元测试用例:产品编号-UT-单元测试项名-单元测试子项名-XXX
● 测试项目
◇ 规则:当前测试用例所属测试大类、被测需求、被测模块、被测单元等
◇ 约定:
系统测试用例测试项目:软件需求项 如:测试手机在没有SIM卡的情况下,可以拨打紧急电话
集成测试用例测试项目:集成后的模块名或接口名 如:测试模块A提供的文件接口
单元测试用例测试项目:被测试的函数名 如:测试函数int ReadFile(char *pszFileName)
● 测试标题
规则:测试用例的概括简单的描述用例的出发点、关注点,原则上不能重复 。
● 重要级别
规则
高:保证系统基本功能、核心业务、重要特性、实际使用频率高的测试用例;
中:重要程度介于高和低之间的测试用例;
低:实际使用频率不高、对系统业务功能影响不大的模块或功能的测试用例 。
● 预置条件
规则:执行当前测试用例需要的前提条件,是后续步骤的先决条件
● 输入
规则:用例执行过程中需要加工的外部信息,输入、文件、数据库等
● 操作步骤
规则:执行当前测试用例需要经过的操作步骤,保证操作步骤的完整性 。
● 预期输出
规则:当前测试用例的预期输出结果,包括返回值的内容、界面的响应结果、输出结果的规则符合度等
4.单元测试用例该怎么写写单元测试用例?好像有些理想化 。
在实际工作中,能有个基本的详细设计文档就不错了,只要有了详细设计文档,就可以直接建立可执行的测试用例 。先写个文字的单元测试用例,费时费力,还要维护,项目不会给那么多时间吧?从我们的客户反馈来看,实际工作中,很多项目是没有规范的详细设计的,这时最容易范的错误就是:测试人员阅读代码来了解代码功能,以便设计用例,结果,测试几乎没有效果 。
所以,除非有规范的文档,否则单元测试要由开人员为主 。如果连详细设计文档都没有,那依据什么来写文字版的单元测试用例?如果有,那就用不着写一个文字版的 。
5.怎么写好测试用例测试用例是测试执行的指导;是测试执行的实体,是测试方法、测试质量、测试覆盖率的重要依据和表现形式;是团队内部交流以及交叉测试的依据,便于测试工作的跟踪管理,包括测试执行的进度跟踪,测试质量的跟踪,以及测试人员的工作量的跟踪和考核;在测试执行工作开展前完成测试用例的编写,可以避免测试工作开展的盲目性;测试用例是说服用户相信产品质量的最佳依据,同时也可以提供给客户作为项目验收的依据 。以上可以看出测试用例在整个测试工作中的地位和作用,以下编写了关于如何写好测试用例的一些个人建议:
1、要参与需求评审,评审需求的过程实际也是熟悉业务需求的过程 。只有对业务比较熟悉了,才能更好的,更充分的设计出高质量的测试用例 。