第一篇：軟件測試讀書心得

軟件測試技術讀書心得

作為一名具有一年多的軟件開發(fā)人員，對于軟件測試我有著深刻的體會。我在2014年6月進入湖北大學軟件工程研究所，開始學習并且進行C#.NET團隊開發(fā)，除了課程設計，也進行了真正的項目實戰(zhàn)開發(fā)。因為這些開發(fā)經驗，我深刻的明白軟件測試在項目開發(fā)當中有著相當重要的地位，尤其是那種團隊開發(fā)！

一、軟件測試的工作及要求

軟件測試工作是一個系統(tǒng)而且復雜的工作，軟件測試的目的就是在確保軟件多分質量，確認軟件以正確的方式做了你所期望的工作，所以軟件測試工作的主要內容就是發(fā)現(xiàn)軟件的錯誤發(fā)現(xiàn)軟件的錯誤、有效定義和實現(xiàn)軟件成分由底層到高層的組裝過程、驗證軟件是否滿足規(guī)格書要求和系統(tǒng)定義文檔所規(guī)定的技術要求、為軟件質量模型的建立提供依據(jù)。

軟件的測試不僅是要確保軟件的質量，還要給開發(fā)人員提供信息，以方便其為風險評估做相應的準備，以及為其提供分析依據(jù)，重要的是要貫穿在整個軟件開發(fā)的過程中，保證整個軟件開發(fā)的過程是高質量的。

軟件測試對測試工程師來講，要求具備較強的專業(yè)知識，嚴謹細心耐心的測試態(tài)度，良好的反向思維、發(fā)散思維能力、溝通能力等等。

二、為什么要進行軟件測試

其實對于開發(fā)人員來說，軟件測試是一件很痛苦的事情。我們每個開發(fā)人員都是希望并且認為我們寫的代碼是沒有問題的，而軟件測試的工作就恰恰就是找出開發(fā)人員程序中的bug，這是一個很讓軟件開發(fā)人員郁悶的一個問題。我辛辛苦苦寫代碼實現(xiàn) 出來的功能在測試人員的眼里，各種問題各種bug都出現(xiàn)了，這對于一個程序人員來說，算的上是一種打擊。這也就是在我們團隊開發(fā)中一個常常出現(xiàn)的問題——出現(xiàn)爭論。

我們團隊經常為了某一個功能爭論，測試人員覺得這個功能不合理，不合適，甚至是錯誤的，而開發(fā)人員覺得這個功能沒有任何問題！而且在大多數(shù)情況下，這種爭論都以軟件測試人員的勝利告終。出現(xiàn)這種爭論的原因是，一個程序員，都會對自己的軟件出現(xiàn)這樣一種期望——期望自己的軟件不會出現(xiàn)錯誤！

然而，正是因為這種期望，我們更是需要進行測試，并且讓專人來進行測試，因為，在這種心理的期望面前，任何程序員都會出現(xiàn)測試上的偏向，他們更偏向于向軟件正常運行的的那個一方面進行測試，然而實際上這種測試是經不起現(xiàn)實數(shù)據(jù)的考驗的。

這也體現(xiàn)了軟件測試的重要性。并且，根據(jù)這種心理，有人提出了一種測試的方法——黑盒測試。

三、軟件需要測試的部分

我們總在說要對軟件進行測試，那么我們到底需要對軟件進行那些測試呢？下面我們對一些常常常需要進行的測試進行一些列舉。

1.邊界測試，測試用戶輸入框中的數(shù)值的最大數(shù)和最小數(shù)，以及為空時的情況。

2.非法測試，例如在輸入數(shù)字的地方輸入字母。

3.跟蹤測試，跟蹤一條數(shù)據(jù)的流程,保證數(shù)據(jù)的正確性。

4.在開始測試時應保證數(shù)據(jù)的正確性，然后在從系統(tǒng)中找出各種BUG。

5.接口測試，程序往往在接口的地方很容易發(fā)生錯誤，要在此模塊測試勿掉以輕心。

6.代碼重用測試，在開發(fā)過程中有些模塊功能幾乎相同，程序員在重用代碼時可能忘記在原有代碼上修改或修改不全面，而造成的錯誤。

7.突發(fā)事件測試，服務器上可能發(fā)生意外情況的測試。

8.外界環(huán)境測試，有些系統(tǒng)在開發(fā)時依賴于另外一個系統(tǒng),當另外一個系統(tǒng)發(fā)生錯誤時, 這個系統(tǒng)所受到的影響的情況。

9.在程序員剛修復Bug之后的地方,再找一找，往往程序員只修復報告出來的缺陷而不去考慮別的功能在修改時可能會重新造成錯誤。

10.認真做好測試記錄在做完一天的測試記錄之后,第二天再根據(jù)第一天的測試記錄重復測試你會發(fā)現(xiàn)有未修正的錯誤。

