我无法相信我是第一个经历这个思考过程的人，所以我想知道是否有人可以帮助我解决这个问题。
目前的情况：开发人员编写一个网站，操作部署它。部署后，开发人员Smoke测试它，以确保部署顺利进行。
对我而言，这感觉不对，这实际上意味着需要两个人来部署应用程序;在我们的例子中，这两个人位于地球的两侧，时区发挥作用，造成严重破坏。但事实仍然是开发人员知道最小的测试集是什么，并且可能会随着时间而变化（特别是对于我们的应用程序的Web服务部分）。对他们充满敬意的操作（他们会自己说出来）是需要一系列指示的按钮按钮。
手动解决方案是我们记录每次部署时测试用例和操作都遵循该文档。这听起来很痛苦，而且他们可能正在为不同的环境（特别是UAT和Production）部署不同的版本，并且每个版本可能需要不同的指令集。
除此之外，我们近期的计划之一是拥有自动化的日常部署环境，因此我们必须指示计算机如何部署我们应用的特定版本。我非常希望添加有关如何对应用程序进行冒烟测试的说明。
现在开发人员更擅长记录计算机的指令而不是人们，因此显而易见的解决方案似乎是使用nUnit的组合（我知道这些不是单元测试本身，但它是内置的 - 用途测试运行器）和Watin或Selenium API运行明显的浏览器步骤并调用Web服务并向Operations人员解释如何运行这些单元测试。我能做到;我大部分已经完成了。
但如果我能让这个过程变得更简单，那不是很好吗？
此时，操作人员和计算机将不得不知道哪组测试与哪个版本的应用程序相关，并告诉nUnit runner它应该指向哪个基本URL（例如，www.example.com） = v3.2或test.example.com = v3.3）。
如果测试运行器本身有办法给它一个基本URL并让它下载一个zip文件，解压缩并自动编辑配置文件，然后运行它在那里找到的任何测试夹具，那不是更好吗？
是否有开源应用程序可以做到这一点？是否需要一个？有没有使用nUnit以外的东西的解决方案，也许是Fitnesse？
为了记录，我首先看的是基于.NET的工具，因为大多数开发人员主要是.NET开发人员，但我们并没有嫁给它。如果使用其他语言存在这样的工具来编写测试，只要有一个适用于Windows的测试运行器，我们就会很乐意适应。
答案 0 :(得分：2)
我在一个烟雾测试编写器中为asp.net应用程序工作。我们使用了QuickTest Pro，测试运行的自动化是用Quality Center完成的（它被称为Test Director。）。这涉及编写数百个测试脚本，以自动化与Web应用程序交互的Web浏览器。这些测试用于在我们的生产服务器上推出之前验证构建。 Quality Center允许您定义测试计算机的“池”，以允许您以多线程方式运行大量测试脚本。
更简单的冒烟测试是记录应用程序生成的所有错误/异常并对系统运行蜘蛛。这不会获得非常“深度”的代码覆盖率，但冒烟测试不适用于深度代码覆盖。此错误日志记录应该是生产应用程序的一部分，以便在出现错误时进行处理。错误总会在裂缝中滑落，可悲的是，最好的测试人员将成为您的用户。
答案 1 :(得分：2)
我过去曾使用Selenium为Web部署进行这类冒烟测试。您可以编写一套测试脚本，然后针对不同环境中的同一站点运行。
答案 2 :(得分：1)
我还对这个序列进行了一些思考，并建议采用声明式方法进行部署和验证，请参阅此处了解我的想法，
http://jimblogdog.blogspot.co.uk/2010/10/introducingdeclarative-deployment.html
我还为我的开源项目Wolfpack创建了一些插件，以自动执行整个过程。基本上，您将“部署冒烟测试”打包为NuGet包，并将其发布到您的私有NuGet订阅源。 Wolfpack将自动检测新版本的软件包并下载它，以及NUnit.Runner NuGet软件包并解压缩所有文件。然后它将使用NUnit控制台运行程序静默运行您的测试，并将结果解析为一个警报，您可以通过电子邮件，咆哮，熟练等方式接收。
http://wolfpackcontrib.codeplex.com/wikipage?title=NUnitDeploymentPublisher
答案 3 :(得分：0)
Telerik有一些免费且不免费的UI测试工具，任何可能对此有帮助的人都可以自动运行。
答案 4 :(得分：0)
我不知道您使用的是哪个VCS，但您可以编写一个解决方案，通过中间服务从VCS中提取特定于版本的配置文件。
您可以编写一个powershell脚本或应用程序，它将从Web服务或Web应用程序下载配置文件，并将测试URL作为参数传递。服务器或应用程序将在可以访问VCS的计算机上运行，因此它可以返回文件内容。一旦检索到，脚本或应用程序就可以启动测试。
答案 5 :(得分：-2)
通常，你的nUnit测试足够了，如果它们全部通过，代码库应该可以正常工作。如果您部署代码，通过nUnit测试，并在网站上遇到故障，那么您需要添加另外一个失败的nUnit，原因相同。然后，当您修复代码以便nUnit正在传递时，您知道已修复了已部署代码所具有的问题。出于这个原因，大多数自动构建系统可以配置为首先自动运行所有nUnit测试，然后在任何测试失败时“失败”构建。
答案 6 :(得分：-2)
在浪费了大量时间试图制作更简单的解决方案后，我们最终教会了运营团队如何使用NUnit Gui跑步者。这比预期的要容易，并且工作正常。