我目前正在python中使用这个库开发一个库和一组程序。 单元测试规定我从库中导入每个模块，并测试其中的类和例程。没问题。我有一个单独的测试目录，其中包含我的所有测试并导入我在开发时运行的库模块。
然而，当涉及到测试程序时，事情会发生变化。要进行测试，程序必须作为一个整体运行。程序假定找到安装的库（实际上可能是这种情况，虽然错误，如果我在我的机器上安装了它的先前版本，增加了进一步的麻烦）。目前，我的程序由一个带有PYTHONPATH定义的测试套件运行，我在手动部署之前进行了部署（IOW，我没有执行安装），但我不认为我做得对。我觉得一般情况下，应该在完全部署时测试程序的功能，但这意味着每次我想进行功能测试时都必须安装它。
您对整个计划的功能测试有哪些经验和建议？你是在部署之前或之后做的，怎么做？
由于
请注意，我没有故意包含python标记。虽然我的问题是python特定的，我更喜欢与python相关的答案，但我认为也可以从其他语言的专家那里获得贡献。
编辑：正如评论中所报道的那样，事实是我的程序在安装时必须导入只在部署时才能找到路径的模块（我即时下载并安装依赖项） ，它们没有安装在我的机器上）。我无法从测试中操作sys.path，因为这意味着我从另一个程序（testsuite，运行并产生一个system（）调用）修改程序（我的可执行文件）的sys.path。
换句话说，我必须在没有部署的情况下测试程序的唯一方法是执行程序，将PYTHONPATH设置为包含deps的dir和程序使用make脚本安装的库（正如我所说，下载，编译和“安装”临时目录中的所有内容。）
在部署时，deps和可执行文件一起打包在一个“OSX bundle”式结构中，该结构是完全可执行和可重定位的。
修改：
增加了150赏金，看看我是否能得到更多反馈。
修改：
我赞赏所有答案，并对所有答案进行了投票。这个选择对我来说是一个艰难的要求，但是LudoMC已经回忆起我很久以前研究过的V模型测试方法。感谢所有人给出了非常好的答案。
答案 0 :(得分：4)
嗯，（自动）测试总是权衡，所以没有一种正确的方法可以做到。
但是，理想情况下，您应该在运行测试之前自动执行程序的完整安装/部署。这样你也可以测试你的安装程序。
也许您可以编写一个安装程序包装器，为您自动执行此操作。如果工作量太大，您也可以在手动创建的部署中运行功能测试。
作为妥协，您可以让您的安装在测试运行开始时只运行一次，然后运行所有功能测试，无需重新安装，以使测试运行得更快。
答案 1 :(得分：4)
在合理范围内尽可能多地进行测试。如果有什么东西可以测试，但需要付出很多努力，那么就不要测试它了。只有当你发现你在那个地方一次又一次地遇到问题时，才会付出努力。永远不要提前考虑问题在哪里（除非你提前知道 ...但是，知道不是假设！ ）。
因此，如果安装程序很少会导致任何问题，请不要尝试测试它。如果您的部署很脆弱，可以编写一个测试来检查安装存档完成而不是尝试安装：您没有测试系统的安装程序，您是测试包。
答案 2 :(得分：4)
在我们公司，我们使用一种非常常用的V-Model作为开发过程，其中单元测试在实现阶段完成，集成测试在架构/设计阶段完成，系统测试针对要求阶段。
因此，在您的情况下，根据我的理解，您希望在功能级别上测试整个应用程序。所以必须完成这些要求。
因此，您需要一个需求文档，无论是全文场景还是（更好）UML用例图，覆盖（理想情况下）应用程序的用例（通常是要实现的第一阶段之一）。 然后，您必须编写涵盖每个用例的测试用例并传递这些测试用例。它可以通过使用众所周知（并且相当昂贵）的工具进行手动或自动测试来完成。
对于何时，我们通常在部署后进行这些系统测试（测试团队使用开发团队提供的安装程序），因为我们还测试安装程序本身，其中集成测试在之前或之前部署后视情况而定。
在您的情况下，如果安装程序没有错误，并且您在使用PYTHONPATH变量进行部署之前100％确定测试将永远不会带来错误，那么您可以选择在部署之前进行测试。这是纯粹的风险管理，这是你的号召，因为你是最了解你的应用程序的利弊的人。 （Personnaly，我不明白为什么那里不存在bug，它们无处不在:-)）
希望有帮助，我不偏离主题
答案 3 :(得分：3)
We已经面临类似的部署问题，并且正在使用virtualenv来测试部署。特别是使用--no-site-packages选项，它就像是一个原始安装，除了经过充分测试的第三方解决方案之外，没有PYTHONPATH。而且可以肯定的是，我们在新的虚拟机中运行整个事物，virtualenv等等。
btw，virtualenv的有用技巧是./setup.py develop。
（从一个熟练工到另一个......）
答案 4 :(得分：2)
当然，您应该在完全准确的部署后方案中测试您的程序。
您可以考虑将自检功能集成到生产代码中，并提供按需运行的机制。仅在您自己的系统测试期间运行自检是有意义的，但您的安装程序可以将其作为最后一步运行，您的用户可以从菜单项运行它，或者您甚至可以进行“开机自检” “在启动时。
有很多技巧可以做到这一点。如果部署Web服务，则可以通过管理URI调用自检，这将使HTTP请求自身验证它们是否有效。静态自检可能就是您所需要的，但您也可以动态加载和运行测试脚本。对于后者，您可以使用您的语言的解释工具，或者如果没有，您可以在您的软件中嵌入一个解释器（例如，TCL for C / C ++和Rhino for Java）或编写自己的迷你解释器。
答案 5 :(得分：2)
进行功能测试有一定的局限性，因为您通常无法模拟使用GUI的人，也不会测试用户可能会做的异常操作，因为他们可能只是点击或输入无意义的内容。
最好的办法是在应用程序的视图中使用尽可能少的业务逻辑，然后就可以更好地进行测试，因为您可以在关闭时测试控制器，或者如果有的话，可以测试您的Web / REST服务下来。
您需要尝试在测试中尽可能完整，测试正面和负面情况，以确保您知道应用程序如何工作，无论用户发送了什么。
我发现NUnit和junit对于以这种方式进行测试很有用，但对于功能测试，最终我最终只能手动执行测试脚本。我倾向于通过使用像ant这样的东西来运行应用程序的所有测试，以帮助确保尽可能多地测试，然后我会回家，因为全套测试可能需要很长时间跑。