11.文字測試，如果在系統(tǒng)中有用詞不當?shù)牡胤?，我想這是不應該的。12.系統(tǒng)兼容測試，例如有些程序在IE6能運行正常，到IE5下不能運行。有些程序在WIN2000下能運行，而到WIN98卻不能運行。像一些很特別的用戶去使用系統(tǒng)，你很有可能發(fā)現(xiàn)BUG。

13.用戶的易用性測試，往往用戶的需求是不斷的變化的，而其中的一部份變化的原因，是有用戶操作上不方便引起的。

以上舉例出來的我們在軟件開發(fā)過程中，一般都需要進行測試

四、軟件測試的基本方法

軟件測試針對的是軟件的缺陷，也就是說我們軟件測試為的就是找出軟件的某些缺陷，為了更好的找出軟件的缺陷，我們應當知道軟件的缺陷的定。

1)軟件缺陷的定義：

? 軟件未實現(xiàn)應實現(xiàn)的功能

? 軟件出現(xiàn)了不應出現(xiàn)的錯誤

? 軟件實現(xiàn)了不應實現(xiàn)的功能

? 軟件未實現(xiàn)符合一般軟件常識的功能

? 軟件出現(xiàn)了使用、性能上等不易被用戶接受的問題

針對上面所述的缺陷，我們提出了一些列的軟件測試的方法。

2)首先從是否關心軟件內部結構和具體實現(xiàn)的角度劃分可以劃分為兩大類

? 黑盒測試（不知道程序的結構）

? 白盒測試（知道程序的結構）

黑盒測試：是軟件測試中的另一種方法，即在測試時，測試人員并不了解程序的結構，因此測試人員只能通過輸入得到相應輸出，并根據(jù)相應的輸出結果來判斷某個功能是否實現(xiàn)、此功能是否正確。黑盒測試常用的方法有: ? 劃分等價類

? 輸入條件 ? 邊界值分析法 ? 錯誤推測法 ? 因果圖法 ? 判定表組成法 ? 正交試驗設計 ? 場景法

這種測試方式只能了解到程序的外部結構。無法知道程序的內部的邏輯結構，因此具有一定的局限性。而知關于邏輯部分的局限性便可由白盒測試來進行彌補。

白盒測試：是軟件測試中比較常用的用來測試邏輯軟件結構的方法，通過白盒測試，我們可以了解程序的詳細的邏輯結構，以此來判斷程序的運行是否得到我們想要的效果。白盒測試常用的方法就是覆蓋測試，也就是語句覆蓋和邏輯覆蓋。語句覆蓋要求在設計測試用例的時候將所有的語句運行到，而邏輯覆蓋則是要求對于每一個判斷所得到的不同的路徑我們均需要進行測試。

3)從是否執(zhí)行程序的角度也分為兩大類

? 靜態(tài)測試 ? 動態(tài)測試

4)從軟件開發(fā)的過程按階段劃分有

A.單元測試 B.集成測試 C.確認測試 D.系統(tǒng)測試 E.驗收測試 F.回歸測試 G.Alpha測試 H.Beta測試

五、軟件測試的過程

軟件測試的方法有很多，而軟件測試應當盡早進行并且按照一定的步驟進行，這樣才可以把問題今早的解決在搖籃里面。下面是軟件測試的步驟。

第一步：對要執(zhí)行測試的產品/項目進行分析，確定測試策略，制定測試計劃。該計劃被審核批準后轉向第二步。測試工作啟動前一定要確定正確的測試策略和指導方針，這些是后期開展工作的基礎。只有將本次的測試目標和要求分析清楚，才能決定測試資源的投入。

第二步：設計測試用例。設計測試用例要根據(jù)測試需求和測試策略來進行，進度壓力不大時，應該設計的詳細，如果進度、成本壓力較大，則應該保證測試用例覆蓋到關鍵性的測試需求。該用例被批準后轉向第三步。第三步：如果滿足“啟動準則”（EntryCriteria），那么執(zhí)行測試。執(zhí)行測試主要是搭建測試環(huán)境，執(zhí)行測試用例。執(zhí)行測試時要進行進度控制、項目協(xié)調等工作。

第四步：提交缺陷。這里要進行缺陷審核和驗證等工作。

第五步：消除軟件缺陷。通常情況下，開發(fā)經理需要審核缺陷，并進行缺陷分配。程序員修改自己負責的缺陷。在程序員修改完成后，進入到回歸測試階段。如果滿足“完成準則”（ExitCriteria），那么正常結束測試。

第六步：撰寫測試報告。對測試進行分析，總結本次的經驗教訓，在下一次的工作中改。

軟件測試過程管理，主要包括軟件測試是什么樣的過程，如何評價一個軟件測試過程，如何進行配置管理和測試風險分析以及測試成本的管理。

第二篇：軟件測試心得

