testing - 用小团队(和很少的时间)对大型项目进行手动与自动测试

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改进这个问题？更新问题，以便 editing this post 提供事实和引用来回答它.

11 个月前关闭。




Improve this question




我在一个由 5 名程序员组成的小型开发团队工作，其中没有人有任何整体测试经验。我们开发的产品是一个复杂的 VMS，基本上由一个(独立的)视频服务器和一个用于查看实况和录制视频的客户端组成。由于视频处理需要大量硬件能力，因此该软件通常部署在多台服务器上。

我们使用精简版的功能驱动开发。在过去的几个月中，实现了许多功能，几乎没有时间花在 QA 上。

我目前正在研究一种方法，让我们尽可能(时间)高效地测试我们的软件。我知道围绕测试构建的软件方法论，例如 TDD。但是，由于许多功能都是围绕分布式架构构建的，因此很难为各个功能编写单独的测试。鉴于许多功能需要一些无穷无尽的场景，因此可以将其部署以进行复制以便正确测试。

例如，最近我们开发了一种故障转移功能，其中一个或多个空闲服务器将监视其他服务器，并在发生故障时取代它。可能的情况包括远程位置或不同子网中的故障转移服务器，或者一次有多个故障服务器。

手动设置这些场景会花费大量宝贵的时间。尽管我知道在这种情况下总是需要手动初始化，但我似乎无法找到一种方法来自动化这些类型的测试(最好在实现功能之前定义它们)而无需投入同等或更大的资金实际创建自动化测试的时间。

有没有人在类似环境中有任何经验，或者可以告诉我更多关于适合这种环境的(自动化)测试方法或技术的信息？如果它以显着的方式增强测试，我们愿意覆盖我们当前的开发过程。

提前感谢您的任何意见。请原谅我的语法，因为英语不是我的第一语言:)

Answer 1

我通过考虑金字塔中的层来处理测试策略。

金字塔的第一层是你的单元测试。我将单元测试定义为执行类的单个方法的测试。系统中的每个类都应该有一套与之相关的测试。并且每个方法都应该在该套件中包含一组测试。这些测试可以而且应该存在于模拟环境中。

这是测试和质量策略的基础。如果你在这里有可靠的测试覆盖率，很多问题都会被扼杀在萌芽状态。这些是您将要创建的所有测试中最便宜和最简单的。您可以在这里获得巨大的 yield 。

金字塔的下一层是您的功能测试。我将功能测试定义为对模块中的类进行测试的测试。这是您测试各种类如何相互交互的地方。这些测试可以而且应该存在于模拟环境中。

下一层是您的集成测试。我将集成测试定义为执行模块之间交互的测试。这是您测试各种模块如何相互交互的地方。这些测试可以而且应该存在于模拟环境中。

下一层是我所说的行为或工作流测试。这些是像客户一样使用系统的测试。这些是构建和维护的最昂贵和最难的测试，但它们至关重要。他们确认该系统按照客户期望的方式运行。

金字塔的顶端是探索性测试。根据定义，这是一项手动事件。在这里，您有一个知道如何使用该系统的人来完成它的步伐并努力找出问题。这在一定程度上是一门艺术，需要特殊的个性。但这对您的整体成功非常宝贵。

我上面描述的只是你需要做的一部分。下一部分是设置持续集成/持续部署 (CI/CD) 管道。

每当代码提交到您的一个存储库时，我确实希望您有一个像这样大的项目被分解为单独的存储库，该组件应该进行静态分析(即 lint 它)，构建，针对它执行测试，收集代码覆盖率数据。

定期构建系统的每个组件的行为将有助于解决问题。将其与针对它运行的单元/功能/集成测试相结合，您将发现很多问题。

构建组件后，应将其部署到测试或登台环境中。此过程必须是自动化的并且能够在无人值守的情况下运行。我强烈建议您考虑使用 Chef来自 Opscode对于这个过程。

一旦您将其部署到暂存或测试环境中，您就可以开始使用工作流和行为测试来实现它。