軟件測試是干什么的
軟件測試是在軟件開發過程中對軟件產品進行評估、檢測和驗證的過程。主要目的是為了發現軟件中的缺陷、錯誤和問題，確保軟件符合規格說明書和用戶需求，并確保軟件的質量和可靠性。
軟件測試的主要任務包括：
驗證軟件的正確性：通過對軟件進行各種測試，確保軟件能夠按照規格說明書和用戶需求的要求正確地工作。
發現軟件中的缺陷和錯誤：通過模擬各種使用場景，發現軟件中的缺陷和錯誤，并及時進行修復和調整。
評估軟件的質量和可靠性：通過軟件測試，評估軟件的質量和可靠性，確保軟件達到預期的質量和性能要求。
確保軟件的安全性：通過對軟件的安全性進行測試，確保軟件能夠抵御各種攻擊和威脅。
軟件測試通常包括靜態測試和動態測試兩個方面。靜態測試主要是對軟件的文檔、代碼和設計進行檢查和審查，以確保軟件的正確性和一致性；動態測試主要是通過對軟件進行各種測試，驗證軟件的正確性和性能。
想要系統學習，你可以考察對比一下開設有相關專業的熱門學校免費獲取資料好的學校擁有根據當下企業需求自主研發課程的能力，能夠在校期間取得大專或本科學歷，中博軟件、南京課工場、南京北大青鳥等開設相關專業的學校都是不錯的，建議實地考察對比一下。
祝你學有所成，望采納。
北大青鳥學生課堂實錄
靜態測試的質量度量
有了嚴格的編程規范，只能算是萬里長征邁出了*步。要提高軟件的可重用性，以及軟件的可維護性，還需要進一步的努力，即靜態質量度量。靜態質量度量所依據的標準是ISO9126。在該標準中，軟件的質量用以下幾個方面來衡量，即功能性()、可靠性()、可用性(Usability)、有效性()、可維護性（）、可移植性()。以ISO9126質量模型為基礎，可以構造質量度量模型。具體到靜態測試，這里主要關注的是可維護性。要衡量軟件的可維護性，可以從四個方面去度量，即可分析性（）、可改變性（）、穩定性（Stability）以及可測試性（）。具體到軟件的可測試性怎么去衡量。又可以從三個度量元去考慮，例如圈復雜度、輸入/輸出的個數等。圈復雜度越大，說明代碼中的路徑越多；路徑越多，意味著要去做測試，需要寫更多的測試用例。輸入/輸出的個數同樣的道理。在具體的實踐中，專門的質量度量工具是必要的。沒有工具的支持，這一步很難只靠人工完成。在這個階段，比較專業的工具有Testbed、Logiscope等。
軟件工程 靜態測試的主要方法有哪些
（1）人工檢測：是指不依靠計算機而是靠人工審查程序或評審軟件，包括代碼檢查、靜態結構分析和代碼質量度量等；
（2）計算機輔助靜態分析：利用靜態分析工具對被測試程序進行特性分析，從程序中提取一些信息，以便檢查程序邏輯的各種缺陷和可疑的程序構造。
靜態測試包括代碼檢查、靜態結構分析、代碼質量度量等。它可以由人工進行，充分發揮人的邏輯思維優勢，也可以借助軟件工具自動進行。
擴展資料：
代碼檢查包括代碼走查、桌面檢查、代碼審查等，主要檢查代碼和設計的一致性，代碼對標準的遵循、可讀性，代碼的邏輯表達的正確性，代碼結構的合理性等方面；可以發現違背程序編寫標準的問題，程序中不安全、不明確和模糊的部分，找出程序中不可移植部分、違背程序編程風格的問題，包括變量檢查、命名和類型審查、程序邏輯審查、程序語法檢查和程序結構檢查等內容。
在實際使用中，代碼檢查比動態測試更有效率，能快速找到缺陷，發現30%～70%的邏輯設計和編碼缺陷；代碼檢查看到的是問題本身而非征兆。但是代碼檢查非常耗費時間，而且代碼檢查需要知識和經驗的積累。
代碼檢查應在編譯和動態測試之前進行，在檢查前，應準備好需求描述文檔、程序設計文檔、程序的源代碼清單、代碼編碼標準和代碼缺陷檢查表等。靜態測試具有的發現缺陷早、降低返工成本、覆蓋重點和發現缺陷的概率高的優點以及耗時長、不能測試依賴和技術能力要求高的缺點。
簡述"軟件測試能保證軟件質量"是否正確
軟件測試是可以保證軟件質量，但不是說你測試一下就可以保證質量的。
你需要去了解如何去保證軟件質量，你可以看下下面的
軟件在沒有發布之前的開發過程主要分為需求分析、設計、編碼和驗證四個階段，最終的軟件質量與這四個階段的各自質量之間的關系如果用C語言來表達的話應當是： 最終的軟件質量 = 需求分析質量 && 設計質量 && 編碼質量 && 驗證質量 即，最終的質量來自于各階段質量之“與”，只要其中一個環節質量是差，則產品的整體質量都將是差，千萬不要認為是“或”的關系。由此看來每一個階段的質量都起著決定性的作用。 以上提及的四個階段的質量將引出以下幾個軟件質量保證的關鍵要素。 完備的需求分析 需求分析的目的是讓項目組明白要做什么，是決定所開發出來的軟件應當是“長什么樣的”，顯然完備的需求分析是高質量軟件的前提。如果所開發出來的軟件與用戶所希望的并不一致，那不可能讓用戶說“這個軟件的質量很好” 。如果方向不對，軟件開發得再“好”也沒有意義。需求分析失誤所帶來的開發成本是高昂的，這一點在《軟件工程》這類書籍中都會提及，因此，整個行業對于需求分析的重要性都具有足夠的認識。當然，知道其重要性與如何獲得完備的需求分析又是兩回事，至于如何做好需求分析請讀者參考相關書籍。 需求分析如果出現失誤的話有一個特點—— 它一定會暴露！只不過存在是暴露在軟件開發過程中還是在用戶手中之別。因此，需求分析所造成的問題盡管嚴重，但它能被發現進而能得到項目組的重視，從而也一定能被修復，只是不同階段發現這類問題所花費的成本將有所不同。 設計 設計階段是通過設計方法找出軟件實現更好的方法，注意這里是“更好”兩個字，而不是強調*。 不良設計并不會象需求分析失誤那樣很容易暴露出其本質，相反，它所暴露出的更多是表象，比如邏輯復雜、維護時舉步為艱等等。如果參與者不具備一定的洞察力以發現隱藏在現象背后的不良設計本質，則很有可能身受其害卻不能自拔，還以為“本來就有那么復雜”。 項目的開發是一個逐步演進的過程，項目組成員對于需求的理解也是逐步加深的，一開始合適的設計到后面看來很有可能就不夠全面或顯得力不從心，如果仍沿用以前的設計則自然將暴露出它的不足，進而會出現需要更高的維護成本。重構思想的提出，就是用于幫助項目演進設計的，當然，在運用重構方法時，應盡可能保證項目有足夠的單元測試用例，以預防重構時又引入新的缺陷。重構不只是一個詞，其核心應當是一個方法論，一個用于優化設計的方法論。 編程好習慣 設計階段輸出的結果就是藍圖，但好的藍圖并不能保證*的質量一定就好。拿造房子打個比方，圖紙設計得再好，如果建造時用的材料不過關，那最終的房子一定好不了。那軟件開發中的“建筑材料”又是什么呢？就是程序員所編寫的代碼。如何保證其質量呢？這需要通過良好的編程習慣去保證。 在現實的項目中，設計有可能與編碼會有一定的揉合，即通過進行一定的編碼來輔助設計。這種實踐方式并不影響這里將設計與編碼分為兩個質量保證關鍵要素。 驗證 驗證很容易讓人想到質量保證的常用方法之一，即測試。但驗證應當包含更多的內涵，比如求證軟件需求是用戶所希望的就是其中的一種。 對于驗證的理解仍需要拿房屋的建造作為一個比方，以便加深理解。在房屋的建造過程中，當建筑材料到了工地以后，需要對其進行檢驗，以保證它的質量是合格的，否則不能用于建造。對應于軟件開發，這個階段就是單元測試。當軟件工程師編寫了代碼以后如何保證代碼的行為是其所希望的呢？那只能通過單元測試去驗證。房子建造好了以后，還得對房子進行整體的驗收以確保其最終是合格的。比如抽查墻壁所使用的水泥與沙的配比是合適的。雖然水泥和沙在進入工地時都經過了質檢且是合格的，但在建造的過程中需要按一定的比例混合它們以作建筑粘合劑，而混合比例將確定粘合強度。在軟件開發過程中，軟件集成測試就如同房子在建造好了以后的驗收。 從上面的比方能得出幾個結論。*，在軟件開發過程中單元測試是必不可少的。它的缺少如同將沒有檢驗過的建筑材料用于建造一樣。第二，單元測試應當在集成測試之前完成。有的項目在一開始時并沒有單元測試流程，但后來發現需要增加這個環節，于是出現了集成測試完成了以后，再進行單元測試這種情形。這種情形還是有點怪怪的，這如同房子已造好了，再將墻打掉去檢查里面的磚是否是好的一樣。“將墻打掉檢查磚”這種行為的勇氣雖然可佳，但是如果盡早地在項目中部署單元測試就能避免這種怪現象的發生。 集成（包括開發集成和系統集成）測試在軟件行業被廣泛采用以保證軟件質量，但單元測試對于軟件質量保證的重要性在整個行業還缺乏廣泛的、深刻的認識，其更多地被當作是負擔而不是一種有效的質量保證手段。
什么是軟件的靜態測試和動態測試，他們的區別？
靜態方法是指不運行被測程序本身，僅通過分析或檢查源程序的語法、結構、過程、接口等來檢查程序的正確性。
對需求規格說明書、軟件設計說明書、源程序做結構分析、流程圖分析、符號執行來找錯。
動態測試方法是指通過運行被測程序，檢查運行結果與預期結果的差異，并分析運行效率、正確性和健壯性等性能。
靜態測試和動態測試主要有測試部分，測試方法，測試方式三個方面的區別。
1、測試部分的不同
靜態測試是指測試不運行的部分：只是檢查和審閱,如規范測試、軟件模型測試、文檔測試等。
動態測試是通常意義上的測試，也就是運行和使用軟件。
2、測試方式不同
靜態測試，通過評審文檔、閱讀代碼等方式測試軟件稱為靜態測試，通過運行程序測試軟件稱為動態測試。
3、測試方法不同
靜態測試是指不用執行程序的測試，它主要采取方案—代碼走查、技術評審、代碼審查的方法對軟件產品進行測試。
動態測試主要通過構造測試實例、執行程序、分析程序的輸出結果這三種方法來對軟件進行測試。
擴展資料：
靜態測試的測試要點：
1、挑選合適的復審員
復審活動人數控制在3-7個人，每次復審活動不要超過2小時，否則應該功能分解或者形式分解。準備充分的復審一小時以內完成。
2、管理*的參與
為復審活動分配時間和資源，特殊情況關于時間、場地選取的一些建議。IBM一個關于電話會議進行復審的一個案例。
3、注意事項
結隊復審方法，對比結隊編程。選擇那些不會引起爭論不休的內容作為每次初期復審對象。
對走查、審查和技術復審的活動指南進行復審，效果會很好。
4、技術復審與項目管理
確定兩次復審之間的時間間隔的根據使你在完全失去對工作狀況的了解的情況下能夠堅持的最長時間。
不管做什么都會犯錯誤，因此把錯誤犯在最安全的地方是一個不錯的策略，這也是復審活動“寧缺勿濫”的理由。
5、復審領導
復審領導的工作是保證復審活動獲得成功-或者是負責匯報復審活動未能獲得成功的原因。
未能成功原因比如：成員在材料充分的情況下依然沒有做好準備、預定的會議室發現泥水匠正在拆墻。
對于復審領導的個人品質很難一概而論，一句話：結果比方式更重要。畢竟領導風格千千種，很難說那種是對是錯。
任何可能因為職位的原因引起利益沖突的人都不應該出現在復審現場，所以，領導對自己的團隊進行復審應該盡力避免。
如果復審偏離主題，復審領導首先要做的是，留心觀察這次跑題是否是某些成員掩蓋其缺乏準備的一個詭計。
6、規則和慣例
準備好你的工作，時刻注意自己評審的是產品而不是同事，任何人都可能犯錯。
注意你的語言，面和負面的評價，實在沒有正面的評價可以“我喜歡你用來評審的水筆的顏色。”提出問題，但不要解決問題。
7、規則
要表現出對復審過程的信任，要為復審過程安排時間，要做好準備讓真正合適的人去參加復審，鼓勵復審活動的參與者做好準備工作。
參考資料來源：百度百科-靜態測試
參考資料來源：百度百科-動態測試
軟件測試主要學什么，在南京有沒有？
軟件測試的分類
從是否關心軟件內部結構和具體實現的角度劃分
A.白盒測試
B.黑盒測試
C.灰盒測試
從是否執行程序的角度
A.靜態測試
B.動態測試。
從軟件開發的過程按階段劃分有
A.單元測試
B.集成測試
C.確認測試
D.系統測試
E.驗收測試
* 測試過程按4個步驟進行，即單元測試、集成測試、確認測試和系統測試及發版測試。
* 開始是單元測試，集中對用源代碼實現的每一個程序單元進行測試，檢查各個程序模塊是否正確地實現了規定的功能。
* 集成測試把已測試過的模塊組裝起來，主要對與設計相關的軟件體系結構的構造進行測試。
* 確認測試則是要檢查已實現的軟件是否滿足了需求規格說明中確定了的各種需求，以及軟件配置是否完全、正確。
* 系統測試把已經經過確認的軟件納入實際運行環境中，與其它系統成份組合在一起進行測試。
單元測試 (Unit Testing)
* 單元測試又稱模塊測試，是針對軟件設計的最小單位 — 程序模塊，進行正確性檢驗的測試工作。其目的在于發現各模塊內部可能存在的各種差錯。
* 單元測試需要從程序的內部結構出發設計測試用例。多個模塊可以平行地獨立進行單元測試。
1. 單元測試的內容
* 在單元測試時，測試者需要依據詳細設計說明書和源程序清單，了解該模塊的I/O條件和模塊的邏輯結構，主要采用白盒測試的測試用例，輔之以黑盒測試的測試用例，使之對任何合理的輸入和不合理的輸入，都能鑒別和響應。
(1) 模塊接口測試
* 在單元測試的開始，應對通過被測模塊的數據流進行測試。測試項目包括：
– 調用本模塊的輸入參數是否正確；
– 本模塊調用子模塊時輸入給子模塊的參數是否正確；
– 全局量的定義在各模塊中是否一致；
* 在做內外存交換時要考慮：
– 文件屬性是否正確；
– OPEN與CLOSE語句是否正確；
– 緩沖區容量與記錄長度是否匹配；
– 在進行讀寫操作之前是否打開了文件；
– 在結束文件處理時是否關閉了文件；
– 正文書寫／輸入錯誤，
– I／O錯誤是否檢查并做了處理。
(2) 局部數據結構測試
* 不正確或不一致的數據類型說明
* 使用尚未賦值或尚未初始化的變量
* 錯誤的初始值或錯誤的缺省值
* 變量名拼寫錯或書寫錯
* 不一致的數據類型
* 全局數據對模塊的影響
(3) 路徑測試
* 選擇適當的測試用例，對模塊中重要的執行路徑進行測試。
* 應當設計測試用例查找由于錯誤的計算、不正確的比較或不正常的控制流而導致的錯誤。
* 對基本執行路徑和循環進行測試可以發現大量的路徑錯誤。
(4) 錯誤處理測試
* 出錯的描述是否難以理解
* 出錯的描述是否能夠對錯誤定位
* 顯示的錯誤與實際的錯誤是否相符
* 對錯誤條件的處理正確與否
* 在對錯誤進行處理之前，錯誤條件是否已經引起系統的干預等
(5) 邊界測試
* 注意數據流、控制流中剛好等于、大于或小于確定的比較值時出錯的可能性。對這些地方要仔細地選擇測試用例，認真加以測試。
* 如果對模塊運行時間有要求的話，還要專門進行關鍵路徑測試，以確定最壞情況下和平均意義下影響模塊運行時間的因素。
2. 單元測試的步驟
* 模塊并不是一個獨立的程序，在考慮測試模塊時，同時要考慮它和外界的聯系，用一些輔助模塊去模擬與被測模塊相聯系的其它模塊。
– 驅動模塊 (driver)
– 樁模塊 (stub) —— 存根模塊
* 如果一個模塊要完成多種功能，可以將這個模塊看成由幾個小程序組成。必須對其中的每個小程序先進行單元測試要做的工作，對關鍵模塊還要做性能測試。
* 對支持某些標準規程的程序，更要著手進行互聯測試。有人把這種情況特別稱為模塊測試，以區別單元測試。
集成測試（ Testing）
* 集成測試 (集成測試、聯合測試）
* 通常，在單元測試的基礎上，需要將所有模塊按照設計要求組裝成為系統。這時需要考慮的問題是：
– 在把各個模塊連接起來的時候，穿越模塊接口的數據是否會丟失；
– 一個模塊的功能是否會對另一個模塊的功能產生不利的影響；
– 各個子功能組合起來，能否達到預期要求的父功能；
– 全局數據結構是否有問題；
– 單個模塊的誤差累積起來，是否會放大，從而達到不能接受的程度。
在單元測試的同時可進行集成測試，
發現并排除在模塊連接中可能出現
的問題，最終構成要求的軟件系統。
* 子系統的集成測試特別稱為部件測試，它所做的工作是要找出集成后的子系統與系統需求規格說明之間的不一致。
* 通常，把模塊集成成為系統的方式有兩種
– 一次性集成方式
– 增殖式集成方式
1. 一次性集成方式(big bang)
* 它是一種非增殖式組裝方式。也叫做整體拼裝。
* 使用這種方式，首先對每個模塊分別進行模塊測試，然后再把所有模塊組裝在一起進行測試，最終得到要求的軟件系統。
2. 增殖式集成方式
* 這種集成方式又稱漸增式集成
* 首先對一個個模塊進行模塊測試，然后將這些模塊逐步組裝成較大的系統
* 在集成的過程中邊連接邊測試，以發現連接過程中產生的問題
* 通過增殖逐步組裝成為要求的軟件系統。
(1) 自頂向下的增殖方式
* 這種集成方式將模塊按系統程序結構，沿控制層次自頂向下進行組裝。
* 自頂向下的增殖方式在測試過程中較早地驗證了主要的控制和判斷點。
* 選用按深度方向組裝的方式，可以首先實現和驗證一個完整的軟件功能。
(2) 自底向上的增殖方式
* 這種集成的方式是從程序模塊結構的*層的模塊開始集成和測試。
* 因為模塊是自底向上進行組裝，對于一個給定層次的模塊，它的子模塊（包括子模塊的所有下屬模塊）已經組裝并測試完成，所以不再需要樁模塊。在模塊的測試過程中需要從子模塊得到的信息可以直接運行子模塊得到。
* 自頂向下增殖的方式和自底向上增殖的方式各有優缺點。
* 一般來講，一種方式的優點是另一種方式的缺點。
(3) 混合增殖式測試
* 衍變的自頂向下的增殖測試
– 首先對輸入／輸出模塊和引入新算法模塊進行測試;
– 再自底向上組裝成為功能相當完整且相對獨立的子系統;
– 然后由主模塊開始自頂向下進行增殖測試。
* 自底向上-自頂向下的增殖測試
– 首先對含讀操作的子系統自底向上直至根結點模塊進行組裝和測試;
– 然后對含寫操作的子系統做自頂向下的組裝與測試。
* 回歸測試
– 這種方式采取自頂向下的方式測試被修改的模塊及其子模塊;
– 然后將這一部分視為子系統，再自底向上測試。
關鍵模塊問題
* 在組裝測試時，應當確定關鍵模塊，對這些關鍵模塊及早進行測試。
* 關鍵模塊的特征：
① 滿足某些軟件需求；
② 在程序的模塊結構中位于較高的層次（高層控制模塊）；
③ 較復雜、較易發生錯誤；
④ 有明確定義的性能要求。
確認測試（ Testing）
* 確認測試又稱有效性測試。任務是驗證軟件的功能和性能及其它特性是否與用戶的要求一致。
* 對軟件的功能和性能要求在軟件需求規格說明書中已經明確規定。它包含的信息就是軟件確認測試的基礎。
1. 進行有效性測試（黑盒測試）
* 有效性測試是在模擬的環境 (可能就是開發的環境) 下，運用黑盒測試的方法，驗證被測軟件是否滿足需求規格說明書列出的需求。
* 首先制定測試計劃，規定要做測試的種類。還需要制定一組測試步驟，描述具體的測試用例。
* 通過實施預定的測試計劃和測試步驟，確定
– 軟件的特性是否與需求相符；
– 所有的文檔都是正確且便于使用；
– 同時，對其它軟件需求，例如可移植性、兼容性、出錯自動恢復、可維護性等，也都要進行測試
* 在全部軟件測試的測試用例運行完后，所有的測試結果可以分為兩類：
– 測試結果與預期的結果相符。這說明軟件的這部分功能或性能特征與需求規格說明書相符合，從而這部分程序被接受。
– 測試結果與預期的結果不符。這說明軟件的這部分功能或性能特征與需求規格說明不一致，因此要為它提交一份問題報告。
2. 軟件配置復查
n 軟件配置復查的目的是保證
u 軟件配置的所有成分都齊全；
u 各方面的質量都符合要求；
u 具有維護階段所必需的細節；
u 而且已經編排好分類的目錄。
n 應當嚴格遵守用戶手冊和操作手冊中規定的使用步驟，以便檢查這些文檔資料的完整性和正確性。
驗收測試（ Testing）
* 在通過了系統的有效性測試及軟件配置審查之后，就應開始系統的驗收測試。
* 驗收測試是以用戶為主的測試。軟件開發人員和QA（質量保證）人員也應參加。
* 由用戶參加設計測試用例，使用生產中的實際數據進行測試。
* 在測試過程中，除了考慮軟件的功能和性能外，還應對軟件的可移植性、兼容性、可維護性、錯誤的恢復功能等進行確認。
* 確認測試應交付的文檔有：
– 確認測試分析報告
– 最終的用戶手冊和操作手冊
– 項目開發總結報告。
系統測試（System Testing）
* 系統測試，是將通過確認測試的軟件，作為整個基于計算機系統的一個元素，與計算機硬件、外設、某些支持軟件、數據和人員等其它系統元素結合在一起，在實際運行環境下，對計算機系統進行一系列的組裝測試和確認測試。
* 系統測試的目的在于通過與系統的需求定義作比較, 發現軟件與系統的定義不符合或與之矛盾的地方。
測試能證明軟件沒有任何缺陷么
原則1——測試顯示缺陷的存在，但不能證明系統不存在缺陷。測試可以減少軟件中存在未被發現缺陷的可能性，但即使測試沒有發現任何缺陷，也不能證明軟件或系統是完全正確的。
2）原則2——窮盡測試是不可能的。由于有太多的輸入組合、有太多的路徑，而且時間是有限的，無法做到完全的測試（*測試覆蓋率）。通過運用風險分析和不同系統功能的測試優先級，來確定測試的關注點，從而替代窮盡測試。
3）原則3——測試盡早介入。軟件項目一啟動，軟件測試就應開始，也就是從項目啟動的*天開始，測試人員就應參與項目的各種活動和開展對應的測試活動。測試工作進行得越早，軟件開發的劣質成本就越低，并能更好地保證軟件質量。例如，在代碼完成之前，可以進行各種靜態測試，主導或積極參與需求文檔、產品規格說明書等的評審，將問題消滅在萌芽階段。
4）原則4——缺陷集群性。版本發布前進行測試所發現的大部分缺陷和軟件運行失效是由于少數軟件模塊引起的。一段程序中發現的錯誤數越多，意味著這段程序的質量越不好。錯誤集中發生的現象，可能和程序員的編程水平、經驗和習慣有很大的關系，也可能是程序員在寫代碼時情緒不夠好或不在狀態等。如果在同樣的測試效率和測試能力的條件下，缺陷發現得越多，漏掉的缺陷就越多。這也就是著名的Myers 反直覺原則：在測試中發現缺陷多的地方，會有更多的缺陷沒被發現。假定測試能力不變，通過測試會發現產品中90％的缺陷。如果在模塊A 發現了180 個缺陷，在模塊B 發現了45 個缺陷，意味著模塊A 還有20 個缺陷沒被發現，而模塊B 只有5個缺陷未被發現。所以，對發現錯誤較多的程序段，應進行更深入的測試。
如何看待軟件測試在保證產品質量中所起的作用？
1. 軟件測試基礎（P1-3）
測試基礎知識的學習目標
本章的學習目標：完成下面模塊(module)的學習后，將明確能做什么。
1.1測試的必要性
? 通過具體的例子，來描述軟件中的缺陷(defect)會以什么樣的方式損害個人、損害環境或者損害公司利益。
? 區分引起缺陷的根本原因及其影響之間的區別。
? 通過舉例的方式說明為什么需要測試。
? 描述為什么測試是質量保證(quality assurance)的一部分，通過舉例說明測試是如何來提高軟件質量的。
? 理解術語錯誤(mistake)、缺陷、失效(failure)以及相應的術語錯誤(error)和bug之間的區別。
1.2 什么是測試 (K2)
? 認識測試的共同目標。
? 描述測試作為發現缺陷的一種手段，測試在軟件開發、維護和運行中的目的，同時通過測試，可以增強對被測軟件的信心并獲得一些相關的信息，從而用來預防缺陷。
1.3 測試的基本原則
? 說明測試的基本原則。
1.4 基本的測試過程
再次認識從計劃到測試結束過程中測試的基本活動，以及在每個活動中的主要任務（K1）。
1.5 測試的心理學
? 認識測試的成功與否，會受測試心理因素的影響：
? 清楚的目標；
? 自己測試和獨立測試之間的平衡；
? 認識到謙恭的溝通和缺陷反饋在測試中的作用。
? 對比測試員(tester)和開發員(developer)的心理差異。
1.1 為什么需要測試 （P4-5）
術語
缺陷(bug)、缺陷(defect)、錯誤(error)、失效(failure)、故障（fault）、錯誤(mistake)、質量（quality）、風險(risk)、軟件(software)、測試(testing)。
1.1.1 軟件系統的狀況
在當今社會，軟件系統(system)越來越成為生活中不可或缺的一部分，包括從商業應用（比如銀行系統）到消費產品（比如汽車）各個領域。然而，很多人都有這樣的經歷：軟件并沒有按照預期進行工作。軟件的不正確執行可能會導致許多問題，包括經濟的損失、時間的浪費和商業信譽的丟失等等，甚至導致人身傷害和死亡。
1.1.2 引起軟件缺陷的原因
所有的人都會犯錯誤。該錯誤error會成為設計的代碼、軟件、系統和文檔中的缺陷。當存在缺陷的代碼被執行時，系統就可能無法執行期望的指令（或者做了不應該執行的指令），從而引起軟件失效（故障）。雖然軟件、系統和文檔中的缺陷可能會引起失效，但并不是所有的缺陷都會這樣。
產生缺陷的原因是多種多樣的：人們本身容易犯錯誤、時間的壓力、復雜的代碼、復雜的系統架構、技術的革新、或者系統之間的配合工作等。
失效也可能是由于環境條件引起的：放射、電磁輻射和污染等都有可能引起硬件的故障，或者由于硬件條件的改變而影響軟件的執行。
※ error（錯誤） → 缺陷（fault，bug） → 故障
1.1.3 在軟件開發、維護和運行中測試的角色
對軟件系統和文檔進行嚴格的測試,可以減少軟件系統在運行環境中的風險，假如在軟件正式發布之前發現和修正了缺陷，就可以提高軟件系統的質量。
進行軟件測試也可能是為了滿足合同和法律法規的需求，或者是為了滿足行業標準。
1.1.4 測試和質量
通過測試，根據發現的缺陷，就可能發現軟件系統在功能()和非功能(non-)需求方面的缺陷，對軟件質量(software quality)進行評判。飛功能需求包括：可靠性()、可用性(usability）、效率()和可維護性()等方面，關于非功能測試方面的更多信息，可以參考第二章。更多關于軟件特征的信息，可以參考[ Software - Software Product Quality (ISO9126) ]。※ISO9126對應與國內規格：JIS-X0129。
當測試發現很少或者沒有發現缺陷的時候，就會對軟件的質量充滿信心。一個設計正確、合理的測試過程完成并順利通過，可以降低整個系統存在問題的風險。而對測試過程中發現的缺陷進行了修正，則軟件系統的質量就會提高。
我們應該從以前的項目中總結經驗教訓。通過分析在其他項目中發現的缺陷和引起缺陷的根本原因，我們就可以改進測試過程(process)。相繼地，過程的改進又可以預防相同的缺陷再次發生，從而提高以后系統的質量。
測試應該作為質量保證的各種作業中（例如：開發標準、教育、缺陷分析）的不可或缺的一部分。
1.1.5 測試是否充分
測試應該進行到哪種程度，取決于技術、產品、項目風險的水平，以及在時間和預算等方面項目上的限制。 （風險將在第5章進行詳細描述）
測試需要給利益相關者提供足夠的信息，幫助他們決定是否發布被測的軟件或系統，是否繼續進行下階段的開發或直接將產品交給用戶。
追求完全的品質，從成本的角度來看沒有效果
缺陷成本：為了修正而產生的成本、產生不良結果的成本
Joseph M. Juran 1.テストの必要性（3/3
1.2 什么是測試（P7-8）
術語
代碼(code)、調試(debugging)、（軟件）開發()、需求()、評審(review)、測試依據(test basis)、測試用例(test case)、測試(testing)、測試目標(test )。
背景
在一般人的理解當中，測試活動只包含了運行測試，也就是執行軟件。但實際上這只是測試的一部分，而不是測試的所有活動。
測試的活動包含了測試執行之前和之后的一些活動，包括計劃(planning)和控制(control)、選擇測試條件(test condition)、設計測試用例(test case)、檢查測試結果(result)、評估完成準則( criteria)、報告測試過程(test process)及被測系統、測試結束或總結。測試同時也包括文檔的評審(review)（包括代碼）和靜態分析(static analysis)。
動態測試(dynamic testing)和靜態測試這兩種手段都可以達到相似的目標，即以提供信息來改進被測試軟件系統的質量，以及改善開發和測試的過程。
? 測試執行前的作業
- 計劃、測試條件、測試用例設計
? 測試執行時的作業
- 執行結果的Check、完了基準的驗證、測試結果報告
? 測試執行后的作業
- 軟件的整理
? 通過整體的作業
- 項目控制、評審
※ 在下一節的《基本的測試流程》中，會將測試執行前的作業分為計劃和設計，當作5個流程來定義。
不同的測試具有不同的測試目標：
? 發現缺陷；
? 獲取對產品質量的信心，以及提供信息；
? 預防缺陷。
在軟件生命周期早期進行測試用例的設計，可以幫助避免將缺陷引入代碼中。同時文檔的評審（例如需求文檔）也可以預防將缺陷引入代碼。
不同的測試階段，需要考慮不同的測試目標。比如，在開發中的測試里，如單元測試(unit testing)、集成測試( testing)和系統測試(system testing)等，測試的主要目標是盡可能的發現失效，從而識別和修正盡可能多的缺陷。在驗收測試（ testing）中，測試的主要目標是用來確認系統是否按照預期工作，從而在系統是否滿足需求方面獲取信心。而在有些情況下，測試的主要目標是對軟件的質量進行評估（不是為了修正缺陷），從而為利益相關人提供這樣的信息：在給定時間內發布的系統版本所存在的風險。而保守測試 (維護測試 testing)通常是為了驗證在開發過程中的變更是否引入新的缺陷。在運行測試階段，測試的主要目標是為了評估系統的特征，比如可靠性或可用性等。
必須明確，調試和測試是兩個不同的概念。測試可以發現由于軟件存在的缺陷引起的失效。而調試是一種開發活動，用來識別引起缺陷的原因，修改代碼以及驗證是否正確的修改了軟件的缺陷。隨后由測試員進行的確認測試( testing)是為了確認修改的代碼已經解決了失效問題。每個活動的職責是截然不同的，即測試員進行測試，開發人員進行調試。
1.3 測試的基本原則
術語
窮盡測試( testing)。
原則
在過去40年中，軟件測試界提出了很多的測試原則，并且提供了適合所有測試的一些共同的測試指南。
原則1 － 測試顯示缺陷的存在
測試可以顯示缺陷(defect)的存在，但不能證明系統不存在缺陷。測試可以減少軟件中存在缺陷的可能性，但即使測試沒有發現任何缺陷，也不能證明軟件或系統是完全正確的。
原則2 － 窮盡測試是不可能的
除了小型項目，進行完全（各種輸入和前提條件的組合）的測試是不現實的。通過運用風險管理(risk )和不同系統功能的測試優先級，來確定測試的關注點，從而替代窮盡測試。
原則3 － 測試盡早介入
在軟件或系統開發生命周期中，測試活動應該盡可能早的介入，并且應該將關注點放在已經定義的測試目標(test objective)上。
原則4 － 缺陷集群性
版本發布前進行的測試所發現的大部分缺陷和軟件運行失效是由于少數軟件模塊引起的。
原則5 － 殺蟲劑悖論
同樣的測試用例一遍一遍重復進行測試，*將不再能夠發現新的缺陷。為了克服這種殺蟲劑悖論，測試用例需要經常性的評審和修改，同時需要不斷增加新的不同的測試用例來測試軟件或系統的不同部分，從而發現潛在的更多的缺陷。
原則6 － 測試活動依賴于測試內容
針對不同的測試內容，進行的測試活動也是不同的。比如，對關注安全的軟件進行測試，與一般的商業軟件測試的重點是不一樣的。
原則7 － 0缺陷的謬論
假如系統無法使用，或者系統不能完成客戶的需求和期望，發現和修改缺陷是沒有任何幫助的。
「所有的模式都是錯誤的。但是，有的模式能夠起到作用」
原則上，是將現實世界抽象化、故意讓很多信息欠缺。
欲將軟件開發和測試這種極富多樣性的活動，用幾個原則來進行說明，
本身就不太可能。但是，這種原則對于理解測試的重要一面，確實有著
非常重要的作用。總而言之，工具是可以使用的。
1.4 基本的測試過程
術語
確認測試( testing)、出口準則(exit criteria)、事件(incident)、回歸測試( testing)、測試依據(test basis)、測試條件(test condition)、測試覆蓋(test coverage)、測試數據(test data)、測試執行(test execution)、測試日志(test log)、測試計劃(test plan)、測試策略(test strategy)、測試總結報告(test summary report)、測試件(testware)。
背景
測試最顯而易見的活動是測試的執行。但是為了提高效率，在測試計劃中，同樣需要保留比較多的時間用于計劃測試活動、設計測試用例、準備測試的執行和評估測試的狀態。
基本的測試過程主要由下面一些活動組成：
? 1 計劃和控制；
? 2 分析和設計；
? 3 實現和執行；
? 4 評估出口準則和測試報告；
? 5 測試結束活動。
雖然上面這些活動在邏輯上是有連續的，但在整個測試過程中它們可能會重疊或同時進行。
1.4.1 測試計劃和控制階段
測試計劃的主要活動是：識別測試的任務、定義測試的目的；以及為實現測試目的而決定測試作業的式樣。
測試控制是持續進行的活動：通過對測試進展和測試計劃之間的比較，報告測試的狀態，包括與計劃之間存在的偏差。測試控制包括在必要的時候采取必要的措施來滿足測試的任務和目標。需要在項目的整個生命周期中對測試活動進行監控，以達到控制測試過程的目的。同時，測試計劃的制定也需要借鑒以前項目測試監控活動的經驗和有用信息。
測試計劃階段主要任務：
? 確定測試的范圍和風險，識別測試的目的；
? 確定測試方法:測試技術、測試項(test item)、測試覆蓋(test coverage)、識別和聯系相關的測試團隊和測試件；
? 確定測試需要的資源:人員、測試環境(test )和計算機等；
? 貫徹測試方針和策略；
? 計劃測試分析和測試設計任務的時間進度；
? 計劃測試作成、執行和驗證的時間進度；
? 確定測試的結束（出口）準則。
測試控制階段主要任務：
? 測量和分析結果；
? 監控和記錄測試進展、測試覆蓋和測試出口準則的文檔化；
? 修改軟件的缺陷；
? 做出決定。
1.4.2 測試分析和設計階段
測試分析和設計是將抽象的測試目標轉化為實實在在的測試條件和測試設計的一系列活動。
測試分析和設計階段的主要任務：
1. 評審測試依據（比如需求、系統架構、設計和接口說明等）。
2. 識別測試條件或測試需求(test )，根據測試項、詳細規格說明、系統行為和結構分析得到必要的測試條件和數據。
3. 設計測試用例。
4. 評估系統和需求的可測試性()。
5. 規劃測試環境的搭建和確定測試需要的基礎設施（）和工具。
1.4.3 測試實現和執行階段
測試實現和執行是將測試條件轉化為測試用例、測試件的一系列活動，并進行測試環境的搭建。
測試實現和執行階段的主要任務：
1. 測試用例的開發和確定它們的優先級，創建測試數據，描述測試的具體步驟，同時也可以準備測試用具(test harnesses)和設計測試腳本(test script)。
2. 根據測試用例建立測試套件(test suite)，以提高測試執行的效率。
3. 確認已經正確搭建了的測試環境。
4. 根據計劃的執行順序，通過手工或使用測試執行工具(test execution tool)來執行測試用例。
5. 記錄測試執行的結果，以及被測軟件的標識和版本、使用的測試工具和測試件。
6. 將實際結果和預期結果進行比較。
7. 對實際結果和預期結果之間的差異，作為缺陷上報，并且分析這些缺陷以確定引起缺陷的原因（代碼缺陷、具體測試數據缺陷、測試文檔缺陷、或測試執行的方法有錯誤等）。
8. 缺陷修正后，重新進行測試活動。比如通過再次執行在上個版本中失敗的用例來確認缺陷是否已經被修正（確認測試）。執行修正后的測試用例或執行一些測試用例來確保缺陷的修正沒有在軟件中引入新的問題后或沒有引起其他的缺陷（回歸測試）。
テストベース、テストスイート、テストケース、テストプロシージャ：
1.4.4 評估出口準則和測試報告階段
評估出口準則階段是將測試的執行結果和已經定義的測試目標進行比較的活動。這個活動在各個測試級別(test level)上都需要進行。
評估測試出口準則的主要任務：
1. 將測試結果記錄與測試計劃作業中定義的終了基準相對比。
2. 判斷是否需要進行更多的測試，或是否需要更改測試的出口準則。
3. 為利益相關者提供一個測試總結報告。
Bug管理圖
1.4.5 測試結束階段
測試結束階段從完成的測試活動中收集資料來鞏固測試經驗，收集測試件、影響測試的因素和其他數據。比如什么時候軟件系統可以發布？什么時候項目測試結束或取消？什么時候達到里程碑？或者何時可以發布一個維護版本等？
測試結束階段的主要任務：
? 檢查提交了哪些計劃的交付物()、缺陷報告是否關閉、提交的變更記錄是否仍處于開放狀態、以及系統的驗收文檔狀態等等。
? 歸檔測試件(testware)、測試環境和測試基礎設備(test )，以備將來的項目使用。
? 移交測試件到維護*。
? 分析學到的經驗教訓，作為將來項目和版本的參考及用來改進測試成熟度(test maturity)。
1.5 測試的心理學
術語
獨立測試( testing)。
背景
在測試和評審中使用的思想方法，與在項目分析和開發中使用的方法不同。開發員可以測試他們自己寫的代碼，但這與測試員職責之間是存在區別的，明白這一點，測試員的獨立測試需要提供專門的工作量，并且具有以下優點：通過專業的培訓和利用專業的測試資源，實現獨立的測試；獨立測試可以應用于任何測試級別。
一定程度的獨立測試（可以避免開發人員對自己代碼的偏愛），可以更加高效的發現軟件缺陷和軟件存在的失效。但獨立測試不是完全的替代物，因為開發人員也可以高效的在他們的代碼中找出很多缺陷。可以定義不同級別的獨立測試：
? 測試用例由軟件本身編寫的人員來設計（低級別的獨立測試）。
? 測試用例由開發小組中的其他成員來設計。
? 測試用例由組織內的其他小組成員來設計（獨立的測試小組）。
? 測試用例由來自其他組織或其他公司的成員來設計（測試外包）。
測試的目標驅使著小組成員和項目的活動。小組成員將根據管理層或其他利益相關者設定的目標對他們的計劃進行調整，比如需要發現更多的缺陷，或確認軟件是否可以正常工作。因此，對測試的目標進行清晰的設定是非常重要的。
測試過程中發現的失效，可能會被看成是測試員對產品的責難或對產品開發者的不恭。因此，測試通常被認為是破壞性的活動，即使它對于管理產品風險是非常有建設性作用的。在系統中發現失效需要測試員具有一顆好奇的心、專業的懷疑態度、一雙挑剔的眼睛、探究根底的精神、與開發人員良好的溝通能力以及對常見的錯誤進行判斷的經驗。
假如可以用建設性的態度對發現的缺陷或失效進行溝通，就可以避免測試員、分析人員和開發設計者之間的不愉快。這個道理同樣適用于文檔的評審過程。
在以建設性的方式討論缺陷、進度和風險時，測試員和測試的負責人都需要具有良好的人與人之間溝通的能力。通過良好的溝通，要讓軟件代碼或文檔的作者明白，發現缺陷的信息可以幫助他們來提高他們的技術水平。在測試階段發現和修復缺陷可以在項目后期節省時間和金錢，而且可以減少項目的風險。
溝通方面的問題經常會發生，特別是當測試員只是作為不受歡迎的缺陷消息的傳遞者的時候。然而可以使用下面的一些建議和方法來改善測試員和其他小組成員之間的溝通和相互關系：以合作而不是爭斗的方式開始項目，時時提醒項目的每位成員：共同目標是追求高質量的產品。
?對產品中發現的問題以中性的和以事實為依據的方式來溝通，而不要嘲笑引入這個問題的小組成員或個兒。比如，客觀而實際的描寫缺陷報告和評審(review)發現的問題。
?盡量理解其他成員的感受，以及他們為什么會有這種反應。
確信其他成員已經理解你的描述，反之亦然。
軟件的易用性測試原則和方法有什么？
軟件測試的目的;在規定的條件下對程序進行操作，以發現程序錯誤，衡量軟件質量，并對其是否能滿足設計要求進行評估。
準則：對計算機軟件進行測試前，首先需遵循軟件測試原則，即不完全原則的遵守。不完全原則即為若測試不完全、測試過程中涉及免疫性原則的部分較多，可對軟件測試起到一定幫助。
因軟件測試因此類因素具有一定程度的免疫性，測試人員能夠完成的測試內容與其免疫性成正比，若想使軟件測試更為流暢、測試效果更為有效，首先需遵循此類原則，將此類原則貫穿整個開發流程，不斷進行測試，而并非一次性全程測試。
測試方法：
1、靜態測試方法
軟件代碼的靜態分析測驗，此類過程中應用數據較少，主要過程為通過軟件的靜態性測試（即人工推斷或計算機輔助測試）測試程序中運算方式、算法的正確性，進而完成測試過程，此類測試的優點在于能夠消耗較短時間、較少資源完成對軟件、軟件代碼的測試，能夠較為明顯地發現此類代碼中出現的錯誤。
2、動態測試
計算機動態測試的主要目的為檢測軟件運行中出現的問題，較靜態測試方式相比，其被稱為動態的原因即為其測試方式主要依賴程序的運用，主要為檢測軟件中動態行為是否缺失、軟件運行效果是否良好。
3、黑盒測試
通過數據輸入觀察數據輸出，檢查軟件內部功能是否正常。測試展開時，數據輸入軟件中，等待數據輸出。數據輸出時若與預計數據一致，則證明該軟件通過測試，若數據與預計數據有出入，即便出入較小亦證明軟件程序內部出現問題，需盡快解決。
4、白盒測試
白盒測試相對于黑盒測試而言具有一定透明性，原理為根據軟件內部應用、源代碼等對產品內部工作過程進行調試。測試過程中常將其與軟件內部結構協同展開分析，*優點即為其能夠有效解決軟件內部應用程序出現的問題，測試過程中常將其與黑盒測試方式結合，當測試軟件功能較多時，白盒測試法亦可對此類情況展開有效調試。
擴展資料
軟件測試工具
開源測試管理工具：Bugfree、Bugzilla、TestLink、mantis zentaopms。
開源功能自動化測試工具：Watir、Selenium [1] 、MaxQ、WebInject。
開源性能自動化測試工具：Jmeter、OpenSTA、DBMonster、TPTEST、Web Load Simulator。
其他測試工具與框架：Rational Tester、Borland Silk系列工具、WinRunner、Robot等。
禪道測試管理工具：功能比較全面的測試管理工具，功能涵蓋軟件研發的全部生命周期，為軟件測試和產品研發提供一體化的解決方案。是一款優秀的國產開源測試管理工具。
Quality Center：基于Web的測試管理工具，可以組織和管理應用程序測試流程的所有階段，包括指定測試需求、計劃測試、執行測試和跟蹤缺陷。
QuickTest ：用于創建功能和回歸測試。
：預測系統行為和性能的負載測試工具。
國內免費軟件測試工具有：和。
參考資料來源：百度百科-軟件測試技術
參考資料來源：百度百科-軟件測試
