小学教师测试方案

第一篇：小学教师测试方案

小学语文教师普通话和“两笔字”测试

实施方案

为了进一步提高小学语文教师普通话水平,规范教师的粉笔字、钢笔字书写，促进教师的专业发展，经局委会研究，决定组织全县小学语文教师进行普通话和“两笔字”测试活动。具体安排如下：

一、组织领导

本次活动在教育局的统一领导下，由教研室具体组织实施。

二、测试对象

小学任语文学科（1968年元月1日以后出生）的全体教师。

三、测试项目

普通话、粉笔字、钢笔字。

四、测试形式

全县教师共分12组，每组24人（最后一组13人），早上测试6组，下午测试6组。

（一）普通话

1、采取现场录音的方式测试。教师面对试题进行现场录音，6分钟内完成。

2、每组24人分成6个小组，每组4人，同时进行

（二）粉笔字和钢笔字

1、采取现场书写的方式测试。粉笔字在小黑板上书写，10分钟内完成；钢笔字以书面形式测试，10分钟内完成。

2、每组24人，粉笔字、钢笔字同时进行。

五、测试地点

普通话测试在教研室二楼05、06、07、08、09、10等6个房间。

粉笔字和钢笔字在进修校教室，每组24人同时进行。

六、测试时间

2013年12月25日，早上1-7组，下午8-12组。

七、各校测试人员名单及编号（见附件）

八、要求：

1、各校要统一组织教师参加测试，有专人负责管理，保障安全。

2、测试教师要按时报到。1-7组教师25日早上8时报到，8-12组教师下午1：30报到，任何人不得缺席。

3、测试教师要自带钢笔。

4、粉笔字、钢笔字卷面只写本人编号，普通话只报本人编号。

小学教研室 2013.12.23

第二篇：2011年七佛小学教师普通话测试方案

2011年青川县七佛乡中心小学校

教师普通话测试方案

一、指导思想和目的：

为了迎接市规范汉字示范校验收，根据我校教育工作实际及教师队伍状况，经学校研究决定特举办2012教师普通话比赛活动。力争通过此次活动，提升教师的群体素质，加快教师队伍的专业化的发展，提高教育、教学水平，推进素质教育，塑造教师新形象。

二、组织机构： 组 长： 副组长： 成 员：

三、参赛对象： 学校所有在职教师

四、测试时间： 2011年9月中旬

五、测试地点： 教师会议室

六、测试内容：

抽签选择内容，所选文章每篇的朗读时间控制在3分钟之内。

七、测试方式：

参加测试的教师先抽签决定朗读次序。参赛时，先读自选内容，再读抽取内容，1号选手随机抽取一篇文章，准备3分钟后上台朗读。1号开始朗读时，2号随机抽取一篇文章做准备，待1号结束朗读后，2号接着朗读，3号随机抽取一篇文章，以下依此类推。

八、评分标准：

1.语言（60分）

（1）语音：发音准确，声调、句调准确，没有语音缺陷，没有方音，声音洪亮。（20分）

（2）语速：语速自然流畅，停顿、断句得当。（20分）（3）节奏：节奏优美，富有感情。（20分）2.感情表达（30分）

（1）要能准确把握作品情感基调，感情处理要得当。（2）要富有感召力、感染力，能引人入胜。（3）态势语恰当。3.台风（10）

台风自然大方，精神面貌好，上下台符合规范。

第三篇：验收测试方案

验收测试方案

1.1 验收目的

验收是项目从实施到售后维护的一个过渡阶段，验收通过之后实施的项目正式实施完成，项目进入系统售后维护阶段。验收是项目建设过程的一个里程碑，说明项目建设完成了实施这一过程，进入了下一个阶段。确保项完成后达到有关要求和标准，正常运行平稳，必须进行项目验收。

1.2 验收对象

咭星坞平台，andorid版本、ios版本、OTT版本 1.3 验收前提条件

1）从测试结果用例覆盖和系统稳定性方面来看，整个系统的运行已经进入正轨，需求 响应也已基本完成，并稳定运行后组织验收； 2）要相关使用科室主要负责人签字； 3）照合同要求全部建成，并满足使用要求； 4）文档和验收资料完备，符合合同的内容； 5）数据处理符合信息安全的要求；

