南京靜態(tài)測試能夠軟件的質(zhì)量

軟件測試是干什么的

軟件測試是在軟件開發(fā)過程中對軟件產(chǎn)品進行評估、檢測和驗證的過程。主要目的是為了發(fā)現(xiàn)軟件中的缺陷、錯誤和問題，確保軟件符合規(guī)格說明書和用戶需求，并確保軟件的質(zhì)量和可靠性。

軟件測試的主要任務包括：

驗證軟件的正確性：通過對軟件進行各種測試，確保軟件能夠按照規(guī)格說明書和用戶需求的要求正確地工作。

發(fā)現(xiàn)軟件中的缺陷和錯誤：通過模擬各種使用場景，發(fā)現(xiàn)軟件中的缺陷和錯誤，并及時進行修復和調(diào)整。

評估軟件的質(zhì)量和可靠性：通過軟件測試，評估軟件的質(zhì)量和可靠性，確保軟件達到預期的質(zhì)量和性能要求。

確保軟件的安全性：通過對軟件的安全性進行測試，確保軟件能夠抵御各種攻擊和威脅。

軟件測試通常包括靜態(tài)測試和動態(tài)測試兩個方面。靜態(tài)測試主要是對軟件的文檔、代碼和設計進行檢查和審查，以確保軟件的正確性和一致性；動態(tài)測試主要是通過對軟件進行各種測試，驗證軟件的正確性和性能。

想要系統(tǒng)學習，你可以考察對比一下開設有相關專業(yè)的熱門學校免費獲取資料好的學校擁有根據(jù)當下企業(yè)需求自主研發(fā)課程的能力，能夠在校期間取得大?；虮究茖W歷，中博軟件、南京課工場、南京北大青鳥等開設相關專業(yè)的學校都是不錯的，建議實地考察對比一下。

祝你學有所成，望采納。

北大青鳥學生課堂實錄

靜態(tài)測試的質(zhì)量度量

有了嚴格的編程規(guī)范，只能算是萬里長征邁出了*步。要提高軟件的可重用性，以及軟件的可維護性，還需要進一步的努力，即靜態(tài)質(zhì)量度量。靜態(tài)質(zhì)量度量所依據(jù)的標準是ISO9126。在該標準中，軟件的質(zhì)量用以下幾個方面來衡量，即功能性()、可靠性()、可用性(Usability)、有效性()、可維護性（）、可移植性()。以ISO9126質(zhì)量模型為基礎，可以構(gòu)造質(zhì)量度量模型。具體到靜態(tài)測試，這里主要關注的是可維護性。要衡量軟件的可維護性，可以從四個方面去度量，即可分析性（）、可改變性（）、穩(wěn)定性（Stability）以及可測試性（）。具體到軟件的可測試性怎么去衡量。又可以從三個度量元去考慮，例如圈復雜度、輸入/輸出的個數(shù)等。圈復雜度越大，說明代碼中的路徑越多；路徑越多，意味著要去做測試，需要寫更多的測試用例。輸入/輸出的個數(shù)同樣的道理。在具體的實踐中，專門的質(zhì)量度量工具是必要的。沒有工具的支持，這一步很難只靠人工完成。在這個階段，比較專業(yè)的工具有Testbed、Logiscope等。

軟件工程 靜態(tài)測試的主要方法有哪些

（1）人工檢測：是指不依靠計算機而是靠人工審查程序或評審軟件，包括代碼檢查、靜態(tài)結(jié)構(gòu)分析和代碼質(zhì)量度量等；

（2）計算機輔助靜態(tài)分析：利用靜態(tài)分析工具對被測試程序進行特性分析，從程序中提取一些信息，以便檢查程序邏輯的各種缺陷和可疑的程序構(gòu)造。

靜態(tài)測試包括代碼檢查、靜態(tài)結(jié)構(gòu)分析、代碼質(zhì)量度量等。它可以由人工進行，充分發(fā)揮人的邏輯思維優(yōu)勢，也可以借助軟件工具自動進行。

擴展資料：

代碼檢查包括代碼走查、桌面檢查、代碼審查等，主要檢查代碼和設計的一致性，代碼對標準的遵循、可讀性，代碼的邏輯表達的正確性，代碼結(jié)構(gòu)的合理性等方面；可以發(fā)現(xiàn)違背程序編寫標準的問題，程序中不安全、不明確和模糊的部分，找出程序中不可移植部分、違背程序編程風格的問題，包括變量檢查、命名和類型審查、程序邏輯審查、程序語法檢查和程序結(jié)構(gòu)檢查等內(nèi)容。

在實際使用中，代碼檢查比動態(tài)測試更有效率，能快速找到缺陷，發(fā)現(xiàn)30%～70%的邏輯設計和編碼缺陷；代碼檢查看到的是問題本身而非征兆。但是代碼檢查非常耗費時間，而且代碼檢查需要知識和經(jīng)驗的積累。

代碼檢查應在編譯和動態(tài)測試之前進行，在檢查前，應準備好需求描述文檔、程序設計文檔、程序的源代碼清單、代碼編碼標準和代碼缺陷檢查表等。靜態(tài)測試具有的發(fā)現(xiàn)缺陷早、降低返工成本、覆蓋重點和發(fā)現(xiàn)缺陷的概率高的優(yōu)點以及耗時長、不能測試依賴和技術能力要求高的缺點。

簡述"軟件測試能保證軟件質(zhì)量"是否正確

軟件測試是可以保證軟件質(zhì)量，但不是說你測試一下就可以保證質(zhì)量的。

你需要去了解如何去保證軟件質(zhì)量，你可以看下下面的

　

