Testing 测试整个程序。最佳做法

我目前正在用python开发一个库和一组使用该库的程序。 单元测试要求我从库中导入每个模块，并测试其中的类和例程。没问题。我有一个单独的测试目录，其中包含所有测试和导入库模块，我在开发时运行这些模块

然而，当涉及到测试程序时，情况发生了变化。要进行测试，程序必须作为一个整体运行。这些程序假定找到已安装的库（如果我在我的机器上安装了以前版本的库，则实际情况可能是这样，尽管是错误的，但这会增加更多的麻烦）。目前，我的程序由一个带有PYTHONPATH定义的testsuite运行，我在部署之前手动执行该定义（注意，我不执行安装），但我认为我做得不对。我觉得一般来说，一个程序在完全部署时应该进行功能测试，但这意味着每次我想执行功能测试时都必须安装它

关于整个程序的功能测试，您有什么经验和建议？您是在部署之前还是之后执行此操作，以及如何执行

谢谢

注意，我并不是故意包含python标记的。虽然我的问题是特定于python的，而且我更喜欢与python相关的答案，但我认为其他语言的专家也可以做出贡献

---

编辑：如评论中所述，事实上，我的程序在安装时必须导入模块，其路径只有在部署时才能找到（我动态下载并安装依赖项，它们没有安装在我的计算机上）。我无法从测试中操纵sys.path，因为这意味着我从另一个程序（运行并生成system（）调用的testsuite）修改程序（我的可执行文件）的sys.path

换句话说，我必须在不部署的情况下测试程序的唯一方法是在PYTHONPATH设置为dir的情况下执行程序，dir包含deps和make脚本安装的程序使用的库（正如我所说，make脚本下载、编译并“安装”临时目录中的所有内容）

在部署时，DEP和可执行文件打包在一个“OSX包”式结构中，该结构完全可执行且可重新定位

编辑：

增加了一笔150英镑的赏金，看看我是否能得到更多的反馈

编辑：

我对所有的答案都表示赞赏，并投了赞成票。这个选择对我来说是一个艰难的选择，但我被LudoMC召回了我很久以前学习的V型测试方法。感谢大家给出了非常好的答案。

好吧，（自动化）测试总是一个折衷方案，因此没有一种正确的方法可以做到这一点

但是，是的，理想情况下，您应该在运行测试之前自动完成程序的完整安装/部署。这样，您还可以测试安装程序

也许您可以编写一个安装程序包装器来为您实现自动化。如果工作量太大，您可能还可以在手动创建的部署中运行功能测试

---

作为一种折衷方案，您可以在测试运行开始时只运行一次安装，然后在不重新安装的情况下运行所有功能测试，以使测试运行更快。

在合理范围内尽可能多地测试。如果某个东西很好测试，但需要付出很多努力，那么不要测试它。。。然而只有当你发现自己在那个地方一次又一次地遇到问题时，你才会付出努力。永远不要预先假设问题会在哪里（除非你提前知道……但是，知道并不是假设！）

---

因此，如果安装程序很少引起任何问题，不要尝试测试它。如果您的部署很脆弱，可以编写一个测试来检查安装存档是否完整，而不是尝试安装：您不是在测试系统的安装程序，而是在测试您的软件包。

在我们公司，我们使用非常常用的V型模型作为开发过程，如果单元测试在实现阶段完成，则集成测试在架构/设计阶段完成，系统测试在需求阶段完成

所以在您的情况下，据我所知，您希望在功能级别上测试整个应用程序。因此，必须按照要求进行

因此，您需要一个需求文档，无论是全文场景还是（更好的）涵盖（理想情况下广泛）应用程序用例的UML用例图（通常是要实现的第一阶段之一）。 然后，您必须编写涵盖每个用例的测试用例，并通过这些测试用例。它可以通过使用知名（而且相当昂贵）的工具进行手动或自动测试来完成

至于何时，我们通常在部署之后进行这些系统测试（测试团队使用开发团队提供的安装程序），因为我们也测试安装程序本身，其中集成测试在部署之前或之后进行，具体取决于具体情况

在您的情况下，如果安装程序没有错误，并且您100%确信在部署前使用PYTHONPATH变量进行测试不会在部署后带来错误，那么您可以选择在部署前进行测试。这是纯粹的风险管理，这是你的决定，因为你是最清楚这对你的应用程序的利弊的人。（个人而言，我不明白为什么虫子不能在那里存在，它们无处不在：-）

希望这对我有所帮助，我没有偏离主题

我曾经遇到过一个关于部署的类似问题，并且正在使用它来测试部署。特别是使用

--无站点软件包

选项，这就像是一个原始的安装，除了经过良好测试的第三方解决方案之外，不会破坏PYTHONPATH。可以肯定的是，我们在一个新的虚拟机中运行了整个东西，包括virtualenv和所有东西

顺便说一句，

v的一个有用技巧