对于没有测试环境的项目，我们需要遵循什么方法？

#1 楼

这取决于您遇到的限制类型。您可以提出虚拟化。这样一来，您可以在一台主机中运行多个环境。您也可以使用容器化方法，即使用同一台主机，但可以通过有效的计算资源隔离来隔离实例。这两个选项都需要一些不平凡的工作来设置所有内容。

如果您没有能帮助您进行设置的熟练人员，则可以选择以下方式之一：


减少花费的时间通过测试自动化进行回归测试
鼓励您的开发人员通过单元测试来涵盖其功能
鼓励您的架构师（或扮演架构师的人）以功能更多或更多的方式设计您的应用彼此之间的隔离度较低（例如微服务架构），因此开发一项功能将对正在测试的功能产生较小的影响
根据计划安排测试的时间，以便进行质量检查和开发测试会话。开发人员通常不需要他们的环境持续在线。因此，您可以就使用环境（某些较长的会话）和何时使用该环境（某些较短的会话）达成一致。

#2 楼

如果您当前的敏捷实践和方法是：


某些项目是敏捷的，客户的持续反馈将不断到来，如果开发人员也处于测试阶段，则开发人员也需要对其进行处理。因为项目的截止日期太短了，客户也不会延长截止日期。


那么你就不是敏捷的了

尽管敏捷的确依赖于根据来自客户的快速，即时反馈，如果误用了这些反馈，并将其转变为“需要立即应用的，来自客户的持续反馈”，而这绕过了敏捷开发过程，它不会“使”您敏捷。在敏捷的商店中，如果您花时间在架构良好的设计和测试的系统上，则可以在几分钟之内将概念付诸实践。这是橡胶为您提供的所有良好实践之路。它们在理论上可能听起来不错，但要实现其吹捧的好处，必须实际应用它们，这很难。

敏捷意味着您以不同的方式开发软件。这并不意味着高成本，昂贵的设备或额外的服务器。

我建议您专注于：


了解有关敏捷开发的更多信息
了解有关TDD的更多信息
了解BDD的更多信息
了解Scrum的信息
了解看板的信息
了解敏捷测试金字塔的信息
了解敏捷测试象限的信息


“项目的期限太短，客户将不会延长期限。”在过去的50年中，一直是开发软件的挑战。您的责任是教育客户或其代表有关质量测试的含义。如果他们拒绝交谈，我建议您寻找其他客户。如果您继续与该客户保持联系，并且不改变方法，随着时间的流逝，它只会变得越来越糟。

关于成本的另一个说明-您可以并且现在应该-为您的环境使用云服务，并每天为测试环境支付几美元-甚至几美分。

#3 楼

您提到即使在sprint之内，也有从开发到测试的过渡。
团队是否愿意做配对工作？在sprint的早期与开发人员坐下来，讨论他们正在创建的单元测试，可能运行的测试，并让他们解释他们如何理解并实现故事功能。

我听到的另一个想法（我意识到并不是纯粹的敏捷）是在sprint结束后的2或3天内“冻结”的想法。因此，如果您有10天的冲刺，假设第8天和第9天的代码是“冻结的”，则可以进行一些测试。剩下的第十天是开发人员可能需要做的最后修复。丑陋的，是的。但是，最终，这是要利用当前拥有的资源为客户做到最好。

#4 楼

尽可能尝试与开发人员合作。尽早加入生命周期。您可以先满足需求，然后提供测试用例。然后与开发人员一起审查。也可以为开发人员单元测试提供输入。与开发人员共享您的测试方案，并尽量减少错误。在测试期间，您还可以进行配对测试
，即使在开发环境中进行测试时，也可能必须持有其他开发人员的其他版本，除非测试完成

至少在不同的说明中对于只有少数几个项目的专用测试环境，当您拥有测试团队时，这些就像非常关键的基本事情