軟件在沒有發(fā)布之前的開發(fā)過程主要分為需求分析、設計、編碼和驗證四個階段，最終的軟件質(zhì)量與這四個階段的各自質(zhì)量之間的關系如果用C語言來表達的話應當是： 最終的軟件質(zhì)量 = 需求分析質(zhì)量 && 設計質(zhì)量 && 編碼質(zhì)量 && 驗證質(zhì)量 即，最終的質(zhì)量來自于各階段質(zhì)量之“與”，只要其中一個環(huán)節(jié)質(zhì)量是差，則產(chǎn)品的整體質(zhì)量都將是差，千萬不要認為是“或”的關系。由此看來每一個階段的質(zhì)量都起著決定性的作用。 以上提及的四個階段的質(zhì)量將引出以下幾個軟件質(zhì)量保證的關鍵要素。 完備的需求分析 需求分析的目的是讓項目組明白要做什么，是決定所開發(fā)出來的軟件應當是“長什么樣的”，顯然完備的需求分析是高質(zhì)量軟件的前提。如果所開發(fā)出來的軟件與用戶所希望的并不一致，那不可能讓用戶說“這個軟件的質(zhì)量很好” 。如果方向不對，軟件開發(fā)得再“好”也沒有意義。需求分析失誤所帶來的開發(fā)成本是高昂的，這一點在《軟件工程》這類書籍中都會提及，因此，整個行業(yè)對于需求分析的重要性都具有足夠的認識。當然，知道其重要性與如何獲得完備的需求分析又是兩回事，至于如何做好需求分析請讀者參考相關書籍。 需求分析如果出現(xiàn)失誤的話有一個特點—— 它一定會暴露！只不過存在是暴露在軟件開發(fā)過程中還是在用戶手中之別。因此，需求分析所造成的問題盡管嚴重，但它能被發(fā)現(xiàn)進而能得到項目組的重視，從而也一定能被修復，只是不同階段發(fā)現(xiàn)這類問題所花費的成本將有所不同。 設計 設計階段是通過設計方法找出軟件實現(xiàn)更好的方法，注意這里是“更好”兩個字，而不是強調(diào)*。 不良設計并不會象需求分析失誤那樣很容易暴露出其本質(zhì)，相反，它所暴露出的更多是表象，比如邏輯復雜、維護時舉步為艱等等。如果參與者不具備一定的洞察力以發(fā)現(xiàn)隱藏在現(xiàn)象背后的不良設計本質(zhì)，則很有可能身受其害卻不能自拔，還以為“本來就有那么復雜”。 項目的開發(fā)是一個逐步演進的過程，項目組成員對于需求的理解也是逐步加深的，一開始合適的設計到后面看來很有可能就不夠全面或顯得力不從心，如果仍沿用以前的設計則自然將暴露出它的不足，進而會出現(xiàn)需要更高的維護成本。重構(gòu)思想的提出，就是用于幫助項目演進設計的，當然，在運用重構(gòu)方法時，應盡可能保證項目有足夠的單元測試用例，以預防重構(gòu)時又引入新的缺陷。重構(gòu)不只是一個詞，其核心應當是一個方法論，一個用于優(yōu)化設計的方法論。 編程好習慣 設計階段輸出的結(jié)果就是藍圖，但好的藍圖并不能保證*的質(zhì)量一定就好。拿造房子打個比方，圖紙設計得再好，如果建造時用的材料不過關，那最終的房子一定好不了。那軟件開發(fā)中的“建筑材料”又是什么呢？就是程序員所編寫的代碼。如何保證其質(zhì)量呢？這需要通過良好的編程習慣去保證。 在現(xiàn)實的項目中，設計有可能與編碼會有一定的揉合，即通過進行一定的編碼來輔助設計。這種實踐方式并不影響這里將設計與編碼分為兩個質(zhì)量保證關鍵要素。 驗證 驗證很容易讓人想到質(zhì)量保證的常用方法之一，即測試。但驗證應當包含更多的內(nèi)涵，比如求證軟件需求是用戶所希望的就是其中的一種。 對于驗證的理解仍需要拿房屋的建造作為一個比方，以便加深理解。在房屋的建造過程中，當建筑材料到了工地以后，需要對其進行檢驗，以保證它的質(zhì)量是合格的，否則不能用于建造。對應于軟件開發(fā)，這個階段就是單元測試。當軟件工程師編寫了代碼以后如何保證代碼的行為是其所希望的呢？那只能通過單元測試去驗證。房子建造好了以后，還得對房子進行整體的驗收以確保其最終是合格的。比如抽查墻壁所使用的水泥與沙的配比是合適的。雖然水泥和沙在進入工地時都經(jīng)過了質(zhì)檢且是合格的，但在建造的過程中需要按一定的比例混合它們以作建筑粘合劑，而混合比例將確定粘合強度。在軟件開發(fā)過程中，軟件集成測試就如同房子在建造好了以后的驗收。 從上面的比方能得出幾個結(jié)論。*，在軟件開發(fā)過程中單元測試是必不可少的。它的缺少如同將沒有檢驗過的建筑材料用于建造一樣。第二，單元測試應當在集成測試之前完成。有的項目在一開始時并沒有單元測試流程，但后來發(fā)現(xiàn)需要增加這個環(huán)節(jié)，于是出現(xiàn)了集成測試完成了以后，再進行單元測試這種情形。這種情形還是有點怪怪的，這如同房子已造好了，再將墻打掉去檢查里面的磚是否是好的一樣。“將墻打掉檢查磚”這種行為的勇氣雖然可佳，但是如果盡早地在項目中部署單元測試就能避免這種怪現(xiàn)象的發(fā)生。 集成（包括開發(fā)集成和系統(tǒng)集成）測試在軟件行業(yè)被廣泛采用以保證軟件質(zhì)量，但單元測試對于軟件質(zhì)量保證的重要性在整個行業(yè)還缺乏廣泛的、深刻的認識，其更多地被當作是負擔而不是一種有效的質(zhì)量保證手段。

什么是軟件的靜態(tài)測試和動態(tài)測試，他們的區(qū)別？

靜態(tài)方法是指不運行被測程序本身，僅通過分析或檢查源程序的語法、結(jié)構(gòu)、過程、接口等來檢查程序的正確性。

對需求規(guī)格說明書、軟件設計說明書、源程序做結(jié)構(gòu)分析、流程圖分析、符號執(zhí)行來找錯。

動態(tài)測試方法是指通過運行被測程序，檢查運行結(jié)果與預期結(jié)果的差異，并分析運行效率、正確性和健壯性等性能。

靜態(tài)測試和動態(tài)測試主要有測試部分，測試方法，測試方式三個方面的區(qū)別。

1、測試部分的不同

靜態(tài)測試是指測試不運行的部分：只是檢查和審閱,如規(guī)范測試、軟件模型測試、文檔測試等。

動態(tài)測試是通常意義上的測試，也就是運行和使用軟件。

2、測試方式不同

靜態(tài)測試，通過評審文檔、閱讀代碼等方式測試軟件稱為靜態(tài)測試，通過運行程序測試軟件稱為動態(tài)測試。

3、測試方法不同

靜態(tài)測試是指不用執(zhí)行程序的測試，它主要采取方案—代碼走查、技術評審、代碼審查的方法對軟件產(chǎn)品進行測試。

動態(tài)測試主要通過構(gòu)造測試實例、執(zhí)行程序、分析程序的輸出結(jié)果這三種方法來對軟件進行測試。

擴展資料：

靜態(tài)測試的測試要點：

1、挑選合適的復審員

復審活動人數(shù)控制在3-7個人，每次復審活動不要超過2小時，否則應該功能分解或者形式分解。準備充分的復審一小時以內(nèi)完成。

2、管理*的參與

為復審活動分配時間和資源，特殊情況關于時間、場地選取的一些建議。IBM一個關于電話會議進行復審的一個案例。

3、注意事項

結(jié)隊復審方法，對比結(jié)隊編程。選擇那些不會引起爭論不休的內(nèi)容作為每次初期復審對象。

對走查、審查和技術復審的活動指南進行復審，效果會很好。

4、技術復審與項目管理

確定兩次復審之間的時間間隔的根據(jù)使你在完全失去對工作狀況的了解的情況下能夠堅持的最長時間。

不管做什么都會犯錯誤，因此把錯誤犯在最安全的地方是一個不錯的策略，這也是復審活動“寧缺勿濫”的理由。

