目錄
- 軟考官網 報名通道
- 軟考架構師筆記（一）：計算機系統基礎
- 軟考架構師筆記（二）：計算機網絡基礎與信息安全
- 軟考架構師筆記（三）：操作系統基礎
- 軟考架構師筆記（四）：企業信息化與系統規划
- 軟考架構師筆記（五）：系統需求工程 需求分析
- 軟考架構師筆記（六）：數據庫
- 軟考架構師筆記（七）：系統分析 系統設計
- 軟考架構師筆記（八）：系統架構
- 軟考架構師筆記（九）：軟件工程與項目管理
- 軟考架構師筆記（十）：系統測試 維護 穩定性
軟件測試
軟件測試可分為單元測試、集成測試、配置項測試、系統測試、驗收測試和回歸測試等類別。
單元測試：
也稱為模塊測試，測試的對象是可獨立編譯或匯編的程序模塊、軟件構件或面向對象軟件中的類（統稱為模塊），
其目的是檢查每個模塊能否正確地實現設計說明中的功能、性能、接囗和其他設計約束等條件，發現模塊內可能存在的各種差錯。
單元測試的技術依據是軟件詳細設計說明書。
測試一個模塊時，可能需要為該模塊編寫一個驅動模塊和若干個樁模塊。
驅動模塊用來調用被測模塊，它接收測試者提供的測試數據，並把這些數據傳送給被測模塊，然后從被測模塊接收測試結果，並以某種可見的方式將測試結果返回給測試人員；
樁模塊用來模擬被測模塊所調用的子模塊，它接受被測模塊的調用，檢驗調用參數，並以盡可能簡單的操作模擬被調用的子程序模塊功能，把結果送回被測模塊。
頂層模塊測試時不需要驅動模塊，底層模塊測試時不要樁模塊。
單元測試策略主要包括自頂向下的單元測試、自底向上的單元測試、孤立測試和綜合測試策略。
①自頂向下的單元測試 先測試上層模塊，再測試下層模塊。測試下層模塊時由於它的上層模塊已測試過，所以不必另外編寫驅動模塊。
②自底向上的單元測試。自底向上的單元測試先測試下層模塊，再測試上層模塊。測試上層模塊由於它的下層模塊已經測試過，所以不必另外編寫樁模塊。
③孤立測試不需要考慮每個模塊與其他模塊之間的關系，逐一完成所有模塊的測試。由於各模塊之間不存在依賴性，單元測試可以並行進行，但因為需要為每個模塊單獨設計驅動模塊和樁模塊，增加了額外的測試成本。
④綜合測試。上述三種單元測試策略各有利弊，實際測試時可以根據軟件特點和進度安排情況，將幾種測試方法混合使用，
集成測試：
目的是檢查模塊之間，以及模塊和已集成的軟件之間的接口關系，並驗證已集成的軟件是否符合設計要求。集成測試的技術依據是軟件概要設計文檔。
集成測試可以分為一次性組裝和增量式組裝，增量式組裝測試效果更好。集成測試計划一般在概要設計階段
系統測試：
的對象是完整的、集成的計算機系統，系統測試的目的是在真實系統工作環境下，驗證完整的軟件配置項能否和系統正確連接，並滿足系統/子系統設計文檔和軟件開發合同規定的要求。
系統測試的技術依據是用戶需求或開發合同。配置項測試的對象是軟件配置項，配置項測試的目的是檢驗軟件配置項與軟件需求規格說明的一致性。
確認測試：
主要驗證軟件的功能、性能和其他特性是否與用戶需求一致。驗收測試是指針對軟件需求規格說明，在交付前以用戶為主進行的測試。
回歸測試：
目的是測試軟件變更之后，變更部分的正確性和對變更需求的復合型，以及軟件原有的、正確的功能、性能和其他規定的要求的不損害性。
驗收確認測試
軟件確認測試一種針對需求的測試，是用戶參與的測試。它主要驗證軟件功能、性能及其它特性是否與用戶需求一致。
軟件確認測試包括：內部確認測試、Alpha、Beta和驗收測試。
α測試是由一個用戶在開發環境下進行的測試，也可以是公司內部的用戶在模擬實際操作環境下進行的測試。
α測試的目的：評價軟件產品的FLURPS(即功能、局域化、可用性、可靠性、性能和支持)。尤其注重產品的界面和特色。
α測試可以從軟件產品編碼結束之時開始，或在模塊(子系統)測試完成之后開始，也可以在確認測試過程中產品達到一定的穩定和可靠程度之后再開始。α測試即為非正式驗收測試。
Beta一種驗收測試。所謂驗收測試是軟件產品完成了功能測試和系統測試之后，在產品發布之前所進行的軟件測試活動，它是技術測試的最后一個階段，通過了驗收測試，產品就會進入發布階段。驗收測試一般根據產品規格說明書嚴格檢查產品，逐行逐字地對照說明書上對軟件產品所做出的各方面要求， 確保所開發的軟件產品符合用戶的各項要求。 通過綜合測試之后，軟件已完全組裝起來，接口方面的錯誤也已排除，軟件測試的最后一步——驗收測試即可開始。驗收測試應檢查軟件能否按合同要求進行工作，即是否滿足軟件需求說明書中的確認標准。
測試的分類
動態測試
黑盒測試 透明的，不可見細節
- 等價類划分
- 邊界值分析
- 錯誤推測
- 因果圖
白盒測試
- 基本路徑測試
- 循環覆蓋測試
- 邏輯覆蓋測試
灰盒測試
靜態測試
- 桌前檢查
- 代碼審查
- 代碼走查
測試特點
盡早、不斷的進行測試
程序員避免測試自己設計的程序
既要選擇有效、合理的數據，也要選擇無效、不合理的數據修改后應進行回歸測試
尚未發現的錯誤數量與該程序已發現錯誤數成正比
測試與調試的區別
測試的目的是找出存在的錯誤，而調試的目的是定位錯誤並修改程序以修正錯誤調試是測試之后的活動，測試和調試在目標、方法和思路上都有所不同測試從一個已知的條件開始，使用預先定義的過程，有預知的結果；
調試從一個未知的條件開始，結束的過程不可預計
測試過程可以事先設計，進度可以事先確定；調試不能描述過程或持續時間
系統轉換
遺留系統演化
如上圖，把對遺留系統的評價結果分列
在坐標的四個象限內。對處在不同象限的遺留系統采取不同的演化策略。
1.淘汰策略
第三象限為低水平、低價值區，即遺留系統的技術含量較低，且具有較低的業務價值。對這種遺留系統的演化策略為淘汰，即全面重新開發新的系統以代替遺留系統。完全淘汰是一種極端性策略，一般是企業的業務產生了根本變化，遺留系統已經基本上不再適應企業運作的需要；或者是遺留系統的維護人員、維護文檔資料都丟失了。經過評價，發現將遺留系統完全淘汰，開發全新的系統比改造舊系統從成本上更合算。對遺留系統的完全淘汰是企業資源的根本浪費，系統分析師應該通過對遺留系統功能的理解和借鑒，可以幫助新系統的設計，降低新系統開發的風險。
2.繼承策略
第二象限為低水平、高價值區，即遺留系統的技術含量較低，已經滿足企業運作的功能或性能要求，但具有較高的商業價值，目前企業的業務尚緊密依賴該系統。對這種遺留系統的演化策略為繼承。在開發新系統時，需要完全兼容遺留系統的功能模型和數據模型。為了保證業務的連續性，新老系統必須並行運行一段時間，再逐漸切換到新系統上運行。
3.改造策略
第一象限為高水平、高價值區，即遺留系統的技術含量較高，本身還有極大的生命力。系統具有較高的業務價值，基本上能夠滿足企業業務運作和決策支持的需要。這種系統可能建成的時間還很短，對這種遺留系統的演化策略為改造。改造包括系統功能的增強和數據模型的改造兩個方面。系統功能的增強是指在原有系統的基礎上增加新的應用要求，對遺留系統本身不做改變；數據模型的改造是指將遺留系統的舊的數據模型向新的數據模型的轉化。
4.集成策略
第四象限為高水平、低價值區，即遺留系統的技術含量較高，但其業務價值較低，可能只完成某個部門（或子公司）的業務管理。這種系統在各自的局部領域里工作良好，但對於整個企業來說，存在多個這樣的系統，不同的系統基於不同的平台、不同的數據模型，形成了一個個信息孤島，對這種遺留系統的演化策略為集成。
系統維護
軟件維護是生命周期的一個完整部分。
可以將軟件維護定義為需要提供軟件支持的全部活動這些活動包括在交付前完成的活動，以及交付后完成的活動。
交付前完成的活動包括交付后運行的計划和維護計划等；交付后的活動包括軟件修改、培訓、幫助資料等。
系統的可維護性分為：
- 易分析性
- 易改變性
- 穩定性
- 易測試性
系統的維護類型分為：
正確性（改正）維護：指改正在系統開發階段已發生而系統測試階段尚未發現的錯誤；為了識別和糾正軟件錯誤、改正軟件性能上的缺陷、排除實施中的誤使用，應當進行的診斷和改正錯誤的過程稱為改正性維護。
適應性維護：指使應用軟件適應信息技術變化和管理需求變化而進行的修改；外部環境（新的硬、軟件配置）、數據環境（數據庫、數據格式、數據輸入/輸出方法、數據存儲介質）可能發生變化。為使軟件適應這種變化而修改軟件的過程稱為適用性維護。
預防性維護：為了改進應用軟件的可靠性和可維護性，為了適應未來的軟硬件環境的變化，應主動增加預防性的新的功能，以使用系統適應各類變化而不被淘汰。
完善性維護：擴充功能和改善性能而進行的修改。對已有的軟件系統增加一些在系統分析和設計階段中沒有規定的功能與性能特征。
在軟件的使用過程中，用戶往往會對軟件提出新的功能與性能要求。為了滿足這些要求，需要修改或再開發軟件，以擴充軟件功能、增強軟件性能、改進加工效率、提高軟件的可維護性。這種情況下進行的維護活動成為完善性維護。
負載均衡
分布式：
集中式：
與分布式負載均衡方式相比，集中式負載均衡實現簡單
缺點：（1）系統的可擴展性不強，均衡器需要記錄所有計算機的負載信息。
（2）安全性較差，如果均衡器所在的計算機癱瘓，則會導致整個集群系統的癱瘓。
（3）實現不夠靈活，負載均衡器很難根據不同腳手架的特性配置不同的均衡策略。