測試，只是專案過程中的乙個階段；我們不是軟體的生產者，但是我們是軟體質量的守護者。為了保證我們的產品質量，不能完全依賴於測試，或者依賴於開發；因為產品的質量不是依靠乙個團隊或乙個階段就可以保障的。我們必須在軟體生產的整個流程、每乙個階段進行控制、監管，所以我們提出了「全流程質量保證」。
1. 需求階段：讓bug停留在紙上。
大家都知道測試介入越早越好，因為介入越早，測試人員就可以盡早的了解需求，更深入的理解業務，也可以更早的發現一些問題。尤其是在需求階段，如果能幫助產品提前發現一些需求或流程上的問題，這樣就可以避免後期設計、編碼、測試很多不必要的時間浪費，可以大大降低專案的風險。 據微軟統計，產品發布以後修復乙個問題的成本是150萬美元（間接成本在200萬美元），發布之前的修復成本是5萬，設計階段修復成本是1千，需求階段修復成本是1百。
在京東零售平台，我們都會要求測試人員在需求分析階段就介入，參與與業務方溝通需求中，深入理解需求的背景及目的。然後站在測試的角度分析需求的範圍、重點、可用性、易用性、流程的完整性、異常處理能力等。幫助產品經理提前完善需求，站在測試角度進行需求的補充。盡可能地提前將產品中的遺漏、缺陷、問題暴露，讓需求階段的bug提前發現，提前修復，只停留在需求分析階段，而不會遺漏到編碼或測試階段再去發現、修復。
2. 研發階段 ：讓bug止於搖籃。
研發階段就是把產品進行**實現的階段，乙個產品90%的bug 都是產生在這個階段；按照正常的測試流程，這些bug一般都是在測試階段被發現。但是如果我們能夠在編碼階段就提前發現**中的缺陷，那修復bug的成本以及後續的測試成本都會大大降低。
在京東零售平台，我們是通過這幾種方式來提前發現**缺陷的：
3. 測試階段 ：讓bug無處可藏。
測試階段，也是我們工作最重要的乙個階段。在這個階段系統各個模組都已整合，並部署到測試環境中。我們就需要進行系統的測試，站在使用者的角度，通過專業的測試分析進行用例設計並測試。
在測試階段我們還會分為用例設計、用例評審、冒煙測試、分支測試、主幹測試、聯調測試、回歸測試、使用者驗收測試等不同階段；根據業務型別及業務情況我們會進行功能、效能、相容性、易用性、穩定性、使用者體驗等方面的測試；通過不同階段不同型別的測試，讓bug無處可藏。
但是如果線上發現了問題或待優化的功能，我們每週都會組織線上問題分析會。由產品、研發、測試共同參加，分析問題的根本原因及解決方案，從技術、管理和流程等方面對問題進行分析，以保證同樣的問題後續不再發生。
4. 上線階段 ：線上排查，抓捕漏網之魚。
能夠保證專案的質量，保證專案按時上線，這是對我們的基本要求。如果目標更高，就要求我們能夠投入最少的資源，在最短的時間內完成專案測試，讓專案早日上線，幫助我們的使用者解決問題。我們提公升工作效率是從下面幾方面進行的。
1. 工具輔助：
在測試過程中，所有工作都是由人工進行執行的。但是有些重複性的，或者可以利用**利用機器幫我們實現的工作，我們都會編寫一些測試工具來幫助我們完成，這樣我們就可以解放我們的雙手解放我們的大腦，投入到其他工作中，而且工具永遠也不會感到累，他們執行的速度也會比我們快很多。所以利用工具來輔助我們測試，使我們的效率會大大提高。
當然我這裡說的工具不僅僅指的是一些小的測試工具，還包括我們的ui自動化測試、介面自動化測試、持續整合平台、自動部署、靜態**掃瞄工具等。只要是能夠幫助我們分擔測試工作，提高工作效率的，都是我們的好幫手。
為了提高開發所提交**的可測性，可以讓我們的工具，持續整合、自動化測試等應用到開發環節，幫助開發在**編寫階段進行自測。通過自測，提公升了提測**的可測性，在測試階段就可以減少很多因為**不可測而浪費的時間。
有一些系統，開發擁有自己的測試環境；這樣開發同學在開發過程中就可以充分利用我們的持續整合平台，進行自動部署測試環境，自動執行ui和介面自動化程式，快速反應**合併後的質量。利用我們的工具幫助我們的研發和測試完成持續開發、持續整合、持續測試，讓每一次**的合併都得到有效、快速的質量保障。
2. 流程優化：
作為**研發下的重要部門，零售平台一直注重專案和需求流程規範管理，在京東研發管理體系的基礎上，零售平台內部產品、研發和測試團隊一起對整體流程進行梳理，評審和討論，最終形成適合本部門的質量管理體系。目前這套流程規範已經在零售平台內部進行宣貫和推廣使用。通過規範專案過程和大家的工作流程，減少不必要的溝通成本，力爭一次性把事情做對，從而保證最終產品質量。
首先，我們總結了專案/需求過程的三四五原則，並在整個部門大力推廣，由質量保證人員定期審核專案需求流程規範性，每週以質量週報形式通報結果和改進方向。
三指專案的三大階段需求、研發、測試階段，每個階段都有明確的活動及產物定義；四是四次主要評審需求、設計、**和測試用例評審，要求專案組全體成員參與，力爭在專案前期將問題暴露出來並解決；五指的是五大主要文件，包括需求文件、設計文件、測試用例、測試報告、線上驗證報告，專案組嚴格按照該原則要求，在每乙個階段完成時，完成本階段的活動，並提交相關產物，從而確保後續工作順利開展。
同時，將流程規範與系統相結合，通過tip（測試整合平台）實現流程的自動化：
以tip測試整合平台為核心，我們已經通過與pmp專案管理系統、jone統一工作平台、source**共享平台相互協同，實現需求管理，研發管理，測試管理等相關活動流程化、標準化和自動化。目前已實現研發線上提測、測試人員傳送測試報告，研發人員傳送自測報告等功能，給研發和測試人員的日常工作帶來極大效率提公升，同時通過系統及時儲存了珍貴的專案/需求過程資產。另外測試階段可通過工作流的形式，通過可配置化任務將編譯、打包、部署、測試等任務組合起來，實現一系列持續整合流程，每天定時執行，定時反饋，極大的提高了測試人員的效率。tip平台功能仍在不斷完善和豐富，為不斷提公升零售平台整體質量水平，我們一直在不懈努力。
京東零售測試團隊之全流程質量保證
提到 碼農 提到 程式猿 大家都非常熟悉。但是提到 測試，很多人都只是聽過，但並不太清楚測試人員到底是做什麼的 即使每天跟測試人員接觸的 程式猿 他們看到的也只是我們在寫用例，我們在手工測試，我們在提bug，我們在發報告。其實他們所看到的這些 工作也只是我們的一部分，或者只是我們其中的乙個角度。不同...
測試質量保證的思路
我所理解的從哪些方面保證質量，歡迎給建議。分層質量管理 資料層 層 測試範圍 流程約束 發版標準 監控告警 5w1h原則 在任何場景下，組織一場活動也好，制定乙個商業計畫書也好，5w1h原則都是需要適用的，自然在測試方案的制定上也能夠適用。how 如何去測？用什麼資源？依據什麼？工具如何選型 案例要...
軟體質量 軟體測試和質量保證
軟體質量 軟體質量包括 內部質量 外部質量 使用質量 就是說軟體滿足規定或潛在使用者需求的能力，要從軟體在內部 外部和使用中的表現來衡量 軟體測試 軟體由文件 資料以及程式組成，那麼軟體測試就應該是對軟體形成過程中的文件 資料以及程式進行測試，而不僅僅是對程式進行的測試。軟體測試和質量保證的區別 軟...