我们测试到底为什么服务?测试不仅仅是为开发团队服务，这是很重要的一个思考问题，通常我看到测试团队开发团队协作非常紧密，事实上不仅需要跟它们合作，还需要跟需求的业务分析部门，甚至跟后面的运营部门，产品上线了，或者递交到外部，我们更多的是要以整合业务的角度来看待问题，这是我们很重要的方面。看业务驱动的软件开发测试生命周期，有不同角色划进来，有最终用户，上层的管理层，还有测试人员、开发人员，架构设计师，这完全是循环，跨平台，跨部门，在各个阶段都有测试的理念。
讲了很多方法和理念之后，下一个理念要引入的，有这样的方法和理念要建立什么团队来支撑我们的工作，让我们测试中心，测试团队更有效。第一点是人才培养，第二个流程建设非常重要，如果没有成型的流程，整个团队遵循的规则都很难控制的，再下面有质量量化和工程量化管理，测试项目的管理，我会一一做介绍，第一个会讲到人员，对人员有分工，角色与职能的分工。首先会有质量总监，测试经理和项目经理，会有架构设计师和软件配置人员，还有后面的测试人员，最后还有质量分析专家，到了后期很重要的环节。所以测试是一门学问，需要很多人，很多人投入，有很多专业知识在里面，我测试有什么价值，怎么提升士气和战斗力时也有人问到这个问题。
关于IBM开发中心测试平台和测试方法，IBM Rational常用的RUP，对测试管理的流程定义，通常会有这样一个角色，这是人员，这是一个行动，这是一个流程在里面，会有很多的工作，有一个固化的流程帮助团队执行这个工作。这是RUP中的测试方法学，生成的软件做什么事情，有测试人员，有测试的分析人员，有纯粹的设计人员，他们工作的内容不太一样，这里强调是我们通过这些方面强调测试的进度和质量，一个需求覆盖率，测试用例实现率，要开发测试用例，写出来是不是执行到了，最后是统计分析，我们要对缺陷分布进行分析，这是一个需求管理，通过Rational产品可以把你需求细化到每一个用例，甚至一个需求用例对应好几个测试用例，有分支，或正反向，测试用户不同有不同的情况出现。
往往你的需求和测试用例对不上，但最后产品质量还是不好，最后客户发现问题是你没发现的，这时候就要借助你的工具。这是一个循环，每一个迭代产生一部分，因为更改可能带来新的BUG，要做回归测试，我不断循环测试，是不是意味着人员的投入非常巨大，因为可能新的代码出现，旧的代码还要维护，测试的话，这里面提倡的自动化，尽量把程序写的自动化一些。纯粹的流程，人是喜欢自由自在的，喜欢无拘无束，写再多流程文档，要让执行很困难，没有人在后面拿鞭子抽他，没有人愿意往前走，你要通过平台和工具来控制他，所有东西才可控，软件工业和传统制造业最大区别，软件是一个思维，顶多变成代码，但这代码意味着什么，很难理解，甚至这代码很轻易被删改和删除掉，你测试用例可能很容易被修改和监测，测试经理很难找到数据，我们需要一个测试管理平台，提供的功能是有测试计划，测试用例的执行，测试报告，测试结果的跟踪。
需要特别指出的重要一点，测试是一个团队，不是一个人单独做，因为一个人只能测一点，每个人之间要有分工，分工要有合作，整个项目是一个交集，合集，怎么了解分配状况，需要集中统一的平台，所有数据在这里交流，所有人可以看到相应的数据，这样数据可以被公开和跟踪。第一个是管理平台，这里面有很多的细节，要测试要分布，比如有200个测试，要分布在10个机器上，我测试分布怎么做，最笨的办法就是一个一个系统跑，远程做一个一个跑可能要远程做。第三个压力怎么办?我跟工行、农行客户，比如信用卡，他设计5年10年以后有1亿用户，现在可能只有1、2百个，他怎么保证系统设施满足将来的需求，只能通过测试方法，但是没有测试环境，而且是并发的，而且不同的测试数据在里面流入，不同的测试流程，没有自动化的工具可能做不到，现在给我的答案，没办法，这确实是一个问题，如果没有手段，现在做就是试用，比如我到江苏省，广东省，在一个省里面推广，没发现问题就用了，将来有问题将来再想办法，经常银行系统通知大家，系统在升级，就是它需要不断做调整，这会影响业务和成交额，前一段时间银行有一个案例就是这样。
Rational的最佳实践测试方法，要测试工作量化，测试度量标准，建立测试任务的流程，还有测试案例管理统一模板，统一管理，一定要建立相应的测试管理的平台，缺陷和变更的管理，以及自动化的实现。
文章来源于领测软件测试网 https://www.ltesting.net/
