分享ERP测试经验

第一篇：分享ERP测试经验

正在进行当中的PConline首次ERP压力测试，测试过程的最大感悟是随时随地等待着“不可预知”的错误发生，也许发现这些问题也算是测试本身的使命之一。bug经历得多了也勉强有些经验了，再借鉴下ERP厂商专职的ERP测试人员，总算有了一些可以和各位读者可以分享的经验了。

基本ERP系统拓扑

一、测试的目的和原则

测试概念的范畴

广义上讲，测试是指软件产品生存周期内所有的检查、评审和确认活动。如：设计评审、系统测试。

狭义上讲，测试是对软件产品质量的检验和评价。它一方面检查软件产品质量中存在的质量问题，同时对产品质量进行客观的评价。测试的目的

简单地说，就是替用户受过，测试的最终目的是确保最终交给用户的产品的功能符合用户的需求，把尽可能多的问题在产品交给用户之前发现并改正。

具体地讲，测试一般要达到下列目标：

（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、界面中英文混杂，经常弹出莫名其妙的信息，而且还拼错单词

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、更多地从用户使用的角度考虑设计、编码与测试

第二篇：erp实施经验

如何盘活失败的erp项目

一个投入上千万的大型ERP项目上线延期了。上至董事长，下至业务主管，所有的怨气都要撒在ERP项目主管钟剑的身上。问题出在哪里？天时、地利与人和，到底是哪一方失利？面对ERP乱局，唯有逐条分析原因，才可以对症下药，解开难题。在逐条捋清问题后，钟剑使出了他的撒手锏，问题迎刃而解。

案例篇

ERP失败算不得稀罕事，但是找到败因，力挽败局，就不是一般CIO都能顺顺当当做下来的了。面对即将或者已经失败的ERP项目，很多CIO会选择遮掩下来，毕竟从选型到实施自己都是项目经理，承认项目失败就是认定自己无能，更不消说领导面上无光，企业形象受损。

如何能在败局中取胜？这家大型生产企业的ERP项目经理钟剑自有一套。

发难

钟剑不知道怎么走出会议室的，他下意识向15楼走去，上了4层楼就感觉气不顺，楼道安静而气闷，额头上开始冒汗了。

“公司花费了上千万元，投入了几十个人的精力，为什么ERP项目拖了一个月还是无法上线，这样一种混乱的局面是什么原因造成的？”刚刚过去的项目进度汇报会上，面对一堆问题，CEO王总责问道：“钟经理，你们信息部在‘脚踩西瓜皮’，作为项目经理，你应该好好思考一下，明天给我一份报告，告诉我原因和解决方案！”说完摔门而去，把项目组成员扔在会议室里，大眼瞪小眼。其实，这也不能怪王总，刚刚项目阶段汇报会议上，各部门反映的情况也真够乱的：

销售部门营销平台的数据通过接口导入ERP系统时，跨月部分产生重复；

生产计划通过MPR计算出来的结果，与目前人工计算差别过大；

采购订单运行项目数据无法自动带到入库单上，需要手工重新录入；

财务报表无法正确显示，会计科目平衡表数据是正确的，但资产负债表一直不平；

仓储存货账与财务账无法做到账账相符，存货账与实物账也存在着一定的差距；

业务部门最终用户在培训操作过程中，发现操作手册上写的内容在系统中根本就找不到，或有出入，且相对比较简单；虽然经过单元测试，但测试的场景过于简单，没有涵盖日常业务运营的全部内容；

在最终用户操作培训的过程中，很多业务部门自己上报的参培人员也没有参与过一次ERP的相关培训；

业务部门投入到项目组的关键用户，大多数是本部门的骨干，但由于他们工作繁忙而没有全力投入项目，造成关键时候找不到人，与其有关的关键问题讨论时他们亦不在场的现象，使得会议一拖再拖，尤其是销售大区和某工厂的关键用户连一次最基本的ERP功能培训都还没有参与；

„„

回溯

钟剑一边回忆着会议上的情况，一边郁闷地转出楼道门乘电梯回到自己位于15楼的办公室。一年前，通过猎头进入这家大型生产企业，经过调研、分析，在了解企业信息化发展现状和业务特点后，他提交了公司信息化三年建设方案。然后，按部就班地着手基础设施的建设、IT部门的团队建设，慢慢熟悉并融入该企业。去年年底ERP系统建设列入公司重点项目计划，这也正是钟剑过来的动因。虽然在原来的集团公司他经历了国外大型ERP项目实施的过程，但角色只是其中一个组的组长，负责某一小块具体的业务流程设计和系统实现工作，没有能够参与项目管理的内容，所以他一直希望能够作为项目经理全程参与和统率一次ERP项目。

ERP项目被正式列上议事日程后，钟剑在进行业务需求调研后，严格按照ERP实施的标准方法，进行了系统选型，最后选择了一家大型ERP系统软件。对实施的顾问团队，他也是一个一个简历看过，个别还进行了面对面的交流，可谓精心挑选。经过半年的努力，终于到了即将上线的最后时刻，但项目停滞不前，出现了上述的混乱而复杂的局面。这种局面究竟是如何产生的？钟剑收回思绪，打开工作目录下的ERP项目文档，一项项内容井井有条地展现在眼前。项目计划：

在项目准备阶段，项目计划的编制成为甲乙双方两位项目经理的主要工作内容，将6个月的总体上线任务和工作内容细化到周甚至到日，并在统驭项目主计划的同时，进行了数据计划、项目整体培训计划、项目宣传、活动计划等内容，以确保项目计划的周密且不遗漏。

“计划没有变化快”。由于人员投入不够，项目虽然按着计划在向前走，但总是存在着这样那样的问题，无法做到深入和完善。而最终导致系统上线推迟的最主要原因就是初期数据迟迟没有收集整理到位。

项目组织：项目组织的建设也是起初脑筋动得比较多的地方，公司成立了项目管理委员会，将公司主要高层都纳入其中，由CEO亲自担任；管理委员会下设项目管理办公室和监理组；接下来是技术组、业务组、数据组和开发组。其中业务组按此次上线的模块分为五个组：销售、采购/仓储、物流、财务和生产，业务组长均由相关业务部门负责人担任，再由其抽调部门骨干进入，同时信息部也在每个业务组派出一名代表。

起初，钟剑一再要求业务组必须有一名业务部门的骨干力量全职参与项目组，但最终由于业务部门负责人的反对，而导致目前业务组除信息部人员外全部属于兼职参与。经常一个讨论分析会都要一变再变地变更时间，尤其到后期的跨模块讨论时更难确定会议的时间。项目组没有一个统一的工作场所，顾问、业务组、信息部人员均在各自的办公室办公，只有开会时再聚到一起。由此，对项目所有工作的开展都产生了巨大的影响。

蓝图设计和系统实现：

由于前期准备工作比较充分，ERP项目启动前已经做过一轮业务流程的调研分析，加之ERP项目刚刚进入大家的视野，在蓝图设计中现状调研阶段，大家还是比较积极地参与，很快就完成了任务。但到了未来蓝图设计时，一是由于工作忙，二是“新婚期”已过，个别部门领导不再参与流程的讲座和分析，而由手下人参与，领导只看最终的汇报和文档，并也在蓝图流程上签字认可了，这些在当时并没有觉得问题有多大。但到了最终用户培训和单元测试时，却发现原来这些蓝图流程与老总们想的有出入，与那些部门骨干的思路也有出入，只好返工重来，还需要协调实施顾问的资源。在原本时间和人力资源比较紧张的情况下，这又浪费了不少时间，让人苦不堪言。这也是上线时间延迟、项目计划不能顺利执行的主要原因之一。

系统实现，一方面是顾问按业务蓝图流程设计进行配置和二次开发，另外就是关键用户熟悉系统，并进行业务场景在系统中测试运行的好时机。由于人力的投入不足，导致很多地方由顾问进行相对标准的测试就草草了事。有些测试虽然由关键用户进行的，但由于系统熟练程度有限，加之大多数部门关键用户没有足够重视，把测试当成一项工作任务来完成，应付了事，没有完全重现业务运作时的多重组合的复杂的业务场景，相对简单地进行了一些业务内容的测试。这就埋下了隐患。

数据整理和接口、报表设计：

