1.2 開(kāi)發(fā)團(tuán)隊(duì)做的遠(yuǎn)不僅是開(kāi)發(fā)
加入團(tuán)隊(duì)已經(jīng)有一段時(shí)間，小艾逐漸發(fā)現(xiàn)，在工作中，似乎每個(gè)人都在做不一樣的事情，而每個(gè)人在團(tuán)隊(duì)中的位置都顯得不可或缺。一個(gè)疑問(wèn)從小艾的心中冒出來(lái)：為什么團(tuán)隊(duì)中大家似乎都在做不同的事情？開(kāi)發(fā)團(tuán)隊(duì)有多少種角色？測(cè)試團(tuán)隊(duì)又有多少種角色？測(cè)試專家的核心價(jià)值究竟在哪里？
凱文的解答從講述團(tuán)隊(duì)分工開(kāi)始。
細(xì)致的分工能提高效率的道理已經(jīng)在許多需要專門技能的領(lǐng)域得到充分證明。在軟件開(kāi)發(fā)領(lǐng)域，分工的作用同樣突出。分工的結(jié)果是，團(tuán)隊(duì)的成員根據(jù)分工的結(jié)果擔(dān)當(dāng)不同的角色，在其位，謀其職。
在一個(gè)軟件開(kāi)發(fā)團(tuán)隊(duì)中，狹義上從事開(kāi)發(fā)任務(wù)的成員其實(shí)只占其中一部分；開(kāi)發(fā)以外的其他任務(wù)，如項(xiàng)目管理、設(shè)計(jì)、測(cè)試等在軟件開(kāi)發(fā)過(guò)程中同樣非常重要。作為測(cè)試團(tuán)隊(duì)中的一員，小艾有必要了解更多關(guān)于測(cè)試團(tuán)隊(duì)中角色分工的內(nèi)容。測(cè)試在軟件開(kāi)發(fā)過(guò)程中的重要性，在許多人心目中并不那么突出，但實(shí)際上，軟件的好壞，在很大程度上是由測(cè)試決定的。
1.2.1 術(shù)業(yè)有專攻
在知識(shí)密集型的社會(huì)，人是最關(guān)鍵的資源。軟件開(kāi)發(fā)的產(chǎn)出和從業(yè)人員的技能密不可分。然而，隨著軟件系統(tǒng)的復(fù)雜度越來(lái)越高，駕馭軟件開(kāi)發(fā)所需的人力資源遠(yuǎn)遠(yuǎn)超出單一個(gè)體的可承受限度。從這個(gè)角度而言，分工是解決個(gè)人控制力有限的唯一方法。從經(jīng)驗(yàn)和效率的角度看，一個(gè)團(tuán)隊(duì)中的個(gè)體在技術(shù)和經(jīng)驗(yàn)上各有千秋，分工能更有效地發(fā)揮人的長(zhǎng)處。
在一個(gè)成熟的開(kāi)發(fā)團(tuán)隊(duì)中，細(xì)致嚴(yán)密的分工使團(tuán)隊(duì)能以更高的效率運(yùn)作。分工有助于提高效能的奧秘在于，絕大多數(shù)情況下，專注的人在效率上要高于注意力分散的人。細(xì)致的分工有利于凝聚人的注意力，提高熟練程度的同時(shí)減少切換帶來(lái)的開(kāi)銷。在軟件開(kāi)發(fā)團(tuán)隊(duì)中，特別是使用了敏捷開(kāi)發(fā)以后，團(tuán)隊(duì)的角色分工是非常明確的，每個(gè)成員根據(jù)各自的角色，專注于開(kāi)發(fā)過(guò)程中的相應(yīng)任務(wù)。
電子商務(wù)平臺(tái)是一個(gè)涉及多種業(yè)務(wù)場(chǎng)景的復(fù)雜軟件系統(tǒng)。軟件開(kāi)發(fā)任務(wù)的順利完成，必須依賴于一個(gè)角色完善的團(tuán)隊(duì)的緊密合作。那么團(tuán)隊(duì)中究竟都需要哪些角色分工呢？
小艾所在的開(kāi)發(fā)團(tuán)隊(duì)使用Scrum模式敏捷開(kāi)發(fā)，是已經(jīng)被證實(shí)可以提高開(kāi)發(fā)效率的開(kāi)發(fā)方式。按照敏捷開(kāi)發(fā)的團(tuán)隊(duì)角色劃分方式，Scrum團(tuán)隊(duì)的核心角色主要包括產(chǎn)品負(fù)責(zé)人（Product Owner）、Scrum Master及團(tuán)隊(duì)成員（Team）。在Scrum團(tuán)隊(duì)的外圍還包括客戶（Stakeholder）、經(jīng)理（Manager）等角色 。
團(tuán)隊(duì)成員主要負(fù)責(zé)產(chǎn)品的具體開(kāi)發(fā)。每個(gè)團(tuán)隊(duì)成員有具體的分工，如架構(gòu)師、開(kāi)發(fā)人員、測(cè)試人員、文檔設(shè)計(jì)人員等。團(tuán)隊(duì)成員組成執(zhí)行團(tuán)隊(duì)，這是個(gè)自組織、自定向和跨功能的執(zhí)行團(tuán)隊(duì)。執(zhí)行團(tuán)隊(duì)通過(guò)直接的行動(dòng)推進(jìn)項(xiàng)目的進(jìn)度，以達(dá)到計(jì)劃的目標(biāo)。執(zhí)行團(tuán)隊(duì)一般由5～9個(gè)各方面的專家組成，團(tuán)隊(duì)的組織結(jié)構(gòu)文檔貫穿整個(gè)開(kāi)發(fā)周期。團(tuán)隊(duì)成員都是開(kāi)發(fā)周期里各個(gè)領(lǐng)域的專家，他們使用專業(yè)的技能完成開(kāi)發(fā)任務(wù)。對(duì)每種角色，通常都有一套技能集（Skill Set），通過(guò)技能集，可以定義一個(gè)角色應(yīng)該具備的能力，反過(guò)來(lái)也能夠判定一個(gè)員工是否具備擔(dān)當(dāng)某個(gè)角色的專業(yè)素質(zhì)。
架構(gòu)師是對(duì)軟件開(kāi)發(fā)過(guò)程的各個(gè)領(lǐng)域都具備一定專業(yè)技能的人員，主要任務(wù)是把軟件開(kāi)發(fā)的需求轉(zhuǎn)化為可以實(shí)現(xiàn)的抽象設(shè)計(jì)和具體設(shè)計(jì)，并完成相應(yīng)的設(shè)計(jì)文檔。同時(shí)，架構(gòu)師還需要把業(yè)務(wù)化的需求轉(zhuǎn)化為技術(shù)化的功能性需求及非功能性需求。架構(gòu)師需要參與軟件開(kāi)發(fā)各個(gè)階段，也作為審核人員對(duì)詳細(xì)設(shè)計(jì)和開(kāi)發(fā)計(jì)劃進(jìn)行審查。架構(gòu)師的技能特點(diǎn)是，具有更高視角，對(duì)技術(shù)的發(fā)展方向能夠有全局的把握，對(duì)業(yè)務(wù)也有深刻的認(rèn)識(shí)。可以說(shuō)，架構(gòu)師的知識(shí)體系兼顧了深度和廣度。
開(kāi)發(fā)人員的職責(zé)是根據(jù)抽象設(shè)計(jì)和高層次的具體設(shè)計(jì)進(jìn)行更細(xì)化的具體設(shè)計(jì)，并按照設(shè)計(jì)完成編碼實(shí)現(xiàn)及單元測(cè)試任務(wù)。在測(cè)試階段，開(kāi)發(fā)人員還有完成問(wèn)題分析和解決缺陷的任務(wù)。由于軟件的代碼實(shí)現(xiàn)都是由開(kāi)發(fā)人員完成的，因此開(kāi)發(fā)人員的開(kāi)發(fā)技能與軟件是否以高質(zhì)量完成有重要的關(guān)系。開(kāi)發(fā)人員具有把宏觀任務(wù)抽象化和把抽象概念具體化的能力，能夠以微觀的視角完成功能細(xì)節(jié)的開(kāi)發(fā)。作為開(kāi)發(fā)人員，卓越的理解能力和編碼能力是必需的。
測(cè)試人員的任務(wù)是根據(jù)軟件設(shè)計(jì)文檔編寫測(cè)試計(jì)劃，并按照測(cè)試計(jì)劃對(duì)軟件進(jìn)行測(cè)試。要完成的測(cè)試種類是根據(jù)需求定義的，在復(fù)雜軟件系統(tǒng)的開(kāi)發(fā)團(tuán)隊(duì)中，通常包括多種類型的測(cè)試人員，分別對(duì)各自的領(lǐng)域進(jìn)行有針對(duì)性的測(cè)試。測(cè)試人員從另一個(gè)角度促進(jìn)軟件的開(kāi)發(fā)過(guò)程，其工作的重點(diǎn)是發(fā)現(xiàn)問(wèn)題和解決問(wèn)題，因此，這對(duì)測(cè)試人員的洞察能力和分析能力提出非常高的要求。測(cè)試人員除了掌握測(cè)試方法學(xué)以外，還需要具有良好的抽象思維能力和邏輯分析能力。
文檔設(shè)計(jì)人員的任務(wù)是根據(jù)需求文檔和設(shè)計(jì)文檔，設(shè)計(jì)編寫交付給用戶的說(shuō)明文檔和使用手冊(cè)。文檔對(duì)于軟件產(chǎn)品的重要作用是不言而喻的，完備的文檔是成熟軟件產(chǎn)品必須具備的交付成果。一套好的文檔在很大程度上決定了軟件產(chǎn)品能否順利被最終用戶接受。文檔對(duì)于開(kāi)發(fā)團(tuán)隊(duì)也有重要的意義。清晰細(xì)致的技術(shù)文檔對(duì)于產(chǎn)品維護(hù)的幫助也是不言而喻的。為了完成文檔的設(shè)計(jì)，對(duì)文檔設(shè)計(jì)人員的技能要求絲毫不能馬虎。文檔設(shè)計(jì)人員需要具有突出的表達(dá)能力和敘述能力，善于把抽象的問(wèn)題具體化，另外，還需要有一定的藝術(shù)才能。
在團(tuán)隊(duì)的外圍，相關(guān)的角色還有客戶和經(jīng)理。
客戶是軟件產(chǎn)品的直接利益相關(guān)者，他們從業(yè)務(wù)的角度提出對(duì)軟件產(chǎn)品的需求。從本質(zhì)上而言，客戶是開(kāi)發(fā)軟件的根本動(dòng)力，為軟件開(kāi)發(fā)支付相應(yīng)的費(fèi)用。在開(kāi)發(fā)過(guò)程中，他們需要對(duì)軟件的進(jìn)度、是否滿足需求進(jìn)行相應(yīng)的把關(guān)，并參與階段性的回顧。客戶的特點(diǎn)是對(duì)業(yè)務(wù)有深入的理解，能夠清晰地理解業(yè)務(wù)流程。
經(jīng)理在團(tuán)隊(duì)中的任務(wù)是控制開(kāi)發(fā)進(jìn)度、解決團(tuán)隊(duì)的資源問(wèn)題、對(duì)團(tuán)隊(duì)的運(yùn)行進(jìn)行技術(shù)性的指導(dǎo)等。根據(jù)這三種不同的任務(wù)，可以有三個(gè)人分別擔(dān)當(dāng)不同的經(jīng)理角色，分別是項(xiàng)目經(jīng)理（Project Manager）、人事經(jīng)理（People Manager）及指導(dǎo)經(jīng)理（Coaching Manager）。通常情況下，也可能是一個(gè)成員同時(shí)兼顧多個(gè)經(jīng)理角色。經(jīng)理不直接參與項(xiàng)目，但在項(xiàng)目的外圍提供關(guān)鍵的支持，為軟件開(kāi)發(fā)營(yíng)造良好的環(huán)境，因而需要有更高的視覺(jué)和領(lǐng)導(dǎo)力以完成相應(yīng)的任務(wù)
作為測(cè)試團(tuán)隊(duì)的一員，小艾最關(guān)心的是測(cè)試團(tuán)隊(duì)中都有哪些角色分工。可以認(rèn)為，測(cè)試團(tuán)隊(duì)的成員都是敏捷開(kāi)發(fā)項(xiàng)目組的測(cè)試人員，都具備測(cè)試人員的一般技能。
由于軟件測(cè)試本身就可以作為一個(gè)項(xiàng)目來(lái)看待，因此測(cè)試團(tuán)隊(duì)中需要相應(yīng)的項(xiàng)目組角色。測(cè)試負(fù)責(zé)人（Test Lead）是測(cè)試的主要統(tǒng)籌者，需要擔(dān)當(dāng)測(cè)試項(xiàng)目經(jīng)理的角色，其任務(wù)包括定義測(cè)試計(jì)劃、統(tǒng)籌人員調(diào)配、監(jiān)督測(cè)試項(xiàng)目進(jìn)度等。測(cè)試負(fù)責(zé)人定期向項(xiàng)目團(tuán)隊(duì)發(fā)布有關(guān)測(cè)試項(xiàng)目的進(jìn)度和更新，對(duì)測(cè)試項(xiàng)目進(jìn)度負(fù)責(zé)。作為測(cè)試的統(tǒng)籌者，為了順利完成測(cè)試任務(wù)，測(cè)試負(fù)責(zé)人需要利用相關(guān)的規(guī)則結(jié)合經(jīng)驗(yàn)安排測(cè)試的執(zhí)行順序，降低測(cè)試進(jìn)度受阻或測(cè)試檢測(cè)出嚴(yán)重問(wèn)題但難以解決的風(fēng)險(xiǎn)。測(cè)試負(fù)責(zé)人的技能要求是綜合的，既需要掌握測(cè)試的專業(yè)技能，又要具備良好的組織能力和協(xié)調(diào)能力。
測(cè)試架構(gòu)師的職責(zé)是定義測(cè)試策略，從宏觀上定義測(cè)試的方向和方法。測(cè)試架構(gòu)師對(duì)測(cè)試目標(biāo)的技術(shù)特性和業(yè)務(wù)需求有準(zhǔn)確的把握，能為測(cè)試團(tuán)隊(duì)提供方法論方面的全面建議。在測(cè)試計(jì)劃完成后，測(cè)試架構(gòu)師需要審核計(jì)劃是否全面覆蓋應(yīng)該包含的驗(yàn)證點(diǎn)，根據(jù)經(jīng)驗(yàn)給出相關(guān)的執(zhí)行建議。作為測(cè)試團(tuán)隊(duì)的“智囊”，測(cè)試架構(gòu)師應(yīng)該具有較高的技能水平，包括深入和全面的測(cè)試經(jīng)驗(yàn)，對(duì)軟件開(kāi)發(fā)和測(cè)試的模型有全面的認(rèn)識(shí)，對(duì)商業(yè)模式及客戶的業(yè)務(wù)需求也有比較深刻的理解。
相對(duì)于具有宏觀視角的測(cè)試架構(gòu)師，測(cè)試工程師以“微觀”的視覺(jué)專注于具體的測(cè)試任務(wù)。根據(jù)特定的測(cè)試場(chǎng)景，測(cè)試工程師重點(diǎn)關(guān)注其測(cè)試的目標(biāo)業(yè)務(wù)部分，根據(jù)特定業(yè)務(wù)場(chǎng)景制訂該部分的測(cè)試計(jì)劃。由于不同的測(cè)試類型之間存在依賴關(guān)系，測(cè)試工程師得進(jìn)行團(tuán)隊(duì)的直接溝通，使測(cè)試計(jì)劃可以滿足這種依賴。測(cè)試計(jì)劃制訂完成以后，測(cè)試工程師就根據(jù)計(jì)劃執(zhí)行測(cè)試；同時(shí)，在測(cè)試過(guò)程中發(fā)現(xiàn)缺陷時(shí)，測(cè)試工程師還有義務(wù)和開(kāi)發(fā)人員一起分析問(wèn)題的原因并提出解決方案。測(cè)試工程師的技能集主要包括設(shè)計(jì)和執(zhí)行測(cè)試用例的專業(yè)技能，良好的業(yè)務(wù)理解能力和問(wèn)題分析能力。
測(cè)試經(jīng)理（Testing Manager）從資源調(diào)配的角度給不同的測(cè)試項(xiàng)目分配資源。通常來(lái)說(shuō)，測(cè)試和開(kāi)發(fā)的執(zhí)行步調(diào)是不一致的，因此同一個(gè)測(cè)試人員有可能同時(shí)承擔(dān)多個(gè)子項(xiàng)目的測(cè)試任務(wù)。在一個(gè)敏捷軟件開(kāi)發(fā)團(tuán)隊(duì)中，對(duì)測(cè)試人員的多任務(wù)處理能力有較高的要求。
在軟件開(kāi)發(fā)團(tuán)隊(duì)和測(cè)試團(tuán)隊(duì)中，有些角色對(duì)承擔(dān)者的資歷有明確要求，如架構(gòu)師角色要求對(duì)業(yè)務(wù)和技術(shù)有一定的經(jīng)驗(yàn)。然而，角色的不同僅僅體現(xiàn)分工的不一樣，并沒(méi)有級(jí)別的區(qū)分。因此，角色并沒(méi)有貴賤之分。每個(gè)角色的技能集都非常明確，相同角色的承擔(dān)者在技能的層次上也可能存在很大的差異。隨著技術(shù)和經(jīng)驗(yàn)的積累，每種角色都可以成長(zhǎng)出資歷深厚的專家。專家和菜鳥(niǎo)，在某種程度上，僅僅是一種“聞道有先后”的差異。
了解到團(tuán)隊(duì)中原來(lái)有這么多不同的角色，而不是僅有“程序員”，小艾覺(jué)得非常興奮。在一個(gè)完備的團(tuán)隊(duì)中，體驗(yàn)不同角色的奧妙，該是一件多么有趣的事情！
1.2.2 好軟件由測(cè)試決定
進(jìn)入電子商務(wù)平臺(tái)開(kāi)發(fā)一段時(shí)間以來(lái)，小艾不時(shí)聽(tīng)身邊的前輩提及IBM的軟件質(zhì)量不錯(cuò)。似乎每個(gè)人都認(rèn)為自己有清晰的標(biāo)準(zhǔn)衡量軟件的好壞，但對(duì)于什么樣的軟件才是好軟件，小艾心中并沒(méi)有明確的界定標(biāo)準(zhǔn)。用"好"來(lái)形容軟件，顯然是一個(gè)相當(dāng)籠統(tǒng)的描述。
軟件質(zhì)量 包括兩個(gè)相關(guān)但截然不同的概念--功能性質(zhì)量（Functional Quality）和結(jié)構(gòu)性質(zhì)量（Structural Quality）。功能性質(zhì)量反映的是軟件是否按照設(shè)計(jì)實(shí)現(xiàn)并滿足相應(yīng)功能性需求（Functional Requirements）；結(jié)構(gòu)性質(zhì)量反映的是軟件是否滿足相關(guān)的非功能性需求（Non-Functional Requirements，NFR）。
要評(píng)價(jià)軟件的功能性質(zhì)量和結(jié)構(gòu)性質(zhì)量，有一系列衡量指標(biāo)。有了衡量指標(biāo)以后，另一個(gè)重要的問(wèn)題就是如何獲得這些指標(biāo)的量化數(shù)值。軟件測(cè)試是驗(yàn)證這些指標(biāo)的有效方法。通過(guò)測(cè)試可以在一定程度上模擬真實(shí)的使用場(chǎng)景，并得到質(zhì)量指標(biāo)的具體水平。如果測(cè)試發(fā)現(xiàn)某些指標(biāo)無(wú)法達(dá)到要求，則需要對(duì)系統(tǒng)進(jìn)行改進(jìn)，以求通過(guò)測(cè)試。測(cè)試的通過(guò)指標(biāo)是根據(jù)質(zhì)量的需求來(lái)定義的，系統(tǒng)通過(guò)了測(cè)試，可以從量化的角度說(shuō)明它符合需求。
正確性（Correctness）反映了實(shí)現(xiàn)的功能達(dá)到設(shè)計(jì)規(guī)范并滿足用戶需求的程度。這是功能性質(zhì)量的基本指標(biāo)。正確性可以通過(guò)功能測(cè)試來(lái)驗(yàn)證。
可靠性（Reliability）衡量在規(guī)定的時(shí)間和條件下，系統(tǒng)維持其性能水準(zhǔn)的程度。這是結(jié)構(gòu)性需求的重要指標(biāo)。對(duì)于企業(yè)級(jí)的應(yīng)用系統(tǒng)，對(duì)可靠性通常都有很高的要求。可靠性指標(biāo)可以通過(guò)系統(tǒng)可靠性測(cè)試獲取。
易用性（Usability）反映用戶掌握軟件操作及理解軟件事務(wù)所需付出的時(shí)間及努力程度。具體的指標(biāo)諸如界面是否友好，是否有在線幫助，是否提供容易理解的異常信息等。易用性指標(biāo)通常由功能測(cè)試獲得。
可移植性（Portability）衡量系統(tǒng)從一個(gè)平臺(tái)轉(zhuǎn)移到另一個(gè)平臺(tái)的容易程度，包括把程序從一種軟/硬件環(huán)境轉(zhuǎn)移到另一種軟/硬件環(huán)境的容易程度等。大型軟件的安裝和部署可能也是一個(gè)復(fù)雜的過(guò)程，高可移植性的系統(tǒng)應(yīng)該是容易安裝和更新的。此外，企業(yè)級(jí)系統(tǒng)對(duì)多國(guó)語(yǔ)言的支持程度也是可移植性的一個(gè)衡量指標(biāo)。可移植性在多平臺(tái)的功能、系統(tǒng)測(cè)試、安裝測(cè)試、多國(guó)語(yǔ)言測(cè)試中得到驗(yàn)證。
可遷移性（Migratability）衡量系統(tǒng)版本升級(jí)的容易程度。大型系統(tǒng)的遷移通常是一件非常復(fù)雜的事情，可遷移性需要通過(guò)遷移測(cè)試來(lái)驗(yàn)證。
效率（Efficiency）衡量系統(tǒng)執(zhí)行某功能所需的計(jì)算機(jī)資源和時(shí)間有效程度，包括功能和性能是否經(jīng)過(guò)優(yōu)化，是否檢驗(yàn)內(nèi)存泄漏或溢出問(wèn)題等。效率是系統(tǒng)測(cè)試的一個(gè)重要檢測(cè)點(diǎn)。
作為測(cè)試團(tuán)隊(duì)的一員，小艾最關(guān)心的是測(cè)試團(tuán)隊(duì)中都有哪些角色分工。可以認(rèn)為，測(cè)試團(tuán)隊(duì)的成員都是敏捷開(kāi)發(fā)項(xiàng)目組的測(cè)試人員，都具備測(cè)試人員的一般技能。
由于軟件測(cè)試本身就可以作為一個(gè)項(xiàng)目來(lái)看待，因此測(cè)試團(tuán)隊(duì)中需要相應(yīng)的項(xiàng)目組角色。測(cè)試負(fù)責(zé)人（Test Lead）是測(cè)試的主要統(tǒng)籌者，需要擔(dān)當(dāng)測(cè)試項(xiàng)目經(jīng)理的角色，其任務(wù)包括定義測(cè)試計(jì)劃、統(tǒng)籌人員調(diào)配、監(jiān)督測(cè)試項(xiàng)目進(jìn)度等。測(cè)試負(fù)責(zé)人定期向項(xiàng)目團(tuán)隊(duì)發(fā)布有關(guān)測(cè)試項(xiàng)目的進(jìn)度和更新，對(duì)測(cè)試項(xiàng)目進(jìn)度負(fù)責(zé)。作為測(cè)試的統(tǒng)籌者，為了順利完成測(cè)試任務(wù)，測(cè)試負(fù)責(zé)人需要利用相關(guān)的規(guī)則結(jié)合經(jīng)驗(yàn)安排測(cè)試的執(zhí)行順序，降低測(cè)試進(jìn)度受阻或測(cè)試檢測(cè)出嚴(yán)重問(wèn)題但難以解決的風(fēng)險(xiǎn)。測(cè)試負(fù)責(zé)人的技能要求是綜合的，既需要掌握測(cè)試的專業(yè)技能，又要具備良好的組織能力和協(xié)調(diào)能力。
測(cè)試架構(gòu)師的職責(zé)是定義測(cè)試策略，從宏觀上定義測(cè)試的方向和方法。測(cè)試架構(gòu)師對(duì)測(cè)試目標(biāo)的技術(shù)特性和業(yè)務(wù)需求有準(zhǔn)確的把握，能為測(cè)試團(tuán)隊(duì)提供方法論方面的全面建議。在測(cè)試計(jì)劃完成后，測(cè)試架構(gòu)師需要審核計(jì)劃是否全面覆蓋應(yīng)該包含的驗(yàn)證點(diǎn)，根據(jù)經(jīng)驗(yàn)給出相關(guān)的執(zhí)行建議。作為測(cè)試團(tuán)隊(duì)的“智囊”，測(cè)試架構(gòu)師應(yīng)該具有較高的技能水平，包括深入和全面的測(cè)試經(jīng)驗(yàn)，對(duì)軟件開(kāi)發(fā)和測(cè)試的模型有全面的認(rèn)識(shí)，對(duì)商業(yè)模式及客戶的業(yè)務(wù)需求也有比較深刻的理解。
相對(duì)于具有宏觀視角的測(cè)試架構(gòu)師，測(cè)試工程師以“微觀”的視覺(jué)專注于具體的測(cè)試任務(wù)。根據(jù)特定的測(cè)試場(chǎng)景，測(cè)試工程師重點(diǎn)關(guān)注其測(cè)試的目標(biāo)業(yè)務(wù)部分，根據(jù)特定業(yè)務(wù)場(chǎng)景制訂該部分的測(cè)試計(jì)劃。由于不同的測(cè)試類型之間存在依賴關(guān)系，測(cè)試工程師得進(jìn)行團(tuán)隊(duì)的直接溝通，使測(cè)試計(jì)劃可以滿足這種依賴。測(cè)試計(jì)劃制訂完成以后，測(cè)試工程師就根據(jù)計(jì)劃執(zhí)行測(cè)試；同時(shí)，在測(cè)試過(guò)程中發(fā)現(xiàn)缺陷時(shí)，測(cè)試工程師還有義務(wù)和開(kāi)發(fā)人員一起分析問(wèn)題的原因并提出解決方案。測(cè)試工程師的技能集主要包括設(shè)計(jì)和執(zhí)行測(cè)試用例的專業(yè)技能，良好的業(yè)務(wù)理解能力和問(wèn)題分析能力。
測(cè)試經(jīng)理（Testing Manager）從資源調(diào)配的角度給不同的測(cè)試項(xiàng)目分配資源。通常來(lái)說(shuō)，測(cè)試和開(kāi)發(fā)的執(zhí)行步調(diào)是不一致的，因此同一個(gè)測(cè)試人員有可能同時(shí)承擔(dān)多個(gè)子項(xiàng)目的測(cè)試任務(wù)。在一個(gè)敏捷軟件開(kāi)發(fā)團(tuán)隊(duì)中，對(duì)測(cè)試人員的多任務(wù)處理能力有較高的要求。
在軟件開(kāi)發(fā)團(tuán)隊(duì)和測(cè)試團(tuán)隊(duì)中，有些角色對(duì)承擔(dān)者的資歷有明確要求，如架構(gòu)師角色要求對(duì)業(yè)務(wù)和技術(shù)有一定的經(jīng)驗(yàn)。然而，角色的不同僅僅體現(xiàn)分工的不一樣，并沒(méi)有級(jí)別的區(qū)分。因此，角色并沒(méi)有貴賤之分。每個(gè)角色的技能集都非常明確，相同角色的承擔(dān)者在技能的層次上也可能存在很大的差異。隨著技術(shù)和經(jīng)驗(yàn)的積累，每種角色都可以成長(zhǎng)出資歷深厚的專家。專家和菜鳥(niǎo)，在某種程度上，僅僅是一種“聞道有先后”的差異。
了解到團(tuán)隊(duì)中原來(lái)有這么多不同的角色，而不是僅有“程序員”，小艾覺(jué)得非常興奮。在一個(gè)完備的團(tuán)隊(duì)中，體驗(yàn)不同角色的奧妙，該是一件多么有趣的事情！
1.2.2 好軟件由測(cè)試決定
進(jìn)入電子商務(wù)平臺(tái)開(kāi)發(fā)一段時(shí)間以來(lái)，小艾不時(shí)聽(tīng)身邊的前輩提及IBM的軟件質(zhì)量不錯(cuò)。似乎每個(gè)人都認(rèn)為自己有清晰的標(biāo)準(zhǔn)衡量軟件的好壞，但對(duì)于什么樣的軟件才是好軟件，小艾心中并沒(méi)有明確的界定標(biāo)準(zhǔn)。用"好"來(lái)形容軟件，顯然是一個(gè)相當(dāng)籠統(tǒng)的描述。
軟件質(zhì)量 包括兩個(gè)相關(guān)但截然不同的概念--功能性質(zhì)量（Functional Quality）和結(jié)構(gòu)性質(zhì)量（Structural Quality）。功能性質(zhì)量反映的是軟件是否按照設(shè)計(jì)實(shí)現(xiàn)并滿足相應(yīng)功能性需求（Functional Requirements）；結(jié)構(gòu)性質(zhì)量反映的是軟件是否滿足相關(guān)的非功能性需求（Non-Functional Requirements，NFR）。
要評(píng)價(jià)軟件的功能性質(zhì)量和結(jié)構(gòu)性質(zhì)量，有一系列衡量指標(biāo)。有了衡量指標(biāo)以后，另一個(gè)重要的問(wèn)題就是如何獲得這些指標(biāo)的量化數(shù)值。軟件測(cè)試是驗(yàn)證這些指標(biāo)的有效方法。通過(guò)測(cè)試可以在一定程度上模擬真實(shí)的使用場(chǎng)景，并得到質(zhì)量指標(biāo)的具體水平。如果測(cè)試發(fā)現(xiàn)某些指標(biāo)無(wú)法達(dá)到要求，則需要對(duì)系統(tǒng)進(jìn)行改進(jìn)，以求通過(guò)測(cè)試。測(cè)試的通過(guò)指標(biāo)是根據(jù)質(zhì)量的需求來(lái)定義的，系統(tǒng)通過(guò)了測(cè)試，可以從量化的角度說(shuō)明它符合需求。
正確性（Correctness）反映了實(shí)現(xiàn)的功能達(dá)到設(shè)計(jì)規(guī)范并滿足用戶需求的程度。這是功能性質(zhì)量的基本指標(biāo)。正確性可以通過(guò)功能測(cè)試來(lái)驗(yàn)證。
可靠性（Reliability）衡量在規(guī)定的時(shí)間和條件下，系統(tǒng)維持其性能水準(zhǔn)的程度。這是結(jié)構(gòu)性需求的重要指標(biāo)。對(duì)于企業(yè)級(jí)的應(yīng)用系統(tǒng)，對(duì)可靠性通常都有很高的要求。可靠性指標(biāo)可以通過(guò)系統(tǒng)可靠性測(cè)試獲取。
易用性（Usability）反映用戶掌握軟件操作及理解軟件事務(wù)所需付出的時(shí)間及努力程度。具體的指標(biāo)諸如界面是否友好，是否有在線幫助，是否提供容易理解的異常信息等。易用性指標(biāo)通常由功能測(cè)試獲得。
可移植性（Portability）衡量系統(tǒng)從一個(gè)平臺(tái)轉(zhuǎn)移到另一個(gè)平臺(tái)的容易程度，包括把程序從一種軟/硬件環(huán)境轉(zhuǎn)移到另一種軟/硬件環(huán)境的容易程度等。大型軟件的安裝和部署可能也是一個(gè)復(fù)雜的過(guò)程，高可移植性的系統(tǒng)應(yīng)該是容易安裝和更新的。此外，企業(yè)級(jí)系統(tǒng)對(duì)多國(guó)語(yǔ)言的支持程度也是可移植性的一個(gè)衡量指標(biāo)。可移植性在多平臺(tái)的功能、系統(tǒng)測(cè)試、安裝測(cè)試、多國(guó)語(yǔ)言測(cè)試中得到驗(yàn)證。
可遷移性（Migratability）衡量系統(tǒng)版本升級(jí)的容易程度。大型系統(tǒng)的遷移通常是一件非常復(fù)雜的事情，可遷移性需要通過(guò)遷移測(cè)試來(lái)驗(yàn)證。
效率（Efficiency）衡量系統(tǒng)執(zhí)行某功能所需的計(jì)算機(jī)資源和時(shí)間有效程度，包括功能和性能是否經(jīng)過(guò)優(yōu)化，是否檢驗(yàn)內(nèi)存泄漏或溢出問(wèn)題等。效率是系統(tǒng)測(cè)試的一個(gè)重要檢測(cè)點(diǎn)。
作為測(cè)試團(tuán)隊(duì)的一員，小艾最關(guān)心的是測(cè)試團(tuán)隊(duì)中都有哪些角色分工。可以認(rèn)為，測(cè)試團(tuán)隊(duì)的成員都是敏捷開(kāi)發(fā)項(xiàng)目組的測(cè)試人員，都具備測(cè)試人員的一般技能。
由于軟件測(cè)試本身就可以作為一個(gè)項(xiàng)目來(lái)看待，因此測(cè)試團(tuán)隊(duì)中需要相應(yīng)的項(xiàng)目組角色。測(cè)試負(fù)責(zé)人（Test Lead）是測(cè)試的主要統(tǒng)籌者，需要擔(dān)當(dāng)測(cè)試項(xiàng)目經(jīng)理的角色，其任務(wù)包括定義測(cè)試計(jì)劃、統(tǒng)籌人員調(diào)配、監(jiān)督測(cè)試項(xiàng)目進(jìn)度等。測(cè)試負(fù)責(zé)人定期向項(xiàng)目團(tuán)隊(duì)發(fā)布有關(guān)測(cè)試項(xiàng)目的進(jìn)度和更新，對(duì)測(cè)試項(xiàng)目進(jìn)度負(fù)責(zé)。作為測(cè)試的統(tǒng)籌者，為了順利完成測(cè)試任務(wù)，測(cè)試負(fù)責(zé)人需要利用相關(guān)的規(guī)則結(jié)合經(jīng)驗(yàn)安排測(cè)試的執(zhí)行順序，降低測(cè)試進(jìn)度受阻或測(cè)試檢測(cè)出嚴(yán)重問(wèn)題但難以解決的風(fēng)險(xiǎn)。測(cè)試負(fù)責(zé)人的技能要求是綜合的，既需要掌握測(cè)試的專業(yè)技能，又要具備良好的組織能力和協(xié)調(diào)能力。
測(cè)試架構(gòu)師的職責(zé)是定義測(cè)試策略，從宏觀上定義測(cè)試的方向和方法。測(cè)試架構(gòu)師對(duì)測(cè)試目標(biāo)的技術(shù)特性和業(yè)務(wù)需求有準(zhǔn)確的把握，能為測(cè)試團(tuán)隊(duì)提供方法論方面的全面建議。在測(cè)試計(jì)劃完成后，測(cè)試架構(gòu)師需要審核計(jì)劃是否全面覆蓋應(yīng)該包含的驗(yàn)證點(diǎn)，根據(jù)經(jīng)驗(yàn)給出相關(guān)的執(zhí)行建議。作為測(cè)試團(tuán)隊(duì)的“智囊”，測(cè)試架構(gòu)師應(yīng)該具有較高的技能水平，包括深入和全面的測(cè)試經(jīng)驗(yàn)，對(duì)軟件開(kāi)發(fā)和測(cè)試的模型有全面的認(rèn)識(shí)，對(duì)商業(yè)模式及客戶的業(yè)務(wù)需求也有比較深刻的理解。
相對(duì)于具有宏觀視角的測(cè)試架構(gòu)師，測(cè)試工程師以“微觀”的視覺(jué)專注于具體的測(cè)試任務(wù)。根據(jù)特定的測(cè)試場(chǎng)景，測(cè)試工程師重點(diǎn)關(guān)注其測(cè)試的目標(biāo)業(yè)務(wù)部分，根據(jù)特定業(yè)務(wù)場(chǎng)景制訂該部分的測(cè)試計(jì)劃。由于不同的測(cè)試類型之間存在依賴關(guān)系，測(cè)試工程師得進(jìn)行團(tuán)隊(duì)的直接溝通，使測(cè)試計(jì)劃可以滿足這種依賴。測(cè)試計(jì)劃制訂完成以后，測(cè)試工程師就根據(jù)計(jì)劃執(zhí)行測(cè)試；同時(shí)，在測(cè)試過(guò)程中發(fā)現(xiàn)缺陷時(shí)，測(cè)試工程師還有義務(wù)和開(kāi)發(fā)人員一起分析問(wèn)題的原因并提出解決方案。測(cè)試工程師的技能集主要包括設(shè)計(jì)和執(zhí)行測(cè)試用例的專業(yè)技能，良好的業(yè)務(wù)理解能力和問(wèn)題分析能力。
測(cè)試經(jīng)理（Testing Manager）從資源調(diào)配的角度給不同的測(cè)試項(xiàng)目分配資源。通常來(lái)說(shuō)，測(cè)試和開(kāi)發(fā)的執(zhí)行步調(diào)是不一致的，因此同一個(gè)測(cè)試人員有可能同時(shí)承擔(dān)多個(gè)子項(xiàng)目的測(cè)試任務(wù)。在一個(gè)敏捷軟件開(kāi)發(fā)團(tuán)隊(duì)中，對(duì)測(cè)試人員的多任務(wù)處理能力有較高的要求。
在軟件開(kāi)發(fā)團(tuán)隊(duì)和測(cè)試團(tuán)隊(duì)中，有些角色對(duì)承擔(dān)者的資歷有明確要求，如架構(gòu)師角色要求對(duì)業(yè)務(wù)和技術(shù)有一定的經(jīng)驗(yàn)。然而，角色的不同僅僅體現(xiàn)分工的不一樣，并沒(méi)有級(jí)別的區(qū)分。因此，角色并沒(méi)有貴賤之分。每個(gè)角色的技能集都非常明確，相同角色的承擔(dān)者在技能的層次上也可能存在很大的差異。隨著技術(shù)和經(jīng)驗(yàn)的積累，每種角色都可以成長(zhǎng)出資歷深厚的專家。專家和菜鳥(niǎo)，在某種程度上，僅僅是一種“聞道有先后”的差異。
了解到團(tuán)隊(duì)中原來(lái)有這么多不同的角色，而不是僅有“程序員”，小艾覺(jué)得非常興奮。在一個(gè)完備的團(tuán)隊(duì)中，體驗(yàn)不同角色的奧妙，該是一件多么有趣的事情！
1.2.2 好軟件由測(cè)試決定
進(jìn)入電子商務(wù)平臺(tái)開(kāi)發(fā)一段時(shí)間以來(lái)，小艾不時(shí)聽(tīng)身邊的前輩提及IBM的軟件質(zhì)量不錯(cuò)。似乎每個(gè)人都認(rèn)為自己有清晰的標(biāo)準(zhǔn)衡量軟件的好壞，但對(duì)于什么樣的軟件才是好軟件，小艾心中并沒(méi)有明確的界定標(biāo)準(zhǔn)。用"好"來(lái)形容軟件，顯然是一個(gè)相當(dāng)籠統(tǒng)的描述。
軟件質(zhì)量 包括兩個(gè)相關(guān)但截然不同的概念--功能性質(zhì)量（Functional Quality）和結(jié)構(gòu)性質(zhì)量（Structural Quality）。功能性質(zhì)量反映的是軟件是否按照設(shè)計(jì)實(shí)現(xiàn)并滿足相應(yīng)功能性需求（Functional Requirements）；結(jié)構(gòu)性質(zhì)量反映的是軟件是否滿足相關(guān)的非功能性需求（Non-Functional Requirements，NFR）。
要評(píng)價(jià)軟件的功能性質(zhì)量和結(jié)構(gòu)性質(zhì)量，有一系列衡量指標(biāo)。有了衡量指標(biāo)以后，另一個(gè)重要的問(wèn)題就是如何獲得這些指標(biāo)的量化數(shù)值。軟件測(cè)試是驗(yàn)證這些指標(biāo)的有效方法。通過(guò)測(cè)試可以在一定程度上模擬真實(shí)的使用場(chǎng)景，并得到質(zhì)量指標(biāo)的具體水平。如果測(cè)試發(fā)現(xiàn)某些指標(biāo)無(wú)法達(dá)到要求，則需要對(duì)系統(tǒng)進(jìn)行改進(jìn)，以求通過(guò)測(cè)試。測(cè)試的通過(guò)指標(biāo)是根據(jù)質(zhì)量的需求來(lái)定義的，系統(tǒng)通過(guò)了測(cè)試，可以從量化的角度說(shuō)明它符合需求。
正確性（Correctness）反映了實(shí)現(xiàn)的功能達(dá)到設(shè)計(jì)規(guī)范并滿足用戶需求的程度。這是功能性質(zhì)量的基本指標(biāo)。正確性可以通過(guò)功能測(cè)試來(lái)驗(yàn)證。
可靠性（Reliability）衡量在規(guī)定的時(shí)間和條件下，系統(tǒng)維持其性能水準(zhǔn)的程度。這是結(jié)構(gòu)性需求的重要指標(biāo)。對(duì)于企業(yè)級(jí)的應(yīng)用系統(tǒng)，對(duì)可靠性通常都有很高的要求。可靠性指標(biāo)可以通過(guò)系統(tǒng)可靠性測(cè)試獲取。
易用性（Usability）反映用戶掌握軟件操作及理解軟件事務(wù)所需付出的時(shí)間及努力程度。具體的指標(biāo)諸如界面是否友好，是否有在線幫助，是否提供容易理解的異常信息等。易用性指標(biāo)通常由功能測(cè)試獲得。
可移植性（Portability）衡量系統(tǒng)從一個(gè)平臺(tái)轉(zhuǎn)移到另一個(gè)平臺(tái)的容易程度，包括把程序從一種軟/硬件環(huán)境轉(zhuǎn)移到另一種軟/硬件環(huán)境的容易程度等。大型軟件的安裝和部署可能也是一個(gè)復(fù)雜的過(guò)程，高可移植性的系統(tǒng)應(yīng)該是容易安裝和更新的。此外，企業(yè)級(jí)系統(tǒng)對(duì)多國(guó)語(yǔ)言的支持程度也是可移植性的一個(gè)衡量指標(biāo)。可移植性在多平臺(tái)的功能、系統(tǒng)測(cè)試、安裝測(cè)試、多國(guó)語(yǔ)言測(cè)試中得到驗(yàn)證。
可遷移性（Migratability）衡量系統(tǒng)版本升級(jí)的容易程度。大型系統(tǒng)的遷移通常是一件非常復(fù)雜的事情，可遷移性需要通過(guò)遷移測(cè)試來(lái)驗(yàn)證。
效率（Efficiency）衡量系統(tǒng)執(zhí)行某功能所需的計(jì)算機(jī)資源和時(shí)間有效程度，包括功能和性能是否經(jīng)過(guò)優(yōu)化，是否檢驗(yàn)內(nèi)存泄漏或溢出問(wèn)題等。效率是系統(tǒng)測(cè)試的一個(gè)重要檢測(cè)點(diǎn)。
可維護(hù)性、可擴(kuò)展性（Maintainability、Scalability）反映當(dāng)環(huán)境改變或出現(xiàn)錯(cuò)誤時(shí)，執(zhí)行修改或修復(fù)的難易程度。系統(tǒng)的設(shè)計(jì)是否很好地考慮日后擴(kuò)展的需求，架構(gòu)是否靈活等因素決定可維護(hù)性和可擴(kuò)展性。系統(tǒng)測(cè)試可以獲得系統(tǒng)的可擴(kuò)展性指標(biāo)。
健壯性（Robustness）衡量系統(tǒng)在接受異常或錯(cuò)誤輸入后能否返回正確的提示信息且不影響正確運(yùn)作的指標(biāo)。詳細(xì)的功能測(cè)試是檢驗(yàn)健壯性的主要方法。
安全性（Security）衡量系統(tǒng)對(duì)攻擊性或不當(dāng)?shù)脑L問(wèn)的抵御能力，檢測(cè)的方向包括在受到?jīng)]有授權(quán)的訪問(wèn)時(shí)系統(tǒng)對(duì)自身及數(shù)據(jù)的保護(hù)程度，系統(tǒng)的安全機(jī)制是否正確地實(shí)現(xiàn)，系統(tǒng)在受到攻擊時(shí)是否能保持正常的業(yè)務(wù)運(yùn)作等。系統(tǒng)測(cè)試有專門的測(cè)試涵蓋安全性的審核。
有了諸多衡量質(zhì)量的指標(biāo)，軟件的好壞就可以量化了，可見(jiàn)有效的測(cè)試是軟件質(zhì)量的重要保證。測(cè)試除了提供量化指標(biāo)以外，還可以作為動(dòng)力來(lái)驅(qū)動(dòng)開(kāi)發(fā)的進(jìn)度，這就是極限編程倡導(dǎo)的測(cè)試驅(qū)動(dòng)開(kāi)發(fā)（Test-Driven Development，TDD）。
測(cè)試驅(qū)動(dòng)開(kāi)發(fā)的要點(diǎn)是先寫測(cè)試程序，然后再編碼實(shí)現(xiàn)使其通過(guò)測(cè)試。測(cè)試可以有效推動(dòng)需求的實(shí)現(xiàn)，但是測(cè)試場(chǎng)景的覆蓋度不足以涵蓋所有的分支，因此，開(kāi)發(fā)前的完整設(shè)計(jì)及第一輪開(kāi)發(fā)過(guò)后的詳細(xì)功能測(cè)試能夠避免測(cè)試場(chǎng)景的覆蓋問(wèn)題。這樣，測(cè)試場(chǎng)景相當(dāng)于提供給開(kāi)發(fā)人員的指導(dǎo)性主線，加快主要功能點(diǎn)的開(kāi)發(fā)速度。
測(cè)試驅(qū)動(dòng)開(kāi)發(fā)的方法為開(kāi)發(fā)提供一種新的方式，測(cè)試處于主導(dǎo)的位置。但測(cè)試的更重要作用還是在于提供衡量軟件質(zhì)量的量化指標(biāo)。因此，我們認(rèn)為，軟件的好壞是由測(cè)試決定的。
1.2.3 測(cè)試也有大學(xué)問(wèn)
既然軟件測(cè)試對(duì)于軟件質(zhì)量有非常重要的影響，那么，如何有效地進(jìn)行軟件測(cè)試，則是非常值得關(guān)注的問(wèn)題。
測(cè)試的目標(biāo)是發(fā)現(xiàn)軟件系統(tǒng)中存在的缺陷，這其中有一個(gè)關(guān)鍵的原則--盡可能早地發(fā)現(xiàn)問(wèn)題。
在軟件開(kāi)發(fā)的前期甚至是設(shè)計(jì)階段，某些缺陷可能已經(jīng)存在，然而在這個(gè)時(shí)期要發(fā)現(xiàn)問(wèn)題并不是件容易的事情。原因是多方面的。首先，在系統(tǒng)的很多功能模塊尚未開(kāi)發(fā)完善時(shí)，由于相互依賴關(guān)系而引起的缺陷一般難以被發(fā)現(xiàn)，因?yàn)槿毕葜挥性谙到y(tǒng)進(jìn)行了集成以后才會(huì)真正暴露出來(lái)。例如，有些模式在簡(jiǎn)單的系統(tǒng)架構(gòu)下可以帶來(lái)不錯(cuò)的開(kāi)發(fā)效率和運(yùn)行效率，但是隨著新模塊的加入，這種架構(gòu)的集成復(fù)雜度會(huì)急劇提高，系統(tǒng)原有的"精簡(jiǎn)"優(yōu)勢(shì)在這種條件下不復(fù)存在，新模塊的運(yùn)行效率會(huì)受到明顯影響。這是個(gè)很明顯的缺陷，但是這種設(shè)計(jì)的缺陷在新模塊加入以前不可能很容易地暴露。其次，有些缺陷在開(kāi)發(fā)前期看起來(lái)也許算不上是個(gè)缺陷，測(cè)試人員很容易忽略或僅僅把它當(dāng)做一個(gè)"事件"。這種問(wèn)題的嚴(yán)重性隨著開(kāi)發(fā)的深入才會(huì)逐漸顯現(xiàn)。一個(gè)典型的例子是數(shù)據(jù)庫(kù)查詢的效率問(wèn)題。使用全表掃描（Table Scan）可以獲取完整的數(shù)據(jù)集合，全表掃描的效率缺陷在開(kāi)發(fā)初期常常不容易被察覺(jué)，隨著越來(lái)越多的數(shù)據(jù)和查詢的加入，全表掃描的問(wèn)題才會(huì)變得越加明顯。另外，在開(kāi)發(fā)周期的前期，項(xiàng)目人員通常會(huì)把注意力放在開(kāi)發(fā)新功能上，在測(cè)試方面投入的資源相對(duì)較少，因此發(fā)現(xiàn)問(wèn)題的可能性也降低了。
從圖1-2中可以看到，一個(gè)相同的問(wèn)題如果在不同的開(kāi)發(fā)階段解決，所需的開(kāi)銷是不一樣的。越到開(kāi)發(fā)后期，解決問(wèn)題所需的開(kāi)銷越大。
有人對(duì)“盡可能早地發(fā)現(xiàn)問(wèn)題”這個(gè)觀點(diǎn)持懷疑態(tài)度。既然問(wèn)題在開(kāi)發(fā)的前期隱藏得非常好，而在后期更容易暴露，那為什么不干脆等到后期才專注于缺陷的發(fā)現(xiàn)和解決？這樣不是更能降低測(cè)試的成本嗎？
就測(cè)試本身而言，這種想法有道理，減小測(cè)試的開(kāi)銷同時(shí)讓更多的問(wèn)題暴露，似乎是個(gè)很理想的策略。然而，從軟件項(xiàng)目的整體上考慮，這就是個(gè)非常糟糕的選擇了。同一個(gè)缺陷，在不同的時(shí)間段發(fā)現(xiàn)，對(duì)其進(jìn)行修復(fù)所需的努力很可能極不相同。一個(gè)典型的例子是使用了不恰當(dāng)?shù)南⒛Ｊ蕉鴮?dǎo)致系統(tǒng)與外圍通信效率低下的問(wèn)題。如果問(wèn)題在需求分析階段即被發(fā)現(xiàn)，那么只要考慮更換一種消息模式。因?yàn)檫@個(gè)過(guò)程中任何實(shí)質(zhì)性的勞動(dòng)都不存在，所以并不需要額外的勞動(dòng)開(kāi)銷。如果問(wèn)題是在設(shè)計(jì)階段出現(xiàn)的，那么更換消息模式還是必需的，同時(shí)，還需要考慮更換模式對(duì)外圍接口的設(shè)計(jì)是否有影響。當(dāng)然，這種考慮主要是評(píng)估性質(zhì)的。假如是在功能實(shí)現(xiàn)的前期發(fā)現(xiàn)問(wèn)題，那么除了評(píng)估對(duì)外圍的影響以外，重寫一部分代碼是必不可少的。隨著開(kāi)發(fā)的進(jìn)一步推進(jìn)，可能有很多模塊對(duì)消息模塊存在依賴，如果針對(duì)依賴的開(kāi)發(fā)已經(jīng)完成以后才發(fā)現(xiàn)問(wèn)題，不可避免地，相應(yīng)的依賴模塊的設(shè)計(jì)和實(shí)現(xiàn)就得重做，所需的代價(jià)變得更加高昂。
軟件開(kāi)發(fā)是一個(gè)迭代和累積的過(guò)程，越是底層的缺陷，發(fā)現(xiàn)的時(shí)間越晚，修復(fù)缺陷的代價(jià)越高。軟件開(kāi)發(fā)項(xiàng)目一般是以工程的方式運(yùn)作的，作為工程會(huì)有明確的目標(biāo)，因此，風(fēng)險(xiǎn)的控制非常重要。如果已知缺陷存在而無(wú)法修復(fù)，軟件產(chǎn)品是無(wú)法發(fā)布的。如果在后期發(fā)現(xiàn)嚴(yán)重問(wèn)題，修復(fù)難度很大或者需要大面積的改動(dòng)，項(xiàng)目的風(fēng)險(xiǎn)會(huì)陡然增加。項(xiàng)目組面臨的選擇只有延期完成或宣布項(xiàng)目失敗。很多失敗的項(xiàng)目都是因?yàn)槎啻蔚难悠诙媸〉摹？梢?jiàn)，從項(xiàng)目整體的角度而言，“盡可能早地發(fā)現(xiàn)問(wèn)題”才能降低風(fēng)險(xiǎn)，而問(wèn)題越遲發(fā)現(xiàn)，項(xiàng)目的風(fēng)險(xiǎn)越高，對(duì)整體進(jìn)度的影響越大。
作為測(cè)試專家，應(yīng)該考慮的問(wèn)題是如何更早地發(fā)現(xiàn)缺陷，以及有效地解決缺陷。
正如之前曾經(jīng)提及的，開(kāi)發(fā)的前期，缺陷可能已經(jīng)存在但不容易暴露。那么，有沒(méi)有辦法讓問(wèn)題“提前”暴露呢？
發(fā)現(xiàn)問(wèn)題的可行方法有兩類，分別是分析方法 和測(cè)試方法。分析主要使用邏輯分析推理的方法發(fā)現(xiàn)缺陷和評(píng)估問(wèn)題的嚴(yán)重性，并根據(jù)所處的階段得到解決的方法。例如，有一個(gè)報(bào)表系統(tǒng)，起初是使用直接SQL查詢的方式實(shí)現(xiàn)報(bào)表功能的。對(duì)實(shí)現(xiàn)的方法進(jìn)行分析，可以發(fā)現(xiàn)，要生成條件復(fù)雜的報(bào)表，需要完成執(zhí)行效率較低的查詢語(yǔ)句，執(zhí)行查詢的時(shí)候是需要給相應(yīng)的表格加鎖的，因此有可能影響對(duì)相同的表有業(yè)務(wù)操作的模塊。單從報(bào)表模塊的設(shè)計(jì)和功能實(shí)現(xiàn)而言，使用直接的SQL查詢已經(jīng)可以滿足功能上的需求，但綜合考慮運(yùn)行效率和跨模塊的相互影響，通過(guò)分析可以得到結(jié)論--報(bào)表系統(tǒng)使用直接SQL查詢的方法，在系統(tǒng)完成實(shí)現(xiàn)后會(huì)帶來(lái)性能和系統(tǒng)級(jí)別的缺陷。
測(cè)試和分析人員可以針對(duì)這個(gè)問(wèn)題直接創(chuàng)建一個(gè)缺陷，雖然這并不是通過(guò)測(cè)試發(fā)現(xiàn)的。針對(duì)這個(gè)問(wèn)題，項(xiàng)目組有機(jī)會(huì)在設(shè)計(jì)階段修復(fù)這個(gè)潛在的缺陷。這里使用“潛在的”作為定語(yǔ)，是因?yàn)檫@個(gè)缺陷沒(méi)有經(jīng)過(guò)測(cè)試證實(shí)，而是通過(guò)分析的方法推導(dǎo)認(rèn)定的。但由于理?yè)?jù)充分，本質(zhì)上這個(gè)缺陷和測(cè)試發(fā)現(xiàn)的缺陷是一樣的。為了提高查詢效率，考慮使用物化表存儲(chǔ)報(bào)表的內(nèi)容，再通過(guò)篩選物化表的記錄生成報(bào)表。因?yàn)橛辛宋锘恚梢园焉a(chǎn)數(shù)據(jù)和報(bào)表數(shù)據(jù)最大限度地隔離，避免了數(shù)據(jù)鎖定而引起的沖突；物化表從性質(zhì)上也保證了查詢的效率。重新設(shè)計(jì)和實(shí)現(xiàn)以后，可以認(rèn)為對(duì)這個(gè)缺陷有了一個(gè)解決方法。最后要做的是通過(guò)嚴(yán)謹(jǐn)?shù)臏y(cè)試證實(shí)問(wèn)題已經(jīng)解決或者潛在的問(wèn)題得到避免。測(cè)試的方式是對(duì)設(shè)計(jì)分析時(shí)認(rèn)為有問(wèn)題的場(chǎng)景進(jìn)行模擬，如果在這種場(chǎng)景下沒(méi)有出現(xiàn)此前認(rèn)為會(huì)出現(xiàn)的問(wèn)題，那么這個(gè)缺陷解決方案就被認(rèn)為是可以接受的。
分析方法不需要等待缺陷目標(biāo)的開(kāi)發(fā)完成并使用測(cè)試進(jìn)行驗(yàn)證，然而，這種方法對(duì)分析人員技能要求較高。分析人員在需求分析和設(shè)計(jì)方面的經(jīng)驗(yàn)必須比較豐富，才能準(zhǔn)確定位問(wèn)題所在。實(shí)施難度相對(duì)較低的是測(cè)試方法。測(cè)試方法設(shè)計(jì)出有針對(duì)性的場(chǎng)景，并在測(cè)試環(huán)境上模擬該場(chǎng)景。如果測(cè)試的輸出和預(yù)期的輸出存在差異，則能證實(shí)問(wèn)題的存在。然而，要使用測(cè)試的方法發(fā)現(xiàn)問(wèn)題，對(duì)測(cè)試環(huán)境是有要求的。要運(yùn)行測(cè)試場(chǎng)景驗(yàn)證用例是否成功，前提是測(cè)試的場(chǎng)景能夠在測(cè)試環(huán)境中正常運(yùn)作。黑盒測(cè)試方式的測(cè)試用例一般是端對(duì)端（End-To-End）的，也就是測(cè)試用例是個(gè)完整的業(yè)務(wù)場(chǎng)景，而不僅僅是一個(gè)單元。在開(kāi)發(fā)的早期，要走通一個(gè)端對(duì)端的用例大多情況下只是個(gè)奢望。可用的方式是使用“假對(duì)象”（Mock Object）或模擬器把端對(duì)端場(chǎng)景中沒(méi)有完成實(shí)現(xiàn)的部分補(bǔ)充完整。
例如，在一個(gè)面向服務(wù)的體系結(jié)構(gòu)（SOA）開(kāi)發(fā)模式下的系統(tǒng)，如果某些流程中服務(wù)并沒(méi)有開(kāi)發(fā)完成，但目標(biāo)測(cè)試用例必須用到這個(gè)沒(méi)完成的服務(wù)，為了讓用例完整地走通，可以設(shè)計(jì)一個(gè)簡(jiǎn)單的假對(duì)象。假對(duì)象不實(shí)現(xiàn)任何邏輯，對(duì)于任何輸入，僅返回符合格式要求的特點(diǎn)數(shù)據(jù)。有了假對(duì)象返回的內(nèi)容，業(yè)務(wù)流程就能以這種臨時(shí)的方式完成。因?yàn)闇y(cè)試的重點(diǎn)在于已經(jīng)完成的部分，因此假對(duì)象沒(méi)有任何業(yè)務(wù)邏輯，也不會(huì)影響測(cè)試的有效性。如果測(cè)試驗(yàn)證失敗，則證明測(cè)試目標(biāo)存在缺陷。這時(shí)候可以對(duì)缺陷進(jìn)行跟蹤和解決。為了在早期發(fā)現(xiàn)問(wèn)題，使用假對(duì)象或"假業(yè)務(wù)數(shù)據(jù)"來(lái)完成測(cè)試，都是常用的"主動(dòng)測(cè)試"策略。
無(wú)論是使用分析方法還是測(cè)試方法發(fā)現(xiàn)的問(wèn)題，都通過(guò)創(chuàng)建缺陷來(lái)跟蹤。高效的項(xiàng)目組一般都有完善的缺陷跟蹤機(jī)制和系統(tǒng)，使應(yīng)有的資源流向相應(yīng)缺陷并盡早解決問(wèn)題。缺陷跟蹤系統(tǒng)定義了缺陷的生命周期和相關(guān)信息 ，如圖1-3所示。
缺陷（Bug），一般是指系統(tǒng)存在的問(wèn)題或者需要加強(qiáng)的細(xì)節(jié)。從廣義的角度而言，系統(tǒng)中任何需要修改或強(qiáng)化的任務(wù)都可以歸類為缺陷。發(fā)現(xiàn)缺陷的人員在系統(tǒng)中創(chuàng)建一個(gè)新的缺陷，對(duì)于這個(gè)缺陷而言，創(chuàng)建的人是缺陷的創(chuàng)始人（Originator）。創(chuàng)始人會(huì)明確說(shuō)明缺陷的內(nèi)容，包括測(cè)試的時(shí)間、環(huán)境、測(cè)步和問(wèn)題的描述、建議等。缺陷創(chuàng)建后，它處于開(kāi)啟（Open）狀態(tài)，在任何時(shí)候它都會(huì)有一個(gè)直接的負(fù)責(zé)人（Owner），負(fù)責(zé)人是必須對(duì)缺陷采取行動(dòng)的那個(gè)人。負(fù)責(zé)人的義務(wù)是推動(dòng)缺陷的解決。初始化的時(shí)候，系統(tǒng)會(huì)根據(jù)一定的規(guī)則指定缺陷的負(fù)責(zé)人，創(chuàng)始人或者被指定的負(fù)責(zé)人可以重新指定（Assign）更適合解決該缺陷的人員為新的負(fù)責(zé)人。
針對(duì)一個(gè)開(kāi)啟狀態(tài)的缺陷，首要的任務(wù)是驗(yàn)證其有效性，因?yàn)樵诓簧偾闆r下，缺陷對(duì)應(yīng)的問(wèn)題是由于不符合規(guī)定的操作導(dǎo)致的。遇到這種缺陷時(shí)，負(fù)責(zé)人僅需要把缺陷退回（Return）給創(chuàng)始人。如果缺陷被返回，創(chuàng)始人可以再次確認(rèn)缺陷是否合法，假如缺陷確實(shí)合法，則可以重新開(kāi)啟（Reopen）缺陷，使缺陷回到開(kāi)啟狀態(tài)；如果證實(shí)缺陷僅是不符合規(guī)定的操作引起的問(wèn)題，則可以把它取消（Cancel）。取消狀態(tài)是缺陷生命周期的其中一種終結(jié)狀態(tài)。如果負(fù)責(zé)人經(jīng)過(guò)驗(yàn)證后證實(shí)了缺陷的有效性，那么下一步的工作就是謀求解決方法。開(kāi)始考慮解決方案前，需要接受（Accept）這個(gè)缺陷，使缺陷的狀態(tài)從開(kāi)啟轉(zhuǎn)成工作中（Working）。
在工作中狀態(tài)下，缺陷的負(fù)責(zé)人可以與測(cè)試人員（缺陷創(chuàng)始人）及相關(guān)人員一同討論問(wèn)題的原因和解決辦法，并根據(jù)方案對(duì)文檔或系統(tǒng)進(jìn)行修改。修改完成以后，負(fù)責(zé)人需要把缺陷的狀態(tài)改為驗(yàn)證（Verify）狀態(tài)，并創(chuàng)建一個(gè)驗(yàn)證記錄（Verification Record）供缺陷創(chuàng)始人驗(yàn)證。這時(shí)缺陷的創(chuàng)始人同時(shí)也是負(fù)責(zé)人。如果驗(yàn)證通過(guò)，問(wèn)題已經(jīng)解決，則缺陷創(chuàng)始人可以認(rèn)可（Accept）這個(gè)解決方案，這時(shí)缺陷的狀態(tài)會(huì)變成認(rèn)可（Accept）。系統(tǒng)可以關(guān)閉（Close）處于認(rèn)可狀態(tài)的缺陷。
從開(kāi)啟到關(guān)閉狀態(tài)的流程，是缺陷生命周期的主要流程。在任何時(shí)候，基于新線索的發(fā)現(xiàn)，缺陷創(chuàng)始人都可以取消缺陷。有一些問(wèn)題可能在不同的測(cè)試用例中以不同的方式暴露出來(lái)，或者分別被不同的測(cè)試人員發(fā)現(xiàn)，這種問(wèn)題所被報(bào)出的缺陷最終都會(huì)被歸結(jié)為同一個(gè)缺陷。缺陷負(fù)責(zé)人僅需要跟蹤第一個(gè)被創(chuàng)建的缺陷（主缺陷），而其他缺陷會(huì)被標(biāo)上重復(fù)（Duplicate）的記號(hào)。然后，驗(yàn)證缺陷的步驟無(wú)論是對(duì)主缺陷還是重復(fù)缺陷的創(chuàng)建人都是必需的。
這種基于狀態(tài)的缺陷生命周期管理模型有利于跟蹤缺陷的狀況并推動(dòng)缺陷的及早解決。缺陷的屬性中會(huì)包括重要性、嚴(yán)重性、發(fā)現(xiàn)時(shí)間等信息，根據(jù)這些信息，項(xiàng)目組可以把更多資源分配給更重要的、嚴(yán)重的和緊急的缺陷。
測(cè)試專家在大多數(shù)情況下會(huì)作為問(wèn)題的發(fā)現(xiàn)者出現(xiàn)，因而也順理成章地成為缺陷處理的推動(dòng)者。如何更早地、有效地發(fā)現(xiàn)問(wèn)題，是測(cè)試專家的一項(xiàng)非常有技術(shù)含量的工作。而測(cè)試專家的另一項(xiàng)有技術(shù)含量的工作，就是發(fā)現(xiàn)問(wèn)題后的問(wèn)題分析（Problem Determination，PD）。
開(kāi)發(fā)人員要做的，遠(yuǎn)不僅限于開(kāi)發(fā)；而測(cè)試專家要做的，也遠(yuǎn)不僅限于測(cè)試。系統(tǒng)出現(xiàn)缺陷好比一個(gè)人生病了，而問(wèn)題分析的過(guò)程則好比醫(yī)生對(duì)病情的診斷，問(wèn)題分析的主要任務(wù)是找到問(wèn)題的原因。只有發(fā)現(xiàn)了問(wèn)題的原因，才有對(duì)癥下藥解決問(wèn)題的可能。
問(wèn)題分析常用的系統(tǒng)方法有兩種--自頂向下（Top-Down）和自底向上（Bottom-Up）方法。在分析錯(cuò)綜復(fù)雜的問(wèn)題，如系統(tǒng)級(jí)別的結(jié)構(gòu)問(wèn)題或性能問(wèn)題時(shí)，這兩種方法能夠有效地定位問(wèn)題。
自頂向下方法，其著眼處在于整體。使用自頂向下方法，首先應(yīng)該認(rèn)同的一個(gè)觀點(diǎn)是，系統(tǒng)整體的問(wèn)題可能是系統(tǒng)某個(gè)部分的原因引起的，而這個(gè)局部的問(wèn)題放大后會(huì)在系統(tǒng)的宏觀級(jí)別上表現(xiàn)出來(lái)。通過(guò)觀察和分析存在缺陷的系統(tǒng)整體情況，把系統(tǒng)分成若干部分，并逐個(gè)部分判斷可能存在的問(wèn)題。判斷確定“嫌疑”所在后，使用調(diào)整--測(cè)試的方法證實(shí)判斷的正確性。如果判斷正確，宏觀的問(wèn)題確實(shí)存在于系統(tǒng)中，那么可以對(duì)這個(gè)細(xì)節(jié)進(jìn)行修改，解決問(wèn)題；如果判斷不正確，則需要重現(xiàn)判斷。從宏觀到微觀的過(guò)程也可能不是一步到位的，在復(fù)雜的系統(tǒng)中，這個(gè)過(guò)程可能會(huì)分為多個(gè)級(jí)別的細(xì)化來(lái)完成。有時(shí)候，整體的問(wèn)題可能是由多個(gè)劃分同時(shí)存在的問(wèn)題引起的。通過(guò)逐個(gè)驗(yàn)證測(cè)試系統(tǒng)劃分的“地毯式排查”方式，可以掃清所有“患處”。
一個(gè)系統(tǒng)的局部分解方式通常是穩(wěn)定的，使用自頂向下方法的理念在于通過(guò)這種穩(wěn)定的分解，使用窮舉方式最終可以確切地找到發(fā)生問(wèn)題的局部。其好處是對(duì)于經(jīng)驗(yàn)不多的人員，使用自頂向下法也能最終找到問(wèn)題所在。當(dāng)然，缺乏經(jīng)驗(yàn)也可能帶來(lái)苦頭--對(duì)某些局部的驗(yàn)證也許是不需要的。
相對(duì)而言，自底向上方法對(duì)分析者的能力要求較高。使用自底向上方法的前提是，承認(rèn)缺陷的全部或部分是由于系統(tǒng)局部細(xì)節(jié)的問(wèn)題引起的。分析時(shí)，根據(jù)系統(tǒng)表面看到的蛛絲馬跡，直接判斷出現(xiàn)問(wèn)題的根源，并驗(yàn)證這個(gè)判斷是否正確。實(shí)踐上，可以從最底一層起，對(duì)系統(tǒng)在邏輯上或功能上進(jìn)行劃分，然后設(shè)計(jì)特定的測(cè)試場(chǎng)景，有針對(duì)性地驗(yàn)證這些劃分是否正常。因?yàn)閷?duì)系統(tǒng)進(jìn)行過(guò)劃分，所以一旦驗(yàn)證性的測(cè)試重現(xiàn)了問(wèn)題，則能夠比較清晰地定位究竟是哪個(gè)部分存在問(wèn)題。
這個(gè)從下往上的判斷過(guò)程當(dāng)然是很有講究的，遭遇問(wèn)題的經(jīng)驗(yàn)、對(duì)問(wèn)題的“嗅覺(jué)”，都有助于提高判斷的準(zhǔn)確性。復(fù)雜的系統(tǒng)中可能有問(wèn)題的細(xì)節(jié)成千上萬(wàn)，作為分析人員，首先應(yīng)該對(duì)系統(tǒng)的這些細(xì)節(jié)及其在整體中的作用比較熟悉，其次要擁有直達(dá)問(wèn)題根源的“直覺(jué)”。如果缺少這種一擊即中要害的技能，自底向上的問(wèn)題分析方法可能并不奏效。
值得注意的是，無(wú)論是自頂向下還是自底向上的問(wèn)題分析方法，其本質(zhì)其實(shí)都是準(zhǔn)確地重現(xiàn)和定位問(wèn)題。只要問(wèn)題得以有效重現(xiàn)和定位，離找到解決的辦法就不遙遠(yuǎn)了。
自頂向下和自底向上方法可通用于一般各種測(cè)試類型，針對(duì)不同測(cè)試類型，這兩種方法的具體使用方式可能存在不同之處。
發(fā)現(xiàn)、定位和解決問(wèn)題的方法，是測(cè)試人員的核心技能。由于測(cè)試的門類眾多，針對(duì)系統(tǒng)的測(cè)試也有多種角度，這些方法在不同的測(cè)試中會(huì)有不同的具體表現(xiàn)。
經(jīng)過(guò)與凱文的談話，小艾覺(jué)得自己對(duì)測(cè)試本身及其重要性、測(cè)試的技巧和竅門等方面的理解都加深不少。許多要點(diǎn)其實(shí)小艾在日常工作中已經(jīng)有所接觸，只是缺少系統(tǒng)的總結(jié)和提煉，而其他一些能力，則需要通過(guò)更多積累才能達(dá)到。凱文提醒道：“作為測(cè)試專家，核心的能力其實(shí)還是思考的能力。五花八門的測(cè)試方法和技術(shù)，得通過(guò)自己的實(shí)踐、總結(jié)和思考，轉(zhuǎn)化成系統(tǒng)的測(cè)試方法論。當(dāng)一套屬于你自己的測(cè)試方法論已經(jīng)形成的時(shí)候，意味著你已經(jīng)從專家成長(zhǎng)為高手了。測(cè)試，在這種角度看，就是一個(gè)完備的哲學(xué)體系。”
（未完待續(xù)）
相關(guān)鏈接：
一個(gè)軟件測(cè)試工程師的成長(zhǎng)日記（連載一）