测试风险
风险需要减轻计划，减轻风险需要花费金钱。测试风险是各种各样的。例如，需求可能迅速地变更，这可能会破坏可测试性或测试成本设想。后继的精化阶段可能会利用新的测试难点的解决方案来解决技术风险。可能需要遵守 MC/DC（Modified Condition/Decision Coverage）测试、ISO 标准、SEI 标准，IEEE 标准，等等这样的标准。 1 这些标准可以减少整个业务成本，但是顺应成本在某种程度上落在测试人员上，并且应该更加明显。可能存在与数据安全相关的政府规章，如保密性规章，使对“真实”数据的测试变得困难或昂贵。
可测试性
可测试性与可行性直接相关，并且很可能找到很难测试的高层次需求。一些需求是非可测试的，因为他们是主观的，或者不是有助于度量或量度的。一些是不可测试的，因为从技术上很难安排一个合适的测试。例如，一些战略防御计划（Strategic Defense Initiative，SDI）的批评家提到在美国执行其导弹防御的可接受性测试时，让苏联启动非武装的洲际弹道导弹（Intercontinental Ballistic Missile，ICBM）的困难。在软件开发项目中，这种情况发生于格外昂贵的硬件不能为了测试很容易地重新执行任务的时候，或者当独特的环境因素使测试的安排变得困难时。
准备测试实验室
通过“实验室”，我的意思是一个环境，在其中有我们测试每个需求所需要的东西，一个被提供但与产品环境有很难区分的不同。即使我们在早期的需求发现阶段，仍有可能估算您很可能需要的资源。
资源可能包括 1) 硬件、计算机、网络，以及由慢速管道或很长的往返传递，及防火墙所引起的瓶颈，2) 软件，包括测软件及其他必需或采用的软件，所有的都处于已知版本层（或根据所有版本进行测试！），3) 测试软件，如测试经理，测试自动化软件，如记录或回放 GUI 测试人员，以及用于可伸缩测试的用户虚拟化，4) 数据，包括用于冒烟测试和功能测试的小型数据集，以及用于可伸缩性测试的大型数据集。
注意到尽管潜在的实验室特性的列表很长，我们还必须在存在相应的实际需求的地方指定实验室需求。例如，不是所有的系统都有可伸缩性需求，所以不是所有的实验室都将需要用户虚拟化工具。
估算需求或场景的整体测试成本
大多数需求将作为普通的功能需求出现。与测试相关的成本通常与编码或设计的成本大致成比例，因此测试工作一般来说将是编码和设计成本的某个比例（比方说 25％）。此系数将具体到每个组织，并且可以通过收集一两个项目量度按经验寻找。
系数将被平台的数量或所需的其他类型的测试工作副本所修改。 2
缺陷管理、构建，发布过程
存在与将测试人员插入开发过程中有关的成本。测试人员共享其他项目团队使用的特定开发工具，如用于缺陷跟踪的工具，以及构建和发布工具，如用于配置管理的工具。
精化（Elaboration）阶段：管理技术风险
RUP 的精化阶段是对准技术风险的管理的。为了制定出自该阶段的可行或不可行的决策，我们需要论证一个对每个鉴别出的技术风险的满意解决方案。通常，最糟的技术问题由非功能需求导致。非功能需求可以造成这样的有趣断言“系统将拥有 99.999％ 的可用性，”或者“系统将支持 10,000 个同时发生的用户会话。”这些需求写起来便宜，但满足和测试起来昂贵。为了进行适当的评估，我们需要了解：
在完成极端的非功能目标中可能隐含的权衡。
当接近这些极限时各种架构退化的方式。
有了此数据，架构师可以选择最适当的架构，并且，当涉众面对他们需求的所有含意时，通常会更愿意调节他们的雄心，并且得到更多的回报。
因此，关键的评估需求是其中一个度量，并且这应该是此阶段测试人员主要的目标。
量度方法的评估
对于每个技术问题，架构团队将建立一个或多个具体表现一个解决方案方法的可执行系统。可能会有若干有竞争的解决方案（举例来说，通信中的 UDP 对 TCP）和大量的对于每个解决方案的可配置选择（举例来说，进程架构中的 10 线程 对 50 个线程）。测试人员执行对生成架构的度量所必需的步骤。
度量强调的是是否对解决方案有了成熟的考虑而不是功能是否被正确的实现了，因为没有人会期望生命周期中早期就实现完全正确的功能或者甚至花费大量的精力去雕琢还不成熟的系统的功能。初始阶段中指定的许多实验室环境将在精化阶段中被需要。我们将度量性能和可伸缩性，跨过通信链接和出自数据库的数据速率，随负载变化时的响应时间，并且我们将生成需求所要求的其他度量。根据所有的架构原型执行这些测试，并且测试团队将与架构师携手工作，共同设计确认或驳斥每个设计决策的测试。
文章来源于领测软件测试网 https://www.ltesting.net/