数据，从一开始就提到比较高的地位，专门成立了数据小组来负责，静态数据很快就进行了统一编码、重新规范等工作，动态数据的模板设计和下发也进行得相对比较顺利，但在业务部门却没有引起足够的重视，或者没有及时提交，或者提交上来的数据没有完善地按模板进行填报，有些业务人员就象征性地填了一两列数据表就上交。因此，数据的整体收集和整理工作一拖再拖。

另外，由于公司从建立到现在有15年，历史遗留下来没有解决的问题比较多，集中反映到数据上就是：账实严重不符，日常在进行审计和核对时，大家只采用账账核对，而只有一些常用的原辅料和流动比较快的产成品在正常流转。这也是不同业务部门在上线数据不符进行调整时，争论得比较多的事情。

虽然公司其他的信息系统并不多，但由于整体行业信息化程度比较高，上下游企业之间的数据传输还比较频繁，为了解决这个问题，在选型时即确定通过接口的开发来完成。这块由于顾问公司人力投入不足，而信息部提交的开发技术人员招聘的事情也被莫名搁置了几个月，到目前为止还没有任何信息。

报表开发需求量也比较大，虽然已经开发好其中的一部分内容，但由于系统没有真实数据，很难对其正确与否进行评估和检查测试。

最终用户培训：

《最终用户操作手册》每个模块在顾问的督促下，在关键用户开始学习的时候就着手编制，只有少数没有关键用户投入的部门涉及到的操作流程未能完成。由于关键用户对于业务的熟悉程度不同、对ERP系统的熟练程度不一，操作手册的优劣差异很大。相对来说业务场景设计得比较全面，且能够详细截图、解说的《最终用户操作手册》不多，这也为最终用户的培训带来了问题。

在最初的培训计划中，安排的是专门的多场集中式培训，但由于业务部门工作繁忙，关键用户和最终用户时间无法统一调配，使得培训的方式变得五花八门：有集中进行培训的，有单一进行培训的，还有到最终用户工作现场进行培训的。反思

王总让钟剑整理一份情况报告，虽然在项目推进的过程中，上述问题都已经通过项目进展通报提交给公司高层和业务部门领导，也在会议上做过汇报和总结，并提出过应对措施，但可能是没有触及到他们的痛处，没有引起足够的重视。钟剑想，看来这一次不能再不痛不痒了，已经受到王总的责难，那就索性和盘托出，痛在一时比一直痛下去要好。

综合前面的回顾和分析，项目主要存在的问题是：

1.人员及精力投入：业务部门没有足够重视，虽然项目组里挂名的都是各个部门的领导，但真正投入的时间和精力的非常有限，个别部门虽然在项目的后期有专职常驻人员，但对业务本身的熟悉程度有限。制丝车间到现在连一个人都没有参与过，销售部西北大区连一个兼职人员都没有来听过课，而工厂的财务部成本会计居然从未露过面。

那么，这一块问题的解决，需要引起公司各部门领导足够的重视，并由项目管理委员会负责人CEO王总亲自发布命令，按最初项目组织的要求，抽调各部门得力骨干，全职参与到项目中来。

同时，需要有一个统一的办公环境，让项目办公室、实施顾问、关键用户坐到同一个办公室中去，以便充分交流，也使得顾问的知识快速传递给关键用户。2.数据整理：虽然经过项目组的努力，基础数据已经有了一定的规范，但那些日常运营的动态数据却迟迟不能收集到位，虽然数据也都采集上来了，但数据本身是不完整的，而主要的物料数据普遍存在着财务账和业务账无法“账账相符”，更不要说业务账和实物之间的“账实相符”了。

针对上述问题，需要动员所有业务部门，重新组建一次数据收集、整理的队伍，针对历史遗留问题进行认真分析，能够核对清楚的进行调账处理，不清楚的部分先打包进入系统，待后续阶段有精力时再进行解决。

3.业务测试场景设计：在业务测试和最终用户手册编写环节，由于顾问对公司的行业熟悉程度有限，协助关键用户进行的单元测试和集成测试场景设计相对简单和标准，没有考虑到业务的复杂变化，而关键用户的精力投入有限，大部门人都把测试当成一个任务而已，没有引起足够的重视，只是简单地设计并做了系统测试。而当最终用户参与学习时，有大量没有经过测试的业务情景出现，结果导致或者没有办法操作，或者问题一堆，再加上系统数据的缺失，使得业务部门最终用户对系统产生不信任感。

需要组织业务骨干，收集和整理日常业务不同的场景变化，统一编辑后，进入系统进行测试，并添加到《最终用户操作手册》中去，为今后最终用户的学习提取更翔实的指导。

4.需求变更：项目开展的前期，业务部门没有足够重视，在业务调研和流程梳理过程中，部门领导和关键业务骨干投入的精力有限，整理出来的业务流程细度和准确度不够，而在最终用户操作培训时，又提出了新的业务需求，且这些需求很多会引起较大的业务流程变更。

对于新提出来的需求，以不阻碍业务正常运转为前题进行筛选，关闭那些与界面、操作习惯等有关的需求，待ERP上线后再慢慢进行优化。

想到这里，钟剑不由得露出了一丝苦笑，其实在项目刚开始组建，以及后来的项目实施过程中，这些问题不止一次地提过，当时王总和各业务老总应允得很好，但最终结果却无法让人满意。他本想把这个项目建设成“公司级”的信息化建设项目，为自己的信息化职业生涯别上一枚金制奖章，最终，在实际项目推进过程中连“业务部门级”项目都没有达成，而沦落为“信息部门”的建设项目。这些是他这个信息部经理无法改变的。

这次的分析报告如果再不点醒高管们，这个ERP项目的走势很明显，而自己在这家公司的职业生涯估计就走到头了，职业生涯中的“污点”也就此留下。钟剑希望能够就此机会反戈一击，一举扭转几个月来的被动局面，给ERP项目成员注入强心剂，做成一个先苦后甜的好案例。

下定决心后，钟剑坐下，信心满满地准备继续“笔伐诸侯”„„

第三篇：自动化测试经验分享

一、测试的困惑

以前我时常反思，测试组的工作多吗？我的回答是多。测试小组的工作成果的好坏和工作任务的多少成正比吗？最终的回答却并非成正比。我们的测试工作成果往往并不理想，甚至是差。那么为什么事倍功半？这问题很难找到清晰的答案。

参与了外部培训之后，发现了自己在对测试的工作有了新层次的理解。对之前工作成果差的问题思考也有了新的方向。“测试的最高境界是找出所有BUG吗？不是，测试的最高境界是不需要进行测试。为什么不需要进行测试？是因为所有的问题都已经在软件各阶段中介入的测试工作中给预防解决了。由此引申，测试的定位并不是找出BUG，而是预防BUG。” 这是我培训报告中的一部分。如果测试的出发点只为是发现BUG，那么测试工作将会如何？辛苦的发现了一个BUG，之后开发针对性的修正了这个BUG，再回重新测试的过程，又会有多少人会重新被卷入，又会有多少BUG因此而产生，又需要花费多少时间，答案可想而知。这就是我们忙又不见成果的主要原因。所以改善这个问题的出发点就是改变对测试工作的认识——测试的目标并不是为了找出BUG，而是预防BUG的出现。

如何理解正确的测试目标是预防BUG的出现。首先可以从软件测试的阶段划分来看。软件测试的阶段划分为需求、设计、编码、测试、验收。但按此划分来定位测试是错误的。假如在编码阶段完成后测试出的BUG属于设计问题（这也是我们测试工作中经常遇到的情况），那么我们已经编码完成的产品就要面临着伤筋动骨的修改，这样的修改会带出多少个新的BUG出现？为这个修改我们又要重复的测试我们的新提交版本多少次？想必都有很深刻及惨痛的答案了。由此可以说明需求设计阶段的测试比编码阶段测试重要的多。在需求上出现的BUG就很有可能足以推翻整个产品。那么如果在需求设计阶段测试人员就能发现产品设计的BUG，那么就可以避免了因此而衍生的产品BUG，达到预防BUG这种测试理念的目标。

