IBM开发中心测试平台和最佳实践测试方法

　摘要: 这是测试的各个环节，项目开始阶段，代码设计阶段到执行阶段是一一对应的，项目从最初的定义，测试的定义，测试的目标等等，通常讲的是主要的测试计划，各个层面的测试计划。Rational的最佳实践测试方法，要测试工作量化，测试度量标准，建立测试任务的流程，还有测试案例管理统一模板，统一管理，一定要建立相应的测试管理的平台，缺陷和变更的管理，以及自动化的实现。

　　为什么要测试，我们测试的目标是什么?作为测试人员和测试经理或了解测试目的软件开发人员也许不需要了解，但现在理念完全改变了，所有人都应该了解测试，不管是项目管理还是开发人员，以及其他团队成员。现在强调测试驱动，业务驱动。测试的目的是什么?最重要的目的是满足用户的需要。讲到测试重要性，很重要的是成本问题，在软件开发有这么一些阶段，有需求分析阶段，设计阶段，编码阶段，还有测试和最终的交付阶段，到产品上线的过程，如果我们发现问题越早，我们付出代价越低，如果到了生产线以后发现问题成本几乎是以前的95倍，因为这个问题会有很多流程，如果到了产品生产线环境里，带来的费用是非常巨大的。作为测试人员发现BUG应该很有成就感，这对公司有很大的贡献。

　　讲到每个阶段产生代码的个数，这是国际知名的软件工程研究所发现的规律，每个程序员每小时产生4.2个缺陷，这数据会根据不同的开发语言，技术层面不同会有所差异，这是一个平均值。而且大部分的缺陷产生于生产、开发阶段，在编码阶段产生很多的缺陷，到后面成本投入越来越高，尽早发现缺陷，尽早解决它，以降低我们的成本。

　　既然测试那么重要，给客户带来信心，帮助我们提高质量，帮助我们改进生产力等，我们如何做呢?首先有一个概念全寿命测试的概念，为什么叫全寿命，在软件测试各个阶段都要引入测试的理念，要同各个团队打交道，测试团队并不只是后端，进入最终代码一级才有的工作，在我们之前会跟很多部门有沟通、交流，有需求，还有跟市场的部门，还有沟通渠道，还有对外交流，项目管理，IT部门，比如要有测试网络，有IT部门的介入，有系列工具的部署，架构设计方法论等等，这一系列都需要有组织级的行为，需要在不同阶段有不同协作的机制。看一下不同测试阶段的划分，这是最早项目的起始阶段，需求分析，到了项目问题的分析到了设计阶段，到系统测试、安装和维护阶段，传统的测试阶段会在设计的后期，会有一些设计文档可能会有测试人员介入或了解，到编码后期测试工作会进来，这理念和过去讲的传统测试不一样的，为什么要这样设计?有他自身的依据，因为越到后面发现问题成本越高，而且传统的说法，在测试阶段发现很多BUG，很多BUG的分类很多是在设计这一块出现的，并不是在编码，设计的理念或需求分析就有偏差，在这个阶段要抓住这个问题。

　　测试生命周期和开发生命周期，在全生命阶段，我们所有计划和需求两个同步进行。而且是一个循环，往往会有多个周期，第一个循环，第二个循环是迭代式开发，为什么要尽早引入而且要频繁测试。下面讲到IBM的测试模型，在定义阶段，项目要做什么样的东西，项目范围多大，项目要在什么阶段产出什么样的产出物，测试的准备工作，测试的计划就会开始启动。测试准备开始了，随后会在设计阶段，还有生成阶段，代码生成阶段，对于单元测试，之后是集成测试，还有系统测试等等都会开始引入。还有测试软件的配置管理，测试环境的建立，需求阶段，定义阶段，一直到最后产品上线，全程都有。有人觉得奇怪，软件平台搭建和软件工具配置跟这有什么关系，其实测试跟开发是类似的，有很多要递交的东西，比如测试计划，测试用意，测试数据，测试的报告，测试中间产生的状态，这些东西都是需要有一个测试的平台来管理，因为你不是一个人作战，你是一个团队，项目越大，你测试不是一个人，是一个团队或一个中心，很多人在里面需要一系列的产出物，这是需要有人管理的，不是在你大脑里或你手里的笔记里，这是没有办法沟通的，一个一个信息孤岛是没有办法交流的，而且没有办法互相监测。不知道大家在座有没有感觉，很多做测试管理和测试开发，测试培训人员，他们面对最大的挑战，我碰多碰到客户讲现在最大挑战，是我不知道现在进度在哪儿，也不知道挑战什么样子，也不知道手下什么样，这就是缺乏平台导致的，所以环境的准备从头到尾。

　　这是测试的各个环节，项目开始阶段，代码设计阶段到执行阶段是一一对应的，项目从最初的定义，测试的定义，测试的目标等等，通常讲的是主要的测试计划，各个层面的测试计划。客户接受测试计划、用户接受测试计划、下一个阶段系统测试计划。从这个侧面看像一个倒写的V，所以我们讲V字型测试模型，现在反过来更强调X，为什么叫X?就是一个V再加一个V，上下两个V就变成X，刚开始可能需求驱动测试，有需求，有项目的立项，有各种各样的计划，反过来，测试又会驱动开发，可能就变成X，再往后有更多测试模型叫W，一个V接一个V下去，多次迭代，每次交付了一部分的功能、代码、设计，所以我们测试在不断循环。

