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

Question

让我们假设一个人在开发周期即将结束时加入了一个项目。该项目已在许多团队中传递，并且总体上是免费的，整个过程中没有进行任何测试。该团队中的其他成员不具备测试知识（耻辱！），并且对每种方法进行单元测试在这一点上似乎不可行。

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

Answer 1

我通常采取自下而上的方法来测试，但我想在你想去自上而下的这种情况。测试最大的组件，您可以绕到单元测试，看看他们是怎么失败的。这些故障应该指向你对什么样的子组件需要有自己的测试。您将有一个相当参差不齐测试套件的时候做到这一点，但它是一个开始。

Answer 2

如果你有预算的话，得到的测试自动化套件。 HP /水星的QuickTest是这个领域的领导者，但非常昂贵。我们的想法是，你通过用例驱动的GUI记录测试情况下，像宏。您在表单上填写输入（网络，.NET，秋千，几乎任何类型的GUI的），发动机学习形式的元素名称。然后，你可以检查在GUI上的分贝预期的输出。然后你就可以在各种测试输入，包括无效的情况下，它应该会失败，并通过数以百计的情况下，如果你想运行一个表或电子表格插件。测试记录后，您还可以编辑生成的脚本来定制。它建立一个整洁的报告，你到底出你到底是什么失败。

也有一些廉价和免费的GUI自动化测试套件，这样做几乎同样的事情，但功能较少。通常更昂贵的套件，少手动customizition是必要的。看看这个名单： http://www.testingfaqs.org/t-gui.html

Answer 3

我觉得这就是一个良好的质量保证测试将进来。写出老式的测试用例，并分发给多个人的团队进行测试。

Answer 4

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

我建议由了解（或可以开发）产品功能规范的人员进行代码检查。

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

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

但是进行代码检查（并纠正通过代码检查发现的缺陷）可能会更快。这将是功能测试之外的。

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

您还需要：

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

Answer 5

的一种技术，我在这个时候在生命周期的输入项目时，作为缺陷报告给相加单元测试（由QA或最终用户）纳入我开发实践。你不会得到现有代码库的完整代码覆盖率，但至少这种方式未来的发展可以通过测试来推动和记录。此外这种方式，你应该放心，您的测试就执行工作之前失败。如果你写的测试，它不会失败，测试故障。

此外，当添加新的功能添加到系统，以使至少那些子系统进行检测开始那些测试。由于新系统与现有的互动，尝试老边界层周围添加测试并随着时间的推移你的工作到底。虽然这些不会是单元测试，这些集成测试是聊胜于无。

重构是还用于测试的另一个主要目标。重构而不进行测试就像是走一条紧绳不净。您可能会得到成功的彼岸，但值得奖励的风险？