9 评估系统

现在应该清楚的是，“可接受 ”是一个很难确定的概念。就信息系统而言，这取决于系统是如何建立或获得的，利益相关者是谁，他们的需求是什么。这个问题没有 “一刀切 ”的答案。我们需要了解并能够应用的是一种程序，用于确定特定系统在特定情况下是否可以接受，这也是本章将重点讨论的内容。

本章讲述的是接受或不接受一个系统的最终决定。当然，在实践中，这一决定并不简单，也不会只有两种可能的结果。
我们将探讨一系列可能出现的情况，每种情况都与是否以及在多大程度上符合验收标准有关。
本章涉及的主题：

• 如何决定是否验收一个系统？
• 何时必须停止测试
• 发布风险
• 衡量发布风险
• 定义和评估紧急发布标准
• 评估 UAT 结果的决策过程
• 测试总结报告结论
• 最终发布决策

9.0 习题

9.0.1 选择题

• 1. 验收的三个关键决定是什么？
     A. 建造是否承包给第三方？
     B. 是否有不可更改的最后期限？
     C. 是否有合同标准？
     D. 是否符合合同标准？
     E. 系统是否实现了业务效益？
     F.发布系统的风险是否可以接受？
• 2. 当测试必须提前结束时，如何通过提前 UAT 活动来降低风险？
     A. 采取了基于风险的方法 B. 持续评估了 UAT C. 较早的 UAT 活动对降低测试期间的风险没有影响 D. A 和 B 都对
• 3. 哪一个是风险评估最不可能的结果？
     A. 按原样发布系统 B. 推迟发布 C. 在额外支持下发布 D. 不发布（拒绝系统）

9.0.2 简答题

1.测试经理希望在 UAT 结束时召开一次会议，讨论系统发布事宜。他们应该邀请谁，为什么？

2.有一些关键缺陷仍未解决。这对发布风险和发布决定意味着什么？

9.1 我们如何决定是否接受一个系统？

简单的答案是，我们必须决定系统是否符合验收标准，但这一答案的前提是我们有一 套整齐划一的标准可供评估。如果你将本书中的建议铭记于心，并将其应用到你的项目中，那么你就应该有一套标准可供使用；如果没有，你就需要一个实际而务实的决策过程。

决定 1 涉及开发工作是否承包给了第三方，或者，从验收角度看，系统是否从第三方供 应商处购得。无论哪种情况，都会有一些合同标准作为最终付款的依据。这与系统验收不同，但却是必要的先决条件。
决定 2 假定存在合同标准，并询问这些标准是否得到满足。如果我们发现合同标准已得到满足，就必须向供应商支付货款，而且我们必须根据已交付的货物开展工作。如果不符合，我们就会与供应商进行某种谈判，最终达成和解，以便从我们的角度来看，这将改善我们的处境。这里的关键因素是合同标准与利益相关者设定的验收标准之间的关系。除非系统是为满足您的具体要求而专门定制的，否则不太可能完全吻合，在这种情况下，合同标准和验收标准将是一致的。在大多数情况下，合同标准与作为信息系统核心的计算机系统有关，而与信息系统本身无关。我们仍然需要确保整个信息系统满足我们的业务需求，并为我们的用户群所接受，这通常意味着要进行更多的测试和更多的工作，以实现可接受的发布，而且还要做出另外两个决定。

第 3 项决定询问系统是否达到了验收标准，这意味着可以实现建立或购置该系统的业务效益。对于合同系统来说，达到合同标准就可以做出这个决定；而对于内部构建的系统来说，这是第一个验收决定。请记住，验收标准是务实的，既要考虑系统的商业价值，也要考虑发布系统的风险。达到验收标准意味着我们现在有了一个平台，可以在此基础上建立业务价值，从而迈出发布系统的一步。但是，我们需要牢记，要确保发布的系统能够增加业务价值，实现最初委托的业务效益，可能仍有大量工作要做。系统的发布并不能保证效益的实现，因此，制定一项提高系统业务价值的计划仍将是一项优先工作。

决定 4 是一个后备问题，也是一个需要经常提出的问题；它询问释放该系统的风险是否可以接受。要对这一问题做出正确的回答，需要我们收集到的所有信息，而且所有利益相关者都需要做好准备，并愿意认真评估释放该系统可能带来的结果。这是一个理想的机会，可以利用某种情景分析来确定系统发布后可能发生的情况，并评估系统在当前状态下将如何应对，同时将目光从系统的直接边界转向任何性能或能力不足所造成的业务影响。
为这种风险评估制定情景假设是用户、开发人员、管理人员和发起人作为一个团队开展工作的好机会。即使系统满足了所有验收标准，情景模拟的工作也是非常有价值的，但如果不能满足所有验收标准，情景模拟的工作就绝对是无价之宝，它将加快使系统适合使用的进程。

