㈠ 軟體測試 畢業論文
搜一個給你參考一下：
軟體測試從零開始
引言
幾年前，從學校畢業後，第一份工作就是軟體測試。那時候，國內的軟體企業大多對軟體測試還沒有什麼概念，書店裡除了鄭人傑編寫的《計算機軟體測試技術》之外，幾乎沒有其它的軟體測試相關書籍，軟體測試僅僅在軟體工程的教材中作為一個章節列出來，因此，我對軟體測試一無所知。不過，在正式走上工作崗位之前，公司提供了為期兩周的系統的軟體測試技術專題培訓，對接下來的軟體測試工作有很大的指導意義。現在，我繼續從事軟體測試的培訓與咨詢服務，在這個過程中，親眼目睹了很多軟體測試新手面對的困惑，他們初涉軟體測試行業，沒有接受系統的培訓，對軟體測試一無所知，既不知道該測試什麼，也不知道如何開始測試。下面針對上述情況，給出若干解決辦法。
• 測試准備工作
在測試工作伊始，軟體測試工程師應該搞清楚軟體測試工作的目的是什麼。如果你把這個問題提給項目經理，他往往會這樣回答： 「 發現我們產品裡面的所有 BUG ，這就是你的工作目的 」 。作為一名軟體測試新手，如何才能發現所有的 BUG ？如何開始測試工作？即便面對的是一個很小的軟體項目，測試需要考慮的問題也是方方面面的，包括硬體環境、操作系統、產品的軟體配置環境、產品相關的業務流程、用戶的並發容量等等。該從何處下手呢？
• 向有經驗的測試人員學習
如果你進入的是一家運作規范的軟體公司，有獨立的軟體測試部門、規范的軟體測試流程、軟體測試技術有一定的積累，那麼，恭喜你！你可以請求測試經理委派有經驗的測試人員作為你工作上的業務導師，由他列出軟體測試技術相關書籍目錄、軟體測試流程相關文檔目錄、產品業務相關的文檔目錄，在業務導師的指導下逐步熟悉軟體測試的相關工作。其實，在很多運作規范的軟體公司，已經把上述的師父帶徒弟的方式固化到流程中。
如果你進入的是一個軟體測試一片空白的軟體企業，那麼，也恭喜你！你可以在這里開創一片自己的軟體測試事業，當然，前提是老闆確實認識到軟體測試的重要性，實實在在需要提高產品的質量。這時候，可以到國內的軟體測試論壇和相關網站上尋找軟體測試資源，這種情況下，自學能力和對技術的悟性就至關重要了。
• 閱讀軟體測試的相關書籍
現在，中文版的軟體測試書籍越來越多，有的是國人自己寫的，有的是翻譯國外經典之作。可以到 www.chinapub.com 或者 www.cnforyou.com 等網路購書的站點查找軟體測試相關的書籍。目前，從國外引入的軟體測試書籍有很多經典之作，但是，翻譯成中文後，翻譯質量對閱讀效果有很大的影響。
• 走讀缺陷跟蹤庫中的問題報告單
如果您所在的公司已經有軟體缺陷跟蹤庫了，無論採用的是商用工具，如 ClearQuest 、 TestDirecter 等工具，還是採用的 Bugzilla 、 Mantis 等開源工具，這都無關緊要，缺陷跟蹤庫中的缺陷報告單才是有價值的。缺陷跟蹤庫中的問題報告單是軟體測試工程師工作績效的集中體現，同時也是軟體產品問題的集中體現。一般來說，缺陷報告單中最關鍵的幾個部分包括：第一部分是發現缺陷的環境，包括軟體環境、硬體環境等；第二部分是缺陷的基本描述；第三部分是開發人員對缺陷的解決方法。通過對上述缺陷報告單的三個部分作仔細分析，不知不覺你已經吸收了其他軟體測試人員的工作經驗，並掌握了軟體產品常見的基本問題。這是迅速提高軟體測試經驗的好方法。
• 走讀相關產品的歷史測試用例
如果你所在的公司有測試用例管理系統，那麼，走讀相關產品的軟體測試用例是迅速提高測試用例設計水平的一條捷徑。走讀測試用例也是有技巧的。測試用例寫作一般會包括測試用例項和根據測試用例項細化的測試用例，下面舉例說明。 「 測試用戶登錄的功能 」 是一個測試項，該測試項的目的是測試用戶登錄功能是否正確，是否能夠完成正常的登錄功能，是否能夠對非法用戶名和密碼做異常處理等等。因此，根據該用例項，可以設計出若干個測試用例，大多數情況下，測試用例項和測試用例是一對多的關系。
通過走讀測試用例項目，你可以掌握應該從哪些功能點著手未來的測試工作；通過走讀軟體測試用例，你可以了解如何根據被測試的功能點開展軟體測試用例的設計工作，包括如何確定測試用例的輸入、測試用例的操作步驟和測試用例的輸出結果等。
總之，走讀其他軟體測試人員設計的優秀軟體測試用例，是提高自身用例設計水平的好方法。
• 學習產品相關的業務知識
軟體測試人員不僅要掌握軟體測試技術相關知識，對產品相關的業務知識也要學習。這很好理解，如果從事財務軟體的測試工作，一定要學習財務知識；如果從事通訊產品測試工作，那麼相關的通訊理論知識也是必須的；如果從事銀行軟體的測試，銀行的業務流程也是不可或缺的知識點。
因此，在學習軟體測試技術的同時，千萬不要忽略產品相關業務知識的學習。如果你是一個軟體測試技術專家，但是對產品業務知識一無所知，那麼也只能測試出來純粹的軟體缺陷，而面對眼前出現的產品業務相關的缺陷，很可能是視而不見，如此這般，軟體測試的效果會大打折扣。
• 識別測試需求
識別測試需求是軟體測試的第一步。如果開發人員能夠提供完整的需求文檔和介面文檔，那固然好。可以根據需求文檔中描述的每個功能項目的輸入、處理過程和輸出，來設計測試用例。如果開發人員沒有提供軟體需求文檔，那該如何是好？下面給出幾個有效的方法：
• 主動獲取需求
開發人員通常不會更好地考慮軟體測試，如果沒有開發流程的強制規定，他們通常是不願意提供任何開發文檔，即便有強制規定，需求文檔也未必能夠真正指導軟體系統測試工作。因此，需要測試人員發揮主觀能動性，與相關的軟體開發項目經理和軟體開發人員保持溝通，了解軟體實現的主要功能是什麼，並記錄得收集到的信息。一般來說，開發人員即便沒有提供相關需求文檔，也會保存一些簡單的過程文檔，主動向開發人員索要這些文檔，可以作為測試的參考。此外，可以與公司的技術支持人員交流，技術支持人員是最貼近用戶的人，因此，通過交流可以獲取第一手的用戶使用感受，在測試的過程中會更加貼近用戶。
當拿到相關的資料後，從哪些方面分析需求？如何與開發人員交流需求？其實，只要把握需求分析的幾個關鍵的點就可以解決問題：輸入、處理過程、輸出、性能要求、運行環境，下面針對每一個項目逐一分析：
軟體輸入： 與該需求相關的一切可能輸入，可以從這幾方面考慮，輸入來源、輸入參數的數量、輸入參數的度量單位、輸入參數的時間要求、輸入參數的精度和輸入參數的有效輸入范圍。在測試用例設計中，這部分內容作為測試用例輸入的依據。
處理過程： 描述對輸入數據所執行的所有操作和如何獲得輸出的過程。測試人員了解處理過程即可，在測試過程中發現 BUG 時候，如果對處理過程了解的深入，對定位問題根源有很大的幫助。
軟體輸出： 描述每個需求的輸出結果，包括輸出的位置（如計算機顯示器、列印機，文件），輸出參數的數量、輸出參數的度量單位、輸出參數的時序、輸出參數精確度、輸出參數的有效輸出范圍、錯誤消息。在測試用例設計中，這部分內容作為測試用例的預期輸出。
性能要求： 與該需求相關的性能要求，比如 「 插入 ATM 取款卡後， 3 秒鍾內彈出提示用戶取款的圖形界面 」 。 3 秒鍾這一限制，就是對需求的基本性能要求。
運行環境： 軟體的運行所需的環境，包括硬體平台的要求、操作系統的要求、資料庫的要求，以及其它相關支撐軟體的要求。
• 確認需求的優先順序
確認需求的優先順序是很必要的，如果在產品進度比較緊的情況下，測試人員可以考慮優先測試優先順序高的需求項，如果進度允許，那麼在測試優先順序低的需求項，如果進度不允許，那麼就放棄測試優先順序低的需求項。如果軟體公司有規范的流程支撐，開發人員在提供軟體需求文檔的時候，應該在文檔中確定需求的優先順序。但是，如果開發人員連基本的軟體需求文檔都沒有提供，又怎能指望他們確定軟體需求的優先順序？如果是這樣，需求的優先順序只能由測試人員完成了。
• 加入開發小組的郵件群組
測試人員需要通曉被測試產品，但是，產品在開發的過程中往往是不斷變化的。如果軟體開發團隊有一套變更控制流程，測試人員會對產品的變更了如指掌。如果沒有變更控制，那就要採用其他的土方法了。如果公司裡面有自動化辦公系統，也許採用的是 Lotus Notes 系統，也許使用的是 E-mail 系統，測試人員應該加入到開發人員的郵件群組中。當開發人員通過郵件討論問題、通知召開技術會議的時候，測試人員可以及時知曉，如果必要，可以參加開發人員的技術會議。即便公司裡面有了軟體變更控制流程，加入到開發郵件群組也是一個很好的習慣。
• 與開發人員為鄰
建議測試人員與開發人員為鄰。我所在的測試組曾經與開發組是在相鄰的寫字間里，開發人員與測試人員的關系非常融洽，拋去同事關系，大家還是不錯的朋友。不管開發人員有什麼樣的活動，測試人員都能第一時間獲得信息。無論從事軟體測試工作，還是從事其它的工作，與工作中上下游環節的同事保持良好的個人關系對工作有很大便利。一般的公司內部都存在部門牆，良好的人際關系是打通部門牆的手段之一。向領導建議測試人員與開發人員為鄰，這很必要。
• 測試用例設計
測試需求收集完畢後，開始測試設計。測試用例是什麼？測試用例就是一個文檔，描述輸入、動作、或者時間和一個期望的結果，其目的是確定應用程序的某個特性是否正常的工作。設計測試用例需要考慮以下問題：
• 重用同類型項目的測試用例
如果我看得遠，那是因為我站在巨人的肩上 －－牛頓。
一般來說，每個軟體公司的項目可以分為固定的幾大類。可以按業務類型劃分，比如 ERP 軟體、產品數據管理軟體、通信軟體、地理信息系統軟體等等；可以按軟體結構來劃分，比如 B/S 架構的軟體、 C/S 架構的軟體、嵌入式軟體等等。參考同類別軟體的測試用例，會有很大的借鑒意義。如果，公司中有同類別的軟體系統，千萬別忘記把相關的測試用例拿來參考。如果，系統非常接近，甚至經過對測試用例簡單修改就可以應用到當前被測試的軟體。 「 拿來主義 」 可以極大的開闊測試用例設計思路，也可以節省大量的測試用例設計時間。
• 測試用例執行
測試用例設計完畢後，接下來的工作是測試執行，測試執行中應該注意以下幾個問題：
• 搭建軟體測試環境，執行測試用例
測試用例執行過程中，搭建測試環境是第一步。一般來說，軟體產品提交測試後，開發人員應該提交一份產品安裝指導書，在指導書中詳細指明軟體產品運行的軟硬體環境，比如要求操作系統系統是 Windows 2000 pack4 版本，資料庫是 Sql Server 2000 等等，此外，應該給出被測試軟體產品的詳細安裝指導書，包括安裝的操作步驟、相關配置文件的配置方法等等。對於復雜的軟體產品，尤其是軟體項目，如果沒有安裝指導書作為參考，在搭建測試環境過程中會遇到種種問題。
如果開發人員拒絕提供相關的安裝指導書，搭建測試中遇到問題的時候，測試人員可以要求開發人員協助，這時候，一定要把開發人員解決問題的方法記錄下來，避免同樣的問題再次請教開發人員，這樣會招致開發人員的反感，也降低了開發人員對測試人員的認可程度。
• 測試執行過程應注意的問題
測試環境搭建之後，根據定義的測試用例執行順序，逐個執行測試用例。在測試執行中需要注意以下幾個問題：
全方位的觀察測試用例執行結果： 測試執行過程中，當測試的實際輸出結果與測試用例中的預期輸出結果一致的時候，是否可以認為測試用例執行成功了？答案是否定的，即便實際測試結果與測試的預期結果一致，也要查看軟體產品的操作日誌、系統運行日誌和系統資源使用情況，來判斷測試用例是否執行成功了。全方位觀察軟體產品的輸出可以發現很多隱蔽的問題。以前，我在測試嵌入式系統軟體的時候，執行某測試用例後，測試用例的實際輸出與預期輸出完全一致，不過在查詢 CPU 佔用率地時候，發現 CPU 佔用率高達 90 ％，後來經過分析，軟體運行的時候啟動了若干個 1ms 的定時器，大量的消耗的 CPU 資源，後來通過把定時器調整到 10ms ， CPU 的佔用率降為 7 ％。如果觀察點單一，這個嚴重消耗資源的問題就無從發現了。
加強測試過程記錄： 測試執行過程中，一定要加強測試過程記錄。如果測試執行步驟與測試用例中描述的有差異，一定要記錄下來，作為日後更新測試用例的依據；如果軟體產品提供了日誌功能，比如有軟體運行日誌、用戶操作日誌，一定在每個測試用例執行後記錄相關的日誌文件，作為測試過程記錄，一旦日後發現問題，開發人員可以通過這些測試記錄方便的定位問題。而不用測試人員重新搭建測試環境，為開發人員重現問題。
及時確認發現的問題： 測試執行過程中，如果確認發現了軟體的缺陷，那麼可以毫不猶豫的提交問題報告單。如果發現了可疑問題，又無法定位是否為軟體缺陷，那麼一定要保留現場，然後知會相關開發人員到現場定位問題。如果開發人員在短時間內可以確認是否為軟體缺陷，測試人員給予配合；如果開發人員定位問題需要花費很長的時間，測試人員千萬不要因此耽誤自己寶貴的測試執行時間，可以讓開發人員記錄重新問題的測試環境配置，然後，回到自己的開發環境上重現問題，繼續定位問題。
與開發人員良好的溝通： 測試執行過程中，當你提交了問題報告單，可能被開發人員無情駁回，拒絕修改。這時候，只能對開發人員曉之以理，做到有理、有據，有說服力。首先，要定義軟體缺陷的標准原則，這個原則應該是開發人員和測試人員都認可的，如果沒有共同認可的原則，那麼開發人員與測試人員對問題的爭執就不可避免了。此外，測試人員打算說服開發人員之前，考慮是否能夠先說服自己，在保證可以說服自己的前提下，再開始與開發人員交流。
• 及時更新測試用例
測試執行過程中，應該注意及時更新測試用例。往往在測試執行過程中，才發現遺漏了一些測試用例，這時候應該及時的補充；往往也會發現有些測試用例在具體的執行過程中根本無法操作，這時候應該刪除這部分用例；也會發現若干個冗餘的測試用例完全可以由某一個測試用例替代，那麼刪除冗餘的測試用例。
總之，測試執行的過程中及時地更新測試用例是很好的習慣。不要打算在測試執行結束後，統一更新測試用例，如果這樣，往往會遺漏很多本應該更新的測試用例。
• 提交一份優秀的問題報告單
軟體測試提交的問題報告單和測試日報一樣，都是軟體測試人員的工作輸出，是測試人員績效的集中體現。因此，提交一份優秀的問題報告單是很重要的。軟體測試報告單最關鍵的域就是 「 問題描述 」 ，這是開發人員重現問題，定位問題的依據。問題描述應該包括以下幾部分內容：軟體配置、硬體配置、測試用例輸入、操作步驟、輸出、當時輸出設備的相關輸出信息和相關的日誌等。
軟體配置： 包括操作系統類型版本和補丁版本、當前被測試軟體的版本和補丁版本、相關支撐軟體，比如資料庫軟體的版本和補丁版本等。
硬體配置： 計算機的配置情況，主要包括 CPU 、內存和硬碟的相關參數，其它硬體參數根據測試用例的實際情況添加。如果測試中使用網路，那麼網路的組網情況，網路的容量、流量等情況。硬體配置情況與被測試產品類型密切相關，需要根據當時的情況，准確翔實的記錄硬體配置情況。
測試用例輸入 \ 操作步驟 \ 輸出： 這部分內容可以根據測試用例的描述和測試用例的實際執行情況如實填寫。
輸出設備的相關輸出信息： 輸出設備包括計算機顯示器、列印機、磁帶等等輸出設備，如果是顯示器可以採用抓屏的方式獲取當時的截圖，其他的輸出設備可以採用其它方法獲取相關的輸出，在問題報告單中提供描述。
日誌信息： 規范的軟體產品都會提供軟體的運行日誌和用戶、管理員的操作日誌，測試人員應該把測試用例執行後的軟體產品運行日誌和操作日誌作為附件，提交到問題報告單中。
根據被測試軟體產品的不同，需要在 「 問題描述 」 中增加相應的描述內容，這需要具體問題具體分析。
測試結果分析
軟體測試執行結束後，測試活動還沒有結束。測試結果分析是必不可少的重要環節， 「 編筐編簍，全在收口 」 ，測試結果的分析對下一輪測試工作的開展有很大的借鑒意義。前面的 「 測試准備工作 」 中，建議測試人員走讀缺陷跟蹤庫，查閱其他測試人員發現的軟體缺陷。測試結束後，也應該分析自己發現的軟體缺陷，對發現的缺陷分類，你會發現自己提交的問題只有固定的幾個類別；然後，再把一起完成測試執行工作的其他測試人員發現的問題也匯總起來，你會發現，你所提交問題的類別與他們有差異。這很正常，人的思維是有局限性，在測試的過程中，每個測試人員都有自己思考問題的盲區和測試執行的盲區，有效的自我分析和分析其他測試人員，你會發現自己的盲區，有針對性的分析盲區，必定會在下一輪測試用避免盲區。
總結：
限於文章的篇幅，本文不可能給出一個類似於 checklist 的指導性的軟體測試新手入門。無論從事軟體測試還是從事其它的工作，技術上的和技巧上的問題都可以通過查詢相關的軟體測試技術書籍獲取，掌握一套基本的方法論是最重要的。以上文字，都是作者從事軟體測試工作積累的經驗之談，如發現謬誤之處請不吝指出。
㈡ 軟體測試相關畢業論文（軟體測試在中外企業的應用特點和發展趨勢）
那好，給你分析的
㈢ 關於軟體測試的畢業論文要怎麼寫拜託各位大神
如何寫好測試計劃,測試用例，測試策略；如果進行自動化測試，功能測試，性能測試；如何通過測試提高軟體質量；某某項目測試如何開展等等
可細化到某一方向，任選一個，也可全流程覆蓋
㈣ 如何通過測試提高軟體質量和可靠性1500字論文
1、軟體測試相關概念 （1）軟體測試：軟體測試是為了發現錯誤而執行程序的過程。或者說，軟體測試是根據軟體開發各階段的規格說明和程序的內部結構而精心設計出一批測試用例，並利用這些測試用例的運行結果來發現程序錯誤的過程。 （2）軟體測試用例：測試用例實際上是對軟體運行過程中所有可能存在的目標、運動、行動、環境和結果的描述。測試用例是測試組織的最小單位，指對一項特定的軟體產品進行測試任務的描述，體現測試方案、方法、技術和策略。內容包括測試目標、測試環境、輸入數據、測試步驟、預期結果、測試腳本等，並最終形成文檔。 軟體測試的核心是設計和執行測試用例。而測試用例的選擇問題可以看作是從龐大的輸入狀態組合中，搜尋哪些可以發現錯誤的狀態組合。因此需要用抽象的手段來盡量使測試更加有效。 （3）測試用例庫：完整的單元測試很少只執行一個測試用例，開發人員通常都需要編寫多個測試用例才能對某一軟體功能進行比較完整的測試，這些相關的測試用例稱為一個測試用例集。將大量的測試用例收集到測試用例庫中，合理的分類後供測試人員選擇使用，能夠極大地提高軟體問題的發現率。 2、提高測試質量的方法 2.1 採用測試性設計技術 軟體測試是目前用來驗證軟體是否能夠完成所期望的功能的唯一有效的方法。但是在測試的實施過程中，由於種種原因導致測試的難度相當大，甚至出現了無法測試的情形。為了提高軟體的可測試性，我們在軟體設計時應當遵循測試性設計原則，通過改變設計或代碼、為軟體增加專門測試結構等方法來提高軟體的可測試性。 （1）測試驅動設計。這種設計就是直接把軟體需求變成測試代碼。在確定軟體測試性能要求的基礎上優先編寫測試代碼。先寫驗收測試，再寫單元測試，並在開發過程中不斷修正。 （2）每個操作對應一個方法，使方法小型化。使用小型化方法說明和重載帶預設方法參數的方法，使得測試中調用這些方法變的很容易。 （3）顯示與控制分離。把代碼移到GUI視圖的外面，各種GUI動作就能成了模型上的簡單方法調用。這樣，在修改程序功能不會影響視圖，同時通過方法調用測試功能也比間接地測試功能更容易。 （4）對於可能要作為參數的類，做一個介面。用介面說明外部程序組件或在需要時改變介面形成一個空類作為參數傳入。 2.2 選擇合適的測試管理模型 模型是系統功能的形式化或半形式化的表示，支持輸入狀態組合的系統枚舉。基於模型的測試主要考慮系統的功能，可以認為是功能測試的一種。測試模型體現了被測試系統的最本質的功能關系。而且要比系統本身更易於開發和分析。一個可測試的模型要能提供足夠的信息用來產生測試用例。所以可測試的模型必須滿足以下要求： （1）必須是某種測試實現的完全准確的反映，模型必須表示要檢查的所有特徵； （2）是對細節的抽象； （3）可以表示所有事件和所有的動作；⑷可以表示系統的各種狀態，以便由可知的方法來確定已達到或沒有達到什麼狀態。
㈤ 軟體測試技術論文2000字
軟體測試被定義為是以評價一個程序或者系統屬性為目標的任何一種活動,測試是對軟體質量的度量。下面我給大家分享軟體技術論文2000字，大家快來跟我一起欣賞吧。
軟體測試技術研究
摘 要：軟體測試是軟體工程范疇的一項重要工作，與軟體質量密切相關。本文就軟體測試的概念、分類和方法等幾個方面進行了論述。
關鍵詞：軟體測試;黑盒測試;白盒測試
中圖分類號：TP311.52
軟體測試是軟體生產過程中的一個重要環節，是伴隨著軟體的產生而發展的，它並不是不能正常運行的軟體的專利，而是為了發現所有軟體缺陷而執行程序的過程。軟體測試貫穿於軟體開發的到投入使用的各個過程中，不同階段的測試手段各不相同，測試成為軟體產品質量控制和管理的重要手段之一。大量資料表明，軟體測試的工作量占軟體開發總工作量的40%以上，測試成本也占總成本的30%―50%。
1 軟體測試的目標和重要性
1.1 軟體測試的定義
看待軟體測試的角度不同，軟體測試的定義也各不相同。總的說來，軟體測試就是利用測試工具按照預先設定好的方案和流程對產品進行功能和性能測試，甚至根據需要重新編寫測試代碼，對測試過程中可能出現的問題進行分析和評估。它是幫助識別開發完成的計算機軟體的正確度、完全度和質量的軟體過程，是保證軟體質量的重要內容。
1.2 軟體測試的目標
軟體測試的正確定義是“為了發現程序中的錯誤而執行程序的過程”。而測試的目的決定了如何去組織測試。測試的目標是什麼?G.Myers曾給出了關於測試的一些規則，這些規則可以看作是軟體測試的目標：
(1)軟體測試並不是為了驗證軟體的正確性，而是為了發現錯誤而執行程序的過程。(2)好的測試方案是盡可能發現目前尚未發現的錯誤的測試方案。(3)成功有效的測試是發現了至今尚未發現的錯誤的測試。從以上規則可以看出，測試是以查找錯誤為中心，和人們通常想像的“測試是為了驗證程序的正確功能”，“成功的測試是沒有發現錯誤的測試”等是完全相反的。所以，近年來，正確軟體測試目標如下：(1)軟體測試並不僅僅是為了查找出軟體的錯誤，而是要通過進一步分析錯誤產生的原因和錯誤的發展趨勢，發現一些可以通過測試避免的開發風險;(2)通過測試能夠幫助測試人員設計出適合該軟體更加有效的測試方法，進一步提高測試效率，縮短測試實踐，降低測試費用;(3)結果完全正確的測試也是有價值的，是軟體質量的一種評價，但並不是測試正確就說明該軟體沒有錯誤，隨著使用的深入，功能的擴充等會逐步暴露出更多的問題，實踐證明，完全沒有錯誤的軟體世間難求。
1.3 軟體測試主要包括
(1)正確性和精確性測試：如果軟體的運行結果不正確和不精確，那麼會給用戶帶來很大的麻煩，甚至造成不可估量的損失，因此是保證軟體質量的最重要因素。(2)容錯性測試：容錯性測試是在認可錯誤的情況下進行的測試，是檢查軟體在異常條件運行，是否具有防護性和能否自我恢復。容錯性測試能確保系統不發生無法意料的事故，從而提高軟體的安全性和可靠性。(3)性能與效率測試：用戶都希望軟體的運行速度更高一些，並且佔用的資源更少些，性能與效率測試主要是優化軟體的演算法，數據結構和代碼組織來提高軟體的性能和效率。(4)易用性測試：易用性測試是測試軟體的易用程度，就像一個常用扳手工具，拿到就能明白怎麼去使用，因此易用性測試沒有一個量化的指標，主觀性較強。在平時使用中，當用戶不能正確使用軟體中的某個功能時，大多數人首先會通過各種方式學習、請教，或者向產品支持部門打電話，還有一部分用戶會查閱用戶手冊。通常認為，用戶不通過翻閱用戶手冊就能使用的軟體易用性較好。(5)文檔測試：文檔測試主要檢查文檔的正確性、完備性和可理解性。
1.4 軟體測試的基本原則
(1)盡早並不斷地進行軟體測試;(2)程序員或程序設計機構避免測試自己的軟體;(3)測試前應當設置合理的測試用例，測試用例的設計不僅要有合法的測試數據，也要有非法的測試數據;(4)對程序修改之後要進行回歸測試;(5)妥善保留測試計劃、嚴格按照計劃測試，排除測試的隨意性，全部測試用例、出錯統計和最終分析報告，並對每一個測試結果做全面檢查。
1.5 軟體測試的地位
軟體的開發過程包括需求分析、設計、實現和測試四個階段。軟體測試在軟體生命周期中占重要地位，是軟體交付用戶使用前保證軟體質量的重要手段。在系統發布之前，從客戶的需求出發，盡早發現問題，修改的成本越低，破壞性也越小。一旦系統投產後發現問題，其危害性被成倍放大，甚至會給雙方造成不可估量的損失。
2 軟體測試方法
按照不同的分類方法，軟體測試可以分為多種類型。
2.1 從是否需要執行被測試軟體的角度分類
靜態測試：是指不需要實際運行軟體，主要對軟體的編程格式、程序邏輯結構等方面進行測試。靜態測試是通過對源程序進行語法檢查，靜態結構分析、代碼質量等方面找出缺陷和可疑之處，例如變數定義和生命周期檢查、模塊介面的正確性、是否允許遞歸、程序邏輯和結構審查等。
動態測試：通常的上機運行軟體而進行的測試，這種方法是使程序有控制地運行，並從多種角度觀察程序的行為，以發現其中的錯誤。在軟體維護階段，當修改軟體後，除了對修改部分的軟體進行常規的測試外，還應對軟體的其他部分進行回歸測試，所謂回歸測試是指全部或部分地重復已做過的測試，它主要檢查軟體的修改是否在軟體的未修改部分引入了新的錯誤。
2.2 從是否針對軟體結構與演算法的角度分為
白盒測試，主要是對軟體的邏輯結構進行的測試。白盒測試要求測試人員對程序內部邏輯結構及有關信息來設計和選擇測試用例，對程序的邏輯路徑進行測試，不需測試軟體產品的功能。測試過程是基於覆蓋全部代碼、分支、路徑和條件。白盒測試是指在知道產品內部工作過程，通過設置測試用例來檢測產品內部動作是否按照規格說明書的規定正確進行，檢驗程序是否都能按預定要求正確工作，而不顧它的功能，白盒測試的主要方法有邏輯覆蓋、基本路徑測試等。
黑盒測試：指測試來檢測每個功能是否可以正常使用。執行嚴格的測試，通過對整個軟體或某些軟體功能，但不檢查程序的源代碼還是非常清楚的了解該軟體的源代碼程序具體如何設計。通過輸入測試數據，並通過分析的結果輸出到測試人員了解軟體是如何工作的。在測試中，主要的功能是用來檢查是否正確的程序或缺少的功能，用戶界面是正確的，錯誤的數據結構或外部資料庫訪問錯誤，性能是正確與否，程序是否有初始化和終止錯誤的存在。
2.3 從測試的不同階段分類
單元測試：指的是對每一個工作單元進行測試，了解其運行結果是否符合我們的預期。它對測試人員的要求比較高，要求測試人員對程序代碼比較熟悉;一般由程序員自己編完某個單元後，先自我檢查通過後，再將測試代碼交給測試人員進行審核，如果發現缺陷，原開發者應當及時修正程序，這樣可以盡快的發現程序中存在的錯誤，及時修正以提高程序開發的效率。
集成測試：是在單元測試的基礎上，測試再將所有的軟體單元按照概要設計規格說明的要求組裝成模塊、子系統或系統的過程中各部分工作是否達到或實現相應技術指標及要求的活動。也就是說，在集成測試之前，單元測試已經完成，集成測試中所使用的對象，已經是經過單元測試的軟體單元。
系統測試：是將已經確認的計算機軟體和硬體設備、網路和外圍設備等元素組合在一起，對已經集成好的系統進行測試，找出所開發的系統與用戶需求不符或矛盾的地方，從而提出更加完善的方案.它的任務是盡可能徹底地檢查出程序中的錯誤，提高軟體系統的可靠性。
驗收測試：也稱為交付測試，完成了功能和系統測試後、產品發布之前所進行的測試活動，它是技術測試的最後一個階段。
總之，隨著軟體開發和測試技術的不斷發展，測試方法也越來越多樣化，針對性更強;選擇合適的軟體測試方法可以讓我們事半功倍。
參考文獻：
[1]張永梅.軟體測試技術研究[J].測試技術學報，2002，6.
[2]劉繼華.軟體測試技術的研究進展[J].微計算機信息，2012，10.
[3]瞿莉麗.淺析軟體測試技術[J].矽谷，2010，4.
點擊下頁還有更多>>>軟體技術論文2000字