第一篇：測試相關總結

2013年對于質控部整體員工來說是緊張的一年，測試的工作量要比去年多很多，但是工作氛圍卻越來越融洽，測試的流程也越來越規范，員工的技能和處事能力都有大幅度提升，時間和精力的投入與收獲基本上成正比。

測試人員最基礎的工作就是測試，對于本公司的項目來說測試人員主要是對業務和功能點進行測試，隨著公司的發展，國內項目現在基本上都是JAVA項目，且JAVA項目的業務和功能點相對.net項目來說要復查的多，剛開始對JAVA項目進行測試時我們基本上都只是停留在表面，沒有進行深入，但隨著測試項目的增加測試人員對項目的理解也在逐漸加深，現在整個部門的人員對業務和功能點的熟悉程度平均下來有90%，但是仍有10%需要測試人員再進行更深入的熟悉和理解。

每個測試人員的測試方式都是不同的，再加上業務的熟悉程度不同，每個人員對相同的模塊的測試覆蓋率也有大有小，導致會出現很多漏測，分析之后的結論是由于測試人員的測試能力有所欠缺和態度不端正引起的，并且測試人員對漏測不是很關注，仍然優先考慮完成工作的時間而不是質量，但自從出現漏測獎懲制度后，測試人員的態度有較大的提升，通過對漏測bug的分析和總結，現在的漏測率也就基本上控制在10%之內了，員工的工作能力還是需要在一定制度的約束下才能夠盡量的發揮出來。

測試人員對缺陷的嚴重級別應該需要有一個很清晰的認識，特別是對3級和3級以下缺陷的劃分要清晰，我們部門員工對于缺陷嚴重級別的概念不是非常清晰，有時會將2級缺陷和3級缺陷搞混淆，但自從缺陷提交標準和測試標準出來之后測試人員對提交的bug越來越規范化，對缺陷的描述越簡單易懂，對缺陷的嚴重程度的定義也越精確，開發人員和測試人員也越少因為缺陷而起爭執，這為整個測試部門的測試流程走向正軌打下了基礎。

對于測試環境的搭建現在不是每個測試人員都具備這個能力，大部分的環境都是我在搭建，其他人在搭建環境中出現的問題也基本上都是我在幫助他們在進行解決，沒有多少人能夠很熟練的搭建環境和發布程序包，此處屬于我們部門員工的薄弱點，還是我們部門同事針對搭建環境的能力進行加強，熟練的搭建環境才能夠節省整個項目的測試時間。

整個質控部的工作模式到目前為止基本上已經成型，每個項目都會分給對應的人員進行負責，項目負責人需要對整個項目有明確的了解，并且通過開發人員提交的程序合理安排時間和人員進行測試，測試完成之后需要對新建的bug進行檢查和過濾等，但是現在的測試負責人仍沒有起到很大的作用，也沒有很合理的安排計劃，也沒有嚴格按照計劃來執行，本人對于測試負責人這塊的工作也沒有做的很到位，有很多的地方都需要改善，在后面的工作中我會盡量將測試負責人的工作做到位。

對于同事之間的合作我們部門做的還是相當不錯的，有人遇到了無法解決的問題之后其他人員也都會較主動的幫助其解決，但是這樣就養成了一個很不好的習慣，有些同事一遇到問題就找其他人員幫忙，都沒有經歷多自己的獨立思考，并且有些同事的健忘性也很大，同樣的問題出現了很多次仍然不知道怎么解決，依賴性太強，希望這些同事在以后的工作中盡量能夠自己獨立解決問題，不然總是找別人也會耗費其他人的時間。

由于工作量的加大質控部門員工學習的時間非常少，且公司對于程序的關注點基本上就是在功能方面，測試人員學習的技能也停留在了功能測試方面，基本上所有的員工對于自動化測試、性能測試等都沒有了解，希望隨著公司的發展，公司對自動化測試和性能測試方面能夠加大關注力度，全方位的提升程序的質量，測試人員通過對自動化和性能的深入了解，在測試這條路上也能夠走的更遠。

以上主要是我個人對質控部工作的一個分析總結，其中的一些問題需要我們共同的去解決，不斷的完善質控部的測試流程和提高測試人員的能力，謝謝！

第二篇：口語測試總結

六年級語文口語測試總結

（2017——2018學年第二學期）

一、總體情況

這次我年級進行口語測試考評，測試地點就為本班班級。學生到位后，考評老師按考核名單點名考核，并且根據情況記錄、評價。首先由學生四人為一組抽簽背誦作品，4人按照抽簽內容背誦完畢后，進入口語考核，同樣抽簽決定考核內容，5分鐘時間準備，前一名學生進行口語考核時，再由后一名學生做好準備。

