使用至 SharePoint 2013 的试验升级查找潜在问题
适用于：
2013 
2016 2019 Subscription Edition SharePoint in Microsoft 365
在开始从 SharePoint 2010 产品升级到 SharePoint 2013 之前，应测试升级过程以确保确切了解要成功进行升级所必须执行的操作。 测试该过程的试验升级可显示以下问题：
升级规划是否适用或者是否必须进行调整。
自定义项位于您的环境中，以便能够规划在升级过程中处理它们。
您是否应升级硬件以提高升级的效率和速度。
升级的时间，即在您的环境中进行升级将用多长时间。
您必须在操作上规划哪些内容 － 例如，要提供的资源。
此外，您可以使用试验升级来熟悉升级工具以及过程本身，以便了解执行实际过程时的预期结果。 通过测试，您可以发现以下问题：
升级用户界面什么样？ 如何知道您已完成一个阶段并将转入另一阶段？
日志文件位于何处，如何读取日志文件？ 日志文件提供什么信息？
是否必须调整升级过程中使用的任何脚本或命令，尤其是当您依赖于用于升级到 SharePoint 2010 产品的任何脚本时。
是否具有适当计划以解决任何中断问题。
本文介绍了用于测试升级的基本步骤，并给出了有关根据在测试过程中了解的信息来审阅结果和调整升级计划的建议。
此外，在测试升级过程时，以下资源可能非常有帮助：
SharePoint 2013 - 测试升级过程模型
下载 SharePoint 2013 Products Preview - Test Your Upgrade Process model（SharePoint 2013 产品预览 - 测试升级过程模型）海报，直观了解如何测试升级过程。
请查看从 SharePoint 2010 升级到 SharePoint 2013 的最佳做法中的测试升级过程最佳做法。
设置测试环境
可以使用虚拟或物理硬件来测试升级过程。 每个环境都是独一无二的。 因此，对于升级需要多长时间或特定自定义项升级的难度，没有一般准则。 衡量升级方式的最佳方式是执行一系列试用版升级。
创建测试环境时要考虑以下一些内容：
使测试服务器场与实际服务器场尽可能保持一致，例如，具有相同的硬件、软件和可用空间。
在测试服务器场和实际服务器场中使用相同的 URL。 否则，您将会浪费时间来诊断实际升级中将不会出现的 URL 相关问题。 您可以通过使用相同 URL 并且仅从具有主机文件更改的计算机中进行测试来实现这一点。
为 Web 和应用程序服务器使用不同的计算机名称。
这将防止 Active Directory 域服务 (AD DS) 冲突。
为测试服务器场使用运行 SQL Server 的独立服务器
如果要为测试和生产服务器场使用运行 SQL Server 的同一服务器，则您会在运行测试时影响生产服务器场的性能。 建议您为生产和测试服务器场使用不同的 SQL Server 计算机（不仅是实例）。
在测试环境中使用相同的数据库名称。
这样就可以验证用于管理环境的任何脚本。 同样，确保使用运行 SQL Server 的独立服务器，否则会面临影响生产环境的风险。
确保将所有设置和自定义项传送到测试环境。 确定和安装自定义项一节中提供了有关收集此信息的说明。
确保您在测试环境中执行的操作不会影响实时环境。 请注意以下内容：
外部数据连接
虽然使用的是环境的副本，但指向数据源的链接是真实的。 对测试环境中的数据所做的更改会影响生产环境。
仍在生产环境中对实时数据库运行命令
确保将数据库的副本而不是生产环境中的活动版本用于测试。 例如，如果对实时数据库而不是副本运行 Test-SPContentDatabase ，则可能会影响生产环境的性能。
使用虚拟测试环境
当使用虚拟化环境进行测试时，无需具有大量硬件。 只需使用两台运行 Hyper-V 的服务器即可复制您的环境。 其中一台服务器具有前端 Web 服务器和应用程序服务器的映像，另一台服务器具有数据库服务器的映像。
但是，虚拟环境可能具有与物理环境不同的性能度量标准。 如果生产环境是物理的，则在计算升级生产环境所需的时间时必须考虑此差异。 一般而言，如果为 SQL Server 使用物理服务器，则可获得更好的性能估计。 确保它具有与生产环境中运行 SQL Server 的服务器类似的性能指标。
虚拟测试环境中服务器的分布
使用物理测试环境
在使用物理环境进行测试时，您必须以尽可能接近的方式复制建议的生产服务器场环境。 如果过度减少前端 Web 服务器、应用程序服务器或数据库服务器的数目，将无法准确估计升级过程所用的时间。 可能无法了解相同角色服务器之间进行交互（如 SQL Server 事务）的复杂性。 如果建议的生产服务器场中有多台服务器属于同一个角色，请在测试服务器场中为该角色至少使用两台服务器来测试此类问题。
物理测试环境中服务器的分布
确定和安装自定义项
为了使测试过程准确无误，您必须查找当前环境中的所有自定义项，并将它们复制到测试环境。 有关必须识别的自定义类型的详细信息，请参阅在 升级到 SharePoint 2013 期间为当前自定义项创建计划。
对 SharePoint 2010 产品 环境中的所有内容数据库使用 Stsadm -o enumallwebs 操作，以确定子网站中的特定自定义项。 此操作会列出环境中每个网站集和子网站的 ID，以及网站所依赖的模板。 有关详细信息，请参阅 Enumallwebs：Stsadm 操作。
使用 WinDiff 之类的工具（大多数 Microsoft 操作系统都提供此工具）将生产环境服务器与测试场服务器进行比较。 您可以使用此工具来了解服务器上存在哪些文件以及这些文件之间的差异。
检查 web.config 文件是否有任何改动，并查看 SafeControls 元素以查找任何自定义控件。
创建已找到的所有自定义项的列表。 如有可能，确定自定义项的来源。 例如，是否有在内部自定义的第三方外接程序或模板？ 确定来源之后，可以检查这些自定义项是否有更新或升级版本。
提示
对于不是您创建的自定义项的相关问题，您应与谁联系？ > 如果你对从 Microsoft 网站下载的模板有问题，请联系 Microsoft。 > 如果遇到他们为早期版本提供的模板或组件的问题，请联系第三方解决方案供应商。 可能会提供升级版本。
在识别所有自定义项之后，请将它们复制到测试服务器场中适当的服务器上。 确保部署了以下自定义项：
解决方案 - 默认情况下，旧式解决方案部署到 /14 目录。 当您安装解决方案以将其部署到 /15 目录时，请使用 CompatibilityLevel 参数。 有关详细信息，请参阅 Install-SPSolution。
自定义母版页
自定义 JavaScript
自定义 CSS 文件（包括主题的那些文件）
自定义工作流操作（必须包含在操作文件中）
确认大型列表查询限制设置以确保大型列表按预期方式显示。
测试自定义项时，请使用以下指南：
检查可视化更改。
检查行为更改。
在 2010 和 2013 模式网站集中测试。
查找任何语言或资源加载问题。
在自定义项存在于 2010 模式时可能出现此问题，且新的自定义项将在 2013 模式中替换它们。 因为只存在一个语言资源的全局目录，所以加载正确文件时可能存在问题。 确保替换 2013 自定义项包括 2010 资源以便自定义项可以继续在两个模式中正常工作。
确认升级未影响自定义项。 确保自定义项不会阻止网站集升级。
在将数据库附加到 SharePoint 2013 之前，可以使用 Test-SPContentDatabase Microsoft PowerShell cmdlet 来确定环境中是否缺少任何自定义项。 在将数据库还原到数据库服务器之后但在运行升级之前，请为每个数据库运行此命令。 请注意，此 cmdlet 以静默方式运行，除非发现问题，否则它将不会返回任何输出。
将真实数据复制到测试环境并升级数据库
除非使用实际数据，否则将无法实现测试目标。 使用 Microsoft SQL Server 备份和还原工具创建内容和服务数据库的副本。
没有比对所有数据的副本执行测试更好的方法来判断升级过程中可能发生的情况。 但是，对于初始测试，这可能并不总是一个现实的选项。 可以通过一次测试一个数据库来分阶段进行测试， (数据库是否为大型) ，以确保测试该数据集的唯一内容。 或者，可以从环境中具有代表性的站点组合一部分数据。 如果要首先使用数据的子集进行测试，请确保该子集具有以下特征：
数据子集包含您的环境所支持的典型网站。
该数据子集的大小和复杂性与环境的实际大小和复杂性非常相似。
重要
测试数据子集并不会生成关于处理环境的全部数据量将花费多长时间的有效基准。
复制数据之后，先执行一遍升级过程以观察发生的情况。 这只是首轮测试。 按照将 内容数据库从 SharePoint 2010 升级到 SharePoint 2013 中的步骤尝试数据库附加升级过程。
当测试升级过程时，确保测试跨服务器场共享的服务。 考虑所有状态，例如以下内容：
连接到 SharePoint 2013 服务场的 SharePoint Server 2010 场。
连接到 SharePoint 2013 服务场的 SharePoint 2013 场。
不同服务的不同版本服务器场。
使用测试环境发现服务应用程序的任何安全性、配置、兼容性和性能问题。
在升级数据库后查看结果
测试升级完成之后，可以审阅结果并重新检查计划。 查看日志文件、查看升级的网站，并签出自定义项。 对于您的环境，升级的工作情况怎么样？ 您发现了什么情况？ 您需要如何重新考虑升级计划？
查看日志文件
查看升级日志文件和升级错误日志文件（在运行升级时生成）。 升级日志文件 (.log) 和升级错误日志文件 (.err) 位于 %COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\15\LOGS 中。 日志文件按以下格式命名：Upgrade- YYYYMMDD-HHMMSS-SSS.log，其中 YYYYMMDD 是日期， HHMMSS-SSS 是 24 小时制格式的时间 (小时，分钟、秒和毫秒) 。
日志文件的格式遵循统一日志记录系统 (ULS) 约定。 若要查看日志文件以找出并解决问题，请从日志文件的开头开始查看。 如果某些错误或警告在环境中的多个网站集中出现，或者这些错误或警告完全阻止了升级过程，则它们可能会在日志文件中反复出现。 例如，如果您无法连接到配置数据库，升级过程将尝试（并且失败）多次，这些尝试将在日志文件中列出。
在 2010 模式中查看网站
确保未升级的网站集在 2010 模式中按预期方式工作。 网站的外观和行为应与在 SharePoint 2010 产品 中一样。 预计需要一些更改。 例如，Office Online 和 Web 分析功能在 SharePoint 2013 中已更改，使用这些功能的网站将受到影响。 有关要查找的特定内容的信息，请参阅 从 SharePoint 2010 升级到 SharePoint 2013 的过程概述。
如果需要，请再次运行升级
如果需要，可以使用 Upgrade-SPContentDatabase Microsoft PowerShell cmdlet 重启数据库的升级过程。 有关此 cmdlet 的详细信息，请参阅 Upgrade-SPContentDatabase。 有关详细信息，请参阅重新启动至 SharePoint 2013 的数据库附加升级或网站集升级。
升级网站集和我的网站
在测试和验证内容和服务数据库的升级后，可以测试网站集的升级过程。 按照将 网站集升级到 SharePoint 2013 中的步骤测试网站集升级过程。 如果环境中有“我的网站”，请参阅 从 SharePoint 2010 升级到 SharePoint 2013 的过程概述 ，详细了解升级过程。
注意
有关“我的网站”的内容仅适用于 SharePoint 2013。
在升级网站集后查看结果
在生产环境中运行升级过程之前，请直观地审阅升级后的网站以找出任何需要解决的问题。 有关要查找的特定内容的详细信息，请参阅 从 SharePoint 2010 升级到 SharePoint 2013 的过程概述。
从上到下开始，查看网站集升级日志文件以检查任何问题。 检查日志文件结尾附近的摘要部分以查看问题数和实际升级状态（如果没有状态，则意味着升级过程失败且必须重试网站升级）。 网站集日志文件存储在网站集本身（在 _catalogs/Upgrade 文档库）中以及文件系统中。 如果需要有关问题的详细信息，文件系统日志文件可提供更多信息。 网站升级日志文件的文件系统版本位于 %COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\15\LOGS 中。 日志文件按以下格式命名： SiteUpgrade-YYYYMMDD-HHMMSS-SSS.log，其中 YYYYMMDD 是日期， HHMMSS-SSS 是 24 小时制格式 (小时、分钟、秒和毫秒) 。
调整计划并再次测试
重复测试过程，直至您确信已找到了所有可能面临的问题，并且知道如何处理这些问题。 您的目标是明确以下问题：假设现在是星期日下午 4:00，您必须在星期一早上重新实现联机，但升级进行得不顺利，这种情况下您有什么计划？ 您是否已经没有退路？ 请测试您的回退计划，并在您开始实际升级之前确保该计划的有效性。
另请参阅
其他资源
从 SharePoint 2010 升级到 SharePoint 2013 的最佳做法
将数据库从 SharePoint 2010 升级到 SharePoint 2013