9.2 何时测试必须停止

我们一开始就清楚地知道需要进行多少测试，也同样清楚地知道如何确定系统是否适合向用户发布。这一框架使我们能够计划和执行结构化测试，并收集有关测试状态和系统状态的数据。一旦完成计划并收集了所有数据，我们就可以停止测试并对结果进行评估，以决定是否接受该系统。
当然，这只是一种理想情况，我们不能指望在 UAT 项目结束时我们会面对这样的现实；我们需要为其他情况做好准备。其中可能包括：

• 企业无法再在项目上烧钱，需要将系统投入使用。
• 系统的效益对时间至关重要，而时间正在流逝。
• 测试发现的问题很少，甚至没有，因此很难证明进一步测试是合理的。

这些都是现实情况，我们面临的挑战是如何应对。我们的方法必须使我们能够在测试的任何阶段对系统进行评估，从而使所有这些情况都不会让我们措手不及。这就是为什么建议对测试进行例行报告，并且作为报告的一部分，定期更新验收标准的进展情况，以便我们在测试的每个阶段都能清楚地了解我们与发布决定之间的关系。
因此，第一条也是最重要的一条经验就是，对系统的评估必须是持续和一致的。也就是说，我们必须决定如何对系统进行评估，并从一开始就制定评估流程，以便在任何阶段都能对系统状态做出可信的评估。
如果我们不得不在测试完成前停止测试，无论出于何种原因，我们都需要对系统在当前状态下的发布风险和商业价值进行评估。

9.3 发布风险

我们在计划阶段所做的所有工作都是为了迎接这一挑战。我们制定了验收标准，以尽可能客观地决定是否适合发布。我们为测试覆盖率和缺陷水平设定了目标，使我们能够清楚地了解系统在每个阶段的状态。如果所有标准都得到了满足，我们就不难做出接受系统的决定。
但如果测试完成后仍未达到标准怎么办？如果停止测试时仍未达到标准怎么办？这些都是我们必须回答的最重要的问题。
一言以蔽之，答案就是风险。我们必须确定，发布一个尚未按照我们的标准准备就绪的系统的风险程度有多大。系统部分或全部失效的可能性有多大，失效的后果是什么？这就是我们一开始就决定基于风险的测试是一种好方法的原因。通过基于风险的测试，我们可以确信，每次测试都会降低一定程度的风险，而且，无论降低的风险多么微小，它都会日积月累，逐次测试。如果我们使用基于风险的方法进行了测试，我们至少可以说，在必须做出决定的那一天，我们所能做到的发布风险是最低的。
但是，无论我们是否采用了基于风险的方法，都不能改变在特定的时间和测试的特定阶段对系统发布的风险作出决定的必要性。
我们需要根据现有的最佳数据，围绕验收标准作出判断。实际的评估将取决于我们最初设定的标准，但我们可以定义一个适用于所有情况的流程。

9.4 衡量发布风险

如果我们在项目开始时通过仔细定义合同或验收标准做好了准备，并且在项目过程中对所有事件、缺陷和其他变更进行了控制，那么最终决策很可能是明确的，发布风险也可能很小。我们仍有可能为业务目的构建了错误的系统，或在某些方面偏离了我们的初衷，但对进度的监控会在相对较早的阶段发现这些问题。在是否发布的问题上，我们可能需要做出一个艰难的决定--艰难的意思是不受欢迎和不舒服--但我们应该做出一个简单的决定，因为正确或最佳（最合适）的结果将很容易确定。整个过程的目的就是让理性的决定成为可能，即使结果不是我们最初想要的，这一点也已经达到了。

另一方面，如果我们在一开始就没有确定合同或验收标准，或者我们没有认真监控开发和测试过程，以便在现阶段不断更新有关产出质量以及系统缺陷和事故状况的记录，那么我们就很难做出决定--这一次的困难在于，从现有信息中得出合理的结论并不容易。

