项目即将完工。是时候开始测试了。哪种方法在开发周期结束时是可行的？

Question

让我们假设一个项目在其开发周期结束时加入项目。该项目已经在许多团队中得到了传播，并且在整个过程中都没有进行任何测试。这个团队中的其他成员不知道测试（羞耻！），并且单元测试每个方法在这一点上似乎都是不可行的。

除了可用性测试之外，此时测试产品的推荐策略是什么？这通常是您手动点击预期输出/实际输出工作的原因吗？

Answer 1

我通常采用自下而上的方法进行测试，但我想在这种情况下你想要自上而下。测试最大的组件，你可以包装单元测试，看看它们是如何失败的。那些失败应该指向哪些子组件需要自己的测试。

。完成后你会有一个非常不稳定的测试套件，但这是一个开始。

Answer 2

如果您有预算，请获取测试自动化套件。 HP / Mercury QuickTest是这一领域的领导者，但价格非常昂贵。我们的想法是通过用例驱动GUI来记录宏等测试用例。您在表单（web，.net，swing，几乎任何类型的GUI）上填写输入，引擎学习表单元素名称。然后，您可以在GUI和数据库中检查预期输出。然后，您可以插入各种测试输入的表格或电子表格，包括失败的无效情况，如果您愿意，可以运行数百个场景。记录测试后，您还可以编辑生成的脚本以对其进行自定义。它最终会为您构建一份简洁的报告，向您显示失败的确切内容。

还有一些便宜且免费的GUI自动化测试套件，它们几乎完全相同但功能较少。通常，套件越贵，手动定制就越少。查看此列表：http://www.testingfaqs.org/t-gui.html

Answer 3

我认为这是一个良好的质量保证测试的地方。写出老式的测试用例并分发给团队中的多个人进行测试。

Answer 4

  

除了可用性测试之外，此时测试产品的推荐策略是什么？

我建议知道（或可以开发）产品功能规范的人/人进行代码检查。

一种极端的，纯粹的方式就是说，因为它“一直是一个完全免费的，没有任何测试”，因此人们不能相信任何一个：不是现有的测试，也不是代码，也没有开发人员，也没有开发过程，也没有管理，也没有关于项目。此外，测试不会增加软件质量（必须内置质量，开发过程的一部分）。拥有优质产品的唯一方法是打造优质产品;这个产品的构建没有质量，因此需要重建它：

• 将现有源代码视为一次性原型或文档
• 逐个构建新产品，可选择合并旧源代码的合适片段（如果有）。

但是，进行代码检查（以及纠正通过代码检查发现的缺陷）可能会更快。这将是功能测试的补充。

您是否不仅要测试它，还要花费额外的时间来开发自动化测试取决于您是否想要维护软件（即，将来，以任何方式更改它）然后重新测试它。）

您还需要：

• 或者：
  • 功能规范（和非功能规范）的知识
  • 有线索的开发人员和/或QA人员
• 或：
  • 一个小而简单的产品
  • 耐心，宽容的最终用户
  • 产品交付后继续提供技术支持

Answer 5

在生命周期中此时进入项目时，我在开发实践中融入的一种技术是在报告缺陷（QA或最终用户）时添加单元测试。您将无法获得现有代码库的完整代码覆盖率，但至少可以通过测试来驱动和记录未来的开发。另外，在执行实现之前，应该确保测试失败。如果您编写测试并且没有失败，则测试有问题。

此外，在向系统添加新功能时，请启动具有测试的功能，以便至少测试这些子系统。当新系统与现有系统交互时，尝试在旧边界层周围添加测试并随着时间的推移逐步完成。虽然这些不是单元测试，但这些集成测试总比没有好。

重构是测试的另一个主要目标。没有测试的重构就像在没有网的情况下走一条紧绳。你可能成功地到达另一方，但风险值得奖励吗？