從事測試到現(xiàn)在已有半年多的時間，剛開始做為新人時，面對未接觸過的系統(tǒng)中的每個模塊，心中是有些慌張的。僅憑業(yè)務學習和前輩們講的測試方法還是很難做到完全讓自己放心，這可能是新人的通病，害怕測試不全面不深入。至少我在測試之初，是比較膽怯的。隨著時間的推移，我發(fā)現(xiàn)自己越來越自信，特別是面對新的模塊新的功能消除了那種恐懼感?？偨Y了以前的一些心得，供大家交流：

一、根據(jù)自己的實際情況，做一個學習計劃，邊學邊測，以學來熟悉側，以測來鞏固學，做到二者的融合；一開始會比較苦，畢竟很多都不熟悉，有時單據(jù)不能保存，有時流程走不下去，一定要堅持?。粯I(yè)務知識熟悉了，就好多了。

二、剛開始時因為業(yè)務不熟悉，需求也不熟悉，就開始測試任務。這時自己就看看測試用例，隨便測測，看功能能不能正常走通。

1、根據(jù)功能做一個基本的測試計劃；當然在做這個測試計劃時可以先問下你的主測或是開發(fā)經理，有什么建議，畢竟他們經驗比我們豐富。

2、開始測試時，嚴格按照測試用例來執(zhí)行，當然等業(yè)務熟練后，自己可以寫測試用例來執(zhí)行，畢竟原有測試用例并未覆蓋整個模塊的功能；這樣就可以補缺補漏。

3、在學習或測試中，有不懂的或是不明白的地方，盡量去問主測或是其他同事，但要有個度，畢竟別人都有自己的任務，不要一有問題就問，你可以將今天學習或是測試中存在的問題一條條記錄下來，等中午休息或是下班前一刻向別人求教；也可回家后自己上網上搜索相關的知識解決問題。

三、學會換位思考，將自己當客戶，發(fā)揮自己的想象找出客戶存在的應用場景，在客戶操作的基礎上尋找測試突破口，假如實際經驗積累不多，可上網查找或是詢問別人；因為每個客戶的操作不一樣，會存在比較復雜業(yè)務邏輯，這時可以分解成一小塊一小塊測試，最后再從整體的角度入手；由簡單到復雜，簡單的測試通過后再做復雜的測試，而不是一開始就做復雜的測試。

四、隨時記錄學習到的新知識，特別是其他相關模塊的知識；同時記錄工作心得，特別是好的測試方法和測試思考方法；好記憶不如爛筆頭，何況在這科技發(fā)達的時代，鍵盤隨便敲敲，即清晰又明了，下次碰到相同問題可查看。

最后說一句，路是自己走出來的，測試也是自己測出來的。

第三篇：軟件測試心得

軟件測試心得體會

軟件測試工作是一個系統(tǒng)而復雜的工程，軟件測試的目的就是確保軟件的質量、確認軟件以正確的方式做了你所期望的事情，所以工作的主要任務是發(fā)現(xiàn)軟件的錯誤、有效定義和實現(xiàn)軟件成分由底層到高層的組裝過程、驗證軟件是否滿足規(guī)格書要求和系統(tǒng)定義文檔所規(guī)定的技術要求、為軟件質量模型的建立提供依據(jù)。

而且軟件的測試不僅是要確保軟件的質量，還要給開發(fā)人員提供信息，以方便其為風險評估做相應的準備，以及為其提供分析依據(jù)，重要的是要貫穿在整個軟件開發(fā)的過程中，保證整個軟件開發(fā)的過程是高質量的。

軟件測試對測試工程師來講，要求具備較強的專業(yè)知識，嚴謹細心耐心的測試態(tài)度，良好的反向思維、發(fā)散思維能力、溝通能力等等。

以下是就自己的個人工作經歷談一些淺見：

1.標準文檔的制定：

1.1.任何一個公司要讓自己的產品面市，都要有自己的一 套完整的品質標準，這個標準一定是在符合國標及客戶標準的基礎上形成的企業(yè)標準，系統(tǒng)而全面地描述一款產品的功能、性能、可靠性、健壯性、安規(guī)要求等一系列的產品標準，并根據(jù)客戶特定要求相應調整。

1.2.測試儀器的作業(yè)指導書(SOP)及保養(yǎng)說明等。定義儀器 的使用步驟、操作指南和保養(yǎng)細則等。

2.測試資料的歸檔：

標準媒體文件、測試報告、BUG LIST庫（電子類問題、結構類問題、軟件類問題：方案自存問題、品證測試問題、生產測試問題、客戶反饋問題、終端消費者反饋問題等）、認證測試文檔歸納總結(認證公司培訓資料、認證過程中出現(xiàn)并改善的問題)、測試工程師經驗分享、常見問題解答FAQ等。

3.功能測試：

3.1.這是軟件測試工作中最核心和最基本的一項測試，該測試的主要內容是檢查軟件是否符合需求定義，并通過構造正常的操作來檢查的動作是否正確；在這個測試里，正確性是最最重要的軟件質量要素。

