前言

断言assert是测试框架的重要组成部分。本篇介绍断言的各种类型，结合测试框架介绍3种断言工具。
//TODO:自定义断言
//TODO:预期结果

断言简介

在《xunit pattern》中提出了“四阶段自动化测试“，即一个最简单的测试用例可以由如下图所示的4个步骤组成。

image.png

断言主要应用在xUnit“四阶段自动化测试“中的第三步-验证(verify)阶段。即对于执行完成SUT某项指令之后，来验证其状态，或者执行的结果。

断言01- 三种断言工具:Junit原生、Hamcrest与AsserJ比较

本小节将简要介绍Junit原生、Hamcrest、以及AssertJ这三个不同时代的经典断言工具。这三个工具可以在不同类型的测试中使用。另外，很多专用自动化测试工具，如RestAssrured等也倾向于自带断言。在了解了经典断言工具后，对于了解这些专用工具自带的断言也更有益处。

Hamcrest

Hamcrest 属于”新一代”的断言工具，Hamcrest这个单词是”matchers”的变位词。它提供了大量丰富的匹配器，能够让断言可读性更高，断言样板代码量更小，更易维护。Hamcrest一经问世，就取得了非常大的成功，甚至一度成为第一个被Junit引入的第三方包，成为Junit4断言的一部分[1]。另外，Hamcrest也开发出了其他语言的版本，如C++, C#, Objective-C, Python, ActionScript 3, PHP, JavaScript, Erlang, and R。

当然，由于以AssertJ为代表的“新新一代”断言工具的出现以及蓬勃发展，Hamcrest又被移除出了Junit5[2], 让测试框架的使用者们可以更加自由的选择断言工具，促进Junit生态圈的发展。

AssertJ

AssertJ与之前的断言工具的最大不同，是引入了流式断言(Fluent Assertion),让断言的编写更加流畅，可读性更强，从而让它大获成功。它甚至还提供了一键转换的工具，将传统的Junit Assert断言转换为AsserJ断言。

Hamcrest与AssertJ比较

热度

首先来比较一下Hamcrest和AssertJ的热度。

image001.png

Hamcrest在2007年7月首次登陆Maven中央库，最近一次更新则在2012年7月，而AssertJ则在2013年登陆Maven中央库，截至本文写成的2018年8月，当年度已经发布3次。两者均录得了累计超过4000个项目的引用，在Maven中央库的历史排名均处于40位之内，属于明星项目。顺便说一下，Junit以超过7万个项目的引用成为最受欢迎的项目，而TestNG则以6000多次的引用排在20多位，两者差距非常明显[3]。

简要比较

以下是笔者整理的Junit Assert、Hamcrest以及AsserJ的简要比较。

关于AsserJ的具体使用，可以参考其官方提供的项目

https://github.com/joel-costigliola/assertj-examples

1 Marc Philipp (21 Oct 2012). "Summary of Changes in version 4.4". JUnit documentation. Retrieved 20 Sep 2016.

https://github.com/junit-team/junit4/blob/master/doc/ReleaseNotes4.4.md#summary-of-changes-in-version-44

