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