1.1.4 測試左移的進(jìn)階實(shí)踐

為了系統(tǒng)性解決軟件測試工程化的困局，我們需要重新審視測試左移的原則與實(shí)踐，在原有測試左移實(shí)踐的基礎(chǔ)上加入新的原則和實(shí)踐。新時(shí)代的測試左移給整個(gè)軟件測試體系帶來了理念上的轉(zhuǎn)變，軟件測試不僅僅是在研發(fā)過程中發(fā)現(xiàn)缺陷，更要致力于在研發(fā)全過程中有效推行質(zhì)量內(nèi)建，把軟件測試活動(dòng)升級為軟件質(zhì)量工程。為此，我們需要引入以下測試左移的原則和實(shí)踐。

1.軟件質(zhì)量全員負(fù)責(zé)制

軟件質(zhì)量全員負(fù)責(zé)制也可以稱為“利益綁定”，這是很關(guān)鍵的一條原則，屬于底層邏輯的范疇。在體制設(shè)計(jì)上，必須讓整個(gè)研發(fā)團(tuán)隊(duì)共同對軟件產(chǎn)品質(zhì)量負(fù)責(zé)，畢竟軟件質(zhì)量不是測出來的，而是開發(fā)出來的。如果軟件質(zhì)量出現(xiàn)問題，應(yīng)由整個(gè)研發(fā)團(tuán)隊(duì)共同負(fù)責(zé)，而不是讓測試團(tuán)隊(duì)“背鍋”，這種認(rèn)知上的進(jìn)步與變革是測試左移能夠順利推行的基本前提。

我們知道，保姆型團(tuán)隊(duì)對組織成長是有害的，只有支持型團(tuán)隊(duì)才能夠發(fā)揮更大的價(jià)值，從而推動(dòng)組織更好地成長。當(dāng)軟件質(zhì)量由整個(gè)研發(fā)團(tuán)隊(duì)共同負(fù)責(zé)的時(shí)候，測試團(tuán)隊(duì)就能完成從保姆型團(tuán)隊(duì)向支持型團(tuán)隊(duì)的蛻變。

2.把測試前置到需求分析和方案設(shè)計(jì)階段

在測試左移的早期實(shí)踐中，測試活動(dòng)已經(jīng)被前置到開發(fā)階段，我們可以進(jìn)一步把測試前置到需求分析和方案設(shè)計(jì)階段。這樣，測試人員除了能夠深入理解需求，在前期掌握詳實(shí)的需求信息，更重要的是還能夠及時(shí)評估需求本身的質(zhì)量，比如分析需求的合理性及完整性等。這樣后續(xù)的測試分析與測試設(shè)計(jì)才能有的放矢地開展，實(shí)現(xiàn)測試用例先行，爭取一次性把事情做正確，避免產(chǎn)生“信息孤島”以及由此產(chǎn)生的各種潛在返工。

這里推薦使用行為驅(qū)動(dòng)開發(fā)（Behavior Driven Development，BDD）和特性驅(qū)動(dòng)開發(fā)（FeatureDriven Development，F(xiàn)DD）的方法，在進(jìn)行需求評估時(shí)更多地從測試視角去思考問題，按照編寫用戶故事或用戶場景的方式，從功能使用者的視角描述并編寫測試用例，從而讓產(chǎn)品經(jīng)理、開發(fā)人員和測試人員著眼于代碼所要實(shí)現(xiàn)的業(yè)務(wù)行為，并以此為依據(jù)通過測試用例進(jìn)行驗(yàn)證。

當(dāng)然，以上實(shí)踐對測試人員也提出了更高的要求，他們必須掌握行為驅(qū)動(dòng)開發(fā)、特性驅(qū)動(dòng)開發(fā)、領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)（Domain Driven Design，DDD）以及實(shí)例化需求（Specification By Example，SBE）等技能。

3. 鼓勵(lì)開發(fā)人員自測

一方面開發(fā)人員必須對軟件質(zhì)量負(fù)責(zé)，另一方面測試活動(dòng)正在不斷滲透到開發(fā)的各個(gè)階段，同時(shí)對測試人員的技能要求越來越向開發(fā)人員看齊，由開發(fā)人員自己來承擔(dān)測試工作的訴求正變得越來越強(qiáng)烈。我們需要的不再是獨(dú)立的開發(fā)人才和測試人才，而是全棧型人才。在這種大背景下，開發(fā)者自測就變得理所應(yīng)當(dāng)了。我們要將傳統(tǒng)職能型團(tuán)隊(duì)重組為全棧團(tuán)隊(duì)，不然質(zhì)量左移、質(zhì)量內(nèi)建只會(huì)流于表面。

