认识达内从这里开始

我们在前几期的文章中给大家简单介绍了无服务器编程开发的一些基础知识等内容，而本文我们就继续来学习一下，无服务器编程测试需要解决哪些问题。

我到目前为止所讨论的所有关于无服务器工具的话题，我认为落后的是测试工具。值得关注的是，无服务器方案较传统解决方案来说有着相当大的测试优势，主要是两点，(a).无服务器计算的各个功能的单元测试很成熟，(b).无服务器服务写的代码更少，并且至少在单元测试层面，只需要做简单的测试。

但是这并没有解决跨组件功能/集成/验收/业务流程等测试问题。无服务器计算时我们的逻辑是分散在几个函数和服务内的，因此，更高级别的测试甚至比使用接近单一方法的组件更重要。当我们如此依赖于在云端基础设施上运行时，我们应该怎么做呢?

对于我们来说，测试可能是没有看清楚的。我猜测未来基于云端的测试会变得很普遍。这一部分会变得更加容易部署、监控，以及调试我们的无服务器apps，甚至于比我现在描述的这些原因更加丰富。

换句话说，为了运行更高级别的测试，我们将会部署整个生态系统的一部分到云端，并且对部署在那里的组件执行测试用例，而不是针对部署在我们自己开发机器上的系统运行测试用例。这种做法有一定的优势：

执行部署在云端的组件的真实度较本地模拟来说更高。

我们较过去，更有可能可以运行高负载/高丰富度数据测试。

生产环境数据源的测试组件(例如，一个发布订阅模式的消息总线，或者一个数据库)会更加容易，虽然显而易见我们需要关注能力/安全问题。

但是这种解决方案也有弱点。先，执行测试的周期时间很有可能由于部署和网络延迟而相应增加。其次，当网络连接中断以后，我们就不可以继续运行测试用例了(例如，在飞机上)。后，因为生产环境和测试环境终部署方案很相近，我们也需要格外小心，当我们打算改变测试用例时，不要发生不小心改变了生产环境的事故。如果我们使用AWS，我们可能需要通过类似于IAM角色这样的工具安全地部署，或者对于不同类型的环境使用完全不同的账号进行部署。

测试并不仅仅是一个二进制程序运行成功或者失败，我们也想要去弄清楚测试是如何失败的。我们应该可以调试本地运行测试和正在运行的远端组件，包括可以单步调试一个运行在AWS上的Lambda函数，因为它可以相应测试。所以所有的远端调试，例如，我前面章节提到的工具也需要测试，而不是仅仅交互式开发。

请注意，我并不是基于这些暗示我们的开发工具需要运行在云端，也不是测试本身需要运行在云端，虽然两者将来都会或多或少地走到这一步。我只是表示正在测试的系统仅运行在云端，而不是一个非云端环境。

使用无服务器作为测试驱动环境可以收获有用的结果。一个例子被称为“无服务器火炮”，这是一种负载测试工具，由运行着的许多并行的AWSLamdbas组成，执行即时、廉价、易于扩展性能测试规模的负载测试用例。

值得指出的是，在某种程度上，我们避免了一些失误。由于技术进步，传统的高层及测试实际上正在变得不那么重要，例如(a)生产环境测试/使用监控驱动开发，(b)平均解决时间(MTTR)的显著降低，(c)基于持续部署。对于许多的无服务器apps应用广泛的单元测试，度量业务水平的生产环境监控&预警，以及一个专用于减少MTTR和基于持续开发的方法，都将会是有效的代码验证策略。

【免责声明】本文系本网编辑部分转载，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与管理员联系，我们会予以更改或删除相关文章，以保证您的权益!更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销，赚更多好礼。