昨天去听IBM的一个工程师讲解他们的RFT，由于去完了基本上就没听到什么内容，只是觉得IBM挺强，几乎把以前所有东西都搭建到Eclipse平台上……下来以后趁他收拾东西的时候问了几个问题。第一就是IBM内部的自动化测试实施率有多少？就是自动化测试占总的测试用例的百分比~得到的结果让我惊讶：15%！原来在IBM也就是15%的用例实现了自动化。那么我又问了一个问题“IBM现在开发一个产品都是每天build一个产品然后每天做一次regression的么？”答案是“看项目需要，有些项目可能还没有自动化环境，有些项目组可能比较先进，但是一个版本出来以后至于是BVT还是Regession那就看项目要求了。”

(原来IBM也这样哦，呵呵)

常常在谈及到自动化测试的时候总会跟每日构建沾上边，让大家总觉得有了自动化测试就能实施每日构建，然后每日回归测试，然后产品就能顺利发布。但是每日构建只是手段不是目的，自动化测试在这里面扮演着辅助的作用。不要觉得每日构建加上自动化测试就无敌了。迷信某种技术带来的后果通常都是走进了死胡同。

（嗯，我也觉得是这样的，总觉得现在的人习惯把自动化提高到一定的程度呀）

在衡量软件企业的是研发和管理能力的是CMM以及后面推出的CMMI，很多公司通过CMM的各个级别的认证，为企业承接项目添加了砝码，而对于软件测试行业来说，还没有出现一个认证机构，测评一个从事软件测试项目的企业具有的能力。其实在几年前，已经推出的TMM（Testing Maturity Model），而我个人认为使用TCMM（Testing Capability Maturity Model）更为合适，TCMM也分为五级。下面我们就看看是如何划分的，来评判一下各位同仁自己所在的公司，所在的级别。

TCMM Level 1：Initial（初始级）
　测试处于一个混乱的状态，还不能把测试同调试分开，在编码完成后才进行测试工作，测试和调试交叉在一起，目的就是发现软件中的bug。测试的目的是表明程序没有错。软件产品发布后没有质量保证。缺乏测试相应的测试资源、例如专职测试人员和测试工具，测试人员没有经过培训。这种类型的公司属于这个阶段，处于这个阶段的公司在测试中缺乏成熟的测试目标，测试处于可无可有的地位。

TCMM Level 2：Phase Definition（阶段定义级）
　测试同调试分开且把测试作做为编码后的一个阶段。尽管测试别看做是一个有计划的行为，但是由于测试的不成熟仅在编码后制定测试计划，因为测试完全是针对于源代码的。处于这个级别的公司测试的首要目的就是验证软件符合需求，会采用基本的测试技术和方法，由于测试处于软件生命周期的末尾环节，导致出现很多无法弥补的质量问题。另外，在需求和设计阶段产生的很多问题被引入到编码中，但基于源代码的测试导致产生了很多的问题无法解决。

TCMM Level 3：Integration（集成级）
　测试不再是编码后的一个阶段，而是把测试贯穿在整个软件生命周期中。就象软件测试领域的V模型，在需求阶段软件测试就介入了，测试是建立在满足用户或客户的需求上，根据需求设计测试用例和作为测试的依据。处于这个级别的公司测试工作由具有独立的部门负责，测试部门与开发部门分开，独立开展工作。测试部门有自己的技术培训并且有测试工具辅助进行测试工作。尽管处于这个阶段的公司认识到了评审在质量控制中的重要性，但是并没有建立起有效的评审制度，还不能在软件生命周期的各个阶段实施评审制度。没有建立起质量控制和质量度量标准。

TCMM Level 4：Management and Measurement（管理和度量级）
　测试是一个度量和质量控制过程。在软件生命周期中评审作为测试和软件质量控制的一部分，被测试的软件产品标准包括可靠性、可用性和可维护性等。在测试项目中设计的测试用例别保存在测试用例数据库中便于重用和回归测试。使用缺陷管理系统管理软件缺陷并划分缺陷的级别。但是处于这个阶段的公司还没有建立起缺陷预防机制，且缺乏自动地对测试中产生的数据进行收集和分析的手段。

TCMM Level 5：Optimization（优化级）
　具有缺陷预防和质量控制的能力。建立TCMM4基础上的测试公司已经建立起测试规范和流程，测试是受控的和被管理的。而达到TCMM5的公司，则坚决贯彻落实测试规范和流程且不断地进行测试过程改进，在实践中运用缺陷预防和质量控制措施。整个测试过程是被以往经验所驱动的，且是可信任和可靠的。选择和评估测试工具存在一个既定的流程。测试工具支持测试用例的运行和管理，辅助设计用例和维护测试相关资料，缺陷收集和分析，为缺陷预防和质量控制提供支持。

   看了上面对于测试能力成熟度模型的分析，我们不难看出，目前我们国内从事软件测试的公司所处的级别，很多公司还处于2级或3级，这虽然与现在软件测试还是一个尚未成熟的行业有关，测试技术和测试工具还在发展之中，各个公司都在摸索阶段，从事测试外包的公司会好一些，这些公司为微软、IBM、Motorala等公司提供测试服务，基本上是按照委托方的要求或带领下进行测试工作，而国内做软件产品和承接软件开项目的公司，虽然有的建立了独立的测试团队，制定了测试规范和测试流程或者评审制度，但是测试工作还是在摸索阶段，大家几乎没有现成的经验可参考，所以目前急需建立软件测试的行业标准，推动测试行业的发展，让测试有依据可查。

