軟件測試的階段性
bug的發現和管理
秘密武器：測試用例和測試計劃
要想真正保證軟件項目如期完成，不僅取決于開發人員，更取決于測試人員。
項目經理經常犯的錯誤之一，是以為只要雇用軟件工程師就行，其他的人都不必要，或是讓軟件工程師占整個團隊很高的比例。他們也許認為開發人員越多，寫出來的程序也越多，這是錯誤的概念。項目的目的是為了完成軟件，而不是完成更多的程序代碼。在開發團隊中，實際有一些工作是不適宜交給軟件工程師做的。
要想真正保證軟件項目如期完成，不僅取決于開發人員，更取決于測試人員。軟件開發好像是在趕進度，而不是在演奏交響樂：交響樂是和諧有序而優雅的，而軟件開發卻更像是一堆排山倒海、蜂擁而至的工作。交響樂任何兩個音符都不能相互抵觸，整體表現出來的才是一段優美的音樂。在一切都不確定的軟件開發過程中，讓測試人員的“Bug指揮棒”來使大家知道什么時候該表現，知道什么時候該退后一點，正是微軟將軟件開發過程帶向高潮的不二法則！
測試組不是開發組的助手
似乎沒有誰比微軟更重視測試的力量。在微軟的產品組中，測試組是與產品規劃組、產品管理組、開發組和用戶教育組等并列的隊伍。測試與軟件成本的關系是，發現產品中存在的問題越早，開發費用越低，產品質量越高，軟件發布后維護費用越低。在微軟開發周期的四個階段中，測試的目的在于保證軟件質量，滿足設計的要求和客戶的需求；系統地揭示出不同類型的錯誤，并耗費最少時間和最小工作量；降低軟件的開發成本和維護成本。
軟件開發過程中開發人員很可能因為一些偶發的小事，或某種無關的靈感而不知不覺中偏離了實際的需要，暫時忘記了什么才是產品最該有的功能，把他們拉回原定軌道中的正是測試工程師。測試人員的職責是配合整個項目組保證按照預定的時間表完成達到預定設計目標的產品。測試人員的工作是具有整體性、持續性的軟件開發活動中的一環，而不是偶爾拿出來點綴一下。軟件產品的質量是由用于測試的資源、產品的功能和項目的時間表來決定的，是三者的平衡。對任何的一個產品組來說，無論是主觀，還是客觀上，都要重視測試工程師的存在，這是產品質量的重要保證。
羅馬不是一天建成的。早期的微軟開發隊伍中也沒有設立單獨的測試組。那個時候的微軟幾百個人做幾個項目，通常是程序員寫完程序了，自己測試一下就算完事。后來微軟的項目越來越大，軟件越來越復雜，寫代碼和測試的工作要平行進行，漸漸產生了獨立的測試組。一個重要的數字是，微軟產品組中測試人員和開發人員的比例大約是1∶1。其實，要想真正保證軟件項目如期完成，不僅取決于開發人員，更取決于測試人員。
測試組獨立于開發組之外的好處在于，程序員總是傾向于認為自己設計的代碼足夠好，獨立的測試組可以使測試人員在不帶任何假設的情況下從不同的角度來測試軟件，有利于保證軟件的質量始終得到控制，并使測試資源得到重用和不斷改進。但是，測試組獨立于開發組之外，并不意味著程序員寫完代碼就扔過“墻壁”，等待測試工程師找到所有的bug，當測試人員認為他的工作就是測試程序，而開發人員認為他的工作就是寫程序給測試人員測試時，如果你是項目經理，要小心了！開發人員的優越感會使測試人員感覺自己是被歧視的少數民族，這勢必會影響到軟件的品質。程序人員在寫完代碼、改正問題后必須完成基本的測試，比如代碼的路徑測試、單元測試和問題驗證等。產品質量控制，存在于開發過程的每一個環節中。
有一個笑話，微軟的測試人員工作時間長了，都有挑刺兒的習慣，下了班見了太太做的飯都要評價一番。對微軟來說，那些聰明、細致、認真，有耐心，追求完美的產品，對用戶有負責任的態度，思維方式獨立又開放，既有足夠的技術背景，但又愿意學習新的技術的測試工程師更容易得到“老板”的青睞。
軟件測試的階段性
軟件開發的過程就像是一支隊伍正在急行軍，但跑著跑著這支隊伍就會“散了架”，設立里程碑的作用就仿佛是到了某一個“點”，大家必須要重新整理步伐，實現同步。就測試組的工作模式而言，測試的階段劃分是與項目的進度相對應的。也就是說，測試人員應當與項目組的其他人員始終保持以相同的步伐“跑步”的狀態，與整個項目的每一個里程碑配合，完成相應的測試工作。
把大項目劃分成若干子項目的里程碑式的開發模式是微軟軟件開發管理的精髓做法，如上一期《微軟研發方法（上）》所述，在微軟的每一個產品開發周期中都有以下幾個重要的里程碑：CC（Code complete:代碼完成）；Beta測試；RC（Release Candidate：候選發布）；RTM（Release To Manufacture:投入生產），測試人員和產品組的其他人員一起，共同達到每一個里程碑。一個完整的測試循環應當包括運行所有的測試用例、Beta標準測試、bug校驗和解所有的bug、隨機測試。好的測試循環能夠保證對軟件質量有一個全面完整的評價，每個里程碑之前至少要有一個完整的測試循環。
在微軟的產品開發周期中，在規劃階段當開發人員在做計劃、編進度，進行功能實現的可行性研究，對計劃的功能進行反饋時，測試人員應當研究規格說明，編寫測試計劃；在第二個階段即開發階段，當開發人員在編寫代碼、測試和調試的同時，測試人員應當開始設計測試用例，開發自動測試工具和程序，熟悉必需的環境、工具、軟件和硬件，不斷地豐富測試用例，直到達到CC（代碼完成）里程碑——這個時候的軟件可以進行一次整體測試，用戶界面可能不完美但能夠工作，可能有很多明顯的bug。
進入開發周期的第三階段，測試人員大顯身手，展開大規模的測試，比如系統級整體測試，交互性和深層測試。測試之后，測試人員應當對新增的功能說“不”，直至達到Bate測試里程碑。達到這個里程碑，意味著所有的Beta致命問題已經被修正和關閉，所有計劃的功能都已經在軟件中并能工作，產品穩定，大部分界面還可以，盡管可能只是一部分，但已經有了在線幫助和用戶手冊，即使是發布了也不會引起負面的影響。
項目經理經常犯的錯誤之一，是以為只要雇用軟件工程師就行，其他的人都不必要，或是讓軟件工程師占整個團隊很高的比例。他們也許認為開發人員越多，寫出來的程序也越多，這是錯誤的概念。項目的目的是為了完成軟件，而不是完成更多的程序代碼。在開發團隊中，實際有一些工作是不適宜交給軟件工程師做的。
要想真正保證軟件項目如期完成，不僅取決于開發人員，更取決于測試人員。軟件開發好像是在趕進度，而不是在演奏交響樂：交響樂是和諧有序而優雅的，而軟件開發卻更像是一堆排山倒海、蜂擁而至的工作。交響樂任何兩個音符都不能相互抵觸，整體表現出來的才是一段優美的音樂。在一切都不確定的軟件開發過程中，讓測試人員的“Bug指揮棒”來使大家知道什么時候該表現，知道什么時候該退后一點，正是微軟將軟件開發過程帶向高潮的不二法則！
測試組不是開發組的助手
似乎沒有誰比微軟更重視測試的力量。在微軟的產品組中，測試組是與產品規劃組、產品管理組、開發組和用戶教育組等并列的隊伍。測試與軟件成本的關系是，發現產品中存在的問題越早，開發費用越低，產品質量越高，軟件發布后維護費用越低。在微軟開發周期的四個階段中，測試的目的在于保證軟件質量，滿足設計的要求和客戶的需求；系統地揭示出不同類型的錯誤，并耗費最少時間和最小工作量；降低軟件的開發成本和維護成本。
軟件開發過程中開發人員很可能因為一些偶發的小事，或某種無關的靈感而不知不覺中偏離了實際的需要，暫時忘記了什么才是產品最該有的功能，把他們拉回原定軌道中的正是測試工程師。測試人員的職責是配合整個項目組保證按照預定的時間表完成達到預定設計目標的產品。測試人員的工作是具有整體性、持續性的軟件開發活動中的一環，而不是偶爾拿出來點綴一下。軟件產品的質量是由用于測試的資源、產品的功能和項目的時間表來決定的，是三者的平衡。對任何的一個產品組來說，無論是主觀，還是客觀上，都要重視測試工程師的存在，這是產品質量的重要保證。
羅馬不是一天建成的。早期的微軟開發隊伍中也沒有設立單獨的測試組。那個時候的微軟幾百個人做幾個項目，通常是程序員寫完程序了，自己測試一下就算完事。后來微軟的項目越來越大，軟件越來越復雜，寫代碼和測試的工作要平行進行，漸漸產生了獨立的測試組。一個重要的數字是，微軟產品組中測試人員和開發人員的比例大約是1∶1。其實，要想真正保證軟件項目如期完成，不僅取決于開發人員，更取決于測試人員。
測試組獨立于開發組之外的好處在于，程序員總是傾向于認為自己設計的代碼足夠好，獨立的測試組可以使測試人員在不帶任何假設的情況下從不同的角度來測試軟件，有利于保證軟件的質量始終得到控制，并使測試資源得到重用和不斷改進。但是，測試組獨立于開發組之外，并不意味著程序員寫完代碼就扔過“墻壁”，等待測試工程師找到所有的bug，當測試人員認為他的工作就是測試程序，而開發人員認為他的工作就是寫程序給測試人員測試時，如果你是項目經理，要小心了！開發人員的優越感會使測試人員感覺自己是被歧視的少數民族，這勢必會影響到軟件的品質。程序人員在寫完代碼、改正問題后必須完成基本的測試，比如代碼的路徑測試、單元測試和問題驗證等。產品質量控制，存在于開發過程的每一個環節中。
有一個笑話，微軟的測試人員工作時間長了，都有挑刺兒的習慣，下了班見了太太做的飯都要評價一番。對微軟來說，那些聰明、細致、認真，有耐心，追求完美的產品，對用戶有負責任的態度，思維方式獨立又開放，既有足夠的技術背景，但又愿意學習新的技術的測試工程師更容易得到“老板”的青睞。
軟件測試的階段性
軟件開發的過程就像是一支隊伍正在急行軍，但跑著跑著這支隊伍就會“散了架”，設立里程碑的作用就仿佛是到了某一個“點”，大家必須要重新整理步伐，實現同步。就測試組的工作模式而言，測試的階段劃分是與項目的進度相對應的。也就是說，測試人員應當與項目組的其他人員始終保持以相同的步伐“跑步”的狀態，與整個項目的每一個里程碑配合，完成相應的測試工作。
把大項目劃分成若干子項目的里程碑式的開發模式是微軟軟件開發管理的精髓做法，如上一期《微軟研發方法（上）》所述，在微軟的每一個產品開發周期中都有以下幾個重要的里程碑：CC（Code complete:代碼完成）；Beta測試；RC（Release Candidate：候選發布）；RTM（Release To Manufacture:投入生產），測試人員和產品組的其他人員一起，共同達到每一個里程碑。一個完整的測試循環應當包括運行所有的測試用例、Beta標準測試、bug校驗和解所有的bug、隨機測試。好的測試循環能夠保證對軟件質量有一個全面完整的評價，每個里程碑之前至少要有一個完整的測試循環。
在微軟的產品開發周期中，在規劃階段當開發人員在做計劃、編進度，進行功能實現的可行性研究，對計劃的功能進行反饋時，測試人員應當研究規格說明，編寫測試計劃；在第二個階段即開發階段，當開發人員在編寫代碼、測試和調試的同時，測試人員應當開始設計測試用例，開發自動測試工具和程序，熟悉必需的環境、工具、軟件和硬件，不斷地豐富測試用例，直到達到CC（代碼完成）里程碑——這個時候的軟件可以進行一次整體測試，用戶界面可能不完美但能夠工作，可能有很多明顯的bug。
進入開發周期的第三階段，測試人員大顯身手，展開大規模的測試，比如系統級整體測試，交互性和深層測試。測試之后，測試人員應當對新增的功能說“不”，直至達到Bate測試里程碑。達到這個里程碑，意味著所有的Beta致命問題已經被修正和關閉，所有計劃的功能都已經在軟件中并能工作，產品穩定，大部分界面還可以，盡管可能只是一部分，但已經有了在線幫助和用戶手冊，即使是發布了也不會引起負面的影響。
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
領測軟件測試網最新更新