6）系统、数据库、中间件、应用软件和开发工具符合知识产权相关政策法规的要求； 1.4 验收方法

项目验收是它是对项目建设高度负责的体现，也是项目建设成功的重要保证。采用的验收方法是：运行项目系统软件，检验其应用软件的实际能力是否与规定的一致；运行应用软件，实际操作，处理业务，检查是否与合同规定的一致，达到了预期的目的。1.5 验收步骤 1）编写验收计划

2）根据咭星坞平台的需求分析的基础上编写验收计划，提交负责人审定。

3）成立项目验收小组实施测试验收工作时，成立项目验收小组，具体负责验收事宜。4）项目验收的实施严格按照验收方案对项目应用软件、系统文档资料等进行全面的测试和验收。

5）提交验收报告项目验收完毕，对项目系统设计、软件运行情况等做出全面的评价，得出结论性意见，对不合格的项目不予验收，对遗留问题提出具体的解决意见。

6）召开项目验收评审会召开项目验收评审会，全面细致地审核项目验收小组所提交的验收报告，给出最终的验收意见，形成验收评审报告并存档 1.6 验收流程

（一）初验

经过系统内部试运行，我公司对内部试运行期间发现的问题改正后，提出系统初验书面申请。验收标准将按照“需求说明书”和双方认可的有关系统设计文档所提的要求进行，初验通过后，咭星坞项目正式进入试运行，我公司应解决试运行期间所反映出的问题，若系统达不到合同规定要求，试运行期将继续顺延，直到系统完善，但试运行期最长不得超过三个月

（二）终验 终验流程

1）申请：初验合格后，承建方根据合同、任务书，检查、总结项目组织实施和完成情况后向建设方提出验收申请。

2）经过审核，材料齐全则由建设方组织验收。验收工作由建设方和供应商项目组人员一起组成验收小组进行验收，验收后提交验收报告。

3）验收签字经过验收、评审形成的验收报告和评审报告，建设方签字，通过验收。终验内容：

1）项目验收最关键的指标，系统实用性，业务流的整体性和数据的一致性

2）系统稳定性：硬件环境的稳定性、软件运行异常处理和正常运行情况。

3）系统可维护性：含网络系统管理与维护、服务器系统平台管理与维护、操作系统管理与维护、应用系统软件管理与维护、数据库管理与维护以及数据库备份、应用系统备份，灾难事件处理与解决实施方案等。

4）系统文档：验收文档是否齐全、规范、准确、详细，主要的文档包括：需求分析报告，框架设计报告，数据库物理及逻辑设计报告，详细设计报告，编码规范，测试报告，系统部署和发布报告，集成方案，软件用户使用手册，系统维护方案和操作文档等。

5）代码规范及注释说明：程序代码编写是否规范；注释说明或代码文档是否详细全面；接口定义是否符合系统规划一致性的要求

6）系统灵活性：系统是否方便客户进行维护；系统是否在先进性的基础上具备未来升级和可扩充性；是否利于系统平台迁移和部署等。

7）系统可操作性：界面是否友好性；是否实现傻瓜化操作和智能化数据检索功能。8）系统安全性：是否有完善的安全机制保证系统的安全性，如软件方面的安全防范（加密措施、相关认证、数据库安全防范），硬件方面（防火墙、物理隔离和逻辑隔离）的安全设置。1.7 验收依据

验收依据为供应商提供的功能设计（项目过程中依据需求调研结果而提交的各子系统《软件功能描述与操作说明书》，即功能清单。具体依据如下：

A、本项目采购合同的所有文件，尤其是项目需求部分；

B、工程施工过程中的经双方签字的变更需求，包括《二次开发方案》《软件功能描述与操作说明书》《合同或合同变更情况》； C、确认的《系统运行情况报告》；

D、确认的《合同执行情况报告》，确认收到的终验提交文档资料情况； 1.8 验收需提交的文档

提供整个产品交付过程中产生的全部文档，产品验收标准技术说明书使用说明书安装、维修及操作手册合同中要求的其他文件资料，系统验收后供货方需提供系统源码，并签订保密协议。

