【文章內(nèi)容簡介】 品功能實現(xiàn)歧義地方，進(jìn)行明確；3開發(fā)人員負(fù)責(zé)功能開發(fā)、缺陷修復(fù)、單元測試；4開發(fā)責(zé)任人負(fù)責(zé)軟件開發(fā)進(jìn)度、版本提交和相關(guān)協(xié)調(diào)；5配置管理員負(fù)責(zé)每輪測試前：代碼獲取、編譯、發(fā)布；6測試經(jīng)理負(fù)責(zé)項目測試整體計劃、協(xié)調(diào)和質(zhì)量；7測試人員負(fù)責(zé)測試方案編寫、測試用例編寫、測試執(zhí)行、質(zhì)量分析；（非必須）隨機(jī)測試沒有書面測試用例、記錄期望結(jié)果、檢查列表、腳本或指令的測試。主要是根據(jù)測試者的經(jīng)驗對軟件進(jìn)行功能和性能抽查。隨機(jī)測試是根據(jù)測試說明書執(zhí)行用例測試的重要補(bǔ)充手段，是保證測試覆蓋完整性的有效方式和過程。 隨機(jī)測試主要是對被測軟件的一些重要功能進(jìn)行復(fù)測，也包括測試那些當(dāng)前的測試用例沒有覆蓋到的部分。另外，對于軟件更新和新增加的功能要重點測試。重點對一些特殊點情況點、特殊的使用環(huán)境、并發(fā)性、進(jìn)行檢查。尤其對以前測試發(fā)現(xiàn)的重大Bug，進(jìn)行再次測試，可以結(jié)合回歸測試（非必須） β測試 （beta測試）β測試是軟件的多個用戶在一個或多個用戶的實際使用環(huán)境下進(jìn)行的測試。開發(fā)者通常不在測試現(xiàn)場，Beta測試不能由程序員或測試員完成。 當(dāng)開發(fā)和測試根本完成時所做的測試，而最終的錯誤和問題需要在最終發(fā)行前找到。這種測試一般由最終用戶或其他人員完成，不能由程序員或測試員完成。 α測試（Alpha測試）Alpha測試是由一個用戶在開發(fā)環(huán)境下進(jìn)行的測試，也可以是公司內(nèi)部的用戶在模擬實際操作環(huán)境下進(jìn)行的受控測試，Alpha測試不能由該系統(tǒng)的程序員或測試員完成。 在系統(tǒng)開發(fā)接近完成時對應(yīng)用系統(tǒng)的測試。測試后，仍然會有少量的設(shè)計變更。這種測試一般由最終用戶或其他人員來完成，不能由程序員或測試員完成。α測試和β測試的不同之處在于測試的環(huán)境，前者是在開發(fā)環(huán)境，后者是在實際使用環(huán)境（生產(chǎn)環(huán)境），故后者模擬真實使用場景程度更高，發(fā)現(xiàn)的問題也更有意義，一般運(yùn)用在項目的試運(yùn)行階段。（按測試內(nèi)容劃分）功能測試也叫黑盒測試，是在不看代碼的前提下，通過運(yùn)行軟件來進(jìn)行測試，重點是關(guān)注系統(tǒng)的功能實現(xiàn)是否正常、設(shè)計是否合理、用戶的需求是否全部覆蓋，這也是測試工作最主要、最重要的內(nèi)容。在版本穩(wěn)定以后，或者進(jìn)行回歸測試的時候，可根據(jù)項目的具體情況，對主要功能通過編寫自動化測試腳本，進(jìn)行自動化測試。根據(jù)被測功能點的特性列丼出相應(yīng)類型的測試用例對其進(jìn)行覆蓋，如；涉及輸入的地方需要考慮等價、邊界、負(fù)面、異常或非法、場景回滾、關(guān)聯(lián)測試等測試類型對其進(jìn)行覆蓋。 在測試實現(xiàn)的各個階段跟蹤測試實現(xiàn)與需求輸入的覆蓋情況，及時修正業(yè)務(wù)或需求理解錯誤。測試內(nèi)容序列分類說明1基本功能、刪、改、查；；；（包括數(shù)據(jù)）。2邊界類，對16bit 的整數(shù)而言 32767 和 32768 是邊界；、最右下位置；；；+1/空值；，找出其它可能的邊界值條件。3等價類，指符合系統(tǒng)設(shè)計有意義的輸入輸出合集；，指不符合系統(tǒng)設(shè)計錯誤的輸入輸入合集；4錯誤推測基于經(jīng)驗和直覺推測程序中所有可能存在的各種錯誤；5因果圖設(shè)計因果圖，將因果圖轉(zhuǎn)化為判定表，判定表的每一列作為一條測試用例。6用戶場景設(shè)計根據(jù)不同用戶運(yùn)行該系統(tǒng)時所做的操作，來設(shè)計用例。8APP特有功能；；；、照相機(jī)服務(wù)，掃描二維碼功能；；；。App的功能測試具體為：l 運(yùn)行1）App安裝完成后的試運(yùn)行，可正常打開軟件。2）App打開測試，是否有加載狀態(tài)進(jìn)度提示。3）App打開速度測試，速度是否可觀。4）App頁面間的切換是否流暢，邏輯是否正確5）注冊同表單編輯頁面用戶名密碼長度注冊后的提示頁面前臺注冊頁面和后臺的管理頁面數(shù)據(jù)是否一致注冊后，在后臺管理中頁面提示6）登錄使用合法的用戶登錄系統(tǒng)。系統(tǒng)是否允許多次非法的登陸，是否有次數(shù)限制。使用已經(jīng)登陸的賬號登陸系統(tǒng)是否正確處理。使用禁用的賬號登陸系統(tǒng)是否正確處理。用戶名、口令（密碼）錯誤或漏填時能否登陸。刪除或修改后的用戶，原用戶登陸。不輸入用戶口令和用戶、重復(fù)點（確定或取消按鈕）是否允許登陸。登陸后，頁面中登陸信息。頁面中有注銷按鈕。登陸超時的處理。7）注銷注銷原模塊，新的模塊系統(tǒng)能否正確處理。終止注銷能否返回原模塊，原用戶。注銷原用戶，新用戶系統(tǒng)能否正確處理。使用錯誤的賬號、口令、無權(quán)限的被禁用的賬號進(jìn)行注銷l 應(yīng)用的前后臺切換1) APP切換到后臺，再回到app，檢查是否停留在上一次操作界面。2) APP切換到后臺，再回到app，檢查功能及應(yīng)用狀態(tài)是否正常，IOS 4和IOS 5的版本的處理機(jī)制有的不一樣。 3) app切換到后臺，再回到前臺時，注意程序是否崩潰，功能狀態(tài)是否正常，尤其是對于從后臺切換回前臺數(shù)據(jù)有自動更新的時候。 4) 手機(jī)鎖屏解屏后進(jìn)入app注意是否會崩潰，功能狀態(tài)是否正常，尤其是對于從后臺切換回前臺數(shù)據(jù)有自動更新的時候。 5) 當(dāng)App使用過程中有電話進(jìn)來中斷后再切換到app，功能狀態(tài)是否正常 6) 當(dāng)殺掉app進(jìn)程后，再開啟app，app能否正常啟動。 7) 出現(xiàn)必須處理的提示框后，切換到后臺，再切換回來，檢查提示框是否還存在，有時候會出現(xiàn)應(yīng)用自動跳過提示框的缺陷。 8) 對于有數(shù)據(jù)交換的頁面，每個頁面都必需要進(jìn)行前后臺切換、鎖屏的測試，這種頁面最容易出現(xiàn)崩潰。l 免登錄很多應(yīng)用提供免登錄功能，當(dāng)應(yīng)用開啟時自動以上一次登錄的用戶身份來使用app. 1) app有免登錄功能時，需要考慮IOS版本差異。 2) 考慮無網(wǎng)絡(luò)情況時能否正常進(jìn)入免登錄狀態(tài)。 3) 切換用戶登錄后，要校驗用戶登錄信息及數(shù)據(jù)內(nèi)容是否相應(yīng)更新，確保原用戶退出。 4) 根據(jù)MTOP的現(xiàn)有規(guī)則，一個帳戶只允許登錄一臺機(jī)器。所以，需要檢查一個帳戶登錄多臺手機(jī)的情況。原手機(jī)里的用戶需要被踢出，給出友好提示。 5) app切換到后臺，再切回前臺的校驗 6) 切換到后臺，再切換回前臺的測試 7) 密碼更換后，檢查有數(shù)據(jù)交換時是否進(jìn)行了有效身份的校驗 8) 支持自動登錄的應(yīng)用在進(jìn)行數(shù)據(jù)交換時，檢查系統(tǒng)是否能自動登錄成功并且數(shù)據(jù)操作無誤。 9) 檢查用戶主動退出登錄后，下次啟動app，應(yīng)停留在登錄界面l 數(shù)據(jù)更新根據(jù)應(yīng)用的業(yè)務(wù)規(guī)則，以及數(shù)據(jù)更新量的情況，來確定最優(yōu)的數(shù)據(jù)更新方案。 1) 需要確定哪些地方需要提供手動刷新，哪些地方需要自動刷新，哪些地方需要手動+自動刷新。 2) 確定哪些地方從后臺切換回前臺時需要進(jìn)行數(shù)據(jù)更新。 3) 根據(jù)業(yè)務(wù)、速度及流量的合理分配，確定哪些內(nèi)容需要實時更新，哪些需要定時更新。 4) 確定數(shù)據(jù)展示部分的處理邏輯，是每次從服務(wù)端請求，還是有緩存到本地，這樣才能有針對性的進(jìn)行相應(yīng)測試。 5) 檢查有數(shù)據(jù)交換的地方，均有相應(yīng)的異常處理。 l 離線瀏覽很多應(yīng)用會支持離線瀏覽，即在本地客戶端會緩存一部分?jǐn)?shù)據(jù)供用戶查看。 1) 在無網(wǎng)絡(luò)情況可以瀏覽本地數(shù)據(jù) 2) 退出app再開啟app時能正常瀏覽 3) 切換到后臺再切回前臺可以正常瀏覽 4) 鎖屏后再解屏回到應(yīng)用前臺可以正常瀏覽 5