部署新系统后应该注意哪些事项？到目前为止，我能想到以下几点：
检查事项：
a）检查它是否部署到正确的文件夹：打开正在部署构建的机器，检查它是否已进入指定文件夹，如有必要，检查是否已覆盖正确的文件。
b) 检查部署正确的 SVN：确保最新的 svn 版本是在已部署机器上找到的正确版本。
c) 应用程序（它实际工作）
d) 检查所做的更改是否存在并测试任何错误。
e) 性能问题（缓慢、崩溃等）
部署测试
软件测试
手动测试
技术
2022-01-12 18:38:25
4个回答
我刚刚编写了一个部署验证工具，能够验证以下内容：
IIS
- 应用程序池
- 存在
- 状态（开始）
- 工作进程
- 存在
- 状态（运行）
- 网站
- 姓名
- 状态（开始）
- 应用
- 应用程序池名称
- 小路
- 物理路径
- 虚拟目录
- 登录方式
- 小路
- 物理路径
- 用户
- 网址发布/获取验证
- 响应代码
- 响应包含或不包含字符串。
- 应用程序池
登记处
- 核心价值
- 类型
数据库
- 桌子
- 姓名
- 柱子
- 姓名
- 类型
- 最大长度
- 版本
- 姓名
- 看法
- 姓名
- 柱子
- 姓名
- 类型
- 最大长度
- 版本
- 姓名
- 存储过程
- 存在
- 版本
- 权限
- 服务器（测试最小权限的白名单和验证功能的可选非白名单）
- 数据库（测试最小权限的白名单和验证功能的可选非白名单）
- 询问
- 预期响应（包含值列表，可选择按特定顺序，可选择仅包含该列表或列表加上附加值）。
- 桌子
视窗服务
- 姓名
- 状态
- 启动类型
- 登录方式
DeploymentFiles（dll、exe、复制到服务器的任何文件）
- 产品版本
- 文件版本
- 存在
- 用户权限
- 用户
- 访问控制类型
- 文件系统权利
文本文件（日志文件、配置文件、人类可读文件）
- 地点
- 文本文件包含或不包含字符串
除了这个工具之外，我们的许多部署验证将包括我们端到端功能测试的子集，无论是 UI 自动化、Web 请求自动化还是其他功能自动化。
感谢 Kunal 的起点：http ://www.testingwithkunal.com/category/deployment-testing/
很高兴听到部署测试问题。部署过程本身似乎经常被忽略。您的部署过程是否自动化？如果它不是质量从那里开始。一致的可重复过程将为成功部署创造奇迹。
完成后，您可以考虑将质量检查添加到您的自动化部署中，例如将 txt 文件添加到您的部署中，以便您知道哪个构建/修订号、验证服务已启动、确认已删除旧文件、自动进行烟雾测试应用等...
如果您谈论测试新的自动化部署，我将专注于测试可能失败的事物并验证错误处理是否可以理解。更重要的是寻找可能失败但不会导致部署失败的项目。更糟糕的部署失败是您甚至不知道失败的部署，当然会在部署过程中添加质量测试步骤（就像我上面提到的那样）。
部署到系统后，我首先要查找的内容：
部署具体的东西？
- 部署了正确的文件/文件夹
- 确保应签名的程序集实际上已正确签名
- 装配版本是正确的
- GAC 的程序集是 GAC 的
- 如有必要，检查桌面图标/开始菜单图标（假设 Windows）
- 检查服务是否已安装/运行（如果有）
- 导航到应该安装/运行的任何 Web 服务
- 制作了正确的注册表项
- 在测试虚拟机/机器上，我在部署之前清理所有事件日志，并在部署后查看所有事件日志
- 检查任何特定于应用程序的日志以获取错误/警告
- 验证错误修复（我假设这是您帖子中的场景）
- 验证文档有正确的部署方案步骤（如果是客户活动）
我做了一个小的健全性检查应用程序是否正常工作，但在那个阶段我不检查应用程序的性能。这完全是另一种情况。
这就是我目前能想到的。通常，我会制作一个清单“大”场景，其中包含很多与产品相关的内容。
现在这都是验证。如果我要对部署/安装进行一些探索性测试，情况会有所不同。我会试图把事情搞砸并破坏部署。
我们做类似的事情，我们称之为发布测试。基本上，我们只执行足够的测试来确认系统已正确部署和配置，它包含预期的增强/修复，并且它在此过程中没有破坏其他东西。
我们在发布测试期间实际做的事情因项目和发布而异。我们总是试图控制发布所需的时间，因为它有时会导致我们的客户停机，而且通常是在非工作时间（没有人想浪费时间的时候）执行的。
有时，与发布相关的转换 - 通常这涉及大量测试以确保转换行为正确。
有些东西，这是一个简单的版本，可能只涉及快速冒烟测试，然后进行一些有针对性的测试，以确保所需的一些修复正确地包含在版本中。