部署新系统后应该看什么?到目前为止,我可以想到以下内容:


要检查的内容:

a)检查它是否已部署到正确的文件夹:也在其中部署了构建的开放式计算机
b)检查部署正确的SVN:确保最新的svn修订版是在已部署的计算机上找到的正确修订版。 > c)应用程序(它确实有效)
d)检查所做的更改是否存在并测试任何错误。
e)性能问题(缓慢,崩溃等)

评论

您是指验收测试吗?

我也很难理解。不确定是指实施后测试还是测试部署机制。

我想他是我在谈论端到端测试。

你的背景是什么?您是在谈论部署到台式机还是服务器?它是一个独立的应用程序,还是移动组件数量庞大的东西,必须与世界上其他亿万个地方进行通信?您做了多少部署前测试?部署后用户是否可以立即访问系统,还是可以部署人员然后进行迁移?

#1 楼

我刚刚编写了一个部署验证工具,可以验证以下内容:



IIS



应用程序池

存在
状态(已开始)
工作流程
存在
状态(正在运行)



站点

名称
状态(开始)
应用程序

ApplicationPoolName
路径
PhysicalPath
虚拟目录

> LogonMethod
路径
PhysicalPath
用户







URL发布/获取验证

响应代码
响应包含或不包含字符串。






注册表


键值
类型



数据库




名称


名称
类型
最大长度


版本


查看

名称


名称
类型
MaximumLength


版本


StoredProcedure

存在
版本


权限

服务器(白名单用于测试最小特权,可选白名单用于验证功能) >数据库(白名单用于测试最小特权,可选的非白名单用于验证功能)


查询

预期的响应(包含值列表,可以选择在特定列表中顺序,可以选择仅包含该列表或列表以及其他值。)





Windows Service


名称
状态
StartupType
LogOnAs



DeploymentFiles(dll,exe,复制到服务器的任何文件)


产品版本
文件版本
存在
UserPermissions

User
AccessControlType
FileSystemRight





TextFiles(日志文件,配置文件,人类可读文件)


位置
文本文件包含或不包含字符串



除了此工具之外,我们的许多部署验证还将包括端到端功能测试的子集,无论是UI自动化,Web请求自动化还是其他功能自动化。

感谢Kunal提供起点:http://www.testingwithkunal.com/category/deployment-testing/

#2 楼

很高兴听到部署测试问题。部署过程本身似乎经常被忽略。您的部署过程是否自动化?如果不是,质量从那里开始。一致的可重复过程将为成功部署带来奇迹。

完成之后,您可以考虑在自动部署中添加质量检查,例如向您的部署中添加txt文件,以便您知道哪个内部版本号/修订版号,确认服务已启动,确认旧文件已删除,对应用程序进行冒烟测试,等等。...

如果您要测试新的自动化部署,我将重点关注测试那些可能失败并验证错误处理是可以理解的。更重要的是,寻找可能失败但不会使部署失败的项目。失败的部署最糟糕的一种是您甚至都不知道失败的,当然还要在部署过程中添加质量测试步骤(就像我上面提到的那样)。

#3 楼

部署到系统后,我首先要寻找的是:

部署特定的东西?


部署正确的文件/文件夹

确保应正确签名的程序集实际上已正确签名
程序集版本正确
GAC的程序集是GAC的
如有必要,请检查桌面图标/开始菜单图标(假定为Windows)
检查服务是否已安装/正在运行(如果有)
导航至应该安装/正在运行的任何Web服务


做出正确的注册表项
在测试VM /计算机上,我在部署之前先清理所有事件日志,并在部署后查看所有事件日志
检查任何特定于应用程序的日志中是否存在错误/警告
验证错误修复程序(我假设这是您所发布的场景)
验证文档是否具有针对部署场景的正确步骤(如果是客户活动)

我愿意对该应用程序进行小的完整性检查,但我不检查应用程序pe在那个阶段的表现。完全是另一种情况。

这就是我目前能想到的。通常,我会列出一个“大”方案清单,其中包含很多与产品相关的内容。

现在这就是验证。如果我要对部署/安装进行一些探索性测试,那将有所不同。我会尝试整理问题并破坏部署。

#4 楼

我们执行类似的操作,称为“发布测试”。
基本上,我们执行足够的测试以确认系统已正确部署和配置,包含预期的增强功能/修复程序且未破坏某些功能。

我们在发布测试期间实际执行的操作因项目而异,并且因发布而异。我们总是试图控制发布所需的时间,因为它有时会给我们的客户造成停机,并且通常是在下班时间执行(当没人想浪费时间时)。

有时,我们需要进行一次转换与发布相关联-通常,这涉及大量测试,以确保转换行为正常。

,这是一个简单的发布,可能只涉及快速冒烟测试,然后进行一些针对性测试确保所需的少量修复程序已正确包含在发行版中。

#5 楼

同意Lyndon,但为什么只考虑发布?

如何定期运行心跳测试以检查一切是否正常。这样,不仅升级会受到测试,而且如果有人酸痛地拔出电缆,您也会了解它(希望比您的客户更早)。

主动进行测​​试-持续进行生产监控测试,而不必仅限于检查简单的内容(例如您是否有足够的磁盘空间)。

#6 楼

我想我可能会理解这个问题,下面是我认为自己理解的问题的答案。

C点可能是最重要的,基本上涵盖了a,b和d点。 。

要添加和添加点f,应在新环境上执行某种形式的漏洞测试。通常,移动机器(即使是升级版)也可能会打开漏洞,使您可以通过这些漏洞获得您本来不是想要的信息。这对于应用程序升级也很重要。

要附加到C点,是的,您应该测试该应用程序是否正常工作。确保还检查正在部署的机器上的某种错误日志,以确保没有新的错误被创建。确保同一台计算机上的其他应用程序仍能像以前一样正常工作。

如果确实要移动机器,请确保具有相同的先决条件,即:COM的版本,先决条件的应用程序版本等。

有了更多有关您正在执行的部署类型(迁移,升级等)的上下文,我很乐于详细说明。

#7 楼

您使用什么工具@ sam-woods进行部署验证?

评论


欢迎使用SQA StackOverflow。请添加您的想法作为评论或新问题。

–demouser123
16年3月3日,9:22