5、復審領導

復審領導的工作是保證復審活動獲得成功-或者是負責匯報復審活動未能獲得成功的原因。

未能成功原因比如：成員在材料充分的情況下依然沒有做好準備、預定的會議室發(fā)現(xiàn)泥水匠正在拆墻。

對于復審領導的個人品質(zhì)很難一概而論，一句話：結(jié)果比方式更重要。畢竟領導風格千千種，很難說那種是對是錯。

任何可能因為職位的原因引起利益沖突的人都不應該出現(xiàn)在復審現(xiàn)場，所以，領導對自己的團隊進行復審應該盡力避免。

如果復審偏離主題，復審領導首先要做的是，留心觀察這次跑題是否是某些成員掩蓋其缺乏準備的一個詭計。

6、規(guī)則和慣例

準備好你的工作，時刻注意自己評審的是產(chǎn)品而不是同事，任何人都可能犯錯。

注意你的語言，面和負面的評價，實在沒有正面的評價可以“我喜歡你用來評審的水筆的顏色?！碧岢鰡栴}，但不要解決問題。

7、規(guī)則

要表現(xiàn)出對復審過程的信任，要為復審過程安排時間，要做好準備讓真正合適的人去參加復審，鼓勵復審活動的參與者做好準備工作。

參考資料來源：百度百科-靜態(tài)測試

參考資料來源：百度百科-動態(tài)測試

軟件測試主要學什么，在南京有沒有？

軟件測試的分類
從是否關心軟件內(nèi)部結(jié)構(gòu)和具體實現(xiàn)的角度劃分
A.白盒測試
B.黑盒測試
C.灰盒測試

從是否執(zhí)行程序的角度
A.靜態(tài)測試
B.動態(tài)測試。

