产品测试管理

研发管理沙龙——产品测试管理时间：2004年2月12日下午2：30～5：00地点：明华国际会议中心(汉华深圳总部)主题：产品测试管理主持人：朱光辉（汉华公司研发管理培训&咨询部总监）董奎(汉华公司高级资深顾问)组织策划：周志强(汉华《研发管理》刊物编辑部主任)邀请嘉宾：司小康（金蝶软件）王振刚（金山软件）严百平(迈瑞医辽)李重阳(康佳集团)侯燕、段昱宽(网易公司)肖人苗(菲奈特软件)江壮生(广州数控)内容：二月十二日，来自网易公司，康佳集团，金蝶软件，金山软件，迈瑞医辽，菲奈特软件，广州数控等公司的相关研发负责人，与汉华的资深顾问们齐聚于蛇口湾畔的明华国际会议中心，参加由汉华企业管理咨询有限公司举办的《研发管理》沙龙系列活动。本次沙龙的主题是：“产品测试管理”。沙龙上的气氛轻松而活跃，与会者纷纷各抒己见。交流了产品测试管理过程中的问题和困难,分析了困难产生的原因,以及提出了一些有效的解决方法。包括为什么要做测试；测试怎么参与到产品开发中去，参与到哪什么程度；系统测试怎样来组织，中间会出现哪些问题，怎么避免这些问题；什么人适合做测试，测试人员如何管理；怎么评估测试质量等问题。与会者分享了各个公司的经验和教训。汉华顾问结合与会者提出的问题，也发表了一些建设性的意见和建议。会议结束后，大家都觉得收获很大。汉华组织的这种形式的沙龙给主管研发的经理们提供了一个非常好的交流平台，大家都受益匪浅。以下记录内容中均以姓代替人名。在各位嘉宾简单自我介绍之后,沙龙正式开始。朱：(汉华公司)今天沙龙的主题是测试，怎么搞好测试。我想今天沙龙大概分这几个方面。一、为什么要做测试；二、测试怎么参与到产品开发中去，参与到哪什么程度；三、系统测试怎样来组织，中间会出现哪些问题，怎么避免这些问题；四、什么人适合做测试，测试人员如何管理；五、怎么评估测试质量；许多人感到测试人员职业发展不明确，许多开发人员不愿做测试，我们经常碰到这些问题。大家可以随意的探讨一下。董：(汉华公司)产品开发分不同的阶段：概念阶段、计划阶段、开发阶段、验证阶段，发布阶段，生命周期管理阶段。大家可能会问测试人员应该在哪些阶段的工作，参与到什么程度？王：（金山软件）我来谈谈吧，主要是结合我们公司的情况，再加上一些我个人的理解。测试人员具体应在哪个阶段参与到工作中，参与的程度如何？我从事测试工作6年了，在我刚参加工作的时候，对测试也全无概念，就知道要保证产品的质量。具体该怎么做，什么时候做，做成什么程度是合适的？我心里也没底。经过这几年自己的摸索和在网上跟同行兄弟的交流学习，总结了一套经验。测试工作在什么时候参与到产品开发中去？在金山测试是在研发一开始就参与进去的，从立项到审核、需求、编码的整个过程中。测试主要是做什么呢？主要是做两件事：第一件是编写测试案例，第二件是组件测试。组件测试主要是用一种介于白箱和黑箱测试之间的技术，开发的时候形成动态链接库，主要是对这些动态链接库进行测试，它本身没有什么功能，只是检查它的参数，函数的输入口，接收的数据信息。现在对这个没有一个界定，也没有一个官方的名词。在市场上要么是白箱测试，要么是黑箱测试，没有对这一方面的界定。而我们在摸索中发现这方面一定要做，所以我们就暂时称它为“灰箱测试”。因为白箱测试是纯代码的测试，黑箱测试是纯界面的，“灰箱测试”是测试函数的，但又看不到函数本身，只是了解这个函数接收什么参数，接收参数后怎么处理。所以在金山从产品测试从产品立项到验收，每一阶段都有测试工作的参与。具体要参与到哪个程度？怎么说呢，因为金山对产品质量要求的程度非常高。基本上是测试主导的那种型式。什么时候编译是由我们测试人员编好计划的，在大进度定好了以后，各处小项目必须依照这个测试计划来做。为什么开发人员不愿参加测试这个方面工作。我有我的一些看法；不是他们不愿意，而是一个你怎样去引导的问题，在金山的时候，有不少开发人员愿到我这个部门来，就说明了这一点。国内的测试行业的发展方向还不明确。给人的感觉是软件行业发展了这么多年，开发的模式和技术也相对成熟了，但是测试技术的发展路线上还不明朗。这样就造成测试人员的测试技术上没有进步。开发人员不愿意做测试。如果我们给他们规划一个好的发展方向，情况就不是这样了。我们要先做灰箱测试，做灰箱测试有两个目的，第一个是练兵，积累经验；第二个是尽可能的代替手工劳动这一块。新的测试人员进来后要让他对这个行业感兴趣，开始就抛给他一些虚的概念，比如测试管理，测试案例，测试驱动；但是只理解了这些概念没用，而是看你怎么用。但到底应该怎么做呢？首先让他们做测试工具，让他们去实现某个测试功能。慢慢地让他们对测试有感觉，这样他们就对测试工作有更深层的了解。在我们摸索阶段怎么走的呢？我开始是为了保证产品的质量。产品质量是第一位的，这是一条主线。发展上有两个方向，第一个是测试本身，第二个测试工具的开发。如果这条主线做好了，测试人员是愿意做测试工作的，我们以前也是这样做的。江：（广州数控）我们公司是做数控系统的，我们测试的主要目的是提高产品的可靠性。我们原先的产品进入市场半年后，维修成本特别高；就是因为前期测试没做好。我们公司相对比较小，在测试方面就是开发人员在做，开发人员边开发边测试。一直没有专门的测试人员。现在我们做了一些大的项目后，这种开发方式就显得比较混乱。测试工作上我们没有什么经验，不知应该怎么做。在开发中我们的开发人员做好系统后，就给我们的测试人员。测试人员只是从整个系统功能方面来测试，实际上就相当一个验证功能的过程。这样做还达不到所希望的要求。所以说测试人员怎么具体开展工作是个我们很关心的问题。我赞成金山的观点，开始研发计划时就开始做测试工作。现在我们正准备做这方面的尝试。想解决测试人员什么时候切入，切入点是什么，切入多深，如何解决测试人员觉得比较烦，没有成就感，不愿做测试工作的问题。现在我们的测试人员陷入了一种每天做重复手工工作的困境中，测试人员感到很忙，就好像掉入一个死循环一样，跳不出来，而测试较率又很低，所以像这种工作，技术人员是不愿做的。公司也不可能配备许多人测试人员去做这些重复性工作。我们也没有什么好办法。司：（金蝶软件）我来谈谈我们公司的做法，我们公司是做ERP软件的。我们认为，产品质量有狭义和广义之分：狭义的理解是产品的本身的缺陷，比如有一个BUG，一个错误。广义上的产品质量，不只是BUG。还包含更广泛的内容，比如操作的方便性(可用性)、可支持性、可靠性、性能等方面的问题。产品功能符不符合客户的需要，客户用你的产品能不能解决他的问题，在长时间的工作过程中会不会出现问题等等，都可归为产品质量范畴。微软从前的NT操作系统，工作一段时间就会出错，需要重新启动；而现在微软的2003操作系统一个重要的特性就是提高操作系统的稳定性，这就是一个可靠性的问题。迈瑞是我们的战略客户，对我们产品的使用方便性上，便提出了很多要求。产品实施方案、解决方案也属于产品质量的一个范畴，叫可支持性。比如做康佳的彩电这个产品，不仅是要把这个彩电做好就完了，还有一个外延的产品，包括说明书呀，营销策略呀，怎么把产品卖给顾客，怎么引导客户去买我们的产品，如何做售后服务呀等。这些都是产品质量的广义的范畴。国际上把这叫做ＦＵＲＰＳ，包括功能性、可用性，可靠性、性能、可支持性五个方面。那金蝶公司的测试是怎么做的呢？刚才金山的“灰箱测试”是很好的。金蝶公司目前的做法，比较符合业界的”V”模型。我们测试工作从产品的立项就开始参与进去了。我们根据产品立项的计划，会开始相应的总体测试计划。一般情况下产品立项计划是说明项目是做什么，要完成客户要求的哪些功能，解决客户的哪些问题？我们做ＥＲＰ，有广大的客户群体，在日常反馈中，收集了很多客户的产品需求，然后要把这些需求体现到我们的产品中去。由于客户的需求有很多，我们的资源和能力是有限的。所以我们不可能实现客户的全部需求，要分阶段的去实现；先实现一部分需求，然后再实现另一部分功能。我们在立项的时候要给客户需求定好位，产品立项时，需求的范围就是我们测试工作的范围，这个在我们的测试总体计划中体现和描述。在需求分析阶段，我们测试人员就开始做大量的测试用例。包括产品的每一个功能、子功能、子子功能；功能的展开，每个子功能的输入输出值、希望输出的结果、实现的步骤等方面我们都要列到测试用例中去。我们测试人员分两类：一类是功能测试人员，一类是技术测试人员。功能测试人员就是检查产品的实现程度，看是否实现了客户对每一个功能的需求。技术测试人员主要是测试代码，并研究决定选用哪些测试工具完成这些测试。我们已经开发了很多自有的测试工具和代码分析工具。金山提到的组件测试，我们也在做这方面的工作。我们还会利用一些第三方的测试工具，比如我们大量使用了康博公司的DPS,它可以把你每一行代码执行的情况都分析出来，当然，语法诊断是最简单的代码测试了，它还能检查代码的执行情况，有没有被执行，执行的效率是怎样，都会分析出来。我们还使用另外一类测试工具，如VBUNIT、JUNIT、NUNIT等，编写测试脚本，对函数、组件等进行测试，当然，我们目前还没有达到百分之百的代码做这样的测试，但我们目前已经达到了30%以上的代码都写测试脚本来测试。通过这样的测试，为后面的功能测试节省了很多时间。如果重大的错误到了测试人员手中才被发现的话，这样非常影响测试人员的效率和情绪。代码和集成测试之间，我们有一套日构建系统。我们借鉴了微软的日构建系统的做法，俗称“每日编译系统”。我把它形容为是我们整个项目研发的心脏，它驱动了我们开发的每一个环节，控制着研发项目的节奏。编译前，开发人员都要CHECKIN他们的代码，编译完成后，通过它发布给测试人员。测试人员开始做相关的测试。我们在编译流程上要求也挺严格的，每天定时去做。在日常中是在4：00-4：30启动编译。到了开发后期时，这个工作变得更为重要，为了促进开发效率的提升，一天要编译二次，甚至三次以上。到了集成测试阶段，就主要是功能上的测试了。当然这只是理论上来划分的，实际上我们是每日集成，每日测试，开发一步，测试一步。测试依据就是我们前期做的测试用例，每个要去检查核对，我们讲究的是测试用例的测试覆盖率，每一个用例是否都被你测到了，测试过程和结果都记录在我们的测试工作底稿中。我们为什么要详细编写测试用例呢？主要目的之一是让我们测试人员排除测试的盲目性和无序性。有了这样测试用例就可以让我们的测试人员做到忙而不乱，知道自己的进度情况，完成哪些，哪些还没有测到。我认为这是一个比较好的做法。我们在集成测试完成之后，就会开始我们的β测试。就是在我们的战略客户现场那里来验证我们的产品。比如我们即将要发布的K/3ERPV10.0，我们从12月25日就完成了α版，但我们到现在还没有正式发布。我们的β版直到现在还在做客户验证测试。我们的要求是若β测试没有结束，就不能发布产品。我们的β测试，就是通过市场渠道或客户服务环节联系我们的战略客户。我们选译这样的客户：一方面要愿意做我们的β测试，另一方面，客户要有代表性。这需要我们去做好与客户的关系，这是很重要的一个环节，因为产品在实验室做得无论有多么好，客户那边验证的不好，代表产品就有质量问题。为了保证质量必须要面向客户，不能是在实验室里面闭门造车。所以我们派了很多人员到了客户那边去，产品经理也会去客户那边，蹲在客户那边。客户发现问题马上解决，因为客户愿意帮我们做测试，我们要感谢客户，让客户满意，要是出了错，没有服务好，下次让客户测试就没门了。我们的测试流程规定必须要经过这一环节。经过我们的努力，愿意当我们β测试的客户还是很多的。这就是金蝶公司整个的测试流程。江：我们在这种种客户的选择上就特别困难，我们的客户一般是都机床厂。我们的系统面对的许多顾客都可能是全国性的，所以顾客特别难选。我们这个系统新出来时不敢给他们用。这方面我们觉得很难开展工作。司：这方面确实是个问题，如果你走好第一步的话，后面就会好办多了。别因为这些困难我们就不去做这些事情。刚开始时，我们找β测试客户确实是很难的，要和不断和客户沟通，说服客户去升级它的产品，并