论研发组织中测试部的意义.docx

论研发组织中测试部的意义.docx

《论研发组织中测试部的意义.docx》由会员分享，可在线阅读，更多相关《论研发组织中测试部的意义.docx（15页珍藏版）》请在冰点文库上搜索。

论研发组织中测试部的意义

论研发组织中测试部的意义

2017-07-24

一、测试的历史和发展

软件测试是20世纪60年代（软件工程建立前）伴随着软件的产生而产生的。

早期的软件开发过程中，那时软件规模都很小、复杂程度低，软件开发的过程混乱无序、相当随意，测试的含义比较狭窄，开发人员将测试等同于“调试”，目的是纠正软件中已经知道的故障，常常由开发人员自己完成这部分的工作。

对测试的投入极少，测试介入也晚，常常是等到形成代码，产品已经基本完成时才进行测试。

1972年在北卡罗来纳大学举行了首届软件测试正式会议。

1975年JohnGoodEnough和SusanGerhart在IEEE上发表了《测试数据选择的原理》的文章，软件测试被确定为一种研究方向。

1979年，GlenfordMyers的《软件测试艺术》，对测试做了定义：

测试是为发现错误而执行的一个程序或者系统的过程。

到了上世纪80年代初期，软件和IT行业进入了大发展，软件趋向大型化、高复杂度，“质量”的号角开始吹响，这个时候，一些软件测试的基础理论和实用技术开始形成，并且人们开始为软件开发设计了各种流程和管理方法，软件测试定义也发生了改变，测试不单纯是一个发现错误的过程，而且包含软件质量评价的内容。

制定了各类标准。

软件开发的方式也逐渐由混乱无序的开发过程过渡到结构化的开发过程，以结构化分析与设计、结构化评审、结构化程序设计以及结构化测试为特征。

人们还将“质量”的概念融入其中，软件测试定义发生了改变，测试不单纯是一个发现错误的过程，而且将测试作为软件质量保证（SQA）的主要职能，包含软件质量评价的内容。

1983年，BillHetzel在《软件测试完全指南》（CompleteGuideofSoftwareTesting）一书中指出:

“测试是以评价一个程序或者系统属性为目标的任何一种活动。

测试是对软件质量的度量。

”这个定义至今仍被引用。

软件开发人员和测试人员开始坐在一起探讨软件工程和测试问题。

软件测试已有了行业标准（IEEE/ANSI），1983年IEEE提出的软件工程术语中给软件测试下的定义是:

“使用人工或自动的手段来运行或测定某个软件系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别”。

这个定义明确指出:

软件测试的目的是为了检验软件系统是否满足需求。

它再也不是一个一次性的、只在开发后期的活动，而是与整个开发流程融合成一体。

软件测试已成为一个专业，需要运用专门的方法和手段，需要专门人才和专家来承担。

进入上世纪90年代，软件行业开始迅猛发展，软件的规模变的非常大，在一些大型软件开发过程中，测试活动需要花费大量的时间和成本，而当时测试的手段几乎完全都是手工测试，测试的效率非常低。

并且随着软件复杂度的提高，出现了很多通过手工方式无法完成测试的情况，尽管在一些大型软件的开发过程中，人们尝试编写了一些小程序来辅助测试，但是这还是不能满足大多数软件项目的统一需要。

于是，很多测试实践者开始尝试开发商业的测试工具来支持测试，辅助测试人员完成某一类型或某一领域内的测试工作，而测试工具逐渐盛行起来。

人们普遍意识到，工具不仅仅是有用的，而且要对今天的软件系统进行充分的测试，工具是必不可少的。

测试工具可以进行部分的测试设计、实现、执行和比较的工作。

通过运用测试工具，可以达到提高测试效率的目的。

测试工具的发展，大大提高了软件测试的自动化程度，让测试人员从繁琐和重复的测试活动中解脱出来，专心从事有意义的测试设计等活动。

采用自动比较技术，还可以自动完成测试用例执行结果的判断，从而避免人工比对存在的疏漏问题。

设计良好的自动化测试，在某些情况下可以实现“夜间测试”和“无人测试”。

在大多数情况下，软件测试自动化可以减少开支，增加有限时间内可执行的测试，在执行相同数量测试时节约测试时间。

