一些軟體工程的基礎知識
軟體工程知識點總結
有以下知識點（考試內容，當然不止這些）
1. 軟體工程的定義
2. 軟體生存週期
3. 軟體過程模型
4. 需求分析的定義、獲取
5. 常見的軟體體系結構（B/S 、C/S 、軟體匯流排中介軟體）
6. SOA 的定義、特點、和工作模型（鬆耦合、明確定義的介面）
7. 雲端計算的定義、優勢和應用模型
8. 軟體測試的概念、原則、方法和測試策略
9. 軟體維護的型別
10. 軟體專案管理的管理過程和領域
11. 成本估算模型、進度計劃的方法
12. 風險管理、質量管理的概念
13. CMM（軟體能力成熟度模型）
第一章
1. 軟體工程的定義：（P3）
軟體工程是一門指導軟體開發
2. 軟體生存期（P5）
軟體生命週期（SDLD）是指一個從使用者需求開始，經過開發、交付使用，在使用中不斷地增補修訂，直至軟體報廢的全過程，亦稱軟體生存期（Life Cycle）。
軟體生命週期分為以下階段：
①可行性研究和專案開發計劃。該階段必須要回答的問題是“要解決的問題是什麼”。
②需求分析。該階段的任務不是具體地解決問題，而是準確地確定“軟體系統必須做什麼”，確定軟體系統必須具備哪些功能。
③概要設計。概要設計就是設計軟體的結構，該結構由哪些模組組成，這些模組的層次結構是怎樣的，這些模組的呼叫關係是怎樣的，每個模組的功能是什麼。同時還要設計該專案的應用系統的總體資料結構和資料庫結構，即應用系統要儲存什麼資料，這些資料是什麼樣的結構，它們之間有什麼關係等。
④詳細設計。即對每個模組完成的功能進行具體描述，要把功能描述變為精確的、結構化的過程描述。
⑤編碼。該階段把每個模組的控制結構轉換成計算機可接受的程式程式碼，即寫成以某特定程式設計語言表示的“源程式”。
⑥測試。它是保證軟體質量的重要手段，其主要方式是在設計測試用例的基礎上檢驗軟體的各個組成部分。測試分為，模組測試、組裝測試、確認測試等。
⑦維護。軟體維護是軟體生存期中時間最長的階段。已交付的軟體投入正式使用後，便進入軟體維護階段，它可以持續幾年甚至幾十年。
在大部分文獻中將生存期劃分為5個階段，即 要求定義、設計、編碼、測試及維護。其中 要求定義階段包括可行性研究和專案開發計劃及需求分析，設計階段包括概要設計和詳細設計。
為了描述軟體生存期的活動，提出了多種生存期模型，如瀑布模型、循壞模型、螺旋模型、噴泉模型、智慧模型等。
3. 目前常見的軟體過程模型如下：瀑布模型、增量模型、螺旋模型、噴泉模型、智慧模型等。
1) 瀑布模型
優點：在軟體工程的第一階段，瀑布模型得到了廣泛的應用，它簡單易用，在消除非結構化軟體，降低軟體的複雜性，促進軟體開發工程化方面起了很大的作用。
缺點：由於瀑布模型是一種理想的線性開發模式，它將一個充滿回溯的軟體開發過程硬性分割為幾個階段，無法解決軟體需求不明確或者變動的問題。這些缺點對軟體開發帶來了嚴重影響，由於需求不明確，會導致開發的軟體不符合使用者的需求而夭折。
2) 增量模型(incremental model)
- 增量模型是一種非整體開發的模型。是一種進化式的開發過程。
- 根據增量的方式和形式的不同，分為：
- 基於瀑布模型的漸增模型
- 基於原型的快速原型模型
該模型具有較大的靈活性，適合於軟體需求不明確、設計方案有一定風險的軟體專案。
增量模型和瀑布模型之間的本質區別是什麼？
增量模型和瀑布模型之間的本質區別是：瀑布模型屬於整體開發模型，它規定在開始下一個階段的工作之前，必須完成前一階段的所有細節。而增量模型屬於非整體開發模型，它推遲某些階段或所有階段中的細節，從而較早地產生工作軟體。
一般的增量模型如下：
3)螺旋模型
對大型軟體,需要多個原型描述系統的生存期，螺旋模型將瀑布模型與原型化模型結合起來,並加入了風險分析。
該模型將開發過程分為幾個螺旋週期，每個螺旋週期可分為4個工作步驟：
①制定計劃：確定目標、方案和限制條件；
②風險分析：評估方案、標識風險和解決風險；
③實施工程：開發確認產品；
④客戶評估：計劃下一週期工作。
一般的螺旋模型如下圖：沿著螺旋線每轉一圈，表示開發出一個更完善的新的軟體版本。如果開發風險過大，開發機構和客戶無法接受，專案有可能就此中止；多數情況下，會沿著螺旋線繼續下去，自內向外逐步延伸，最終得到滿意的軟體產品。
4) 噴泉模型
噴泉模型以面向物件的軟體開發方法為基礎，以使用者需求作為噴泉模型的源泉。如下圖：
6. 噴泉模型是物件驅動的過程，物件是所有活動作用的實體，也是專案管理的基本內容。
7. 噴泉模型在實現時，由於活動不同，可分為系統實現和物件實現，這既反映了全系統的開發過程，也反映了物件族的開發和重用過程5）智慧模型
智慧模型也稱為基於知識的軟體開發模型，是知識工程與軟體工程在開發模型上結合的產物，以瀑布模型與專家系統的綜合應用為基礎建立的模型，該模型通過應用系統的知識和規則幫組設計者認識一個特定的軟體的需求和設計，這些專家系統已成為開發過程的夥伴，並指導開發過程。
從圖中可以清楚地看到，智慧模型與其他模型不同，它的維護並不在程式一級上進行，這樣就把問題的複雜性大大降低了。
智慧模型的主要優點有：
① 通過領域的專家系統，可使需求說明更加完整、準確和無二義性。
② 通過軟體工程的專家系統，提供一個設計庫支援，在開發過程中成為設計的助手。
③ 通過軟體工程知識和特定應用領域的知識和規則的應用來提供開發的幫助。
但是，要建立合適於軟體設計的專家系統，或建立一個既適合軟體工程由適合應用領域的知識庫都是非常困難的。目前，在軟體開發中正在使用AI技術，並已取得區域性進展；例如在CASE工具系統中使用專家系統，又如使用專家系統實現測試自動化。
第二章
1.需求分析的定義
在傳統軟體工程生命週期中，涉及軟體需求的階段稱做需求分析。
2.需求工程的定義
需求工程是一個包括創新和維護系統需求文件所必須的一切活動，是對系統應該提供的服務和所受到的約束進行理解、分析、檢驗和建立文件的過程。
3. 需求的獲取和分析
需求的獲取和分析是需求工程的關鍵和核心步驟，直接影響到後期的開發工作和系統的成敗。
·需求獲取
在深入實際調查研究，充分理解使用者需求的基礎上，獲取系統需求。獲取過程為：
①瞭解領域知識，工程技術人員需要依靠領域專家，學習和理解相關的專業知識，才能正確抽取使用者需求。
②需求收集，與專案相關人員進行溝通，在進一步瞭解專業領域的基礎上，發現系統需求的過程。
·需求分析
需求分析的過程是對收集到的需求進行提煉、分析和審查的過程，最終確定需求，並確保所有專案相關人員對需求取得一致性認識。分析階段的主要工作包括：
①確定系統範圍。確定系統與其他外部實體或其他系統的邊界和介面。
②分類排序。對所收集的需求進行重新組織、整理、分類和篩選，並對每類需求進行排序，確定哪些是最重要的需求。
③建立需求分析模型。這是分析階段的核心工作。需求分析模型是對需求的主要描述手段，是根據不同的分析方法建立的各種檢視，例如資料流圖（DFD）、實體關係圖（E-R）、用例圖（Use Case）、類圖、狀態圖、各種互動圖等。還可建立輔助的說明，如資料詞典。
④建立需求規格說明。軟體需求規格說明（Software Requirement Specification,SRS）是將需求的結果按照不同開發方法規定的格式用圖形和文件形式描述出來。需求規格說明在整個開發過程中具有很重要的作用，是使用者和開發人員之間進行交流和理解系統的手段。使用者通過需求規格說明檢查是否符合和滿足所提出的全部需求。開發者則通過需求規格文件，瞭解和理解所開發系統的內容，並以此作為軟體設計和軟體測試的依據。專案管理人員以它為依據，規劃軟體開發過程、計劃，估算軟體成本和控制需求的變更過程。
第三章
·軟體體系結構設計
倉庫模型（The repository model）
也稱“容器模型 ”，是一種集中式的模型。在這種結構模型當中，應用系統用一箇中央資料倉庫來儲存各個子系統共享的資料，其它的子系統可以直接訪問這些共享資料。當然，每個子系統可能會有自己的資料庫。為了共享資料，所有的子系統之間緊密耦合的，並且圍繞中央資料倉庫，如下圖：
倉庫模型的主要優點：
①資料由一個子系統產生，並且被另外一些子系統共享；
②共享資料能得到有效的管理，各子系統之間不需要通過複雜的機制來傳遞共享資料。
③一個子系統不必關心其他的子系統是如何使用它產生的資料的。
④所有的子系統都擁有一致的基於中央資料倉庫的資料檢視。如果新子系統也採用相同的規範，則將它整合與系統中是容易的。
倉庫模型的主要缺點：
①為了共享資料 ,各子系統必須有一致的資料檢視 ，不可避免地會影響了整個系統的效能。
②一個子系統發生了改變，它產生的資料結構也可能發生改變。為了其他共享的目的，資料翻譯系統會被用到。但這種翻譯的代價是很高的，並且有時是不可能完成的。
③中央資料倉庫和各子系統擁有的資料庫必須有相同的關於備份、安全、訪問控制和恢復的策略，這可能會影響子系統的效率。
④集中式的控制使資料和子系統的分佈變得非常困難甚至成為不可能。這裡分佈指的是將資料或子系統分散到不同的機器上。
一般來說，命令控制系統、CAD系統等常採用這種結構。
分散式結構
分散式結構有如下一些優勢：
①資源共享：系統中每個服務結點上的資源都可以被系統中的其他結點訪問。
②開放性高：系統可以方便地增刪不同軟、硬體結構的結點。
③可伸縮性好：系統可以方便的增刪新的服務資源以滿足需要。
④容錯能力強：分散式系統中的資訊冗餘可以容忍一定程度的軟、硬體故障。
⑤透明性高：系統中的結點一般只需知道服務的位置而不必清楚系統的結構。
分散式結構有如下一些不足：
①複雜性：分散式系統比集中式系統要複雜的多。集中式系統的效能主要依賴於主機的處理能力，而分散式系統的效能則還要依賴於網路的頻寬，這讓情況變得更加複雜。
②安全性：網路環境隨時面臨著各種威脅，如病毒、惡意程式碼、非法訪問等，如何保證安全性是一個讓人頭痛的問題。
③可管理性：分散式系統的開放性造成了系統的異構性，顯而易見，管理異構的系統比管理主機系統要困難得多。
④不可預知性：這主要指系統的響應時間。網路環境本身的特點決定了網路負載會明顯地影響整個系統的響應時間。
下面主要討論幾種不同的分散式結構.
1)客戶-伺服器模型（Client/Server Architectural Model）
客戶-伺服器結構（Client/ServerArchitecture）是一種典型的分散式結構。典型的客戶-伺服器C/S 結構的系統包括三個組成部分：
①伺服器（Server）:多個獨立的伺服器為系統提供諸如Web、檔案共享、列印等服務。
②客戶（Client）:多個併發客戶應用訪問多個伺服器提供的服務，每個客戶應用都是獨立的同樣的客戶應用可以同時有多個例項。
③網路（Network）:客戶和伺服器通過網路連線在一起。這是C/S結構的常用模式。有時客戶應用和伺服器應用會在同一臺機器上執行，但兩個應用還是要通過本機的網路協議進行通訊，其效果就像在不同的機器上執行一樣。
C/S 結構的應用都由三個相對獨立的邏輯部分組成：
①使用者介面部分：資料表示層，實現與使用者互動。
②應用邏輯部分：業務邏輯層，進行具體運算和資料處理；
③資料訪問部分：資料訪問層，完成資料查詢、修改、更新等任務。
以上三種邏輯之間的關係如下圖：
根據應用邏輯層所處的位置，C/S 結構的應用系統常可以分為兩層結構、三層/多層應用結構。
1)兩層客戶-伺服器模型（Two Tier Client/ServerArchitectural Model）
在兩層C/S 結構中，應用系統有兩個典型的應用組成，其中一個是主要負責使用者介面部分的客戶端，另一個是主要負責資料訪問的伺服器，兩者通過網路進行資料交換。其結構如下圖：
現在舉資料庫應用的例子來說明兩層C/S結構的工作方式。
客戶應用工具需求向資料庫伺服器發出資料訪問請求，資料庫伺服器會響應這個請求，查詢、更新資料，然後將結果返回給客戶端。這是典型的“請求-響應-得結果”模式。當然，不是所有的請求都需要返回結果。實際上，C/S 的工作模式是一種遠端過程呼叫（Remote Procedure Call, RPC）模式。允許客戶端和伺服器端有不同的軟硬平臺。
·完整的應用包含三個相對獨立的邏輯部分，而兩層的C/S結構只有兩個端應用。應用邏輯應該對映到哪一端上呢？ 三種情況：
在上圖中：
C/S 應用1的結構中，客戶端應用負責使用者介面和應用邏輯部分，因此他的工作比較繁重。這種結構往往被稱為胖客戶端（Fat-Client）結構，一般的資料庫應用都是屬於這種結構的。以此相反，
C/S 應用3的結構中，伺服器負責了更多的工作，而客戶端的工作就變得非常單純。這種結構成為瘦客戶（Thin-Client）結構。瀏覽器/Web 伺服器結構就屬於瘦客戶結構，而且常被稱為Browser/Server(B/S)結構。
不過，越來越多的B/S應用包含了一些可以遷移的程式碼，例如包含客戶端指令碼的網頁，這些程式碼從伺服器端下載到客戶端並在客戶端執行，這樣一來，客戶端也或多或少地要處理一部分的應用邏輯。這種B/S結構實際上介於胖客戶和瘦客戶結構之間，就如上圖中的C/S 應用2的結構。
由於兩層C/S 架構將資料表示和處理邏輯分開，這樣，客戶端和伺服器的功能相對來說就比較單一，兩端的維護和升級也比集中式結構簡單。
但C/S 架構也存在著明顯的缺陷：
由於應用邏輯和兩端之一是緊耦合的，因此當它發生改變時，不是客戶端就是伺服器也要跟著做出相應的改變，同時這種改變極有可能會影響到另一端。因此，C/S 架構不適合用在多使用者、多資料庫、非安全的網路環境中。另外，客戶端應用程式越來越大，對使用者的要求也越來越高。
3）三層/多層應用模型(Three/Multi Tier Model)
第一級是資料庫管理結點(databasemanagement node)。
第二級或中間級是“商業邏輯結點” (business logic node),是指具體應用中實施的 程式邏輯和法則。
第三級是使用者介面級，強調高效、方便易用的使用者介面。
在下圖所示的多層應用模型中，為了有效地管理那些完成業務邏輯的元件，中間層會用到應用服務，包括事務服務、訊息服務等。常見的事務伺服器有Microsoft Transaction Server，訊息伺服器有Microsoft Message Queue。
常見的三層結構應用有瀏覽器-Web服務-資料服務結構。這是一種典型的B/S結構。在這種結構中，
客戶應用是一個通用的瀏覽器，如 Microsoft Internet Explorer(IE),它完成網頁的顯示和客戶端指令碼的遠行；
Web伺服器，如Microsoft Internet Information Server,它響應客戶的網頁訪問請求，執行服務端指令碼，並通過Microsoft ADO元件物件向資料庫伺服器發出資料請求；
資料庫伺服器，如Microsoft SQL Server ,響應資料請求並返回結果。
·多層應用模型的優點相當的明顯：
①客戶端的功能單一，變得更“瘦”。
②每一層可以被單獨改變，而無須其他層的改變。
③降低了部署與維護的開銷，提高了靈活性、可伸縮性。
④應用程式各部分之間鬆散耦合，從而使應用程式各部分的更新相互獨立。
⑤業務邏輯集中放在伺服器上有所有使用者共享，使得系統的維護和更新變得簡單，也更安全。
4) 分散式物件結構(Distributed Objects Architecture)
採用分散式物件結構 ：
·服務的提供者是被稱為“物件(Object)”的系統元件(System Component)。
·每個物件在邏輯上是平等的，它們可以互相為對方提供所需的服務。
·提供服務的物件就是伺服器，而提出服務請求的物件就是客戶。
·為了能夠提供服務，每個物件都有一個服務介面。
下圖是分散式物件結構：
分散式物件結構的另一個重要特點是，物件可能分佈在網路的各個結點上而不是集中在一臺硬體伺服器上。為了將分散的物件提供的服務“串”起來，一種被形象地稱為“軟體匯流排（Software Bus)”的中介軟體起了關鍵的作用。
由於分散式物件結構具有相當好的開放性和透明性，使用者可以非常方便地在總線上新增或者刪除元件物件，從而完成增加、更新或刪除功能。
“軟體匯流排(Software Bus)”的中介軟體(Middleware) ，即物件請求代理(Object Request Broker，簡稱ORB) 。
流行的ORB技術標準有：
1 、CORBA(Common Object Request BrokerArchitecture)
公共物件請求代理體系結構。由物件管理組織OMG （Object Management Group）提出的應用軟體體系結構和物件技術規範。
2、DCOM(Distributed Component ObjectModel)
元件物件模型。為元件之間、元件與應用程式之間的通訊和互操作提供了統一的標準和技術規範，使不同語言開發的元件可進行基於元件的軟體開發。
3、 EJB（Enterprise Java Bean）
由Sun公司定義的規範，EJB構件是實現EJB規範的Java構件，完成企業級應用中的業務邏輯。EJB構件駐留在EJB容器中。
5) 中介軟體（Middleware）
現代應用系統具有如下的一些特點：
①分佈性。整個任務不只是在單機上執行，而是由網路中多臺計算機上的相關應用共同協作完成，這需要考慮網路傳輸、資料安全、資料一致性、同步等諸多問題。
②異構性。支撐應用的計算機硬體、作業系統、網路協議、資料庫系統，以及開發工具種類繁多，需要考慮資料表示、呼叫介面、處理方式等諸多問題。
③動態協作性。參與協作的應用允許位置透明性、遷移透明性、負載平衡性等需求。
④應用程式各部分之間鬆散耦合，從而使應用程式各部分的更新相互獨立。
⑤業務邏輯集中放在伺服器上有所有使用者共享，使得系統的維護和更新變得簡單，也更安全。
應用中介軟體系統可以滿足現代系統的需要。中介軟體是一種處於系統軟體（作業系統和網路軟體）與應用軟體之間的軟體，它能使應用軟體之間進行跨網路的協同工作（也就是互操作），並允許個應用軟體所涉及的“系統結構、作業系統、通訊協議、資料庫和其他應用服務”各不相同。
·中介軟體按其應用領域分為以下6種：
①遠端過程呼叫中介軟體
②分散式物件中介軟體
③資料庫訪問中介軟體
④事務處理中介軟體
⑤訊息中介軟體
⑥其他中介軟體
補充內容:面向服務的軟體架構（PPT）
1. 面向服務的體系結構（service-oriented architecture，SOA）的定義
面向服務的體系結構（service-orientedarchitecture，SOA）是一個構件模型，它將應用程式的不同功能單元（稱為服務）通過定義良好的介面和契約聯絡起來。
·介面是採用中立的方式進行定義的，它應該獨立於實現服務的硬體平臺、作業系統和程式語言。這使得構建在各種這樣的系統中的服務可以以一種統一和通用的方式進行互動。
2. 服務（service）是封裝成用於業務流程的可複用構件的應用程式函式。它提供資訊或簡化業務資料從一個有效的、一致的狀態向另一個狀態的轉變。
3. SOA的特點
·鬆耦合
①在該體系架構中，客戶端不和任何伺服器相關聯，它只和服務相聯絡，所以客戶端和伺服器的整合不影響客戶端應用程式。
②無論老的或者新的功能模組都可以被封裝成服務構件被髮布。
③功能構件和它們的介面分離，所以新的介面可以非常方便地插入。
④在複雜的應用程式裡，業務過程的控制可以被隔離：引入一個業務規則引擎用來控制已經定義好的業務過程流。引擎根據工作流的狀態呼叫各種不同的服務。
⑤服務可以在執行時動態地合成進來。
⑥通過配置檔案進行繫結，所以可以非常容易地適應各種新的需要。
·明確定義的介面
·服務互動必須是明確定義的
· Web 服務描述語言（Webservices Description Language，WSDL）是受到廣泛支援的方法，用於描述服務請求者所要求的繫結到服務提供者的細節
· 服務
·呼叫操作的訊息
·構造這種訊息的細節
· 關於向何處傳送用於構造這種訊息的處理細節的訊息的資訊
· 無狀態的服務設計
· 服務應該是獨立的、自包含的請求，在實現時它不需要從一個請求到另一個請求的資訊或狀態
· 服務不應該依賴於其他服務的上下文和狀態。當需要依賴時，它們最好定義成通用業務流程、函式和資料模型
補充內容:雲端計算（PPT）
1. 雲端計算的定義
雲端計算（Cloud Computing ）：是分散式處理(Distributed Computing)、並行處理(ParallelComputing)和網格計算(Grid Computing)的發展，或者說是這些電腦科學概念的商業實現。是指基於網際網路的超級計算模式--即把儲存於個人電腦、行動電話和其他裝置上的大量資訊和處理器資源集中在一起，協同工作。在極大規模上可擴充套件的資訊科技能力向外部客戶作為服務來提供的一種計算方式。
2. 雲端計算的優勢：
①開發容易快速
②無多餘的開支
③每月花費低
④IT人員減少，費用降低
⑤提供最新的技術和功能
⑥支援、推行IT標準
⑦系統和資訊共享更容易
3. 雲端計算的應用模型
·雲端計算三種服務方式
·SAAS（ Software as a Service ）
·PAAS（Platform as a Service ）
·IAAS（Infrastructure as a Service ）
雲端計算的應用—IAAS（Infrastructure as a Service）
實現模式
·完全作業系統（軟硬體）接入
·防火牆
·路由器
·負載平衡
優勢
·節省費用/所付及所用
·即時升級
·安全
·可靠
·APIs
例項
當你想執行成批的程式組，但是沒有合適的軟硬體環境，可使用Amazon的EC2。
當你想在網路上釋出一個短期（幾天到幾個月）的網站，可使用Flexiscale。
雲端計算的應用—PAAS（ Platform as a Service ）
實現模式
·平臺價格昂貴
·需求估算不科學
·平臺管理複雜麻煩
流行的服務
·儲存
·資料庫
·擴充套件性
優勢
·節省費用/所付及所用
·即時升級
·安全
·可靠
·APIs
例項
當你想把一個大容量的檔案上傳到網路上，允許35000個使用者使用2個月的時間，可使用Amazon的Cloud Front即時升級。
當你想在網路上儲存大量的文件，但是你沒有足夠的儲存空間，可使用Amazon的S3。可靠。
雲端計算的應用—SAAS（ Software as a Service ）
實現模式
·在中小企業盛行
·無需管理軟硬體
·服務通過瀏覽器實現
優勢
·無浪費費用
·即時擴充套件
·安全
·可靠
·APIs
例項
·CRM
·財務計劃
·HR
·文書處理
雲端計算的應用
IaaS、PaaS & SaaS共性
·無浪費費用
·即時擴充套件
·安全
·可靠
·APIs
優勢
·使用者花費低
·減少底層管理職責
·允許意想不到的資源裝載
·業務應用實現迅速
風險
·安全性
·宕機問題
·接入問題
·獨立性
·協同互動問題
第七章 軟體測試
1. 軟體測試的概念
2. 軟體測試的原則
· Davis 提出了一組指導軟體測試的基本原則：
①所有的測試都應根據使用者的需求來進行。
②應該在測試工作真正開始前的較長時間內就進行測試計劃（測試規劃）的編寫。一般而言，測試計劃可以在需求分析完成後開始，詳細的測試用例定義可以在設計模型被確定後立即開始，因此，所有測試可以在任何程式碼被編寫前進行計劃和設計。
③Pareto 原則應用於軟體測試。Pareto 原則意味著測試發現的80%的錯誤很可能集中在20%的程式模組中。
④測試應從“小規模”開始，逐步轉向“大規模”。即從模組測試開始，再進行系統測試。
⑤窮舉測試是不可能的，因此，在測試中不可能覆蓋路徑的每一個組合。然而，充分覆蓋程式邏輯，確保覆蓋程式設計中使用的所有條件是有可能的。
⑥為達到最佳的測試效果，提倡由第三方來進行測試。
·其他的測試原則：
①在設計測試用例時，應包括合理的輸入條件和不合理的輸入條件
②嚴格執行測試計劃，排除測試的隨意性
③應當對每一個測試結果做全面檢查
④妥善儲存測試計劃、測試用例、出錯統計和最終分析報告，為維護提供方便
⑤檢查程式是否做了應做的事僅是成功的一半，另一半是檢查程式是否做了不該做的事。
⑥在規劃測試時不要設想程式中不會出錯誤
3. 測試用例的設計方法大體可分為兩類
白盒測試/白箱測試
把測試物件看作一個透明的盒子，根據程式內部的邏輯結構及有關資訊設計測試用例
黑盒測試/黑箱測試
把測試物件看做一個黑盒子，完全不考慮程式內部的邏輯結構和內部特性
4. 白盒測試
又稱結構測試、邏輯驅動測試或基於程式的測試
把測試物件看作一個透明的盒子，測試人員根據程式內部的邏輯結構及有關資訊設計測試用例，檢查程式中所有邏輯路徑是否都按預定的要求正確地工作。
主要用於對模組的測試
白盒法常用的測試方法
①基本路徑覆蓋測試
根據程式或設計圖畫出控制流圖，並計算其區域數，然後確定一組獨立的程式執行路徑，最後為每一條基本路徑設計一個測試用例
②邏輯覆蓋測試
考察使用測試資料執行被測程式時對程式邏輯的覆蓋程度
通常希望選擇最少的測試用例來滿足所需的覆蓋標準
語句覆蓋：每個可執行語句都至少執行一次
判定覆蓋：每個判定的每個分支至少經過一次
條件覆蓋：每個判定中的每個條件的所有可能結果都至少出現一次
判定－條件覆蓋：每個判定的所有可能結果都至少執行一次，並且，每個判定中的每個條件的所有可能結果都至少出現一次
條件組合覆蓋：每個判定中條件結果的所有可能組合都至少出現一次
路徑覆蓋：每條可能執行到的路徑都至少經過一次（如果程式中包含環路，則要求每條環路至少經過一次）
③資料流測試
·根據程式中變數的定義（賦值）和引用位置來選擇測試用例
④迴圈測試
·簡單迴圈、巢狀迴圈、串接迴圈和非結構迴圈
⑤檢查程式是否做了應做的事僅是成功的一半，另一半是檢查程式是否做了不該做的事。
⑥在規劃測試時不要設想程式中不會出錯誤
5. 黑盒測試
黑盒法是把測試物件看做一個黑盒，測試時完全不考慮程式內部的邏輯結構與內部特性，只需根據需求規格說明書，測試程式的功能或程式的外部特性，因此黑盒發又稱為功能測試或資料驅動測試。
黑盒測試法注重於測試軟體的功能需求，主要試圖發現下列幾類錯誤：功能不對或遺漏；效能錯誤；初始化和終止錯誤；介面錯誤；資料結構或外部資料庫訪問錯誤。
黑盒法的主要測試方法：
①等價分類法
·將所有可能的輸入資料劃分成若干個等價類，然後在每個等價類中選取一個代表性的資料作為測試用例
②邊界值分析法
·挑選那些位於邊界附近的值作為測試用例
③錯誤推測法
·憑以往的經驗和直覺推測程式中某些可能存在的各種錯誤，從而針對性地設計測試用例
④因果圖法
·既考慮輸入條件的組合關係，又考慮輸出條件對輸入條件的依賴關係
⑤比較測試法
分別開發二個軟體版本，用相同的測試用例對二個版本的軟體分別進行測試，比較其測試結果
6.軟體測試的策略
·單元測試
單元測試（UnitTesting）,也稱模組測試（Module Testing）。測試的主要目的是檢查模組內部的錯誤。因此，測試方法應以白盒法為主。
單元測試的內容
①模組介面
②區域性資料結構
③重要的執行路徑
④邊界條件
⑤錯誤處理
·單元測試步驟：
由於被測試的模組往往不是獨立的程式，它處於整個軟體結構的某一層位置上，被其他模組呼叫或呼叫其他模組，其本身不能單獨執行，因此在單元測試時，需要為被測試模組設計若干輔助測試模組。輔助模組有兩種
一種是驅動模組(driver),用以模擬主程式或者呼叫模組的功能，用於向被測模組傳遞資料，接收、列印從被測模組返回的資料。一般只設計一個驅動模組。
另一種是樁模組（stub）,用於模擬那些由被測模組所呼叫的下屬模組的功能，可以設計一個或者多個樁模組，才能更好地對下屬模組進行模擬。
·整合測試（Integrated Testing）
整合測試（IntegratedTesting）是指在單元測試的基礎上，將所有模組按照設計要求組裝成一個完整的系統而進行的測試，也稱為聯合測試或組裝測試。重點測試模組的介面部分，需設計測試過程所使用的驅動模組或樁模組。測試方法以黑盒法為主
整合的方式
·非漸增式測試
非漸增式測試方法採用一步到位的方法來整合系統。首先對每個模組分別進行單元測試，然後再把所有的模組按設計要求組裝在一起進行測試。
非漸增式是將所有的模組一次連線起來，簡單、易行，節省機時，但測試過程中難於查錯，發現錯誤也很難定位，測試效率低。
·漸增式測試
它的整合式逐步實現的，組裝測試也是逐步完成的，也可以說它把單元測試與組裝測試結合起來進行的。該測試是逐個把未經過測試的模組組裝到已經測試過得模組上去，進行組裝測試，每加入一個新模組進行一次整合的測試。重複此過程直至程式組裝完畢。
在增量整合測試過程中發現的錯誤，往往與新加入的模組有關。
增量式整合又可分為自頂向下結合和自底向上結合
α測試和β測試
α測試是邀請某些有信譽的軟體使用者與軟體開發人員一道在開發場地對軟體系統進行測試，其測試環境要儘量模擬軟體系統投入使用後的實際執行環境。在測試過程中，軟體系統出現的錯誤或使用過程中遇到的問題，以及使用者提出的修改要求，均要由開發人員完整、如實地記錄下來，作為對軟體系統進行修改的依據。α測試的整個過程是在受控環境下，由開發人員和使用者共同參與完成的。α測試的目的是評價軟體的FLURPS，其中FLURPS 表示對一下專案的測試:
①Function Testing(功能測試)
②Local Area Testing(區域性化測試)
③Usability Testing(可使用性測試)
④Reliability Testing (可靠性測試)
⑤Performance Testing (效能測試)
⑥Supportability Testing(可支援性測試)
β測試是由軟體