开发技术文档：《需求分析说明书》、《详细设计》、《二次开发方案》、《数据结构》、《框架结构图》、《应用系统测试方案》、《系统功能说明》，以及其它要求的技术文档。工程技术文档：《测试记录》、《测试报告》、《数据准备报告》《用户操作手册》《系统维护手册》《系统操作说明书》《培训计划》、《培训记录》、《故障情况记录表》《阶段验收方案》 1.9 验收结论

验收结果分为：验收合格、需要复议和验收不合格三种。

1、项目凡具有下列情况之一的，按验收不合格处理：

（一）未按项目考核指标或合同要求达到所预定的主要技术指标的；

（二）所提供的验收材料不齐全或不真实的；

（三）实施过程中出现重大问题，尚未解决和作出说明，或项目实施过程及结果等存在纠纷尚未解决的；

（四）没有对系统或设备进行试运行，或者试运行不合格；

（五）项目经费使用情况审计发现问题的；

（六）违反法律、法规的其他行为。

1.10 项目交接

项目验收合格后，应办理项目交接手续，转入售后维护阶段。

第四篇：体质测试方案

为了加强学校体育工作，使学生积极参加体育锻炼，养成良好的体育锻炼习惯，提高学生的体质健康水平，促进学生健康发展，根据国家教育部和体育总局颁发的《学生体质健康标准》精神和“健康第一”的指导思想，结合我校实际情况，特制定本方案。

一、组织与管理

1.领导小组：

组

长： 李文明 副组长：刘振杰

组

员：王爱国 李金松以及全体班主任

2.具体分工

（1）测试及原始数据采集：王爱国（七、九年级）李金松（八年级）各班主任协助。

（2）数据录入：各班主任及李金松老师。

（3）器材管理：王爱国

（4）数据核查及上报：韩亚婷 李金松。

3、工作时间安排

1、测试及原始数据采集阶段：10.10～10.27

2、数据录入、核查及上报阶段：10.27～10.30

二、测试项目根据学生的生长发育规律，从身体形态、身体机能、身体素质等方面综合评定学生的体育健康状况，测试数据项目为：

男子：身高、体重、肺活量、坐位体前屈、50米跑、1000米跑、引体向上

女子：身高、体重、肺活量、坐位体前屈、50米跑、800米跑、1分钟仰卧起坐

三、测试、登记

1.测试前要作好充分准备工作和制定测试过程中的安全措施。测试数据和记录要准确无误，并进行严格核查，测试、记录。

=2.因病或残疾不能参加全部或部分项目测试，无法进行评分和等级评定的学生，可向学校提交免予执行《学生体质健康标准》的申请，经县级以上证明，班主任、体育教师签字，学校审批后方可免予执行。

但能参加测试的项目仍需测试记录。

3.因病临时不能参加测试的学生经班主任证明，体育教师核准，可不参加本次测试，但须进行补测。

4.对《学生体质健康标准》测试成绩不合格者，在本学准予补考一次，补考仍不及格者，则学年评定等级为不及格。

5.测试成绩、评定结果应及时反馈给学生和家长，以便指导学生进行科学合理的锻炼和得到家长的支持、帮助。

6.《学生体质健康标准》按百分制记分，每个测试项目得分之和为《学生体质健康标准》的最后得分，根据最后得分评定等级：85分以上为优秀，75—84分为良好，60分一74分为及格，59分以下为不及格。

7.每学年测试的原始数据和统计资料由团委妥善保存。

四、具体要求与措施

1.学校做好学生、教师、家长的宣传教育工作，让学生懂得体质健康的重要性，让教师重视学生的体质健康，让家长支持学校的体育达标活动。

2.学校加强对《学生体质健康标准》测试的组织和管理，积极组织多种多样的体育锻炼形式，将体育课的组织形式与课间操以及各种体育课外活动有机结合，促进学生体质健康的发展。

3.学校有计划地开展体育测验活动，督促、指导和加强学生平时锻炼和了解自身体质健康状况，但要避免将体育课变成测验课。

4.学校保证学生体育锻炼时间，安排好两操、一活动，确保学生的每天一小时体育锻炼时间，并作好安排、记录，保证锻炼的质量。

