“标准”测试过程

Question

我意识到术语“标准”很奇怪，因为测试非常依赖于项目，但如果我布置一个非常标准的场景，我希望得到关于我应该关注的测试类型的反馈。

我的团队正在创建一个中型数据驱动的Web应用程序。我们正在使用一个相当敏捷的过程。在大多数情况下，要求已经设定，但我们也会在最后一刻得到一些改变。

到目前为止，我们一直在进行大多数手动测试。我们正努力尽可能地实现自动化。我一直在研究一些工具，以下是我认为需要关注的测试类型：

• 单元测试（测试驱动开发风格） - 由于编写了大量代码，因此游戏有点晚了，但是我还是计划在实现功能之前进行测试。出于这个问题的目的，我们甚至可以假设我没有开始这个项目。

• 集成测试 - 由于我们的应用程序在网上，我想我使用术语集成测试来表示页面之间的链接？什么是一个很好的开源工具（让我们说.NET）？

• 回归测试 - 我们的单元测试似乎是免费的

• 数据完整性测试 - 不确定您所说的是什么，只是想知道我们从客户端加载到应用程序中的数据是有效的。

• 功能测试 - 这通常是在GUI中完成的吗？是否有良好的代码驱动选项？

• 性能和负载测试 - 确保应用程序即使在压力下也能快速响应。

我总是被告知QA团队应该有几乎与开发团队一样多的时间来查看应用程序，但似乎现在很多方面都可以实现自动化。这些天，官方的“QA团队”是不是更少需要？

我的主要问题是：

• 对于拥有saavy技术团队的中型项目来说，这是一项合理的测试工作吗？是否有我遗漏或应该关注的大事？
• 这些测试工作的典型周期是什么？ （例如，每次入住或每晚办理单元测试）？
• 这些天的典型QA工时与发展工时相比如何？

非常感谢！

Answer 1

有so many things我需要写回答......我会提出一些亮点，指望其他人提供一些好的见解。

集成测试
通常，它被理解为测试应用程序组件之间的集成。这可以是业务层模块之间的交互。它可以是Business Objects和Data Access Objects之间的交互。集成测试背后隐藏着许多东西。 “页面之间的联系”将是我想到的最后一次。它正在验证Web应用程序的“完整性”，但这里没有多少人会说这是集成测试。也许从wiki definition开始，检查SO questions。

回归测试
您是否只想测试各个类，功能，业务流程，数据流等？回归测试定义了重复某些测试的动机，而不是您执行测试的级别。您可以进行回归测试，以检查给定测试所涵盖的功能是否因系统中的最新更改而中断。它可以是单元测试，它可以是集成，它可以是功能的，它可以是基于GUI的，也可以不是。检查wiki definition。

数据完整性测试
我没有处理它，但我不确定你的说服是否正确。试试google search？

功能测试
功能测试通常被理解为GUI级别，但它不必。它可以在Web服务，EJB上，甚至在API上完成。检查this definition以澄清这一点 至于GUI的代码驱动测试，有许多解决方案。 MSVS2010--用它的CodedUI测试，HP QTP用于许多技术，有来自IBM的工具，有一个来自Borland（Silk Test，现在Borland属于某些公司）。有开源工具：WatiN，Selenium，Abbot，RobotFramework，还有许多其他工具。

性能测试
Performance Testing有许多种类，压力测试，浸泡测试，负载测试等等。请查看此MS reference以获取基本概述。

现在，主要问题是：）

1. 你可以做一些事情，但你只会抓住表面。此外，你需要能够做到这一点的人。没有不尊重，但你确定你的开发人员知道所有这些并且可以做到吗？更重要的是他们有时间做所有这些吗？从小处开始。继续进行单元测试，组件集成测试，对两者进行回归分析。开始自动化功能测试，也许尝试验收测试驱动开发（something here，something there）。更多地关注您发现错误的区域，最大化您的投资回报率：P（如果您没有遇到性能问题，可能会轻微地进行性能测试？）。
2. 设置continuous integration。经常运行快速测试，有时运行慢速测试，在需要时运行完全回归（基于风险评估）。
3. 关于需要多少测试时间，没有明确的规则。这取决于很多因素。最重要的是，实际产品有多少？更多错误 - ＆gt;更多修复 - ＆gt;更多回归=更多测试。有像谷歌（许多项目的一个测试人员）或微软（每个开发人员多达多个测试人员）等公司。很难说先验项目，没有历史数据（来自您的组织，对于给定的团队/项目类型）。 This short post可能会为您提供更多见解。

干杯。

Answer 2

我完全同意yoosiba的答案，（但）对我来说，从开发人员的角度来看似乎是一个答案（这不是批评）。同样重要的是不要忘记用户的观点。

因此，当开发人员测试进展顺利并且你有一个正在运行的系统时，那么System test的时间（你可以根据yoosiba的答案将其排序为功能测试）。而且我不会完全自动化这部分（当然这部分可以自动完成）。

特别是我从Exploratory testing得到了很好的结果。 简而言之，您需要一位经验丰富的测试人员（用户）尝试使用该系统主动查找错误。测试人员必须能够找到对系统有压力，发现极限情况或罕见用例的棘手测试用例。 这不仅会发现错误，而且从可用性的角度来看，它也会找到可能很难的点。 这里重要的是，测试人员不是开发人员，因为根据我的经验，开发人员倾向于相信他们的技能和软件（也不错），并且可能只测试他们已实现的内容。 （系统测试/探索性测试是一个黑盒测试，即测试人员不必/不应该知道实现）