而测试工具的选择和推广也越来越受到重视。

1996年提出的测试能力成熟度TCMM（TestingCapabilityMaturityModel）、测试支持度TSM（Test-abilitySupportModel）、测试成熟度TMM（TestingMaturityModel）。

到了2002年，Rick和Stefan在《系统的软件测试》一书中对软件测试做了进一步定义：

测试是为了度量和提高被测软件的质量，对测试软件进行工程设计、实施和维护的整个生命周期过程。

二、测试的目的

软件测试的目的

一、确认软件的质量

1．一方面是确认软件做了你所期望做的事情（Dotherightthing）；

2．另一方面是确认软件以正确的方式来做了这个事情（Doitright）；

二、提供信息，比如提供给开发人员或程序经理的回馈信息，为风险评估所准备的信息；

三、软件测试不仅是在测试软件软件产品本身，而且还包括软件开发的过程；

如果一个软件产品开发完成之后发现了很多问题，这说明此软件开发过程很可能是有缺陷的。

因此，软件测试的第三个目的是保证整个软件开发过程是高质量的。

系统测试的目的

目前IVS测试部的主要工作是做整机系统测试，系统测试的目的是在真实系统工作环境下通过与系统的需求定义作比较，检验完整的软件配置项能否和系统正确连接，发现软件与系统/子系统设计文档和软件开发合同规定不符合或与之矛盾的地方。

系统测试是将通过确认测试的软件，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合起来，在实际运行（使用）环境下，对整机系统进行的测试。

是为了发现缺陷并度量产品质量，按照系统的功能和性能需求进行的测试。

而且，系统测试还要检验系统的文档等是否完整、有效。

另外，系统测试的测试用例应根据需求分析说明书来设计，并在实际使用环境下来运行。

最后，系统测试一般使用黑盒测试技术，并由独立的测试人员完成。

对于软件工作而言，系统测试是软件研制人员参加系统的综合测试，软件及整机系统加入到系统中进行测试。

应该一方面为系统测试提供必要的软、硬件及资料支持，另一方面从软件测试角度提出系统测试中关于软件的测试设计。

从软件测试角度看，系统测试有如下几方面的意义：

1）系统测试的环境是软件真实运行环境的最逼真模拟。

系统测试中，各部分研制完成的真实设备逐渐替代了模拟器，是软件从未有过的运行环境。

有关真实性的一类错误，包括外围设备接口、输入/输出、或多处理器设备之间的接口不相容，整个系统的时序匹配等，在这种运行环境下能得到比较全面的暴露。

2）通常系统测试的困难在于不容易从系统目标直接生成测试用例。

而系统测试由系统人员组织，从系统完成任务的角度测试，软件在系统测试下获得了系统任务下直接的“测试实例”，这对检验软件是否满足系统任务要求是非常有意义的。

3）

三、测试的重要性

在很多情况下，软件开发人员同用户的思路是完全不同的。

开发人员由于接近硬件底层，更多的是从机器的“思维”来考虑问题，而用户只是为了使用。

很多软件开发人员抱有这样的思维，认为用户很笨，“你这样用就不会出现错误了！

”但事实上，作为一种产品，必须要能够考虑到用户使用的方方面面，并考虑进行各种容错处理。

为了记录下用户使用软件的习惯用来提供软件的易用性和发现潜在的问题。

硬件越来越复杂，对软件在应用领域和规模上的期望越来越高,软件的发展速度落后于硬件的发展速度,导致了软件质量不高,超出预算,软硬性兼容问题也体现了测试的重要性。

软件系统复杂性提高、多人合作：

随着软件系统的复杂性提高,项目的组成越来越多角色,这使得每个角色的主观性会在软件产品中出现各类差异：

文档不规范，编码不规范等等类似的问题需要在投产之前不断地测试发现，提高软件产品质量。

没有经过测试的软件很难在发布之前知道该软件的质量，就好比ISO质量认证一样，测试同样也需要质量的保证，这个时候就需要在团队中开展软件测试的工作。

在测试的过程发现软件中存在的问题，及时让相应开发人员得知并修改问题，在即将发布时，从测试报告中得出软件的质量情况。

软件定义、设计、实现、打包/部署、使用过程中出现的与明确的需求不一致：

