网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。
一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!
1、Junit注解
@Test
来接着看下面:
将其与我们之前写的 selenium 代码 比较一下,就能发现 Junit 的好处了。
甚至我们可以一次性执行多个测试单元。
@BeforeEach、@BeforeAll
表示被注解的方法应该在其它方法之前被执行。
@BeforeEach:表示被注解的方法,在每个方法执行之前。都要执行一遍.
@BeforeAll:表示被注解的方法,在所有方法执行之前。只要执行一遍.
@AfterEach && @AfterAll
有 Before,那么就有After,不过分吧?
@AfterEach:在每个测试单元执行之后,都要执行一遍
@AfterAll:在所有测试单元都执行完之后,在最后执行一次。
2、断言
写自动化测试,测试结果分为两种:成功 和 失败。
就像我们前面写的测试来说
看起来很美好。
但是!查询的结果可能跟预期不相符,而我们只是将获取的数据进行输出。
至于结果和我们预期的结果是否一样,那就不得而知了。
更重要的是:当查询的结果和预期结果不一致时,它是不会报错的。
像这样的测试用例就没有起到测试的作用,只是单纯的获取打印信息而已。
等我们有了断言之后,就能对查询到的结果做出判断(测试操作)。这时候它才真正算是一个 自动化测试!
以前写的代码,只能算是 自动化,不算是测试。
1、Assertions - assertEquals 方法
校验 实际数据 是否与 期望值 相同
2、Assertions - assertNotEquals 方法
校验 实际数据 是否与 期望值 不相同
3、Assertions - assertTrue && assertFalse方法
assertTrue 方法 :条件为真通过测试,条件为假测试失败。
将等号换成 equals 即可。
assertFalse 方法 :条件为假通过测试,条件为真测试失败
4、Assertions - assertNull && assertNotNull
assertNull:如果条件为null,通过测试;反之,则不通过。
assertNotNull:如果条件不为null,测试通过;反之,则不通过。
小结
正是因为有了断言,我们的自动化才能带上 “测试” 两个字。
以前我们写的自动化代码【没有断言】对结果是没有标准的。
我们不知道什么样的结果才是正确的,是错误的。
有了断言,我们才知道什么样子的结果才是我们想要的结果。
3、用例的执行顺序 - 方法排序( @Order 注解)
我们先来看两个例子
通过上面的测试用例,我们知道 Junit 的执行顺序不是 “标准(从上往下)”的。
这里需要注意的是: Junit 的默认执行顺序是不确定的,而且官方文档也没有明确给出答案。
Junit官方地址:https://junit.org/junit5/
有兴趣的,可以去看看
但是,我们仍可以使用 Junit里提供的方法【方法非常多】来 手动设置 用例的执行顺序。1、方法的排序
2、标签的排序
3、类的排序
。。。。。这里我们着重学习 方法排序 —— 通过 @Order 注解来排序
现在看来是有序的,可能执行其它的用例就不是这样的了。
虽然说:Junit 是有 执行顺序的,但是容易翻车!
所以我们可以使用 @Order 注解来设置执行的顺序。
在此之前,我们需要引入一个注解 @TestMethodOrder
使用 @TestMethodOrder 注解 所提供的 @Order 注解 的目的就是:
为了保证测试用例执行的顺序,确保测试过程中按照人为预设的步骤执行得到预期的结果。【用例之间存在关联关系】
下面我们再通过 @Order 注解 来制定顺序
虽然这个例子举的不太好,但是意思get的到,就OK。
4、测试套件 - Suite
目前,我们一次最多启动一个类中的 测试单元。
现在我们想把 junittest 包中的所有测试类都执行起来,我们该怎么做呢?
这就需要借助到 测试套件了。
第一种方法:@Suite && @SelectClasses
@Suite【表示被注解的类是套件(类)】 && @SelectClasses【指定需要执行测试的类文件】
上面只是选择额一个类,下面我们来选择多个类文件。
虽然我们可以一次执行多个类文件中的 测试单元。
但是,还是存在一个致命问题:
如果我们想一次性执行 几十个类文件中的测试单元,那就太麻烦了(低效)。
第二种方法:@Suite && @SelectPackages
既然选择类文件的方式太低效了,那不如我们直接选择包。
我们可以看到有几个测试类没有被执行。
这是因为使用指定的包来添加套件的前提:
1、所有类文件的命名都要以 Test、Tests 结尾。
2、所有的测试单元都要使用 @Test 注解
5、参数化
我们前面写的测试单元(方法)都是不带参数的。
下面我们来写个示例,通过这个我们来了解参数化是什么。
那么我们该如何去写呢?
使用 @Parameterizetest 注解,标注方法类型为“参数化”.
在注明方法类型为参数化,同时需要强调参数的来源。
1、@ParameterizeTest(参数化) && @ValueSource(参数来源)
这里需要特别注意的是 @ValueSource 的使用。
下面我就来使用它们。【使用时候,在类型名称后面加上 s】
通过这两个注解,我们就能实现 参数化(批量测试)了。
我们可以发现 这两个测试方法是分开进行,而且都是只指定了一种数据类型【单参数】。
那么,如果我们想同时输出 name 和 i ,在一个方法里呢?【多参数】
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,涵盖了95%以上软件测试知识点,真正体系化!
由于文件比较多,这里只是将部分目录截图出来,全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频,并且后续会持续更新
如果我们想同时输出 name 和 i ,在一个方法里呢?【多参数】
[外链图片转存中…(img-xHOOa5r3-1715135297858)]
[外链图片转存中…(img-XrbUWj1a-1715135297858)]
[外链图片转存中…(img-27gBOV3s-1715135297858)]
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,涵盖了95%以上软件测试知识点,真正体系化!
由于文件比较多,这里只是将部分目录截图出来,全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频,并且后续会持续更新