　　我们测试到底为什么服务?测试不仅仅是为开发团队服务，这是很重要的一个思考问题，通常我看到测试团队开发团队协作非常紧密，事实上不仅需要跟它们合作，还需要跟需求的业务分析部门，甚至跟后面的运营部门，产品上线了，或者递交到外部，我们更多的是要以整合业务的角度来看待问题，这是我们很重要的方面。看业务驱动的软件开发测试生命周期，有不同角色划进来，有最终用户，上层的管理层，还有测试人员、开发人员，架构设计师，这完全是循环，跨平台，跨部门，在各个阶段都有测试的理念。

　　讲了很多方法和理念之后，下一个理念要引入的，有这样的方法和理念要建立什么团队来支撑我们的工作，让我们测试中心，测试团队更有效。第一点是人才培养，第二个流程建设非常重要，如果没有成型的流程，整个团队遵循的规则都很难控制的，再下面有质量量化和工程量化管理，测试项目的管理，我会一一做介绍，第一个会讲到人员，对人员有分工，角色与职能的分工。首先会有质量总监，测试经理和项目经理，会有架构设计师和软件配置人员，还有后面的测试人员，最后还有质量分析专家，到了后期很重要的环节。所以测试是一门学问，需要很多人，很多人投入，有很多专业知识在里面，我测试有什么价值，怎么提升士气和战斗力时也有人问到这个问题。

　　关于IBM开发中心测试平台和测试方法，IBM Rational常用的RUP，对测试管理的流程定义，通常会有这样一个角色，这是人员，这是一个行动，这是一个流程在里面，会有很多的工作，有一个固化的流程帮助团队执行这个工作。这是RUP中的测试方法学，生成的软件做什么事情，有测试人员，有测试的分析人员，有纯粹的设计人员，他们工作的内容不太一样，这里强调是我们通过这些方面强调测试的进度和质量，一个需求覆盖率，测试用例实现率，要开发测试用例，写出来是不是执行到了，最后是统计分析，我们要对缺陷分布进行分析，这是一个需求管理，通过Rational产品可以把你需求细化到每一个用例，甚至一个需求用例对应好几个测试用例，有分支，或正反向，测试用户不同有不同的情况出现。

　　往往你的需求和测试用例对不上，但最后产品质量还是不好，最后客户发现问题是你没发现的，这时候就要借助你的工具。这是一个循环，每一个迭代产生一部分，因为更改可能带来新的BUG，要做回归测试，我不断循环测试，是不是意味着人员的投入非常巨大，因为可能新的代码出现，旧的代码还要维护，测试的话，这里面提倡的自动化，尽量把程序写的自动化一些。纯粹的流程，人是喜欢自由自在的，喜欢无拘无束，写再多流程文档，要让执行很困难，没有人在后面拿鞭子抽他，没有人愿意往前走，你要通过平台和工具来控制他，所有东西才可控，软件工业和传统制造业最大区别，软件是一个思维，顶多变成代码，但这代码意味着什么，很难理解，甚至这代码很轻易被删改和删除掉，你测试用例可能很容易被修改和监测，测试经理很难找到数据，我们需要一个测试管理平台，提供的功能是有测试计划，测试用例的执行，测试报告，测试结果的跟踪。

　　需要特别指出的重要一点，测试是一个团队，不是一个人单独做，因为一个人只能测一点，每个人之间要有分工，分工要有合作，整个项目是一个交集，合集，怎么了解分配状况，需要集中统一的平台，所有数据在这里交流，所有人可以看到相应的数据，这样数据可以被公开和跟踪。第一个是管理平台，这里面有很多的细节，要测试要分布，比如有200个测试，要分布在10个机器上，我测试分布怎么做，最笨的办法就是一个一个系统跑，远程做一个一个跑可能要远程做。第三个压力怎么办?我跟工行、农行客户，比如信用卡，他设计5年10年以后有1亿用户，现在可能只有1、2百个，他怎么保证系统设施满足将来的需求，只能通过测试方法，但是没有测试环境，而且是并发的，而且不同的测试数据在里面流入，不同的测试流程，没有自动化的工具可能做不到，现在给我的答案，没办法，这确实是一个问题，如果没有手段，现在做就是试用，比如我到江苏省，广东省，在一个省里面推广，没发现问题就用了，将来有问题将来再想办法，经常银行系统通知大家，系统在升级，就是它需要不断做调整，这会影响业务和成交额，前一段时间银行有一个案例就是这样。

　　Rational的最佳实践测试方法，要测试工作量化，测试度量标准，建立测试任务的流程，还有测试案例管理统一模板，统一管理，一定要建立相应的测试管理的平台，缺陷和变更的管理，以及自动化的实现。

原文转自：http://www.ltesting.net