5.学校加强对学生进行安全教育，在日常体育锻炼、测试中作好安全防范工作。

6.学校配齐《学生体质健康标准》测试所用器械，以保障《学生体质健康标准》测试工作的顺利开展。

2015年10月1日

永安中学

附件：

校园学生体质健康标准数据管理与分析系统简介

“校园学生体质健康数据管理与分析系统”产品主要功能： 1.数据上报：一键直接上报国家数据库，实时查询数据上传结果。同时，还可以根据各省市实际需求建立本级学生体质健康标准数据库，实现同步数据管理与分析。

2.运动处方：根据本校每个学生的体质测试状况，制定个性化运动处方，使学生能够有的放矢地进行体育锻炼，有效改善学生的体质健康状况。

3.按测试项目导入：教师可以根据本校体育课测试情况，按2014年新标准规定的测试项目导入学生测试成绩，测试一项导入一项，无需所有项目测试完毕后再导入；如使用智能测试仪进行数据测试，可实时将仪器中的学生测试成绩导入到软件中，不需要进行任何处理和转化。

4.单项评分：系统可以根据学生的测试情况，对单个测试项目进行评分，方便教师及时掌握学生该项目的测试情况，积极引导学生进行针对性锻炼。

5.统计报表：系统可按、年级、班级的学生体质健康标准情况进行实时统计，对学生的测试成绩和全校范围的学生体质健康标准状况进行分析和汇报和总结。

6.学升级：系统拥有自动升级功能，不用反覆的输入或导入学生的基本信息，大大减轻教师工作量，提高了工作效率。

7.登记卡打印：学生毕业一次性打印该生在校期间各年级的体质健康测试成绩，并自动为其计算毕业成绩和等级。

8.网络联机输入：在校园局域网内，可多机联网输入学生体质健康数据功能，不受时间和计算机数量所限，可以更灵活的进行数据管理和报送工作。

第五篇：软件测试方案模板

（项目名称）测试方案

（仅供参考）

文档版本控制

文档版本号

日期

作者

审核人

说明

V1.0.0

2015/X/X

创建文档

1.概述

【软件的错误是不可避免的，所以必须经过严格的测试。通过对本软件的测试，尽可能的发现软件中的错误，借以减少系统内部各模块的逻辑，功能上的缺陷和错误，保证每个单元能正确地实现其预期的功能。检测和排除子系统（或系统）结构或相应程序结构上的错误，使所有的系统单元配合合适，整体的性能和功能完整。并且使组装好的软件的功能与用户要求(即常说的产品策划案)保持一致。】

2.测试资源和测试环境

2.1硬件的配置

关键项

数量

性能要求

期望到位阶段

测试PC机

1台以上

奔4，主频2.6GHZ，硬盘300G以上，内存2G以上，此配置是实际用机

需求分析阶段

数据库服务器

暂定1台

奔4，主频2.6GHZ，硬盘300G以上，内存4G以上，此配置是实际用机

需求分析阶段

2.2.软件配置

资源名称/类型

配置

操作系统环境

操作系统主要分为windows

XP，windows

7。其中windows

XP和windows

7是重点测试对象

浏览器环境

主流浏览器有：IE（IE8以上）、Chrome、Firefox。此测试根据软件研发人员提供的依据决定测试范围

功能性测试工具

手工测试

测试管理工具

DevSuite

2.3.测试数据

本测试方案的测试数据来源于软件测试需求以及测试用例。

3.测试策略

系统测试类型及各种测试类型所采用的方法、工具等介绍如下：

3.1.1.功能测试

测试范围

验证数据的精确度、数据类型、业务功能等相关方面的正确性。

测试目标

核实所有功能均已正常实现，即是否与需求一致。

采用技术

主要采用黑盒测试、边界测试、等价类划分等测试方法。

工具与方法

手工测试

开始标准

开发阶段对应的功能完成并且测试用例设计完成完成标准

测试用例通过并且最高级缺陷全部解决

特殊项

比如该产品可能隶属于A产品线，且A线新功能点多等风险性产品

3.1.2.用户界面(UI)测试

测试范围

