脚本测试经验分享

1、脚本测试特点

脚本语言语法简单灵活，与效率不是很相关的部分，使用脚本比较方便。对于多个文件的读写和控制，有比较成熟的库，几行代码可以解决C、C++需要较多代码才能实现的功能。特别是对多文件的处理，数据流动和处理比较复杂的情况。

脚本语言的劣势在于，缺乏严格的编译环节，变量定义，函数定义等问题发生概率比较大，会多制造一些障碍给测试人员。上帝关上一扇门，同时也开启了另一扇门，解释性的运行方式，使我们很容易在程序中插入测试代码，从而灵活的进行测试，对程序代码行、函数、代码段、脚本，都能在不同的粒度上进行控制，测试更加彻底，不易出现漏测问题。

2、打好语言基础

对脚本的快速测试，需要基于一定的语言基础，增强对脚本执行的调试能力：

1）sh –vx 执行看变量，sh –n 基本语法检查

2）快速多行注释，%s，快速注释多行方法“<<标记标记”

3）熟悉awk，shell的基本语法，基本用法

4）掌握awk快速对数据的分析能力

5）Perl、python的调试能力

3、如何做到无漏测

从问题角度出发，看存在哪些类问题，发现阶段最早在？

1）历史漏测点

A）Awk漏测，数据测试不充分，基于构造的方法比较困难，（看懂代码+理解逻辑+异常构造）

比如awk中的数据处理的第一条和最后一条是否符合预期，awk内存占用是否正常，可优化，数据的处理结果是否和预期一致。

B）上线单漏测

复杂上线单中的验证，上线的时间点是否合理（非线上运行时间）

C）多级环境部署漏测

多机环境下需要模拟，远程登录执行或者scp数据，用户之间要有信任关系，如spider@A到work@B的信任关系，需要在前面加上用户名，否则ssh B会有问题。

2）历史bug（可能漏测点）

知史而至今，前提是知史，需要对前面的问题有个学习，避免今后工作中出现。

3）无遗漏发现问题

从发现途径上，单步执行、分块执行、整体执行、考虑重复多次执行环境问题。从多个层次上对脚本进行测试和考虑，从细节->功能->整体运行维护：

A）Sh –x，sh -n 单步执行

解决语法问题、变量问题、文件存在性问题。

B）分块儿执行

避免语法、逻辑问题、异常处理验证、下载验证、md5验证、数据验证

C）整体多次执行考虑

线上是多次运行，历史数据维护，会不会有硬盘问题，会不会自动清理历史文件，历史文件的清理是否正确。

D）可维护角度

报警是否合理，是否报警过多。

E）上线阶段

上线时间是否合理，是否正在运行中，上下游数据准备好的时间是否有足够的时间缓冲。

F）上线检查

对log进行检查，及时发现问题。

从以上几个角度出发，测试的过程是完整的，有效地避免了bug中的大部分。测试难点在于：大awk的测试，异常测试、数据流程理解和数据异常测试、

历史环境、复杂上线单测试、多机环境部署配合测试。

本次只是针对awk测试重点进行讲述，awk如果出问题都是数据问题，影响效果，下面针对awk的陷阱做了一些总结：

Case1：代码阅读发现缺陷，基于逻辑的数据检查，注意第一条和最后一条的输出逻辑：

16 awk 'BEGIN{

17 pre_user=""；check=0；dead=0