因此，下文将考虑后一种情况。如果没有明确的接受标准，我们该如何着手？面对不完整且可能相互矛盾的信息，以及业务和时间压力使我们无法花时间收集和评估数据的情况，我们该如何做才能做出合理的决定？请记住，作为 UA 测试人员，我们不是决策者，但我们此时最接近系统，因此最有能力识别风险因素，并以有益、积极和建设性的方式向决策者报告--请始终记住，我们也将是系统发布前最后接触该系统的一组人员，因此我们至少要对结果负部分责任。

参考资料

• 软件测试精品书籍文档下载持续更新 https://github.com/china-testing/python-testing-examples 请点赞，谢谢！
• 本文涉及的python测试开发库 谢谢点赞！ https://github.com/china-testing/python_cn_resouce
• python精品书籍下载 https://github.com/china-testing/python_cn_resouce/blob/main/python_good_books.md
• Linux精品书籍下载 https://www.cnblogs.com/testing-/p/17438558.html

9.5 定义和评估紧急发布标准

如果我们没有积极的接受标准来确定我们希望从系统中得到什么，我们就必须依靠一些更具防御性的标准来保护自己免受麻烦。有三个参数对我们的决策有一定价值：

• 1.系统的稳定性；
• 2.系统的可用性
• 3.测试的覆盖面。

9.5.1 稳定性(Stability)

稳定性是衡量系统应对变化能力的标准。我们需要系统有足够的稳定性，以便制定改进计划，而改进计划几乎肯定会涉及对作为信息系统核心的计算机系统进行更改。如果计算机系统不能适应变化，我们就无法对其进行改进，以满足我们最初的期望。
我们至少必须确保了解系统的稳定性如何，这样我们才有信心根据需要进行必要的更改，以提高系统的业务价值、性能、可用性或其他参数。

• 衡量稳定性

评估稳定性的一种方法是查看在开发过程中进行了哪些更改、更改的原因以及更改后出现的问题（如果有的话）。要做到这一点，我们需要查看已发生的事件、已发现并纠正的缺陷以及在系统构建过程中做出的更改。测试日志将确认计划中的更改是否稳定，而 IM 系统将告诉我们，为纠正缺陷所做的更改是导致了新版本的发布，还是发现了更多缺陷。

如果我们能访问事件日志和变更日志，我们就能确定变更和缺陷之间的关系，了解变更是否会导致缺陷率激增。这是一个典型的不稳定性指针。

9.5.2 易用性

易用性在这里被非正式地定义为衡量用户操作作为信息系统核心的计算机系统的程度。如果用户在有效使用系统方面有困难，就很难对系统进行改进，因为用户将试图与一个对他们来说已经很困难的系统进行交互；改变系统可能会使情况变得更糟。

• 确定易用性

我们在这里所寻求的是一种非正式但可靠的评估，即在改进计划实施期间，用户能 够在多大程度上管理和操作该系统，以提供至少基本的服务。一个好的机制是定义一套核心的用户交互，使关键服务得以实现，提供广泛的用户交互，并创建一个用户可以以一致的方式进行操作的场景。然后，一小批经过培训但具有代表性的最终用户可以通过该场景进行操作，并提供体验反馈。每个用户在完成情境操作时都应计时，反馈应通过标准问卷或带有结构化问题的访谈进行。对于最终用户、管理人员和发起人来说，确定情景和反馈机制是一项很好的团队工作。
需要向用户充分介绍情况，以免他们对这项工作感到畏惧。
测试结果应能很好地反映用户对系统可用性的看法，而且这项工作还能从一开始就让最终用户群体参与到改进计划中来。

9.5.3 覆盖率

我们已经把测试的覆盖面定义为迄今为止已经测试了多少系统。稳定性和可用性的衡量标准必须与覆盖范围相比较，因为如果一个系统只测试了 25% 的需求，就不稳定或无法使用，那么这个系统将面临重大返工。而在另一个极端，如果一个系统已经针对 90% 的要求进行了测试，并且相当稳定和可用，那么作为改进平台，它的风险就很低。

我们需要认真考虑我们在整个生命周期和 UAT 阶段所做的测试，并确定这些测试是否足以作为任何决策的基础。

• 确定测试覆盖率