考評完畢后，由本班語文教師做好登記、統計全班考評成績，并將考核結果交由教導處存檔。

朗讀和說話不合格的都給予了一次補說的機會。

二、成績和不足

這次口語測試，學生參與率高。測試中，所有學生能用普通話對話，少數學生口試發音準確、說話流利、連貫，通過測試，大部分學生能重視口語對話。但仍存在很多問題。

1、部分學生對口語測試重視不夠。試題下發后兩天內，要求學生積極準備，但在以后的測試中，讀音不準、讀錯字、別字的人很多，甚至有個別學生在復試時仍將字讀錯。說話測試時，有少數學生三言兩語就結束，有的根本就沒有圍繞話題，有應付口試跡象。

2、學生的朗讀水平普遍很差。測試中發現學生對朗讀普遍停留在識字階段，缺乏對內容的理解和朗讀感情的投入，一字一板，平鋪直敘的識字式朗讀者甚多；讀音的輕重緩急、停頓、語調變換等朗讀技巧能體現者較少；有少數學生已出現斷句錯誤，將詞分開來讀。

3、說話測試問題最多。首先是很多學生缺乏認真審題，其次是學生在說話時語句組織不當。方言詞過多、大量重復、說話不連貫、前言不搭后語想象較多。

4、交往常識、社會禮儀不重視。雖然我們沒有要求使用禮貌用語，但仍有很多同學上臺自報姓名，測試完畢后都能用“請”“謝謝”等禮貌用語，但效仿者不多；很多學生在測試時低著頭，身體搖來晃去，舉止不大方；盡管我們沒有扣分，但給人留下了一個不好的測試印象。

通過這次測試，我們語文教師感覺我校學生口語交際水平還很低，還需要我們在以后工作中給予重視，另外，個別筆試成績優異的學生卻口試成績不理想，也告誡我們，在素質教育和新課改的背景下，我們要重視學生的各方面能力培養，讓學生全面發展，才能讓其更好地走入社會，適應社會。

第三篇：體育測試總結

2013年學生體質測試工作總結

西華縣實驗小學 13年11月12日

為貫徹落實學校體育“健康第一”的指導思想，切實加強學校體育工作的開展，我校十分重視《學生體質健康標準》實施和測試工作，在2013年9月至10月對全校學生進行了體育項目測試，并將測試數據上報，現將實施工作總結如下：

一、積極宣傳，加強培訓，提高工作質量

開學初，李校長召開全體體育老師及班主任會議，要求各級各班要重視體育測試工作。要求體育教師明確各年級測試項目，測試步驟和操作細則，對各班進行《標準》的測試項目及鍛煉方法的宣傳教育，讓他們認識《標準》實施辦法的重要性和必要性，李校長還把《標準》工作方案復印給各班，讓學生了解測試達標要求來督促自已平時積極主動地鍛煉身體。會后體育教師共同學習了國家學生體質健康標準測試數據上報工作培訓手冊，制訂具體測試方法、步驟。

二、組織測試，保障安全

1、在測試前，對各班學生認真統計、輸機、把每個學生的信息輸入微機并上傳到國家測試網。對學生進行身體健康情況的摸底調查，有計劃、有組織地安排測試，并對測試儀器調試、場地、設施以及環境的布臵和安排進行排查，制訂詳細的測試細則和安全措施，指導受試者做好充分的預備活動等。

2、對各年級的測試項目都做了統一的規定，身高、體重、視力為各年級的必測項目，其他年級測試項目為：

一、二年級一分鐘跳短繩、50米跑、坐位體前屈。

三、四年級為50米跑、坐位體前屈、一分鐘仰臥起坐、一分鐘跳短繩。五六年級為50米跑、肺活量、坐位體前屈、一分鐘仰臥起坐、一分鐘跳短繩、50米乘8往返跑。在測試過程中，充分發揮體育骨干的作用，使學生能安全有序地完成測試任務。

3、在測試過程中，局領導非常重視測試工作，安排主要項目都有外校體育教師測試，并親自到現場視察、指導工作。在測試過程中，學生態度端正，認真測試，積極配合外校來測試老師工作，各項測試成績很真實。但是也有一小部分學生抱著好玩的心態。五六年級學生對耐力項目（50米×8）的測試有偷懶的現象，導致50米×8往返跑成績較低。

三、數據整理上報

在測試全部結束后，利用計算機教師的空余時間對數據進行錄入、錄入之后體育教師對數據進行了認真核對，分析并上傳，實事求是地向學生反饋測試結果。

