系統集成測試:了解你的被測系統-信息收集方法

　　如果看完了第一篇文章，你的答案是Yes。我們可以繼續討論如何做系統集成測試啦。

　　了解你的被測系統(why?)

　　一如既往的，你會想到在一個測試之前，你需要做測試計劃，你需要做測試策略、方案。但在這之前你首先要了解你的被測系統。

　　這里講的被測系統不僅僅指的軟、硬件系統自身。你還需要理解系統所處的上下文環境這包括：所有干系人，項目周期，相關文檔(過程文檔，技術文檔)，部署，相關技術，商務合同，歷史信息，業務知識，法務、文化相關的東西。

　　獲取的信息越多，越有助于我們做出正確的判斷。上述信息都相當重要，有時候會影響到系統集成測試的成敗，甚至項目的成敗。下面舉2個例子：

　　1.某電信項目的總包商對某個分包商拿到的子系統業務的復雜度認識不足，簽署的項目主計劃中確定在項目較晚階段才開始做集成測試，結果發現大量問題，造成項目延期5個月。而合同中項目逾期的賠款規定讓總包商沒有賺到利潤。

　　2.某大型項目(系統升級類型)，在集成測試團隊花費了很多精力梳理業務場景(BPS)后，一名業務分析師發現：有一份非常好的業務場景定義文檔靜靜的躺在配置管理庫的歷史文檔區，這份文檔幾乎可以直接被拿來使用。這時候，幾十個人月已經被浪費了。

　　3.某大型項目，在集成測試進行過半后，得到一個消息，某個測試過的主業務場景，這令工作了幾個星期的測試人員十分沮喪。而造成這一切的是因為一次變更會議，測試經理沒有參加，也沒有得到相應的郵件或者其它形式的變更通知(我們當然要責怪項目管理的不堪，但沒有及時獲取變更也是浪費造成的主要原因)。

　　有人肯定要問了，這些信息都要掌握?豈不是頭都要爆了?上述的信息量肯定會讓一個測試經理頭大，但，這就是他的工作。負責集成測試的測試經理50%以上的時間應該方法信息的獲取與分析上。你也許要說：如果嚴格依照軟件工程，測試經理根本不用那么費勁就能獲取這些信息。我只能說這么想圖樣圖森破，或者你是神仙。在我和我認識的所有測試經理經歷過的系統集成測試案例中，過程非常順暢，結果非常成功的不足1%，也許不足0.1%。涉及的干系人越多，干系方越多，問題也就越多，有時候是指數級增長。這些不都是測試經理能夠搞定的，但沒有非常好的信息獲取能力，分析能力，沒有很強的管理協調能力，是很難做好系統集成測試的。

　　了解你的被測系統(how?)

　　那怎么能有效獲取這些信息呢?下面我給出一些常用建議：

　　1.盡量參加所有項目相關的重要會議，這些會議會確定很多重要的事情：項目范圍，周期，投入，干系人職責。這些都對你后續工作帶來直接影響;如果你級別不夠，盡量爭取，或者讓你的上級或者干系人同步給你相關信息;依靠配置管理工具獲取這些會議的紀要;保存重要相關郵件，并納入配置管理(如果你維護測試相關的配置管理)。

　　2.獲取風險信息，并管理風險。具體的方法論可以參考James Bach這篇文章，里邊給出了非常好的方法論(不僅僅是獲取信息，還有怎樣利用風險進行測試，如何管理風險)：http://www.satisfice.com/articles/hrbt.pdf

　　3.配置管理!配置管理!配置管理!重要過程文檔基線化，重要文檔基線化(需求，涉及，測試用例等)，盡量讓干系人使用一套配置管理系統。

　　4.干系人訪談：這里的干系人可能包含一切有利于你工作的人，子系統測試經理，子系統項目經理，總體項目負責人，最終用戶，業務分析師等等。一個建議是：從風險問起，讓他們從自己的角度談談項目的最大風險是什么(有可能非常有啟發性)。

　　5.盡早進行文檔收集與梳理，對你最重要的文檔有：系統總體的需求、總體技術架構(可能以概要，主要功能點描述之類的非正式文檔出現，很多時候你拿不到提綱挈領的東西)，業務場景分析(如果是業務密集系統)，各子系統測試用例(可以復用)，測試報告(幫助你分析風險及測試深度)，

原文轉自：http://www.cnblogs.com/skytraveler/p/3508046.html