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