本討論來自SE Forum China，
歡迎大家來交流
From: BigMac (cx)
To: "SE Forum China" <[email protected]>
題目：關於軟件測試的問題
單元測試：是針對開發人員而言的，它是指開發人員在完成某一相對
獨立的功能的編碼之後立即進行的針對此段代碼的測試。它屬於內部
的白盒測試，在測試時要保證代碼的覆蓋率，保證代碼中的各個分支
均已遍歷。如果達到上述要求，即可以認爲已達到單元測試的要求；
集成測試：也是針對開發人員而言的，一般是指在完成了軟件產品的所
有/大部分編碼工作以後，將原來由不同開發人員完成的代碼組合在一
起作爲一個整體進行測試。進行集成測試的前提是已完成單元測試。
在集成測試時主要是測試需求規範中所規定的各項功能是否已正確實
現，是否可以結束的標準就是當前的軟件產品是否已正確實現需求中
所各功能。一般而言，在集成測試中爲避免開發人員自身思維的侷限
性，自已所完成的部分應由其它開發人員進行測試。如果時間允許，
最好一個功能由多個不同的開發人員進行測試。集成測試如果可能的
話，儘量提前進行，隨時進行。例如在實際工作中如果代碼的採用版
本管理工具進行管理的話，例如MS的Source Safe，那麼，每次CHECK-IN
代碼進入VSS庫時必須先從庫中取出所有當前代碼的最新版本，在自已
本機上進行單元測試和集成測試，保證正確後，再CHECK-IN。這樣做
的好處是在VSS中始終中一個可能隨時運行的軟件版本（這也是MS在開
發中採用的方法）。當然，如果有人力物力的話，最好有一個配置管理
小組，每天負責對當前版本管理工具中的最新代碼進行BUILD以及相應的測試。
系統測試：這是由專門的測試部分的同事所進行的黑盒測試。測試的標準也
是需求規範。測試人員應根據需求規範制定相應的測試計劃及方案。當然
如果有可能的話，最好測試部門的高級測試人員能儘早加入開發團隊，了
解需求，瞭解產品的內部結構，這樣才能更好地更有針對性地制定方案及
計劃。此外系統測試與前兩種測試的不同在於，此時的測試人員是代表最
集成測試：也是針對開發人員而言的，一般是指在完成了軟件產品的所
有/大部分編碼工作以後，將原來由不同開發人員完成的代碼組合在一
起作爲一個整體進行測試。進行集成測試的前提是已完成單元測試。
在集成測試時主要是測試需求規範中所規定的各項功能是否已正確實
現，是否可以結束的標準就是當前的軟件產品是否已正確實現需求中
所各功能。一般而言，在集成測試中爲避免開發人員自身思維的侷限
性，自已所完成的部分應由其它開發人員進行測試。如果時間允許，
最好一個功能由多個不同的開發人員進行測試。集成測試如果可能的
話，儘量提前進行，隨時進行。例如在實際工作中如果代碼的採用版
本管理工具進行管理的話，例如MS的Source Safe，那麼，每次CHECK-IN
代碼進入VSS庫時必須先從庫中取出所有當前代碼的最新版本，在自已
本機上進行單元測試和集成測試，保證正確後，再CHECK-IN。這樣做
的好處是在VSS中始終中一個可能隨時運行的軟件版本（這也是MS在開
發中採用的方法）。當然，如果有人力物力的話，最好有一個配置管理
小組，每天負責對當前版本管理工具中的最新代碼進行BUILD以及相應的測試。
系統測試：這是由專門的測試部分的同事所進行的黑盒測試。測試的標準也
是需求規範。測試人員應根據需求規範制定相應的測試計劃及方案。當然
如果有可能的話，最好測試部門的高級測試人員能儘早加入開發團隊，了
解需求，瞭解產品的內部結構，這樣才能更好地更有針對性地制定方案及
計劃。此外系統測試與前兩種測試的不同在於，此時的測試人員是代表最
終用戶進行測試，除了按需求規範測試外，他們要從用戶實際使用的角度
考慮問題：這項功能實現的過程是否流暢，人機界面是否美觀等等。另外
我們應明確一點：依靠各種測度我們均無法保證100%發現軟件產品中的所
有BUG！我們進行各種測試的目的在於：在有限的人力物力情況下，最終
的軟件產品質量已足夠好，即Good-Enough而不要奢望Zero-error。在
實際測試中常常會碰到BUG層出不窮，好象越測心裏越沒底，不知道何處
是盡頭。其實對大多數軟件來說，在測試進程中BUG的發現機率是有一定
規律性可言的，如果產品趨於穩定的話，BUG的出現率是會呈遞減趨勢的，
當此出現率穩定在一可接受的程序或爲零時，我們就可以認爲此產品已達
到GOOD-ENOUGH了，這時就可以進入穩定期測試了。在穩定期，測試人員
將會將以前測試過程中所有測試過的測試用例再過一遍。如果沒有問題的
話，就可以發貨了。否則將退出穩定性，開發人員修改BUG，測試方面接
着測試，最後再進穩定期直至一切OK。另外，測試過程中要注意迴歸測
試的問題。
最後補充一點：測試開始的越早越好！這些BUG帶來的損失才能降到最小，
國外有人提出需求階段就應進行測試，這個我沒什麼經驗，不知有沒有
瞭解此道的高手指點一下。
以上是個人在開發中的一些體會，歡迎指正。
-----Original Message-----
From: [email protected] <[email protected]>
To: [email protected] <[email protected]>
Date: 2000-06-28 15:29
Subject: [selab] 請教關於軟件測試的問題
測試工作(單元測試,集成測試,系統測試)在什麼情況下可以終止.
是否有一個標準之類 的東西.
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
本討論來自SE Forum China，
歡迎大家來交流
From: davew
To: "SE Forum China" <[email protected]>
題目：關於軟件測試的問題
說得不錯，必須明確測試的基準和依據是什麼。
事實上，從V模型中可以很清楚地看出各個測試的工作和停止標準。
這裏停止並不意味着這一測試工作的徹底完成，迭代是很正常的。
看到陳哥的高論，我也來說說軟件測試，拋磚引玉，希望大家指點
具體地講：
單元測試對應詳細設計工作（報告或文檔or similar），測試時，
單元測試人員(可能就是開發人員本人，不過經常是由另外一個開發
人員來對此進行單元測試)負責學習該詳細設計，根據詳細設計嚴格
對相應模塊進行測試，單元測試有好多手段，如白盒測試和黑盒測
試（黑盒測試也用），在測試時根據不同公司、不同的項目軟件既
定過程、不同的客戶要求、不同的質量標準可能要求不同，如不同
代碼覆蓋率，並可能有一些特殊測試，例如2000測試也可能就在單
元測試時展開。一般講，當單元測試完成對應的詳細設計內規定時，
就可以停止該單元的單元測試。一定一定明確的是這裏的詳細設計
服從於其所屬的概要設計乃至相應的需求文檔（產生更改時必須以
更新後的爲準），因此所謂單元測試對應詳細設計恐怕不能單看那
一個或幾個詳細設計文檔，即使真正做到了需求的在詳細設計的落
實和可跟蹤，有些內容還是不能完全反映在單個詳細設計中，如很
多性能、功能需求和其他約束。所以說，單元測試是內容是相對確
切的，而作用十分重要，其實同時也是十分靈活的，我們的軟件項
目對單元測試有一定理解，應用也還是較多的，但就是理解不夠，
做的就更是容易流於形式了。
集成測試在V模型中對應的是概要設計，什麼時候可以停止集成測
試呢，那就需要看概要設計的內容了。事實證明，很多問題都是
在集成測試才發現的，關注我們概要設計的模塊間的接口吧！集成測
試的一項重要任務就是對不同模塊間的接口設計進行檢驗，即使設計
的結構很細緻，由於需求的變更，這文檔or similar），測試時，
單元測試人員(可能就是開發人員本人，不過經常是由另外一個開發
人員來對此進行單元測試)負責學習該詳細設計，根據詳細設計嚴格
對相應模塊進行測試，單元測試有好多手段，如白盒測試和黑盒測
試（黑盒測試也用），在測試時根據不同公司、不同的項目軟件既
定過程、不同的客戶要求、不同的質量標準可能要求不同，如不同
代碼覆蓋率，並可能有一些特殊測試，例如2000測試也可能就在單
元測試時展開。一般講，當單元測試完成對應的詳細設計內規定時，
就可以停止該單元的單元測試。一定一定明確的是這裏的詳細設計
服從於其所屬的概要設計乃至相應的需求文檔（產生更改時必須以
更新後的爲準），因此所謂單元測試對應詳細設計恐怕不能單看那
一個或幾個詳細設計文檔，即使真正做到了需求的在詳細設計的落
實和可跟蹤，有些內容還是不能完全反映在單個詳細設計中，如很
多性能、功能需求和其他約束。所以說，單元測試是內容是相對確
切的，而作用十分重要，其實同時也是十分靈活的，我們的軟件項
目對單元測試有一定理解，應用也還是較多的，但就是理解不夠，
做的就更是容易流於形式了。
集成測試在V模型中對應的是概要設計，什麼時候可以停止集成測
試呢，那就需要看概要設計的內容了。事實證明，很多問題都是
在集成測試才發現的，關注我們概要設計的模塊間的接口吧！集成測
試的一項重要任務就是對不同模塊間的接口設計進行檢驗，即使設計
的結構很細緻，由於需求的變更，這個接口可能會發生直接或間接的變化，
很多項目的一大部分時間都花在了集成測試上，一方面可能是單元測
試質量不高，另一方面也可能是概要設計存在問題，但概要設計出現
問題時，就需要重新進行結構的設計，這個重新的程度就看問題有多
大了，有時需要重新對整個方案進行考慮。
系統測試在V模型中對應的是需求，對應的是功能規格說明FS，理論
上講，僅當FS中的每一個需求都得到確認和驗證時，系統測試才能宣
告ok. 在項目功能分配上，不同組織系統測試安排可能不一樣，有的
系統測試是由專門的部門來進行，有的則是項目組內部現招或調，無
論那種形式，都必須由項目組來統一組織和管理。根據系統測試的目標，
可以推出測試人員在FS形成階段就應當開始工作了，深度理解FS，把握
需求分配，到集成設計完畢時，他們應當已經準備好了test case，
test script等等的設計。從我的體會來講，用戶手冊的編寫和維護
應當由測試人員來負責，他們最理解FS，最理解用戶的每一項需求，
瞭解每一次需求變動，而且會對每一個需求進行確認和驗證，用戶手冊的
工作可能就在很早就可以開始了（FS形成之後），大家以爲如何呢？
時間所限，就談這些。
davew
6/29
*********** REPLY SEPARATOR ***********
On 00-6-28 at 16:02 Gao,Smith wrote:
我個人的經驗是：
測試工作是以系統的設計、需求爲依據的，正常情況下，只要系統達到
設計要求和需求，並且沒有運行錯誤，就可以OK。 測試具有一定的重複性，
集成測試階段發現系統單元的新問題時，既要進行單元測試，又要進行集成
測試；測試的終止只 具有階段性，比如，在系統發佈前如果發現不了問題，
測試就可以告一段落，但用戶使用過程中有可能發現新的問題，修
改問題時，又要進行新一輪的單元測試，集成測試，系統測試了
以上只是我的一些經驗，不知會答的對否！
-----原始郵件-----
發件人: [email protected] [mailto:[email protected]]
發送時間: 2000年6月28日 15:29
收件人: [email protected]
主題: [selab]請教關於軟件測試的問題
測試工作(單元測試,集成測試,系統測試)在什麼情況下可以終止.是否有一個標準之類 的東
西.