3.2.功能測試按照可見性可以分為兩類：顯性功能和隱性功能。

顯性功能：指在菜單里可以看得到的功能。隱性功能：指在菜單里看不到的功能。

例如，電話本的顯性功能有增加、編輯、刪除、撥打等，這些功能可以在電話本的菜單里面看得到，姓名列表排序則屬于一個隱性功能，因為在電話本的菜單里沒有這樣一個子菜單，但它卻是一個實實在在的功能。如以下這些隱性功能都測試中都需重點關注： a.電話本上下頁切換，是否有遺漏聯(lián)系人信息？ b.是否支持手機內存、SIM卡電話本的同時下載？還是支持從一種介質里下載？

c.斷電后再上電，系統(tǒng)設置的時間是否有記憶功能？ d.GPS信號正常時，導航地圖中時間是否有更新？ e.TFT屏在Power off→on, ACC off→on時，屏的角度是否有記憶？

f.模擬導航時，是否有雙工功能？后臺源聲音輸出是否正常？

g.路試語音產品外置麥克風使用效果時，考慮車速、風聲、車內講話噪聲、汽車底盤/發(fā)動機噪聲等對麥克風錄音效果的影響，軟件多線程開啟時導致的資源占用/系統(tǒng)繁忙對后臺錄音系統(tǒng)的影響。(也可從結構方面考慮：外置麥克風型腔開孔的接觸面積，是否360度可旋轉等來增加錄音的路徑等。）

h.地圖上的POI信息通過后臺語音搜索獲取不到，解決措施：要求方案商訊飛完善后臺語音庫。

3.3.在實際的測試過程中，顯性功能通過菜單遍歷可以很容易地進行無遺漏的測試，但是隱性功能卻很容易為我們所忽略！一個有效的解決辦法是去檢查軟件的功能定義列表(Feature List)，從這個列表里面找出那些隱性的功能。

3.4.制定測試用例時，要充分考慮各功能模塊軟件的顯性功能和隱性功能。

4.健壯性測試：

橘生淮南則為橘，生于淮北則為枳。是說明橘的健壯性太差。該成語充分說明了我們對產品進行健壯性測試的必要性。4.1.健壯性是指在異常情況下，軟件還能正常運行的能力。健壯性有兩層含義：一是容錯能力，二是恢復能力。健壯性測試主要包括：電子硬件健壯性(如：遙控距離測試、高低電壓適應性測試、插拔電及開關機測試、靜電抗擾度測試、熱插拔測試)和機械健壯性(如：整機結構設計基準測試、模擬運輸測試、常溫包裝跌落測試)。4.2.這項測試主要是檢查軟件對異常操作的容錯能力，異常操作通常要考慮異常輸入操作及異常條件兩個方面。例如：測試藍光媒體播放器時，反復把HDMI連接線拔掉，造成通信異常中斷，再接上復合視頻(CVBS)信號輸出，即由數(shù)字信號輸出轉為模擬信號輸出?；謴蜏y試重點考察一下幾項：（1）系統(tǒng)能否重新運行；（2）有無重要的數(shù)據(jù)丟失；（3）是否毀壞了其它相關的軟件或硬件；（4）若軟件出現(xiàn)系統(tǒng)報錯，是否有自恢復能力。

4.3.軟件的很多功能的實現(xiàn)是有很多隱含的條件的，在健壯性測試中，要檢查當這些條件不滿足的時候的反應。例如：目前大多數(shù)3G智能手機，與各電信運營商形成利益捆綁，每款手機支持特定的電信運營商提供的通信服務，其它運營商提供的服務則被拒之門外。當使用移動SIM卡安裝在只支持聯(lián)通通信服務的3G手機上，關注該手機表現(xiàn)：是否在執(zhí)行自動更新時重啟？還是執(zhí)行自動更新后提示不支持移動運營通信服務：SIM card not supported, emergency calls only？

例如：在做完常溫包裝跌落測試后，再測試機芯的讀碟能力，讀取偏芯碟、面振碟、偏重心碟、刮痕碟、指紋碟等等碟片，與未做跌落測試前讀碟能力進行比較。如果讀碟能力比以前更差，則考慮改進措施：軟件適當增加錄軌時間或機芯托盤加固等。

5.矩陣測試

5.1.矩陣測試是使處于一個特定的狀態(tài)，然后構造一個異步事件，檢查當這個異步事件發(fā)生時軟件的性能。

5.2.根據(jù)事件的來源，異步事件分為外部事件和內部事件

兩種。

外部事件舉例：藍牙模式下來短信、來電話、各種介質(U盤、iPod、導航卡、收音天線)接入等。如接入導航盒后，導航不運行，看是否會對其它模式的運行產生影響？最近測試的Mazda J53R就是在接入導航盒后，產生系統(tǒng)不穩(wěn)定，長時間播放藍牙音樂、iPod曲目等會出現(xiàn)系統(tǒng)報錯。

內部事件舉例：車載DVD藍牙自動連接、自動接聽、音樂下載流量使用提醒, 手機低電警告、自動關機等。如帶在線音樂功能的車載DVD，插上3G dongle時，下載歌曲時是否有流量提醒：該歌曲占用多少容量、目前已用多少流量、還剩余多少流量。

6.UI測試

好的UI設計不僅是讓軟件變得有個性有品味，還要讓軟件的操作變得舒適、簡單、自由、充分體現(xiàn)軟件的定位和特點。UI測試遵循的原則：

6.1.易用原則：如主菜單icon的排列布局：橫縱向、環(huán)形、橢圓形。

6.2.友好原則：歌曲列表中的drag bar是否太窄，導致不方便拖動？

6.3.求美原則：檢查在UI的布局里，各種要素是否能傳達一種美感，布局是否合理，色彩是否合諧。

如拖動列表的動態(tài)效果、刷新列表的沙漏效果等。6.4.一致性原則：同樣的一個功能的UI在不同的情景(scenario)所呈現(xiàn)的方式應該保持一致。

例如：在設置菜單選擇DSP模式，退出后在各放音源下檢查DSP模式與設置菜單中是否一致；將系統(tǒng)語言改為英語等其它語言，播放界面及菜單等，拼寫是否正確，顯示是否一致、是否越界等。

6.5.普遍性原則：即遵循約定俗成的規(guī)定。藍牙icon一般遵照藍牙認證協(xié)會

標識，如果自己另外搞一種icon設計，反而弄得不倫不類。

測試用戶界面的色彩搭配、整體布局、行距、對齊，樣式統(tǒng)一等等。還有就是一些控件是否合理，提示信息和頁面信息是否有語法錯誤等等一系列問題，都應考慮進去。

7.用戶體驗：

用戶體驗：一種純主觀在用戶使用產品過程中建立起來的感受。對于一個界定明確的用戶群體來講，其用戶體驗的共性是能夠經由良好設計實驗來認識到。例如：

7.1.自然往往和人的本性相關的。微信的搖一搖是個以“自然”為目標的設計。設計“搖一搖”時，目標是和人的“自然”或者說“本能”動作體驗做到一致。搖一搖的體驗包括：動作:搖動；視覺:屏幕裂開并合上來響應動作； 聽覺:有吸引力的聲音來響應動作；結果:從屏幕中央滑下的一張名片。整個界面沒有菜單和按鈕。但幾乎沒有比它更簡單的交互體驗了。聯(lián)想到車載DVD，如果能通過手勢識別來實現(xiàn)上、下頁菜單的切換也是不錯的選擇。

7.2.如Mazda J53R平臺藍牙電話本的下載，使用部分手機連接成功后下載時間超過2分鐘并提示Time out，且電話本條目數(shù)量也不多，約200條，從用戶角度來說此時長不合理且不易接受。例如建議軟件增加電話本保存在內存中，需要調用時直接從主機菜單內導出即可，這樣方便且快捷，而且下載時間快，不需再通過藍牙傳輸。7.3.主機主音量不變的情況下，通過切換模式，主觀感覺不同模式下聲音輸出幅度不一致，即不同模式間切換感覺聲音忽大忽小，這樣就會給用戶造成較差的聽覺感受。此時我們可通過增益平衡(Gain Balance)來分析各源間的信號輸出幅度：

a.將TCD-784碟第2曲1KHz 0dB信號作為標準信號通過Line out輸出,再在信號發(fā)生器上定標準輸出； b.調節(jié)信號發(fā)生器參數(shù)為頻率98.1MHz,調制率75KHz，信號強度66dB,比較與CD輸出時的幅度差別； c.調節(jié)信號發(fā)生器參數(shù)為頻率999KHz,調制率80%，信號強度80dB,比較與CD輸出時的幅度差別；

d.轉到AUX,將輸入設置為1KHz，500MV(-12dB), 比較與CD輸出時的幅度差別。

通過不同模式下的輸出幅度對比作為理論依據(jù)來改善, 如判定標準0+/-3dB。

8.兼容性測試：

主要測試不同介質對于被測設備的表現(xiàn)。包括：硬件兼容性測試(USB、SD、碟片、藍牙手機等兼容性測試)和軟件兼容性測試(音視頻、圖片、文本格式兼容性測試)。

如何在有限的成本和資源考慮下，針對此軟件產品規(guī)劃出適當?shù)募嫒菪詼y試，是所有軟件測試技術人員關注的重點。8.1.評估軟件應用環(huán)境，有針對性的制定測試計劃。做多少設備投資？投入多少人力？要測試多少兼容性測試完全會影響到軟件產品的最終成本。想要專心和投資在研發(fā)上，又想要節(jié)省成本的做好兼容性測試，只有評估軟件應用環(huán)境，有針對性的制定兼容性測試計劃,才能兼顧成本和產品的兼容性質量。