不能正确完成任务、完成多余的任务，还包括：

改善产品的建议；与用户隐含的需求不一致等等，通过测试能更站在用户的角度去发现问题，控制错误。

对于企业来说，企业软件质量的好坏直接影响一个企业对外的形象，企业的收益，进而关系到每个员工的切身利益，所以无论哪个角度来说，程序的测试工作都是非常重要的。

测试人员必须深刻的领会到测试工作的重要性，更好地投身于测试工作中去。

站在用户的角度对程序的可实现功能性（是否与功能说明书相符），可行性（是否适用于实际生产），可操作性（是否方便使用）等进行测试。

值得提出的一点，以用户的身份进行对程序的验证，测试必须细致，全面，详尽。

好的程序不但能用，更需要好用。

测试人员的工作态度是测试工作成功与否的关键。

所以测试人员要端正自己的态度，认识到自己的重要性，测试人员是和开发人员站在对等的立场上来共同完成一个好的软件；更高层次的说，测试人员是站在高于开发人员，等同于设计人员的高度去把控整个项目的质量，我们要对系统规格书，软件需求说明书，程序等进行全方位的把控。

测试人员需要具备哪些素质

测试人员具有通过对测试案例的分类、BUG的分类，可以准确地分析每个方面的测试（安全性、输入场、功能、性能）是否充分。

让数据说话：

测试人员在测试过程中通过对测试用例和BUG的追踪统计，能够准确地看出项目组发生了什么、正在发生什么、将会发生什么。

测试人员在BUG描述中，如果有原因定位和解决办法，会提高测试人员地位。

比如：

1、清晰描述问题现象，让开发人员容易理解，可采用对比、贴图、录像回放等多种方式；

2、可能的原因及分析；

3、可能的解决办法或建议；

从系统和规范的角度看，对一些客户不认为是问题的问题，测试人员也应坚持意见。

提出问题，即使找不到解决的办法，也应该受到鼓励；这些问题可以作为项目结束后的思考方向并纳入长期的工作计划中。

每个阶段每个角色都要完成自己的工作，某个阶段或某个人完不成的工作，一定会以各种方式转嫁到其它阶段或其他人身上。

因此遇到的问题都要及时解决，否则问题会在项目后期集中爆发，所以测试人员在测试准备时能够充分准确地预估自己的工作量，以免上述情况发生。

综上所述各点是在实际的测试工作中测试人员该有的素质，当然对工作该有的素质还包括兴趣、必备的专业知识、责任心、学习能力、细心、执着、沟通能力等等。

尤其是沟通能力这点对我们测试人员非常重要，与开发人员的有效沟通会直接影响你的工作效率。

软件测试工程负责理解产品的功能要求，然后对其进行测试，检查软件有没有错误（bug）决定软件是否具有稳定性（Robustness），并写出相应的测试规范和测试案例。

微软公司曾经算过一笔账：

最初，微软公司与大家一样，认为测试不重要，重要的开发人员。

通常，一个团队中有几百个开发人员，但只有几个测试人员，并且开发人员的工资比测试人员高很多。

经过多年的实践后，公司发现，为那些出现问题的产品再去修一个补丁程序,简称所花的钱，比多雇用几个测试人员的费用要多得多。

测试人员水平越高，找到Bug的时间就越早，软件就越容易更正，产品发行之后越稳定，公司赚的钱也越多。

这是微软慢慢悟出来的道理。

在谈到软件测试时，许多人都引用Grenford·J·Myers在《TheArtofSoftwareTesting》一书中的观点:

（1）软件测试是为了发现错误而执行程序的过程；

（2）测试是为了证明程序有错，而不是证明程序无错误。

（3）一个好的测试用例是在于它能发现至今未发现的错误；

（4）一个成功的测试是发现了至今未发现的错误的测试。

测试工作的组织与管理

作为软件开发的重要环节，软件测试越来越受到人们的重视。

随着软件开发规模的增大、复杂程度的增加，以寻找软件中的错误为目的的测试工作就显得更加困难。

然而，为了尽可能多地找出程序中的错误，生产出高质量的软件产品，加强对测试工作的组织和管理就显得尤为重要。

当设计工作完成以后，就应该着手测试的准备工作了。

