第一篇：小學教師測試方案

小學語文教師普通話和“兩筆字”測試

實施方案

為了進一步提高小學語文教師普通話水平,規范教師的粉筆字、鋼筆字書寫，促進教師的專業發展，經局委會研究，決定組織全縣小學語文教師進行普通話和“兩筆字”測試活動。具體安排如下：

一、組織領導

本次活動在教育局的統一領導下，由教研室具體組織實施。

二、測試對象

小學任語文學科（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.測試用例跟蹤表(僅供參考)