8.2.在多種平臺/應用環(huán)境上測試一個軟件產品的開發(fā)成功，不僅僅是編寫完為使用者提供服務功能的程序而已，更重要的是能在用戶環(huán)境中可靠的運行。因此，軟件程序編寫工作的完成，其實只是完成了開發(fā)任務中的一半，對軟件進行模擬用戶環(huán)境進行兼容性測試其重要性不亞于對程序本身的開發(fā)。因此在不同平臺、不同版本軟件上做對比測試很有必要。

9.性能測試

性能測試通過自動化的測試工具模擬多種正常、峰值以及異常負載條件來對系統(tǒng)的各項性能指標進行測試。負載測試和壓力測試都屬于性能測試，兩者可以結合進行。

9.1.測試通道延遲和極性（Channel Delay and Polarity），播放通道激勵信號bd_8ch_delaypol_21,使用AP2700 掃描到的曲線圖（如下），以此觀察通道的延遲和極性是否符合要求。

9.2.音視頻同步（A/V Synchronize）,播放標準AV測試信號，使用AV同步測試儀接受信號，測試儀的另一端連接PC。如Dolby Digital Plus判定標準：視頻先于音頻10ms或視頻后于音頻15ms，為可接受范圍。

10.臨界測試

臨界測試，就是指數(shù)據(jù)在保存、刪除、傳送、發(fā)送時或者這些動作即將發(fā)生時，考察軟件對外部干擾事件的處理情況。如文本文件容量大于或等于設計容量，關注讀取時的表現(xiàn)；藍牙通話/藍牙音樂關注傳輸距離臨界值附近的測試結果；藍牙連接成功立即斷開再連接等。如MTK平臺的某些機型在即將刪除一條短信息時收到一條新信息，但刪除的卻不是剛剛選定的那條信息，而是剛剛收到的這條新信息！

