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

论研发组织中测试部的意义2017-07-24一、 测试的历史和发展软件测试是 20 世纪 60 年代（软件工程建立前）伴随着软件的产生而产生的。早期的软件开发过程中，那时软件规模都很小、复杂程度低，软件开发的过程混乱无序、相当随意，测试的含义比较狭窄，开发人员将测试等同于“调试”，目的是纠正软件中已经知道的故障，常常由开发人员自己完成这部分的工作。对测试的投入极少，测试介入也晚，常常是等到形成代码，产品已经基本完成时才进行测试。1972 年在北卡罗来纳大学举行了首届软件测试正式会议。1975 年 John Good Enough 和 Susan Gerhart 在 IEEE 上发表了测试数据选择的原理的文章，软件测试被确定为一种研究方向。1979 年，Glenford Myers 的软件测试艺术，对测试做了定义：测试是为发现错误而执行的一个程序或者系统的过程。到了上世纪 80 年代初期，软件和 IT 行业进入了大发展，软件趋向大型化、高复杂度，“质量”的号角开始吹响，这个时候，一些软件测试的基础理论和实用技术开始形成，并且人们开始为软件开发设计了各种流程和管理方法，软件测试定义也发生了改变，测试不单纯是一个发现错误的过程，而且包含软件质量评价的内容。制定了各类标准。软件开发的方式也逐渐由混乱无序的开发过程过渡到结构化的开发过程，以结构化分析与设计、结构化评审、结构化程序设计以及结构化测试为特征。人们还将“质量”的概念融入其中，软件测试定义发生了改变，测试不单纯是一个发现错误的过程，而且将测试作为软件质量保证(SQA)的主要职能，包含软件质量评价的内容。1983 年，Bill Hetzel 在软件测试完全指南(Complete Guide of Software Testing)一书中指出:“测试是以评价一个程序或者系统属性为目标的任何一种活动。测试是对软件质量的度量。”这个定义至今仍被引用。软件开发人员和测试人员开始坐在一起探讨软件工程和测试问题。软件测试已有了行业标准(IEEE/ANSI )，1983 年 IEEE 提出的软件工程术语中给软件测试下的定义是:“使用人工或自动的手段来运行或测定某个软件系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别”。这个定义明确指出:软件测试的目的是为了检验软件系统是否满足需求。它再也不是一个一次性的、只在开发后期的活动，而是与整个开发流程融合成一体。软件测试已成为一个专业，需要运用专门的方法和手段，需要专门人才和专家来承担。进入上世纪 90 年代，软件行业开始迅猛发展，软件的规模变的非常大，在一些大型软件开发过程中，测试活动需要花费大量的时间和成本，而当时测试的手段几乎完全都是手工测试，测试的效率非常低。并且随着软件复杂度的提高，出现了很多通过手工方式无法完成测试的情况，尽管在一些大型软件的开发过程中，人们尝试编写了一些小程序来辅助测试，但是这还是不能满足大多数软件项目的统一需要。于是，很多测试实践者开始尝试开发商业的测试工具来支持测试，辅助测试人员完成某一类型或某一领域内的测试工作，而测试工具逐渐盛行起来。人们普遍意识到，工具不仅仅是有用的，而且要对今天的软件系统进行充分的测试，工具是必不可少的。测试工具可以进行部分的测试设计、实现、执行和比较的工作。通过运用测试工具，可以达到提高测试效率的目的。测试工具的发展，大大提高了软件测试的自动化程度，让测试人员从繁琐和重复的测试活动中解脱出来，专心从事有意义的测试设计等活动。采用自动比较技术，还可以自动完成测试用例执行结果的判断，从而避免人工比对存在的疏漏问题。设计良好的自动化测试，在某些情况下可以实现 “ 夜间测试 ” 和 “ 无人测试 ” 。在大多数情况下，软件测试自动化可以减少开支，增加有限时间内可执行的测试，在执行相同数量测试时节约测试时间。 而测试工具的选择和推广也越来越受到重视。1996 年提出的测试能力成熟度 TCMM（Testing Capability Maturity Model）、测试支持度 TSM（Test-ability Support Model）、测试成熟度TMM（Testing Maturity Model）。到了 2002 年，Rick 和 Stefan 在系统的软件测试一书中对软件测试做了进一步定义：测试是为了度量和提高被测软件的质量，对测试软件进行工程设计、实施和维护的整个生命周期过程。二、 测试的目的软件测试的目的一、确认软件的质量1一方面是确认软件做了你所期望做的事情（Do the right thing）；2另一方面是确认软件以正确的方式来做了这个事情（Do it right）；二、提供信息，比如提供给开发人员或程序经理的回馈信息，为风险评估所准备的信息；三、软件测试不仅是在测试软件软件产品本身，而且还包括软件开发的过程；如果一个软件产品开发完成之后发现了很多问题，这说明此软件开发过程很可能是有缺陷的。因此，软件测试的第三个目的是保证整个软件开发过程是高质量的。系统测试的目的目前 IVS 测试部的主要工作是做整机系统测试，系统测试的目的是在真实系统工作环境下通过与系统的需求定义作比较，检验完整的软件配置项能否和系统正确连接，发现软件与系统/子系统设计文档和软件开发合同规定不符合或与之矛盾的地方。系统测试是将通过确认测试的软件，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合起来，在实际运行（使用）环境下，对整机系统进行的测试。是为了发现缺陷并度量产品质量，按照系统的功能和性能需求进行的测试。而且，系统测试还要检验系统的文档等是否完整、有效。另外，系统测试的测试用例应根据需求分析说明书来设计，并在实际使用环境下来运行。最后，系统测试一般使用黑盒测试技术，并由独立的测试人员完成。对于软件工作而言，系统测试是软件研制人员参加系统的综合测试，软件及整机系统加入到系统中进行测试。应该一方面为系统测试提供必要的软、硬件及资料支持，另一方面从软件测试角度提出系统测试中关于软件的测试设计。从软件测试角度看，系统测试有如下几方面的意义：1）系统测试的环境是软件真实运行环境的最逼真模拟。系统测试中，各部分研制完成的真实设备逐渐替代了模拟器，是软件从未有过的运行环境。有关真实性的一类错误，包括外围设备接口、输入/输出、或多处理器设备之间的接口不相容，整个系统的时序匹配等，在这种运行环境下能得到比较全面的暴露。2）通常系统测试的困难在于不容易从系统目标直接生成测试用例。而系统测试由系统人员组织，从系统完成任务的角度测试，软件在系统测试下获得了系统任务下直接的“测试实例”，这对检验软件是否满足系统任务要求是非常有意义的。3）三、 测试的重要性在很多情况下，软件开发人员同用户的思路是完全不同的。开发人员由于接近硬件底层，更多的是从机器的“思维”来考虑问题，而用户只是为了使用。很多软件开发人员抱有这样的思维，认为用户很笨，“你这样用就不会出现错误了！”但事实上，作为一种产品，必须要能够考虑到用户使用的方方面面，并考虑进行各种容错处理。为了记录下用户使用软件的习惯用来提供软件的易用性和发现潜在的问题。硬件越来越复杂，对软件在应用领域和规模上的期望越来越高,软件的发展速度落后于硬件的发展速度,导致了软件质量不高,超出预算,软硬性兼容问题也体现了测试的重要性。软件系统复杂性提高、多人合作：随着软件系统的复杂性提高,项目的组成越来越多角色,这使得每个角色的主观性会在软件产品中出现各类差异：文档不规范，编码不规范等等类似的问题需要在投产之前不断地测试发现，提高软件产品质量。没有经过测试的软件很难在发布之前知道该软件的质量，就好比 ISO 质量认证一样，测试同样也需要质量的保证，这个时候就需要在团队中开展软件测试的工作。在测试的过程发现软件中存在的问题，及时让相应开发人员得知并修改问题，在即将发布时，从测试报告中得出软件的质量情况。软件定义、设计、实现、打包/部署、使用过程中出现的与明确的需求不一致：不能正确完成任务、完成多余的任务，还包括：改善产品的建议；与用户隐含的需求不一致等等，通过测试能更站在用户的角度去发现问题，控制错误。对于企业来说，企业软件质量的好坏直接影响一个企业对外的形象，企业的收益，进而关系到每个员工的切身利益，所以无论哪个角度来说，程序的测试工作都是非常重要的。测试人员必须深刻的领会到测试工作的重要性，更好地投身于测试工作中去。站在用户的角度对程序的可实现功能性（是否与功能说明书相符），可行性（是否适用于实际生产），可操作性（是否方便使用）等进行测试。值得提出的一点，以用户的身份进行对程序的验证，测试必须细致，全面，详尽。好的程序不但能用，更需要好用。测试人员的工作态度是测试工作成功与否的关键。所以测试人员要端正自己的态度，认识到自己的重要性，测试人员是和开发人员站在对等的立场上来共同完成一个好的软件；更高层次的说，测试人员是站在高于开发人员，等同于设计人员的高度去把控整个项目的质量，我们要对系统规格书，软件需求说明书，程序等进行全方位的把控。测试人员需要具备哪些素质测试人员具有通过对测试案例的分类、BUG 的分类，可以准确地分析每个方面的测试（安全性、输入场、功能、性能）是否充分。让数据说话：测试人员在测试过程中通过对测试用例和 BUG 的追踪统计，能够准确地看出项目组发生了什么、正在发生什么、将会发生什么。测试人员在 BUG 描述中，如果有原因定位和解决办法，会提高测试人员地位。 比如：1、清晰描述问题现象，让开发人员容易理解，可采用对比、贴图、录像回放等多种方式； 2、可能的原因及分析； 3、可能的解决办法或建议；从系统和规范的角度看，对一些客户不认为是问题的问题，测试人员也应坚持意见。提出问题，即使找不到解决的办法，也应该受到鼓励；这些问题可以作为项目结束后的思考方向并纳入长期的工作计划中。每个阶段每个角色都要完成自己的工作，某个阶段或某个人完不成的工作，一定会以各种方式转嫁到其它阶段或其他人身上。因此遇到的问题都要及时解决，否则问题会在项目后期集中爆发，所以测试人员在测试准备时能够充分准确地预估自己的工作量，以免上述情况发生。综上所述各点是在实际的测试工作中测试人员该有的素质，当然对工作该有的素质还包括兴趣、必备的专业知识、责任心、学习能力、细心、执着、沟通能力等等。尤其是沟通能力这点对我们测试人员非常重要，与开发人员的有效沟通会直接影响你的工作效率。软件测试工程负责理解产品的功能要求，然后对其进行测试，检查软件有没有错误（bug）决定软件是否具有稳定性（Robustness），并写出相应的测试规范和测试案例。微软公司曾经算过一笔账：最初，微软公司与大家一样，认为测试不重要，重要的开发人员。通常，一个团队中有几百个开发人员，但只有几个测试人员，并且开发人员的工资比测试人员高很多。经过多年的实践后，公司发现，为那些出现问题的产品再去修一个补丁程序,简称所花的钱，比多雇用几个测试人员的费用要多得多。测试人员水平越高，找到 Bug 的时间就越早，软件就越容易更正，产品发行之后越稳定，公司赚的钱也越多。这是微软慢慢悟出来的道理。在谈到软件测试时，许多人都引用 GrenfordJMyers 在The Art of Software Testing一书中的观点:(1)软件测试是为了发现错误而执行程序的过程；(2)测试是为了证明程序有错，而不是证明程序无错误。(3)一个好的测试用例是在于它能发现至今未发现的错误；(4)一个成功的测试是发现了至今未发现的错误的测试。测试工作的组织与管理作为软件开发的重要环节，软件测试越来越受到人们的重视。随着软件开发规模的增大、复杂程度的增加，以寻找软件中的错误为目的的测试工作就显得更加困难。然而，为了尽可能多地找出程序中的错误，生产出高质量的软件产品，加强对测试工作的组织和管理就显得尤为重要。当设计工作完成以后，就应该着手测试的准备工作了。一般来讲，由一位对整个系统设计熟悉的设计人员编写测试大纲，明确测试的内容和测试通过的准则，设计完整合理的测试用例，以便系统实现后进行全面测试。测试人员要仔细阅读有关资料，包括规格说明、设计文档、使用说明书及在设计过程中形成的测试大纲、测试内容及测试的通过准则，全面熟悉系统，编写测试计划，设计测试用例，作好测试前的准备工作。为了保证测试的质量，将测试过程分成几个阶段，即：代码审查、单元测试、集成测试和验收测试。综上，软件测试是一个极为复杂的过程。一个规范化的软件测试过程通常须包括以下基本的测试活动。（1）拟定软件测试计划；（2）编制软件测试大纲；（3）设计和生成测试用例；（4）实施测试；（5）生成软件问题报告。实际上，软件测试过程与整个软件开发过程基本上是平行进行的。测试计划早在需求分析阶段即应开始制定，其它相关工作，包括测试大纲的制定、测试数据的生成、测试工具的选择和开发等也应在测试阶段之前进行。充分的准备工作可以 有效地克服测试的盲目性，缩短测试周期，提高测试效率，并且起到测试文档与开发文档互查的作用。四、 测试部门独立的必要性测试部门在各个公司所处的位置可能是各不相同，大致可能有这么几种：1、测试部门独立，与开发部门平行； 2、测试部门独立，但从属于开发部门； 3、虚拟的测试部门，测试人员以组为单位被安排到各个开发团队； 4、没有专门的测试部门，每个开发团队会有若干人在系统集成阶段转换成测试角色；好坏基本上是一目了然。第一种情况，从软件过程管理上看，应该是最理想的，测试部门与开发部门平行，因此在项目中的地位就是平起平坐，从组织上避免了在项目中受制于开发团队的风险，也因此能够最大限度的根据软件质量规范对产品进行测试；后面三种情况，都是比较让测试人员比较郁闷的，在项目中会处处受制于开发团队，这就像做工程监理的要被工程实施的管着一样，变得比较可笑了。其实，测试人员融入到开发团队也是有好的方面的，沟通会比较方便，任务响应也会比较及时，缺憾就是由于开发和测试人员沟通很容易，因此原有的一些软件过程规范就开始变得不被重视，比如说当设计变更后，开发人员可能就不会再去更新设计文档，而是口头通知测试人员了，这样的话，一是没有留下设计变更的相关文档，在后续的开发中无据可依，二是“空口无凭，立字为据”，产品若是出了问题，到底是谁的责任就说不清了；而且，在没有一个过程规范的背景下去开发，产品质量肯定是无从保证的。因此，从软件的质量控制上考虑，测试部门还追好是独立，与开发平行，而且测试部门更多的是要对产品经理负责。五、 测试团队的组织要讨论这个话题，首先要讨论下测试人员本身的归属，因为通常是人多了才有组织的必要，很多东西都是一点点长出来的。人数少，大部分是比较基础的黑盒测试，相对也比较弱势。没有任何贬低的意思，但是客观来说，这个阶段的测试很难有一些比较深入的测试技术上的实践，时间不允许，也处于没有人带的情况，大家基本上都专注在项目的功能测试上面。一直觉得环境对人的影响是比较大的。有些比较有上进心的同学会自己学一些技术，但是因为没有指导，也没有实际应用的场景，通常比较浅。后面等到整个研发体系发展大了之后，可能测试人员也慢慢多了起来，同时服务于多个开发小组，于是就出现了测试团队的二级组织。比如对口每个开发小组的有几个人，或者更多，然后有一个 lead 或者 first line manager，然后这些