问什么时候才是为任何长期运行的项目启动测试自动化的合适时间？

EN

20%的功能提供了80%的价值。如果您交付的小块，希望人们可以开始使用最有价值的功能后，头2-3个月已经。现在你可能会有一个范式的转变，也许你将不需要两年的想象中的特性。假设企业主获得了新的洞察力，并在功能上做了一个小小的转变，但是您想继续使用已经交付的功能，如何确保您没有破坏任何功能呢？手动回归测试？

我总是建议从项目一开始就开始测试自动化。以测试驱动开发的形式，测试第一方法越来越普遍。每一个特性我都会写：

• 很多单元测试
• 几个集成测试
• 一条幸福之路--端到端测试
• 一次负端到端试验

在测试社区中还有另一种观点。为仍然处于大量变化中的软件创建测试自动化，例如用户界面经常会发生变化，您应该等到UI稳定下来，因为重写您的测试非常昂贵。我认为这是一个错误的假设，来自于这样一种想法，即大多数(如果不是全部)自动化测试都是端到端的。开发和维护确实是缓慢和昂贵的。当开发人员没有低级测试自动化的经验，而测试人员只具有端到端测试自动化的经验时，就会发生这种情况。我认为这可能是在为开发团队收集技能时没有正确应用测试金字塔的结果。

我认为对于长期运行的项目，开发人员能够安全地重构他们的代码是很重要的。他们应该有信心对项目进行架构更改，以保持其可理解性和可维护性。为了能够在小的步骤中做到这一点，您需要大量的快速自动化测试。

有一个测试原则--尽早。因此，最好的案例--一旦产品的想法被大声宣布，就开始原型测试。时时刻刻。

从一开始就开始，并考虑在您的UI中使用BDD实践，这样您的自动化就可以与需求一起更新。首先要搜索最大的内容--您的最终用户的登录页面，他们将创建的主要数据条目。这种东西最不可能随着时间的推移而改变，两年后你就不想再试了！

如果您的应用程序涉及一个api，那么首先使用该api。这个部分应该首先稳定下来，有几个api自动化工具是简单而直接的--我认为邮递员是目前最流行的。