11.可靠性測試

11.1.可靠性是指在一定的環(huán)境下、在給定的時間里，軟件不發(fā)生故障的概率。

11.2.可靠性本來是硬件領域的術語，比如某個電子設備在剛開始工作時挺好的，但由于器件在工作中其物理性質會發(fā)生變化（如發(fā)熱），慢慢地系統(tǒng)的功能或性能就會失常。

例如：高溫工作試驗：常溫下將產品置于恒溫恒濕試驗箱中，按實際裝車的狀態(tài)連接輸入設備，負載設備，電源，使樣機為POWER OFF狀態(tài)，逐步升溫到+70℃，保持2小時后，使樣機為POWER ON標準工作狀態(tài)，分別設置為AM、FM電臺收音/DVD、CD、SD卡播放/藍牙/導航等工作模式下工作，若無電臺則接收AM/FM信號發(fā)生器輸出標準信號,音量開關置1W輸出功率位置,試驗中經常確認樣機工作是否正常。樣品工作72小時后，外觀、功能應正常；試驗后在常溫下放置2小時以上，電性能指標測試應正常。

11.3.軟件在運行過程中不會發(fā)生像硬件那樣的物理變化，但是并不代表軟件現(xiàn)在運行是正確的，那它一輩子運行也是正確的，說不定哪一天它就不正常了。軟件中司空見慣的“內存泄漏”與”誤差積累“等問題不是一時半會兒就能測試出來的，需要一個較長時間的觀察。例如：做完高溫試驗導致Flash壞塊、或丟代碼等，此時需要軟件對該模塊代碼做雙備份處理。

11.4.時隱時現(xiàn)的問題一般都屬于可靠性問題，糾錯的成本非常高。當工程師十萬火急地感到問題現(xiàn)場時，問題消失了；等工程師離開后，問題又出現(xiàn)了，仿佛敵進我退一般！此種低概率現(xiàn)象一定要錄好Trace和Video。

12.黑盒測試模型

輸入黑盒輸出制約條件期望結果 12.1.黑盒測試不需要去關注軟件的整體架構及其編碼細則，只需要通過構造一些合理的輸入（操作），來觀察被測設備的實際結果或現(xiàn)象（輸出），從而判定是否存在問題，需求文檔是黑盒測試的主要依據(jù)。

12.2.在一個功能的實現(xiàn)過程中，可能存在這一些隱含的制約條件，它們影響著期望結果或者是輸出。

“牛吃的是草，擠出的是奶”，這個命題有一個制約條件，魯迅先生雖然沒有說明，但我們應該明白，這里是特指母牛，你就是把公牛捏死了也擠不出奶來！12.3.問題就是輸出跟期望結果的差距，需要注意的是，當立場不同時，對問題的定性也可能不一樣，開發(fā)人員站在研發(fā)的角度說這不是問題，測試人員站在質量的角度說這是問題。

13.實用的黑盒技術