一般来讲，由一位对整个系统设计熟悉的设计人员编写测试大纲，明确测试的内容和测试通过的准则，设计完整合理的测试用例，以便系统实现后进行全面测试。

测试人员要仔细阅读有关资料，包括规格说明、设计文档、使用说明书及在设计过程中形成的测试大纲、测试内容及测试的通过准则，全面熟悉系统，编写测试计划，设计测试用例，作好测试前的准备工作。

为了保证测试的质量，将测试过程分成几个阶段，即：

代码审查、单元测试、集成测试和验收测试。

综上，软件测试是一个极为复杂的过程。

一个规范化的软件测试过程通常须包括以下基本的测试活动。

（1）拟定软件测试计划；

（2）编制软件测试大纲；

（3）设计和生成测试用例；

（4）实施测试；

（5）生成软件问题报告。

实际上，软件测试过程与整个软件开发过程基本上是平行进行的。

测试计划早在需求分析阶段即应开始制定，其它相关工作，包括测试大纲的制定、测试数据的生成、测试工具的选择和开发等也应在测试阶段之前进行。

充分的准备工作可以有效地克服测试的盲目性，缩短测试周期，提高测试效率，并且起到测试文档与开发文档互查的作用。

四、测试部门独立的必要性

测试部门在各个公司所处的位置可能是各不相同，大致可能有这么几种：

1、测试部门独立，与开发部门平行；

2、测试部门独立，但从属于开发部门；

3、虚拟的测试部门，测试人员以组为单位被安排到各个开发团队；

4、没有专门的测试部门，每个开发团队会有若干人在系统集成阶段转换成测试角色；

好坏基本上是一目了然。

第一种情况，从软件过程管理上看，应该是最理想的，测试部门与开发部门平行，因此在项目中的地位就是平起平坐，从组织上避免了在项目中受制于开发团队的风险，也因此能够最大限度的根据软件质量规范对产品进行测试；后面三种情况，都是比较让测试人员比较郁闷的，在项目中会处处受制于开发团队，这就像做工程监理的要被工程实施的管着一样，变得比较可笑了。

其实，测试人员融入到开发团队也是有好的方面的，沟通会比较方便，任务响应也会比较及时，缺憾就是由于开发和测试人员沟通很容易，因此原有的一些软件过程规范就开始变得不被重视，比如说当设计变更后，开发人员可能就不会再去更新设计文档，而是口头通知测试人员了，这样的话，一是没有留下设计变更的相关文档，在后续的开发中无据可依，二是“空口无凭，立字为据”，产品若是出了问题，到底是谁的责任就说不清了；而且，在没有一个过程规范的背景下去开发，产品质量肯定是无从保证的。

因此，从软件的质量控制上考虑，测试部门还追好是独立，与开发平行，而且测试部门更多的是要对产品经理负责。

五、测试团队的组织

要讨论这个话题，首先要讨论下测试人员本身的归属，因为通常是人多了才有组织的必要，很多东西都是一点点长出来的。

人数少，大部分是比较基础的黑盒测试，相对也比较弱势。

没有任何贬低的意思，但是客观来说，这个阶段的测试很难有一些比较深入的测试技术上的实践，时间不允许，也处于没有人带的情况，大家基本上都专注在项目的功能测试上面。

一直觉得环境对人的影响是比较大的。

有些比较有上进心的同学会自己学一些技术，但是因为没有指导，也没有实际应用的场景，通常比较浅。

后面等到整个研发体系发展大了之后，可能测试人员也慢慢多了起来，同时服务于多个开发小组，于是就出现了测试团队的二级组织。

比如对口每个开发小组的有几个人，或者更多，然后有一个lead或者firstlinemanager，然后这些人汇总到一个secondline的manager。

这个时候随着测试团队规模的壮大，当然也是随着整个研发组织的壮大，以及业务和开发方面提出了更多更高的质量要求，测试团队在客观上有了进一步提升的需求。

主观上因为secondline的出现，会不再满足于完成基本的测试工作，也有提升的动力。

一些测试的规范，用例设计，缺陷管理，数据的分析，工具平台的引入，自动化的开展等慢慢开始引入。