5，加强测试管理：测试任务有更强的计划性，尽量能细化到测试的功能和测试的case这个级别去监控进度；
6，对于集成测试，还要保证开发部送测版本的质量。避免测试终止或者多轮测试版本才能放行的情况。我们这边会用版本送测次数，版本测试失败次数去衡量开发部门送测版本的质量

......

虽然这个开发进度时间是一个大概的估计时间，但我们要尽力按照这个开发进度来执行。每个星期五下午我们有一个Status Meeting（一般那时工作效率较低，适合开会），在此会议上我们会根据这个进度来review我们的工作，每个人手上的工作是否按照这个进度在走，是否有人延后了，是否block住别人的工作了。在此会议上每个人都要报告自己的进度，同时还要报告上个星期做了什么，正在做什么，以及下个星期打算做什么。通过这个会议，会让你觉得有人在监督你，无形之中迫使你不断地督促自己不要使任务延后

......

若有谁check in的代码导致daily build失败则会被要求某些惩罚措施或警告，象微软公司要负责照看当日的每日构建。有时我们编写的代码涉及到多个文件，而且此改动是比较复杂需要花费多天的工作量，如果现在check in进去可能会导致BVT（Build Verify Test）测试通不过，因为有些代码没有完全完成，而之前的代码能使BVT测试通过，而且这些代码基本上不会涉及到他人，在这种情况下可以不check in进去，直到全部代码完成能提交BVT测试时再一起check in进去。
每天我们都会做daily build，一般是在凌晨4点进行，那时有个程序会自动从VSS中拉下最新的代码并进行编译。因为我们同美国进行同步开发，因此如果想要把修改的代码进入到这个build中去那就需要在凌晨4点之前把相应的代码check in进去。若有人check in进去的代码导致编译通不过则会在本步骤中被发现。当编译完成之后自动产生安装包，测试部门将会对这些代码进行BVT测试，同时对VSS中开发库打上label，如果发现了什么BUG就能根据这个label知道是哪个时候开始出现这个BUG的。BVT是指Build Verify Test，是对组件中基本功能的测试。这个测试每天都会进行，看新加入的代码或修改是否会影响系统的基本功能，便于及早发现错误。

......

5. 测试
在开发人员完成了function Spec后，测试部门开始了测试规划，确定需要测试哪些方面，如何测试及进度安排。测试人员需要写许多测试代码，有些测试代码需要集成进BVT测试，有些可能需要进行单独的测试，目的都是为了使产品符合要求，使开发人员容易找出问题所在并改正。产品功能是否符合了要求，是否能被发布是由测试人员决定的，因此测试人员也比较辛苦，责任重大。通过了每天的BVT测试，还有一些性能测试、兼容性测试、灾难测试等需要在产品发布前进行。在完成这些测试之后由测试人员决定本产品是否能release出去了，如果没有什么问题则会给某些关系较好的用户进行β测试，之后再最终release出去。
......

在QA增加BUG和开发人员fix BUG的游戏中，BUG的数量曲线图会象股市曲线一样上下波动，但总体趋势一般是前期BUG放量攀升，后期震荡下挫，若到了后期新open的BUG数量一直上升则说明风险在增大，有可能无法控制，也就是说fix了一个BUG导致了多个新的BUG产生。在量化开发进度中也可以用代码数量的曲线图来粗略的呈现。在有大量新功能增加时可能代码量的增加会较快，当在fix bug阶段，代码的修改较多，因此代码数量的增幅会降低，依据代码量可以看出开发的状况处于何种阶段。 
需要指出的是我们对BUG的定义比较广泛，一些新功能也可以作为BUG被提出，只不过这些BUG级别比较低，让它们进入到下一个版本中去实现。因此BUG的创建者也可以是技术支持人员、市场人员甚至开发人员本身。关于开发人员本身，因为他可能会找出一些BUG，有些是其他开发者的，有些可能是此开发者本身的，把这个BUG添加进BUG库中可以帮助开发人员在以后产生新问题时或类似的BUG时有一个借鉴和思路，但此BUG的verify必须要让测试本模块的测试人员来verify。 
.......

7. Code Freeze当P5之前的BUG都被修复了，这时离产品发布日期也就不远了，一般是2个星期后就能release产品，这时要对VSS中的代码进行freeze，以保证代码库的稳定性。Code freeze阶段一般会把各开发人员的check in和check out的权限关闭，若在这时仍有BUG报告上来并经讨论确定是重大的且必须在本版本中fix的，则需要经管理层同意并特殊地授予权限，在修改完成后修改者要把修改了哪些文件，影响了哪些文档等信息上报给各部门如QA、build人员、文档编写者等。在code freeze阶段，测试部门在紧张地进行着各种测试，得出各种数据，并决定本版本是否可以release了。