ERP 测试经验

87117899

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

下面是一些低效的用户界面的例子：
1、表达不清或过于模糊的信息提示
2、要求用户输入多余的、本来系统可以自己得到的数据。如：服务是否启动，安装后用户要手动修改某些配置文件。
3、为了达到某个设置或对话框，用户必须做许多冗余操作。如，对话框嵌套层次太多。
4、不能记忆用户的设置或操作习惯，用户每次进入都需要重新操作一次初始环境。
5、使用不完善的功能且不给用户以恰当的提示。
6、不经用户确认就对系统或数据进行重大修改
稳定性问题：---影响用户正常工作
1、不可重现的死机，或不断申请但不完全释放资源，系统性能越来越低
2、主系统和子系统使用同样的临界资源而互相不知道。如：使用同样的类名或临时文件名、使用同样的数据库字段名或登录帐号。
3、不能重现的错误，许多与代码中的未初始化变量(在Debug时一般是缺省初始化的)有关，有些与系统不检查异常情况(如内存申请不成功、网络突然中断或长时间没有响应)有关。
其他问题
1、文档匮乏：无标准；无新功能使用方法；无版本改动说明。我们不仅要认为没有说明文档的产品不是是一个完整的产品，也要认为没有说明或没有正确说明的功能是一个没有完全实现的功能，因为用户无法用得起来。
2、运行时不检查内存、数据库或硬盘空间等
3、无根据地假设用户环境：硬件/网络环境；有些动态库；安装程序换台机器不正确；假设网络随时都是连通的
4、提供的版本带病毒，或根本无法安装，或没有加密
5、提供Debug版本给测试组或测试用户，或项目组与测试组使用不同版本
6、用户现场开发和修改，又没有记录和保留
7、错误反复出现，改动得不彻底、或版本管理出现混乱
8、错误越改越多，改动得不彻底、或改动得不小心
9、版本中部分内容和接口倒退
10、有些选项永远是灰的；有些选项、菜单项在该灰时还不灰，并且还能状态显示
11、资源没有和代码分离，不同语言版本间不能平滑转换
12、缺少第三方产品的评估：广告管理系统2000年问题
13、产品配合不利，准备当作一套产品或方案推出，互相之间却各不负责，(没有整个项目负责人，是面向组织的而不是面向产品或方案的)。
期望项目组关注的一些问题
1、修改Bug的人考虑得不够周全，也可能是没有能力考虑周全---不懂全部程序
2、问题留给测试组去发现的心态----不仔细测试、不小心修改、甚至不全面改(不彻底)
3、自己不会用，不了解产品的用法。
4、更多地从用户使用的角度考虑设计、编码与测试

[ 本帖最后由 87117899 于 2007-8-21 10:13 编辑 ]

云层

注意看看论坛，这样的问题有很多，解答都有

厍仕杰

你要是到一个公司全是做测试的更郁闷！