四、通過數據分析問題。全校2762人參加了《標準》活動，結果表明，學生的體質健康的現狀不容樂觀，主要表現如下幾個方面：

1、學生體能素質下降。學生的速度、耐力、柔韌性、爆發力和力量等素質均出現全面下降。除反映速度素質的 50米跑成績下降幅度較小外。其余各方面素質下降幅度較為明顯。

2、學生視力下降，近視的人數增加，肥胖學生增多，特別是低年級肥胖增長更快。

3、從坐位體前屈及格人數看，學生身體的協調性還有待于提高。

4、反映肺功能的肺活量有下降趨勢。學生體質健康方面存在的問題其原因是多方面的，但造成學生身體下降。特別是耐力、柔韌性、力量和肺活量持續下降的重要原因之一是學生體育鍛煉不足，包括鍛煉時間和強度均不夠，尤其是學校組織的課外體育活動少。存在重智育輕體育的嚴重現象。而隨著人民生活水平普遍改善帶來的熱量攝入過多，飲食結構和習慣也不合理。也是導致學生肥胖，身體素質下降的主要原因之一。

雖然完成了今年的工作任務，但還有許多問題要繼續研究和探索，建立一套更加完善的方法，促進學生身心健康成長，為全面建設社會主義小康社會和構建社會主義和諧社會做出應有的貢獻

第四篇：app測試總結

App測試總結

一、App測試流程與web項目流程區別

1.對UI要求比較高，需要更加注重用戶體驗。對于一個小小的屏幕，如何讓用戶使用更加輕便、簡介、易用。

2.App是調用服務端接口展示數據。我們測試需要可以判斷問題是客戶端還是服務端接口返回數據錯誤。

3.App網絡測試。手機對網絡要求比較特別，網絡分2G，3G，wifi。有條件的話，可以分別測試下。

4.App需要版本升級功能。（非常重要）

5.Push推送測試（現在客戶基本都挺重視此功能）

二、服務端測試

服務端一般會提供JSON格式的數據給客戶端，所以我們在服務端需要進行接口測試，確保服務端提供的接口并轉換的JSON內容正確，對分支、異常流有相應的放置。我們可以用RESTClient進行接口測試（接口需要開發提供文檔，如何調用接口）安裝方法

1.安裝Firefox-附件組件-擴展

2.安裝成功后，點擊restclient圖標

根據開發提供文檔編輯url如圖，可以獲取json數據。通過這個我們可以測試接口返回數據是否正確

三、客戶端測試

1.網絡

1）無網絡，執行需要網絡的操作，要有友好的提示，確保程序不出現crash。由于網絡出現crash都屬于bug。

2）內網測試時，要注意選擇到外網操作時的異常處理。

3）網絡信號不好時，檢查功能狀態是否正常，確保不因提交數據失敗而造成crash 4）網絡信號不好時，檢查數據是否會一直處于提交中的狀態，有無超時限制。如遇數據交換失敗時要給予提示

5）網絡信號不好時，執行操作后，在回調沒有完成的情況下，退出本頁面或者執行其他操作的情況，有無異常情況。此問題也會經常出現程序crash

2.應用的前后臺切換

1）app切換到后臺，再回到app，檢查是否停留在上一次操作界面 2）app切換到后臺，再回到app，檢查功能及應用狀態是否正常

3）app切換到后臺，再回到前臺時，注意程序是否崩潰，功能狀態是否正常，尤其是對于從后臺切換前臺數據有自動更新的時候。

4）手機鎖屏解屏后進入app注意是否會崩潰，功能狀態是否正常，尤其是對于從后臺切換前臺數據有自動更新的時候。

5）當app使用過程中有電話進來中斷后再切換到app，功能狀態是否正常 6）當殺掉app進程后，再開啟app，app能否正常啟動

7）出現必須處理的提示框后，切換到后臺，再切換回來，檢查提示框是否還存在（譬如強制更新提示框）。有時候會出現應用自動跳過提示框的缺陷

8）對于有數據交換的頁面，每個頁面都必須要進行后臺切換、鎖屏測試。這種頁面最容易出現崩潰

3.數據更新

根據應用的業務規則，以及數據更新量的情況，來確定最優的數據更新方案。1）需要確定哪些地方需要提供手動刷新，哪些地方需要自動刷新，哪些地方需要手動+自動刷新

2）確定哪些地方從后臺切換回前臺時需要進行數據更新 4.5.6.7.8.3）根據業務、速度及流量的合理分配，確定哪些內容需要實時更新，哪些需要定時更新

4）確定數據展示部分的處理邏輯，是每次從服務端請求，還是有緩存到本地，這樣才能有針對性的進行相應測試

