全面的系统测试策略

全面的系统测试策略

我们的团队最初称这些测试为“UI测试”，直到我们更多的项目和更多的整合策略。其中输入我们的系统的不是一个浏览器，而是消息，一个REST端点，或FTP下拉菜单，批文件的处理。UI测试是全系统测试的子集。一个完整的系统测试背后的想法是,我们想要测试我们的软件,因为它可能会用于生产。对于一个MVC应用程序,这些将是基于浏览器的测试。对于批处理文件,我们将使用实际的文件。REST中，是实际的HTTP请求。消息，是真正的队列和消息。

在产品上线前，如果我们想知道应用程序能否按照预期运行,一个有效和高效的方法是创建一个自动化的测试,测试完整的系统。如果我的基于UI的测试可以登录应用程序，并下订单，然后可以验证是否生成一个订单。我感觉是一件很不错的事情。

有关完整的系统测试中一个常见的误解是，他们是黑盒测试。他有自身的特点，全系统测试要求必须能了解系统内部发生了什么。实际上，全系统测试甚至可以采用领域模型来构建数据，而不是通过纯粹为了测试的系统后门来创建测试数据。团队中常犯的错误是，不按照与产品实际应用一直的路径来测试代码，导致系统处于奇怪的、失效的和无法处理的状态。

在我们的项目中，全系统测试时我们生成一个特性/用户故事完成之前所写的最后的代码。手工测试的成本太高，而且也无法可靠地验证一个特性已完成。但如果我可以通过外部接口来验证产品实际使用时的操作，这是成功的。

整体策略

对于一个待测系统，为了提高覆盖率，我们发现最有效的测试策略是从全系统测试开始，逐渐深入到单元测试。首先使用宽松的但是简单的断言，然后逐渐深入单元级别的逻辑。对于一个新的应用程序，我们倾向于不只是关注一个区域，对于一个长期维护的系统来说，所有的测试都是很重要的。

我们这种测试策略确实需要一定程度的投入。当知道这个应用程序对于客户的业务来说至关重要时，我们发现这种整体策略是非常有效的。如果应用程序是关键业务, 它定会发生变更，如果发生需求变更，我们最好能安全的实施变更，而不会影响我们的客户的业务。