2(https://en.wikipedia.org/wiki/Hamcrest#cite_ref-3) "JUnit 5 User Guide - Third-party Assertion Libraries". Retrieved 11 May 2018. https://junit.org/junit5/docs/5.0.0/user-guide/#writing-tests-assertions-third-party

3 http://mvnrepository.com/popular

4 https://joel-costigliola.github.io/assertj/assertj-core-converting-junit-assertions-to-assertj.html

断言02-断言变体

除了应用于Verify 阶段的断言，还有如哨兵断言、delta断言等不同的断言形式。

1）哨兵断言

这是一种让测试用例快速失败的断言，一般存在于用例的前部，甚至是setup阶段，或者是底层的测试框架中。
如何判断需要使用这种类型的断言呢？ 当测试用例中出现了if这样的判断来决定测试用例的执行路径时，就需要考虑是否引入哨兵断言了。这样就可以在测试用例用引入测试逻辑。

image.png

典型的案例是，在UI 自动化测试中，往往会首先判断一下某个页面的标志性icon是否存在，如果存在，则继续执行该页面下的操作。
另外一种场景是，在通过API接口进行业务场景自动化测试时，我们会假设协议层通讯正常，request/response可以正常发送和接收。业务的结果，无论正确/错误，都在更上层的response中体现。
如HTTP restful的接口，其HTTP状态码（HTTP Status Code）应该都是200,表示消息传输正常。
因此，我们可以在测试框架的通信层首先对状态码进行断言，保证协议层的通信正常，然后再将返回的body交由上层代码进行处理。
一个简单的示例如下：

@Before
    public void setUp() {
        RestAssured.baseURI= "http://192.168.1.119";
        RestAssured.port = 8080;
        RestAssured.basePath = "/service/v1";
    }

    @Test
    public void testUserLogin() {
      expect().
        statusCode(200).
        body(
          "success", equalTo(true),
          "userInfo.userId", equalTo("admin"),
          "userInfo.firstName", equalTo("admin"),
          "userInfo.lastName", equalTo("admin"),
          "error", equalTo(null)).
        when().
        get("/user/login?userName=admin&password=abc");
    }
//为简单起见，该案例直接将body信息进行了验证。

如果有需要，如每个用例均需要完成的哨兵断言，甚至都可以考虑放进setup方法中进行，便于重复使用。

2）Delta断言

Delta断言让我们有机会脱离SUT的具体状态来进行验证。
如在某个测试用例中，测试用例需要验证转账1个亿的准确性。因此，我们可以通过验证该账户转账前后的资金差异来确定结果是否准确。如以下的伪代码

    @Test
    public void testBalance() {
      long balanceBefore=api.queryBalance();
      api.trans(1，"aaa","bbb");
      long delta = api.queryBalence() - balanceBefore();
    assertThat(delta).isEqualto(1);
    }

采取这种方式的好处是，我们可以不必要知道，或者验证该账户在转账前后的具体资金是什么。
如果没有采用delta验证，而是直接验证转账(前)后的该账户资金余额，那么则要求该测试用例需要严格控制上下文，保证每次执行该用例时，系统账户的金额处于预期的状态下。

    @Test
    public void testBalance() {
      long balanceBefore=api.queryBalance();
    assertThat(balanceBefore).isEqualto(123456789);
      api.trans(1，"aaa","bbb");
       assertThat(api.queryBalance()).isEqualto(123456788);
    }

读者一定也会发现，这样的用例对于系统的环境控制要求较高，如果该用例执行时，系统没有将该账户余额正确设置为初始值，用例就会在第一步失败。
或者其它用例中也用到了该账户进行了转账/入账的操作，并没有及时复原（如reset数据库）的话，由于用例间的潜在数据依赖关系，导致用例也会执行失败。

断言03-验证方法

对于结果验证来说，至少有两种方法可以选择。

1. 直接验证返回结果
   如前一小节中转账的案例，

    assertThat(api.trans(1，"aaa","bbb")).isEqualto("OK");

通过直接验证方法的返回值，可以对结果进行直接验证。

2）间接验证
在前一小节的转账案例中，笔者通过查询账户在转账前后的余额来对结果进行验证。这种不对被测对象（转账接口）进行直接验证，而通过间接方法进行验证的方式，也是测试过程中常用的方法。
在传统的带有数据库的系统中，测试人员也非常习惯于在前台操作完成后，到系统数据库中通过编写SQL的方式进行查询验证结果。
这是因为，一个接口的调用，除了完成返回值之外，可能会产生多个后续的动作。

image.png

这些后续的操作，也可以作为验证的对象。
就转账而言，转账成功后，该用户的账户余额会发生改变。另外，如果设置了当日转账限额的话，该限额也应该会被更新。
就系统自身而言，还可以延申到数据库表的记录更新、日志系统的记录等等。
在金融系统中，如果涉及到了资金的变化，一般建议除了直接返回值进行验证之外，应该尽可能地通过间接验证地方式对系统进行测试验证，尤其是如当日转账限额等隐含更新的数据。在实际地工作中，这些也是出现过漏测缺陷的教训的。

断言04-预期结果

这一部分主要关注验证(Verify)时的预期结果的问题。当谈到预期结果时，经常会 联系到test oracle。根据维基百科，test oracle是以下这个意思：
In computing, software engineering and software testing a test oracle, or just oracle, is a mechanism for determining whether a test has passed or failed.[1] The use of oracles involves comparing the output(s) of the system under test, for a given test-case input, to the output(s) that the oracle determines that product should have.
在测试设计中，除了关于预期结果的具体内容之外，还关心
1）验证结果的范围
2）验证结果如何产生
3）可否自动生成预期结果

测试结果获得的复杂性比较

在UI自动化测试中，根据笔者的经验，由于在界面上获取数据的复杂性，往往会简化验证范围。如新建用户的场景，往往只会验证创建过程的完成（如出现某个提示icon)或者是简单在用户列表中能查询到该新建用例的用户名，亦或者通过delta断言比较系统用户数量+1。如果通过一个页面上的表单来逐个获取一个用户的10个属性，来和预期结果进行比对，是非常不经济的行为。
而在接口测试等较为底层的测试中，结果往往可以通过返回值的方式获取到，如一个数据库或者用户信息接口的查询，即可完整获得上述10个属性值，并和预期结果进行比较。这也反映出了底层测试更为经济和高效。

全面比较的必要性和成本

由于UI自动化中获取数据的复杂性,测试人员经常会选择只对部分关键信息进行断言。而在API自动化测试中，虽然数据的获取成本大为降低，但是由于接口返回值的字段往往较长，人工逐个编写预期结果也往往费时费力，测试人员也经常选择只对一些关键信息进行断言。希望既能保证测试结果的正确性，又能保证一定的设计和执行效率。
然而在实际的测试实践中，笔者所在团队也发生过因为预期结果不够丰富，导致了某个缺陷遗留到线上的问题。后来经过缺陷根因分析，发现
1）该测试场景虽然在分析时没有考虑到，但是在设计用例时，其实已经触发了该缺陷，或者说其实该场景已经覆盖到了。
2）测试人员在编写预期结果时，只校验了和测试场景直接相关的字段，对于返回结果中与缺陷相关的字段没有校验。从而产生了漏测缺陷。

预期结果的动态生成 （runtime assertion )

在之前的案例中，所有的预期结果，无论是人工编写的，或者是通过运行生成的，在下一次的测试用例运行之前，这些数据都是已经确定的。
在金融系统中，基础数据是经常变化的。在之前的一篇关于 数据管理的文章 中提到了动态数据的问题。如果希望能一次编写用例，可以在不同的基础数据环境中运行的话，就需要运用动态数据，通过运行时查询和基础数据衍生等方式，来生成测试用例的入参和与之配套的预期结果。
目前我们在线上冒烟测试系统上采用了这种方式。当然，由于入参和预期结果之间的关联算法其实比较复杂的，甚至可能是业务的一种简单实现。开发和维护这些算法的成本也是比较高的。这也阻碍了这种测试方法在功能测试中的大规模使用和推广。