但是說到讓開發(fā)人員自己完成測試工作，我們常常會(huì)聽到很多質(zhì)疑聲，質(zhì)疑的焦點(diǎn)是開發(fā)人員是否適合做測試，這里我們展開討論一下。

從人性的角度來看，開發(fā)人員通常具備“創(chuàng)造性思維”，自己開發(fā)的代碼就像親兒子一樣，怎么看都覺得很棒；而測試人員則具備“破壞性思維”，測試人員的職責(zé)就是盡可能多地找到潛在的缺陷，而且專職的測試人員通常已經(jīng)在以往的測試實(shí)踐中積累了大量典型的容易找到缺陷的模式，所以測試人員與開發(fā)人員相比，往往更能客觀且全面地做好測試。

從技術(shù)層面來看，由開發(fā)人員自己完成測試，會(huì)存在嚴(yán)重的“思維慣性”——通常開發(fā)人員在設(shè)計(jì)和開發(fā)過程中沒有考慮到的分支和處理邏輯，在自己做測試的時(shí)候同樣不會(huì)考慮到。比如對于一個(gè)函數(shù)，它有一個(gè) string 類型的輸入?yún)?shù)，如果開發(fā)人員在做功能實(shí)現(xiàn)的時(shí)候完全沒有考慮到 string類型的參數(shù)存在 null 值的可能性，那么代碼的實(shí)現(xiàn)里面也不會(huì)對 null 值做處理，在測試的時(shí)候就更不會(huì)設(shè)計(jì)針對null 值的測試數(shù)據(jù)，這樣的“一條龍”缺失就會(huì)在代碼中留下隱患。

上述分析非常客觀，筆者曾經(jīng)也非常認(rèn)同，但是在經(jīng)歷并主導(dǎo)了國內(nèi)外多家大型軟件企業(yè)的開發(fā)者自測轉(zhuǎn)型實(shí)踐之后，筆者改變了看法。開發(fā)人員其實(shí)是最了解自己代碼的人，所以他們能夠最高效地對自己的代碼進(jìn)行測試，開發(fā)人員可以基于代碼變更自行判斷可能受影響的范圍，實(shí)現(xiàn)高效的精準(zhǔn)測試。同時(shí)，當(dāng)開發(fā)人員有了質(zhì)量責(zé)任和測試義務(wù)之后，測試能力就會(huì)成為其技能發(fā)展的重要方向。我們說“好馬是跑出來的，好鋼是煉出來的”，只有通過實(shí)戰(zhàn)，開發(fā)人員的測試分析與設(shè)計(jì)能力才能提升，進(jìn)而開發(fā)的內(nèi)建質(zhì)量才能提升。可以說，開發(fā)者自測是軟件質(zhì)量提升的必經(jīng)之路。

4. 在代碼開發(fā)階段借助TDD的思想

這里的TDD是指測試驅(qū)動(dòng)開發(fā)（Test Driven Development），但我們并不是要照搬TDD的實(shí)踐，而是借助TDD的思想，用測試先行的思路，幫助開發(fā)人員梳理和理解需求，完成更好的代碼設(shè)計(jì)與實(shí)現(xiàn)，縮短代碼質(zhì)量的反饋周期，提高軟件質(zhì)量。

5. 預(yù)留測試時(shí)間

在做項(xiàng)目計(jì)劃的時(shí)候，尤其在讓開發(fā)人員進(jìn)行時(shí)間評估時(shí)，必須為自測預(yù)留時(shí)間。一個(gè)功能可以交付的標(biāo)準(zhǔn)不僅僅是功能的實(shí)現(xiàn)，對應(yīng)的測試也是需要時(shí)間成本的，這需要管理層進(jìn)行思維轉(zhuǎn)換，否則測試左移只能停留在概念層面，很難真正落地。

6.提高軟件的可測試性

提高軟件的可測試性是測試左移中一個(gè)重要的實(shí)踐，因?yàn)樗梢杂行У貛椭覀冊O(shè)計(jì)適合團(tuán)隊(duì)的測試策略。我們需要測試人員在參與需求分析和方案設(shè)計(jì)的過程中，能夠提出相關(guān)的可測試性需求，幫助研發(fā)人員設(shè)計(jì)出易于測試的軟件架構(gòu)和代碼模塊，從而提高測試工作的效率和有效性。關(guān)于軟件的可測試性設(shè)計(jì)，詳見1.3節(jié)。