計算機來源
計算機之父：圖靈(圖靈機，人工智能之父，圖靈測試)，馮諾依曼(馮諾依曼計算機體系：輸入,輸出,輸出,計算,控制,存儲)
C/S架構軟件（Client/Server,客戶端/服務器模式）：桌面級應用 響應速度快，客戶端需要安裝專門的軟件。比如QQ，微信。
C/S架構的優點：C/S架構的界面和操作可以很豐富（客戶端操作界面可以隨意排列，滿足客戶的需求），你們歡耍的英雄聯盟就是典型的C/S架構，界面樣式豐富。
本地響應速度快，在硬件和網絡環境不好的情況下用C/S能提高效率(其實是降低用戶憤怒值)
缺點：用戶群固定。由於程序安裝才可以使用，因此不適合面向一些不可知的用戶，維護成本高，發生一次升級，則所有客戶端的程序都需要改變，開發兼容性不高，在window下的cls軟件，Linux,下就永不了，開發方式不同。
B/S架構軟件：(Browser/Server,瀏覽器/服務器模式）web可實現跨平台，比如百度，實驗樓。
B/S架構的優點：客戶端無需安裝，只有web瀏覽器即可，
B/S架構可以直接放在廣域網上，通過一定的權限控制實現多客戶的訪問，交互性強
無需升級多個客戶端，升級服務器即可，可以隨時更新版本，無需用戶下載
缺點：在速度和安全性上需要花費巨大的成本設計，而且需要刷新頁面，在瀏覽器歷史版本的兼容問題不是很好，原始IE瀏覽器不太兼容以及新的web服務。
-
客戶端：用戶安裝的軟件；
-
服務端：統一管理數據庫的主機中的軟件就叫做服務端，再后來服務端不只是管理數據，外加處理業務邏輯。
瀑布模型
特點：每個階段只執行一次，
優點：開發的每個階段比較清晰,當前一階段完成后，才開始要去關注后續階段，避免后期大量返工的現象，還可以減少后期維護工作的人力和費用
缺點：不適應需求的變化，風險往往在后期顯露。
快速原型模型
在開發真實系統前，構造一個原型，在這個原型的基礎上，逐漸完成整個開發的工作
優點：克服瀑布模型的缺點，減少由於軟件需求不明確帶來的風險。快速構建軟件的原型，支持用戶參與
缺點：不適合大型的系統的開發（適合小型的，靈活性高的系統）
螺旋型
螺旋模型的特點：引進風險分析活動
優點：很大程度是一種風險驅動的方法體系
缺點：采用螺旋型需要具有相當豐富的風險評估和專門知識。
敏捷開發
v模型
介紹：v模型是最具有代表意義的測試模型，最早是由Paul Rook在20世紀80年代后期提出的，由英國國家計算機中新，提出改進軟件開發的效率和效果；
v模型本身軟件開發中瀑布模型的變種，它反映了測試活動與分析和設計的關系
v模型標明了測試過程中本身存在的不同階段，從左往右，描述了在開發過程和測試過程間的階段對應關系。
優點：v測試v模型包含了底層測試又包含高層測試
缺點：當需求變更(變化)時將會導致返回工作量非常大，模型靈活性比較低。
示意圖如下：
w模型
w模型介紹：測試伴隨着整個軟件開發周期，並且測試的對象不僅僅是程序，需求和設計同樣要測試。
優點：（1）強調測試伴隨整個軟件開發的周期，而且測試的對象不僅僅是程序，還包括需求和設計。
（2）更早的介入測試，能盡早得發現缺陷進行修復。
缺點：對於測試技術要就比較高，實踐起來比較困難。
示意圖如下：
測試的分類與理解
按測試階段划分為：單元測試，集成測試，系統測試，驗收測試。
按是否覆蓋源代碼分為：黑盒測試，白盒測試，灰盒測試。
按是否運行分為：靜態測試盒動態測試。
按是是否自動化分為：人工測試和自動化測試。
按其他分為：冒煙測試，回歸測試，隨機測試，探索測試。
單元測試：單元測試是對軟件中的最小可驗證單元進行檢查和驗證。比如對Java中的類和方法的測試。
單元測試的好處：
1、盡早的發現缺陷；
2、利於重構；
3、簡化集成；
4、文檔；
5、用於設計。
單元測試的不足：
1、不可能覆蓋所有的執行路徑，所以不可能保證捕捉到所有路徑的錯誤；
2、每行代碼需要3~5行代碼進行單元測試，存在投入與產出的平衡。
集成測試：集成測試是在單元測試的基礎上，把軟件單元按照軟件概要設計規格說明的規格要求，組裝成模塊、子系統或系統的過程中各部分工作是否達到或實現相應技術指標及要求。
集成測試包括BigBang、自頂向下、自底向上、核心系統集成、高頻集成。
系統測試 ：將經過集成測試的軟件，作為計算機系統的一部分，與系統中其他部分結合起來，在實際運行環境下進行一系列嚴格有效的測試，以發現軟件潛在的問題，保證系統的正常運行。
集成測試和系統測試之間的比較：
1、測試內容：集成測試是測試各個單元模塊之間的接口，系統測試是測試整個系統的功能和性能；
2、測試角度：集成測試偏重於技術的角度進行測試，系統測試是偏重於業務的角度進行測試。
測試的目的：盡可能多的發現缺陷，比如功能的錯誤，性能低下，易用性差。
測試的思路：先假設程序存在什么缺陷，然后執行程序來發現缺陷。
測試類型：白盒測試，黑盒測試。
白盒測試：看得見的程序內部結構，測試源程序的邏輯結構和實現細節。白盒測試必須由開發人員獨立執行，因為測試人員無法理解代碼內部邏輯。
黑盒測試：看不見的程序內部結構。
如：測試一個模塊時，白盒測試：要對所有代碼進行單步跟蹤測試，關注的是程序的內部細節。黑盒測試：只需測試模塊的接口是否要求，關注的是程序的外部實現。
冒煙測試：看整體的功能是否可以運行。
回歸測試：對之前的測過的功能再進行一次測試。
驗收測試 ：在軟件產品完成了功能測試和系統測試之后、產品發布之前所進行的測試活動。它是技術測試的最后一個階段，也稱為交付測試。
補充：
> 黑盒測試, 又稱數據驅動測試，完全不考慮程序內部結構和內部特性，注重於測試軟件的功能需求，只關心軟件的輸入數據和 輸出數據。 > > 白盒測試, 指的是把盒子打開，去研究里面的源代碼和程序結構。 > > 灰盒測試，是介於白盒測試與黑盒測試之間的一種測試，不僅關注輸出、輸入的正確性，同時也關注程序內部的情況。
冒煙測試: 冒煙測試就是對系統進行最基本功能的測試，保證基本的功能和流程能走通 回歸測試: 當修復一個BUG后，把之前的測試用例在新的代碼下進行再次測試 冒煙測試發生在代碼開發完成以后，會首先進行冒煙測試 當bug修改完成以后會進行回歸測試，判斷修改是否正確
- 功能性 - 可靠性 - 易用性 - 效率 - 可維護性 - 可移植性
公司的一個工作流程，以及測試人員的介入時機
