也许有或也许没有实际的可执行程序作为 LCO 简报的一部分。这些可能由技术示范者、现有产品的快速出租，或者也许是更实质的东西组成。我的意见是在如此初步的阶段执行如此正式的操作是不适当的。
因为测试成本对总的开发成本做出贡献，所以我已经列出许多对测试成本做出贡献的行为。
测试风险
风险需要减轻计划，减轻风险需要花费金钱。测试风险是各种各样的。例如，需求可能迅速地变更，这可能会破坏可测试性或测试成本设想。后继的精化阶段可能会利用新的测试难点的解决方案来解决技术风险。可能需要遵守 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 个同时发生的用户会话。”这些需求写起来便宜，但满足和测试起来昂贵。为了进行适当的评估，我们需要了解：
文章来源于领测软件测试网 https://www.ltesting.net/
