3

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

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

您对整个程序的功能测试有何经验和建议？你是在部署之前还是之后做的，如何做？

谢谢

请注意，我没有故意包含 python 标记。虽然我的问题是特定于 python 的，并且我更喜欢与 python 相关的答案，但我认为也可以从其他语言的专家那里获得贡献。

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

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

在部署时，deps 和可执行文件被打包在一个类似“OSX 包”的结构中，该结构是完全可执行和可重定位的。

编辑：

添加了 150 赏金，看看我是否可以获得更多反馈。

编辑：

我感谢所有答案并投票赞成所有答案。这个选择对我来说是一个艰难的决定，但 LudoMC 让我想起了我很久以前研究过的 V 模型测试方法。感谢所有人提供的非常好的答案。

4

6 回答 6

4

好吧，（自动化）测试总是一个权衡，所以没有单一的正确方法来做到这一点。

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

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

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

于 2009-04-27T11:10:40.487 回答
4

在合理范围内尽可能多地进行测试。如果某些东西测试起来很棒，但需要付出很多努力，那么不要测试它......但是。只有当你发现你在那个地方一次又一次地遇到问题时，然后再花精力。永远不要提前假设问题出在哪里（除非您提前知道......但是，知道并不是假设！）。

因此，如果安装程序很少会导致任何问题，请不要尝试对其进行测试。如果您的部署很脆弱，也许可以编写一个测试来检查安装存档是否完整，而不是尝试安装：您不是在测试系统的安装程序，而是在测试您的包。

于 2009-04-27T12:12:48.433 回答
4

在我们公司，我们使用非常常用的 V-Model 作为开发过程，其中单元测试在实现阶段完成，集成测试在架构/设计阶段完成，系统测试在需求阶段完成。

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

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

对于when，我们通常在部署之后进行这些系统测试（测试团队使用的是开发团队提供的安装程序），因为我们也会测试安装程序本身，其中集成测试根据情况在部署之前或之后进行。

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

希望有帮助，我不是题外话

于 2009-05-02T16:02:40.023 回答
3

我们在部署方面遇到过类似的问题，并且正在使用virtualenv来测试部署。尤其是有了这个--no-site-packages选项，它就像一个原始安装，并且除了经过良好测试的 3rd 方解决方案之外，没有使用 PYTHONPATH。可以肯定的是，我们在一个新的虚拟机中运行整个东西，virtualenv 等等。

顺便说一句， s 的一个有用技巧virtualenv是./setup.py develop.

（从一个熟练工到另一个...）

于 2009-05-03T03:38:24.627 回答
2

当然，您应该在完全准确的部署后场景中测试您的程序。

您可能会考虑将自测功能直接集成到您的生产代码中，并提供一种按需运行它的机制。仅在您自己的系统测试期间运行自检可能是有意义的，但是您的安装程序可以将其作为最后一步运行，您的用户可以从菜单项运行它，或者您甚至可以进行“开机自检” “在启动时。

有很多技术可以做到这一点。如果您部署 Web 服务，则可以通过管理 URI 调用自检，该管理 URI 会在自身上发出 HTTP 请求以验证它们是否工作。您可能只需要静态自测，但您也可以动态加载和运行测试脚本。对于后者，您可以使用您的语言的解释工具，或者如果没有，您可以将解释器嵌入到您的软件中（例如，用于 C/C++ 的 TCL 和用于 Java 的 Rhino）或编写自己的迷你解释器。

于 2009-05-05T23:16:26.307 回答
2

进行功能测试有局限性，因为您通常无法模拟使用 GUI 的人，并且您不会测试用户可能执行的异常操作，因为他们可能只是单击或键入没有意义的内容。

最好的办法是在应用程序的视图部分中包含尽可能少的业务逻辑，然后您可以更好地测试，因为您可以测试控制器关闭，或者如果您有它，您的 Web/REST 服务关闭。

您需要尽可能完成测试，测试正面和负面案例，以确保您知道应用程序将如何工作，无论用户发送什么。

我发现 NUnit 和 junit 对以这种方式进行测试很有用，但对于功能测试，最终我最终只能手动通过测试脚本，在大多数情况下。我倾向于通过使用 ant 之类的东西来运行应用程序的所有测试，以帮助确保可以测试尽可能多的东西，然后我会回家，因为全套测试可能需要很长时间跑步。

于 2009-05-05T23:24:24.010 回答