• 首页
        • 更多产品

          客户为中心的产品管理工具

          专业的软件研发项目管理工具

          简单易用的团队知识库管理

          可量化的研发效能度量工具

          测试用例维护与计划执行

          以团队为中心的协作沟通

          研发工作流自动化工具

          账号认证与安全管理工具

          Why PingCode
          为什么选择 PingCode ?

          6000+企业信赖之选,为研发团队降本增效

        • 行业解决方案
          先进制造(即将上线)
        • 解决方案1
        • 解决方案2
  • Jira替代方案
目录

测试用例怎么写

测试用例的格式主要包含以下字段:1. 测试项目;2. 测试子项;3. 测试标题;4. 测试用例优先级;5. 预置条件、输入、执行步骤;6.预期结果。其中,测试项目是本次测试的功能点,如登录。

一、测试用例的格式

1.测试项目

本次测试的功能点,如登录

2.测试子项

测试子项是表示我们本次测试的目的:如正常登录测试用例编号 测试用例编号,

3.测试标题

测试标题表示该用例测试的目标

4.测试用例优先级

之所以对用例进行标级,是因为可以根据用例的优先级来确定我们的测试策略。

通常对于用例优先级定义:高、中、低三个级别

确定测试用例的优先级一般有两种方式:一是业务的优先级;二是用例优先级评估模型。

业务的优化级 :

根据业务的优化级来定义的优化级,即如果业务的优化级越高,那么用例的优化越高。业务的优先级有两个方面:一是需求本身优先级;二是业务本身分为基本与备选流。需求的优先级也分为:高、中、低三个级。

高:如果这个需求不做或者说做的不完善,那么这个产品无法销售

中:该需求一定要实现,但可以做不是那完善或极致

低:该需求是否实现无所谓,不会影响到产品都可以卖出去,但是可能会影响产品的定价和销售量。也称之 为“镀金需求”

VH:核心业务+基本流

H:核心业务+备选流,基本+基本流

M:基本业务+备选流和一般业务+基本流

L:一般业务+备选流 用例优先级模型

用例优先级模型从三个来评估用例等级:

—>使用频率

使用次数,每天使用多少次或者是每多少天使用一次

—>影响程度

如果这个用例失效了,那么对用户的影响程度

—>失效可能性

这个功能出现问题的概率有多大,每执行多少次会失效一次

上面三个维度又为会高、中、低三个级别,分别对应的权重为5、3、1。

每个维度的权重分别为:0.4、0.2、0.4

例如,如果使用频率为高、影响程度为中、失效可能性为低 5 * 0.4 + 3 * 0.2 + 1 * 0.4 = 3(M)

5.预置条件、输入、执行步骤

执行用例之类系统应该达到的状态;

该用例在执行测试时,需要输入的数据;

步骤是我们执行这个用例时我们操作软件的步骤

6.预期结果

预期结果是从何而来的,预期结果是来自软件需求

预期应该从哪些维度来描述:

—>GUI界面:例如界面提示、对话框 —>数据库:例如,注册,注册成功后数据库中会有一条用户信息

—>相关文件:例如:QQ文件传输的默认路径,这个路径如果修改了那么就会将保存这个默认路径的配置文件 也修改。

—>日志文件:很多业务每执行一次,不管是成功还是失败都会写一条日志文件信息

延伸阅读:

二、测试用例重要性

软件测试的重要性是毋庸置疑的。但如何以最少的人力、资源投入,在最短的时间内完成测试,发现软件系统的缺陷,保证软件的优良品质,则是软件公司探索和追求的目标,每个软件产品或软件开发项目都需要有一套优异的测试方案和测试方法。

影响软件测试的因素很多,例如软件本身的复杂程度、开发人员(包括分析、设计、编程和测试的人员)的素质、测试方法和技术的运用等。因为有些因素是客观存在,无法避免的;有些因素则是波动的、不稳定的。例如开发队伍是流动的,有经验的开发人员走了,新人不断补充进来;每个开发人员的工作也会受情绪影响,等等。有了测试用例,无论是谁来测试,参照测试用例实施,都能保障测试的质量,从而把人为因素小。即便最初的测试用例考虑不周全,随着测试的进行和软件版本更新,也将日趋完善。

以上就是关于测试用例的内容希望对大家有帮助。

一站式研发项目管理平台 PingCode

一站式研发项目管理平台 PingCode

支持敏捷\瀑布、知识库、迭代计划&跟踪、需求、缺陷、测试管理,同时满足非研发团队的流程规划、项目管理和在线办公需要。

相关文章