软件质量控制
1、質量控制
軟件質量控制對開發過程中的軟件產品的質量特性進行連續的收集和反饋，通過質量管理和配置管理等機制，使軟件開發過程向著既定的質量目標發展。質量控制是質量管理的的路標和動力，質量管理是質量控制的執行機制。
問題1：軟件質量控制應該注意哪些方面？
建議：
（1）在整個軟件生命周期中都該進行質量控制；
（2）不同階段活動不同，應采用不同的技術；
（3）綜合使用“預防性”和“檢測性”技術。
問題2：軟件質量控制技術有哪些類型？
建議：
（1）預防性技術：通過為過程、產品和資源設立標準等途徑，來避免在產品開發過程中產生缺陷；
（2）檢查性技術：用于發現和糾正缺陷，甚至分析產生缺陷的原因。
問題3：軟件質量控制一般有哪些方法？
建議：
（1）目標問題度量法：通過確定軟件質量目標并連續監視這些目標是否達到來控制軟件質量；
（2）風險管理法：設別和控制軟件開發過程中對軟件質量危害最大的因素；
（3）PDCA質量控制法：PDCA是一個基于統計方法的迭代過程，已被作為國際標準。
問題4：軟件質量控制的準則有哪些？
建議：
（1）制定明確的改進質量目標，滿足客戶需要；
（2）持續改進過程以提高質量和生產率，降低成本；
（3）消除恐懼，讓員工更有效地工作；
（4）消除領域障礙，建立團隊精神；
（5）不以口號要求零缺陷、高效率；
（6）進行培訓，為所有人建立學習和自我提高機制。
2、質量目標
為了達到質量控制，測試團隊不但需要明確軟件的功能，還要明確軟件應達到什么樣的質量標準，即制定軟件的質量目標。為了達到這些目標，在開發過程的各個階段進行檢查和評價。在質量評價時，需要有對質量進行度量的準則和方法，但更重要的是，需要在軟件生存期中如何使用這些準則和方法的質量保證步驟及提高該項作業生產率的工具。
問題1：制定合理的質量目標需要從哪些方面考慮？
（1）適應性：必須制定能適應各種用戶要求、軟件類型和規模的質量標準，并能夠度量；
（2）易學性：不需要特殊技術，軟件技術人員人人都容易掌握；
（3）可靠性：對同一個軟件的評價，評價的人或場合可能不同，但評價結果必須一致；
（4）針對性：不是在檢查時才改進質量，而必須從設計階段起就確立質量目標，在各個階段實施落實；
（5）客觀性：要從各種不同角度加以評價，并將評價結果定量地表示，使得人人都能理解；
（6）經濟性：考慮如何才能把質量度量和保證所需要的費用控制在適當的范圍內。
問題2：測試團隊，需要重點關注哪些質量指標？
建議：
（1）測試設計覆蓋率
（2）測試執行覆蓋率
（3）各階段缺陷密度
問題3：測試過程中，需要關注哪些測試缺陷密度？
建議：
（1）測試計劃評審缺陷發現密度
（2）測試策略/方案評審缺陷發現密度
（3）測試用例評審缺陷發現密度
（4）系統測試缺陷發現密度
（5）集成測試缺陷發現密度
（6）驗收測試缺陷密度
3、同行評審
在軟件開發過程中邀請同行對工作產品進行審查，以圖盡早查找出工作產品缺陷，進行質量控制的一種質量活動。需要前期準備、計劃，安排好時間進度表，而且越早開展對項目越有價值。
問題1：常見的評審有哪些形式？
建議：
（1）審查：由公正的、接受過正式評審技術培訓的組織者引導進行的同行檢查；
（2）走查：又稱走讀，由產品的設計者或開發人員引導開發組成員和其它相關組成員瀏覽軟件工作產品；
（3）分發：又稱輪查，產品的設計者或開發人員將要評審的工作產品共享或分發，評審人員以修訂標記或批注的方式將意見直接添加到工作產品或其復件上。
問題2：評審過程中常見的問題？
建議：
（1）項目進度緊張，開發人員沒有時間進行評審；
（2）評審力度不夠，評審發現的有效問題太少；
（3）評審會議中過多爭論占用大量時間；
（4）評審專家與作者，或者多位評審專家之間的評審意見不一致；
（5）評審發現問題修改后，評審人員跟蹤不充分。
問題3：項目進度緊張，專家沒有時間進行評審怎么辦？
建議：
（1）將評審活動的時間、需要的評審專家寫入項目計劃；
（2）通過“正式渠道”協調評審專家資源，并得到承諾；
（3）評審開始前提前1-2天通知評審專家。
問題4：如何可以提高測試評審的效果，達到預期的效果？
建議：
（1）評審前可以使用Checklist、代碼檢視工具等進行自檢活動；
（2）考慮知識結構、觀點角度等方面，選擇合理評審專家；
（3）必要時安排介紹會議，向相關專家介紹被評審對象；
（4）充分安排好足夠預審時間。
4、漏測預防
漏測是指軟件產品的缺陷在某一階段未被發現而遺漏到了后續階段、經效果評估后，將有效的預防措施納入到流程或相關預防平臺中，制定改進措施和跟進實施。
問題1：哪些環節容易發生漏測？
建議：
（1）需求分析，如需求分析遺漏、需求分析特性理解錯誤、需求變更未及時跟蹤；
（2）策略漏測，如組網考慮不全面、繼承特性考慮不全、性能穩定性考慮不全面；
（3）設計漏測，如用例描述不規范準確、用例觀察點遺漏、功能交互遺漏、異常考慮不全面等；
（4）執行漏測，如用例執行構造數據不全面、沒有嚴格按步驟執行用例、測試技能或經驗不足等。
問題2：漏測分析需要做哪些工作？
建議：
（1）選擇問題，選擇有代表性的漏測問題；
（2）分析根因，進行漏測問題的根因分析；
（3）改進實施，制定改進措施并跟進實施；
（4）補充測試設計，共性問題要跟蹤多版本閉環；
（5）成果固化，經效果評估后，將有效的預防措施納入到流程或相關預防平臺中。
問題3：有哪些方法，可以進行漏測預防？
建議：
（1）測試策略和測試方案充分考慮各業務邏輯之間的交互和影響；
（2）測試用例設計時，充分考慮功能點與其他模塊之間的交互和影響；
（3）充分考慮修改問題單、需求變更是否引入新的問題；
（4）參考優秀實踐和經驗案例；
（5）每次缺陷分析完要有總結，把容易漏測的形成測試經驗checklist，并組織學習。
5、發散測試
發散測試，顧名思義就是不以某個標準或者框框作為約束的一種測試，發散測試準確來說應該叫具備發散思維的探索性測試。為了提高測試執行覆蓋率，在嚴格按照用例測試執行后，通常需要進行發散測試，這里包括自由測試和交叉測試。
問題1：發散測試，需要關注哪些方面？
建議：
（1）重點模塊和核心流程，需要安排多人進行交叉測試；
（2）根據2/8原則，對發現缺陷高的模塊，需要重點安排人力交叉測試；
（3）了解用戶場景，按照用戶常常使用的實際場景進行發散測試；
（4）識別異常場景，模擬可能發生的各種異常場景進行發散測試；
（5）遵循規范原則，根據規范組織測試，如協議規范、設計規范和接口規范等。
總結
- 上一篇： Duplicate entry 'san
- 下一篇： velo2cam_calibration