20xx年ps-qa-軟件開發(fā)測(cè)試流程-免費(fèi)閱讀
【正文】 八 注意事項(xiàng) ? 需求發(fā)生變更時(shí)，產(chǎn)品人員和研發(fā)人員 都要在第一時(shí)間通知 測(cè)試人員 ? 測(cè)試環(huán)境與現(xiàn)網(wǎng)環(huán)境要相符 ? 研發(fā)數(shù)據(jù)庫(kù)與測(cè)試數(shù)據(jù)庫(kù)分離 ? 測(cè)試環(huán)境應(yīng)與研發(fā)環(huán)境分離 ? 測(cè)試時(shí)間制定需與測(cè)試人員協(xié)商 ? 研發(fā)人員在重啟、更新環(huán)境時(shí)需要第一時(shí)間通知測(cè)試人員，以免影響測(cè)試人員工作 ? 項(xiàng)目組組長(zhǎng)以郵件的形式提前下周的測(cè)試任務(wù) ? 研發(fā)人員提交測(cè)試的版本要先通過自測(cè)，自測(cè)通過后再提交測(cè)試人員 ? 測(cè)試執(zhí)行中出現(xiàn)特殊情況需要上線 時(shí)，需要產(chǎn)品人員、運(yùn)營(yíng)人員簽字，方可上線 。修改完成的 bugs在 bugs系統(tǒng)中修改其狀態(tài)， 在備注欄中概要描述是怎樣解決的或 是 bugs 的需求是否發(fā)生變化等（方便測(cè)試人員回歸測(cè)試，測(cè)試功能、模塊有影響的部分）， 并對(duì) Reopen的 bugs再次進(jìn)行核對(duì)或修改。 包括以下各種錯(cuò)誤： ? 光標(biāo)跳轉(zhuǎn)設(shè)置不好，鼠標(biāo)（光標(biāo)）定位錯(cuò)誤 ? 一些建議性問題 ? 拼寫錯(cuò)誤，文本未對(duì)齊 七 缺陷管理說(shuō)明 缺陷管理工具使用 Mantis，測(cè)試人員及時(shí)提交在測(cè)試過程中發(fā)現(xiàn)的 bugs，并及時(shí)通知研發(fā)人員修改，以保證項(xiàng)目進(jìn)度。系統(tǒng)崩潰導(dǎo)致系統(tǒng)不能繼續(xù) 運(yùn)行。 【說(shuō)明】 ： ? 測(cè)試完成 ：是指對(duì)當(dāng)前版本完成了測(cè)試，等待發(fā)布新版本進(jìn)行回歸測(cè)試。 3. 研發(fā)人員 ? 研發(fā)人員在接到任務(wù)工單的同時(shí)，需同時(shí)給測(cè)試組下任務(wù)工單 ； ? 根據(jù)項(xiàng)目的實(shí)際確定多長(zhǎng)時(shí)間發(fā)布一次版本（根據(jù)項(xiàng)目具體情況決定）； ? 制定項(xiàng)目進(jìn)度計(jì)劃，接到新的研發(fā)任務(wù)要制定進(jìn)度計(jì)劃時(shí)，需要把測(cè)試時(shí)間考慮進(jìn)去，具體的測(cè)試時(shí)間可與測(cè)試人員進(jìn)行溝通，以確保項(xiàng)目的進(jìn)度。 ? 驗(yàn)收通過，測(cè)試人員編寫測(cè)試分析報(bào)告，報(bào)告中描述測(cè)試中出現(xiàn)的問題，以及測(cè)試結(jié)果。 ? 測(cè)試人員根據(jù)《需求說(shuō)明文檔》和《概要設(shè)計(jì)文檔》編寫《測(cè)試用例》 。一般用自動(dòng)化測(cè)試工具代替人工操作，但由于人力資源問題，一般公司不經(jīng)歷這個(gè)階段 ? 驗(yàn)收測(cè)試 —— 驗(yàn)收測(cè)試是相對(duì)復(fù)雜的一種測(cè)試，需要研發(fā)人員、最終用戶的共同參與，驗(yàn)收不僅僅針對(duì)系統(tǒng)的 bugs，而是對(duì)整體項(xiàng)目或產(chǎn)品的發(fā)布流程的一種測(cè)試，一般包括系統(tǒng)本身測(cè)試、文檔測(cè)試等。通常 采用 白盒測(cè)試方法 。評(píng)審不通過時(shí)測(cè)試人員對(duì)測(cè)試計(jì)劃進(jìn)行修改、補(bǔ)充，直至評(píng)審?fù)ㄟ^ 。 ? 如果模塊中所有問題均已關(guān)閉，郵件或直接通知相關(guān)人員該模塊測(cè)試結(jié)束。 【注】：提交的《需求說(shuō)明》文檔應(yīng)為通過《需求說(shuō)明》文檔評(píng)審的。（根據(jù)運(yùn)營(yíng)的具體需求調(diào)節(jié)）； ? 由于項(xiàng)目進(jìn)度不同，測(cè)試文檔會(huì)根據(jù)不同的情況進(jìn)行整合。 4. 《需求文檔》、《設(shè)計(jì)文檔》和編碼實(shí)現(xiàn)一致。 包括以下各種錯(cuò)誤： ? 操作界面錯(cuò)誤（包括數(shù)據(jù)窗口內(nèi)列名定義、含義是否一致） ? 打印內(nèi)容、格式錯(cuò)誤（只影響報(bào)表的格式或外觀，不影響數(shù)據(jù)顯示結(jié)果的錯(cuò)誤） ? 簡(jiǎn)單的輸入限制未放在前臺(tái)進(jìn)行控制 ? 刪除操作未給出提示 ? 已被捕捉的系統(tǒng)崩潰，不影響繼續(xù)操作 ? 雖然正確 性不受影響，但系統(tǒng)性能和響應(yīng)時(shí)間受到影響 ? 不能定位焦點(diǎn)或定位有誤，影響功能實(shí)現(xiàn) ? 顯示不正確但輸出正確 ? 增刪改功能，在本界面不能實(shí)現(xiàn)，但在另一界面可以補(bǔ)充實(shí)現(xiàn)。 4. 測(cè)試人員對(duì)每一個(gè)新的測(cè)試版本進(jìn)行測(cè)試，測(cè)試過程中發(fā)現(xiàn)的 bugs 會(huì)提交到缺陷跟蹤系統(tǒng)中，并對(duì)上一版本中提交的 bugs進(jìn)行回歸測(cè)試。 9. 置為 Later 狀態(tài)的 bugs 研發(fā)人員最好注明什么時(shí)候進(jìn)行修改或是將在哪一個(gè)版本進(jìn)行修改。影響測(cè)試組進(jìn)度的需要給出合理的解釋，影響其他項(xiàng)目測(cè)試進(jìn)度的需要由項(xiàng)目組長(zhǎng)協(xié)調(diào)時(shí)間。對(duì)于描述不清或是不能重現(xiàn)的問題可以直接到測(cè)試人員處詢問或是查看。 2. 每次提交測(cè)試版本時(shí)需要把每次 build版本修改的 bugs、需求發(fā)生變化的功能、模塊或新增功能等以文檔的形式提交測(cè)試人員，可以讓測(cè)試人員知道每次新版本的測(cè)試重點(diǎn) 。 包括以下各種錯(cuò)誤： ? 程序接口錯(cuò)誤 ? 因錯(cuò)誤操作迫使程序中斷 ? 系統(tǒng)可被執(zhí)行，但操作功能無(wú)法執(zhí)行（含指令） ? 單項(xiàng)操作功
公司管理相關(guān)推薦
鄂ICP備17016276號(hào)-1