那么又如何能做好以预防BUG为目标的测试工作。“测试工作不只是一种技术，也不仅是一种活动。测试工作的成功也不能取决于测试成果，测试的BUG越多并不能证明测试工作做的好，所以由此引申，测试工作要站在团队的高度来开展，在团队中做好测试，而不是在测试小组中做好测试。”这是我培训报告中的另一部分。要做好以预防BUG为目标的测试工作，首先要尽早的参与到项目中，其次就是需要各部门及小组的大力支持，与业务、项目、代码人员共同形成团队，在团队中影响其他小组提高产品质量，更好的完成以预防产品出现BUG为目标的测试活动。

总结来看，我个人觉得拥有这样的测试理念可以解开我们的疑惑，带领我们走出目前的困境。

二、自动化测试迷失

随着工作、发展、提高等等多方面的需要，我接到了开展自动化测试的研究工作。概念上来说自动化测试是一种测试度量体系。现实点来说，自动化测试可以为我们自动、无误的运作完成大量且需要重复执行的测试用例。这是多么让人振奋的概念。甚至可以解开我上文所提到的有关测试工作的困惑。我很兴奋的去展开研究目前最流行的自动化测试工具之一QTP。甚至设计出了管理中心的三个重要功能的自动化测试脚本，并且运行无误在自动化测试讨论会上兴奋的向大家演示。之后还用工具按键精灵设计出了前端的A类测试用于实际的测试。但很让人沮丧的是最终这些脚本全被遗弃在电脑硬盘的角落，再也没派上用场。为什么？因为他们维护起来很困难，因为他们编写它们的时间与实现的价值并没有超过手工测试。这就是自动化测试吗？怎么不可行啊，我有点不太相信这种结局，所以我再一次困惑了。

外部培训的老师这样告诉我们：“我们并没有理性的看待自动化测试，自动化测试并不是我们看上去的那样美。首先自动化测试能直接的节约成本、让测试人员变轻松的想法是一个误区。因为原本用于手工测试的时间用来编写及维护测试脚本了，而完善的自动化测试脚本编写或维护的时间很可能会超过手工测试的时间。再者自动化测试脚本用例是测试人员所编写，自动化测试只能是沿着该测试人员的“足迹”前进。所以用自动代测试来发现更多软件产品问题的想法也是一个误区。其次并不是所有的测试都能自动化，测试的自动化也不一定是解决问题的最佳手段。”

听完这些，原本困惑的我又多了份惊讶，一方面惊叹产述的这些状况与我之前的自动化测试的试行失败是相近的。另一方面又猜疑这自动化测试该不会像共产主义社会那般吧！随着培训内容的展开，我终于解开了困惑，何为理性的看待自动化测试。

“如同不能指望原始社会拥有了汽车就能进入现代社会一样，自动化测试工具永远都不能主导测试实现自动化”（出自国信培训文档）。我们错误的把自动化测试看成了一种测试工具或测试手段。自动化测试是一种理念，它要发挥它真正的作用就需要这种理念转变为一种体系——自动化测试体系。

“引入自动化测试的前提是已经建立了合适的自动化测试体系，如果没有这些，而片面的追求自动化，无异于缘木求鱼。自动化测试体系是指能够适用某种环境的测试工具、过程、人员结构、方法的综合，运用于整个项目团队”。回到我之前的对QTP研究失败的原因，首先我开始就觉得因为研发的设计、编码实现并没有考虑到自动化，而导致自动化脚本的编写非常吃力。比如产品页面项目的命名不规范，导致自动化测试工具很难捕捉这些页面对像。其次就是测试脚本的方向迷失，我在研究QTP的时候就发现了这个问题。随着我一点点的在编写着脚本，我不断的发现自己在的测试脚本的编写方向上出现了迷失。这段脚本我编写的目标本来是功能测试，但随着我的补充却接近于开发级的单元测试。而另一段本属于功能性测试的脚本，因为功能的重点需要，我又补充了部分脚本导致整个测试脚本测试目标变成了完整关联性测试。而做为单元测试的脚本却并没有在开发的角度上来设计，根本做不到函数、类等代码级的测试，根本不能达到要求。做为完整性测试的脚本也无法模拟接口功能中几何倍数级的各种条件输入对应的输出测试。而功能测试脚本算是硕果仅存，但随着开发对产品的代码大规模调整（这些调整当然不会考虑对已经实现的脚本的影响）而直接“报废”。如果需要脚本继续工作，那么就要花时间来修改调整它。这些脚本的结局又再一次可想而知了。

所以首先我们要理性的看待自动化测试，不要片面的去追求它。对不同的项目要开展不同自动化策略。参考如下

（1）评审项目中特定的部分作为应用自动化的候选对像。

（2）从项目中高度冗余的任务或场景重点考虑自动化。

（3）将乏味且人工容易出错的工作重点考虑自动化。

（4）将回归测试经常需要“照顾”到的部分重点考虑自动化。

（5）自动化开始时要首先关注开发成熟、理解透彻、相对稳定的且不易变的部分优先考虑自动化

其次，自动化所实现的最大价值目标是可不间断的、可重复的自动执行对需求、设计、代码全面覆盖的大量测试用例从而预防bug的产生的一套质量保障机制。所以自动化测试的重点在于测试自动化作为一个体系，要运用于整个项目团队。项目组要讨论它（策略、时间、成本等）、研发需要参与它（编码方向、自动化支撑、以及代码单元测试自动化的计划和执行等）、测试要引导及推进它（策略、方法、执行、跟进、维护等），各团队共同形成体系，才能让自动化测试工具真正的成为一种质量保证的有力武器。

第四篇：测试经验小结

软件测试经验小结界面

界面测试

(1)测试界面设计是否合理、简洁、美观，操作是否方便

领测软件测试网

(2)功能键、数据项信息是否齐全 copyright 领测软件测试网

(3)确认系统中同一功能抌名称是否统一 http://www.ltesting.net

(4)设计样式、风格(查询条件样式;输入风格(点选/手输入);)是否与系统其它模块

领测软件测试网

统一 copyright 领测软件测试网

(5)确认页面内所有字段名称显示风格是否统一(居中、左对齐、右对齐，一般采用居中

内容来自ltesting.net

显示风格)

领测软件测试网

(6)

ltesting.net

1.1 新增页面及功能测试

领测软件测试网http://www.ltesting.net

字段内容来自ltesting.net

在开始测试时应该保证数据的正确性，然后再从系统中找出各种Bug 领测软件测试网

(1)各字段输入正确的信息值保存，确认系统是否可以正确完成新增操作。ltesting.net

(2)进入添加界面不输入任何信息值，单击“保存”功能按钮，系统应该给出某个不允许为

领测软件测试网http://www.ltesting.net

空字段的提示信息(属于边界测试)

http://www.ltesting.net

(3)建议不允许为空的字段前面加上‘*’作为标记(统一性，方便性问题)

内容来自ltesting.net

(4)编码/编号字段不允许输入中文及特殊字符，否则系统应该给出相应的提示信息

(5)测试编码/编号字段不允许重复，否则系统应该给出相应的提示信息 ltesting.net

(6)确认字段是否已做长度限制，如果输入值超出长度范围，那么在保存时系统应该给出提

内容来自ltesting.net

示信息

(7)非法测试，如：校验数值型字段输入非数值，保存时系统是否给出相应的提示信息;(根领测软件测试网http://www.ltesting.net

据实际需要确定数值型字段是否能够接受负数)

领测软件测试网http://www.ltesting.net

(8)边界测试，如：确认数值型字段的边界值(如：有效值为‘0-100’整数，那么输入-1 内容来自ltesting.net

或101 保存时系统应该给出相应的提示信息;输入值为0、100 系统应该能正确保存信

http://www.ltesting.net

息值;输入0 到100 内的整数值系统应该正确保存信息值)http://www.ltesting.net

(9)精确值测试，测试小数位数是否在定义的长度内 http://www.ltesting.net

(10)字段精确值是否正确(四舍五入否)。http://www.ltesting.net

(11)根据实际情况测试名称字段是否具有唯一性，(一般情况下名称是不允许重复的，具体

领测软件测试网http://www.ltesting.net

问题具体分析)，否则系统应该给出相应的提示信息

内容来自ltesting.net

(12)确认各字段名称书写是否正确(注意：要求编辑界面、住息列表中、错误提示信息、查

内容来自ltesting.net

询条件中的字段名称完全相同)领测软件测试网http://www.ltesting.net

(13)确认特殊格式的字段是否已做标准格式的限制(如：电子邮件、邮编等)

