如何高质量的编写测试用例?

一、单元测试用例

单元测试用例有人总结出来了编写用例的3A原则,分别是

1.Arrange: 初始化测试对象或者准备测试数据

2.Act : 调用被测方法

3.Assert: 断言

给一个例子

[TestMethod]  
public void Withdraw_ValidAmount_ChangesBalance()  
{  
    // arrange  
    double currentBalance = 10.0;  
    double withdrawal = 1.0;  
    double expected = 9.0;  
    var account = new CheckingAccount("JohnDoe", currentBalance);  
    // act  
    account.Withdraw(withdrawal);  
    double actual = account.Balance;  
    // assert  
    Assert.AreEqual(expected, actual);  
}  

二、服务间的接口测试用例

服务间的接口测试实际上是黑盒测试,3A原则也适用于这种测试用例的编写

1.Arrange: 准备测试数据,这里的方案会有很多

2.Act : 使用各种参数调用被测接口

3.Assert: 断言

举个例子


    def test_get_task_by_id(self):
        # arrange
        create_task_res = self.create_task('test', 'desc')
        new_id = create_task_res['id']

        # act
        url_for_get_by_id = self.ip + '/api/tasks/' + str(new_id)
        res = requests.request("GET", url_for_get_by_id).json()
        
        # assert
        self.assertEqual(res['id'], new_id)

三、手工测试用例

手工的功能测试用例也可以用3A原则来编写

1.Arrange: 准备被测功能相关的测试数据,比如往系统里录入一批工单以便测试工单的分页功能

2.Act : 调用被测的功能,实际上这就是我们一直讲的测试步骤

3.Assert: 断言

举个例子

# arrange and act
打开chrome浏览器并跳转至http://localhost/wordpress/wp-login.php
在用户名文本框中输入admin
在密码文本框中输入admin
点击登陆按钮
# assert
浏览器跳转到http://localhost/wordpress/wp-admin/
右上角出现“你好,amdin”字样

在一些测试团队中,手工测试用例会在测试人员之间进行传播,比如李雷写了手工测试用例,韩梅梅则是用例的执行者。如果李雷的测试用例写的比较抽象派和印象派,韩梅梅是很难去直接执行的,所以会有一些测试团队强调尽量编写可以让人理解,也就是不用脑补的手工测试用例。但是写的越精确花费的时间就越长,如果项目周期紧张的话,是没有充足的时间去写完备的测试用例的。

在这种情况下,一些有经验的测试人员会写一些测试大纲,相当于是测试备忘录,提醒自己该测哪些情况,不要有遗漏,比如

登录成功的情况
登录失败:用户名密码为空
登录失败:密码不对
登录失败:只输用户名不输密码

四、用例的维护

用例的维护成本往往是很高的

1.单元测试用例: 被测代码发生变化时单元测试用例需要相应更新

2.服务间接口用例:被测服务的接口或逻辑发生变化时需要相应更新

3.手工测试用例:需求变化了用例就要跟着改

创建了一个测试交流群,如果对软件测试、接口测试、自动化测试、面试经验交流感兴趣可以加测试交流群:829792258,还会有同行一起技术交流

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
编写测试用例的步骤如下: 1. 理解需求:仔细阅读需求文档或用户故事,确保对需求有充分的理解。 2. 定义测试目标:根据需求文档或用户故事,确定测试的目标和范围,明确测试的目的是什么。 3. 设计测试用例:根据测试目标,设计测试用例,包括输入数据、预期输出、测试步骤等。 4. 执行测试用例:按照测试用例执行测试,记录测试结果。 5. 分析测试结果:根据测试结果分析问题所在,对问题进行分类和优先级排序。 6. 编写缺陷报告:对于发现的问题,编写缺陷报告,描述问题的详细信息和复现步骤。 7. 修复缺陷:开发人员根据缺陷报告修复问题。 8. 重复执行测试用例:对于修复的问题,重复执行相关测试用例,确保问题已修复。 为了保证测试用例的覆盖度,可以采用以下方法: 1. 分类测试:将测试用例按照功能、模块、场景等进行分类,确保每个分类都有相应的测试用例。 2. 边界测试:在输入数据的边界范围内进行测试,确保系统能够正确处理边界条件。 3. 异常测试:模拟系统出现异常情况,如输入错误数据、网络中断等,确保系统能够正确处理异常情况。 4. 性能测试:对于需要处理大量数据或有大量并发访问的系统,进行性能测试,确保系统性能符合要求。 为了维护测试用例,可以采用以下方法: 1. 定期更新测试用例:随着系统的不断更新,测试用例也需要不断更新,确保测试用例与系统保持一致。 2. 定期评估测试用例:定期评估测试用例的有效性和覆盖度,删除无效的测试用例,增加新的测试用例。 3. 自动化测试:对于重复性较高的测试用例,可以采用自动化测试工具进行自动化测试,提高测试效率。 4. 团队协作:测试用例的维护不仅需要测试人员的努力,也需要开发人员和产品经理的协作,确保测试用例的质量和覆盖度。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值