项目管理资源网

您的位置:项目管理资源网 >> IT通信项目管理

软件项测试的两个阶段

2020/11/7 22:29:03 |  784次阅读 |  来源:网友转载   【已有0条评论】发表评论

  对于整周期软件开发项目的测试而言,上述过程组的内容会有较大的差异。比如:项目章程将重点关注开发,而不会过多讨论测试相关的工作。对于这一类型的软件测试,笔者建议在任命开发项目经理的同时,由项目经理[适用于项目型或强矩阵组织]或高层经理[适用于弱矩阵或职能型组织]指定项目测试经理。测试经理应根据项目章程、项目初步范围说明书和项目建议书尽早开始软件测试相关规划和设计(即会先粗略地进行软件测试需求分析和软件测试设计,以后再进一步细化),并和项目经理沟通、协调,以将一些重要的信息及时反映给项目经理,从而使项目计划能较好地支持测试工作的开展。

  二、软件测试需求分析

  理论上,软件测试需求是源于软件需求的,而软件需求又是源于用户需求的。然而,有些时候在分析软件测试需求时并不存在已经文档化的软件需求规格说明。在这种情况下,要分析软件测试需求可能仍然需要追溯到用户需求(当发生这种情况时,普通测试工程师会很吃惊地发现自己原来还肩负着需求开发工程师的部分职责。是的,事实上,资深的软件测试工程师会发现软件测试这个职位几乎涉及所有的开发技能和部分管理技能。)由于后者涉及需求工程的专门知识,本文略过不做细述;这里重点讨论前者。在一个规范化的软件需求规格说明中,用户需求是由更高层次的业务需求(体现在项目章程、SOW、项目建议书等文档中)细化而成,它通常描述了用户使用该软件系统会涉及到的不同的执行路径、工作逻辑以及所预期的处理结果。在UML表示方法中,用户需求通常通过Use Case来进行刻画。接下来,用户需求将进一步转化为三类需求项,即功能需求项、性能需求项以及约束性需求项。这三类需求项就是通常意义上的软件需求项。管理这三类需求项的矩阵被称为需求矩阵。

  理论上,在测试资源许可并且确有必要的前提下,测试的使命将是验证和确认待开发的软件及其中间产品满足需求矩阵各个需求项。(注意:为了简化讨论,这里笔者没有把需求的验证与确认纳入进来,实际上这部分工作也是软件测试工作的重要组成部分。详细论述请参阅拙文《试论软件测试学科架构建设》)然而,几乎没有几个公司或开发团队能够提供这类测试所需的诸多的资源,此时,一种可行的策略是将待测试的软件需求项按照优先关系进行排序,以帮助测试经理决策在既定资源的情况下,应该如何统筹安排测试工作。

  软件需求项是测试需求分析的起点,这一点在工程实践中并不绝对。对于不同阶段的测试(这里主要指单元测试、集成测试、系统测试和验收测试,暂不考虑验证技术和需求设计确认),测试需求开发所涉及的工作内容和方法都会略有差异。例如,如果是一个验收测试,那么,除了个别的需求需要做进一步明确外,几乎可以将测试需求等同于用户需求和业务需求(由于该类测试是以客户为主体,因此并不需要向下追溯到软件需求);又如,如果是系统测试,除了需要对不具备可测试性的软件需求项进一步开发外,几乎可以对软件需求和测试需求不做区分。再如,如果是集成测试,测试需求应该从概要设计规格说明中导出。如果尚不存在概要设计规格说明,就需要从软件需求规格说明出发,与软件设计人员协同工作,具体定出构成系统的各个模块、子系统、分系统的功能、性能、约束性条件以及相互接口关系。根据协同工作的结果,开发出对应的测试需求。最后,如果是单元测试,测试需求应该从详细设计规格说明中导出。如果项目不存在概要设计规格说明,就需要从概要设计规格说明出发,与软件设计人员明确每个模块内部的对象属性与方法以及对象与对象间的通信关系。根据此结果,进一步

    项目经理胜任力免费测评PMQ上线啦!快来测测你排多少名吧~

    http://www.leadge.com/pmqhd/index.html

“项目管理生根计划”
企业项目经理能力培养和落地发展方案下载>>

分享道


网站文章版权归原作者所有,如有认为侵权请联系我们,将于1个工作日内作出处理!
网友评论【 发表评论 0条 】
网友评论(共0 条评论)..
验证码: 点击刷新

请您注意护互联网安全的决定》及中华人民共和国其他各项有关法律法规或间接导致的民事或刑事法律责任
·您在项目管理资源网新闻评论发表的作品,项目管理资源网有权在网站内保留、转载、引用或者删除
·参与本评论即表明您已经阅读并接受上述条款