内容来自ltesting.net

(14)测试上级信息字段(如：上级XXX 名称、上级XXX 编号)的信息值是否根据所选择的上级XXX 名称系统自动生成(注意：编号生成值一定是维护界面的编号，而不应该是

内容来自ltesting.net

相应表的那个主键编码)

http://www.ltesting.net

(15)测试如果某字段信息值是从另一个模块中选择输入的，那么需要确认其它相关联字段的内容来自ltesting.net

信息值是否也相应的正确的自动带入，并且这些字段应该都是只读的

(16)创建人/编辑人、发布人、创建时间、创建人字段应该设为只读的，而且此类字段值应该领测软件测试网http://www.ltesting.net

默认当前操作人的姓名

ltesting.net

(17)如果某个字段可以点选输入多个信息值，那么测试该字段是否接受，并保存了点选输入

ltesting.net 的多个信息值 http://www.ltesting.net

(18)对于多选字段，测试是否具有记忆上次选择值并已验重

http://www.ltesting.net

(19)测试字符型字段是否可以接受空格(统一性问题，建议不要接受空格)copyright 领测软件测试网

(20)引用其它模块的字段信息值的字段长度是否与被引用模块相应字段长度一致

领测软件测试网http://www.ltesting.net

(21)

ltesting.net

1.2 多行添加编辑页面

ltesting.net

(1)测试插入单行是否可以正确保存相应字段值领测软件测试网http://www.ltesting.net

(2)插入/添加多行测试是否对多行相应字段空值是否进行校验(通常如果有多条空行保领测软件测试网

存时系统会弹出XXX 字段不允许重复提示信息，要求仅对空行不保存即可，不需 http://www.ltesting.net

要提示的)

领测软件测试网http://www.ltesting.net

(3)多行添加，测试如果某个字段值太长保存后是否会导致界面混乱

领测软件测试网http://www.ltesting.net

(4)保存---保存新添加的多行记录信息

内容来自ltesting.net

(5)保存---勾选待删除记录，单击此功能按钮系统正确完成删除操作领测软件测试网http://www.ltesting.net

(6)插入空行---单击此功能按钮系统插入一条空的记录行 copyright 领测软件测试网

(7)领测软件测试网

1.3 主子表编辑页面 http://www.ltesting.net

(1)测试只有保存主表信息后才能维护子表信息，否则系统应该给出相应的提示信息

http://www.ltesting.net

(2)如果子表信息是否需要维护取决于主表中的某个字段值，那么请确认主表中相关联 copyright 领测软件测试网的字段取值是否对应子表的存在(主表中较常用的取决子表存在的字段是“底层否”，领测软件测试网http://www.ltesting.net

如果与底层相关联一般只有在底层才能维护其子表信息)

领测软件测试网http://www.ltesting.net

(3)如果子表中有继承主表信息，那么确认继承的信息是否完全正确 http://www.ltesting.net

1.4 左树右表的测试方法

领测软件测试网http://www.ltesting.net

(1)添加、修改、删除保存后目录树信息是否要自动刷新(统一性问题)

领测软件测试网

(2)添加界面：测试继承上级信息的字段(如：上级机构名称、上级机构编码等)值系领测软件测试网http://www.ltesting.net

统是否自动生成，而且信息值是否是只读的copyright 领测软件测试网

(3)测试是底层节点才可以进行添加操作，还是非底层节点才可以进行添加操作(业务领测软件测试网http://www.ltesting.net

测试)领测软件测试网

(4)含有子结点信息的当前结点是不允许修改为“底层”结点的选择按钮可以相互切换

领测软件测试网http://www.ltesting.net

(4)为操作方便，建议‘有效否’的字段值添加时默认为‘有效’

内容来自ltesting.net

(5)

领测软件测试网

编辑控件(移动项目)

领测软件测试网http://www.ltesting.net

(1)测试保存后，编辑控件内各段落间系统是否自动加了空行(此控件常出现的问题)http://www.ltesting.net

(2)测试保存后，编辑控件上方是否会出现乱码

内容来自ltesting.net

(3)测试系统是否按设计的格式保存了信息值领测软件测试网

(4)

1.6 常用功能键的功能测试 http://www.ltesting.net

(1)保存---所有编辑页面如果未输入任何信息值而单击“保存”，系统应该给出“XXX 字

内容来自ltesting.net

段不允许为空”的提示信息领测软件测试网

(2)保存---如果某字段输入值有错误或超出长度范围，那么单击“保存”按钮时，系统应 ltesting.net

该给出相应的提示信息

内容来自ltesting.net

(3)保存---输入相关信息单击“保存”后，建议系统给出“保存成功”提示信息

(4)保存---测试新增/修改信息保存后，信息列表是否自动刷新 http://www.ltesting.net

(5)下一步---单击此按钮，如果有非空字段为空，系统应该给出相应提示信息;如果有字

内容来自ltesting.net

段输入非法值，单击此按钮系统应该给出相应提示信息;正常情况下单击此功能按钮，http://www.ltesting.net

系统进入到下一个编辑/操作界面

ltesting.net

(6)上一步---单击此功能按钮，系统应该正确返回到上一个编辑/操作界面

领测软件测试网

(7)浏览---测试该功能键功能是否已经正确实现，单击此按钮系统应该弹出文件选择页面，ltesting.net

并且可以选择输入相关附件 ltesting.net

(8)上传附件---测试上传功能已经正确实现，确认上传的附件在界面相应位置是否显示

http://www.ltesting.net

(9)下载---测试下载功能已经正确实现(可以将上传到服务器的附件下载的本地相应位置)copyright 领测软件测试网

(10)重新上传---保存操作后上传功能按钮名称应该自动变为“重新上传”，并且可以重新上

领测软件测试网

传附件 http://www.ltesting.net

(11)发布---测试该功能键功能已经正确实现，单击些功能按钮系统完成发布操作，相应的ltesting.net

信息状态变为“已发布”，发布人、发布时间系统自动生成或已经正确保存(注意：已

ltesting.net

经发布的信息是不允许再进行修改操作的)(根据系统需求及设计测试，有些系统只有

信息修改页面才有此功能)

内容来自ltesting.net

(12)取消发布---测试该功能键功能是否已经正确实现，单击此功能按钮系统完成取消发布

内容来自ltesting.net

功能，相应信息状态变为“未发布”(根据系统需求及设计测试，有些系统只有信息修领测软件测试网

改页面才有此功能)

内容来自ltesting.net

(13)关闭---单击此功能按钮系统将关闭当前页面，建议当单击此功能按钮时系统弹出“确内容来自ltesting.net

认离开此页面提示信息” ltesting.net

(14)查询---单击查询功能按钮，系统按钮输入查询条件进行模糊查询;查询条件输入非法

ltesting.net

值进行查询操作，系统应该查询0 记录领测软件测试网

(15)删除----未勾选待删除记录单击此按钮系统弹出相应提示信息;正常情况下系统删除所选

领测软件测试网http://www.ltesting.net

记录

内容来自ltesting.net

(16)选择---勾选待选记录，单击此按钮系统完成选择操作;单击选择超链接功能按钮系统完 copyright 领测软件测试网

成选择操作

内容来自ltesting.net

(17)取消选择---单击此功能按钮，系统完成取消选择操作(清除所有选择信息)领测软件测试网http://www.ltesting.net

(18)ltesting.net

1.7 华表(待续)

领测软件测试网http://www.ltesting.net

(1)测试华表自带的所有功能按钮/工具栏中的工具的功能是否可以正确使用(公式定

http://www.ltesting.net

义、添加加行、列;字体设置;图表;信息排序等)

ltesting.net

(2)测试可以在选定的单元格进行编辑等相关操作领测软件测试网

(3)测试是否可以手插入、追加、删除、重命名表页;手动设置表页尺寸等 ltesting.net

(4)工作表之间定义公式是否可能以确自动计算

http://www.ltesting.net

(5)测试输入的信息值是否与字段类型完全相匹配，不匹配是否有相应提示信息

内容来自ltesting.net

(6)相关模块是否可能正确调用已定义好的华表模板 http://www.ltesting.net

(7)调用的华表模板信息提取是否完全(确认调用的华表信息是否有丢失)ltesting.net

(8)确认调用的华表模板中的公式计(尤其是关联多个表数据的公式)算是否正确，精

