qileilove

          blog已經轉移至github,大家請訪問 http://qaseven.github.io/

          軟件項目管理實踐之如何實施質量控制?

            質量控制包括對項目管理過程績效和項目可交付成果的質量控制。質量控制主要通過文檔評審、技術評審、代碼走查和測試檢查實現。

            一、技術評審

            技術評審包括技術文檔評審、技術實現評審和代碼走查。

            1、文檔評審

            實施過程前期產生的需求規格說明書、系統設計說明書、測試用例等文檔是后期編碼、測試的主要依據和輸入,這些文檔的質量直接決定了軟件系統的好壞、系統返工的多寡以及客戶滿意度。因而對這些文檔的評審尤為重要,評審的目的在于在交付給下游開發或測試時及早發現問題,修正錯誤,以免問題和錯誤在系統中的蔓。

            文檔評審采用同行評審會議的方式進行,由項目經理組織,開發相關文檔參與的角色包括其他子系統的系統分析員、質量控制部相關人員、其他兄弟部門有類似經驗的系統分析員等;測試相關文檔則由項目經理、測試經理、系統分析員和其他測試人員參與。評審過程中,主要從以下幾方面考察文檔的質量:

            ● 可讀性。主要從文檔是否符合公司模板規范、邏輯結構層次是否清晰明確、文字表達是否無歧義等方面判斷;

            ● 完整性。主要從文檔是否完全滿足要求,是否已覆蓋所有的功能點等方面判斷;

            ● 一致性。主要判斷文檔表述是否前后不一、是否有矛盾等;

            ● 技術可行性。主要判斷目前的技術框架是否支持,是否有類似的經驗,是否有技術風險等。

            2、技術實現評審

            技術實現評審包括項目技術框架選型評審、具體某個模塊的技術實現方法評審。技術框架的評審目的是為了在進入大規模編碼開發前確認選擇何種技術框架、判斷現有的技術框架是否滿足項目功能和性能需求、框架是否足夠穩定以及可能存在的風險等;具體某個模塊的技術實現方式評審目的是為了保證選擇的實現方式目前來說是最優的、可以推廣到其他模塊使用的。技術評審通過評審會議的方式進行,參與的人員包括項目經理、系統分析員、開發人員、公司內部相關技術的專家、有同類項目經驗的實施人員、質量控制人員等。

            3、代碼走查

            代碼走查主要是對軟件代碼進行復審,主要以高級程序員復審代碼或同級別的程序員交叉檢查的形式進行。代碼走查的目的是通過抽查,保證代碼的編寫和注釋符合編碼規范,編碼邏輯符合系統設計要求,減少測試返工以及因測試返工引起的來回溝通、回歸測試等問題,降低管理成本,提高開發效率。

            二、測試檢查

            測試檢查是由測試人員根據測試用例對軟件產品進行功能測試以及使用壓力測試工具對系統進行壓力測試。測試檢查的目的是確保交付給客戶執行驗收測試前軟件產品經內部嚴格測試,檢查系統是否滿足用戶需求和符合實際應用環境的需要,從而增強客戶對項目成功的信心。

            我們定義了五個測試檢查過程,包括單元測試、集成測試、系統測試、客戶驗收測試以及確認缺陷已正確修復的回歸測試。

            單元測試由開發人員自行負責,測試通過標準由系統分析員制定,測試團隊核準,確保開發人員在提交代碼前在本地已經過測試,主流程可以跑通,可以進入集成測試階段。主要目的是通過自查自糾減少返工以及降低后續測試階段中開發人員與測試人員之間的來回溝通成本。

            集成測試由系統分析員負責,通過集成開發人員提交的代碼,利用Ant等自動化工具發布到測試環境。系統分析員選取典型的測試用例對軟件產品進行測試,確保業務模塊在操作過程中沒有出現重大的業務邏輯錯誤以及頁面方面的低級錯誤,可以提交到測試團隊進行進一步的深入測試。測試過程如出現問題,進一步分析產生原因和影響分析后提交到JIRA系統中交由開發人員處理,同時在JIRA系統上進行缺陷跟蹤。

            系統測試由測試團隊負責,依照經過評審的測試用例對已發布可用于測試的軟件產品進行全面的功能性測試,確保系統滿足功能需求。測試過程中,發現的問題連同問題出現時的系統截圖一并提交到JIRA系統中,由系統分析員分析后轉由開發人員實施缺陷修復,同樣的,在JIRA系統中進行缺陷跟蹤。

            客戶驗收測試由客戶需求負責人負責,測試團隊配合完成。測試的過程也是對客戶系統操作培訓的過程,必要時,由系統分析員給客戶演示和解釋。客戶需求負責人往往是業務骨干,精通業務規則,熟悉業務流程和操作,可以對系統進行更深入的功能測試,發現隱藏較深的缺陷或者因為考慮不周引致的設計缺陷。

            回歸測試由測試團隊負責,根據JIRA系統上的缺陷修復狀態,對已包含缺陷修復的版本進行驗證測試。測試過程不單是對缺陷修復進行驗證,同時對因修復缺陷影響到的其他模塊進行回歸測試,確保缺陷被正確修復的同時不影響原有模塊以及不引入新的缺陷。由于回歸測試的工作量很大,我們使用QTP工具,通過錄制測試腳本,使回歸測試可以自動化執行,減輕測試團隊的負擔,提高工作效率。

            每周的測試情況以測試周報的形式體現,周報內容包括測試范圍、測試過程中遇到的問題以及解決方法等。另外,周報還報告了缺陷的統計信息,包括缺陷總數(其中:本周新增的缺陷)、已關閉的缺陷總數(其中:本周關閉的缺陷)、已處理但未關閉的缺陷總數、正在處理的缺陷總數以及未處理的缺陷總數。通過這些信息基本上可以看出軟件系統的缺陷趨勢,從而為后續的決策提供量化支持。

            測試發現的缺陷我們使用JIRA系統進行跟蹤和監控。測試人員在系統上提bug,由相應的系統分析員負責對缺陷進行原因分析和影響分析,必要時與程序員一起確認問題產生的原因和可能影響的模塊,分析后轉交由相應的開發人員進行修改,缺陷修復并經單元測試后發布到測試環境交由測試人員進行驗證測試并關閉此問題,最后由客戶進行驗收測試后并確定發布版本和發布時間后予以發布。在這個流程中,測試人員驗證測試時需要對該缺陷涉及的本模塊其他功能和其他模塊進行一輪回歸測試,確保已修復的缺陷不再重復產生,其他功能不受影響。

            另外,為了確保已發現的缺陷不再重復出現,對于頻繁出現的,如界面顯示的是代碼而非中文、缺乏信息提示、沒有進行邏輯檢查、后臺計算結果有誤等缺陷進行進一步的分析,找出是因為系統設計文檔的缺陷、人為疏忽還是沒有按照設計文檔設計或其他原因所導致,從而制定相應的改進措施。

          posted on 2011-11-22 17:16 順其自然EVO 閱讀(464) 評論(0)  編輯  收藏 所屬分類: 管理方向

          <2011年11月>
          303112345
          6789101112
          13141516171819
          20212223242526
          27282930123
          45678910

          導航

          統計

          常用鏈接

          留言簿(55)

          隨筆分類

          隨筆檔案

          文章分類

          文章檔案

          搜索

          最新評論

          閱讀排行榜

          評論排行榜

          主站蜘蛛池模板: 嘉祥县| 驻马店市| 抚顺县| 仁化县| 寻乌县| 通榆县| 曲靖市| 潞城市| 焦作市| 潢川县| 湛江市| 镇平县| 汶川县| 潮州市| 九龙坡区| 大方县| 文山县| 商水县| 云霄县| 丹东市| 息烽县| 邵阳市| 唐海县| 泌阳县| 星座| 邛崃市| 万全县| 芦山县| 彩票| 隆回县| 镇巴县| 康平县| 惠安县| 九寨沟县| 兰西县| 尚志市| 夏津县| 揭阳市| 永胜县| 田林县| 余庆县|