接下来，可能到研发部门层面有一个完整的测试团队，进而可能是整个公司，或者事业部（BG，BU）层面有一个完整的测试部门，或者中心。

目前看到的腾讯和阿里的几个大的业务导向的事业部都是这样的情况，比如腾讯的互联网，互动娱乐，电商（曾经）；阿里的淘宝，天猫和支付宝，都是在事业部层面有一个完整的测试团队。

进一步，如果这类很大型的公司，把全集团的测试集中到一起的还没看到，主要是因为组织架构的顶层还是按业务来划分的，比如事业部制。

基于上面的讨论，我们可以从测试的集中这种角度来看看测试团队的情况，这样划分就有两种，集中还是不集中。

集中的例子就是上面说的情况，所有专职测试人员都在一个小组，一个大的二级组，进而一个中心，一个部门，数据结构上是一颗树。

非集中的情况就是测试人员散落在不同的开发中心，或者开发组，是一个森林。

每一块的测试人员组成一个小组，汇报给开发中心的总监，或者开发经理。

目前了解到不少公司是这样来组织的。

每一种组织方式都是结合了公司的实际情况和要求，但是如果单纯从测试团队的价值和效率方面，目前来看，会觉得集中到一起是个更好的方式，主要的理由是下面几点。

1.集中到一起之后，因为资源的整合，可以减少各个团队的重复建设，集中来做一些平台建设，技术研究，或者横行的技术共享，有利于提升团队的技术深度。

2.从业务的角度，集中后测试可以横向的对齐，来看各个项目的质量情况，研发流程的过程执行和效率的情况。

从整个组织的角度，对研发的质量和效率有促进的作用。

3.从测试人员个人发展的角度，因为整个测试组织有了更好的深度，个人发展的空间也会更大，无论技术还是管理方面。

4.测试人员的归属感，有自己的部门和自己的职业发展通道。

谈到和项目的对应，目前采用测试集中方面的团队也基本上是矩阵式管理，特别是针对负责业务测试的小组。

一方面，从组织架构上是归属于质量部或者质量中心，但是从日常工作上，是归属到项目或者产品，和对应的产品、开发团队密切配合，包括座位可能都在一起。

就目前观察的情况来看，这种组织架构相对是比较成熟，也比较普遍被采用的，运作起来也还比较顺畅。

第二个方面，想讨论一下测试人员的内部细分。

IT行业早已经是内部就开始隔行如隔山，分得非常细了。

考虑对口的产品和技术形态，测试人员也有很大的差异了，比如测试通信设备的，测试Web网站的，以及测试app的，其背景知识，工作流程也有很大的差异。

即使不考虑这方面，从专注的测试工作内容上看，也有进一步的细分。

我接触到的会分为四个方面：

1.业务测试

这一部分的测试人员就是上面提到的矩阵式管理的那一类，负责具体的产品的测试和质量提升。

所以这一类的人就数量上来说通常是最多的。

2.专项测试

如果测试组织稍大，对测试的深度有更高的要求，而有些测试类型又需要比较长时间的积累，且技能有横向的共用性，那么就可能有专人来做，俗称专项。

比如安全测试，性能测试等。

就实际运作的情况来看，像安全测试这种看起来确实比较有必要，因为没有长时间专注的积累难以有效果。

这样的专项测试通常人数不是很多。

3.质量管理

有些地方叫QA或者SQA，就是第二篇里面提到的专注在质量数据的收集，研发流程的管理和推动等事项上面的一些人。

通常放在测试部门，但是也可能放在研发管理等团队。

4.测试开发

当整个测试的团队比较大，需要很多共性的基础的平台和工具建设，就可能会抽出一个团队专门来做这方面的事情，称之为测试开发。

实际中，关于业务测试和测试开发，其实有时候界限是没有那么清楚的，取决于多个方面的因素：

1.老大观念

没办法，这个很重要。

接触到几位部门级测试团队的负责人，观念不完全一样，有些认为独立的测试开发团队很重要，且愿意大的投入，有些觉得没必要有专门的测试开发团队，业务测试团队应该有能力来做测试技术方面的事情。

2.业务测试团队的能力

这个要看实际的情况，业务测试如果要做得比较好，业务测试的团队本身也需要比较好的技术能力，所以很多测试开发意义上的事情业务测试团队也可以做，实际也在做。