内容来自ltesting.net

确值是否准确领测软件测试网

(9)如果华表中定义/调用的是树结构信息，确认同一等级的单元格合并的是否正确 http://www.ltesting.net

(10)测试可编辑的单元格是否支持复制、粘贴功能 ltesting.net

(11)测试可编辑的单元格复制粘贴后，注释信息是否会丢失或发生变化 ltesting.net

(12)测试引用的华表模板中的图表信息是否会丢失;是否会按输入/提取到的数据正确生 copyright 领测软件测试网

成图表 ltesting.net

(13)边界测试方法测试字段接收值是否正确

http://www.ltesting.net

(14)如果华表模板需要自动提取数据，那么确认被引用的模板是否自动提取了数据;提 copyright 领测软件测试网

取到的数据是否对应正确

http://www.ltesting.net

(15)ltesting.net

1.8 修改页面测试

http://www.ltesting.net

字段

(1)确认各字段是否已经保存了添加界面输入的信息值

内容来自ltesting.net

(2)确认各字段所保存/取到的信息值，是否与添加界面输入的相关信息值完全匹配（1、领测软件测试网

确认字段保存值是否有串行

2、字段值是否经过校验)

领测软件测试网

(3)确认字段是否保存修改后的信息值领测软件测试网http://www.ltesting.net

(4)修改界面的字段长度是否与添加界面相应字段长度一致

(5)修改界面字段命名是否与新增界面相应字段命名完全一致领测软件测试网

(6)内容来自ltesting.net

1.9 管理/维护页面测试 ltesting.net

(1)测试界面整体设计合理，操作方便，尤其是查询条件排放是否整齐，操作是否方便;功领测软件测试网http://www.ltesting.net

能按钮顺序设计是否合理，操作是否方便，(一般顺序为查询、添加、删除)领测软件测试网

(2)测试信息列表是否有一定的排序规则(建议如果有时间一般按时间倒序--先从客户要求)ltesting.net

(3)测试维护界面各功能按钮功能是否已经正确实现 ltesting.net

(4)测试系统内不同模块相同的查询条件值输入方式是否统一 ltesting.net

(5)测试各查询条件是否起作用，即输入查询条件值可以查到相应查询结果

(6)测试可以手动输入查询条件什的查询条件支持全部模糊查询;通常对于下拉选择输入、内容来自ltesting.net

点选择输入的查询条件仅支持精确查询 ltesting.net

(7)测试信息列表中显示的信息(字段)是否齐全，是否方便查询/查看

http://www.ltesting.net

(8)测试信息列表中信息值显示格式是否统一 ltesting.net

(9)测试列表各字段信息值是否有折行显示，要求所有字段不允许折行显示 ltesting.net

(10)测试是否提供翻页查询功能，并且功能是否已经正确实现 http://www.ltesting.net

(11)测试信息列表中的链接数据是否正确链接到相应信息界面 http://www.ltesting.net

(12)下拉选择输入格式的查询条件如果没有特殊要求，系统默认查询‘全部’选择值 ltesting.net

(13)测试时间查询条件查询结果是否正确：

1、查询结果包括边界时间值的记录;

2、不包括 http://www.ltesting.net

边界时间值的记录(统一性测试

内容来自ltesting.net

(14))copyright 领测软件测试网

1.10 权限测试主要包括以下内容

内容来自ltesting.net

根据需求等相关文档，查看程序设置权限级别是否正确，即每一级别的用户所能执行的功能 ltesting.net

是否分配正 ltesting.net

1、业务权限

领测软件测试网http://www.ltesting.net

(1)按需求测试用户业务权限分配是否正确，业务权限主要控制功能模块、功能菜

ltesting.net

单的展示，没有相应业务权限的不展示其功能模块有功能菜单。所有需要使用

领测软件测试网

不同权限级的户进入系统，验证业务权限实现是否正确。

领测软件测试网

(2)

ltesting.net

操作权限

领测软件测试网

(1)权限组：按组用户来分配操作权限。(组内所有人员都具有所分配的操作权限)

(2)测试已分配操作权限的功能按钮是可见的http://www.ltesting.net

(3)测试已分配操作权限的功能按钮是否可用;是否可以正确完成相应功能操作 ltesting.net

(4)通常不分配调看操作权限是无法进行修改操作

领测软件测试网

(5)验证同一功能菜单不同权限用户的操作命令的查看及操作权限分配的是否正确

领测软件测试网

(6)使用没有分配特定权限(特定权限指特定信息的查看权限)的用户登陆系统,进 copyright 领测软件测试网

入指定的功能菜单中验证是否可以查看到相应信息.http://www.ltesting.net

(7)测试将已分配的操作权限删除后重新登录，确认用户是否还具有其相应操作权

领测软件测试网http://www.ltesting.net

限。

ltesting.net

(8)测试子结点是否继承了父结点操作权限(如果勾选了继承，则当前结点自动继

领测软件测试网

承其父结点的所有操作权限，否则只具有给当前结点分配的操作权限)ltesting.net

(9)领测软件测试网

1.11 对用户名、密码的有效性测试

ltesting.net

(1)密码信息有效性测试：特殊字符、正常字符、空字符(不输入)、空格

(2)登陆名是否区分大小写

ltesting.net

(3)登陆名是否允许重名 ltesting.net

(4)用户名字和密码都为最大长度(边界值分析，取上点)ltesting.net

(5)用户名字和密码都为最小长度(边界值分析，取上点)copyright 领测软件测试网

(6)用户名字和密码都是非最大和最小长度的数据(边界值分析，取内点)copyright 领测软件测试网

(7)用户名长度大于要求1 位(边界值分析，取离点)领测软件测试网

(8)用户名长度小于要求1 位(边界值分析，取离点)领测软件测试网

(9)密码长度大于要求1 位(边界值分析，取离点)

(10)密码长度小于要求1 位(边界值分析，取离点)

内容来自ltesting.net

(11)是否记住上次登陆名领测软件测试网

(12)密码信息有效性测试：字母数字混排、数字、符号数字、字母符号、数字符号、空字 copyright 领测软件测试网

符(不输入)、空格、ASCII 字符、字符串在有空格、串在有半角空格

内容来自ltesting.net

(13)口令锁定：即输入口令次数的限制

(14)密码显示是否以星号或者别的符号显示内容来自ltesting.net

(15)看是否支持tap 和enter 键等领测软件测试网http://www.ltesting.net

(16)密码是否可以复制粘贴

内容来自ltesting.net

(17)copyright 领测软件测试网

密码修改测试方法

领测软件测试网

(1)不输入旧密码，直接改密码

ltesting.net

(2)输入错误旧密码

内容来自ltesting.net

(3)不输入确认新密码 http://www.ltesting.net

(4)不输入新密码 copyright 领测软件测试网

(5)新密码和确认新密码不一致 copyright 领测软件测试网

(6)新密码中有空格

领测软件测试网

(7)新密码长度有效性测试方法同上 copyright 领测软件测试网

(8)新密码为非允许字符(如有的密码要求必须是英文和数字组成，那么要试汉字和符号等)领测软件测试网

(9)测试密码是否区分大小写，新密码中英文小写，确认密码中英文大写

领测软件测试网http://www.ltesting.net

(10)新密码与旧密码一样能否修改成功

ltesting.net

(11)领测软件测试网工作流(待续)http://www.ltesting.net

(1)测试流程启动后是否严格按照所选择的流程模板自动流转

内容来自ltesting.net

(2)测试在流程流转过程中相关人员是否可以维护流程步骤 copyright 领测软件测试网

(3)测试流程流转过程中，所有操作按钮是否已完全按需求实现

领测软件测试网http://www.ltesting.net

回退：根据具体的业务需求确认回退目标是否正确/是否正确回退给了指定的目

内容来自ltesting.net

标 http://www.ltesting.net

转交：确认转交的目标是否已经接收并可以进行相关处理操作内容来自ltesting.net

审核：确认审核通过流程流转是否正确领测软件测试网http://www.ltesting.net

审核通过：通常会自动流转到下一个处理人处;或流转到下一个处理阶领测软件测试网http://www.ltesting.net

段;或返回到指定负责人处内容来自ltesting.net

审核未通过：如果审核未通过，通常会停留在当前审核步骤，待下次送 copyright 领测软件测试网