13.1.輸入的構造通常會采用窮舉的思想，可是窮舉的空間如果非常大，那將使人十分的沮喪，還不如回家象張恒一樣數(shù)星星，說不定還能數(shù)出個天文學家來。有兩種手段可以有效地縮小窮舉空間：等價劃分和邊界值分析。13.2.等價劃分：等價區(qū)間的概念可以這樣表述，設(A，B)是命題f(x)的一個等價區(qū)間，在(A，B)中任意取值x1進行測試：

如果f(x1)錯誤，那么f(x)在整個區(qū)間(A，B)上都將出錯；

如果f(x1)正確，那么f(x)在整個區(qū)間(A，B)上都將正確。

等價劃分思想的關鍵是找到一個合適的標準去劃分等價區(qū)間！

新中國成立不久，有一位外國記者問周恩來總理：總理先生，請問你們中國有幾個廁所？意思是新中國一窮二白，除了廁所多一點之外沒有什么別的財富。周恩來回答說：記者先生，我們中國只有兩個廁所，一個是男廁所，另一個是女廁所。這是周恩來總理等價劃分的高超藝術。

13.3.邊界值分析，“缺陷遺漏在角落里，聚集在邊界上”，邊界值分析是對等價劃分的一種有效補充。

14.測試計劃

制定一個完整、規(guī)范的測試計劃對每一個測試管理人員來說是非常重要的！測試計劃應該至少包括如下之內容： 14.1.概述(Overview): 文檔通常都是以概述開頭的，測試計劃在概述里應該要寫明該測試是做什么的，把測試的范圍定下來，要測什么，不測什么。

14.2.測試目標(Test Goals)和發(fā)布標準(Release Criteria)一般說來，測試計劃以定要寫明測試的最終目標(Test Goals)，必須使自己和別人明白為什么必須做這個測試，該測試需要達到的目的是什么。

另外，測試計劃還需要明確定義發(fā)布標準(Release Criteria)的范圍，如果有需要，可能還需要定義每一個發(fā)布標準定義在DR2、DR3和DR4個階段的目標。14.3.測試方法描述(Testing Approach/Description)從項目總體的角度定義軟件的測試方法，如我們在前面講過的單個功能測試、集成測試、系統(tǒng)測試，以及沒有講的附件測試、專項測試、外場測試(Field Trial)。14.4.測試進度表(Testing Schedule)定義在DR各個階段的詳細進度，該進度表依賴于項目總進度及軟件開發(fā)進度。14.5.測試資源(Testing Resource)。

第四篇：軟件測試心得

《軟件測試心得體會》

軟件測試在整個軟件周期中的重要性。它存在于整個項目周期，在項目開始

下面簡單談談我的幾點體會：

體會一：

體會一：軟件測試在整個軟件周期中的重要性。

它存在于整個項目周期，在項目開始之初需求調研的時候就開始了，在形成需求規(guī)格說明書的時候就需要針對文檔進行測試。這個環(huán)節(jié)在后續(xù)整個項目中占了很大的比重，能主導整個項目的走向，成敗與否全在于開始階段的決策。

體會二：軟件測試的真正意義在于發(fā)現(xiàn)錯誤，而不在于驗證軟件是正確的。

再嚴密的測試也不能完全發(fā)現(xiàn)軟件當中所有的錯誤，但是測試還是能發(fā)現(xiàn)大部分的錯誤，能確保軟件基本是可用的，所以在后續(xù)使用的過程中還需要加強快速響應的環(huán)節(jié)。結合軟件測試的理論，故障暴露在最終客戶端之前及時主動的去發(fā)現(xiàn)并解決。這一點就需要加強研發(fā)隊伍的建設。

體會三：在系統(tǒng)性能測試方面需要重視。

經過這次培訓中多個案例的講解，讓我了解到系統(tǒng)在上線之后會有很多不能預知的性能問題，需要在上線之前實現(xiàn)進行模擬，以規(guī)避風險，包括大數(shù)據(jù)量訪問，高并發(fā)數(shù)等等。當然也有很多應對手段，沒有哪種手段可稱為最完美，只有最合適的，需要靈活掌握，綜合運用以達到最優(yōu)程度，這是個很值得研究的領域。

下面是我的幾點想法：

想法一：加強系統(tǒng)上線前的性能測試。

目前我們在項目建設過程中對性能壓力測試的重視程度還不太高，廠家也很少有雇傭第三方的測試機構。而是在現(xiàn)網進行試用，遇到問題再解決，可能會產生滯后問題，影響客戶使用。希望以后能在性能測試方面提高重視程度，加大人力投入，以保證系統(tǒng)上線后能夠穩(wěn)定運行。

想法二：適當介入相關項目研發(fā)

對于快速響應這塊，我們不能一味依賴廠家，而希望自己就能快速響應，及時將問題解決。這也是一個比較長遠的問題，需要加強研發(fā)力量的投入。

