軟體專案中的基礎測試
單元測試（ut）
什麼是單元測試
• 單元測試（又稱為模組測試）是針對程式模組(軟體設計的最小單位)來進行正確性檢驗的測試工作。序單元是應用的最小可測試部件。在過程化程式設計中，乙個單元就是單個程式、函式、過程等。
單元測試流程
• 在傳統軟體開發過程中，單元測試是在編寫完模組**後開始進行的。基本流程是：1.模組設計；2.編寫模組；3.設計測試用例；4.進行單元測試。
• 在敏捷開發中，倡導測試驅動的方法。所以在單元測試中的流程有所不同。在測試驅動中的單元測試的基本流程：1.概據模組功能需求設計測試用例；2.模組設計；3.程式設計模組；4.進行單元測試。
• 在1和2的順序中可以並行來做。
單元測試的好處
• 單元測試提供了系統的一種文件記錄。借助於檢視單元測試提供的功能和單元測試中如何使用程式單元，開發人員取得了程式單元api的基礎直觀的理解。
• 通過單元測試能保證模組是可執行的，增加了程式設計師對自己編寫的模組提交的自信。
單元測試中的覆蓋率
• 單元測試中乙個最重要的指標就是**測試覆蓋率。其中包括：**語句覆蓋率；程式分支覆蓋率和子模組覆蓋率。
• 在單元測試中覆蓋率原則上是越高越好。但在專案開發過程中又有成本（包括人力，物力，時間）的限制。所以在進行在覆蓋率和成本上需要有個很好的平衡點。
• 在單元測試中可以先針對被測試的模組**進行分類。
• 1.必須測試的。
• 2.可以測試的。
• 3.測試不到的。
• 必須測試的是程式的主體結構。模組要實現的功能和流程。還要一些基本的異常處理**。
• 這部分的的**和分支是必須百分之百覆蓋的。因為這是保證模組結構的完整性和模組功能正常實現。
• 測試不到的是指一些在當前單元測試環境中暫時無法執行到的，但程式中又必須包含的**。這部分**在正常情況下是很少的。可以考慮放到後面的整合測試中當環境滿足時進行補充測試。
• 可以測試的是指除必須測試和測試不到的**所剩餘的部分。在考慮這部分**的測試覆蓋上就要加入成本的考慮了。在原則上這部分**盡量測試覆蓋。在這些**和分支中會存在一些測試成本很高但測試意義並不大的**或分支。在可控的成本範圍內進行評估哪些需要覆蓋，哪些可以暫時不覆蓋，在後面的整合測試中去測試。
• 在單元測試中不能只追求覆蓋率有多高。在針對覆蓋率的問題上應該在綜合各種因素後制訂有靈活的幅度範圍。不然大家就會為了達到高覆蓋率而做覆蓋工作了，這樣的工作效率低且意義不大。
整合測試（it）
什麼是整合測試
• 整合測試（也叫組裝測試，聯合測試）是單元測試的邏輯擴充套件。它的最簡單的形式是：兩個已經測試過的單元組合成乙個元件，並且測試它們之間的介面。從這一層意義上講，元件是指多個單元的整合聚合。在現實方案中，許多單元組合成元件，而這些元件又聚合成程式的更大部分。方法是測試片段的組合，並最終擴充套件程序，將您的模組與其他組的模組一起測試。最後，將構成程序的所有模組一起測試。
整合的測試的作用
• 在單元測試的基礎上，將所有模組按照設計要求（如根據結構圖〕組裝成為子系統或系統，進行整合測試。實踐表明，一些模組雖然能夠單獨地工作，但並不能保證連線起來也能正常的工作。程式在某些區域性反映不出來的問題，在全域性上很可能暴露出來，影響功能的實現。
整合測試的條件
• 在整合測試之前，單元測試應該已經完成，整合測試中所使用的物件應該是已經經過單元測試的軟體單元。這一點很重要，因為如果不經過單元測試，那麼整合測試的效果將會受到很大影響，並且會大幅增加軟體單元**糾錯的代價。
• 在很多傳統的專案中，整合測試會放在專案後期才開始。這樣做法讓很多問題暴露的很晚。問題也會堆積如山，造成整合測試寸步難移。最後可能由於一些問題無法補救和解決造成整個專案失敗。
• 在敏捷開發中，整合測試應該在專案早期開始進行。在進行概要設計時就要開始設計整合測試的框架和用例。整合測試環境在專案開始應該開始搭建。每乙個模組在完成單元測試後就能馬上進行組合並進入整合測試。這樣能把問題盡早的暴露出來，有利於問題的解決和專案的改進。
• 整合測試中盡量要做到全自動化測試。
整合測試的問題
• 在做整合測試中能發現很多邏輯錯誤問題。這些邏輯問題在單元測試中無法發現。
• 在這些問題當中大部分是邊界邏輯和異常處理邏輯問題。
• 為什麼在整合測試中暴露出來的問題大部分是邊界和異常處理邏輯問題呢？
• 1.整合測試是聯合測試多個模組，每個模組的設計與編寫不是乙個能完成的。
每個人對同一件事物的理解都是不能完全相同的。所以人與人之間的對功能模組的理解也有所偏差，這需要通過不斷的溝通與交流來不斷修正。在模組間的連線點需要進行充分的溝通，嚴格的介面設計與介面邏輯設計
• 2.在做概要設計和一些模組設計時，程式設計師都會把主要精力放在正常功能的設計上，針對邊界與異常處理的設計上不夠充分。
• 大部分的程式開發中，大部分的**都是處理邊界與異常處理的。所以在設計時不但要把正常功能的邏輯設計周全，也要與相同的態度去設計邊界邏輯和異常處理邏輯（這個工作量會比設計正常功能要多很多倍）。
• 3.必要的設計文件不健全。
• 在敏捷開發中雖然說是簡潔的文件，但必須的設計文件還是非常有必要的。比如一些深度死鎖問題。如果有健全的程式邏輯流程文件是比較容易發現的。特別是在多模組間的死鎖問題。如果沒有這型別的文件，只靠口頭交流是很難發現。而且在測試中發現了這類問題要定位出來也是相當費力的。如果有健全的程式邏輯流程圖可以在早期發現並解決此類問題，在後期測試中發現了這類問題，也可以通過圖很容易的定位出來。如果只靠**來定位是很難的。因為每個模組並不是同乙個人設計和編寫，要理解別人的**並氫這些模組間的**邏輯串聯並定位出問題是相當耗時耗力的。
系統測試（st）
什麼是系統測試
• 系統測試是將已經確認的軟體、計算機硬體、外設、網路等其他元素結合在一起，進行資訊系統的各種組裝測試和確認測試，其目的是通過與系統的需求相比較，發現所開發的系統與使用者需求不符或矛盾的地方，從而提出更加完善的方案。
系統測試的條件與作用
• 在獲取使用者需求後就得開始系統測試的工作了。在需求設計和系統架構設計時應該開始設計系統測試的計畫，系統設計的框架與基本的系統測試用例。在專案開發過程中需要根據使用者需求和設計變更做出調整。在專案的中間有多個模組完成整合測試後即可進入系統測試。系統測試主要針對使用者面，以使用者的角度進行測試。看實現的功能和效能是否滿足使用者需求。
系統測試的要求
• 在系統測試中除了完成功能測試外，還要著重效能測試。要反覆的折騰系統，保證系統在各種可能的環境中正常執行。在系統測試中，可以讓終端使用者參與進來，讓他們親自來進行系統測試。看使用者是否對系統的體驗是否滿意，有哪些不符合他們的要求。而且終端使用者對系統裡面的實現方法並不清楚，操作測試起來更有不可以**性，能發現更多隱蔽的缺陷。
• 參與系統測試的模組必須先經過充分單元測試和充分的整合測試。因為系統測試所發現的問題可能很難定位。原則是能在單元測試解決的問題不要留到整合測試中，能在整合測試中解決的問題不要留到系統測試中。因為越往後，問題越難定位，越難解決。
軟體專案中的風險管理
http www.csai.cn 2005年07月27日 1.引言 軟體專案風險是指在軟體開發過程中遇到的預算和進度等方面的問題以及這些問題對軟體專案的影響。軟體專案風險會影響專案計畫的實現，如果專案風險變成現實，就有可能影響專案的進度，增加專案的成本，甚至使軟體專案不能實現。如果對專案進行風險管理...
軟體專案中存在的問題
在學習 軟體工程 前，我個人倒是著實作了點專案，個人做的和團隊合作的都有。但無論是個人做或是團隊合作，給我印象最深的就是分工不明，雖然這種組織專案開發的方式快速，但與此對應所帶來的惡果常常是混亂和持續不斷的錯誤，並使得開發熱情迅速消耗殆盡，最後變成了磨洋工。學了 軟體工程 之後，覺得自己的思路開闊了...
軟體專案中存在的問題
在學習 軟體工程 前，我個人倒是著實作了點專案，個人做的和團隊合作的都有。但無論是個人做或是團隊合作，給我印象最深的就是分工不明，雖然這種組織專案開發的方式快速，但與此對應所帶來的惡果常常是混亂和持續不斷的錯誤，並使得開發熱情迅速消耗殆盡，最後變成了磨洋工。學了 軟體工程 之後，覺得自己的思路開闊了...