审后再次激活当前审核步骤;有时会返回到项目负责人处，待项目负责人处理

并激活流转步骤。

拒绝审核/审核未通过：测试拒绝后流程流转的是否正确

领测软件测试网http://www.ltesting.net

结束：根据实际需求而定，有的系统有此需求，有的没有。如果有此需求，那

领测软件测试网http://www.ltesting.net

么需要测试特殊人员是否可以强制结束流程的流转，测试强制结束的流程状态

http://www.ltesting.net

是否正确领测软件测试网http://www.ltesting.net

归档：测试流程流转结束后，相关信息是否已经归档;(确认强制结束的信息是领测软件测试网http://www.ltesting.net

否已归档，状态为‘已结束’)领测软件测试网

分发传阅：测试传阅对象是否已经正确接收到传阅信息;测试传阅人的操作权

http://www.ltesting.net

限是否正确(一般对于传阅人某些操做是不允许的);根据需求及模板的定义测

试测试传阅人是否全部传阅完成后，分发人才可以办理/提交到下一个流程阶段。

ltesting.net

(根据实际情况测试，有些工作流是不需要此操作的)内容来自ltesting.net

(4)测试在流程在流转过程中是否已作权限限制(如：操作按钮的使用权限;附件编辑，内容来自ltesting.net

查看权限，信息的编辑、相看权限)-----参考权限测试方法 ltesting.net

(5)测试流程跟踪/历史审核信息是否正确，记录是否齐全(一般按流程步骤，操作时间

升序排列)领测软件测试网

(6)如果当前办理/审批阶段是以组的形式存在的，那么需要根据需求及流程模板的定 copyright 领测软件测试网

义，测试是需要组内成员全部办理/审批完成，流程流转到下一流程阶段，还是只需

组内一个成员办理/审批通过就可以流转到下一个流程阶段领测软件测试网

(7)跟踪测试，跟踪一条数据的流程，保证数据的正确性(个人认为工作流最有效的测 ltesting.net

试方法)

ltesting.net

(8)领测软件测试网http://www.ltesting.net 业务测试(待续)

要做好项目的测试工作，保证测试质量，必须对业务流程非常熟悉。对业务的熟悉程度

http://www.ltesting.net

决定你测试能做到多深的程度。

(1)测试某些特殊字段的选择值是否已经升效，如(底层否：如果值为‘是’，那么不允 copyright 领测软件测试网

许再为当前结点添加子结点，否则还可以继续为当前结点添加子结节点。如果有效

领测软件测试网http://www.ltesting.net

状态：选择值为‘有效’，那么当前信息才可以被使用或被引用，否则不可以(初始内容来自ltesting.net

化查询时应该过滤掉)。启用否：如果选择值为‘是’，那么相应信息才可以被引内容来自ltesting.net

用，否则不可以(初始化查询时应该过滤掉))

(2)测试信息时，一年只能有一条信息，否则系统应该给出“该信息已经存在”

内容来自ltesting.net

提示信息 http://www.ltesting.net

(3)测试信息的子表信息：a)同一内同一子表内的信息值不允许有重复(编号、领测软件测试网http://www.ltesting.net

名称)信息，否则系统应该给出相应的提示信息。b)不同内同子表内的信息值

是可以有重复信息的内容来自ltesting.net

(4)某些信息只归属于底层信息，在测试时注意当前位置是否是底层(此类业务常出现领测软件测试网

在左树右表的信息维护及主子表的信息维护中)

领测软件测试网

(5)如果当前结点含有子结点信息，那么当前结点信息是不允许删除，否则系统应该给

http://www.ltesting.net

出相应的提示信息

ltesting.net

(6)被其它模块引用的信息是不允许删除的(根据实际情况测试被其它模块引用的信息

领测软件测试网http://www.ltesting.net

是否允许进行修改操作)http://www.ltesting.net

(7)含有子结点信息的当前结点是不允许修改为“底层”结点的 copyright 领测软件测试网

(8)只有底层结点才能继续维护其子表信息否则应该将其子表信息隐藏 copyright 领测软件测试网

(9)主模块是否可以正确调用子模块信息（1、不估任何操作主模块自动调用子模板信息;内容来自ltesting.net

2、启动操作后主模块调用子模块信息)

(10)测试确认主模块调用子模块信息时，被引用的信息是完全对应并且无丢失内容来自ltesting.net

(11)测试被引用的信息是否可以进行修改操作(通常作为基本信息被引用时是不允许进领测软件测试网http://www.ltesting.net

行修改操作的;而在工作流程中被引用/调用的信息是可以进行修改操作的)内容来自ltesting.net

(12)工作流程是否严格按需求中的业务流程流转

(13)工作流程中权限分配是否正确

内容来自ltesting.net

(14)工作流中必须严格按分配的权限操作

http://www.ltesting.net

(15)测试仅限于某个阶段才能进行的操作，在其它阶段是否禁止或无此操作按钮内容来自ltesting.net

(16)根据需求确认，如果当前审核步骤已经审核结束，需要经过某个操作激活下一审核

内容来自ltesting.net

步骤还是系统自动流转到下一审核步骤 copyright 领测软件测试网

(17)我的任务

领测软件测试网

1)待启动的项目：统计查询需要当前登录人启动的项目(启动人操作权限根据需求来

确定----通常是项目负责启动项目)。查询列表应该提供启动操作，启动操作后相应 copyright 领测软件测试网

项目信息自动过滤掉。内容来自ltesting.net

2)待分派项目：统计查询分派是当前登录人的项目。分派操作后相应项目信息自动过领测软件测试网http://www.ltesting.net

滤掉。内容来自ltesting.net

3)待审核/处理的项目：统计查询在审核阶段，并且当前审核步骤的审核人/处理人是

内容来自ltesting.net

当前登录人或包含当前登录人的项目。查询列表中应该提供可能直接进行审核的功

ltesting.net

能按钮，审核操作后操作后相应项目信息自动过滤掉。http://www.ltesting.net

4)我参与的项目：统计查询已启动但未结束并且当前登录人做为项目组内成员参与的 ltesting.net

项目信息 http://www.ltesting.net

5)我负责的项目：统计查询已启动但未结束(并且当前登录人是项目负责人的项目信

息根据需求确认，有时我管理的项目不受条件限制统计查询所有当前登录人是项目内容来自ltesting.net

负责人的所有信息信息)。

ltesting.net

6)已审核的项目：统计查询当前登录人已经审核完毕的项目信息(注意有的需求这里

领测软件测试网http://www.ltesting.net

只查询统计在审核阶段的已审核的项目)http://www.ltesting.net

(18)

领测软件测试网http://www.ltesting.net 权限测试 ltesting.net

2、业务权限 copyright 领测软件测试网

(3)按需求测试用户业务权限分配是否正确，业务权限主要控制功能模块、功能菜

ltesting.net

单的展示，没有相应业务权限的不展示其功能模块能功能菜单。http://www.ltesting.net

(4)领测软件测试网http://www.ltesting.net

操作权限 copyright 领测软件测试网

(10)权限组：按组用户来分配操作权限。(组内所有人员都具有所分配的操作权限)

(11)测试已分配操作权限的功能按钮是可见的http://www.ltesting.net

(12)测试已分配操作权限的功能按钮是否可用;是否可以正确完成相应功能操作

领测软件测试网

(13)通常不分配调看操作权限是无法进行修改操作领测软件测试网

(14)领测软件测试网http://www.ltesting.net 算法

内容来自ltesting.net

(1)测试前需要充分了解算法的整个计算过程及结果值的精度领测软件测试网http://www.ltesting.net

(2)算法测试之前需要准备充足，而且是准确无误的测试实例 copyright 领测软件测试网

(3)根据输入值确认系统计算输出结果是否与预期结果完全一致

领测软件测试网

(4)如果计算公式中含有引用其它模块的数据，需要先确认数据提取是否对应的正确内容来自ltesting.net

(5)先用等价划分法、边界值测试方法测试输入数据是否在需求范围内

领测软件测试网http://www.ltesting.net

(6)严格按照测试用例执行测试，确认计算结果是否正确无误，注意结果的精度。copyright 领测软件测试网

(7)copyright 领测软件测试网压力测试

(1)压力测试前需要准备压力测试方案，构造测试数据，搭建测试环境内容来自ltesting.net