1.导航、链接、Cookie、页面结构包括菜单、背景、颜色、字体、按钮名称、TITLE、提示信息的一致性等，2.友好性、可操作性（易用性）

测试目标

核实各个窗口风格（包括颜色、字体、提示信息、图标、title等）都与需求保持一致，或符合可接受标准，能够保证用户界面的友好性、易操作性，而且符合用户操作习惯。

采用技术

网页测试通用方法

工具与方法

手工测试、目测(扫描)

开始标准

界面开发完成完成标准

UI符合可接受标准，能够保证用户界面的友好性、易操作性，而且符合用户操作习惯

测试重点与优先级

根据实际需求而定

需考虑的特殊事项

根据实际需求而定

根据实际需求而定

3.1.3.性能测试

测试范围

1.用户、管理员的密码安全

2.权限

3.非法攻击

测试目标

1.用户、管理员的密码管理

2．应用程序级别的安全性：核实用户只能操作其所拥有权限能操作的功能。

3．系统级别的安全性：核实只有具备系统访问权限的用户才能访问系统。

采用技术

代码包或者非法攻击工具

工具与方法

手工测试

开始标准

功能测试完成完成标准

执行各种非法操作无安全漏洞且系统使用正常

测试重点与优先级

根据实际需求而定

需考虑的特殊事项

根据实际需求而定

3.1.4.安全性测试

测试范围

1.用户、管理员的密码安全

2.权限

3.非法攻击

测试目标

1.用户、管理员的密码管理

2．应用程序级别的安全性：核实用户只能操作其所拥有权限能操作的功能。

3．系统级别的安全性：核实只有具备系统访问权限的用户才能访问系统。

采用技术

代码包或者非法攻击工具

工具与方法

手工测试

开始标准

功能测试完成完成标准

执行各种非法操作无安全漏洞且系统使用正常

测试重点与优先级

根据实际需求而定

需考虑的特殊事项

根据实际需求而定

3.1.5.兼容性测试

测试范围

1．使用不同版本的不同浏览器、分辨率、操作系统分别进行测试。

2．不同操作系统、浏览器、分辨率和各种运行软件等各种条件的组合测试。

测试目标

核实系统在不同的软件和硬件配置中运行稳定

采用技术

黑盒测试

工具与方法

手工测试

开始标准

项目组移交系统测试

完成标准

在各种不同版本不同类项浏览器、操作系统或者其组合下均能正常实现其功能（此测试根据开发提供依据决定测试范围）

测试重点与优先级

根据实际需求而定

需考虑的特殊事项

根据实际需求而定

3.1.6.回归测试

测试范围

所有功能、用户界面、兼容性、安全性等测试类型

测试目标

核实执行所有测试类型后功能、性能等均达到用户需求所要求的标准

采用技术

黑盒测试

工具与方法

手工测试和自动化测试

开始标准

每当被测试的软件或其环境改变时在每个合适的测试阶段上进行回归测试

完成标准

95%的测试用例执行通过并通过系统测试

测试重点与优先级

测试优先级以测试需求的优先级为参照

需考虑的特殊事项

软硬件设备问题

3.2．测试实施阶段

测试类型

测试阶段

单元测试

集成测试

系统测试

验收测试

功能测试

×

ü

ü

×

性能测试

×

ü

ü

×

安全性测试

×

ü

ü

×

兼容性测试

×

ü

ü

×

用户界面（UI）测试

×

ü

×

回归测试

每当被测试的软件或其环境改变时在每个合适的测试阶段上进行回归测试。

备注：“ü”表示由测试组执行，“×”表示由项目组执行；

4.软件测试的通用标准

被测系统无业务逻辑错误和二级的BUG。经确定的所有缺陷都已得到了商定的解决结果。所设计的测试用例已全部重新执行，已知的所有缺陷都已按照商定的方式进行了处理，而且没有发现新的缺陷。

注：缺陷的严重等级说明

A：严重影响系统运行的错误；

B：功能方面一般缺陷，影响系统运行；

C：界面布局不美观或轻型错误；

D

:

不影响运行的错别字等；

E：合理化建议。

5.测试用例及测试用例追溯表

5.1.1测试用例模板(仅供参考)

5.1.2.测试用例跟踪表(仅供参考)