如果我们没有设计测试以达到特定的测试覆盖率水平，我们仍然可以尝试确定已运行的 测试用例中测试了哪些内容。首先，我们需要分析一些测试用例，以确定它们与需求的关系。这需要由测试专家、业务分析师或开发人员来完成；这可能需要一些技能和洞察力，我们无法合理地期望最终用户具备这些技能和洞察力，而且我们需要快速完成这项工作。样本分析完成后，我们就可以用一种简单的方法来确定整个 UAT 套件的需求覆盖率。我们可能会发现需求覆盖率很高，在这种情况下，测试是相当有效的。
如果我们发现覆盖率很低，就应该担心在重要领域可能存在未被发现的缺陷。
如果初步分析无法确定覆盖率，例如，测试是在没有参考需求的情况下进行的，我们只能得出需求覆盖率很低的结论。这本身并不一定是改进计划的障碍，但它指出了潜在的问题所在，也肯定指出了改进计划中必须填补的空白--实现系统测试，为将来的变更提供覆盖率数据。

• 确定是否达到了应急标准

利用我们能找到的所有有关事件、缺陷、变更、可用性和覆盖范围的数据，我们应该能 够得出一些有关发布风险的结论。数据可能无法得出详细的结论，但如果简短的调查不能得出释放风险相对较高或相对较低的结论，那将是不正常的，而这对我们的目的来说可能就足够了。

这三个标准是我们的紧急备用标准。从任何意义上讲，它们都不能替代更严格的验收标准，因为它们为我们提供的只是一个衡量标准，让我们相信计算机系统是一个适合逐步改进的平台。这是在我们制定计划将系统提升到我们最初预期和支付的水平时，为保持系统活力所做的最后努力。

9.6 评估 UAT 结果的决策过程

我们现在有了一个对 UAT 结果进行总结的通用过程。详细程度和结论的坚定性将取决于所做测试的范围和质量以及所做记录的详细程度，但每种情况下的方法都是相似的。

• 第 1 步--合同验收

如果（也只有在）签订了外部合同来构建我们的系统，或者如果系统是在经过或不经过修改的情况下购得的，那么肯定会有与供应商验收系统相关的标准。这些标准很可能与我们为自己的验收决策所定义的标准相似，而且这些标准应该是可衡量的，这样验收的决定才会一目了然，不会引起争论。第 1 步是评估这些标准（或标准中与测试有关的部分），并将结果报告给相关利益方，同时提出是否接受的建议。
在这一步完成之前，流程无法进入下一步，因此在进入第 2 步之前，需要完成任何差异或谈判。
如果在开发过程中没有第三方合同参与，则进入第 2 步。

• 第 2 步--满足验收标准 我们自己的验收标准是基于业务意图的实现程度。这些标准也应该是可衡量的，并且可以相对直接地进行评估。
  在整个 UAT 过程中，我们应该一直在跟踪离实现这些标准还有多远，因此最后的评估应该不需要大量的工作。它应明确确定系统是否符合其业务意图，并应向相关利益者报告，同时提出建议。这通常以 UAT 完成报告的形式出现，报告应准确描述为 UAT 所做的测试，以及与验收标准相关的测试结果。
  如果没有达到验收标准，利益相关者的决定需要 UAT 团队提供一些意见，因此我们需要确保在 UAT 完成报告中根据每项验收标准对系统的性能进行评估，确定系统离达到标准还有多远，并评估任何差距的影响。在此分析基础上，报告应提出可能的替代行动方案，供利益相关者考虑。

• 第 3 步--评估发布风险

无论何时，只要未达到验收标准，我们就应该对系统在当前状态下的释放风险进行评估。第 2 步概述了这一机制，但如果与验收标准相关的数据有限，我们可以使用 “定义和评估紧急释放标准 ”一节中概述的方法。在这种情况下，我们的结论通常会比明确评估验收标准的结论更具暂定性，因此通常需要更多的评注，以便利益相关者能够自行评估可能的结果以及与每个结果相关的风险，从而做出发布决定。

9.6 结论

完成报告中的结论需要围绕业务意图的实现程度以及与发布系统相关的风险水平来构建。在这一点上，我们可以确定一系列可能的建议。

• 结果 1 - 按原样发布系统

这是最乐观的结果。这意味着业务效益已经实现，发布的风险很低。验收标准中可能存在一些差异，但这些差异并不严重，不需要采取任何具体措施。

• 结果 2--推迟发布，直到关键的降低风险措施到位

结果 2 意味着业务效益尚未完全实现，发布风险相对较高。关于降低风险活动的建议也可以与提高系统可实现的业务效益的活动相匹配。