從軟件開發(fā)的過程按階段劃分有
A.單元測試
B.集成測試
C.確認測試
D.系統(tǒng)測試
E.驗收測試
* 測試過程按4個步驟進行，即單元測試、集成測試、確認測試和系統(tǒng)測試及發(fā)版測試。
* 開始是單元測試，集中對用源代碼實現(xiàn)的每一個程序單元進行測試，檢查各個程序模塊是否正確地實現(xiàn)了規(guī)定的功能。
* 集成測試把已測試過的模塊組裝起來，主要對與設計相關的軟件體系結(jié)構(gòu)的構(gòu)造進行測試。
* 確認測試則是要檢查已實現(xiàn)的軟件是否滿足了需求規(guī)格說明中確定了的各種需求，以及軟件配置是否完全、正確。
* 系統(tǒng)測試把已經(jīng)經(jīng)過確認的軟件納入實際運行環(huán)境中，與其它系統(tǒng)成份組合在一起進行測試。
單元測試 (Unit Testing)
* 單元測試又稱模塊測試，是針對軟件設計的最小單位 — 程序模塊，進行正確性檢驗的測試工作。其目的在于發(fā)現(xiàn)各模塊內(nèi)部可能存在的各種差錯。
* 單元測試需要從程序的內(nèi)部結(jié)構(gòu)出發(fā)設計測試用例。多個模塊可以平行地獨立進行單元測試。
1. 單元測試的內(nèi)容
* 在單元測試時，測試者需要依據(jù)詳細設計說明書和源程序清單，了解該模塊的I/O條件和模塊的邏輯結(jié)構(gòu)，主要采用白盒測試的測試用例，輔之以黑盒測試的測試用例，使之對任何合理的輸入和不合理的輸入，都能鑒別和響應。
(1) 模塊接口測試
* 在單元測試的開始，應對通過被測模塊的數(shù)據(jù)流進行測試。測試項目包括：
– 調(diào)用本模塊的輸入?yún)?shù)是否正確；
– 本模塊調(diào)用子模塊時輸入給子模塊的參數(shù)是否正確；
– 全局量的定義在各模塊中是否一致；
* 在做內(nèi)外存交換時要考慮：
– 文件屬性是否正確；
– OPEN與CLOSE語句是否正確；
– 緩沖區(qū)容量與記錄長度是否匹配；
– 在進行讀寫操作之前是否打開了文件；
– 在結(jié)束文件處理時是否關閉了文件；
– 正文書寫／輸入錯誤，
– I／O錯誤是否檢查并做了處理。
(2) 局部數(shù)據(jù)結(jié)構(gòu)測試
* 不正確或不一致的數(shù)據(jù)類型說明
* 使用尚未賦值或尚未初始化的變量
* 錯誤的初始值或錯誤的缺省值
* 變量名拼寫錯或書寫錯
* 不一致的數(shù)據(jù)類型
* 全局數(shù)據(jù)對模塊的影響
(3) 路徑測試
* 選擇適當?shù)臏y試用例，對模塊中重要的執(zhí)行路徑進行測試。
* 應當設計測試用例查找由于錯誤的計算、不正確的比較或不正常的控制流而導致的錯誤。
* 對基本執(zhí)行路徑和循環(huán)進行測試可以發(fā)現(xiàn)大量的路徑錯誤。
(4) 錯誤處理測試
* 出錯的描述是否難以理解
* 出錯的描述是否能夠?qū)﹀e誤定位
* 顯示的錯誤與實際的錯誤是否相符
* 對錯誤條件的處理正確與否
* 在對錯誤進行處理之前，錯誤條件是否已經(jīng)引起系統(tǒng)的干預等
(5) 邊界測試
* 注意數(shù)據(jù)流、控制流中剛好等于、大于或小于確定的比較值時出錯的可能性。對這些地方要仔細地選擇測試用例，認真加以測試。
* 如果對模塊運行時間有要求的話，還要專門進行關鍵路徑測試，以確定最壞情況下和平均意義下影響模塊運行時間的因素。
2. 單元測試的步驟
* 模塊并不是一個獨立的程序，在考慮測試模塊時，同時要考慮它和外界的聯(lián)系，用一些輔助模塊去模擬與被測模塊相聯(lián)系的其它模塊。
– 驅(qū)動模塊 (driver)
– 樁模塊 (stub) —— 存根模塊
* 如果一個模塊要完成多種功能，可以將這個模塊看成由幾個小程序組成。必須對其中的每個小程序先進行單元測試要做的工作，對關鍵模塊還要做性能測試。
* 對支持某些標準規(guī)程的程序，更要著手進行互聯(lián)測試。有人把這種情況特別稱為模塊測試，以區(qū)別單元測試。
集成測試（ Testing）
* 集成測試 (集成測試、聯(lián)合測試）
* 通常，在單元測試的基礎上，需要將所有模塊按照設計要求組裝成為系統(tǒng)。這時需要考慮的問題是：
– 在把各個模塊連接起來的時候，穿越模塊接口的數(shù)據(jù)是否會丟失；
– 一個模塊的功能是否會對另一個模塊的功能產(chǎn)生不利的影響；
– 各個子功能組合起來，能否達到預期要求的父功能；
– 全局數(shù)據(jù)結(jié)構(gòu)是否有問題；
– 單個模塊的誤差累積起來，是否會放大，從而達到不能接受的程度。
在單元測試的同時可進行集成測試，
發(fā)現(xiàn)并排除在模塊連接中可能出現(xiàn)
的問題，最終構(gòu)成要求的軟件系統(tǒng)。
* 子系統(tǒng)的集成測試特別稱為部件測試，它所做的工作是要找出集成后的子系統(tǒng)與系統(tǒng)需求規(guī)格說明之間的不一致。
* 通常，把模塊集成成為系統(tǒng)的方式有兩種
– 一次性集成方式
– 增殖式集成方式
1. 一次性集成方式(big bang)
* 它是一種非增殖式組裝方式。也叫做整體拼裝。
* 使用這種方式，首先對每個模塊分別進行模塊測試，然后再把所有模塊組裝在一起進行測試，最終得到要求的軟件系統(tǒng)。
2. 增殖式集成方式
* 這種集成方式又稱漸增式集成
* 首先對一個個模塊進行模塊測試，然后將這些模塊逐步組裝成較大的系統(tǒng)
* 在集成的過程中邊連接邊測試，以發(fā)現(xiàn)連接過程中產(chǎn)生的問題
* 通過增殖逐步組裝成為要求的軟件系統(tǒng)。
(1) 自頂向下的增殖方式
* 這種集成方式將模塊按系統(tǒng)程序結(jié)構(gòu)，沿控制層次自頂向下進行組裝。
* 自頂向下的增殖方式在測試過程中較早地驗證了主要的控制和判斷點。
* 選用按深度方向組裝的方式，可以首先實現(xiàn)和驗證一個完整的軟件功能。
(2) 自底向上的增殖方式
* 這種集成的方式是從程序模塊結(jié)構(gòu)的*層的模塊開始集成和測試。
* 因為模塊是自底向上進行組裝，對于一個給定層次的模塊，它的子模塊（包括子模塊的所有下屬模塊）已經(jīng)組裝并測試完成，所以不再需要樁模塊。在模塊的測試過程中需要從子模塊得到的信息可以直接運行子模塊得到。
* 自頂向下增殖的方式和自底向上增殖的方式各有優(yōu)缺點。
* 一般來講，一種方式的優(yōu)點是另一種方式的缺點。
(3) 混合增殖式測試
* 衍變的自頂向下的增殖測試
– 首先對輸入／輸出模塊和引入新算法模塊進行測試;
– 再自底向上組裝成為功能相當完整且相對獨立的子系統(tǒng);
– 然后由主模塊開始自頂向下進行增殖測試。
* 自底向上-自頂向下的增殖測試
– 首先對含讀操作的子系統(tǒng)自底向上直至根結(jié)點模塊進行組裝和測試;
– 然后對含寫操作的子系統(tǒng)做自頂向下的組裝與測試。
* 回歸測試
– 這種方式采取自頂向下的方式測試被修改的模塊及其子模塊;
– 然后將這一部分視為子系統(tǒng)，再自底向上測試。
關鍵模塊問題
* 在組裝測試時，應當確定關鍵模塊，對這些關鍵模塊及早進行測試。
* 關鍵模塊的特征：
① 滿足某些軟件需求；
② 在程序的模塊結(jié)構(gòu)中位于較高的層次（高層控制模塊）；
③ 較復雜、較易發(fā)生錯誤；
④ 有明確定義的性能要求。
確認測試（ Testing）
* 確認測試又稱有效性測試。任務是驗證軟件的功能和性能及其它特性是否與用戶的要求一致。
* 對軟件的功能和性能要求在軟件需求規(guī)格說明書中已經(jīng)明確規(guī)定。它包含的信息就是軟件確認測試的基礎。
1. 進行有效性測試（黑盒測試）
* 有效性測試是在模擬的環(huán)境 (可能就是開發(fā)的環(huán)境) 下，運用黑盒測試的方法，驗證被測軟件是否滿足需求規(guī)格說明書列出的需求。
* 首先制定測試計劃，規(guī)定要做測試的種類。還需要制定一組測試步驟，描述具體的測試用例。
* 通過實施預定的測試計劃和測試步驟，確定
– 軟件的特性是否與需求相符；
– 所有的文檔都是正確且便于使用；
– 同時，對其它軟件需求，例如可移植性、兼容性、出錯自動恢復、可維護性等，也都要進行測試
* 在全部軟件測試的測試用例運行完后，所有的測試結(jié)果可以分為兩類：
– 測試結(jié)果與預期的結(jié)果相符。這說明軟件的這部分功能或性能特征與需求規(guī)格說明書相符合，從而這部分程序被接受。
– 測試結(jié)果與預期的結(jié)果不符。這說明軟件的這部分功能或性能特征與需求規(guī)格說明不一致，因此要為它提交一份問題報告。
2. 軟件配置復查
n 軟件配置復查的目的是保證
u 軟件配置的所有成分都齊全；
u 各方面的質(zhì)量都符合要求；
u 具有維護階段所必需的細節(jié)；
u 而且已經(jīng)編排好分類的目錄。
n 應當嚴格遵守用戶手冊和操作手冊中規(guī)定的使用步驟，以便檢查這些文檔資料的完整性和正確性。
驗收測試（ Testing）
* 在通過了系統(tǒng)的有效性測試及軟件配置審查之后，就應開始系統(tǒng)的驗收測試。
* 驗收測試是以用戶為主的測試。軟件開發(fā)人員和QA（質(zhì)量保證）人員也應參加。
* 由用戶參加設計測試用例，使用生產(chǎn)中的實際數(shù)據(jù)進行測試。
* 在測試過程中，除了考慮軟件的功能和性能外，還應對軟件的可移植性、兼容性、可維護性、錯誤的恢復功能等進行確認。
* 確認測試應交付的文檔有：
– 確認測試分析報告
– 最終的用戶手冊和操作手冊
– 項目開發(fā)總結(jié)報告。
系統(tǒng)測試（System Testing）
* 系統(tǒng)測試，是將通過確認測試的軟件，作為整個基于計算機系統(tǒng)的一個元素，與計算機硬件、外設、某些支持軟件、數(shù)據(jù)和人員等其它系統(tǒng)元素結(jié)合在一起，在實際運行環(huán)境下，對計算機系統(tǒng)進行一系列的組裝測試和確認測試。
* 系統(tǒng)測試的目的在于通過與系統(tǒng)的需求定義作比較, 發(fā)現(xiàn)軟件與系統(tǒng)的定義不符合或與之矛盾的地方。

測試能證明軟件沒有任何缺陷么

原則1——測試顯示缺陷的存在，但不能證明系統(tǒng)不存在缺陷。測試可以減少軟件中存在未被發(fā)現(xiàn)缺陷的可能性，但即使測試沒有發(fā)現(xiàn)任何缺陷，也不能證明軟件或系統(tǒng)是完全正確的。
2）原則2——窮盡測試是不可能的。由于有太多的輸入組合、有太多的路徑，而且時間是有限的，無法做到完全的測試（*測試覆蓋率）。通過運用風險分析和不同系統(tǒng)功能的測試優(yōu)先級，來確定測試的關注點，從而替代窮盡測試。
3）原則3——測試盡早介入。軟件項目一啟動，軟件測試就應開始，也就是從項目啟動的*天開始，測試人員就應參與項目的各種活動和開展對應的測試活動。測試工作進行得越早，軟件開發(fā)的劣質(zhì)成本就越低，并能更好地保證軟件質(zhì)量。例如，在代碼完成之前，可以進行各種靜態(tài)測試，主導或積極參與需求文檔、產(chǎn)品規(guī)格說明書等的評審，將問題消滅在萌芽階段。
4）原則4——缺陷集群性。版本發(fā)布前進行測試所發(fā)現(xiàn)的大部分缺陷和軟件運行失效是由于少數(shù)軟件模塊引起的。一段程序中發(fā)現(xiàn)的錯誤數(shù)越多，意味著這段程序的質(zhì)量越不好。錯誤集中發(fā)生的現(xiàn)象，可能和程序員的編程水平、經(jīng)驗和習慣有很大的關系，也可能是程序員在寫代碼時情緒不夠好或不在狀態(tài)等。如果在同樣的測試效率和測試能力的條件下，缺陷發(fā)現(xiàn)得越多，漏掉的缺陷就越多。這也就是著名的Myers 反直覺原則：在測試中發(fā)現(xiàn)缺陷多的地方，會有更多的缺陷沒被發(fā)現(xiàn)。假定測試能力不變，通過測試會發(fā)現(xiàn)產(chǎn)品中90％的缺陷。如果在模塊A 發(fā)現(xiàn)了180 個缺陷，在模塊B 發(fā)現(xiàn)了45 個缺陷，意味著模塊A 還有20 個缺陷沒被發(fā)現(xiàn)，而模塊B 只有5個缺陷未被發(fā)現(xiàn)。所以，對發(fā)現(xiàn)錯誤較多的程序段，應進行更深入的測試。

如何看待軟件測試在保證產(chǎn)品質(zhì)量中所起的作用？

1. 軟件測試基礎（P1-3）
測試基礎知識的學習目標
本章的學習目標：完成下面模塊(module)的學習后，將明確能做什么。
1.1測試的必要性
? 通過具體的例子，來描述軟件中的缺陷(defect)會以什么樣的方式損害個人、損害環(huán)境或者損害公司利益。
? 區(qū)分引起缺陷的根本原因及其影響之間的區(qū)別。
? 通過舉例的方式說明為什么需要測試。
? 描述為什么測試是質(zhì)量保證(quality assurance)的一部分，通過舉例說明測試是如何來提高軟件質(zhì)量的。
? 理解術語錯誤(mistake)、缺陷、失效(failure)以及相應的術語錯誤(error)和bug之間的區(qū)別。
1.2 什么是測試 (K2)
? 認識測試的共同目標。
? 描述測試作為發(fā)現(xiàn)缺陷的一種手段，測試在軟件開發(fā)、維護和運行中的目的，同時通過測試，可以增強對被測軟件的信心并獲得一些相關的信息，從而用來預防缺陷。
1.3 測試的基本原則
? 說明測試的基本原則。
1.4 基本的測試過程
再次認識從計劃到測試結(jié)束過程中測試的基本活動，以及在每個活動中的主要任務（K1）。
1.5 測試的心理學
? 認識測試的成功與否，會受測試心理因素的影響：
? 清楚的目標；
? 自己測試和獨立測試之間的平衡；
? 認識到謙恭的溝通和缺陷反饋在測試中的作用。
? 對比測試員(tester)和開發(fā)員(developer)的心理差異。
1.1 為什么需要測試 （P4-5）
術語
缺陷(bug)、缺陷(defect)、錯誤(error)、失效(failure)、故障（fault）、錯誤(mistake)、質(zhì)量（quality）、風險(risk)、軟件(software)、測試(testing)。
1.1.1 軟件系統(tǒng)的狀況
在當今社會，軟件系統(tǒng)(system)越來越成為生活中不可或缺的一部分，包括從商業(yè)應用（比如銀行系統(tǒng)）到消費產(chǎn)品（比如汽車）各個領域。然而，很多人都有這樣的經(jīng)歷：軟件并沒有按照預期進行工作。軟件的不正確執(zhí)行可能會導致許多問題，包括經(jīng)濟的損失、時間的浪費和商業(yè)信譽的丟失等等，甚至導致人身傷害和死亡。
1.1.2 引起軟件缺陷的原因
所有的人都會犯錯誤。該錯誤error會成為設計的代碼、軟件、系統(tǒng)和文檔中的缺陷。當存在缺陷的代碼被執(zhí)行時，系統(tǒng)就可能無法執(zhí)行期望的指令（或者做了不應該執(zhí)行的指令），從而引起軟件失效（故障）。雖然軟件、系統(tǒng)和文檔中的缺陷可能會引起失效，但并不是所有的缺陷都會這樣。
產(chǎn)生缺陷的原因是多種多樣的：人們本身容易犯錯誤、時間的壓力、復雜的代碼、復雜的系統(tǒng)架構(gòu)、技術的革新、或者系統(tǒng)之間的配合工作等。
失效也可能是由于環(huán)境條件引起的：放射、電磁輻射和污染等都有可能引起硬件的故障，或者由于硬件條件的改變而影響軟件的執(zhí)行。
※ error（錯誤） → 缺陷（fault，bug） → 故障
1.1.3 在軟件開發(fā)、維護和運行中測試的角色
對軟件系統(tǒng)和文檔進行嚴格的測試,可以減少軟件系統(tǒng)在運行環(huán)境中的風險，假如在軟件正式發(fā)布之前發(fā)現(xiàn)和修正了缺陷，就可以提高軟件系統(tǒng)的質(zhì)量。
進行軟件測試也可能是為了滿足合同和法律法規(guī)的需求，或者是為了滿足行業(yè)標準。
1.1.4 測試和質(zhì)量
通過測試，根據(jù)發(fā)現(xiàn)的缺陷，就可能發(fā)現(xiàn)軟件系統(tǒng)在功能()和非功能(non-)需求方面的缺陷，對軟件質(zhì)量(software quality)進行評判。飛功能需求包括：可靠性()、可用性(usability）、效率()和可維護性()等方面，關于非功能測試方面的更多信息，可以參考第二章。更多關于軟件特征的信息，可以參考[ Software - Software Product Quality (ISO9126) ]?！鵌SO9126對應與國內(nèi)規(guī)格：JIS-X0129。
當測試發(fā)現(xiàn)很少或者沒有發(fā)現(xiàn)缺陷的時候，就會對軟件的質(zhì)量充滿信心。一個設計正確、合理的測試過程完成并順利通過，可以降低整個系統(tǒng)存在問題的風險。而對測試過程中發(fā)現(xiàn)的缺陷進行了修正，則軟件系統(tǒng)的質(zhì)量就會提高。
我們應該從以前的項目中總結(jié)經(jīng)驗教訓。通過分析在其他項目中發(fā)現(xiàn)的缺陷和引起缺陷的根本原因，我們就可以改進測試過程(process)。相繼地，過程的改進又可以預防相同的缺陷再次發(fā)生，從而提高以后系統(tǒng)的質(zhì)量。
測試應該作為質(zhì)量保證的各種作業(yè)中（例如：開發(fā)標準、教育、缺陷分析）的不可或缺的一部分。
1.1.5 測試是否充分
測試應該進行到哪種程度，取決于技術、產(chǎn)品、項目風險的水平，以及在時間和預算等方面項目上的限制。 （風險將在第5章進行詳細描述）
測試需要給利益相關者提供足夠的信息，幫助他們決定是否發(fā)布被測的軟件或系統(tǒng)，是否繼續(xù)進行下階段的開發(fā)或直接將產(chǎn)品交給用戶。
追求完全的品質(zhì)，從成本的角度來看沒有效果

缺陷成本：為了修正而產(chǎn)生的成本、產(chǎn)生不良結(jié)果的成本
Joseph M. Juran 1.テストの必要性（3/3
1.2 什么是測試（P7-8）
術語
代碼(code)、調(diào)試(debugging)、（軟件）開發(fā)()、需求()、評審(review)、測試依據(jù)(test basis)、測試用例(test case)、測試(testing)、測試目標(test )。
背景
在一般人的理解當中，測試活動只包含了運行測試，也就是執(zhí)行軟件。但實際上這只是測試的一部分，而不是測試的所有活動。
測試的活動包含了測試執(zhí)行之前和之后的一些活動，包括計劃(planning)和控制(control)、選擇測試條件(test condition)、設計測試用例(test case)、檢查測試結(jié)果(result)、評估完成準則( criteria)、報告測試過程(test process)及被測系統(tǒng)、測試結(jié)束或總結(jié)。測試同時也包括文檔的評審(review)（包括代碼）和靜態(tài)分析(static analysis)。
動態(tài)測試(dynamic testing)和靜態(tài)測試這兩種手段都可以達到相似的目標，即以提供信息來改進被測試軟件系統(tǒng)的質(zhì)量，以及改善開發(fā)和測試的過程。
? 測試執(zhí)行前的作業(yè)
- 計劃、測試條件、測試用例設計
? 測試執(zhí)行時的作業(yè)
- 執(zhí)行結(jié)果的Check、完了基準的驗證、測試結(jié)果報告
? 測試執(zhí)行后的作業(yè)
- 軟件的整理
? 通過整體的作業(yè)
- 項目控制、評審
※ 在下一節(jié)的《基本的測試流程》中，會將測試執(zhí)行前的作業(yè)分為計劃和設計，當作5個流程來定義。
不同的測試具有不同的測試目標：
? 發(fā)現(xiàn)缺陷；
? 獲取對產(chǎn)品質(zhì)量的信心，以及提供信息；
? 預防缺陷。
在軟件生命周期早期進行測試用例的設計，可以幫助避免將缺陷引入代碼中。同時文檔的評審（例如需求文檔）也可以預防將缺陷引入代碼。
不同的測試階段，需要考慮不同的測試目標。比如，在開發(fā)中的測試里，如單元測試(unit testing)、集成測試( testing)和系統(tǒng)測試(system testing)等，測試的主要目標是盡可能的發(fā)現(xiàn)失效，從而識別和修正盡可能多的缺陷。在驗收測試（ testing）中，測試的主要目標是用來確認系統(tǒng)是否按照預期工作，從而在系統(tǒng)是否滿足需求方面獲取信心。而在有些情況下，測試的主要目標是對軟件的質(zhì)量進行評估（不是為了修正缺陷），從而為利益相關人提供這樣的信息：在給定時間內(nèi)發(fā)布的系統(tǒng)版本所存在的風險。而保守測試 (維護測試 testing)通常是為了驗證在開發(fā)過程中的變更是否引入新的缺陷。在運行測試階段，測試的主要目標是為了評估系統(tǒng)的特征，比如可靠性或可用性等。
必須明確，調(diào)試和測試是兩個不同的概念。測試可以發(fā)現(xiàn)由于軟件存在的缺陷引起的失效。而調(diào)試是一種開發(fā)活動，用來識別引起缺陷的原因，修改代碼以及驗證是否正確的修改了軟件的缺陷。隨后由測試員進行的確認測試( testing)是為了確認修改的代碼已經(jīng)解決了失效問題。每個活動的職責是截然不同的，即測試員進行測試，開發(fā)人員進行調(diào)試。
1.3 測試的基本原則
術語
窮盡測試( testing)。
原則
在過去40年中，軟件測試界提出了很多的測試原則，并且提供了適合所有測試的一些共同的測試指南。
原則1 － 測試顯示缺陷的存在
測試可以顯示缺陷(defect)的存在，但不能證明系統(tǒng)不存在缺陷。測試可以減少軟件中存在缺陷的可能性，但即使測試沒有發(fā)現(xiàn)任何缺陷，也不能證明軟件或系統(tǒng)是完全正確的。
原則2 － 窮盡測試是不可能的
除了小型項目，進行完全（各種輸入和前提條件的組合）的測試是不現(xiàn)實的。通過運用風險管理(risk )和不同系統(tǒng)功能的測試優(yōu)先級，來確定測試的關注點，從而替代窮盡測試。
原則3 － 測試盡早介入
在軟件或系統(tǒng)開發(fā)生命周期中，測試活動應該盡可能早的介入，并且應該將關注點放在已經(jīng)定義的測試目標(test objective)上。
原則4 － 缺陷集群性
版本發(fā)布前進行的測試所發(fā)現(xiàn)的大部分缺陷和軟件運行失效是由于少數(shù)軟件模塊引起的。
原則5 － 殺蟲劑悖論
同樣的測試用例一遍一遍重復進行測試，*將不再能夠發(fā)現(xiàn)新的缺陷。為了克服這種殺蟲劑悖論，測試用例需要經(jīng)常性的評審和修改，同時需要不斷增加新的不同的測試用例來測試軟件或系統(tǒng)的不同部分，從而發(fā)現(xiàn)潛在的更多的缺陷。
原則6 － 測試活動依賴于測試內(nèi)容
針對不同的測試內(nèi)容，進行的測試活動也是不同的。比如，對關注安全的軟件進行測試，與一般的商業(yè)軟件測試的重點是不一樣的。
原則7 － 0缺陷的謬論
假如系統(tǒng)無法使用，或者系統(tǒng)不能完成客戶的需求和期望，發(fā)現(xiàn)和修改缺陷是沒有任何幫助的。
「所有的模式都是錯誤的。但是，有的模式能夠起到作用」
原則上，是將現(xiàn)實世界抽象化、故意讓很多信息欠缺。
欲將軟件開發(fā)和測試這種極富多樣性的活動，用幾個原則來進行說明，
本身就不太可能。但是，這種原則對于理解測試的重要一面，確實有著
非常重要的作用。總而言之，工具是可以使用的。
1.4 基本的測試過程
術語
確認測試( testing)、出口準則(exit criteria)、事件(incident)、回歸測試( testing)、測試依據(jù)(test basis)、測試條件(test condition)、測試覆蓋(test coverage)、測試數(shù)據(jù)(test data)、測試執(zhí)行(test execution)、測試日志(test log)、測試計劃(test plan)、測試策略(test strategy)、測試總結(jié)報告(test summary report)、測試件(testware)。
背景
測試最顯而易見的活動是測試的執(zhí)行。但是為了提高效率，在測試計劃中，同樣需要保留比較多的時間用于計劃測試活動、設計測試用例、準備測試的執(zhí)行和評估測試的狀態(tài)。
基本的測試過程主要由下面一些活動組成：
? 1 計劃和控制；
? 2 分析和設計；
? 3 實現(xiàn)和執(zhí)行；
? 4 評估出口準則和測試報告；
? 5 測試結(jié)束活動。
雖然上面這些活動在邏輯上是有連續(xù)的，但在整個測試過程中它們可能會重疊或同時進行。
1.4.1 測試計劃和控制階段
測試計劃的主要活動是：識別測試的任務、定義測試的目的；以及為實現(xiàn)測試目的而決定測試作業(yè)的式樣。
測試控制是持續(xù)進行的活動：通過對測試進展和測試計劃之間的比較，報告測試的狀態(tài)，包括與計劃之間存在的偏差。測試控制包括在必要的時候采取必要的措施來滿足測試的任務和目標。需要在項目的整個生命周期中對測試活動進行監(jiān)控，以達到控制測試過程的目的。同時，測試計劃的制定也需要借鑒以前項目測試監(jiān)控活動的經(jīng)驗和有用信息。
測試計劃階段主要任務：
? 確定測試的范圍和風險，識別測試的目的；
? 確定測試方法:測試技術、測試項(test item)、測試覆蓋(test coverage)、識別和聯(lián)系相關的測試團隊和測試件；
? 確定測試需要的資源:人員、測試環(huán)境(test )和計算機等；
? 貫徹測試方針和策略；
? 計劃測試分析和測試設計任務的時間進度；
? 計劃測試作成、執(zhí)行和驗證的時間進度；
? 確定測試的結(jié)束（出口）準則。
測試控制階段主要任務：
? 測量和分析結(jié)果；
? 監(jiān)控和記錄測試進展、測試覆蓋和測試出口準則的文檔化；
? 修改軟件的缺陷；
? 做出決定。
1.4.2 測試分析和設計階段
測試分析和設計是將抽象的測試目標轉(zhuǎn)化為實實在在的測試條件和測試設計的一系列活動。
測試分析和設計階段的主要任務：
1. 評審測試依據(jù)（比如需求、系統(tǒng)架構(gòu)、設計和接口說明等）。
2. 識別測試條件或測試需求(test )，根據(jù)測試項、詳細規(guī)格說明、系統(tǒng)行為和結(jié)構(gòu)分析得到必要的測試條件和數(shù)據(jù)。
3. 設計測試用例。
4. 評估系統(tǒng)和需求的可測試性()。
5. 規(guī)劃測試環(huán)境的搭建和確定測試需要的基礎設施（）和工具。
1.4.3 測試實現(xiàn)和執(zhí)行階段
測試實現(xiàn)和執(zhí)行是將測試條件轉(zhuǎn)化為測試用例、測試件的一系列活動，并進行測試環(huán)境的搭建。
測試實現(xiàn)和執(zhí)行階段的主要任務：
1. 測試用例的開發(fā)和確定它們的優(yōu)先級，創(chuàng)建測試數(shù)據(jù)，描述測試的具體步驟，同時也可以準備測試用具(test harnesses)和設計測試腳本(test script)。
2. 根據(jù)測試用例建立測試套件(test suite)，以提高測試執(zhí)行的效率。
3. 確認已經(jīng)正確搭建了的測試環(huán)境。
4. 根據(jù)計劃的執(zhí)行順序，通過手工或使用測試執(zhí)行工具(test execution tool)來執(zhí)行測試用例。
5. 記錄測試執(zhí)行的結(jié)果，以及被測軟件的標識和版本、使用的測試工具和測試件。
6. 將實際結(jié)果和預期結(jié)果進行比較。
7. 對實際結(jié)果和預期結(jié)果之間的差異，作為缺陷上報，并且分析這些缺陷以確定引起缺陷的原因（代碼缺陷、具體測試數(shù)據(jù)缺陷、測試文檔缺陷、或測試執(zhí)行的方法有錯誤等）。
8. 缺陷修正后，重新進行測試活動。比如通過再次執(zhí)行在上個版本中失敗的用例來確認缺陷是否已經(jīng)被修正（確認測試）。執(zhí)行修正后的測試用例或執(zhí)行一些測試用例來確保缺陷的修正沒有在軟件中引入新的問題后或沒有引起其他的缺陷（回歸測試）。
テストベース、テストスイート、テストケース、テストプロシージャ：
1.4.4 評估出口準則和測試報告階段
評估出口準則階段是將測試的執(zhí)行結(jié)果和已經(jīng)定義的測試目標進行比較的活動。這個活動在各個測試級別(test level)上都需要進行。
評估測試出口準則的主要任務：
1. 將測試結(jié)果記錄與測試計劃作業(yè)中定義的終了基準相對比。
2. 判斷是否需要進行更多的測試，或是否需要更改測試的出口準則。
3. 為利益相關者提供一個測試總結(jié)報告。

Bug管理圖
1.4.5 測試結(jié)束階段
測試結(jié)束階段從完成的測試活動中收集資料來鞏固測試經(jīng)驗，收集測試件、影響測試的因素和其他數(shù)據(jù)。比如什么時候軟件系統(tǒng)可以發(fā)布？什么時候項目測試結(jié)束或取消？什么時候達到里程碑？或者何時可以發(fā)布一個維護版本等？
測試結(jié)束階段的主要任務：
? 檢查提交了哪些計劃的交付物()、缺陷報告是否關閉、提交的變更記錄是否仍處于開放狀態(tài)、以及系統(tǒng)的驗收文檔狀態(tài)等等。
? 歸檔測試件(testware)、測試環(huán)境和測試基礎設備(test )，以備將來的項目使用。
? 移交測試件到維護*。
? 分析學到的經(jīng)驗教訓，作為將來項目和版本的參考及用來改進測試成熟度(test maturity)。
1.5 測試的心理學
術語
獨立測試( testing)。
背景
在測試和評審中使用的思想方法，與在項目分析和開發(fā)中使用的方法不同。開發(fā)員可以測試他們自己寫的代碼，但這與測試員職責之間是存在區(qū)別的，明白這一點，測試員的獨立測試需要提供專門的工作量，并且具有以下優(yōu)點：通過專業(yè)的培訓和利用專業(yè)的測試資源，實現(xiàn)獨立的測試；獨立測試可以應用于任何測試級別。
一定程度的獨立測試（可以避免開發(fā)人員對自己代碼的偏愛），可以更加高效的發(fā)現(xiàn)軟件缺陷和軟件存在的失效。但獨立測試不是完全的替代物，因為開發(fā)人員也可以高效的在他們的代碼中找出很多缺陷。可以定義不同級別的獨立測試：
? 測試用例由軟件本身編寫的人員來設計（低級別的獨立測試）。
? 測試用例由開發(fā)小組中的其他成員來設計。
? 測試用例由組織內(nèi)的其他小組成員來設計（獨立的測試小組）。
? 測試用例由來自其他組織或其他公司的成員來設計（測試外包）。
測試的目標驅(qū)使著小組成員和項目的活動。小組成員將根據(jù)管理層或其他利益相關者設定的目標對他們的計劃進行調(diào)整，比如需要發(fā)現(xiàn)更多的缺陷，或確認軟件是否可以正常工作。因此，對測試的目標進行清晰的設定是非常重要的。
測試過程中發(fā)現(xiàn)的失效，可能會被看成是測試員對產(chǎn)品的責難或?qū)Ξa(chǎn)品開發(fā)者的不恭。因此，測試通常被認為是破壞性的活動，即使它對于管理產(chǎn)品風險是非常有建設性作用的。在系統(tǒng)中發(fā)現(xiàn)失效需要測試員具有一顆好奇的心、專業(yè)的懷疑態(tài)度、一雙挑剔的眼睛、探究根底的精神、與開發(fā)人員良好的溝通能力以及對常見的錯誤進行判斷的經(jīng)驗。
假如可以用建設性的態(tài)度對發(fā)現(xiàn)的缺陷或失效進行溝通，就可以避免測試員、分析人員和開發(fā)設計者之間的不愉快。這個道理同樣適用于文檔的評審過程。
在以建設性的方式討論缺陷、進度和風險時，測試員和測試的負責人都需要具有良好的人與人之間溝通的能力。通過良好的溝通，要讓軟件代碼或文檔的作者明白，發(fā)現(xiàn)缺陷的信息可以幫助他們來提高他們的技術水平。在測試階段發(fā)現(xiàn)和修復缺陷可以在項目后期節(jié)省時間和金錢，而且可以減少項目的風險。
溝通方面的問題經(jīng)常會發(fā)生，特別是當測試員只是作為不受歡迎的缺陷消息的傳遞者的時候。然而可以使用下面的一些建議和方法來改善測試員和其他小組成員之間的溝通和相互關系：以合作而不是爭斗的方式開始項目，時時提醒項目的每位成員：共同目標是追求高質(zhì)量的產(chǎn)品。
?對產(chǎn)品中發(fā)現(xiàn)的問題以中性的和以事實為依據(jù)的方式來溝通，而不要嘲笑引入這個問題的小組成員或個兒。比如，客觀而實際的描寫缺陷報告和評審(review)發(fā)現(xiàn)的問題。
?盡量理解其他成員的感受，以及他們?yōu)槭裁磿羞@種反應。
確信其他成員已經(jīng)理解你的描述，反之亦然。

