一個(gè)產(chǎn)品的質(zhì)量是這個(gè)產(chǎn)品的靈魂。

不能在最后才開始做測試

很多時(shí)候人們理所應(yīng)當(dāng)覺得測試應(yīng)該在項(xiàng)目的最后階段進(jìn)行，但是這樣的策略存在以下缺點(diǎn)：

• 很難改進(jìn)現(xiàn)有產(chǎn)品質(zhì)量
• 在測試之前一直有錯(cuò)誤，但是未被發(fā)現(xiàn)
• 項(xiàng)目的狀態(tài)難以測量，一次性發(fā)現(xiàn)的大量錯(cuò)誤難以估計(jì)修復(fù)時(shí)間
• 錯(cuò)失反饋時(shí)機(jī)
• 因?yàn)楹笃诘捻?xiàng)目壓力，測試可能會(huì)被削減

所以我們需要利用Scrum將測試融入在整個(gè)項(xiàng)目的行進(jìn)過程當(dāng)中。這樣進(jìn)行的項(xiàng)目有如下特點(diǎn)：

• 程序員和測試人員之間每天都會(huì)打交道，不存在“交接”的說法，這樣一起工作的團(tuán)隊(duì)更有協(xié)作能力，同時(shí)大家可以一同討論項(xiàng)目的趨勢。
• 在Sprint的第一天和最后一天有著同樣多的測試活動(dòng)。

自動(dòng)化測試

這里要提到一個(gè)自動(dòng)化測試的金字塔模型，從下到上分別是：單元測試，服務(wù)測試，UI測試。分別對應(yīng)我們項(xiàng)目當(dāng)中的UT，IT以及NightWatch測試。

單元測試

單元測試是整個(gè)自動(dòng)化測試的一大基石，非常重要。它不但能夠保證最小粒度上代碼的正確性，而且效率非常高。我們的經(jīng)驗(yàn)是，一個(gè)產(chǎn)品的初期可能會(huì)花費(fèi)相對大量的時(shí)間寫UT代碼，并且效果并不是很明顯。但是隨著產(chǎn)品的增強(qiáng)，項(xiàng)目的進(jìn)行，初期所寫的單元測試將會(huì)發(fā)揮巨大的作用。

服務(wù)測試

即對應(yīng)我們項(xiàng)目當(dāng)中的IT測試，是針對整個(gè)服務(wù)進(jìn)行的測試，程序員編寫測試代碼直接對于服務(wù)的功能進(jìn)行測試。這樣做的測試能夠直接驗(yàn)證服務(wù)的正確性，并且成本較低。

UI測試

書中提到UI測試應(yīng)當(dāng)適當(dāng)少的進(jìn)行（不是盡量少）。因?yàn)閁I測試相對于服務(wù)測試具有以下缺點(diǎn)：

• 脆弱，因?yàn)楣δ艿男「膭?dòng)可能給UI測試代碼帶來巨大改動(dòng)。
• 成本高，相對于服務(wù)測試，UI測試代碼確實(shí)需要更多的時(shí)間去寫。
• 耗時(shí)，運(yùn)行一次UI測試往往需要更多的時(shí)間。

從我們項(xiàng)目的經(jīng)驗(yàn)來看，UI測試確實(shí)存在以上的問題。但是在大家做總結(jié)的時(shí)候發(fā)現(xiàn)UI測試其實(shí)是必不可少的，因?yàn)闀械挠^點(diǎn)只是試圖通過UI測試發(fā)現(xiàn)服務(wù)端有哪些Bug。但是我認(rèn)為UI測試另外一個(gè)非常重要的功能（可能是最重要的功能）就是保證UI的功能的正確性。實(shí)踐中我們覺得UI測試確實(shí)起到了這樣的作用。

手工測試

自動(dòng)化測試并不能覆蓋所有的測試點(diǎn)，而且有些時(shí)候自動(dòng)化測試比手工測試成本更高。手工測試應(yīng)主要作為探索性測試。另外在一個(gè)Sprint當(dāng)中，開發(fā)出來的新功能應(yīng)進(jìn)行手工測試。

技術(shù)債務(wù)

技術(shù)債務(wù)指的是在開發(fā)過程中，如果出現(xiàn)了不良的設(shè)計(jì)或?qū)崿F(xiàn)，則是“欠債”。后面需要一些時(shí)間精力來修復(fù)，即“還債”。
并不是所有的技術(shù)債務(wù)都是不好的。比如說在項(xiàng)目快要交付的時(shí)候，有時(shí)候?yàn)榱诵薷囊粋€(gè)問題可能會(huì)引入稍欠考慮的實(shí)現(xiàn)，但是這樣的技術(shù)債務(wù)是利大于弊的。但是對于所有的債務(wù)，應(yīng)當(dāng)盡快的解決。“只要快速的歸還，小的債務(wù)可以加速開發(fā)”。