例如，如果认为尚未纠正的缺陷的数量和严重程度都很高，建议可以推迟发布，同时改善这种情况。改进需要一定的时间，需要一定的开发资源，这就为利益相关者提供了一系列策略，可以在更多或更少的时间内，利用更多或更少的资源，实现更多或更少的风险降低。这样就可以将时间或商业压力等其他因素考虑在内。在这种情况下，谨慎的做法是对稳定性和可用性进行衡量，以确保在不增加系统故障风险的情况下实施风险降低和改进计划。

• 结果 3--在提供额外支持的情况下发布系统

另一个可以考虑的方案是立即或提前发布系统，但在系统支持方面投入额外资源，以抵消早期问题的风险。这显然取决于预期问题的性质，并将以风险分析为基础。如果风险与可能出现的用户界面或性能问题有关，而这些问题可以在相当短的时间内得到 解决，则可以选择加强用户支持（例如，提供额外的帮助资源，根据测试结果建立常见问答清 单，使支持人员能够快速诊断问题并提出有效的 “变通办法”）。
至于结果 2，可能会有一系列可能的应对措施。在这里，对稳定性和可用性进行测评也是谨慎之举，以便使人相信，在不增加系统故障风 险的情况下，可以实施风险降低和改进计划。

• 结果 4--推迟发布，降低风险，提供额外支持

结果 4 显然是结果 2 和结果 3 的结合。如果系统实现其主要功能的能力存在风险，需要在降低风险的同时推迟发布，而且还存在与用户界面或性能有关的潜在问题，那么这就成为一个重要的备选方案。用于降低风险所花费的时间很可能需要大量的开发资源，因此短期内无法纠正不太关键的缺陷。因此，当系统延期后发布时，额外的支持会缓解问题。
在这种情况下，必须对紧急发布标准进行评估，以确保系统能在现实的时间内以合理的成本达到可接受的标准。

• 结果 5--否决系统

结果 5 是一种合乎逻辑的可能性，但在现阶段不太可能成为一种结果，因为在达到这 一阶段之前，从开发和测试中得到的反馈很可能已经发现了严重的问题。

9.7 最终发布决定权

最终发布决定权掌握在利益相关者而不是 UAT 小组手中，但 UAT 小组组长必须随时准备提供咨询和建议。
无论作出何种发布决定，UAT 小组的结果、数据和经验都可能对决定如何进入下一阶段很有价 值，无论下一阶段是改进计划还是立即发布系统。

9.8 小结

本章总结了 UAT 结束时可能出现的各种情况，并为每种情况确定了适当的结果和下一步措施。
阅读本章后，您应该能够回答以下问题：

• 如何确定系统已准备就绪可以使用？
• 如何确定软件投入使用的风险是否可控？
• 谁来决定系统是否可以验收？
• 谁来决定是否达到验收标准？
• 如果没有完全达到验收标准会怎样？
• 如果部分达到验收标准，我们该如何做才能将风险降到最低？

9.9 参考答案

9.9.1 选择题

• 1 D、E、F

答案 A 不正确。这是决策逻辑的一部分，但不是决定接受与否的因素。
答案 B 不正确。这很可能是一个挑战，但不能自动决定是否接受。
答案 C 不正确。这也是决策逻辑的一部分，但不能决定是否接受。

• 2 D
  答案 A 不正确。基于风险的测试策略有助于降低风险，但如果测试提前结束，该策略可能没有完全实施。
  答案 B 不正确。持续评估对确定验收标准的进展很重要，但如果测试提前结束，就不能减轻风险。
  答案 C 不正确。UAT 中的所有活动都有助于最终的风险结果。例如，确定基于风险的测试策略是一个关键步骤。
  答案 D 是最佳答案，因为它把基于风险的方法与持续评估结合起来，这样就可以监控风险缓解情况，并在测试必须停止时作出明智的判断。

• 3 D

答案 A、B 和 C 都有或多或少的可能性。如果 UAT 已进展到风险评估阶段，那么就不太可能存在严重缺陷；对于存在重大问题的系统来说，继续开发和测试到这一阶段的成本会很高，而且会更早采取行动，因此不可能完全拒绝。

9.9.2 简答题

• 1. 测试经理希望在 UAT 快结束时召开一次会议，讨论发布问题。他们应该邀请谁，为什么？

有两组相关方，即参与 UAT 的人员和利益相关者。
这两类人的代表都应出席会议。理想情况下，会议不应该是关于测试成功和进展的首次沟通。参与 UAT 的人员应准备好以一种对发布决策有意义的方式解释 UAT 结果，而利益相关者则应准备好根据数据做出决策。与会人员的相关观点越多，会议就越有可能得出合适的结论。