1.准备测试数据

领测软件测试网http://www.ltesting.net

确定性能测试指标： http://www.ltesting.net

1)用户容量(系统的最大注册用户数);

ltesting.net

2)系统负载(最大负载，最小负载);

领测软件测试网http://www.ltesting.net

3)网络带宽;

领测软件测试网

4)并发的用户数;(同一时刻承受的最大压力，测试对象“系统登录”)领测软件测试网

5)典型事物的响应时间;(用户给定的可接受的时间上限)

http://www.ltesting.net

6)稳定运行时间：在指定的事物数、指定的负载用户下、稳定运行时

间;

领测软件测试网http://www.ltesting.net

根据性能测试指标，选择一个业务场景：领测软件测试网http://www.ltesting.net

7)登录业务;(并发用户数)

领测软件测试网

8)系统日志查询业务;(典型事物的响应时间)

ltesting.net

9)报表(多表)查询业务;http://www.ltesting.net

10)简单事务;(稳定运行时间：在指定的事物数、指定的负载用户下、领测软件测试网

稳定运行时间)http://www.ltesting.net

2.搭建测试环境;

内容来自ltesting.net

测试环境尽可能的与用户的客户端环境相同。ltesting.net

3.执行测试

ltesting.net

4.结合性能测试指标，分析实时监视图表，确定系统瓶颈;ltesting.net

事物的响应时间是否可以接受? http://www.ltesting.net

网络带宽是否足够?

内存是否够用?内存是否泄漏? ltesting.net

Cpu 是否堵塞? 内容来自ltesting.net

系统能否处理高负载?

领测软件测试网http://www.ltesting.net

(2)根据性能缺陷，进行缺陷定位，调优工作;直到满足性能测试指标。领测软件测试网http://www.ltesting.net 安装测试

(1)自动安装还是手工配置安装，测试各种不同的安装组合，并验证各种不同组合的正 copyright 领测软件测试网

确性，最终目标是所有组合都能安装成功。领测软件测试网http://www.ltesting.net

(2)安装退出之后，确认应用程序可以正确启动、运行

领测软件测试网

(3)卸载测试和安装测试同样重要，如果系统提供自动卸载工具，那么卸载之后需检验

http://www.ltesting.net

系统是否把所有的文件全部删除，注册表中有关的注册信息是否也被删除。领测软件测试网http://www.ltesting.net

(4)至少要在一台笔记本上进行安装测试，因为有很多产品在笔记本中会出现问题，尤内容来自ltesting.net

其是系统级的产品。(有条件的情况下)

领测软件测试网http://www.ltesting.net

(5)安装完成之后，可以在简单地使用之后再执行卸载操作，有的系统在使用之后会发

内容来自ltesting.net

生变化，变得不可卸载。ltesting.net

(6)安装时间是否合理;

领测软件测试网

(7)对于客户服务器模式的应用系统，可以先安装客户端，然后安装服务器端，测试是领测软件测试网

否会出现问题。

http://www.ltesting.net

(8)考察安装该系统是否对其他的应用程序造成影响，特别是Windows 操作系统，经常 ltesting.net

会出现此类的问题。

内容来自ltesting.net

(9)

http://www.ltesting.net 统一性测试

http://www.ltesting.net

(1)所有弹出窗口居中显示

领测软件测试网http://www.ltesting.net

(2)所有页面设计要求饱合，但尽量不要有横纵滚动条 http://www.ltesting.net

(3)页面设计风格要统一 ltesting.net

(4)要求编辑界面、住息列表中、错误提示信息、查询条件中的字段名称完全相同

内容来自ltesting.net

(5)添加/修改保存后，添加/修改界面是否自动关闭要求统一(建议修改保存后，修改界

面一般是自动关闭)

http://www.ltesting.net

(6)一个系统中相同功能的按钮名称要统一(如：添加新增，取消取消选择)

内容来自ltesting.net

(7)底层结点不允许添加子结点信息，那么单击底层结点时，“添加”功能按钮设为不可 copyright 领测软件测试网

用的，还是系统弹出相应的提示信息，在一个系统中要求统一

领测软件测试网

(8)同一个功能按钮，不同模块相同的错误提示信息是否统一 ltesting.net

(9)不同模块相同字段值的输入方式是否统一领测软件测试网

(10)领测软件测试网http://www.ltesting.net 易用性测试 ltesting.net

(1)默认按钮要支持Enter 及选择操作，即按Enter 后自动执行默认按钮对应操作。(根

领测软件测试网http://www.ltesting.net

据实际情况现在可以只对登录界面要求此易用性)

领测软件测试网

(2)可写控件项检测到非法输入后，应该给出说明并自动获取焦点

领测软件测试网http://www.ltesting.net

(3)按Tab 键可进入下一个输入框 copyright 领测软件测试网

注意：在修改过的Bug 确认时，不仅要确认修改的Bug 是否已经通过，而且还要测试修改

后的程序是否引出新的Bug，因为在程序员刚修复Bug 之后时,往往程序员只修复报告出来 ltesting.net 的缺陷而不去考虑别的功能在修改时可能会造成新的错误。

软件产品测试部对经过内部单元测试、集成测试和系统测试后的软件所进行的测试，测

内容来自ltesting.net

试用例采用业务流程测试用例

领测软件测试网

