请教功能测试用例怎么写???

发布网友 发布时间：2022-04-19 12:26

我来回答

共3个回答

热心网友 时间：2023-08-13 23:01

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

热心网友 时间：2023-08-13 23:01

【不在于测试用例该怎么写，而在于想怎么测。】【对用例的理解表达出来，格式自然出来了】呵呵，偶要顶一下，偶不是完全赞同这两句话。用例的理解跟格式没有必然的联系。也没有主次轻重之分。【先保证自己对业务流程和业务规则的理解和熟悉，然后可以对这部分先思考一下，哪些地方需要测试，需要怎样的测试？如何来施行这些测试？之后再增加对系统中其他规则、特性和算法的熟悉，继续增加测试的深度和广度。】——这句说的很对。有这么一个公式， 数据结构＋算法＝程序。这里类比一下用例设计，jackei和skinapi版主强调的是用例的“算法”，而文档格式是用例的“结构”。两者的关系是相辅相成，而不是矛盾的（好像在上*课哈）。至于说“对用例的理解表达出来，格式自然出来了”，这个境界太高了，不是一般人可以做到的。面对现实的企业应用，做项目的话你会遇到各种各样的情况，要做到“格式自然出来”实在是太……厉害了呵呵。是这样的：用例格式相当于一个规范，给你一个结构，一个框架（framework），仅此而已，并不因为你的用例模板而能体现用例的好坏。所以， “用例怎么写”其实分两个：用例的“算法”＋用例的“结构” （也就是模板）了。 查看原帖>>

热心网友 时间：2023-08-13 23:02

同意jackei，如何设计出好的用例才是关键，把对用例的理解表达出来，格式自然出来了，如果只局限于形式，编写用例反而成了一件不断的重复操作和填鸭，痛苦不说也不容易写好。