问软件的测试时间不能太长，但是软件需要经过彻底的测试才能商业化。

EN

在开始测试过程之前，您应该了解测试的主要原则。

https://www.guru99.com/software-testing-seven-principles.html

1. 测试显示存在缺陷
2. 彻底的测试是不可能的
3. 早期测试
4. 缺陷聚类
5. 农药悖论
6. 测试与上下文相关。
7. 无错误谬误

这个最重要的

曾经是:

详尽的测试是不可能的，并且没有错误谬误：

不能在代码流百分比下进行测试。在测试产品时，您应该专注于业务需求而不是功能，这将确保涵盖和测试最重要的工作流。这确保了“不存在错误谬误”，这意味着您不会发布没有所需功能的产品。

早期测试：

您需要确保有一个“测试金字塔”，将左移的方法移到像单元测试、集成测试、系统测试等早期测试的地方。

有适当的单元测试，集成测试等，显示了什么失败了，并迅速。因此，它方便了更快的反馈。

如果只有系统测试，那么开发人员应该浪费时间调试，并重新测试它是UI错误还是后端错误，哪个组件失败了等等。如果您有适当的单元测试，那么它就会突然失败，并显示出故障所在，这样您就可以节省反馈和重新测试时间(时间是生意上的钱)。

测试与上下文相关：

每个测试策略和方法取决于预算、团队、产品、团队规模等技能。

现在回到你的问题：

我知道黑匣子测试可以更快，但是我们如何减少白盒测试的时间?测试？

“白盒”测试是关于了解应用程序内部结构的知识，这只是一个额外的信息，您可以使用它来编写更有趣的测试用例。它并不比黑匣子慢或快，因为它不是测试过程，而是关于对产品的理解。

白盒测试通常由“单元测试”覆盖，这里我们没有看到整个代码库，而只是每个组件的代码库。组件可以是类或函数。

在这里，我们只是验证我们实现了大约100%的分支和语句覆盖。如果我们没有达到所需的覆盖范围，我们就会失败。这确保为每个组件测试所有最坏的、平均的和最好的情况。

如何减少白盒测试的时间？

1. 编写更多单元测试
2. 在您的系统架构中有正确的“坚实”原则，并实现单元测试和覆盖度量。
3. 自动化
4. 左移，进行早期测试，如静态代码分析、单元测试等。

因此，软件的测试时间不能太长，但是软件需要经过彻底的测试，然后才能通过实现商业化。

1. 自动化测试活动
2. 有代码和分支的覆盖率阈值
3. 有静态代码分析
4. 早期测试
5. 涵盖所有业务需求
6. 将安全性、性能等集成到构建管道左侧的DevSecOps方法
7. “知道”详尽的测试是不可能的，但是可以通过对所有业务流程、回归阶段、安全性和性能进行适当的自动化覆盖来建立对产品的信心。

测试的核心是一个简单的事实:测试只显示缺陷的存在--它不能证明没有缺陷。

因此，我们通常采用多层方法.

• 静态代码分析
• 动态白盒(“单位”)测试
• 动态黑箱(“系统”)测试

但是我们如何减少白盒测试的时间呢？

1. 首先，计划测试活动(S)-尽早开始。通常情况下，测试会一直拖到很晚，并且没有足够的时间。
2. 其次，单元测试需要单元测试，然后只在需要重做的时候重新进行单元测试。
3. 第三，并与之相联系，看看你的模块化，这样“单位”是独立的.每个功能/过程服务于一个功能，从而允许单元测试被聚焦。
4. 最后，在它可以帮助的地方自动化。不要浪费时间使一次性测试自动化，而是要自动化重复的测试。
5. 适当的工具不仅在测试中，而且在相关的度量中都会有所帮助:例如，在显示测试覆盖率方面。

大部分时间，在计划测试时付出的努力是多方面的.但是(就像老生常谈的那样)，没有计划就是计划失败。