基本上我想知道是否有人有任何提示可以确保您的代码经过良好测试，而无需在有限的时间范围内从其他人那里获得任何帮助？
过去，我总是能够找到其他人对我的代码进行测试，或者让专门的质量保证团队检查所有内容并找出所有错误。
我通常很小心，但我总是会发现一些我想念的东西，当我测试它们时，我就是看不到它们。
然而，在我目前的工作中，我被要求在非常有限的时间内编写两个 PHP Web 应用程序，并且我被告知我需要自己进行所有测试，尽管我的反馈是这不是一个好主意。
我想知道以前是否有其他人遇到过这个问题并且可以提供一些见解？
我在想也许在对每个区域进行编码之前编写一个快速测试计划并在进行测试之前仔细检查需求可能会很好。
当然，单元测试，无论是否先测试，都应该是您的第一道防线，确保您的应用程序的每个部分都按照您认为的方式工作。但是，您正在谈论的测试类型，它可能有助于获得另一双眼睛，更多的是在验收测试领域 - 应用程序作为一个整体是否按其应有的方式工作？它是否适用于各种奇怪的场景或行为等？
一种有用的方法是想象人物角色：首先以您自己的身份测试应用程序，然后再次测试它，假设您已经 85 岁了，不能很好地看东西，并且不会使用鼠标。你可能倾向于点击最亮或最大的东西，假设它是你应该做的，但它可能不是。现在想象一下，你 12 岁，并且非常匆忙。你绝对不会阅读说明。它仍然有效吗？
对于任何给定的字段，一个人可能输入的内容的边缘情况是什么？如果只输入空格会发生什么？只有数字进入文本字段？如果你输入 HTML 会发生什么？Javascript？非西方字母表中的东西？如果你输入的东西真的很长怎么办？
关键不只是测试“快乐路径”，即用户按照您想象的方式浏览应用程序。以任何人都不应该的方式浏览应用程序。因为……他们会的。
另一个重要的部分是永远不要忽视任何事情。很容易出现一个奇怪的屏幕并对自己说“哦，这只是侥幸”。你必须让自己注意到并追踪所有不应该如此的事情。
你可以做多少测试总是有限制的。在约束范围内，您显然需要构建测试。显然，您希望首先为最关键的领域（安全性、损坏可能性、数据丢失、功能）构建测试。
除了功能规范之外，您不太可能获得大量手动帮助来决定测试什么。但是您可以通过测试覆盖工具的形式获得自动化帮助。这些工具告诉你你测试了哪些代码，因此你还没有测试过哪些代码。通过检查未经测试的代码，您可以确定它是否或多或少是关键的，因此或多或少值得在发布之前对其进行编码测试。测试覆盖率工具还告诉您测试代码与总代码的比率，这是确保该比率为 70% 或更高的行业最佳实践。您可以使用这些数据通过一个简单的技巧与您的老板协商更多时间：“我们只有 15% 的测试覆盖率……我们敢发布吗？”
可以在此处找到适用于 PHP 的测试覆盖率工具： 语义设计 PHP 测试覆盖率工具
我认为 TDD 正是您正在寻找的。首先编写测试，然后编写通过测试的代码。除了您之外，您不需要任何其他人（不过，建议对测试提供一些帮助），并且即使在开始编码之前，您也会更清楚地了解该工具应该做什么。
您的雇主显然不认为测试很重要。你应该辞职并找到一份合适的工作。
我不想这么说，但我认为在你的情况下 Alex Tingle 是对的。这是一个不可能的情况。
JacobM 和 Santi 在提到单元测试、验收测试和测试驱动开发方面是正确的。我会在该列表中添加代码覆盖率和静态分析工具。
但是，虽然 TDD 或基本单元测试通常会在减少测试时间、降低缺陷率和易于维护方面获得回报，但它们并不能帮助您在死亡行进中按时交付。如果您没有编写自动化测试的经验，则尤其如此。
礼貌地说，你的老板要求你承担技术债务。准确地说，他是在要求你无视职业道德。
微笑，说“是的，先生”，在分配的时间内尽力而为，并更新您的简历。
需要记住的一件事是，开发人员有一种自然的倾向来测试他们的代码的“最佳路径”。换句话说，你写了它，所以你知道你应该点击某些点，输入某些东西，然后你测试一下。这当然很重要。
这里有一些很好的建议，但大多数人（但不是全部）似乎都忽略了一个是负面测试。基本上，您需要测试边界并且需要测试恶意软件。如前所述，将脚本代码放在以下字段中：
<script>alert('abc')</script>
如果收到警报，很明显您未能正确编码！另一件事是：
abc' or 'a' = 'a'
这可能会在身份验证等方面显示 SQL 注入问题。您还可以使用以下方法测试 SQL 注入：
abc'; drop table users; select * from dual where 'a' = '
如果您的桌子刚刚消失，那么您就有问题了！有大量的示例，但至少您需要花一些时间来测试 OWASP 前 10 名。
您要测试的其他地方是非常大的数字，尤其是在 32 位平台上期望整数输入、负值、无值等时。基本上，测试所需的流程是否有效，然后尽一切可能打破它.
我同意之前发布的关于测试驱动开发和单元测试的价值和有效性的答案。如果做得正确，在编写生产/可交付代码之前编写单元测试的 TDD 过程将有助于保持专注并帮助验证您的设计和接口。此外，其他开发人员将能够以一种非常直接的方式从如何使用和使用您的代码方面获得清晰一致的工作方式。请记住，单元测试并不相同，并且不能替代完整的集成测试。在这种方法中，您可能仍需要编写完整的集成测试计划。
我主要在 .NET 中工作，并且在使用 NUnit 方面取得了不错的成绩。
我以前没有在 PHP 中工作过，但根据我所见，您可能需要考虑SimpleTest或 PHPUnit。
考虑到你老板的要求，你在为他工作时必须尊重，直到你改变他的想法，你已经在问题中给出了正确的答案。