4、Drive quality upstream
我們都知道bug越是滯后發(fā)現(xiàn)，修復(fù)的成本越高。據(jù)微軟統(tǒng)計(jì)，如果產(chǎn)品發(fā)布以后需要發(fā)布一個(gè)熱修復(fù)，它的直接成本是150萬美元（間接成本在200萬美元），而在發(fā)布之前的一個(gè)月發(fā)現(xiàn)的話，修復(fù)成本是5萬，設(shè)計(jì)階段修復(fù)成本是1千，需求階段修復(fù)成本是1百。在需求分析階段，測(cè)試人員主要職責(zé)就是驗(yàn)證需求分析的可行性和可靠性。PM和DEV的共性是易于樂觀，傾向于把實(shí)際情況簡(jiǎn)單化，所以會(huì)作出很多假設(shè)。比如用戶肯定不會(huì)這么使用，用戶肯定知道如何用，所有用戶的環(huán)境肯定都有該配置。但是實(shí)際情況下總會(huì)有用戶不知道如何用，總會(huì)有用戶會(huì)不按“預(yù)先設(shè)計(jì)”的方式使用，總會(huì)有用戶環(huán)境沒有該項(xiàng)配置。所以測(cè)試人員的主要職責(zé)就是找出這些假設(shè)并提出疑問并加以驗(yàn)證。
在dev設(shè)計(jì)階段，測(cè)試人員需要驗(yàn)證設(shè)計(jì)，同樣找出dev的假設(shè)然后疑問這些假設(shè)是否合理，看看該設(shè)計(jì)是否處理很多沒有預(yù)料的但是有可能會(huì)發(fā)生的情況，比如用戶輸入特殊字符，非常規(guī)操作，非常規(guī)流程，機(jī)器重啟，死機(jī)，數(shù)據(jù)庫(kù)連接中斷，網(wǎng)絡(luò)中斷，內(nèi)存耗盡等等。除了驗(yàn)證設(shè)計(jì)是否處理非正常情況外，測(cè)試人員的另外一個(gè)更為重要的職責(zé)是驗(yàn)證設(shè)計(jì)的可測(cè)試性。可測(cè)試性是指測(cè)試軟件容易的程度。軟件的可測(cè)性對(duì)于提高軟件的質(zhì)量至關(guān)重要。道理很簡(jiǎn)單，如果你的軟件很難測(cè)試，無從下手，測(cè)試一個(gè)用例需要幾個(gè)小時(shí)甚至幾天的話，你的軟件質(zhì)量也就無從保證。提高軟件可測(cè)試性通常的做法是把軟件模塊化，松耦合，模塊內(nèi)部運(yùn)行狀態(tài)可見，模塊內(nèi)部運(yùn)行分支可控制。在評(píng)審一個(gè)設(shè)計(jì)時(shí)通常問的問題是該如何測(cè)試該模塊，是否容易測(cè)試它，能不能單獨(dú)測(cè)試它。如果不可以的話，需要重新考慮設(shè)計(jì)。因?yàn)橐粋€(gè)設(shè)計(jì)的很容易測(cè)試的模塊和產(chǎn)品可以使得后期的測(cè)試代價(jià)大大降低。微軟大部分復(fù)雜系統(tǒng)都會(huì)有一個(gè)“one-box”版本，該版本是個(gè)假的模擬系統(tǒng)但是擁有真正系統(tǒng)的幾乎所有功能，它可以運(yùn)行在任何機(jī)器上。系統(tǒng)的絕大部分功能都可以在該模擬系統(tǒng)上快速方便驗(yàn)證。我在培訓(xùn)的時(shí)候很多學(xué)生問？？他們?cè)诤笃跍y(cè)試的時(shí)候遇到許多無法測(cè)試或者很難測(cè)試的困境，問我該如何解決。在具體了解困難和困境之后，我發(fā)現(xiàn)他們的測(cè)試策略非常單調(diào)，只能把產(chǎn)品部署到有限的測(cè)試環(huán)境下從用戶界面上做端到端的測(cè)試。如果想測(cè)試某個(gè)特定模塊或功能需要好幾個(gè)其它模塊配合起來才可以。我就坦率的說如果你的軟件是這么架構(gòu)設(shè)計(jì)的話而且已經(jīng)到了這一步，世界上沒有人可以解決你現(xiàn)在面臨的困難。因?yàn)榭雌饋砗孟衲闶强ㄔ诂F(xiàn)在這一步了，但實(shí)際上根本問題是在前期，在需求或設(shè)計(jì)。就像解決河流的水質(zhì)污染問題，你在下游無論多大的代價(jià)也只能稍微改善，解決問題的根本方法是在解決上游的污染源。或者像隔靴撓癢，隔著厚厚的靴子無法撓到關(guān)鍵地方，必須能夠把靴子脫掉直接撓。
5、Getting better every day
軟件測(cè)試的目的一個(gè)是找出bug，另外一個(gè)是衡量軟件的質(zhì)量。通過測(cè)試來了解產(chǎn)品哪些地方薄弱，哪些地方不穩(wěn)定. 通過監(jiān)控測(cè)試的結(jié)果，包括功能測(cè)試，性能壓力測(cè)試，安全測(cè)試，本地化測(cè)試，容錯(cuò)測(cè)試等等來反映當(dāng)前軟件的質(zhì)量。這也是持續(xù)集成的一個(gè)重要原因，它一方面短期迭代，另一方面可以在最短的時(shí)間內(nèi)知道軟件的質(zhì)量，同時(shí)跟蹤軟件質(zhì)量重開始到發(fā)布，軟件質(zhì)量的變化曲線。衡量軟件質(zhì)量的通常指標(biāo)有：測(cè)試用例通過率/趨勢(shì)，bug數(shù)量，種類/趨勢(shì)，代碼覆蓋率等等。另外測(cè)試在開發(fā)周期中通常做的其它工作還有：bug root cause analysis，Bug analysis，Testcase failure analysis， test gap analysis，Bug talk，bug share，CCS data analysis等等。這一方面促使產(chǎn)品質(zhì)量逐漸變好，而且是看得見的好。另外也促使自己放下繁忙的工作靜心思考一下，如何更有效率更進(jìn)一步提高質(zhì)量。
6、Engineering agility
隨著軟件即服務(wù)和云計(jì)算的興起，它們給開發(fā)管理，質(zhì)量管理，運(yùn)營(yíng)管理等提出了很多新的挑戰(zhàn)。以前那種保密開發(fā)測(cè)試2－3年再突然發(fā)布的策略無法適應(yīng)互聯(lián)網(wǎng)應(yīng)用服務(wù)的要求，而是逐漸演變成快速開發(fā)出產(chǎn)品基本原型，然后就發(fā)布，根據(jù)用戶反饋不斷加以改進(jìn)的方式。質(zhì)量管理方面，基于服務(wù)的產(chǎn)品除了關(guān)注功能性能，還有其它特別重要的方面，比如scalability， high availability， fault tolerance， disaster recovery， etc.. 這些都是桌面型產(chǎn)品所沒有的或不重視的。微軟從2010年開始在很多組開始實(shí)踐如何提高服務(wù)型產(chǎn)品的質(zhì)量，比如Azure， Bing， etc…。其中最為根本的一點(diǎn)就是提高整個(gè)團(tuán)隊(duì)的敏捷度，團(tuán)隊(duì)能夠跟的上快速迭代交付的節(jié)奏。這需要從產(chǎn)品設(shè)計(jì)上到測(cè)試自動(dòng)化，工具，基礎(chǔ)設(shè)施上得以保障。另外一個(gè)非常重要的實(shí)踐就是TiP （test in production） 或 crowd-sourced testing. 我們?cè)谇懊嬲劦?#8220;drive quality upstream”，也即是提前測(cè)試。test in production正好相反是“drive quality downstream”，也即是在產(chǎn)品環(huán)境中測(cè)試。傳統(tǒng)的桌面產(chǎn)品發(fā)布之后就不再測(cè)試了。服務(wù)型產(chǎn)品，產(chǎn)品發(fā)布后繼續(xù)測(cè)試。它的基本出發(fā)點(diǎn)是：無論投資多少建立測(cè)試環(huán)境用以模擬產(chǎn)品運(yùn)行環(huán)境，測(cè)試環(huán)境和真正產(chǎn)品環(huán)境總會(huì)有不同。無論花費(fèi)多大的代價(jià)做前期測(cè)試，都不可能找出所有的bug。所以無論在發(fā)布之前花費(fèi)多大的代價(jià)做測(cè)試，在產(chǎn)品上線后總會(huì)發(fā)現(xiàn)新的bug。現(xiàn)在既然發(fā)布產(chǎn)品更新非常快和容易，為什么不干脆在真正產(chǎn)品環(huán)境中來測(cè)試，或者利用真正的用戶使用真正的產(chǎn)品來測(cè)試（當(dāng)然用戶意識(shí)不到）。一旦發(fā)現(xiàn)bug，馬上修復(fù)，馬上更新。這不僅減輕了前期測(cè)試的投入，而且提高的測(cè)試效率。看看我們?cè)跍y(cè)試環(huán)境中發(fā)現(xiàn)的bug有多少?zèng)]有被認(rèn)為是“真正”的bug就明白了。當(dāng)然要做到test in production， 需要很多具體的流程、技術(shù)，工具作為保障。不能影響用戶的關(guān)鍵業(yè)務(wù)，不能讓用戶發(fā)現(xiàn)過于簡(jiǎn)單的bug。 除了基本的測(cè)試自動(dòng)化基礎(chǔ)設(shè)施和測(cè)試用例外，常用的一些TiP技術(shù)有：A/B testing，expose control/slicing model，on/off features，chaos-monkey，measuring/monitoring.
最后一篇將和大家討論一下測(cè)試工程師的技能提高和職業(yè)發(fā)展，to be continued .....
相關(guān)鏈接：