1

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

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

4

5 回答 5

2

我通常采用自下而上的方法进行测试，但我认为在这种情况下你想要自上而下。测试可以包装单元测试的最大组件，看看它们是如何失败的。这些失败应该指出哪些子组件需要自己进行测试。完成后，您将拥有一个相当参差不齐的测试套件，但这是一个开始。

于 2009-05-21T14:05:06.643 回答
2

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

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

于 2009-05-21T14:32:21.470 回答
0

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

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

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

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

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

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

您还需要：

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

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

于 2009-05-21T14:02:13.793 回答
0

在生命周期的这个时候进入项目时，我在开发实践中采用的一种技术是在报告缺陷时添加单元测试（由 QA 或最终用户）。您不会获得现有代码库的完整代码覆盖率，但至少通过这种方式可以通过测试驱动和记录未来的开发。同样，您应该确保您的测试在实施之前失败。如果您编写测试并且它没有失败，则测试是错误的。

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

重构是测试的另一个主要目标。没有测试的重构就像没有网的绳索。您可能会成功到达另一边，但风险值得回报吗？

于 2012-09-04T18:57:44.180 回答