转自:领测软件测试网[http://www.ltesting.net]

原文链接:http://www.ltesting.net/ceshi/ceshijishu/rjcsgcsrm/2011/0610/202582.html

第五篇：ERP、MES及WMS经验分享

ERP、MES及WMS经验分享

作者：比亚迪IT部ERP项目经理何垂乾

我今天为大家演讲的ERP、MES及WMS应用经验。在今年我做了几十个SAP项目，在我看来SAP项目实施其实很简单，所以我几乎不用管，最短的项目实施周期1-2周。我在汽车的信息化方案就没有请顾问，自己看文档就可以实施。比亚迪追求创新性，所以允许我们犯错误，允许犯错误，并不代表别人对我们的要求不高，我们的用户象外部顾问公司一样严格要求我们。

我们的IT团队很优秀，我经常告诫我下面的人说你不要告诉我做不到，他们很少做不到，只是时间问题，简单的问题就几天，难的就一个月。对于SAP，有时候我要改变系统核心的东西，我们会想方设法通过改善和开发来实现我们用户的需求，从而提升用户的效率。我自己的SAP顾问加起来也有二、三十个了，我们可以同时做5个项目。我们MES项目也有20多个人，我觉得我们MES项目很难做，以前我也跟一些CIO聊过，通常MES的报价很贵，很多都是几千万，包括我们做汽车，MES项目确实很难实施，有一些是SAP顾问过去实施MES，很多人都感觉特别艰难。

我们的MES系统最开始用了一个软件产品，后面都是自主开发，做到个性化十足。MES的概念就是制造集成系统，王总关注两点：一个是成本，在生产方面；第二是质量，SAP有QM，我们也上了一些QM，但是可能不好操作，要么数据不准，因为它对于应用不是很贴身。我们现在的MES应用重要到哪种地步？在业务应用中MES系统停一分钟，就马上有人找我们，这是好事还是坏事呢？这说明我们的系统就像鱼和水的关系。所以我们的压力很大，考虑的东西很多。

现在我们的系统和生产设备的集成是最多的，现在我们的MES和SAP系统也进行集成，例如跟仓库WMS系统的集成。我们MES做的主要目的是收集数据，来鉴定一些报表的分析。公司领导对MES很重视，要求我们将MES系统在整个汽车产业群进行推广，当时这个项目做的难度很大，我们10几个人同时要做两、三个项目。

我们做MES的时候和事业部的要求是一样的，都是当用户出现投诉的时候，就会追查一个根本的原因。但是我们规模很大，比如一个数据有300多参数，并且每个参数有很多字段，我们都是每天复印一箱的A4纸来去查，并且这样的方式会导致数据在过程中会丢失，没有数据库，没办法系统查，出现问题以后翻箱倒柜的，这个问题很严重。另外一个问题公司领导要求要追溯到原材料，假如出现问题以后原材料是谁送的，包括操作员工。所以我们在MES还做了一个模块，就是员工的记录，所有的员工都要在MES里刷卡，就清楚这批货是那批班次的员工在刷卡，经过的工序，生产时间，关键的参数，原材料批次的问题都可以追溯到。举例说，我们有条生产线经常用来成品组装，系统能够做到是否能够自动的调验和操作，提醒你做错了或者装错了怎么办。员工很容易出问题，上了MES以后，就不会出现这个问题。另外就是排序，比如某个客户给你399个不良代码，就要你排出来前十名的缺陷是什么，这样要是没有MES系统的话肯定排不出来的。

关于生产线的饱和度，到底它的利用率有多高？我们有个事业部就出现这样的情况：比如汽车总装考核生产效率，通过MES系统可以告诉每辆车的生产情况，它的产量是多少，一天能生产多少辆车，甚至我们做电池的，每台设备的吃喝拉撒都要记录下来。我们解决的办法是用一个十几块钱的单片机把56台设备全部控制到一台机器上，把它的信息装到我们的MES里面去。我就非常清楚，比如去上个厕所，按一下停机，回来再按一下开机。OEE的设备管理非常复杂，它会非常清楚设备停机的故障是什么，利用率有多高。我们有一万多种设备，他们都想管理得很清楚，还有合格率，生产数量，品质都会涉及到。MES在比亚迪中的应用其实也是被逼的，也是在跟先进的客户合作中逼迫我们使用MES，开始没有ERP，没有MES，当时MES是比较新的东西。所以说客户对质量品质的追溯，要求很高，后面做汽车是王总的要求，必须得树立公司品牌形象。

我们MES项目的应用应该是比较晚的，我们从08年1月份有这个想法，2月份才启动了这个项目。但是我们做的速度还是很快，项目都没停过，用了一个外部的系统是在IT产业群做手机组装的，后面汽车都是我们自己做的MES，包括我们的组装还有发动机，我们整个生产线都是我们自己开发设计的，整条线完全集成。我们自己做项目实施，自己可以管，MES基本上不花钱，比较便宜。

在做项目的时候分工都会很明确，不过不同的项目阶段人员的变动都不一样，我们开展业务分析的应用。在做了一系列项目之后，发现其实还是有许多相通的东西。但是不同产业群和不同行业它的需求是不一样的，但是我们界面的要求，MES项目应用的对象都是一线工人，有的甚至有不识字，所以界面要求特别简单，我们在业务组包括操作的友好性，怎么部署都比较清楚，为他们提供设计的方案，有我们自己开发的人员。系统组专门做服务器和开发程序的部署，包括压力测试。

我们第一次项目做的是生产节拍，这个项目是我负责的。第一个项目都会很难做，事业部的业务部门都很强势，比如原来生产量是每天2万台手机，他们就会跟你说你上系统可以，但你绝对不能低于2万台，但是实施MES的时候肯定会减少一点，所以说追求节拍要求很高。但是我很清楚，现在2万的标准是很低的，我们不上系统也会提高，所以不会影响到生产节拍。我们对成本控制很严，比如说MES里面叫做固定扫描箱和手动扫描箱，手动的800块一个，固定的是8千一个，但是手动扫描箱经常出错，我们就要换成固定扫描箱，换了以后减少了2个人的任务量，算一下成本很快就会回来。我们为了生产节拍，我们只能项目用的过程中在完善。其实我们的ERP实施也一样，实施顾问做的东西都是按部就班来做的，其实真正累的就是维护人员。

另外就是测试数据，就像我们的客户要求很严格，它的ID号关键的数字可能就有10-20个，并且要求分发式的。就比如下订单下100万，就会给你100万个入网许可证的号码段，要求我必须识别他的手机，识别他的请求，我要个性化的分配给他。我们开始做的时候，我们当时重了好几个号，出货就出不去，后来我们自己想出来在开发里面加了多重调研，结果是一千万台手机都不会有重复，MES只要用上，就会很好。每个标签都是在不同的工位打出来，并且要求很高，这是客户的项目。

刚讲的是我们手机组装那块，现在讲汽车。汽车要做到关键零部件的明确，就是说我们只要查一下零部件，就要查到用到哪个车，哪些订单，查车要知道我用了哪些零部件。我们力争做到组装一次性。其中发动机是相当复杂，要继承48种设备，发动机的专用生产设备，测试设备，这些参数的自动集成，还要提供实时报警的功能，达到一定的比例的时候就用邮件来报警，要实现生产过程系统的高效节能化。我觉得MES最难做的就是设备集成这块，设备五花八门，只是做硬件，软件很少，设备的解决方案有很多种，但都靠我们自己。

动力电池这块，包括跟所有产品集成，我们的设备很多，设备集成非常的灵活。我去看过他们的操作很简单，假如设定的值为10伏-20伏，那只有这个范围的电池才能通过。实现了仓库系统的集成，企业要是不够复杂的话，那就是SPC，但是SPC我们事业部做得很好，SPC就是统计学，我们有个副总裁就是SPC的高手，刚好他管这个事业部，一看SPC就能看出来他产品品质的情况。关于我们MES的经济效益，数据显示在比亚迪部门水平能降低23%，订单响应速度提高80%，不良率可以降低6%，供货时间可以提前67%，能耗降低23%。

接下来是仓库管理系统(WMS)，这是属于我们产值最大的一个事业部，是属于那个上市公司的事业部。他的仓库管理系统很复杂，在实施之前他看了十几家，因为我做这个项目之前没有做过，他让我先想我的思路。我当时做了2个方案，其实如果MES选择SAP作为支撑，选择一个外部的MES的话，在财务这块是过不了关的，但是那个事业部老又要求要确保财务数据的安全。我就在考虑到底外部团队对SAP的理解有多深？他能不能支持实施？接了这个任务很艰巨，我用了SAP的WMS，有一些主数据我不需要自己开发，配置相对来说简单。我们实现的功能很多，比如任务管理，杜绝工厂、采购等部门的互相扯皮，通过这种管理，让它变成一个流程来进行规范。现在的效果还不错，我们有专门的采购和收货指令，与SAP做集成，系统实现2个小时同步一次。

在仓库作业方面，按理来说一般的做法，是针对一种类型去做的。但是SAP有300多种移动类型，那你是不是每种都要去开发呢？我们就开发一种，就把所有的类型都做出来，包括原来的出入货，质量检验。大部分公司只做到工厂层和地点层。我们上了项目以后能够定位，能够找到料，能告诉你，上到哪个货架。

关于标签，如果我们的门户做好以后，我们打印标签就会很方便，只要在门户上挂一个链接就能在模板上打印。我们根据PO制定出货，但是有的采购部门并不适应，说我想要你交货的时候你就要交，不愿意修改交货日期。从而仓库管理与采购人员容易产生矛盾，明明这样做是不对的，本来是检验交货他变成机动交货，你说仓库会收吗？并且明明知道交货日期但是采购就是不愿意调整计划。经过开发以后，现在特殊时候也可以无指令交货。

最后一个是成品入库，还算简单。我每次到一些日本企业，他们都把管理做到系统里。我们国内就没这种条件，因为用户不认为他的操作是错的，只认为你系统是错的。按日本企业来说，一个产品和一个订单应该放在一起，我们很混乱。所以我们现在开发了PDA的扫描，现在跟SAP做集成，假如订单一个代码里有20箱货，20个订单，我扫20次，它会按照不同的订单来保存，产生20个物料凭证，跟超市一样。盘点我们是两次，是需要自动调，因为我们每一箱产品都用到一个ID号，每天要入6千多箱货，可能开始上线的时候会承受不了，盘点时用PDA去盘点很容易，原来本来应该上这个物料，但是上了别的物料，要求我们自动给他们调整，不用人工调节，我们也帮他们实现。所有我们有2次盘点，让他们在第一次盘点的时候如果不对可以再二次盘点，来调整出现的差异。

我今天的介绍就到这里。

分享ERP测试经验

第一篇：分享ERP测试经验

第二篇：erp实施经验

第三篇：自动化测试经验分享

第四篇：测试经验小结

第五篇：ERP、MES及WMS经验分享

相关范文推荐

测试工程师面试经验

ERP沙盘模拟总结(前人经验)

多年ERP咨询顾问从业经验分享

ERP沙盘模拟大赛高手整理经验集

软件测试经验与教训评论

《软件测试经验与教训》读后感

软件测试经验小总结[合集五篇]

ERP系统验收测试流程、方法原则及内容