但是也有些情况，业务测试团队本身的技术能力不够，或者时间非常的局限。

从业务测试团队本身的意愿上，肯定也希望能做一些技术方面的事情。

3.测试开发团队和业务测试团队的双向互动的情况

一方面是看测试开发团队做的东西能否在业务测试团队落地，涉及方案本身，是否贴合项目时间，以及和业务测试团队的配合的情况。

这个实际情况应该还是比较复杂的，各个团队面临的实际情况都不太一样。

六、测试团队的定位和意义

目前IVS测试团队已逐渐介入事业部各项产品的测试，并根据团队的开发模式、产品方向不断调整测试策略、方法。

团队创建至今颇有感概，特姚总要求编写文档之际，与大家分享一下我的从业经历（软件测试、软件项目经理）及公司现状下，测试团队的定位及存在意义。

首先，从之前介绍的软件测试发展史可以发现，软件测试的理论随着软件项目的规模、复杂度不断增强，而不断完善的。

软件测试目前已经不再是我们10-20年前所熟知的找缺陷的过程（由于国内软件测试的环境部，大部分理论研究均来自于国外，所以相关理论的应用、推广也比较滞后），软件测试已经成长为一项与软件开发类似，同样具有生命周期的持续过程性任务。

在软件测试的每个生命周期，测试工程师的职责、工作任务和产出均有明确说明，每个阶段也有对应的评审过程以保证各项产出的准确性、有效性。

从软件测试的最新定义看来，软件测试目前可作为整个软件项目中的一个子项目进行实施。

再来聊一下与软件测试相关的，大家比较熟悉的几个名词：

缺陷（BUG），这是大家对软件测试产出最直观的认识，也是绝大部分国内公司考察软件测试工程师KPI中最直观的指标之一。

大部分人对缺陷的认知还是比较狭隘的（包括我从业初期2年时间），可能在大家看来只有功能无法使用、软件崩溃、数据无法读写、软件逻辑冗乱等这些与应用相关的异常才称之为缺陷。

我们首先来辩证地认识缺陷的常规描述：

缺陷即瑕疵、缺点、欠缺、不完美，从缺陷的定义看来缺陷是一个相对定义，他需要一个比照标准以判断是否与标准匹配。

然后回到软件测试中的缺陷认知，类似的软件测试的缺陷也需要一个参照标准，凡是与标准不一致的功能、描述、输入、输出、UI、配色、布局、入口、出口、数据格式、数据精确度、数据流向、数据一致性等都可称之为缺陷。

测试的意义，这个命题有点类似于罗素悖论：

从公司层面而言，各位领导期望在最短的时间，使用最少的人力完成项目的各类测试（功能、性能、UI、安全、兼容、安装/卸载、易用、压力、负载、文档）提交各类文档，并保证软件不存在缺陷；从测试团队而言，工程师希望公司投入更多的人力、时间对软件进行充分测试、尽可能发现更多潜在缺陷（事实上，缺陷永远无法消除）。

比如：

尽管微软的开发、测试从业人员比例小于1比2，但是每年仍不停的发布补丁以修复各类缺陷），在进行多次充分测试后再进行结论文档书写。

通常测试团队会在项目周期内，根据项目资料尽早进行测试准确，对客户关注部分进行详细测试，其余部分与需求规格说明匹配情况即结束了项目的测试。

这类处理方式看似非常中庸，实为项目管理制下满足客户、领导要求最大化的无奈之举。

回到公司的测试团队及研发的各兄弟团队上来。

在我最初参加工作时，公司有建制的团队为：

开发、项目管理、运维、部门管理。

公司测试团队空缺的情况下，部分测试任务被分配到开发团队和运维团队的日常工作中。

这样做的弊端如下：

●对于开发人员而言，检查自己的作品是一件虐心的活动。

在这种心理下，开发人员很难较多地发现自己的作品存在的缺陷；

●测试方法、测试理论的缺失，导致开发人员和运维人员很难定义什么样的现象属于有效缺陷，测试的效率较低；

●测试在局部展开，很难形成有效的测试报告，并将测试成果运用于其他项目；

●测试、缺陷修复的随意性，导致版本发布较为随意，版本管理比较困难；

因此开发、