51Testing软件测试论坛

标题: 谈谈ERP软件测试机制---为定制开发护航 [打印本页]

作者: hujy_07 时间: 2008-7-28 17:53
标题: 谈谈ERP软件测试机制---为定制开发护航
一个公司的软件在测试计划制定、实施上该如何进行，测试工作应该如何开展，我想每个公司都有自身的一套方法、形式。或成熟、或并不十分完善，但都在积极地推动着自身研发的软件且现今各位老总们已经认识到软件测试是保障软件质量必不可少的环节。作为一名测试工作人员，我们也应该喜悦于自身的努力与成就之中。

那么，今天想谈谈自己在ERP软件方面为公司定制的测试机制，请各位朋友指点指点。

首先，我们公司是一家定制性软件开发公司，完全是依据客户的实际工厂作业流程与企业规模、现况进行的ERP软件开发。基于此特点在软件测试上形成的利弊也就十分鲜明，有利的是我们直接面对着一批有目的性的客户群体，这给我们带来的测试依据就更加准确、清晰;然而，对应的弊端也更加尖锐――需求变更的频繁性，需求是整个项目的奠基石，可谓是一动而牵全身。

对此，作为负责软件质量的测试小组，应该如何应对？如果此时按照书本或某测试机构宣称：等待着开发人员一个版本成形以后，大家一起测，完毕以后，提交报告，等待下一轮的修改，验证。显然对于此类型的公司、此类型的软件开发是行不通的，我们知道ERP软件不同与其他类型的软件，生产作业流程是整个企业生产的命脉，仅凭测试用例的多少、测试技术的高超是不足以对此软件做质量保证的。

为此，我制定了“分散、集中”制的测试管理方法。即对每个项目实行一人负责到底、多人支援救助制，这样不仅激发测试人员的积极性，也让每位测试人员肩负起一份责任。（个人认为，每位员工在走进工作岗位上的时候都是怀着一颗踌躇满志，施展抱负的热切之心而来的，只是随着时间，环境、机制的推移，某些人逐渐地被消蚀殆尽。我曾在论述《中国企业下的员工发展》中曾提到过国内的公司不是不注重人才，而是不能大胆启用人才，这也是造成员工自身发展受阻的严重来源之一。）

所谓“分散”，即保证每个项目有一位主要负责人，从项目的启动到项目的结束，负责对此项目测试业务流程的组织与管理，日常的项目缺陷跟踪、整理、反馈。这也是为了更好的应对项目的频繁变更，保证至少有一位测试人员在第一时间内了解测试项目概貌，及时对测试工作进行组织安排调整。

所谓“集中”，就是在项目（或多个功能）需要交付试用或者是正式上线之初，在测试上需要验证多方面的功能，即对项目需要进行集成测试、系统联调（这两个测试步骤是我在《ERP软件测试五步曲中》的定义，未必就是目前所谓的测试术语），此时凭借单个人的力量是无法胜任的（时间、任务执行），需要其它的测试人员配合，该项目测试负责人就可以申请调用其它测试人员，为了快速的让测试人员进入角色、熟悉项目，就可以由项目测试负责人把该项目的业务流程做统一的讲解和培训，有效解决鞭长莫及的现象。（短时间的训练怎么可以胜任呢？别忘了前面的“分散”制，这些测试人员就是其他项目中的测试负责人，有着几乎完全一致的测试方法、技术，以及对开发软件的共同了解。公司虽然针对着许多个不同生产企业，但是在开发出的软件上是采用的同一框架、同一理论去解决单个企业问题。）

其次，我再讲讲这种机制的好处

1、激励员工
我记得几年前某位上级对我们进行员工考核时问过这样一个问题：你认为什么样的工作管理机制会使员工充分地发挥才能？我当时的回答是集体管理、允许个性发挥，这样才是一个充满激情的团队。

而这种“分散、集中”制恰好使每一位成员都有两重身份，即：这个项目组的测试负责人，另外一个项目组的普通测试人员，最终，又都归属测试小组这个集体。这样每个测试人员可以在自己的项目组里自由发挥，不受级别限制，当作为普通测试人员时又可以向其他项目组人员学习、借鉴，另一方面测试人员必须主动地全面了解自己负责的测试项目，以便在项目需要做集成测试、系统联调时对其他同事进行培训。
如果别的项目培训的都很好，而自己负责的没有做好，那会是什么景象呢？人最大的特点就是比上、比下时都无动于衷，只有和身边的人、同等的人相比时才会极其敏感。不难想象，是一位热血儿女都会非常努力地、勤奋地要赶上对方，甚至于超越对方，有如此一个默默赶拼、面对难度与挑战勇往之前的团队，老板还会担心员工偷赖吗？

2、深入研究、保留劳动果实
由于所有项目都有其共同点，不同的行业又单独具有本行业的特质，每个测试人员在熟悉了本项目的基础之上，可以很快的理解其他项目，避免被动的接受，做到借鉴与互补的同时可以相互探讨、总结软件中最大的缺陷在哪里？为开发者或需求者提供参考意见，同时测试小组依据各项目的特点调整整个测试的管理，把制定的、探讨出的测试方式、过程，寻求到的测试技巧得以在不同的项目中实施。这种重复的探索最终会慢慢地使测试小组形成相当丰富的劳动成果，不仅仅只是受益于整个测试，而在某种程度上积累到的项目特性最终会给其他部门，或整个公司带来亨之不尽的资源。

最后，再谈谈这种机制的可执行面

项目测试负责人自己有权调配时间，自己控制功能的稳定情况（当然这里的稳定性需要和项目负责人做沟通），对所负责的测试项目制定相关的测试计划进度，在一定时候向测试小组提出对项目进行集成测试、系统联调，由测试小组商讨以后，分配出时间、人员，对该项目（功能）执行一次较完整的测试。

为了避免项目负责人自身还没有做测试，或测试做的不完整时，要求其他人员协助测试，那么测试小组规定，请求资源测试者必须对测试的功能执行过单元测试、组合测试（这两个测试步骤是我在《ERP软件测试五步曲中》的定义，未必就是目前所谓的测试术语），当协助人员发现如有初级错误时，测试小组有权拒绝测试者的资源请求（在一定程度上，这些协助人员又起到了监督的作用，且有着非常权威性的发言权，避免出现不懂乱指挥、造成双方都不满意的窘境）。当然一些特殊原因除外，功能模块较多或是这次测试工作比较紧急，测试小组应该予以支持。

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)