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 回答