一、单元测试用例
单元测试用例有人总结出来了编写用例的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,还会有同行一起技术交流