对于整周期软件开发项目的测试而言，上述过程组的内容会有较大的差异。
比如：项目章程将重点关注开发，而不会过多讨论测试相关的工作。对于这一类型的软件测试，笔者建议在任命开发项目经理的同时，由项目经理[适用于项目型或强矩阵组织]或高层经理[适用于弱矩阵或职能型组织]指定项目测试经理。测试经理应根据项目章程、项目初步范围说明书和项目建议书尽早开始软件测试相关规划和设计(即会先粗略地进行软件测试需求分析和软件测试设计，以后再进一步细化)，并和项目经理沟通、协调，以将一些重要的信息及时反映给项目经理，从而使项目计划能较好地支持测试工作的开展。
二、软件测试需求分析
理论上，软件测试需求是源于软件需求的，而软件需求又是源于用户需求的。然而，有些时候在分析软件测试需求时并不存在已经文档化的软件需求规格说明。
在这种情况下，要分析软件测试需求可能仍然需要追溯到用户需求(当发生这种情况时，普通测试工程师会很吃惊地发现自己原来还肩负着需求开发工程师的部分职责。是的，事实上，资深的软件测试工程师会发现软件测试这个职位几乎涉及所有的开发技能和部分管理技能。)由于后者涉及需求工程的专门知识，本文略过不做细述;这里重点讨论前者。在一个规范化的软件需求规格说明中，用户需求是由更高层次的业务需求(体现在项目章程、SOW、项目建议书等文档中)细化而成，它通常描述了用户使用该软件系统会涉及到的不同的执行路径、工作逻辑以及所预期的处理结果。
在UML表示方法中，用户需求通常通过Use Case来进行刻画。接下来，用户需求将进一步转化为三类需求项，即功能需求项、性能需求项以及约束性需求项。这三类需求项就是通常意义上的软件需求项。管理这三类需求项的矩阵被称为需求矩阵。
理论上，在测试资源许可并且确有必要的前提下，测试的使命将是验证和确认待开发的软件及其中间产品满足需求矩阵各个需求项。(注意：为了简化讨论，这里笔者没有把需求的验证与确认纳入进来，实际上这部分工作也是软件测试工作的重要组成部分。详细论述请参阅拙文《试论软件测试学科架构建设》)然而，几乎没有几个公司或开发团队能够提供这类测试所需的诸多的资源，此时，一种可行的策略是将待测试的软件需求项按照优先关系进行排序，以帮助测试经理决策在既定资源的情况下，应该如何统筹安排测试工作。
软件需求项是测试需求分析的起点，这一点在工程实践中并不绝对。
对于不同阶段的测试(这里主要指单元测试、集成测试、系统测试和验收测试，暂不考虑验证技术和需求设计确认)，测试需求开发所涉及的工作内容和方法都会略有差异。例如，如果是一个验收测试，那么，除了个别的需求需要做进一步明确外，几乎可以将测试需求等同于用户需求和业务需求(由于该类测试是以客户为主体，因此并不需要向下追溯到软件需求);
又如，如果是系统测试，除了需要对不具备可测试性的软件需求项进一步开发外，
文章来源于领测软件测试网 https://www.ltesting.net/
