异步系统的两种测试方法

有志者，事竟成！如果你在学习数据库，那么本文《异步系统的两种测试方法》，就很适合你！文章讲解的知识点主要包括MySQL，若是你对本文感兴趣，或者是想搞懂其中某个知识点，就请你继续往下看吧~

互联网软件系统一直随着需求、用户量上升等等的原因在演进，以求适应更复杂的业务场景，更高的性能要求等等。软件演进方式各种各样，系统异步化即为其中一种。

一般的，对于那些实时性要求不高，但却计算密集或者需要处理大数据量的耗时较长的任务，或是有较慢 I/O 的任务，选择异步化是一个不错的选择。在系统层面，像引入消息中间件来解耦系统，将耗时长的任务放在中间件后异步执行。在方法层面，像把耗时较长的任务放到其他线程中去异步执行。

与测试同步系统或方法不同，当我们测试异步系统（端到端测试、集成测试）或异步方法的时候（单元测试），由于测试线程不会被异步任务线程阻塞而让测试变得不可控，概率性失败，以单元测试为例，这样写异步测试是不稳定的：

@Test
public void testAsynchronousMethod() {
    callAsynchronousMethod();
    assertXXX(...);  //异步任务可能仍未完成，这时assert可能会失败
}

异步任务的两种类型：

• 异步任务执行后对任务发起方或调用方有感知，比如发出一个事件或通知
• 异步任务执行后对任务发起方或调用方没有感知，只是改变了系统中的某些状态

对异步任务的测试也分以上两种类型讨论。对于第一种，我们可以采用

import org.junit.Before;
import org.junit.Test;

public class ExampleTest {
    private final Object lock = new Object();

    @Before
    public void init() {
        new Thread(new Runnable() {
            public void run() {
                synchronized (lock) {  //获得锁
                    monitorEvent();    //监听异步事件的到来
                    lock.notifyAll();  //事件到达，释放锁
                }
            }
        }).start();
    }

    @Test
    public void testAsynchronousMethod() {
        callAsynchronousMethod();  //调用异步方法，需要较长一段时间才能执行完，并触发事件通知

        /**
         * 事件未到达时由于init已经获得了锁而阻塞，事件到达后因init中的锁释放而获得锁，
         * 此时异步任务已执行完成，可以放心的执行断言验证结果了
         */
        synchronized (lock) {
            assertTestResult();
        }
    }
}

这里的前提是事件通知会到来并被监听到，可要是不来呢（比如异常任务执行失败了）？我们就干等吗，其实我们还可以在测试中引入超时机制，这也引出了第二种类型的异常测试（可以称之为

@Test
public void testAsynchronousJob() throws Exception {
    String msg = buildNsqMsg();    //构造NSQ消息
    nsqClient.send(TOPIC, msg, false);    //发送Nsq消息

    with().pollInterval(ONE_HUNDRED_MILLISECONDS).  //100ms后开始检查
            and().with().pollDelay(10, MILLISECONDS).  //此后每隔10ms检查一次
            await("description").  //描述信息
            atMost(1L, SECONDS).   //1s超时时间
            until(() -> xxxService.getState() == "changed");  //业务相关的断言逻辑
}

上述测试我们引入了 awaitility 工具类来做轮询操作，一个靠谱的轮询至少包含以下特性：

• 超时机制，不可能一直轮询
• 首次延迟轮询
• 轮询频率

最后，我们来讨论下测试结果可靠性问题。

假设一个异步系统采用轮询方式测试，触发异步任务后，当在两次轮询中间系统状态因为某些原因出现了抖动，下一次轮询时轮询方式可能会误以为异步操作还未完成或出现了异常，从而导致测试结果误判：

相对的，监听方式是不存在这样的问题的，只要系统状态改变，监听中的测试能立马感知到，并作出可靠的测试结果：

很多异步系统对外是没有回调的，这时候只能使用轮询方式测试异步任务，而轮询测试的可靠性取决于待测系统的可靠性。

可是，一个周期性执行的可靠系统同样会遇到上述问题，测试会因为代码周期性执行，系统状态周期性改变而变得不可靠。对于这样的系统，我们可以做一些可测性改造。将业务逻辑和周期执行逻辑剥离，并增加一个可以调用业务逻辑的入口，比如一个 restful 接口，这样测试时可以准确控制业务逻辑的执行时机和频率，也就可以可靠的测试了。

有赞已经在一些异步 Job 中采用上述轮询方式测试，我们在测试中主要碰到了两类 Job，一类是会和 Elasticsearch 搜索引擎交互的，由于 Elasticsearch 的刷新机制（有赞出于性能原因设置为 5 秒刷新一次数据），轮询方式因为测试时间太长而很局限，除非提高 Elasticsearch 的刷新频率；另一类则是跟 Mysql、Redis 交互的 Job，这类 Job 的测试可以工作的很好，测试基本可以在 150 毫秒内完成，也就意味着可以像普通测试一样置入持续集成的构建中了。

以上就是《异步系统的两种测试方法》的详细内容，更多关于mysql的资料请关注golang学习网公众号！