第三章 软件开发开发过程质量控制实践.pptVIP

量化需求跟踪 Essentials of IBM Rational Performance Tester V7.0 - Instructor Notes Module 4 - Getting Started with Creating Tests This module: Provides students with their first opportunity to use Rational Performance Tester to record and playback a performance test Stresses the importance of unique page titles Teaches students how to validate and assess a performance test Timing This module takes approximately 2 hours. Labs This module references lab exercises 4.1, 4.2, 4.3, and 4.4 in the student workbook. * VANGOGH 凡高科技 * VANGOGH 凡高科技 * VANGOGH 凡高科技 软件开发过程质量控制若干实践 软件开发过程质量控制若干实践 建立合理的配置发布流程 1 建立合理的需求管理过程 2 以下是我们在实际工作中遇到的一个例子，这个例子充分说明了正确的工作流程对于保证软件产品质量的重要意义。 某一开发团队为其客户开发业务软件，系统上线之后存在着很多的业务需求变更，同时也有很多业务部门在使用过程中所发现的软件缺陷，我们把需求变更和软件缺陷统称为变更。开发团队需要迅速响应客户所提出变更请求，把相应的软件版本修复及时地安装到生产系统上去。 为了保证产品质量，该开发团队建立了以下的软件发布流程： 这四个环节分别对应以下四种环境： 开发环境：开发实现客户的变更请求 测试平台：开发团队把软件发布给客户之前做内部系统测试 准生产环境：客户把软件发布到生产系统之前做验收测试 生产系统：最终的生产系统 案例分析 当开发团队将变更实现提交用户验收测试时，凡是没有通过验收测试的变更将被拒绝，只有通过验收测试的变更才会被部署到生产系统上去。整个流程如下图所示，假设开发团队总共实现了3个变更，其中变更1和变更2通过了系统测试被提交用户验收测试，但只有变更1通过了用户验收测试，最终只有变更1被部署到生产系统上。 案例分析 为了支持这种工作流程，该团队分别在配置管理系统中管理了四种源代码版本： 凡是通过每一个环节的变更所对应的源代码版本将被复制到下一个环节的版本基线中去。看上去这一流程非常合理，不是吗？ 案例分析 为了支持这种工作流程，该团队分别在配置管理系统中管理了四种源代码版本： 凡是通过每一个环节的变更所对应的源代码版本将被复制到下一个环节的版本基线中去。看上去这一流程非常合理，不是吗？ 场景I：未经测试的版本组合 质量陷阱 在生产系统上运行的是未经测试的版本组合! 质量陷阱 场景II：未经测试的版本 在下面的例子中，在前面三个测试环节中，文件f2被测试的版本都是版本4。当变更2未通过用户验收测试时，文件f2最终被复制到生产系统上的版本为3，这个版本是未经测试的。 结果令人难以置信： 在生产系统上运行的是未经测试的版本?! 质量陷阱 任何一个软件系统，它的所有代码应该被作为一个整体来进行交付，而不是象上述例子中那样只交付部分的代码（变更相关的代码）,这是造成质量陷阱的根本原因。一个看上去合理的流程存在本质的缺陷。 改进建议 选成以上质量隐患的根本原因是系统代码没有被作为一个整体来处理，并且在发布过程中我们发布的是源代码，正确的流程（也是业界较为通行的做法）应该发布构建后的目标码而非源代码。我们可以建立一个闭环的质量保证流程（如下图所示）来批量地进行软件发布。 改进建议 其中系统测试过程中发现的缺陷应该被开发人员及时改正，然后再做构建，再测试，直到达到一个比较稳定的版本才会发布到验收测试环节。同样的，验收测试中发现的问题也会回到开发环节进行修复。这应该是一个多次循环的过程，不断地发现错误，然后改正，再测试。这个循环到什么时候结束呢？这个取决于各个软件项目的实际情况： 最理想的情况当然是到所有的缺陷都被改正为止，但是所花的时间比较长，可能赶不上项目的进度要求，现实工作不大可能做到这一点。 折衷的情况是所有严重的缺陷（即那些影响系统使用的的缺陷）都必须被改正，但允许有一些已发现的缺陷遗留到后面再去解决,前提是所遗留的缺陷不会影响其他变更的实现。大家平时在一些商用软件的新版本中经常可以见到发布说明