午啪啪夜福利无码亚洲,亚洲欧美suv精品,欧洲尺码日本尺码专线美国,老狼影院成年女人大片

1、財務公司項目文檔及測試管理制度編 制： 審 核： 批 準： 版 本 號: ESZAQDGF001 編 制： 審 核： 批 準： 版 本 號: 第一章 項目文檔和用例管理（一）項目文檔1、項目立項默認提供測試計劃、測試用例、測試過程管理文檔、驗收報告和測試報告五個文檔，默認提交功能測試報告，有性能測試的需求需要在申請測試文檔時注明。性能測試可提供性能測試計劃、性能測試用例、性能測試報告；2、如還需提供其他文檔請在測試文檔申請表詳細寫明，然后發送電子郵件到指定測試人員郵箱并抄送給測試組長，項目交付文檔以申請郵件填寫的申請表內容為準；3、項目測試期間所有與客戶和研發人員的往來郵件都要抄送給直屬上級領2、導；4、每個項目結束要寫總結文檔要對項目的缺陷數量和比例進行統計，分析BUG產生原因，提出改進建議，統計不同BUG所占比例，整理成圖表文檔發送給上級領導；5、每個季度編寫項目總結文檔，對項目的缺陷數量和比例進行統計，分析BUG產生原因，統計不同BUG所占比例，整理成圖表存檔并向上級領導提交報告；（二）項目用例1、所有項目均可以根據項目實際需求在通用用例庫選擇相應的用例執行測試，需要寫補充用例的要及時編寫并錄入通用用例庫。需求不完善的首先跟客戶確認需求、幫客戶設計需求，根據客戶需求制定執行標準。必要時，根據行業通用標準、公司慣例完成測試工作；2、所有用例需要100%執行通過后才算通過；3、 在項3、目中遇到新的測試用例要及時錄入通用用例庫以保證用例庫的更新和完善。所有的項目郵件將作為工作中的重要信息保存直至項目留存封擋之后。刪除舊數據時需要發送郵件請示上級領導，得到許可后方可進行刪除；4、 項目結束整理項目的各項數據并按季度和年度提交上級領導；（三）測試文檔申請和交付標準流程1、項目需求自交付之日起3個工作日內提交測試文檔申請表，該表可以在項目中期追加測試文檔申請，項目起始時間和申請的相關文檔以申請表為準。其他形式的追加文檔一律安排到所有項目的測試工作完成之后提供；2、項目工期提前或延期需提前2周填寫項目延期通知單（表3）或項目工期提前通知單（表4）。經測試人員回復郵件確認項目文檔交付的4、日期，如提交超過一次則按項目負責人最近一次提交的申請單的日期為準。同時研發部項目組長需要給測試文檔的交付預留至少1周的時間；3、項目進行中客戶對需求的修改文檔都要第一時間上傳到版本管理器SVN，并告知更新文檔相關的研發人員，以提高工作效率。需求修改時需要填寫“需求修改確認單”（表5）4、需要做性能測試的項目，需提前確認性能測試需求，需填寫性能測試申請單，并確認測試時間和地點，需提前5個工作日確認；5、確認時間少于5個工作日的一律自行調整項目交接時間，給測試工作和測試文檔撰寫爭取時間；6、如在項目后期需要追加測試文檔，需提前10個工作日提交申請表，無申請表一律不予提供；7、需要外派測試的需要提前5、2個工作日申請，申請郵件中需注明工作地點、乘車路線信息、外派公司接待人聯系方式、外派工位申請、協商好外派公司的行政管理部等相關部門，為外派的同事處理好工作銜接；8、測試文檔已郵件形式發送，每次都要抄送給上級領導和指定關聯人；第二章 測試執行流程及標準一、 測試執行標準流程（一） 角色與職責1、角色與職責角色職責項目經理協調軟件、硬件、人力資源、風險控制、項目進度和質量等；測試經理管理測試相關資源、分配測試工作、風險控制等，對測試工作進度把握和質量監督。協調客戶需求和開發人員的合作；測試組長制定測試計劃、編寫測試用例、執行測試、提交缺陷、回歸測試、編寫測試分析報告、性能測試計劃、性能測試用例、性6、能測試報告、項目總結；測試工程師協助測試組長的工作、對負責的模塊用例進行篩選、確認BUG并提交至缺陷管理系統、指派對應的開發人員修復；測試員執行負責模塊的測試用例，提交缺陷至缺陷管理系統；開發人員修改缺陷、開發人員修改完缺陷后由測試人員進行回歸測試，測試通過則“關閉”缺陷，檢驗未通過，則轉給開發人員，繼續修改；提交缺陷修改程序代碼；提供必要的測試數據；配置管理人員管理測試需要的資源，包括軟硬件環境，版本管理和缺陷跟蹤管理。建立代碼基線，配合進行配置檢查；2、 測試范圍（根據項目實際選擇完成測試類型）系統集成后的功能性測試；l系統集成后的容錯性測試；l系統集成后的界面測試；l系統集成后的常用控件7、測試；l系統集成后的接口測試；l系統集成后的可用性測試；l系統集成后的完整性測試；系統集成后的壓力測試；系統集成后的安全性測試；3、 進入測試條件項目概要設計通過評審；單元測試通過；冒煙測試通過；4、 退出條件缺陷基本修復完畢、系統穩定；測試報告評審通過；項目上線，代碼基線化；線上測試通過；二、測試的準備工作 （1）測試人員在項目的需求階段開始介入，首先仔細閱讀需求文檔，然后跟研發人員一同接受需求的業務培訓，參與需求評審、數據庫評審，從而更全面精準的了解業務流程，針對項目周期安排進行測試工作的計劃； （2）在“需求分析”期間著手編寫測試計劃，直到“概要設計”、“詳細設計”階段，將測試計劃有效的8、編寫完成。同時也篩選用例，將項目用例單獨整理成文當。對需要設計補充用例的模塊進行設計； （3）在軟件的“代碼編寫”期間，完成測試用例的編寫。測試計劃的時間規劃和工作安排要與項目的整體進度吻合。 （4）安排的測試人員要與技術等級、工作量匹配，保證有效的工作進度，必要時采取加班方式增加工作量，為項目完成降低可預見的更多風險； （5）監測需求的變化及時調整測試用例； （6）性能測試指標及方案需要在項目撰寫測試計劃時預估性能測試工作量并預先安排工作時間，根據項目實際情況和客戶需求制定性能測試計劃和測試指標，編寫性能測試報告； 三、測試執行進程（一）需求（1） 參加立項會議，查看需求文檔，接受業務培訓詳9、細了解業務流程。我們是外包公司為客戶提供服務為主營業務。在接受客戶指定項目負責人提供的（以下簡稱客戶）直接的需求文檔，由研發部項目負責人先接受需求培訓，然后組織相項目經理、研發經理、人員、開發人員、環境管理人員、測試人員和其他相關人員進需求評審，確保達成一致意見。對系統連接測試需求分析和集成測試需求分析進行評定，確保系統連接測試需求和系統集成測試需求通過評審。對于內部測試需求分析中導出的內部測試需求，應由研發中心測試組組織相關業務人員、開發項目組進行評審，執行統一標準，形成合作默契。所有評審文檔確認后都要上傳到SVN；在整個項目研發過程中與客戶進行需求變更的細節溝通，項目結束后也要隨時幫助客戶10、解決項目問題，體現人和創建員工的高素質、高服務意識，維護公司的良好形象。另一種是第三方提供需求，除了等同客戶需求的工作之外，要特別注意：第三方對需求的確認狀態和修改次數。不能簡單的、一味的、直接接受第三方的想法，必要時要求對方立即與客戶確認，做好需求的修改記錄。在修改需求時與第三方的文件傳輸要每次都抄送上級和相關負責人，郵件正文中注明郵件目的、傳輸文檔數據屬性和發送原因。所有評審文檔確認后都要上傳到SVN；（2） 單元測試開發人員完成代碼編寫后首先進行單元測試。其中，編寫單元測試計劃，設計單元測試用例、執行單元測試過程、記錄單元測試缺陷、編寫單元測試報告等工作由白盒測試人員完成。根據項目組具體11、情況安排，目前本部開發人員自行完成單元測試，而且不提供任何相關文檔給測試人員。（二）功能測試和性能測試指標 （1）新項目的首次功能測試是從“冒煙測試”開始。新項目交接到測試部，首先進行“冒煙測試”通過后進行功能測試，如測試結果為：“不通過”將不予測試，打回重做。冒煙測試合格的項目基本的功能測試可以使用完整的流程，比如正常使用會員管理系統，可以進行會員注冊、登錄、會員信息修改、退出、管理員查詢、統計、凍結/刪除和修改會員信息等基本功能。期間沒有異常退出系統、掛機、報黃頁、安裝和卸載無異常等主要功能流程可以正常實現。也就是，被測試程序能完整實現基本功能的流程，軟件基本功能正常，可以進行后續的正式測12、試工作。即為冒煙測試通過，反之則沒有通過，不予測試，退回開發項目組負責人。升級版的項目也需要進行冒煙測試，在Web測試和負載測試中，冒煙測試時間短，工作量也小。使用冒煙測試是為了在運行功能測試或壓力測試之前，確保一切都已配置正確并可按預期運行。 （2）冒煙測試用例選擇標準1)新功能版本發布u 測試人員接到新版本后首先需要對新功能進行冒煙測試。冒煙測試主要驗證所提交的功能重點模塊是否按需求開發完、是否進入測試階段、是否可以按照正常測試用例執行測試。選擇主要功能的正常用例做為冒煙測試執行的用例，一般選擇測試用例中優先級別低的用例；2) 含有舊的BUG未修復的新功能版本u 新功能開發完成后，如果依賴13、于某個功能模塊且該功能模塊中存在未修正的BUG，則不接受新版本部署測試。選擇新功能正常測試用例和優先級為“高”級別以上，并且已經修復的BUG做為冒煙測試執行的用例。項目組成員可以用分配好的用戶名和密碼登錄缺陷管理系統實時查看缺陷情況。3）BUG修正版本發布u 選擇優先級為“高”級別以上，并且已經修復的BUG，以及主要功能的正常測試用例做為冒煙測試執行的用例。項目組成員可以用分配好的用戶名和密碼登錄缺陷管理系統實時查看缺陷情況。 （2）功能測試冒煙測試合格可以進行功能測試。項目可以正常運行完整的流程，而且系統沒有A級缺陷，并且能達到系統功能完整度總通過率不低于80%，回歸測試BUG遺留不超過4014、%，才可以進行下一輪測試。否則交由研發部將缺陷修復后重新進行測試。第二輪測試，系統沒有A級、B級和C級缺陷，并且用例通過率不低于90%，回歸測試BUG遺留不超過30%，可以進行第三輪測試。第三輪測試，系統沒有D級以上缺陷，同時用例通過率達到100%，回歸測試BUG遺留不超過3%。集成回歸測試時，如回歸測試全部通過，該項目測試通過，出具測試報告。此時可以著手開展性能測試的工作。首先要達到的普遍標準：1、 通過冒煙測試后的項目才可以確認開始功能測試；2、 確認兼容的系統、瀏覽器版本和環境等信息；3、 準備測試機，搭建測試環境，保證環境正常有效；4、 測試頁面上的：靜態頁面、動態獲取、色差、像素值、15、圖標、圖片、文字、符號、背景、鏈接、留白等是否兼容；5、 將測試結果及時錄入缺陷管理系統，完成缺陷分配信息；6、 完成缺陷分類、圖文并茂的直觀描述BUG，使用語言簡潔準確，內容較復雜時使用排序方式描述，如1，2，3.；7、 測試JS腳本和其他插件是否對系統和環境兼容，基本的彈出窗口是否正常，記錄同上；8、 及時查看缺陷信息，對已經修復的缺陷及時回歸，完成集成回歸測試；9、 界面測試：多窗體、單窗體以及資源管理器風格；其次，參考測試標準文檔：1、 界面測試執行標準；2、 常用基本控件測試用例；3、 通用用例庫4、 測試方案5、 測試計劃6、 測試評審表7、 缺陷報告8、 缺陷統計9、 測試過程管16、理10、 測試報告11、 驗收報告12、 項目操作手冊13、 性能測試需求申請單14、 性能測試用例15、 性能測試報告（3） 軟件性能測試中的性能指標和實施方法各種軟件在系統實施過程中，需要滿足客戶的一些特殊要求。如果軟件系統沒有經過測試和優化，軟件系統將無法滿足用戶的需求，還會給軟件在實際應用中帶來很大的風險。性能測試是整個軟件測試中一個重要方面，能測試軟件的穩定性和承受較大數據量時系統的運行能力。性能測試目的是驗證軟件系統是否能夠達到用戶提出的性能指標，同時發現軟件系統中存在的性能瓶頸，優化軟件，最后起到優化系統的目的。性能測試工程師技能要求： 熟悉軟件測試基本理論； 掌握軟件測試常用方17、法； 熟悉一門編程語言； 熟悉一種數據庫管理系統； 熟悉Web服務器，如IIS、Apache等； 熟悉常見網絡協議，如Http； 掌握性能測試理論； 熟練使用一種性能測試工具； 實際工作中需要的其他技能（性能調優除外）；包括以下幾個方面：1、評估系統的能力，測試中得到的負荷和響應時間數據可以被用于驗證所計劃的模型的能力，并幫助作出決策。2、識別體系中的弱點：受控的負荷可以被增加到一個極端的水平，并突破它，從而修復體系的瓶頸或薄弱的地方。3、系統調優：重復運行測試，驗證調整系統的活動得到了預期的結果，從而改進性能。檢測軟件中的問題：長時間的測試執行可導致程序發生由于內存泄露引起的失敗，揭示程序中18、的隱含的問題或沖突。4、驗證穩定性、可靠性：在一個生產負荷下執行測試一定的時間是評估系統穩定性和可靠性是否滿足要求的唯一方法。定義：性能測試類型包括負載測試，強度測試，容量測試等。負載測試：負載測試是一種性能測試指數據在超負荷環境中運行，程序是否能夠承擔。強度測試： 強度測試是一種性能測試，他在系統資源特別低的情況下軟件系統運行情況。容量測試：確定系統可處理同時在線的最大用戶數觀察指標： 性能測試主要是通過自動化測試工具模擬多種正常、峰值以及異常負載條件來對系統的各項性能指標進行測試。負載測試和壓力測試都屬于性能測試，兩者可以結合進行。通過負載測試，確定在各種工作負載下系統的性能，目標是測試當19、負載逐漸增加時，系統各項性能指標的變化情況。壓力測試是通過確定一個系統的瓶頸或者不能接收的性能點來獲得系統能提供的最大服務級別的測試。軟件方面1、響應時間反映系統處理效率指標響應時間是從開始到完成某項工作所需時間的度量。在客戶/服務器環境中，通常是從客戶方測量響應時間。響應時間通常隨負載的增加而增加。2、吞吐量反映系統處理能力指標吞吐量是單位時間內完成工作的度量，在客戶/服務器環境中通常是從服務器方進行評估。隨著負載的增加，吞吐量往往增長到一個峰值后，然后下降，隊列變長。在如客戶/服務器這樣的端到端系統中，吞吐量依賴于每個部件的運行。系統中最慢的點決定了整個系統的吞吐率。通常稱此慢點為瓶頸。 20、3、 日訪問量 常用頁面最大并發數：分為廣義并發和狹義并發，沒有特定標明一般指廣義并發。可以通俗理解為，在同一個時間點有一批用戶在使用某一功能。當然，同時也有另外一批用戶在使用其他功能。同時在線人數：在某一時間段有登錄操作的用戶，有上傳、下載、支付款項、頁面瀏覽等的所有用戶人數。也可以按照session的個數來決定。響應時間：從發出請求到服務器響應返回到請求頁面的時間。 4、資源利用：率反映系統能耗指標5、創建測試場景、執行場景，根據“測試腳本”，得到“測試腳本運行結果”。測試實施人員根據“測試腳本運行結果”，寫出性能測試報告。第三章 缺陷級別和缺陷狀態定義（一）缺陷級別定義A級 不能完全滿足21、系統要求，基本功能未完全實現；或者危及人身安全。系統崩潰或掛起等導致系統不能繼續運行。包括以下各種錯誤：1. 由于程序所引起的死機,非法退出2. 死循環3.數據庫發生死鎖4.因錯誤操作導致的程序中斷5.重大功能錯誤6.與數據庫連接錯誤7.數據通訊錯誤B級嚴重地影響系統要求或基本功能的實現，且沒有更正辦法（重新安裝或重新啟動該軟件不屬于更正辦法）。使系統不穩定、或破壞數據、或產生錯誤結果，或部分功能無法執行，而且是常規操作中經常發生或非常規操作中不可避免的主要問題。包括以下各種錯誤：1.程序接口錯誤2.因錯誤操作迫使程序中斷3.系統可被執行，但操作功能無法執行（含指令）4.單項操作功能可被執行，22、但在此功能中某些功能（含指令參數的使用）無法被執行（對系統非致命的）5.在功能項的某些項目（選項）使用無效（對系統非致命的）6.業務流程不正確7.功能實現不完整，如刪除時沒有考慮數據關聯8.功能的實現不正確，如在系統實現的界面上，一些可接受輸入的控件點擊后無作用；對數據庫的操作不能正確實現9.報表格式以及打印內容錯誤（行列不完整，數據顯示不在所對應的行列等導致數據顯示結果不正確的錯誤）C級 嚴重地影響系統要求或基本功能的實現，但存在合理的更正辦法（重新安裝或重新啟動該軟件不屬于更正辦法）。系統性能或響應時間變慢、產生錯誤的中間結果但不影響最終結果等影響有限的問題。包括以下各種錯誤：1.操作界面23、錯誤（包括數據窗口內列名定義、含義是否一致）2.打印內容、格式錯誤（只影響報表的格式或外觀，不影響數據顯示結果的錯誤）3.簡單的輸入限制未放在前臺進行控制4.刪除操作未給出提示5.雖然正確性不受影響，但系統性能和響應時間受到影響6.不能定位焦點或定位有誤，影響功能實現7.顯示不正確但輸出正確8.增刪改查功能，在本界面不能實現，但在另一界面可以補充實現。D級使操作者不方便或遇到麻煩，但它不影響執行工作功能或重要功能。界面拼寫錯誤或用戶使用不方便等小問題或需要完善的問題。 包括以下各種錯誤： 1. 界面不規范 2. 輔助說明描述不清楚 3. 輸入輸出不規范4. 長時間操作未給用戶提示5. 提示窗口24、文字未采用行業術語6. 可輸入區域和只讀區域沒有明顯的區分標志7. 必填項與非必填項應加以區別8. 滾動條無效9. 鍵盤支持不好，如在可輸入多行的字段中，不支持回車換行；或對相同字段，在不同界面支持不同的快捷方式10. 界面不能及時刷新，影響功能實現。E級 測試過程中站在用戶角度提出一些易用性，人性化等更利于系統優化的建議。1. 光標跳轉設置不好，鼠標（光標）定位錯誤2. 一些建議性問題。（二）缺陷狀態定義OK： 測試結果無差異NOK：測試結果大部分正確NG： 測試結果有較大的錯誤NT： 由于各種原因本次無法測試redmine缺陷狀態：新建：新發現的BUG等待解決；進行中：正在修復中；已解決：25、已經修改過的BUG等待返測；反饋:經開發人員、需求人員和測試人員等一致同意不需要修復的BUG；已關閉：由于各種原因不再需要進行任何操作的BUG；重新打開：根據實際情況需要，將修復過的BUG再次打開，重新進行修改和測試；復測通過：開發修改后經測試人員測試通過；已投產：已經更新到生產環境，即：已上線；（三）BUG處理原則 當變更BUG狀態時，開發、測試人員需要確認bug表單。（1）測試人員處理原則提交BUG后主動與開發人員溝通，需要以辦公管理軟件、即時通訊工具或郵件通知BUG；BUG描述需要盡量做到清晰、易懂，對于可以重現的BUG開發人員能夠按照描述步驟重現BUG；測試執行中發現BUG直接寫入缺陷26、管理系統的BUG列表中，描述BUG時要將BUG發現步驟描述清楚，還需提供測試數據、系統日志、截圖等有助于開發人員分析、解決BUG的相關數據；填報BUG或者轉給他人BUG是否需要Email通知根據不同項目決定，但是所有轉給產品人員的BUG均需要同步發送Email通知，并保留發送記錄以備日后查詢；（2）開發人員處理原則1.開發人員去除一個BUG，必須修改缺陷管理系統中的缺陷狀態，方便進行回歸測試；2.對于標記為“可重現”的BUG，開發人員必須按BUG描述步驟自己重現BUG，必要時請測試人員配合重現；3.開發、測試人員將一個BUG轉給他人之，必須發郵件給接受人和測試人員進行說明，接受人回復同意交接才27、可繼續；4.Bug的優先級別遵循測試人員的設定；5.任何BUG都不應該被刪除，但可以被置為“拒絕修改”或“關閉”；6.開發人員修復一個BUG后需要在缺陷報告中詳細描述BUG產生的原因及修復的文件；（3）無效BUG定義1.產品定義不明確：如刪除了某會員后該會員登錄系統后是什么狀態沒有定義，而由此產生的BUG則可以選擇此項；2.產品遺留的BUG：如某個項目的升級版本出現BUG，經查是原版本已知的BUG；3.測試人員誤操作：包括但不限于：測試人員需求理解錯誤、測試環境中毒、測試人員技較差、測試人員重復提交已經存在的BUG等引起的BUG；4.需求在報BUG之后發生了變化導致BUG無效；（4）BUG產生28、原因定義1.產品定義不明確，對操作的邏輯定義不完善；產品原有BUG，如：某個項目的升級版本出現BUG，經查是原版本已知的BUG則可以選擇此項；2.粗心大意、單元測試不足、對程序設計語言不熟悉、軟件設計缺陷、未遵從編碼規范、需求理解錯誤、業務知識缺乏；3.由其他BUG引起，如：調用了一段代碼，該段代碼存在BUG，則選擇此項）4.相關系統不兼容引起的BUG；5.無效BUG，如：由于測試人員操作有誤或者由于測試環境出現問題產生的BUG，則選擇測試退出準則（5）新產品測試退出準則1.所有功能均符合用戶需求并已經通過確認；2.BUG趨勢出現明顯收斂狀態達到兩個版本以上。明顯收斂的定義：當前測試版本發現的29、BUG占此項目總BUG數的0%3%，根據項目規模大小不同可以在這個范圍內選擇，但最大不能超過3%；3.測試退出前完成一次執行全部測試用例的回歸測試。對優先級別為“高”BUG回歸；4.測試退出前一個版本的測試定為“穩定期”，在此期間無優先級別為A級、B級的BUG存在；5.測試退出前測試經理主導召開最后一次BUGReview，所有與會人需要簽字確認是否可以退出測試；（6）升級版本測試退出準則1.完全滿足新產品測試退出準則；2.系統當前線上運行版本中的功能、性能未出現新的BUG;(7)Patch（修復BUG）版本測試退出準則1.需要修復的BUG已經修復；2.系統原有版本（指當前線上運行版本）中的功能30、性能未出現新的BUG；3.測試退出前完成一次執行全部測試用例的回歸測試及優先級別為“高”的BUG回歸；注：測試退出前測試經理主導召開最后一次BUGReview，所有與會人需要簽字確認是否可以退出測試；（8）測試執行期間版本發布原則開發人員處理的所有BUG均需要輸入bug列表，修正的BUG需要說明問題發生的原因及如何解決，解決后是否對其他相關模塊有影響；其他狀態的BUG均需要說明理由。1）新功能版本發布按正常發布版本流程發布測試版本。接到新版本測試人員要對新功能進行冒煙測試，主要驗證所提交的功能點是否按需求完成，能否執行測試用例。冒煙測試過程中如出現重大BUG阻礙下一步測試，則冒煙測試不通過，31、不接受測試。待開發人員進行修復后再部署版本進行測試。冒煙測試中執行的測試用例只標示“運行”狀態，不報BUG。執行過程中測試用例如果執行失敗則關聯BUG。2）新功能版本 + BUG修正版本發布新功能開發完成后，如果依賴于某個功能模塊且該功能模塊中存在“未修復”的BUG則不接受新版本部署測試。3）BUG修正版本發布測試執行過程中，在測試人員進行了第一輪測試后，開發人員需要對BUG進行修改，原則上修改BUG達到以下標準后才能發布第二輪測試版本，如遇緊急情況另行處理。l1.高優先級Bug修復要求2.力爭目標：對優先級大于等于C級的BUG需要全部修復；3.最低目標：對優先級大于等于C級的BUG如果不能全32、部修復，則影響到下一步執行測試的BUG必須全部修復；并對不能修復的BUG給予說明。4.低優先級Bug修復要求：對優先級小于C級的BUG需要修復80%。對于不修改或者拒絕的BUG進行說明；不修改的BUG需要項目經理將其置為“Later”狀態。5.除以上情況外“緊急發布情況”需要開發經理提交項目經理與測試經理評估，評估通過后即可發布測試。6.針對不同的開發語言QA做不同的版本發布規則。4）版本發布推進原則測試人員提交BUG后發送Email通知開發人員。開發人員根據BUG優先級進行修復，如遇BUG描述不清及時與測試人員溝通，以保證BUG及時修復。第四章 附表 所有表格和相關文檔上傳至SVN，項目指定33、專人填寫項目測試文檔需求表格并自行下載。請將使用表格單獨復制保存成WORD文檔進行填寫； 項目測試文檔申請表- 表1申請人項目名稱版本號提供項目文檔明細申請測試文檔明細申請日期開始測試日 期結束測試日 期項目負責人項目延期是/否升級版本信 息測試者提醒文檔提交日期文檔提交日期確認提供文檔清單回執日期回執人審核結果備注項目測試文檔接收單-表2（寫完測試文檔，提交給指定負責人的表格）文檔接收者項目名稱版本號項目概況（項目名稱及進度等信息）已接收的測試文檔接收日期升級版本信 息是否延期文檔提交者全部接收（全部接收/部分接收）文檔交接完 畢（是/否）項目測試文檔延期通知單-表3文檔申請者項目名稱版本號34、提供項目文 檔所需測試文 檔延期原因（寫明原因和延長日期）測試確認項目工期提前測試申請單 - 表4文檔申請者項目名稱版本號提供項目文 檔所需測試文 檔提前原因（寫明原因和具體日期）測試確認需求修改確認單-表5需求提供人信息（姓名電話）項目名稱及版本號文檔作者填寫日期必填，精確到幾點幾分，采用24時制模塊名稱模塊詳細修改日期歷史修改更新內容模塊1（填寫模塊名稱）功能數量按鈕個數按鈕功能輸入數據輸出數據預估數據量列表功能備注模塊2（填寫模塊名稱）功能數量按鈕個數按鈕功能輸入數據輸出數據預估數據量列表功能備注模塊3（填寫模塊名稱）功能數量按鈕個數按鈕功能輸入數據輸出數據預估數據量列表功能備注模塊4（填寫模塊名稱）功能數量按鈕個數按鈕功能輸入數據輸出數據預估數據量列表功能備注模塊5（填寫模塊名稱）功能數量按鈕個數按鈕功能輸入數據輸出數據預估數據量列表功能備注模塊6（填寫模塊名稱）功能數量按鈕個數按鈕功能輸入數據輸出數據預估數據量列表功能備注模塊7（填寫模塊名稱）功能數量按鈕個數按鈕功能輸入數據輸出數據預估數據量列表功能備注模塊8（填寫模塊名稱）功能數量按鈕個數按鈕功能輸入數據輸出數據預估數據量列表功能備注模塊9（填寫模塊名稱）功能數量按鈕個數按鈕功能輸入數據輸出數據預估數據量列表功能備注模塊10（填寫模塊名稱）功能數量按鈕個數按鈕功能輸入數據輸出數據預估數據量列表功能備注