我個人是做開發(fā)出身，有此類經驗，當時是在客戶現(xiàn)場，因為了解系統(tǒng)內部結構，能夠在第一時間排查解決客戶所反饋問題。

現(xiàn)在系統(tǒng)完全由廠家開發(fā)，很難了解內部結構，或許會造成后期維護困難。所以，是否應該針對某些項目介入廠家研發(fā)工作，比如請廠家提供源代碼等相關要素，以增進維護人員對系統(tǒng)的了解。

最后再次感謝公司提供的平臺，感謝領導的信任，讓我有機會得到更深層次的學習以及展示自己能力的機會，我也會盡我所能來完善工作的系統(tǒng)，提高整體工作效率，為南方電網的發(fā)展建設提供更堅實，優(yōu)秀的支撐服務平臺。

第五篇：軟件測試讀書總結

軟件測試（第二版）書的一些總結

軟件測試這本書分為了六個部分，介紹了軟件測試的基礎知識。以下分部分是我的一些理解。

1.第一部分是軟件測試綜述，主要介紹了與軟件測試及其相關內容的一些定義。

（1）什么是軟件缺陷？

軟件缺陷可以理解為導致軟件失敗的缺陷，失敗的軟件可以理解為不符合軟件產品說明書或不符合用戶要求的軟件。

（2）導致出現(xiàn)缺陷的原因以及軟件修復的難度（優(yōu)先級）？

軟件缺陷的原因實際是在說明書編寫、設計、編碼時出現(xiàn)了偏差錯誤，并且隨著開發(fā)往后，更不容易修復。

（3）軟件測試是要做什么？

軟件測試目的是要發(fā)現(xiàn)缺陷，給出提示，并且給出一定的建議（也可以是提供缺陷優(yōu)先級或嚴重性等度量）。值得注意的是，并不是非要給出修改軟件的建議，也可以是給出針對用戶培訓以規(guī)避軟件缺陷之類的建議。并且軟件測試所針對的范圍是交付用戶部分，所以測試要包含文檔測試。

（4）軟件測試時的原則

第一是不要求完全測試程序，要把測試控制在合理的測試量內（可由剩余缺陷和測試費用關系得到）；第二是找到軟件缺陷越多那么軟件缺陷越多。

2.第二部分是測試基礎，介紹了一些基本的測試方法（白盒與黑盒法的區(qū)別是是否參考了代碼，動態(tài)與靜態(tài)區(qū)別是是否運行了代碼）：

（1）靜態(tài)黑盒法測試產品說明書。

（2）動態(tài)黑盒法，一般用來進行功能性測試。使用等價類劃分的方法，將測試用例合理劃分，將測試量控制在合理范圍，并通過對測試用例和運行結果對比，得到測試結果。

測試不止是對數(shù)據(jù)測試，還要對軟件狀態(tài)進行測試（可參考狀態(tài)圖進行，測試軟件狀態(tài)轉換是是否出現(xiàn)問題）

（3）靜態(tài)白盒法，設計、編程階段審查設計、代碼。

（4）動態(tài)白盒測試，對程序中的代碼段或者某個模塊進行測試，測試用例不僅需要對數(shù)據(jù)覆蓋（例如代碼端公式里除數(shù)為0的情況），還要對代碼覆蓋（語句覆蓋、分支覆蓋、條件覆蓋，一級比一級覆蓋廣一些）

3.第三部分是運用測試技術，介紹了一些常見的測試，如：配置測試、兼容性測試、外國語言測試、易用性測試、文檔測試、軟件安全測試，并以網站測試作為實例進行了講解。

4.第四部分對測試方法進行補充。首先是自動化工具，可以減少測試一些性能難度，可以簡單的在短時間進行多次測試；其次是共享測試，就一個軟件的測試區(qū)域讓不同測試者進行測試，屬于內部測試；最后是beta版本測試，通過用戶使用后的數(shù)據(jù)進行分析。

（1）自動化測試工具中負載壓力工具與干擾注入器、噪聲發(fā)生器的區(qū)別？

負載和壓力工具測試軟件，用來給軟件加壓，加載，比如在測試文本處理程序的時候，設置其處于的磁盤空間和內存很小。類似于負載和壓力工具干擾注入器、噪聲發(fā)生器并不是提供固定不變的壓力、負載而是不斷變化，更不穩(wěn)定。

5.第五部分詳細介紹了測試的步驟（和各個過程產生的結果文檔）：

測試計劃?測試用例計劃（包括：測試設計即在什么地方用用例，測試用例即測試用例詳細說明，測試方法即怎樣用用例）?報告問題

值得注意的是，報告問題時需要對軟件缺陷進行跟蹤，才能及時了解軟件缺陷被提出了沒，正在被解決沒，解決掉沒。跟蹤其處在生命周期的哪個階段。

6.第六部分是職業(yè)的介紹展望。