軟件的易用性測試原則和方法有什么？

軟件測試的目的;在規(guī)定的條件下對程序進行操作，以發(fā)現(xiàn)程序錯誤，衡量軟件質(zhì)量，并對其是否能滿足設計要求進行評估。
準則：對計算機軟件進行測試前，首先需遵循軟件測試原則，即不完全原則的遵守。不完全原則即為若測試不完全、測試過程中涉及免疫性原則的部分較多，可對軟件測試起到一定幫助。
因軟件測試因此類因素具有一定程度的免疫性，測試人員能夠完成的測試內(nèi)容與其免疫性成正比，若想使軟件測試更為流暢、測試效果更為有效，首先需遵循此類原則，將此類原則貫穿整個開發(fā)流程，不斷進行測試，而并非一次性全程測試。
測試方法：
1、靜態(tài)測試方法
軟件代碼的靜態(tài)分析測驗，此類過程中應用數(shù)據(jù)較少，主要過程為通過軟件的靜態(tài)性測試（即人工推斷或計算機輔助測試）測試程序中運算方式、算法的正確性，進而完成測試過程，此類測試的優(yōu)點在于能夠消耗較短時間、較少資源完成對軟件、軟件代碼的測試，能夠較為明顯地發(fā)現(xiàn)此類代碼中出現(xiàn)的錯誤。
2、動態(tài)測試
計算機動態(tài)測試的主要目的為檢測軟件運行中出現(xiàn)的問題，較靜態(tài)測試方式相比，其被稱為動態(tài)的原因即為其測試方式主要依賴程序的運用，主要為檢測軟件中動態(tài)行為是否缺失、軟件運行效果是否良好。
3、黑盒測試
通過數(shù)據(jù)輸入觀察數(shù)據(jù)輸出，檢查軟件內(nèi)部功能是否正常。測試展開時，數(shù)據(jù)輸入軟件中，等待數(shù)據(jù)輸出。數(shù)據(jù)輸出時若與預計數(shù)據(jù)一致，則證明該軟件通過測試，若數(shù)據(jù)與預計數(shù)據(jù)有出入，即便出入較小亦證明軟件程序內(nèi)部出現(xiàn)問題，需盡快解決。
4、白盒測試
白盒測試相對于黑盒測試而言具有一定透明性，原理為根據(jù)軟件內(nèi)部應用、源代碼等對產(chǎn)品內(nèi)部工作過程進行調(diào)試。測試過程中常將其與軟件內(nèi)部結(jié)構(gòu)協(xié)同展開分析，*優(yōu)點即為其能夠有效解決軟件內(nèi)部應用程序出現(xiàn)的問題，測試過程中常將其與黑盒測試方式結(jié)合，當測試軟件功能較多時，白盒測試法亦可對此類情況展開有效調(diào)試。
擴展資料
軟件測試工具
開源測試管理工具：Bugfree、Bugzilla、TestLink、mantis zentaopms。
開源功能自動化測試工具：Watir、Selenium [1] 、MaxQ、WebInject。
開源性能自動化測試工具：Jmeter、OpenSTA、DBMonster、TPTEST、Web Load Simulator。
其他測試工具與框架：Rational Tester、Borland Silk系列工具、WinRunner、Robot等。
禪道測試管理工具：功能比較全面的測試管理工具，功能涵蓋軟件研發(fā)的全部生命周期，為軟件測試和產(chǎn)品研發(fā)提供一體化的解決方案。是一款優(yōu)秀的國產(chǎn)開源測試管理工具。
Quality Center：基于Web的測試管理工具，可以組織和管理應用程序測試流程的所有階段，包括指定測試需求、計劃測試、執(zhí)行測試和跟蹤缺陷。
QuickTest ：用于創(chuàng)建功能和回歸測試。
：預測系統(tǒng)行為和性能的負載測試工具。
國內(nèi)免費軟件測試工具有：和。
參考資料來源：百度百科-軟件測試技術
參考資料來源：百度百科-軟件測試