20 }{

21 # pattern need check

22 if(ARGIND==1)

23 dict[$1]=$2;

24 else{

25 t=split($1,a,"/");

26 p1=a[1]"/"a[2]"/";

27 p2=a[1]"/";

29 if(p1 in dict)

30 p=p1;

31 else if (p2 in dict)

32 p=p2;

33 else next;

34 if(check!=0&&p!=pre_user){

35 print p,check >>"'$3'";

36

37 if(check==dead)

38 {

39 if(check>=dict[p])

40 print p,check >>"'$4'";

41 else print p,check >>"'$5'";

42 }

43 check=0

Case2：脚本中dump.sh调用filter.awk时，取不到dump.sh中使用的she ll变量，DEL_REASON的变量值，导致从LINKBASE上取到的数据经filter.aw

k处理后没有任何数据输出，dead.url_age.[$i]永远为空。

Case3：对2个有序文件进行merge，构造case的时候，构造文件$1，$2进行merge，如果$1先结束，会造成$1的最后一条还会不断打印出来，使文件

无序，如果$2文件先结束，则不会出现该情况，构造数据验证时要注意等价类

划分情况，保证所有情况都被测试到。

错误代码：

77 awk '

78 BEGIN{

79 key_url=""

80 key_all=""

81 ret=1

82 }

83 {

84 if($2<'$OLDEST_TIME') next

85 url=$1

86 while( url>key_url){ ######修改为while(ret>0 && url>key_url)

87 if(key_all) print key_all

88 while((ret=getline line < "'$1'")>0){

89 sp=index(line, " ")

90 tmp_url=substr(line, 1, sp-1)

91 if(tmp_url>key_url){

92 key_url=tmp_url

93 key_all=line

94 break

95 }

96 print line

97 }

98 if(ret==0) break

99 }

100 print

101 }

102 END{

103 if(ret) print line

104 while(ret=getline line < "'$1'"){ #######修改为((ret=getline line < "'$1'")>0 print line 105 print line

106 }

107 }' $2

4、加快脚本测试方法

做任何事情，如果想加快，都有一些熟知的方法：1、并行处理；2、借助于工具，自动化不需要人工介入的部分；3、加快必须人工部分的速度。如果把

上面的基本方式映射到我们的脚本测试中：

4.1 并行执行多个CASE

我们可以对多次运行做并行化。对于脚本类测试，大多数是挖掘类，基于一个比较复杂的测试周边环境，但是，不会修改本模块以外的环境和数据。

我们可以利用一个周边环境，部署多个被测程序，通过修改conf来保证运行：

a）对同一台机器部署多个不同目录（减少搭建周边环境）

b）对不同机器相同路径部署（减少修改conf）

对不同目录进行不同case运行。比如，新旧对比，性能，功能等同时进行。

同时对多个粒度进行测试，避免因为某次运行，占用环境，而堵塞我们的测试过

程。

4.2 借助工具

自动化操作步骤，这个我们自己可以编写test脚本来完成，比如性能监控，环境清理等功能。

借助于自动化通用工具，比如类似编译器的变量检查，路径检查，函数接口检查等，实现脚本之间调用关系和数据依赖关系的检查等。对很多产品线的公共问题，统一处理，这些都是大组、专人来开发和维护。

4.3 脚本测试技巧

人是灵活的，不是所有的工作都适合自动化。脚本测试设计中和代码逻辑强相关的部分，不易自动化，因为自动化要兼容多种可能性的时候，太复杂，而且不能保证100%的准确率，还是需要人工参与，比如：

问题1：if的异常分支，空文件构造，数据的清空逻辑，数据的历史维护逻辑，ssh逻辑，如何快速验证？

问题2：我们为了不同粒度的测试，需要多次运行脚本，有些脚本运行时间很长，是否可以一次运行，测试完所有粒度的功能？

上面这个例子中的一些技巧：

A）异常分支，我们可以通过添加语句mkdir –p a；rm a，来保证#？的检测

B）构造各种逻辑，或者看代码，看是否满足线上对数据逻辑的需求。

C）中间数据的保留，对需要长时间运行的代码块儿，插上桩，将结果cp 到其他文件，缩短时间，后续修改脚本代码，利用备份的中间文件多次独立运行，节省时间。

D）成功运行一次，和多次运行相结合，对中间文件如果在脚本被删除，需要我们再需要关注的关键点cp得到bak文件，运行一次后，保证任何段的代码（粒度），单独都可以运行。加上多环境，我们就可以在一次成功运行后，测试完所有的功能，同时并行完成性能测试。）

E）多机不同用户部署，可以变为单机不同用户部署；总控和运行机器，也可以通过单台模拟，和自己建立信任关系，来验证功能。

工作经验交流材料16篇

《工作经验交流材料》 工作经验交流材料（一）： 宣传工作经验交流材料 20xx年，我局狠抓信息报送质量，在审计信息工作中坚持服务大局，不断提升审计信息工作的综合效应，努力采取用心措施，信息采用率和批示率大幅度提升，取得了明显成效。全年共编发简报57期380篇，被各级报刊、网站等采用411篇次，比去年同期增长71.2%。其中审计署网站采用102篇，江苏审计网站采用239篇。值得一提的是，《xx对名人故居开展绩效审计》一文还被《xxx》第xxx期采用。我局2009年度的审计信息宣传被《xxx》及时代出版社评为先进单位，通联工作被《中国审计报》评为优秀单位，获xx市委市政府党政信息二等奖，省审计厅审计信息三等奖。 一、领导高度重视，统一思想认识 在局主要负责同志的强力推进下，我局构成了信息宣传工作齐抓共进的良好局面。克服了以往信息宣传工作以少数人为主多数人为辅的现象，只求数量、不讲效果的做法。全市各级审计机关切实把信息与宣传工作作为检验审计质量的重要标准，作为审计成果转化的重要资料，作为服务领导决策的重要途径。各市(县)区局都先后构成了一套比较科学合理和相对稳定的信息考核、奖惩机制，做到认识到位、职责到位，确保每个层面、每个环节都有明确的信息宣传工作目标和相关措施，真正构成全员参与、人人动手的良好氛围。 近年来，我局始终把审计信息宣传工作摆在重要位置。审计信息宣传工作在我局是一把手工程，局长要求全局统一思想认识，充分认识信息与宣传是整个审计工作的重要组成部分，是体现审计工作成果的重要载体。局领导经常透过各种会议强调信息宣传的重要性，对上级发放的信息刊物做到每期必看，对各类审计宣传媒体做到每一天必看，并经常作出批示，要求办公室瞄准先进，确保全局信息宣传工作的质量和水平。局主要负责同志还经常听取审计信息宣传工作汇报，不定期为信息人员出题目、理思路，并亲自把关、亲自修改。 二、加强队伍建设，构成整体合力 审计信息宣传队伍的思想理论水平、分析问题的潜力以及文字综合潜力，直接关系到审计宣传的质量。为此，我们抓住三个关键，切实加强审计信息宣传队伍建设，构成整体合力。 一是健全队伍。各县区局，市局各处室明确一名文字基础较好的同志担任信息宣传员，加强审计宣传工作中的沟通与协作。办公室信息宣传人员主动与县区局和市局处室挂钩联系。各县区局和市局处室有重要审计项目或活动，及时与信息宣传员联系，沟通状况，寻求宣传方面的支持和帮忙。信息宣传员主动与挂钩的单位、处室持续紧密联系，一方面注意发现、挖掘和采写审计中有价值的信息，另一方面及时修改、编发其报送的宣传稿件，对存在问题提出意见和推荐，对基础比较薄弱的，经常带给帮忙和服务，促进审计宣传工作均衡发展。 二是抓好培训。今年，我局采用专门培训和以会代训相结合的方法，抓好信息宣传人员的培训，不断提高信息宣传人员的思想政治素质和业务工作潜力。安排信息宣传员参加市里组织的理论学习和培训，定期召开审计信息宣传工作会议，让审计人员在学习中提高，在交流中进步。举办兵教兵式的培训，由办公室信息员根据工作实际，准备制作审计信息写作的课件，深入各县区局，宣讲信息宣传工作的重要性，同时讲解信息写作的重点和思路，对报送的信息宣传稿件进行点评，基层审计局普遍反映良好。下半年，拟邀请省厅办公室、市委政策研究室、

3性能测试赛题A6BS资产管理系统性能测试要求

任务四：性能测试 1、执行性能测试 本部分按照软件性能测试任务书要求，执行性能测试；使用性能测试工具LoadRunner ，录制脚本、回放脚本、配置参数、设置场景、执行性能测试并且 截图，截图需粘贴在性能测试总结报告中。性能测试具体要求如下： 。录制用户登录、资本录制：录制脚本协议选择“Web-HTTP/HTML ” 产维修模块进行维修登记、用户退出操作。录制完成后脚本名称命名为C_wx 。录制脚本具体要求如下： 用户登录操作录制在init ；资产维修登记操作录制在Action ；用户退出操作录制在end 。 Action 录制维修登记，使用资产名称为ZCLZ 开头的数据进行维修登记录制；对资产维修登记操作设置集合点和事务。集合点名称：R_wx ；事务名称：T_wx；维修登记成功后设置检查点，使用资产列表中新登记成功的资产名称作 为检查点，检查是否维修登记成功。 截图要求：一共3 张图，分别为：① init 登录部分脚本截图，包含左侧菜单；② Action 中进行维修登记操作部分截图，包括集合点、事务、检查点代码； ③end 退出部分脚本截图。 制完成脚本回放：脚本录制完成后使用回放功能对脚本的正确性进行校验。脚 本回放具体要求如下： 回放需要对脚本参数进行修改，使用资产名称为ZCHF 开头的数据进行回放；检查点检查资产名称。回放操作完成，查看Loadrunner 回放日志。 截图要求：一共 2 张图，分别为：①资产维修登记脚本截图；②回放概

要（Replay Summary ）截图。 本参数设置要求：脚本回放成功后可继续进行下面的操作。进行性能测试之前 需先对资产名称进行参数化设置。脚本参数设置要求如下： 使用资产名称为ZCYL 开头的数据进行维修登记参数配置；资产名称参 数名称：value ，参数类型选择：File，输入50 条资产名称对应值，每次迭代取唯一值。 检查资产名称，检查点参数名称：title ，参数类型选择：File，取值规则选择同value 值相同行。 截图要求：一共 2 张图，分别为：①资产名称参数化截图；②检查点参 数化截图。 填写表格：填写性能测试总结报告中表格，表格中填写value 和title 参数值。 景设置：按照要求设置虚拟用户个数以及进行场景配置，配置要求如下：设置50 个虚拟用户。 设置集合点策略，选择设置25 个虚拟用户到达集合点时释放。 场景策略：场景名称：C_wx ，虚拟用户总数50 ，用户递增数量25，递增间隔5 秒，场景运行到所有Vuser 运行结束。 截图要求：一共 3 张图，分别为：①集合点设置策略截图；②Design 中的场景设置策略和交互计划图截图；③场景执行完成后Run 界面截图，包括运行结果。 形结果分析：场景执行完成后，需对测试结果进行截图操作，需要

Web功能测试脚本录制

课程名称软件测试技术实验名称集成测试工具调查与分析 姓名王周学号201007040219 专业班级软件1002 实验日期2013.4.18 成绩指导老师杨怀洲 (①验目的②实验原理③主要仪器设备④实验内容与步骤⑤实验数据记录与处理⑥实验结果分析⑦问题建议) 一、实验目的 在自学第7章内容和上网调查相关资料的基础上给出一个有效的测试工具平台，最低要求是能满足测试用例管理、软件缺陷管理和能生成基本的测试报告.从功能，价格，学习难易程度，预算等方面选择集成测试工具，并得出实验评估报告和结果。 二、实验原理 Compuware的QACenter家族集成了一些强大的自动工具，这些工具符合大型机应用的测试要求，使开发组获得一致而可靠的应用性能。 QACcenter这个主要包括应用测试产品的家族，能自动执行整个开发周期中的所有测试。它提供了集中的测试跟踪和管理能力，包括与Compuware的大型机和客户机/服务器测试产品的集成。这些能力可以从单一平台访问，并符合真正的商务需求，它们将作为系统的一部分被移植到客户机/服务器；而有些部分将得到增强以继续在大型机上运行。从而实现来自单一驱动程序平台的真实的企业测试。 Compuware为用户提供全面的专业服务，确保其测试项目的成功。 开源测试工具组合开源测试工具评测开源测试工具开发开源软件测试新闻开源软件测试资源软件质量保证需求管理配置管理软件度量项目估算项目管理质量模型SOA MDA 测试驱动开发解决方案软件测试具Mercury软件测试工具 Rational软件测试工具 Borland软件测试工具Compuware软件测试工具 Parasoft软件测试工具其它软件. 管理整个测试过 测试过程要求大量因素的配合，包括：许多的步骤、测试者、大量测试数据和不同应用的多种版本。QADirector是Compuware的QACenter家族的一部分，它提供的应用系统管理框架，使开发者和QA工作组将所有测试阶段巧妙地组合在一起，从而最有效地使用现有测试资料、测试方法和应用测试. QADirector使用户能够自动地组织测试资料，包括：自动脚本—由QAHiperstation或者QARun产生手工脚本—测试步骤的序列MVS批处理作业脚本—执行作业所必须的JCL其它脚本—在用户工作站上执行程序的测试脚本 1.建立测试过程，以便对多种情况和条件进行测试 2.按正确的次序执行多个测试脚本 3.记录、跟踪、分析和记录测试结果 4.与多个并发用户共享测试信息 5.结合用户定义的或工业标准的试验方法 6.发扬开发人员和质量保证人员之间的协作精神

软件测试人员工作总结

软件测试人员工作总结 总结，是对过去一定时期的工作、学习或思想情况进行回顾、分析，并做出客观评价的书面材料。按内容分，有学习总结、工作总结、思想总结等，按时间分，有年度总结、季度总结、月份总结等。人们常常对已做过的工作进行回顾、分析，并提到理论高度，肯定已取得的成绩，指出应汲取的教训，以便今后做得更好。工作总结频道为你准备了《软件测试人员工作总结》希望你喜欢！ 软件测试人员工作总结（一） 本人自20XX年6月25日起进入梦龙移通公司从事手机软件测试工程师一职，在不知不觉中已经经过了2个月的试用期。在这段时间里，我感悟颇多，虽然这并不是我的第一份工作，但是在此期间，我对于工作一贯谦虚谨慎、认真负责的工作态度，从来没有改变过。 在本部门工作中，我一直严格要求自己，认真及时地完成领导布置的每一项任务，并虚心向同事学习，不断改正工作中的不足；配合各部门负责人落实及完成公司各项工作，在过去的2个月中，通过不断的学习和自我提高，已经适应了本职的工作，但对于一个初入公司的新人，要全面融入企业的方方面面，可能在一些问题的考虑上还不够全面，但我相信，通过公司领导及同事的悉心指导，我一定会在今

后的工作中更好的提高自己的水平、素质，更好的完成本职工作。 在今后的工作中，我要继续努力，克服自己的缺点，弥补不足，向白盒测试、内部代码测试方向了解，加强软件测试、计算机语言方面的知识，不断自我学习，力争成为学习型、创新型、实干型兼备的新世纪人才。 软件测试人员工作总结（二） 一、20XX年工作回顾及总结 回顾20XX年这一年来的工作，我在公司领导及各位同事的支持和帮助下，严格要求自己，按照公司要求，比较好地完成了本职工作。通过近一年的学习和工作，工作模式上有了新的突破，工作方式有了较大的改变。现将这一年的工作情况总结如下： 1、总体来说，20XX年我主要完成了“xx银行系统”、“xx 渠道管理平台”、“xx”、“xx”、的日常测试以及质量控制工作；“xx”已经稳定上线运行6个多月，“xx”即将上线。 2、日常我主要负责项目测试工作、测试文档编辑、参与功能需求设计、协调开发进度、总结经验分享、完成所需知识积累、工具学习及研究、兼容性软件测试。就在银联项目工作来说，主要的工作内容有： a、测试项目案例、测试用例的设计与编写； b、对测试过程中遇到的问题进行沟通，并提供意见；

经验交流材料格式

经验交流材料格式经验交流材料格式要求 一、经验交流材料统一采用A4纸； 二、在左上角标注“全国污水和垃圾处理经验交流会” 三、标题采用华文中宋小二号字居中； 四、地方（省或市）名称和时间（统一定为“二ＯＯ六年十二月二十九日”）采用楷体四号字居中； 五、正文采用仿宋四号字两端对齐； 经验交流材料写作经验 无论是机关企事业单位，还是社团民间组织，每年都要召开若干大大小小的会议，交流情况，交流经验，交流体会，促进工作，提高水平。对于领导者来说，抓两头促中间、抓典型带一般，更是常用的一种领导方法，胸中有思路、手中有典型，往往被看作一个领导者称职和成熟的标志。因此，在各种大大小小形形色色的会议上，经验交流材料总是必不可少的，其在实际工作中应用广且大。 经验交流材料不属于正式文件，也不是规范性公文，没有特别的规定，没有固定的格式，是应用文中限制最少的文种之一，完全应该写得活泼引人。但在实际生活中，真正吸引人、感动人、启发人的经验交流材料可谓凤毛麟角，图解政策、矫揉造作、空洞乏味的经验交流材料常常成为开无效会的“帮凶”。究其原因，很大程度上是写作经验交流材料的人凭“经验”、套格式，缺乏创新意识，往往把活材料写死了。写活经验交流材料，没有现成的模式，没有标准的套路，只有在实践中去体会、去探索。笔者长期从事公文写作，整理和审阅经验交流材料可谓家常便饭，现将自己的几点感受和想法写出来，以期抛砖引玉。

一、从“典型”的角度去寻找“经验”、发现“经验”既然是经验交流材料，就必然要有其先进性、典型性、代表性，可以供人学习，供人借鉴，催人奋进，以此为榜样努力追赶。因而，写作经验交流材料，首先必须抓住经验的可学之处、先进之处，挖掘它的典型意义。通常情况下，不具有代表性的典型不算典型，不具有典型意义的经验也不能算经验，更无需交流了。所以，很多人又把经验交流材料称作典型材料。那么，什么样的“经验”才是“典型”的，才具有交流价值呢?笔者认为可以从以下三个方面去衡量。 1.思路要独特。思路决定出路，思路决定行动，思路决定效果。看一个地区、一个单位或者一个人的工作是否有特色、有创新，经验是否值得总结、值得推广，不能仅仅看“好点子”、“好主意”，更应看其是否有好的工作思路。思路有特色主要体现在四个方面：一是创造性。思路要能创造性地贯彻上级的大政方针和主要精神，是上级意图的延伸和深化，它充分体现大政方针的精神实质，但不是依葫芦画瓢，照本宣科，照搬照转，也不是简单图解和机械执行上级要求。好的思路应该是在全面贯彻中有独到见解，在认真执行中有探索创新。如果思路是上级要求的全面翻版，全盘复制，则毫无“典型”可言，更无“经验”可谈。当然，思路也不能背离上级要求，另搞一套，那样就成“反面典型”了。二是针对性。思路要能切实解决本地本单位急需解决的问题，打开工作局面，改变被动或落后状况，开辟完成任务和实现奋斗目标的有效途径。不着边际、中听不中用的思路不可以作为“典型”。三是普遍性。思路不仅要有独到见解，有创新，有实用性，而且要有普遍意义，可以指导面上工作，是做好同类工作、化解同类难题的好对策、好办法。否则，个别化的思路，再好也没有在面上交流推广的必要。四是前瞻性。思路要有超前意识，能够应对工作中可能出现的各种新情况、新问题、新变化，能够克服各种困难，战胜各种挑战，确保实现预期目标。有远见的思路才是真正的出路，才是含“经”量高的经验。

测试脚本

1.线性脚本：是录制手工执行的测试实力得到的脚本。这种脚本包括所有的击键、功能键、箭头、控制测试软件的控制键及输入数据的数字键。 2.结构化脚本：类似于结构化程序设计，结构化脚本中含有控制脚本设计的指令。这些指令或为控制结构或为调用结构。 3.共享脚本：脚本可能被多个测试事例使用。 4.数据驱动脚本技术：将测试输入存储在独立的文件中，而不是存储在脚本中。 5.关键字驱动脚本：较复杂的数据驱动技术的逻辑扩展。 测试专业技能涉及的范围很广：既包括黑盒测试、白盒测试、测试用例设计等基础测试技术，也包括单元测试、功能测试、集成测试、系统测试、性能测试等测试方法，还包括基础的测试流程管理、缺陷管理、自动化测试技术等知识。 １、一个测试用例要写到什么程度才比较好? ２、刚开始做测试的时候，你是怎么学习写测试用例的？ ３、你对黑盒测试用例的编写的体会是什么？有什么好的版本或者标准吗？ ??下面先来分析第一个问题吧：一个测试用例要写到什么程度才比较好？ ?在我测试工作中，碰上的测试类型我自己划分成这么４种：项目的测试，产品的测试，产品个性化的测试，第三方验收测试。项目的测试指的是我所测试的软件是一个项目，是某一个具体用户使用的。产品的测试指的是我所测试的软件是一个通用产品，是供很多用户使用的。产品个性化测试指的是我所测试的软件是某一用户在使用产品时，提出了特殊的功能，针对这些新功能，对产品针对用户进行了个别修改。第三方验收测试大家都应该很熟悉了，这里就不需要做解释了。 ?对项目、产品的测试，测试的时候通常要考虑这个项目的周期和测试资源。我所在的公司，通常项目开发时间都很短４到５个月，然而测试通常都是在开发即将结束的时候才真正介入。测试就是１个人负责。因此时间和人力资源对测试来说是完成测试工作的一个风险。为此在这种情况下，我都是先熟悉系统的业务，把握重点业务和功能后，参考需求，把测试需求、测试计划和测试大纲给制定好。由于时间关系，测试用例都是先写重点的业务，也就是集成测试的测试用例。另外测试用例是根据测试大纲来的。通常都是先挑最重要的测试项和风险大的业务功能编写测试用例。由于测试用例是本人执行，所以测试用例可以写的简单些，但是一定要开发人员能够看明白。可惜我所在的公司，都没有人来看我的测试用例。测试用例对我来说是用来提示我不要忘记了要测试哪些项。一些很有价值的ｂｕｇ通常不是在写测试用例的时候发现的，而是在测试软件的过程中，我在家睡觉前的思考和回家的路上思考出来的。这就是手动测试的魅力，有些软件的缺陷是在你使用软件的一瞬间和思考的一刹那突然发现的。所以要我回答测试用例要写到什么程度才比较好，我觉的只要你所写的测试用例在你的公司能够顺利的执行，不影响你的测试执行工作就可以了。因为测试用例写的太详细，你要花费时间和人力成本，这样出来的测试用例是最好的也是最贵的，一旦需求变更，也需要修改，这时你会发现这种详细的测试用例是最不挣钱的。测试用例写的太粗，别人看不懂，不能执行，那你要花费你的时间去解释，这就加大了测试的工作量。这也不是好的方法。 ?第二个问题，刚开始做测试的时候，你是怎么学习写测试用例的？ ??现在想想自己刚开始写测试用例的时候，真是好笑。就像小孩子学习写字一样。先是在网上狂搜索了一把测试用例的模板，综合了几个，就形成了。我之所以不用公司原有的测试用例模板，是因为太不适用了。还好，公司没有严格要求必须要那个模板，只要适用就行。模板找好了，可是写就费劲了。对于刚做测试的新人，看似简单的一个填表工作，要写好真是不简单。一开始写的比较不自然，有些生搬硬套，而且还很慢。没有办法，那时候没有人指导我，全靠自己自学和领悟，所以那段日子很苦阿！多写几次后，就知道和领悟了，测试用

一个成功软件测试项目的经验

本文以一个工作流测试项目为例，总结了在测试过程中积累的经验，探讨了目前国内软件开发企业在软件测试过程中遇到的问题以及解决的方法。测试项目背景和实施情况工作流在某公司软件产品线中占有重要地位。 Workflow项目是5系列中的一个小版本，主要增加了任务代办、任务代理、以及任务交接等功能，同时还修复了一些易用性和功能性的Bug。下面，我们大概介绍一下这个项目的实施情况： ●项目规模与测试人员配置： ○项目代码行数：5万行 ○开发人员配置：开发人员5名、实习生1名 ○测试人员配置：测试设计人员1名、测试执行人员2名、实习生1名 ●项目测试时的系统部署情况: ●测试预期与测试执行情况整个测试项目是比较成功的，项目的时间执行情况和预期的测试指标度量都比较接近。发现Bug总数和缺陷密度都达到了要求的标准。当然，测试周期的实际值比计划值晚了两周，原?因是在系统测试后期，为了满足PSO部门提出的定时器需求造成了一定的延期。回顾整个项目的测试过程，我有几点小小的感悟，愿在此和大家一起分享。 测试如何尽早介入 基于以前的测试经验，我们也越来越认识到测试人员应该尽早介入项目的重要性。简单地沿用测试V模型往往出现很多问题，特别是在项目进度拖延的情况下更是如此。如果测试人员一味固执地被要求严格按照V模型定义的标准来开展测试工作的话，则结果往往是在项目初期测试人员工作量极度不饱和（很多测试人员无所事事），而到了项目后期，一旦项目经理决定压缩测试时间，测试人员就不得不加班加点地工作。但是，不少朋友实践“测试人员尽早介入”的效果并不理想，例如： ●测试人员参加项目前期的各种会议，会被当作“专职的”会议记录员。 ●测试人员参加代码评审，又不甚了解程序开发语言，浪费了时间其丢失了自信。那么，在这个XXX5.2 Workflow项目中我们是怎么做的呢？实际上，在项目开发初期，测试人员可以开展很多有价值的工作，例如： ●评审需求文档的正确性和可测试性；根据需求文档整理和分析测试需求，清晰明确的测试需求是测试设计的基础。 项目管理者联盟，项目管理问题。 ●在开发设计过程中，根据需求文档和设计文档进行测试设计，测试设计方案是测试用例的保证。 ●和项目团队中的集成组和开发组协?商软件版本的编译方式和编译进度以及测试人员提取版本的方式和进度。

典型经验交流材料格式(精选多篇)

典型经验交流材料格式(精选多篇) 班主任典型经验交流材料 ——孙宪云 人说：班主任是世界上最小的主任，也有人说：班主任是学校里最苦的岗位。我从95年9月开始工作以来，就开始担任班主任。一开始我感觉非常新鲜、有趣，但随着时间的推移，我更感到班主任的工作是一件非常繁琐、但同时是很一件很重要的工作。在班主任工作中，我感触颇深，有几分劳累，几许收获，我咀嚼过失败的苦涩，也品尝过成功的甘甜。经历过一次次心灵的历程,我认为做班主任老师是不乏味的、没有遗憾的、是充实的、完美的老师。做学生的心理辅导工作，和家长沟通，开家长会等等，

真的使自己的综合能力得到了提高。我深知自己面临的工作的繁杂，但我更清楚肩负的责任。就因为心中有对他们如对自己孩子一样的爱，再累，我总能看到希望，所以工作中我感觉到了从未有过的愉快。也是在对孩子们的付出中，我第一次对工作着并快乐着有了深深的体会。我总结自己做班主任的经验感悟颇深，觉得至少有以下几个方面的工作是需要做好的： 一、班主任工作，从爱做起 我班有个学生叫吕睿。我刚接这个班时，他上课无精打采，要么搞小动作，要么影响别人学习，提不起一点学习的兴趣；下课追 逐打闹，喜欢动手动脚；作业不做，即使做了，也做不完整，书写相当潦草??每天不是科任老师就是学生向我告状。于是，我找他谈话，希望他能遵守学校的各项规章制度，以学习为重，按时完成作业，知错就改，争取进步，争取做一个他人喜欢、父母喜欢、老师喜欢的

好孩子。他开始是一副爱理不理的样子，后来口头上答应了。可他又一如既往，毫无长进，真是“承认错误，坚决不改”。此时我的心都快冷了，算了吧，或许他是根“不可雕的朽木”。但又觉得身为班主任，不能因一点困难就退缩，不能因一个后进生无法转化而影响整个班集体，必须面对现实！我内心一横:不转化你，誓不罢休。他无进步，或许是他并没有真正认识自己的错误，没有真正要做个他人喜欢的人的念头。 为了有针对性地做工作，我决定先让他认识自己的错误，树立做个受人喜欢的人的思想。于是我再次找他谈话，谈话中，我了解到他心里十分怨恨二年级的班主任老师。我心里一喜，让他认识错误的机会来了。我轻声问他：“你为什么会恨那个老师？”他不好意思地回答：“因为她常常批评我。”我顺着问：“老师为什么会常在课堂上批评你，你知道吗？”他说：“因为我常违反纪律，没有按时完成作业，书写也不工整??”“你已经

性能测试计划模板(实例)

XXXX系统 性能测试方案 软件产品名称：XXXX 软件开发部门：XXXX 软件测试部门：XXXX 编写：XXX 日期：2008 年11 月8 日审核：XXX 日期：2008 年11 月10 日批准：日期：年月日

1．引言 1.1测试方案概述 方案名称：xxxx系统性能测试方案 测试部门：xxxxxxxx科技发展有限公司 1.2目的 本测试方案将对国美电器供应链系统的测试方法、测试工具、测试范围、测试的软件硬件环境、测试进度、测试人员的分工和职责以及测试流程进行详细的定义和整体的描述。 1.3系统概述 产品名称： xx供应链系统JL SCM 开发部门： xxxx有限公司 在企业的信息化建设中，北京国美电器有限公司将在全国范围内实施“金力供应链系统JL SCM”，该系统中采用了 Sybase 最新版本的企业智能型关系数据库产品Adaptive Server Enterprise 12.5 (ASE12.5)及复制服务器产品Sybase Replication Server，由武汉金力软件有限公司开发并协助实施。国美电器实施的“金力供应链系统JL SCM”，从现代企业理念、物流体系和全方位服务的角度，完全解决了企业的决策、计划、管理、核算、经营、物流、服务、人事及电子商务等问题。 2.术语和定义 性能测试：在一定约束条件下（指定的软件、硬件和网络环境等）确定系统

所能承受的最大负载压力的测试过程。 场景：一种文件，用于根据性能要求定义在每一个测试会话运行期间发生的事件。 虚拟用户：在场景中， LoadRunner 用虚拟用户代替实际用户。模拟实际用户的操作来使用应用程序。一个场景可以包含几十、几百甚至几千个虚拟用户。 虚拟用户脚本：用于描述虚拟用户在场景中执行的操作。 事务：表示要度量的最终用户业务流程。 3.测试流程 负载测试通常由五个阶段组成：计划、脚本创建、场景定义、场景执行和结果分析。 计划负载测试：定义性能测试要求，例如并发用户的数量、典型业务流程和所需响应时间。 创建虚拟用户脚本：将最终用户活动捕获到自动脚本中。 定义场景：使用 LoadRunner Controller 设置负载测试环境。 运行场景：通过 LoadRunner Controller 驱动、管理和监控负载测试。 分析结果：使用 LoadRunner Analysis 创建图和报告并评估性能。 4.测试目标与策略 4.1测试目标 1）确定系统能承载的最大容量； 2）定位系统性能瓶颈； 3）确定系统典型事务响应时间； 4）出具可信的独立的第三方的性能测试报告。

自动化测试流程图解析

功能自动化测试流程解析 本流程是描述软件功能自动化测试过程中的步骤、内容与方法，明确各阶段的职责、活动与产出物。 1流程图 2流程说明 2.1 测试计划（可选） 与以前的测试计划过程一致，只是在原来的测试计划中，添加对项目实施自动化测试所需的资源、测试范围、测试进度的描述。该过程产出物为《测试计划》。 2.2 自动化测试用例设计 根据《测试计划》、《软件需求规格说明书》、《系统测试用例》设计出针对自动化测试的测试用例。测试用例的粒度精确到单个功能点或流程，对于各个功能点的业务规则，通过对脚本添加相应的检查点来进行测试。该过程的产出物是《自动化测试用例》。

2.3 自动化脚本设计（可选） 根据《软件需求规格说明书》、《自动化测试用例》、《系统原型》、《系统设计说明书》编写《自动化脚本设计说明书》，其主要内容包括：分析当前项目，设计出适合的脚本基本架构，针对特殊自动化测试用例设计可行的脚本编写方法，设计特殊检查点的实现方式，并对潜在的技术难点提出解决方案。该过程的产出物是《自动化脚本设计说明书》。 2.4 自动化脚本编写 根据《软件需求规格说明书》、《自动化测试用例》、《系统原型》、《自动化脚本设计说明书》，录制、调试、编写各个功能点的自动化测试脚本，并添加检查点，进行参数化。该过程还需要编写数据文件处理脚本、日志文件处理脚本、数据库处理脚本、公共检查点处理脚本等等。该过程的产出物是各个功能点的自动化测试脚本和其他公共处理脚本。 2.5 自动化测试数据设计 根据《软件需求规格说明书》、《自动化测试用例》设计出对各个功能点和相关业务规则进行测试的输入数据和预期输出，填写入对应的数据文件中。该过程的产出物是各个功能点的数据文件。 2.6 自动化测试执行 搭建好测试环境。根据《自动化测试用例》，执行自动化脚本，对系统进行自动化测试，并自动记录测试结果到日志文件中。 2.7 自动化测试结果分析 对测试结果文件中报告错误的记录进行分析，如果确实是由于被测系统的缺陷导致，则提交缺陷报告。对自动化测试的结果进行总结，分析系统存在的问题，提交《测试报告》。 2.8 自动化测试脚本维护（可选） 如果系统发生变更时，对自动化测试脚本和相关文档包括《自动化测试用例》、《自动化脚本设计说明书》进行维护，以适应变更后的系统。

分享ERP测试经验

正在进行当中的PConline首次ERP压力测试，测试过程的最大感悟是随时随地等待着“不可预知”的错误发生，也许发现这些问题也算是测试本身的使命之一。bug经历得多了也勉强有些经验了，再借鉴下ERP厂商专职的ERP测试人员，总算有了一些可以和各位读者可以分享的经验了。 基本ERP系统拓扑 一、测试的目的和原则 测试概念的范畴 广义上讲，测试是指软件产品生存周期内所有的检查、评审和确认活动。如：设计评审、系统测试。 狭义上讲，测试是对软件产品质量的检验和评价。它一方面检查软件产品质量中存在的质量问题，同时对产品质量进行客观的评价。 测试的目的

简单地说，就是替用户受过，测试的最终目的是确保最终交给用户的产品的功能符合用户的需求，把尽可能多的问题在产品交给用户之前发现并改正。 具体地讲，测试一般要达到下列目标： （1）确保产品完成了它所承诺或公布的功能，并且所有用户可以访问到的功能都有明确的书面说明------在某种意义上与ISO9001是同一种思想。 产品缺少明确的书面文档，是厂商一种短期行为的表现，也是一种不负责任的表现。所谓短期行为，是指缺少明确的书面文档既不利于产品最后的顺利交付，容易与用户发生矛盾，影响厂商的声誉和将来与用户的合作关系；同时也不利于产品的后期维护，也使厂商支出超额的用户培训和技术支持费用。从长期利益看，这是很不划算的。 当然，书面文档的编写和维护工作对于使用快速原型法(RAD)开发的项目是最为重要的、最为困难，也是最容易被忽略的。 最后，书面文档的不健全甚至不正确，也是测试工作中遇到的最大和最头痛的问题，它的直接后果是测试效率低下、测试目标不明确、测试范围不充分，从而导致最终测试的作用不能充分发挥、测试效果不理想。 （2）确保产品满足性能和效率的要求。使用起来系统运行效率低(性能低)、或用户界面不友好、用户操作不方便(效率低)的产品不能说是一个有竞争力的产品。 用户最关心的不是你的技术有多先进、功能有多强大，而是他能从这些技术、这些功能中得到多少好处。也就是说，用户关心的是他能从中取出多少，而不是你已经放进去多少。 （3）确保产品是健壮的和适应用户环境的。健壮性即稳定性，是产品质量的基本要求，尤其对于一个用于事务关键或时间关键的工作环境中。 另外就是不能假设用户的环境(某些项目可能除外)。 测试的原则---Good Enough 对于相对复杂的产品或系统来说，zero-bug是一种理想，good-enough是我们的原则。

(新安全生产)安全经验分享材料

（新安全生产）安全经验分享材料

擅自上机操作伤害自己 一、事故经过 2000年11月28日，河南省某化肥厂机修车间，1号Z35摇臂钻床因全厂设备检修，加工备件较多，工作量大，人员又少，工段长派女青工宋某到钻床协助主操作工干活，往长3m直径75x 3．5不锈钢管上钻直径50的圆孔。28日10时许，宋某在主操师傅上厕所的情况下，独自开床，并由手动进刀改用自动进刀，钢管是半圆弧形，切削角矩力大，产生反向上冲力，由于工具夹(虎钳)紧固钢管不牢，当孔钻到2／3时，钢管迅速向上移动而脱离虎钳，造成钻头和钢管一起作360度高速转动，钢管先将现场一长靠背椅打翻，再打击宋某臀部并使其跌倒，宋某头部被撞伤破裂出血，缝合5针，骨盆严重损伤。 二、事故原因分析 事故发生后，厂领导高度重视，对事故责任者送医院进行治疗，厂安委会组织安环处、劳资处、机修车间，成立事故调查小组，对现场工作环境进行查看，召开事故分析会，查清事故责任、原因。 (1)造成事故的主要原因是宋某违反了原化学工业部安全生产《禁令》第八项“不是自己分管的设备、工具不擅自动用”的规定。因为直接从事生产劳动的职工，都要使用设备和工具作为劳动的手段，设备、工具在使用过程中本身和环境条件都可能发生变化，不分管或不在自己分管时间内，可能对设备性能变化不清楚，擅自动用极易导致事故。 (2)宋某参加工作时间较短，缺乏钻床工作经验，对钻床安全操作规程不熟：①“应用手动进刀，不该改用自动进刀”；②工件与钢管紧固螺栓方位不对，工件未将钢管夹紧；③宋某工作中安全观念淡薄，自我防范意识不强。 三、事故防范措施 (1)本着对事故“四不放过”的原则，厂安委会和机修车间及时组织职工，进行事故案例现场教育。 (2)钻床操作人员必须经过专业技能安全培训，掌握一定操作技能，并通过安全考试，持有特种工《安全作业证》才能上机操作。 (3)工件与工具夹应用扳手或专用工具紧固牢，严格按照钻床安全操作规程办事，切莫只对表面操作程序简单了解就上机操作。 (4)工段长在派人更换岗位工种时，首先交代本岗安全操作注意事项，特别是参加工作较短的青工。

性能测试流程规范汇编

目录 1前言 (2) 1.1 文档目的 (2) 1.2 适用对象 (2) 2性能测试目的 (2) 3性能测试所处的位置及相关人员 (3) 3.1 性能测试所处的位置及其基本流程 (3) 3.2 性能测试工作内容 (4) 3.3 性能测试涉及的人员角色 (5) 4性能测试实施规范 (5) 4.1 确定性能测试需求 (5) 4.1.1 分析应用系统，剥离出需测试的性能点 (5) 4.1.2 分析需求点制定单元测试用例 (6) 4.1.3 性能测试需求评审 (6) 4.1.4 性能测试需求归档 (6) 4.2 性能测试具体实施规范 (6) 4.2.1 性能测试起始时间 (6) 4.2.2 制定和编写性能测试计划、方案以及测试用例 (7) 4.2.3 测试环境搭建 (7) 4.2.4 验证测试环境 (8) 4.2.5 编写测试用例脚本 (8) 4.2.6 调试测试用例脚本 (8) 4.2.7 预测试 (9) 4.2.8 正式测试 (9) 4.2.9 测试数据分析 (9) 4.2.10 调整系统环境和修改程序 (10) 4.2.11 回归测试 (10) 4.2.12 测试评估报告 (10) 4.2.13 测试分析报告 (10) 5测试脚本和测试用例管理 (11) 6性能测试归档管理 (11) 7性能测试工作总结 (11) 8附录：................................................................................................ 错误!未定义书签。

1前言 1.1 文档目的 本文档的目的在于明确性能测试流程规范，以便于相关人员的使用，保证性能测试脚本的可用性和可维护性，提高测试工作的自动化程度，增加测试的可靠性、重用性和客观性。 1.2 适用对象 本文档适用于部门内测试组成员、项目相关人员、QA及高级经理阅读。 2性能测试目的 性能测试到底能做些什么，能解决哪些问题呢？系统开发人员，维护人员及测试人员在工作中都可能遇到如下的问题 1.硬件选型，我们的系统快上线了，我们应该购置什么样硬件配置的电脑作为 服务器呢？ 2.我们的系统刚上线，正处在试运行阶段，用户要求提供符合当初提出性能要 求的报告才能验收通过，我们该如何做？ 3.我们的系统已经运行了一段时间，为了保证系统在运行过程中一直能够提供 给用户良好的体验（良好的性能），我们该怎么办？ 4.明年这个系统的用户数将会大幅度增加，到时我们的系统是否还能支持这么 多的用户访问，是否通过调整软件可以实现，是增加硬件还是软件，哪种方式最有效？ 5.我们的系统存在问题，达不到预期的性能要求，这是什么原因引起的，我们 应该进行怎样的调整？ 6.在测试或者系统试点试运行阶段我们的系统一直表现得很好，但产品正式上 线后，在用户实际环境下，总是会出现这样那样莫名其妙的问题，例如系统运行一段时间后变慢，某些应用自动退出，出现应用挂死现象，导致用户对我们的产品不满意，这些问题是否能避免，提早发现？ 7.系统即将上线，应该如何部署效果会更好呢？ 并发性能测试的目的注要体现在三个方面：以真实的业务为依据，选择有代表性的、关键的业务操作设计测试案例，以评价系统的当前性能；当扩展应用程序的功能或者新的应用程序将要被部署时，负载测试会帮助确定系统是否还能够处理期望的用户负载，以预测系统的未来性能；通过模拟成百上千个用户，重复执行和运行测试，可以确认性能瓶颈并优化和调整应用，目的在于寻找到瓶颈问题。

软件功能测试

软件功能测试 功能测试 折叠定义 Functional testing(功能测试)，也称为behavioral testing(行为测试)，根据产品特性、操作描述和用户方案，测试一个产品的特性和可操作行为以确定它们满足设计需求。本地化软件的功能测试，用于验证应用程序或网站对目标用户能正确工作。使用适当的平台、浏览器和测试脚本，以保证目标用户的体验将足够好，就像应用程序是专门为该市场开发的一样。功能测试是为了确保程序以期望的方式运行而按功能要求对软件进行的测试，通过对一个系统的所有的特性和功能都进行测试确保符合需求和规范。 功能测试也叫黑盒测试或数据驱动测试，只需考虑需要测试的各个功能，不需要考虑整个软件的内部结构及代码.一般从软件产品的界面、架构出发，按照需求编写出来的测试用例，输入数据在预期结果和实际结果之间进行评测，进而提出更加使产品达到用户使用的要求。 折叠应用 应用电子技术方面的测试: 印刷电路板，又称印制电路板，印刷线路板，常使用英文缩写PCB(Printed circuit board)，是重要的电子部件，是电子元件的支撑

体，是电子元器件线路连接的提供者。由于它是采用电子印刷技术制作的，故被称为"印刷"电路板。 在印制电路板出现之前，电子元件之间的互连都是依靠电线直接连接而组成完整的线路。电路面包板只是作为有效的实验工具而存在，而印刷电路板在电子工业中已经成了占据了绝对统治的地位。 20世纪初，人们为了简化电子机器的制作，减少电子零件间的配线，降低制作成本等优点，于是开始钻研以印刷的方式取代配线的方法。三十年间，不断有工程师提出在绝缘的基板上加以金属导体作配线。而最成功的是1925年，美国的Charles Ducas 在绝缘的基板上印刷出线路图案，再以电镀的方式，成功建立导体作配线。[1] 直至1936年，奥地利人保罗·爱斯勒(Paul Eisler)在英国发表了箔膜技术，他在一个收音机装置内采用了印刷电路板;而在日本，宫本喜之助以喷附配线法"メタリコン法吹着配线方法(特许119384号)"成功申请专利。而两者中Paul Eisler 的方法与现今的印刷电路板最为相似，这类做法称为减去法，是把不需要的金属除去;而Charles Ducas、宫本喜之助的做法是只加上所需的配线，称为加成法。虽然如此，但因为当时的电子零件发热量大，两者的基板也难以配合使用[1]，以致未有正式的实用作，不过也使印刷电路技术更进一步。

软件测试人员6年工作经验总结

1、分享第一条经验：“学历代表过去、能力代表现在、学习力代表未来。”其实这是一个来自国外教育领域的一个研究结果。相信工作过几年、十几年的朋友对这个道理有些体会吧。但我相信这一点也很重要：“重要的道理明白太晚将抱憾终生！”所以放在每一条，让刚刚毕业的朋友们早点看到哈！ 2、一定要确定自己的发展方向，并为此目的制定可行的计划。不要说什么，“我刚毕业，还不知道将来可能做什么？”，“跟着感觉走，先做做看”。因为，这样的观点会通过你的潜意识去暗示你的行为无所事事、碌碌无为。一直做技术，将来成为专家级人物？向管理方向走，成为职业经理人？先熟悉行业和领域，将来自立门户？还是先在行业里面混混，过几年转行做点别的？这很重要，它将决定你近几年、十年内“做什么事情才是在做正确的事情！”。 3、软件开发团队中，技术不是万能的，但没有技术是万万不能的！在技术型团队中，技术与人品同等重要，当然长相也比较重要哈，尤其在MM比较多的团队中。在软件项目团队中，技术水平是受人重视和尊重的重要砝码。无论你是做管理、系统分析、设计、编码，还是产品管理、测试、文档、实施、维护，多少你都要有技术基础。算我孤陋寡闻，我还真没有亲眼看到过一个外行带领一个软件开发团队成功地完成过软件开发项目，哪怕就一个，也没有看到。倒是曾经看到过一个“高学历的牛人”(非技术型)带一堆人做完过一个项目，项目交付的第二天，项目组成员扔下一句“再也受不了啦！”四分五裂、各奔东西。那个项目的“成功度”大家可想而知了。 4、详细制定自己软件开发专业知识学习计划，并注意及时修正和调整(软件开发技术变化实在太快)。请牢记：“如果一个软件开发人员在1、2年内都没有更新过自己的知识，那么，其实他已经不再属于这个行业了。”不要告诉自己没有时间。来自时间管理领域的著名的“三八原则”告诫我们：另外的那8小时如何使用将决定你的人生成败！本人自毕业以来，平均每天实际学习时间超过2小时。 5、书籍是人类进步的阶梯，对软件开发人员尤其如此。书籍是学习知识的最有效途径，不要过多地指望在工作中能遇到“世外高人”，并不厌其烦地教你。对于花钱买书，我个人经验是：千万别买国内那帮人出的书！我买的那些家伙出的书，100%全部后悔了，无一本例外。更气愤的是，这些书在二手市场的地摊上都很难卖掉。“拥有书籍并不表示拥有知识；拥有知识并不表示拥有技能；拥有技能并不表示拥有文化；拥有文化并不表示拥有智慧。”只有将书本变成的自己智慧，才算是真正拥有了它。 6、不要仅局限于对某项技术的表面使用上，哪怕你只是偶尔用一、二次。“对任何事物不究就里”是任何行业的工程师所不应该具备的素质。开发Windows应用程序，看看Windows程序的设计、加载、执行原理，分析一下PE文件格式，试试用SDK开发从头开发一个Windows应用程序；用VC＋＋、Delphi、Java、.Net开发应用程序，花时间去研究一下MFC、VCL、J2EE、.Net它们框架设计或者源码；除了会用J2EE、JBoss、Spring、Hibernate等等优秀的开源产品或者框架，抽空看看大师们是如何抽象、分析、设计和实现那些类似问题的通用解决方案的。试着这样做做，你以后的工作将会少遇到一些让你不明就里、一头雾水的问题，因为，很多东西你“知其然且知其所以然”！ 7、在一种语言上编程，但别为其束缚了思想。“代码大全”中说：“深入一门语言编程，不要浮于表面”。深入一门语言开发还远远不足，任何编程语言的存在都有其自身的理由，所以也没有哪门语言是“包治百病”的“灵丹妙药”。编程语言对开发人员解决具体问题的思路和方式的影响与束缚的例子俯拾皆是。我的经验是：用面对对象工具开发某些关键模块时，为什么不可以借鉴C、C51、汇编的模块化封装方式？用传统的桌面开发工具(目前主要有VC++、Delphi)进行系统体统结构设计时，为什么不可以参考来自

经验交流材料

班主任教育案例3 付博来自依兰第一中学，在班级中，他的形象很典型：个子很矮，中考成绩较差，但他头脑聪明，思维活跃，为人随和，个性活泼开朗，与同学关系融洽，能虚心听取师长教诲，积极参加各项集体活动。他是我班班长，生活中的他，无忧无虑。遇到老师大老远就大声喊老师好；喜欢表现，常常当着老师的面做好事的；但经常犯些小错误，虚心接受批评，坚决不改的，是他；学习不认真，利用各种时间玩手机，开小差，在校表现不太好时候，被家长知道，得知家长伤心难过，自己内疚得哭出来的，具备了青春期男孩的许多心理特征，让你觉得可气又可爱，孩子气太重，又让你觉得他老是长不大。 付博身上存在的问题，其实是班级多数男生的共同问题。由于许多方面的原因，这一届的学生，男女比率明显失调，学生素质本就参差不齐，在班级的管理中，占总数三分之二的男生，却比女生需要多花至少两倍以上的精力。班级较活跃的男生中，就有五六个自学习风气较差，进入高中以后，还保留了原来的许多坏习惯，他们人数不多，但每个人的活动能力、影响能力都是很强的，破坏性极大。从入学一直到高一年即将结束，尽管花了大量的精力在教育这些男生上面，也明显改善了他们的精神面貌和学习状态，但，仍觉得很烦，任重而道远。 结合班级学生特色及个人特点，在对他的教育中，我注意从实际情况出发，对症下药，取得了一些成效。

首先，不厌其烦地利用各种时机进行思想道德教育，在班级中树立正确的舆论导向，让学生们知道高中与初中学习的不同，明确什么事该做，什么事不该做，用群体的力量来约束、督促、带动后进生。平时工作中注意加强对问题突出学生的跟踪和个别谈话教育，督促其认识错误，改正不足。李博顽皮贪玩，我在肯定其优点的基础上，帮助他一一找出毛病，要求他应遵守纪律，改正错误，端正学习态度。在严格要求的同时，又热情地关心他，在各种集体活动及日常表现中注意、发现、捕捉他的长处或闪光点，及时予以鼓励或表扬，激励他自尊心和自信心，上课时注意他是否认真听讲，课后和他多接触、多交流，建立师生感情。这样他愿意接近老师，也能听老师的话，在各方面都有所改善。 其次，家长与学校配合，督促自我控制，改进不良习惯。后进生之所以后进，常表现为行为习惯不良，或者学习习惯、学习成绩较差，部分后进生两者兼而有之。观察中发现，一部分后进生之所以无法养成好习惯，是因为他们比较缺少自我控制、自我约束的能力，这种时候，教师和家长就应该做他们生活学习的指导者、价值的引导者、行为习惯养成的督促者。一次周末，我马上就去他家进行家访，主动和家长取得联系，向家长明确了自己的看法和学校不提倡学生带手机进校园的要求，与他们商量解决问题的办法。家长当场表明会配合老师的工作，尽力督促孩子，要求他在学习时间禁止使用手机。 总之，在班主任工作特别是后进生转化的工作中，常常会有挫折感，常常感慨个人的力量是有限的，也常常为学生行为的反复而头痛。