软件测试是在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程测试项目的启动、规划以及测试项目需求分析往往是很多软件服务型企业的薄弱环节所在。软件测试描述一种用来促进鉴定软件的正确性、完整性、安全性和质量的过程。换句话说，软件测试是一种实际输出与预期输出间的审核或者比较过程。本文围绕该难点问题，重点讨论了这两个阶段所应进行的项目活动以及相关工作流程。
文章源自玩技e族-https://www.playezu.com/12907.html
文章源自玩技e族-https://www.playezu.com/12907.html
文章源自玩技e族-https://www.playezu.com/12907.html
文章源自玩技e族-https://www.playezu.com/12907.html
一般地，项目启动过程组包括两个过程[参见PMBOK2004版]：即制定项目章程和制定项目初步范围说明书；而项目规划过程组则会综合项目的成本、范围、时间、质量、风险、人力、沟通、采购等因素制定项目计划，该项目计划将用于指导项目的实际执行。文章源自玩技e族-https://www.playezu.com/12907.html
对任一项目而言，有三个文件是非常重要的。即：项目章程、项目范围说明书，项目管理计划。这三个文件均产生于项目启动阶段和项目规划阶段。其中项目章程被认为是三大文件之首（项目章程、项目范围说明书，项目管理计划）。一个项目，不论大小，都应该有项目章程。文章源自玩技e族-https://www.playezu.com/12907.html
文章源自玩技e族-https://www.playezu.com/12907.html
1）项目名称及背景描述；文章源自玩技e族-https://www.playezu.com/12907.html
2）项目经理任命及职责范围界定；文章源自玩技e族-https://www.playezu.com/12907.html
3）项目业务需求描述；文章源自玩技e族-https://www.playezu.com/12907.html
4）项目发起的原因；
5）主要项目干系人及其初步需求；
6）产品及预期交付成果描述；
7）项目假设和约束条件。
项目章程由项目发起人(Sponsor)签发，自签发之日起，项目经理即获得法定权力。项目经理在获得法定权力之后的第一动作是制定项目初步范围说明书。为了制定这份文档，他/她将广泛地收集来自项目发起人的需求，以便在项目计划正式编制之前，与项目发起人在项目范围的理解上达成一致。项目初步范围说明书还将在后续项目范围规划过程中进一步细化，并融入项目客户、执行组织、项目干系人等各方面需求，进而形成完整的项目范围说明书。项目初步范围说明书编制完成以后，项目经理将进入项目计划编制阶段。这个阶段将会涉及项目管理方方面面的规划、计划。比较典型的有项目范围基线、项目成本基线、项目进度计划、项目质量计划、项目风险分析及应对计划、人力资源计划、项目沟通计划以及项目采购计划。这些计划、规划经过权衡、调整，最终将集成为一个完整的项目管理计划。项目管理计划经由项目发起人、高级管理层审批以后，即可生效。此后，项目经理将召开项目开工会议(Kickoff meeting)，宣布项目正式开始进入执行阶段。
项目启动阶段的项目章程和项目初步范围说明书(或SOW)，也可以体现在分包或采购合同中。这在软件外包服务型企业中最为常见。通常，伴随合同到达项目经理手中的还有项目建议书(Project Proposal)，项目建议书由项目发起人制定，内容和项目章程中有关产品、可交付成果的描述大致类似，此外，还应包括对项目经理成功完成此项目的一些指导性建议。项目经理根据合同、SOW以及Project Proposal进行综合考虑，与相关干系人磋商，在项目团队相关专家的帮助下，制定出合适的项目管理计划。
上面讨论的是一般项目启动过程组与规划过程组。具体到测试项目的启动与规划，工作内容也是类似的。读者朋友请根据所在测试项目的特点做适当调整。需要交待清楚的是测试项目启动与规划过程组有可能与其他六个过程组有重叠。比如，规划过程组有可能在整个项目生命期内都有更新和完善（典型的有滚动波浪式规划）。
对于整周期软件开发项目的测试而言，上述过程组的内容会有较大的差异。比如：项目章程将重点关注开发，而不会过多讨论测试相关的工作。对于这一类型的软件测试，笔者建议在任命开发项目经理的同时，由项目经理[适用于项目型或强矩阵组织]或高层经理[适用于弱矩阵或职能型组织]指定项目测试经理。测试经理应根据项目章程、项目初步范围说明书和项目建议书尽早开始软件测试相关规划和设计（即会先粗略地进行软件测试需求分析和软件测试设计，以后再进一步细化），并和项目经理沟通、协调，以将一些重要的信息及时反映给项目经理，从而使项目计划能较好地支持测试工作的开展。
理论上，软件测试需求是源于软件需求的，而软件需求又是源于用户需求的。然而，有些时候在分析软件测试需求时并不存在已经文档化的软件需求规格说明。在这种情况下，要分析软件测试需求可能仍然需要追溯到用户需求（当发生这种情况时，普通测试工程师会很吃惊地发现自己原来还肩负着需求开发工程师的部分职责。是的，事实上，资深的软件测试工程师会发现软件测试这个职位几乎涉及所有的开发技能和部分管理技能。）由于后者涉及需求工程的专门知识，本文略过不做细述；这里重点讨论前者。在一个规范化的软件需求规格说明中，用户需求是由更高层次的业务需求（体现在项目章程、SOW、项目建议书等文档中）细化而成，它通常描述了用户使用该软件系统会涉及到的不同的执行路径、工作逻辑以及所预期的处理结果。在UML表示方法中，用户需求通常通过Use Case来进行刻画。接下来，用户需求将进一步转化为三类需求项，即功能需求项、性能需求项以及约束性需求项。这三类需求项就是通常意义上的软件需求项。管理这三类需求项的矩阵被称为需求矩阵。
理论上，在测试资源许可并且确有必要的前提下，测试的使命将是验证和确认待开发的软件及其中间产品满足需求矩阵各个需求项。（注意：为了简化讨论，这里笔者没有把需求的验证与确认纳入进来，实际上这部分工作也是软件测试工作的重要组成部分。详细论述请参阅拙文《试论软件测试学科架构建设》）然而，几乎没有几个公司或开发团队能够提供这类测试所需的诸多的资源，此时，一种可行的策略是将待测试的软件需求项按照优先关系进行排序，以帮助测试经理决策在既定资源的情况下，应该如何统筹安排测试工作。
软件需求项是测试需求分析的起点，这一点在工程实践中并不绝对。对于不同阶段的测试（这里主要指单元测试、集成测试、系统测试和验收测试，暂不考虑验证技术和需求设计确认），测试需求开发所涉及的工作内容和方法都会略有差异。例如，如果是一个验收测试，那么，除了个别的需求需要做进一步明确外，几乎可以将测试需求等同于用户需求和业务需求（由于该类测试是以客户为主体，因此并不需要向下追溯到软件需求）；又如，如果是系统测试，除了需要对不具备可测试性的软件需求项进一步开发外，几乎可以对软件需求和测试需求不做区分。再如，如果是集成测试，测试需求应该从概要设计规格说明中导出。如果尚不存在概要设计规格说明，就需要从软件需求规格说明出发，与软件设计人员协同工作，具体定出构成系统的各个模块、子系统、分系统的功能、性能、约束性条件以及相互接口关系。根据协同工作的结果，开发出对应的测试需求。最后，如果是单元测试，测试需求应该从详细设计规格说明中导出。如果项目不存在概要设计规格说明，就需要从概要设计规格说明出发，与软件设计人员明确每个模块内部的对象属性与方法以及对象与对象间的通信关系。根据此结果，进一步开发相应的测试需求。相应地，上一节所说的对软件需求项进行优先关系排序在实践中要变通地理解为对测试需求项进行优先关系排序。
等，都需要在测试需求开发阶段一并分析清楚。除了对软件需求项、测试需求项做优先关系排序、对不具备可测试性或不确定的需求进一步细化、明确化之外，测试需求开发阶段的工作还包括分析各测试需求项之间可能的时间关系排序。
读者朋友可能会问，对于整周期的开发项目，以上论述是否意味着测试需求开发的依据文档是否要根据测试所处的阶段而不断调整呢？是的，笔者认为这也是完全必要的。我们不能指望软件需求项能够描述清楚集成或单元测试阶段的测试需求。
测试需求的开发总是有赖于相应层次的软件规格说明书（只有在开发团队不能提供的情况下才确有必要循着“详细设计规格说明->概要设计规格说明->软件需求规格说明->用户需求规格说明->项目章程、合同、项目建议书、工作说明书等”的顺序往前追溯）。通常相关依据文档的可测试性越好，测试需求开发所需要的工作量越少。
图文来源网络，如有侵权联系删除
觉得文章不错记得点赞，转发就更好了