时间旅行中的软件测试——当地时间的重要性

Question

作为一名软件测试人员，我遇到了一个关于在具有时间旅行的平台上进行测试的事件。 （时间可以根据测试需要手动设置过去/未来）

所以申请时间不必和我的当地时间一样......还是应该一样？

我发现了一个错误，这是由于我的本地时间和应用程序时间不一致造成的。简单描述：有两个验证。验证#1 验证客户端的用户输入（并使用本地日期进行验证），验证#2 验证服务器端的用户输入（并使用服务器日期）。两种验证都根据项目规范中指定的业务规则。 （它没有指定它应该在本地运行还是在服务器端运行）当这些日期之间存在不一致时，它会产生意想不到的结果。

但是，开发人员拒绝了这个错误，因为我的测试是错误的，并且同步这两个日期是客户的责任。

老实说，我看不出我的当地时间与应用程序行为有什么关系。有很多功能和规则，所有这些都使用服务器时间作为参考点。但是由于客户端验证是由 javascript 完成的，所以参考点是本地时间（因为它是默认行为，所以不是故意的）。

所以我只是在询问您的意见。你认为这是一个错误还是我对当地时间的重要性的理解不好？你是如何在你的项目中处理这些事情的（作为测试人员或开发人员）？这不仅仅是测试和服务器时间旅行的问题，还有客户端“时间旅行”呢？ （例如，不同的时区）。您是否付出了任何努力来处理这些事情，或者只是相信“糟糕的本地时间=客户问题”并且这不是开发问题？

Answer 1

一般来说，这将真正取决于您的应用程序、它的作用以及需要什么。但是，作为最佳实践，“应用程序时间”始终是 UTC。作为另一个最佳实践，永远不要相信客户时间。最终用户的计算机时间完全关闭或不同步的原因有很多。

在我使用过的几乎所有应用程序中，我们都将应用程序服务器设置为 UTC。对于最终用户，我们让他们设置他们的时区，我们用它来确定时区偏移量。因此，例如，如果最终用户选择“东部时区”，我们会将该设置与 -5 小时偏移量一起存储（为简洁起见，忽略夏令时）。如果您没有将用户设置存储到数据库中，您仍然可以通过客户端首选项屏幕或通过 javascript 自动获取他们的时区。但关键因素是忽略他们的时间，而只是获得他们的时区/偏移量。然后您将该时区发送到服务器，以便您可以使用服务器的准确时间翻译时间。这样一来，您始终拥有准确的服务器时间，然后是对用户本地时间的引用，您可以将其用于报告、逻辑或显示值。

所以回答您的问题：在大多数情况下，需要考虑糟糕的当地时间，这将是您的问题。最终用户不会检查他们的时钟以确保它们准确无误，他们希望您的应用程序能够在没有 IT 人员维修的情况下运行。