5）檢查有數據交換的地方，均有相應的異常處理 Push測試

1）檢查push消息是否按照指定的業務規則發送

2）檢查不接受推送消息時，檢查用戶不會再接收到push 3）如果用戶設置了免打擾的時間段，檢查在免打擾時間段內，用戶接收不到push。再非免打擾時間段，用戶能正常收到push 4）需要注意的是，Ios如果是開發刷上來的app，是沒有推送的。需要自己網頁上下載或者拿到ipa安裝包自己使用手機助手安裝的才有推送 客戶端更新

客戶端更新一般是通過與服務器返回的當前版本號比較來判斷是否有更新。我們測試模擬更新時，首先要了解到服務端當前版本號(1.0)，然后讓客戶端打高版本的安裝包(2.0)，通知服務端改服務端版本號也改成2.0，把2.0安裝包放服務端后。即可開始升級測試。

1）當客戶端有新版本時，有更新提示

2）當版本為非強制升級版時，用戶可以取消更新，老版本能正常使用。用戶在下次啟動app時，仍能出現更新提示。如果是正式app已經上線，那么升級時一定要考慮老版本是否能正常使用。

3）當版本為強制升級版時，當給出強制更新后用戶沒有做更新時，退出客戶端或者切換到后臺，下次啟動app時，仍出現強制升級提示

4）可以不刪除客戶端，覆蓋安裝。覆蓋安裝后，登錄信息都應該保存的。5）更新成功后，檢查是否是新版本。并且不能再提示升級 免登錄

很多應用提供免登錄功能，當應用開啟時自動以上一次登錄的用戶身份來使用app 1）考慮無網絡情況時能否正常進入免登錄狀態

2）切換用戶登錄后，要校驗用戶登錄信息及數據內容是否相應更新，確保原用戶退出

3）App切換到后臺再切換到前臺的校驗

4）密碼更換后，檢查有數據交換時是否進行了有效身份的校驗 5）檢查用戶主動退出登錄后，下次啟動app，應停留在登錄頁面 離線瀏覽

很多應用會支持離線瀏覽，即在本地客戶端會緩存一部分數據供用戶查看。1）在無網絡情況可以本地瀏覽本地數據 2）退出app再開啟app時能正常瀏覽 3）切換到后臺再切回前臺可以正常瀏覽 4）鎖屏后再解屏回到應用前臺可以正常瀏覽

5）在對服務端的數據有更新時會給予離線的相應提示 時間測試

客戶端可以自行設置手機的時區、時間因此需要校驗該設置對app的影響。

時間一般需要根據服務器時間再轉換成客戶端對應的時區來展示，這樣的用戶體驗比較好。譬如發表一篇微博在服務端記錄是10:00，此時，華盛頓時間為22:00，客戶端去瀏覽時，如果設置的是華盛頓時間，則顯示發表時間為22：00.四、零散通用內容測試

1.對模擬鍵盤的處理，例如鍵盤展開后，點擊其他位置是否正常首期，鍵盤使用完成后，能否正常收起

2.同事或者快速點擊不同的兩個按鍵，檢查程序是否正常，此問題經常會crash，或者出現兩個功能界面并存的情況 3.較快速點擊同一按鈕多次，檢查程序是否正常，一般情況下需要對按鈕做置灰處理，在響應成功之前，只允許操作一次，否則可能會產生重復數據

4.文字特殊符號的展示顯示能正常輸入，不轉義顯示，如<>不會顯示成<> 5.考慮界面的完整性，在界面數據顯示寬度上，我們要考慮是自適應，還是自動換行，當自適應的時候，程序會在顯示不全的時候自動顯示…,此時，就要考慮哪些內容是可以…,哪些內容是必須要完整顯示的。

6.字體，顏色，視覺搭配的感觀測試也是很重要的一點，如果你感覺看上去很模糊，或者看著很累，說明設計上肯定是存在一定問題

五、問題排查

我們在客戶端測試時，經常會碰到程序crash，有的是可以重現的。有的是莫名其妙的閃退

可以找開發debug，譬如ios。連上xcode運行，debug。Ios的話，你的應用的歷史crash都是可以在蘋果mac機器上看到crash的日志的。

第五篇：功能測試總結

以下內容，感謝本人朋友提供：

1.對你們整個系統的數據流走向熟悉了嗎 2.沒操作一步，數據進入哪些表? 什么狀態? 3.產生多少條數據 4.服務架構是什么 5.抓包分析你的接口了嗎

6.那怎么定位到代碼錯誤的?先查看日志

服務器架構