3.1.1 在需求分析阶段
需求是测试的源头。测试架构师在需求阶段的重点工作包括：
·理解需求。
·制定一份总体测试策略，以此来确定测什么和怎么测。
测试架构师应该在项目启动时就参与进来，和产品人员、系统架构师一起理解用户的需求。但问题是，如何才算“理解需求”呢？是不是只要参与每一场需求的讨论会，熟读每一条需求规格就够了呢？要想真正对需求有透彻理解，理解所测产品的商业目标、核心价值和用户的使用场景是第一步，也是测试策略的源头。
1.理解产品的商业目标和核心价值
Dave Hendricksen在他的著作《软件架构师的12项修炼》中提出：“系统架构师在考虑软件架构的真正价值时，不能只关注系统构造的技术，更要对客户价值和商务价值——你能帮助客户真正解决怎样的问题、你怎样帮助公司赚钱——有深刻的认识。”原因在于，即便产品使用的是最先进的开发技术，只要不能满足用户的需求，就没有价值，这样的产品就是无用的产品，不能称为成功的产品。这一点对于测试架构师来说同样适用：测试架构师在制定测试策略时，也需要基于特性的价值来分类，来设置优先级、测试的重点，以及不同的测试深度和广度，以此来保证测试资源的最优分配和投入方案。
如何理解产品的商业目标和价值呢？Dave Hendricksen用一个气泡图形象地概括了商务知识和软件架构的交错关系，如图3-1所示。
图3-1 Dave Hendricksen的气泡图
认识我们所在的领域，了解我们的公司、客户及商务，这是我们能做出最合适的测试策略的前提和基础。下面这些问题可以帮助测试架构师获得答案。
·公司中的营销人员和销售人员如何细分客户？
·每个细分市场的关键价值主张是什么？
·公司试图增长哪些细分市场？如何增长？
·每个市场是谁做出购买决策的？
·每个细分市场的主要竞争对手是谁？
·公司对此产品的策略主张是什么？产品是如何融入这一战略的？
测试架构师要能围绕下述内容展开测试活动。
·如何验证待测试的产品正确体现了市场价值？
·所做的测试策略是否和公司的财务、销售、营销目标一致？
当测试架构师对这些内容进行深入思考，并通过沟通交流和决策者、系统架构师、市场人员等角色达成一致、统一的目标时，测试就能很自然地融入其中，成为公司的伙伴，而不是成为阻碍软件按时发布的“拦路虎”。这样测试也能更容易获得决策者和产品开发人员的认可，测试的深度、广度会更透明，从而利于测试者更好地把握测试进度。这样也可通过压缩测试时间来换取项目进度。（很多时候都会存在压缩测试时间来保证项目进度的问题，出现这样的问题，很大一部分原因是决策者根本不认可测试的内容和方法，认为测试过度或者冗余过多，没有准确评估测试真正的工作量。）
2.梳理用户的使用场景
梳理用户的使用场景是测试架构师需要重点关注的另外一项内容。
所谓“用户的使用场景”，简单来说就是用户将会如何使用这个产品。用户场景将直接体现产品的价值。因此，在测试之前，了解你的用户至关重要。
·产品有多少种用户？这些用户的业务是什么？他们如何从你的产品中获得价值（比如通过你的产品赚钱或获得某种资源）？
·产品的竞争对手为用户提供了哪些有价值的解决方案？你们之间的差异是什么？
·产品所在领域有哪些基本的规范和要求？行业背景有哪些？用户的习惯是什么（如完成各种活动的顺序、对活动完成的判断标准和可能的重要决定等）？
测试架构师还需要把梳理得到的用户使用场景归纳为测试场景，具体如下。
·针对不同类型的用户，分别确定这些用户的行为习惯和关注点。
·逐一分析这些用户会如何使用产品，根据分析结果建立产品的拓扑模型、配置模型、流量模型等，抽象出典型场景。
·确定各个典型场景下的输入和输出（包括正常输入和异常输入、攻击，还需要考虑模拟测试的时间长短等）。
3.输出产品总体测试策略
产品总体测试策略是测试架构师的重要输出之一，它就好像测试的总纲，帮助整个测试团队明确测试的范围、目标，测试的重点和难点，测试的深度和广度，以及如何安排各种测试活动（及测试分层）。
注意，测试重点和测试难点是完全不同的两个概念。测试重点是通过产品价值、质量目标、产品实现（新写代码、开源代码或是继承代码）、历史情况（主要针对继承类产品）和风险等多个因素确定测试的优先级；测试难点是从测试技术的角度对产品测试验证难易程度进行分析。
测试深度和测试广度也是不同的。测试广度是从所能覆盖的测试类型的角度对产品测试进行的描述；而测试深度是从测试方法（如单运行测试、多运行测试、边界值或错误输入等）的角度对测试进行的描述。
测试分层让我们把一个复杂的测试分成多个不同的阶段，每一个阶段都有自己的测试目标和出入口条件，我们可据此来安排测试活动，让测试过程变得有序、可控。
除此之外，我们还可以使用缺陷趋势预判技术，得到当前的缺陷趋势预判图，通过量化评估的方式为我们后续调整测试策略提供依据。
上述内容构成了测试的整体框架，如图3-2所示，对此更详细的描述可参见第6章和第7章。如果把测试需求分析、测试分析设计、测试执行、测试质量评估等测试活动比做珍珠，测试策略就是那根穿珍珠的线。