有了这样的东西，这是巨大的并且没有预先测试，我想说你的首要任务是探索（很可能是手动），以收集信息并确定为其构建回归的最佳方法。

我会这样处理：

1. 手动探索，专注于独立的功能集群和可测试的材料。我要寻找的一些东西包括数据验证（如何处理它们，是否需要在多个级别进行测试，例如 web-front、数据库等）、模块之间的接口、通用导航和流程、区域符合 80/20 规则（80% 的用户将使用 20% 的应用程序）。
2. 优先考虑模块/功能集群/流程流（取决于您的应用程序的性质，其中任何一个都可能是您的回归测试用例最明智的基础——我经常使用销售点软件，因此基于“销售”的流程流某事”是我最常见的测试用例） - 您可能希望与主题专家合作来确定这一点。还要寻找自动化时间回报最大的领域。不管自动化会有很大的前期成本，所以选择高优先级的测试用例是一种策略，它们是 a) 任务关键型，b) 自动化相对简单，c) 具有高回归风险是一种制定策略的方法（以我的经验为例——我测试的软件必须支持多个不同国家的税收规则。简短的税收回归自动化在两个独立的自动化项目中运行，总共运行 16 小时。同样的回归会消耗 5 名测试人员一个多星期的时间，而且准确度要低得多——但是构建和生成准确的基线需要很长时间，这纯粹是痛苦的。也就是说，它经常拯救我的培根，值得每一分钟的开发）。
   1. 选择一个对您正在使用的应用程序有意义的工具。有许多优秀的 Web 应用程序测试工具，但考虑到应用程序的大小和 PHP 的使用，我猜还涉及其他接口，例如数据库。您希望您的工具也可以访问它，以存储测试数据（读取文本文件也适用于此。我正在使用构建在 CSV 文件中的关系数据库形式的测试工具，以及它的数据存储在 CSV 文件中拥有自己的关系数据库）。如果它可以可靠地满足您的需求，那么任何工具都是好的——但您需要确保您（以及其他相关人员）知道如何使用它。
   2. 依次在每个模块中混合探索性测试和自动化测试的构建，从最高优先级开始并逐步进行。

最重要的是，确保与您一起工作的每个人都知道这不会快速、简单或便宜（如果只是在时间投入方面）。您需要确保与您一起工作的人知道随着复杂性的增加会产生更多的测试和自动化时间。

祝你好运！

1 亿（代码？行？还是别的什么？）而且网站根本没有经过测试？

您应该首先考虑一些手动功能测试。如果您甚至不确定该站点是否正常工作，那么查看自动化是没有意义的。

你知道要求吗？是否至少清楚该网站应该做什么？

好吧，你在为谁测试它？

一般来说，他们想知道什么？根据您为他们找到的信息，他们会做出什么样的决定？

你有什么神谕——即你可以用什么来帮助你理解什么时候你可能会遇到问题？不要太拘泥于“要求”——如果它从未被测试过，那么我怀疑你有任何要求。横向思考——你可以利用产品所有者、用户或支持人员等人，你可以询问他们想要的行为、帮助指南等文档、与竞争对手网站的比较（行业标准）等等。

您还有其他人可以帮助您进行此测试吗？是否有任何工具可以帮助您，您有哪些可用的测试环境（如果有）？

您的客户希望在多长时间内获得此信息？以及以什么形式？多久一次？如果他们不太确定，您可能会建议您尽早给他们一份样本报告，然后他们可以弄清楚他们喜欢和不喜欢什么并让您知道。

测试是一种调查：如果您不知道您的客户想要什么，或者更糟糕的是，如果您的客户不知道他们想要什么 - 您几乎没有希望为他们提供有用的信息。首先弄清楚你的任务：我使用自己的助记符来帮助指导我的问题，SORT（范围、预言机、资源、时间）——你可能会注意到我是如何组织上述问题的。如果客户以前从未有过任何测试经验，您可能需要通过建议选项来指导他们一点。无论您做什么，都必须确保您定期与他们一起回顾以确保他们仍然满意。

对于任何测试项目，您都应该从发现此类信息开始。如果你有，请告诉我们。如果你没有它 - 去找出来！（一旦你了解了一些，你就可以开始测试——这可能是一个渐进的过程，你可能会发现越来越多，但如果你不知道以上任何一个，你应该和你的客户。）

您（或更好的应用程序所有者）应按优先级将应用程序拆分为功能区/功能。适当地组织你的测试，这使得它们更容易维护。测试类型取决于应用程序本身。使用自动化测试来测试某些应用程序行为会更有效（尤其是在计划不时重复测试时）。但是可能有一些 Web 应用程序功能无法通过自动化测试进行有效的测试（很难为其编写自动化测试，或者需要很多时间）。所以在现实中经常使用混合测试风格。您选择哪种自动化测试框架取决于您的个人经验和需求。