|
|
本文主要目的是加强项目组和测试中心之间的相互了解，分享一些测试人员在工作中的经验和成果， 从而使项目组和测试中心的配合更加默契，共同把握住产品的质量要素。
一、 测试的目的和原则
1、测试概念的范畴
广义上讲，测试是指软件产品生存周期内所有的检查、评审和确认活动。如：设计评审、系统测试。
狭义上讲，测试是对软件产品质量的检验和评价。它一方面检查软件产品质量中存在的质量问题，同
时对产品质量进行客观的评价。
2、测试的目的
简单地说，就是替用户受过，测试的最终目的是确保最终交给用户的产品的功能符合用户的需求，把
尽可能多的问题在产品交给用户之前发现并改正。
具体地讲，测试一般要达到下列目标：
1、确保产品完成了它所承诺或公布的功能，并且所有用户可以访问到的功能都有明确的书面说
明------在某种意义上与ISO9001是同一种思想。
产品缺少明确的书面文档，是厂商一种短期行为的表现，也是一种不负责任的表现。所谓短期行为，是指缺少明确的书面文档既不利于产品最后的顺利交付，容易与用户发生矛盾，影响厂商的声誉和将来与用户的合作关系；同时也不利于产品的后期维护，也使厂商支出超额的用户培训和技术支持费用。从长期
利益看，这是很不划算的。我有个感觉，接触过的软件产品，很少有向方正这样大大的产品、薄薄的文档。
当然，书面文档的编写和维护工作对于使用快速原型法(RAD)开发的项目是最为重要的、最为困难，也是最容易被忽略的。
最后，书面文档的不健全甚至不正确，也是测试工作中遇到的最大和最头痛的问题，它的直接后果是测试效率低下、测试目标不明确、测试范围不充分，从而导致最终测试的作用不能充分发挥、测试效果不理想。
2、 确保产品满足性能和效率的要求
使用起来系统运行效率低(性能低)、或用户界面不友好、用户操作不方便(效率低)的产品不能说是一
个有竞争力的产品。
用户最关心的不是你的技术有多先进、功能有多强大，而是他能从这些技术、这些功能中得到多少好
处。也就是说，用户关心的是他能从中取出多少，而不是你已经放进去多少。
3、 确保产品是健壮的和适应用户环境的
健壮性即稳定性，是产品质量的基本要求，尤其对于一个用于事务关键或时间关键的工作环境中。
另外就是不能假设用户的环境(某些项目可能除外)，如：报业用户许多配置是比较低的，而且是和某
些第三方产品同时使用的。
3、测试的原则---Good Enough
对于相对复杂的产品或系统来说，zero-bug是一种理想，good-enough是我们的原则。
Good-enough原则就是一种权衡投入/产出比的原则：不充分的测试是不负责任的；过分的测试是一种
资源的浪费，同样也是一种不负责任的表现。我们的操作困难在于：如何界定什么样的测试是不充分的，
什么样的测试是过分的。目前状况唯一可用的答案是：制定最低测试通过标准和测试内容，然后具体问题
具体分析。最明显的例子就是FIT3.0中文报版的产品测试。
4、测试的规律----木桶原理和80-20原则
1、木桶原理。
在软件产品生产方面就是全面质量管理(TQM)的概念。产品质量的关键因素是分析、设计和实现，测
试应该是融于其中的补充检查手段，其他管理、支持、甚至文化因素也会影响最终产品的质量。应该说，
测试是提高产品质量的必要条件，也是提高产品质量最直接、最快捷的手段，但决不是一种根本手段。反
过来说，如果将提高产品质量的砝码全部押在测试上，那将是一个恐怖而漫长的灾难。
2、 Bug的80-20原则。
一般情况下，在分析、设计、实现阶段的复审和测试工作能够发现和避免80%的Bug，而系统测试又能
找出其余Bug中的80%，最后的5%的Bug可能只有在用户的大范围、长时间使用后才会曝露出来。因为测试
只能够保证尽可能多地发现错误，无法保证能够发现所有的错误。
二、 测试中心测试组织、测试实施的现状和改进
1、测试中心的任务和发展目标----质量
参与到监控产品生命周期中一切影响到质量的因素的工作中去。
目前测试中心的主要任务是负责产品的系统测试。
但实际上，因为单独的系统测试不能保证产品最终的质量，所以测试中心在部分项目中也参与到集成
测试和用户测试中。
另外，测试中心也承担了部分系统评测的任务和用户技术支持的任务。
测试中心将来的发展目标是研究院开发的产品的质量保证中心，我们的中心任务只有两个字："质
量"，测试中心也只对这两个字负责，并且将参与到监控产品生命周期中一切影响到质量的因素的工作中去。
2、测试中心的组织方式----小组
测试中心内部的个体分为测试人员和支持人员(管理人员属于支持人员)。
测试中心的工作实体(最小组织单位)是测试小组和支持小组，分别由小组长全权负责。小组长向测试
中心主任负责。
测试小组根据测试项目或评测项目的需要临时组建，小组长也是临时指定。与项目组的最大区别是生
命周期短，一般是2周到4个月。在系统测试期间或系统评测期间，测试组长是测试中心对外(主要是项目
组)的唯一接口，对内完全负责组员的工作安排、工作检查和进度管理。
支持小组按照内部相关条例负责测试中心的后勤保障和日常管理工作，机构设置一般相对比较稳定。
主要负责网络管理、数据备份、文档管理、设备管理和维护、员工内部培训、测试理论和技术应用、日常
事务管理和检查等。
另外，测试中心对于每一个重要的产品方向，如：报社系统(包括采编、FIT、RIP、字模等)、电视台
系统(包括点睛、新闻等)…，均设置1-3个人长期研究和跟踪方正及竞争对手的产品特征、性能、优缺点
等。在有产品测试时，指导或参加测试(但不一定作为测试组长)，在没有产品测试时，进行产品研究，并
负责维护和完善测试设计。目前希望在需求分析阶段多多参与(如：Chirashi2.1)。
3、测试中心的运作方式----制度化并形成应用
主要介绍一下项目组关心的系统测试流程：
1、项目组提交系统测试申请给测试中心指定帐号。由专人检查文档格式和完备性。
2、检查合格后交给该产品对应方向的研究人员，评价其内容的有效性和真实性。
3、检查合格后由测试中心主任审查并通过，成立测试组，指定测试组长(但暂时没有组员)。
4、测试组长根据该产品的申请报告、测试设计和以往测试数据，制定测试方案。
5、测试中心主任审核通过测试方案后，根据测试方案指定测试组成员，并由支持组完成其他支持任
务(如：设备的配备、测试数据库的建立、网络权限的修改…)。
6、测试期间测试组根据测试方案进行实际测试，记录并跟踪测试缺陷报告，填写测试记录。测试期
间测试组长与项目组(测试经理)经常沟通，并获取产品的更新版本。同时，测试组长审查、修改并提交所
有缺陷报告，保证随时掌握产品的质量情况，并监督测试进度。
7、产品进行到一定阶段后(标志是测试缺陷报告库中所有的报告处于归档状态)，由项目组和测试组
长共同决定产品进入稳定期测试。稳定期测试版本之前的版本必须在显著位置标明为测试版字样。
8、稳定期测试期间所发现的缺陷报告也需要记录在测试缺陷报告库中，并在稳定期结束后由双方(有
时可能也有市场方面的意见)共同决定对这些缺陷的处理方式。如果需要改动产品，则重新开始稳定期，
否则通过稳定期测试。
9、测试组长对于通过稳定期测试的产品填写综合测试报告，测试中心依此发布产品发行通知。
10、测试组对整个测试过程和产品质量进行总结和评价，形成文档并备案。同时，将测试过程中对测
试设计的改动纳入基线。最后，组长整理并在指定地点保存相关测试数据和测试样张。
11、测试中心解散测试小组。
另外，在系统测试阶段，我们要求测试小组要进行一些常规内容测试(如：Y2K测试，病毒检查、裸机
测试、加密检查、说明书检查…)，并要求写入测试方案中。
4、传统测试流程遇到的挑战和对策----问题发现得越早，解决的代价就越小
1、 自动测试工具和测试理论
由于我们的产品开发模式还不够规范、相关文档不够完备，所以测试工具的应用效果不理想，只能部
分应用。如：SQA。
对于测试理论，测试思想/测试理念的灌输工作还是有成效的，但是测试数学模型的研究和建立工作
进展不顺利，主要原因也是我们的产品生命周期内部操作不够规范。
目前主要依赖于：测试人员的经验和素质；产品说明文档和项目组的技术咨询；测试设计。
2、 测试分类
根据目前的实际情况(已经由传统的瀑布开发模式、使用结构化设计和实现手段，变为现在的RAD开发
模式、使用OOD和OOP)，我们将把测试分为三种：产品测试、项目测试、系统评测。我们的依据是：问题
发现得越早，解决的代价就越小。
产品测试的流程基本和上面提到的一样。
项目测试的原则是尽早加入测试，并充分重视和支持用户测试。
系统评测是简化工作流程。 |
评分
-
查看全部评分
|
/1 
关于我们
发表于 2006-12-27 16:00:10
QQ好友和群
QQ空间
腾讯微博
腾讯朋友
微信
收藏
置顶服务
换色服务
楼主
