⑴ 作為軟體測試人員該怎麼做
在我看來一個軟體測試人員需要具備多方面的特質：
● 細心：這個不用多解釋了吧。粗枝大葉的人是沒法做好軟體測試的。
●
耐心：軟體測試，特別是當前國內主流的手動黑盒功能測試。基本上測試的工作就是一項重復勞動，需要有一定的耐心來保證不在枯燥的重復勞動中放過那些細小的缺陷。
● 好奇心：軟體測試，是需要保持一顆好奇心的工作。好奇心使得測試人員會多問一個「為什麼」，「如果這樣，行不行?」。往往這些問題會引導你找到缺陷。
● 會溝通：軟體測試人員需要與客戶，開發，產品等方方面面保持密切的關系，溝通很重要。良好的溝通過程可以有效地控製成本。
● 總結歸納能力：這跟「會溝通」有關聯，軟體測試人員需要找到缺陷的真正關鍵步驟，歸納出缺陷產生的一般規律，總結出一份詳盡的測試報告。
● 理解能力：對需求的准確理解，是軟體測試人員需要具備的必需條件。
● 表達能力：編寫的測試用例什麼的只有你自己能讀懂可不行。
●
時間觀念：軟體測試工作是無止境的，但是軟體本身是有交付日期的。軟體測試工作需要在保證交付日期之前完成工作，保證軟體產出的質量。時間與質量本身需要有一個平衡，為了追求零缺陷而罔顧交付日期的做法是不科學的。前期的制定計劃開始，就要對整個過程有一個良好的規劃並且按照這個計劃的日期來推進。
好吧，以上這些差不多是我想到的對與軟體測試人員來說比較重要的特質。當然，還有一些不一定是普適的要求，比如英語聽說讀寫的能力。也歡迎補充看看我還遺漏了那些特質。
朱杉： 其實抽屜同學已經都總結得很好了，我就再說兩點我自己的體會就好。
●
責任感：責任感是個系數，責任感與個人資質的乘積才是最終體現到工作中的實際能力。尤其是就目前國內的黑盒手工測試來說，極少有需要特別牛x的人才能幹得下來的事情，大家的工作成果差異，常常是態度問題而非能力問題。而很多面試中體現出良好資質的人，放到工作中會發現實際效果不理想，也多與此有關。
● 原則性：測試需要一顆有原則的正直的心，不會為了湊數量，將同類問題的變體重復提交;不會因為dev簡單的一句：」這不是問題「而妥協。
●
學習能力：測試需要不斷接觸新功能、新理論、新技術、新工具，並非一個省心的活兒。對於學習能力還是有一定的要求的。除了工作相關的以外，開闊的知識面，對於測試人員來說有時也意味著思路的可延展性。
就這些啦。其實有些能力是可以在做的過程中培養的，而做測試的過程也是對心性的一種歷練
⑵ 怎樣做好功能測試
細心，耐心，責任心等。是做好軟體測試的基本要求
一、分析能力，軟體測試考研測試人員的是對功能的分析和總結能力，對於一項測試首先要了解該項目，對業務領悟能力要強
二、全局能力，為何這么說呢？軟體測試現在基本都是在項目一開始就介入，為何，我相信很多人比我都清楚，因為早介入能早發現問題，但是確實是不是真的能早發現問題呢？還是需要我們從全局去考慮到，需求分析工程師，架構師，開發都是人，是人就會有考慮不全的地方，所以對於測試來說，能夠有「眾人皆醉我獨醒」的心態和全局觀是非常重要的，而且這往往也能體現測試人員在相關部門的價值和可信度
三、溝通能力，作為一個功能測試人員要學會更好的溝通，良好的溝通能力能夠幫助我們更好的做好測試工作
四、測試專業技術，想做好的測試首先得了解測試，具有一定得測試基礎。在工作中不斷地進行學習，並且不斷培養自己的良好邏輯思維。很多東西我們可以不會，但是要做好測試得會學習
⑶ 如何讓做好軟體功能測試，哪位大俠給個大體思路
你好！
軟體功能測試其實是最簡單的測試，但是也是最多用到的測試，做法簡單，但是想法要多，給你一個最簡單的辦法，比如你在測試一個任務流程
1到2在到3
你就設計一個想法，讓1到2用最基本的做法，讓他保持正確，然後在3這個點上使勁扣，能先到什麼就的方法都測，然後你在設計2到3為正常，使勁測1這個點
，這樣簡單還不容易遺漏東西
我的回答你還滿意嗎~~
⑷ 一個菜鳥怎樣做好功能測試
1. 首先學習軟體測試基本知識和軟體流程。功能測試最開始最基礎的就是分析需求編寫測試用例，測試是把握質量的守關人，保證不漏測的第一步就是要編寫盡可能全面的測試用例。可以學慣用例編寫方法、黑盒測試方法，閱讀一些書籍，比如：軟體測試藝術；此外，了解軟體流程也很重要，根據迭代所處階段測試可以做不同的事情，需求宣講階段制定測試計劃、分析需求編寫測試用例；開發階段了解實現技術細節准備開發自測用例；提測後按用例測試，每天拋出風險和進度，根據執行質量考慮是否測試多輪，根據質量判斷是非可以上線發布；上線後及時根據運營問題；
2. 基礎打牢後多實踐。測試是講究經驗的職業，從簡單需求開始，制定測試計劃，編寫用例執行，執行過程及時調整計劃爆出風險和進度給團隊知道非常重要。從簡單需求到復雜需求到迭代跟進，除了執行，技術了解和bug跟進分析很重要，了解技術實現可以幫助你設計更全面的用例，更好評估功能質量風險；bug分析也是，往往一個經典的bug分析出來會發現更多隱蔽問題；功能測試完成建議編寫測試總結，對測試方案、邏輯實現、發現問題和自己分析過程進行整理；
3. 進行下去後會更加深入了解被測對象，從而可以做更多深入測試。比如穩定性測試，性能專項測試，介面測試等；團隊合作下去可能會發現一些流程上的問題，可以思考如何優化流程讓合作更高效，以及沉澱文檔和規則；迭代跟進後會有一些質量效率問題，需要思考如何優化：自動化、精準測試、重復工作腳本化、工具化；根據每個迭代總結和測試數據分析也需要思考哪些數據待提高：漏測情況、bug發現情況；用戶反饋問題多了，可以思考如何專題解決、如何快速定位……將這些工作完成並記錄沉澱下來形成方法論，多做分享擴大自己影響面；
4. 團隊擴展後就需要思考如何培養新人，如何開展團隊工作，幫助大家一起進步、高效工作；
項目支持是基本，在這基礎上多發現問題多實踐多思考，擴大自己影響。
⑸ 如何做好軟體測試工作
測試和開發一個很大的不同就是，開發要求對某個點有很深入的研究，對於測試來說，更多的是廣度方面的提升。拿互聯網測試人員來說，有些知識是必須的，比如說最基本的cookie／cache／session，還有SEO，網站上的廣告植入等等，並不一定說你要各個點都要精通，最起碼你要有基本的了解。
還有就是domain knowledge了。我們最近招了很多新人，人員流動也比較大，這個時候往往就會有很大的risk，這個時候其實對於測試人員來說，是一個挑戰，也是一個機遇。挑戰的是，怎樣確保新人做的東西，不會破壞以前的功能。與此同時，這也是你展示測試的重要性的一個機遇。
其實任何職業的人，一般都會有危機感，其實這也是一件好事，說明你是積極向上的。不管測試也罷，其他職業也罷，把事情做到極致，是很重要的一個職業素養。我覺得我做的很成功的一個點，就是產品經理任何時候，在proction上發現了一個問題，都會讓我去做一下investigation。這個時候，其實我們能做的事很多，簡單的處理就是，告訴他這是個bug，然後註明bug讓開發去研究解決。而我，會做的稍微多一點，比如說把原始的feature ticket是怎樣的貼上去，可能的原因會是什麼，怎樣能夠復現等等。時間久了，就會贏得別人對你的尊重。
⑹ 怎樣做好軟體測試
作為一個軟體測試工程師，首先，你要建立自己的測試思維，這個很重要，因為測試思維相當於你的軟體的世界觀，這也就是為什麼，個人不支持從 開發轉測試的原因，因為對於開發而言，他們是目標型的世界觀，即需求要完成什麼我去完成，如果你在開發中待的時間太長，容易習慣這樣目標型世界觀，而測試更多關注的是多方面的，有時候，就是一些在開發所謂的不可能、無所謂的東西最後造成軟體的失敗，而如何建立自己的軟體世界觀，那就要去通過測試的方法論的理解，很多人喜歡把黑盒測試方法論、白盒測試方法論，分得很清楚，其實兩者是相通的，看懂這些東西很快的，但是悟透，這個過程會漫長。
接下來 我們講講你需要作為一個初級功能工程師所需要基本素質吧
1、軟體測試的基本方法（邊界值、等價類、錯誤分類、流程分析等等黑盒、白盒測試方法要有了解，並且掌握）這個不難，但請務必牢記在心中，它是你去建立自己世界觀的基礎，所有的測試逃不出這些方法
2、會寫的基礎的測試文檔（測試用例、缺陷報告等）
3、會看開發文檔（需求說明書、操作手冊）
4、知道軟體工程中，測試所需要做的事情，了解性能測試、安全測試等
當你有了基礎，同時也有了自己的世界觀，祝賀你已經入門了，這個時候，我建議你可以去了解不同軟體開發不同環節人所作的事情，不單單是開發，需求、設計、運維等等，因為這樣你會知道什麼是體系、規范，為你以後的發展有著很好的幫助，這也是測試相對於開發優勢的地方，開發更關注的是點，而測試要關注的是面，所以對於測試而言，除了准確的抓住細節的同時，大局觀要好，否則做不好測試。
最後才是細節技術就是所謂的白盒測試、性能測試、自動化、安全等等，這些其實對測試而言反而是小節，技術永遠不會阻礙你前行的腳步，反而思維，這個你可以根據自己喜好去發展，沒有固定模式
順便說一句，別看不起基礎的功能測試，它沒外人看得那麼簡單，因為如果你連測試用例都不會設計就別去說做性能測試、自動化測試、安全測試等等，要做一好的功能測試工程師，寫的一手好用例（你的用例是個識字人都能執行、並且用例有效的系統覆蓋率也是很高的）、好缺陷（是個識字的人都能理解你說的是問題，並且抓住重點），很難的，真心不是普通人能做好的，要去花心思琢磨的。
⑺ 怎樣做好軟體測試
首先我們需要了解軟體的測試要求，同時學會如何更好的學習。更為詳細：
1.需要技術知識和深奧的分析能力創建極其復雜的測試。每個軟體都有不同的特性。我們需要依靠專業的技術知識和深奧的分析能力去解決復雜的軟體運算問題。並做好測試。
簡而言之。做好軟體測試並不是那麼容易，需要有專業的技術，也需要足夠強的分析能力，還要有強學習能力去解決問題。同時還要懂得如何打破常規。才能更好的做好軟體測試。
⑻ 軟體功能測試流程
1、測試計劃：測試計劃一般由測試經理編寫，根據需求估算測試所需資源（人力，設備等）、所需時間、功能點劃分、如何合理分配安排資源。
2、用例設計：根據測試計劃，修改好的需求分析文檔開始寫測試用例，同時開發人員完成概要設計文檔和詳細設計文檔。測試人員根據這兩份文檔補充測試用例。
3、測試環境：測試人員搭建測試環境。
4、執行測試：開發人員提交第一個版本，如果存在未完成的功能，開發需跟測試人員說明，然後測試人員根據測試用例的詳細步驟，執行測試用例，發現BUG提交缺陷庫。
5、BUG跟蹤：開發人員提交第二個版本，包括修改的BUG以及增加的部分功能，測試人員進行第二輪測試和回歸測試，跟蹤BUG直到關閉。
6、測試報告：通過不斷測試，BUG跟蹤，直到用例全部測試，覆蓋率、缺陷率以及其他各項指標達到質量標准，即達到上線要求。
(8)怎樣做好一個軟體的人工功能測試擴展閱讀：
功能測試根據產品特性、操作描述和用戶方案，測試一個產品的特性和可操作行為以確定它們滿足設計需求。本地化軟體的功能測試，用於驗證應用程序或網站對目標用戶能正確工作。使用適當的平台、瀏覽器和測試腳本，以保證目標用戶的體驗將足夠好。
功能測試是為了確保程序以期望的方式運行而按功能要求對軟體進行的測試，通過對一個系統的所有的特性和功能都進行測試確保符合需求和規范。只需考慮需要測試的各個功能，不需要考慮整個軟體的內部結構及代碼。
⑼ 如何進行軟體測試
測試方法很多，白盒，黑盒和灰盒，最初級的是黑盒測試，也稱功能測試，也就是根據需求、原型和效果圖和所做的系統進行對比，將需求不明的同項目經理確認，超出需求以外的或需求上的功能有的沒有實現的話，可以記錄，然後重現以便開發人員更改這些問題，這個是很多中小型企業比較關心的，性能、壓力、兼容性對手機客戶端的開發較為重要，這些你可以自己問問度娘，我就不一一列舉了，白盒測試，就是對代碼進行修改，以完善功能的實現，灰盒就是白盒加黑盒，此外，現在很多公司還注重自動化測試，這個就要看你使用的自動化測試工具的不同而言了，比如loadrunnner，他是腳本的錄制與回放，monkey是性能測試，這個學習工程是較為龐大的，要想學好軟體測試。
⑽ 軟體測試的方法有哪些
一下來自網路相當全面的資料。或者你可以看看51testing測試論壇，上面很多資料都是免費下載的。
β測試_Beta測試 β測試，英文是Beta testing。又稱Beta測試，用戶驗收測試（UAT）。 β測試是軟體的多個用戶在一個或多個用戶的實際使用環境下進行的測試。開發者通常不在測試現場，Beta測試不能由程序員或測試員完成。 當開發和測試根本完成時所做的測試，而最終的錯誤和問題需要在最終發行前找到。這種測試一般由最終用戶或其他人員員完成，不能由程序員或測試員完成。 α測試_Alpha測試 α測試，英文是Alpha testing。又稱Alpha測試. Alpha測試是由一個用戶在開發環境下進行的測試，也可以是公司內部的用戶在模擬實際操作環境下進行的受控測試，Alpha測試不能由該系統的程序員或測試員完成。 在系統開發接近完成時對應用系統的測試;測試後，仍然會有少量的設計變更。這種測試一般由最終用戶或其他人員來完成，不能由程序員或測試員完成。 可移植性測試 可移植性測試，英文是Portability testing。又稱兼容性測試。 可移植性測試是指測試軟體是否可以被成功移植到指定的硬體或軟體平台上。 用戶界面測試-UI測試 用戶界面測試，英文是User interface testing。又稱UI測試。 用戶界面，英文是User interface。是指軟體中的可見外觀及其底層與用戶交互的部分（菜單、對話框、窗口和其它控制項）。 用戶界面測試是指測試用戶界面的風格是否滿足客戶要求，文字是否正確，頁面是否美觀，文字，圖片組合是否完美，操作是否友好等等。UI 測試的目標是確保用戶界面會通過測試對象的功能來為用戶提供相應的訪問或瀏覽功能。確保用戶界面符合公司或行業的標准。包括用戶友好性、人性化、易操作性測試。 用戶界面測試用戶分析軟體用戶界面的設計是否合乎用戶期望或要求。它常常包括菜單，對話框及對話框上所有按鈕，文字，出錯提示，幫助信息 (Menu 和Help content)等方面的測試。比如，測試Microsoft Excel中插入符號功能所用的對話框的大小，所有按鈕是否對齊，字元串字體大小，出錯信息內容和字體大小，工具欄位置/圖標等等。 冒煙測試 冒煙測試，英文是Smoke testing。 冒煙測試的名稱可以理解為該種測試耗時短，僅用一袋煙功夫足夠了。也有人認為是形象地類比新電路板功基本功能檢查。任何新電路板焊好後，先通電檢查，如果存在設計缺陷，電路板可能會短路，板子冒煙了。 冒煙測試的對象是每一個新編譯的需要正式測試的軟體版本，目的是確認軟體基本功能正常，可以進行後續的正式測試工作。冒煙測試的執行者是版本編譯人員。 隨機測試 隨機測試，英文是Ad hoc testing。 隨機測試沒有書面測試用例、記錄期望結果、檢查列表、腳本或指令的測試。主要是根據測試者的經驗對軟體進行功能和性能抽查。隨機測試是根據測試說明書執行用例測試的重要補充手段，是保證測試覆蓋完整性的有效方式和過程。 隨機測試主要是對被測軟體的一些重要功能進行復測，也包括測試那些當前的測試樣例(TestCase)沒有覆蓋到的部分。另外，對於軟體更新和新增加的功能要重點測試。重點對一些特殊點情況點、特殊的使用環境、並發性、進行檢查。尤其對以前測試發現的重大Bug，進行再次測試，可以結合回歸測試 (Regressive testing)一起進行。 本地化測試 本地化測試，英文是Localization testing。 本地化就是將軟體版本語言進行更改，比如將英文的windows改成中文的windows就是本地化。本地化測試的對象是軟體的本地化版本。本地化測試的目的是測試特定目標區域設置的軟體本地化質量。本地化測試的環境是在本地化的操作系統上安裝本地化的軟體。從測試方法上可以分為基本功能測試，安裝/卸載測試，當地區域的軟硬體兼容性測試。測試的內容主要包括軟體本地化後的界面布局和軟體翻譯的語言質量，包含軟體、文檔和聯機幫助等部分。 本地化能力測試 本地化能力測試，英文是Localizability testing。 本地化能力測試是指不需要重新設計或修改代碼，將程序的用戶界面翻譯成任何目標語言的能力。為了降低本地化能力測試的成本，提高測試效率，本地化能力側是通常在軟體的偽本地化版本上進行。 本地化能力測試中發現的典型錯誤包括：字元的硬編碼（即軟體中需要本地化的字元寫在了代碼內部），對需要本地化的字元長度設置了國定值，在軟體運行時以控制項位置定位，圖標和點陣圖中包含了需要本地化的文本，軟體的用戶界面與文檔術語不一致等。 國際化測試 國際化測試，英文是International testing。又稱國際化支持測試。 國際化測試的目的是測試軟體的國際化支持能力，發現軟體的國際化的潛在問題，保證軟體在世界不同區域都能正常運行。國際化測試使用每種可能的國際輸入類型，針對任何區域性或區域設置檢查產品的功能是否正常，軟體國際化測試的重點在於執行國際字元串的輸入/輸出功能。國際化測試數據必須包含東亞語言、德語、復雜腳本字元和英語（可選）的混合字元。 國際化支持測試是指驗證軟體程序在不同國家或區域的平台上也能夠如預期的那樣運行，而且還可以按照原設計尊重和支持使用當地常用的日期，字體，文字表示，特殊格式等等。比如，用英文版的 Windows XP 和 Microsoft Word 能否展示阿拉伯字元串?用阿拉伯版的 Windows XP 和 阿拉伯版的Microsoft Word 能否展示阿拉伯字元串?又比如，日文版的Microsoft Excel對話框是否顯示正確翻譯的日語?一旦來說執行國際化支持測試的測試人員往往需要基本上了解這些國家或地區的語言要求和期望行為是什麼。 安裝測試 安裝測試，英文是Installing testing。 安裝測試是確保軟體在正常情況和異常情況下，例如，進行首次安裝、升級、完整的或自定義的安裝都能進行安裝的測試。異常情況包括磁碟空間不足、缺少目錄創建許可權等場景。核實軟體在安裝後可立即正常運行。安裝測試包括測試安裝代碼以及安裝手冊。安裝手冊提供如何進行安裝，安裝代碼提供安裝一些程序能夠運行的基礎數據。 白盒測試-結構測試-邏輯驅動測試 白盒測試，英文是White Box Testing。又稱結構測試或者邏輯驅動測試。 白盒測試是把測試對象看作一個打開的盒子。利用白盒測試法進行動態測試時，需要測試軟體產品的內部結構和處理過程，不需測試軟體產品的功能。 白盒測試法的覆蓋標准有邏輯覆蓋、循環覆蓋和基本路徑測試。其中邏輯覆蓋包括語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、條件組合覆蓋和路徑覆蓋。 白盒測試是知道產品內部工作過程，可通過測試來檢測產品內部動作是否按照規格說明書的規定正常進行，按照程序內部的結構測試程序，檢驗程序中的每條通路是否都有能按預定要求正確工作，而不顧它的功能，白盒測試的主要方法有邏輯驅動、基路測試等，主要用於軟體驗證。 白盒測試常用工具有：Jtest、VcSmith、Jcontract、C++ Test、CodeWizard、logiscope。 黑盒測試-功能測試-數據驅動測試 黑盒測試，英文是Black Box Testing。又稱功能測試或者數據驅動測試。 黑盒測試是根據軟體的規格對軟體進行的測試，這類測試不考慮軟體內部的運作原理，因此軟體對用戶來說就像一個黑盒子。 軟體測試人員以用戶的角度，通過各種輸入和觀察軟體的各種輸出結果來發現軟體存在的缺陷，而不關心程序具體如何實現的一種軟體測試方法。 黑盒測試常用工具有：AutoRunner、winrunner、loadrunner。 自動化測試 自動化測試，英文是Automated Testing。 使用自動化測試工具來進行測試，這類測試一般不需要人干預，通常在GUI、性能等測試和功能測試中用得較多。通過錄制測試腳本，然後執行這個測試腳本來實現測試過程的自動化。國內領先的自動化測試服務提供商是澤眾軟體。自動化測試工具有AutoRunner和TAR等。 回歸測試 回歸測試，英文是Regression testing。 回歸測試是指在發生修改之後重新測試先前的測試以保證修改的正確性。理論上，軟體產生新版本，都需要進行回歸測試，驗證以前發現和修復的錯誤是否在新軟體版本上再次出現。 根據修復好了的缺陷再重新進行測試。回歸測試的目的在於驗證以前出現過但已經修復好的缺陷不再重新出現。一般指對某已知修正的缺陷再次圍繞它原來出現時的步驟重新測試。通常確定所需的再測試的范圍時是比較困難的，特別當臨近產品發布日期時。因為為了修正某缺陷時必需更改源代碼，因而就有可能影響這部分源代碼所控制的功能。所以在驗證修好的缺陷時不僅要服從缺陷原來出現時的步驟重新測試，而且還要測試有可能受影響的所有功能。因此應當鼓勵對所有回歸測試用例進行自動化測試。 驗收測試 驗收測試，英文是Acceptance testing。 驗收測試是指系統開發生命周期方法論的一個階段，這時相關的用戶或獨立測試人員根據測試計劃和結果對系統進行測試和接收。它讓系統用戶決定是否接收系統。它是一項確定產品是否能夠滿足合同或用戶所規定需求的測試。 驗收測試一般有三種策略：正式驗收、非正式驗收活Alpha 測試、Beta 測試。 動態測試 動態測試，英文是Moment Testing。 動態測試是指通過運行軟體來檢驗軟體的動態行為和運行結果的正確性。 根據動態測試在軟體開發過程中所處的階段和作用，動態測試可分為如下幾個步驟： 1、單元測試 2、集成測試 3、系統測試 4、驗收測試 5、回歸測試 探索測試 探索測試，英文是Exploratory Testing。 探索測試是指通常用於沒有產品說明書的測試，這需要把軟體當作產品說明書來看待，分步驟逐項探索軟體特性，記錄軟體執行情況，詳細描述功能，綜合利用靜態和動態技術來進行測試。探索測試人員只靠智能、洞察力和經驗來對bug的位置進行判斷,所以探索測試又被稱為自由形式測試。 單元測試 單元測試，英文是Unit Testing。 單元測試是最微小規模的測試;以測試某個功能或代碼塊。典型地由程序員而非測試員來做，因為它需要知道內部程序設計和編碼的細節知識。這個工作不容易做好，除非應用系統有一個設計很好的體系結構; 還可能需要開發測試驅動器模塊或測試套具。 集成測試 集成測試，英文是Integration Testing。 集成測試是指一個應用系統的各個部件的聯合測試，以決定他們能否在一起共同工作並沒有沖突。部件可以是代碼塊、獨立的應用、網路上的客戶端或伺服器端程序。這種類型的測試尤其與客戶伺服器和分布式系統有關。一般集成測試以前，單元測試需要完成。 集成測試是單元測試的邏輯擴展。它的最簡單的形式是：兩個已經測試過的單元組合成一個組件，並且測試它們之間的介面。從這一層意義上講，組件是指多個單元的集成聚合。在現實方案中，許多單元組合成組件，而這些組件又聚合成程序的更大部分。方法是測試片段的組合，並最終擴展進程，將您的模塊與其他組的模塊一起測試。最後，將構成進程的所有模塊一起測試。此外，如果程序由多個進程組成，應該成對測試它們，而不是同時測試所有進程。 集成測試識別組合單元時出現的問題。通過使用要求在組合單元前測試每個單元，並確保每個單元的生存能力的測試計劃，可以知道在組合單元時所發現的任何錯誤很可能與單元之間的介面有關。這種方法將可能發生的情況數量減少到更簡單的分析級別 系統測試 系統測試，英文是System Testing。 系統測試是基於系統整體需求說明書的黑盒類測試，應覆蓋系統所有聯合的部件。系統測試是針對整個產品系統進行的測試，目的是驗證系統是否滿足了需求規格的定義，找出與需求規格不相符合或與之矛盾的地方。 系統測試的對象不僅僅包括需要測試的產品系統的軟體，還要包含軟體所依賴的硬體、外設甚至包括某些數據、某些支持軟體及其介面等。因此，必須將系統中的軟體與各種依賴的資源結合起來，在系統實際運行環境下來進行測試。 端到端測試 端到端測試，英文是End to End Testing。 端到端測試類似於系統測試，測試級的「宏大」的端點，涉及整個應用系統環境在一個現實世界使用時的模擬情形的所有測試。例如與資料庫對話，用網路通訊，或與外部硬體、應用系統或適當的系統對話。端到端架構測試包含所有訪問點的功能測試及性能測試。端到端架構測試實質上是一種"灰盒"測試，一種集合了白盒測試和黑盒測試的優點的測試方法。 健全測試 健全測試，英文是Sanity testing。 健全測試是指一個初始化的測試工作，以決定一個新的軟體版本測試是否足以執行下一步大的測試努力。例如，如果一個新版軟體每5分鍾與系統沖突，使系統陷於泥潭，說明該軟體不夠「健全」，目前不具備進一步測試的條件。 衰竭測試 衰竭測試，英文是Failure Testing。 衰竭測試是指軟體或環境的修復或更正後的「再測試」。可能很難確定需要多少遍再次測試。尤其在接近開發周期結束時。自動測試工具對這類測試尤其有用。 接受測試 接受測試，英文是Accept Testing。 接受測試是基於客戶或最終用戶的規格書的最終測試，或基於用戶一段時間的使用後，看軟體是否滿足客戶要求。一般從功能、用戶界面、性能、業務關聯性進行測試。 負載測試 負載測試，英文是Load testing。 負載測試是測試一個應用在重負荷下的表現。例如測試一個 Web 站點在大量的負荷下，何時系統的響應會退化或失敗，以發現設計上的錯誤或驗證系統的負載能力。在這種測試中，將使測試對象承擔不同的工作量，以評測和評估測試對象在不同工作量條件下的性能行為，以及持續正常運行的能力。 負載測試的目標是確定並確保系統在超出最大預期工作量的情況下仍能正常運行。此外，負載測試還要評估性能特徵，例如，響應時間、事務處理速率和其他與時間相關的方面。 強迫測試 強迫測試，英文是Force Testing。 強迫測試是在交替進行負荷和性能測試時常用的術語。也用於描述象在異乎尋常的重載下的系統功能測試之類的測試，如某個動作或輸入大量的重復，大量數據的輸入，對一個資料庫系統大量的復雜查詢等。 壓力測試 壓力測試，英文是Stress Testing。和負載測試差不多。 壓力測試是一種基本的質量保證行為，它是每個重要軟體測試工作的一部分。壓力測試的基本思路很簡單：不是在常規條件下運行手動或自動測試，而是在計算機數量較少或系統資源匱乏的條件下運行測試。通常要進行壓力測試的資源包括內部內存、CPU 可用性、磁碟空間和網路帶寬等。一般用並發來做壓力測試。 性能測試 性能測試，英文是Performance Testing。 性能測試是在交替進行負荷和強迫測試時常用的術語。理想的「性能測試」(和其他類型的測試)應在需求文檔或質量保證、測試計劃中定義。性能測試一般包括負載測試和壓力測試。 通常驗證軟體的性能在正常環境和系統條件下重復使用是否還能滿足性能指標。或者執行同樣任務時新版本不比舊版本慢。一般還檢查系統記憶容量在運行程序時會不會流失(memory leak)。比如，驗證程序保存一個巨大的文件新版本不比舊版本慢。 可用性測試 可用性測試，英文是Practical Usability Testing。 可用性測試是對「用戶友好性」的測試。顯然這是主觀的，且將取決於目標最終用戶或客戶。用戶面談、調查、用戶對話的錄象和其他一些技術都可使用。程序員和測試員通常都不宜作可用性測試員。 卸載測試 卸載測試，英文是Uninstall Testing。 卸載測試是對軟體的全部、部分或升級卸載處理過程的測試。主要是測試軟體能否卸載，卸載是否干凈，對系統有無更改，在系統中的殘留與後來的生成文件如何處理等。還有原來更改的系統值是否修改回去 恢復測試 恢復測試，英文是Recovery testing。 恢復測試是測試一個系統從如下災難中能否很好地恢復，如遇到系統崩潰、硬體損壞或其他災難性問題。恢復測試指通過人為的讓軟體（或者硬體）出現故障來檢測系統是否能正確的恢復，通常關注恢復所需的時間以及恢復的程度。 恢復測試主要檢查系統的容錯能力。當系統出錯時，能否在指定時間間隔內修正錯誤並重新啟動系統。恢復測試首先要採用各種辦法強迫系統失敗，然後驗證系統是否能盡快恢復。對於自動恢復需驗證重新初始化（reinitialization）、檢查點(checkpointing mechanisms)、數據恢復(data recovery)和重新啟動 (restart)等機制的正確性；對於人工干預的恢復系統，還需估測平均修復時間，確定其是否在可接受的范圍內。 安全測試 安全測試，英文是Security Testing。 安全測試是測試系統在防止非授權的內部或外部用戶的訪問或故意破壞等情況時怎麼樣。這可能需要復雜的測試技術。安全測試檢查系統對非法侵入的防範能力。安全測試期間，測試人員假扮非法入侵者，採用各種辦法試圖突破防線。例如： ①想方設法截取或破譯口令； ②專門定做軟體破壞系統的保護機制； ③故意導致系統失敗，企圖趁恢復之機非法進入； ④試圖通過瀏覽非保密數據，推導所需信息，等等。理論上講，只要有足夠的時間和資源，沒有不可進入的系統。因此系統安全設計的准則是，使非法侵入的代價超過被保護信息的價值。此時非法侵入者已無利可圖。 兼容性測試 兼容測試，英文是Compatibility Testing。 兼容測試是測試軟體在一個特定的硬體/軟體/操作系統/網路等環境下的性能如何。向上兼容向下兼容，軟體兼容硬體兼容。軟體的兼容性有很多需要考慮的地方。 比較測試 比較測試，英文是Compare Testing。 比較測試是指與競爭夥伴的產品的比較測試，如軟體的弱點、優點或實力。來取長補短，以增強產品的競爭力。 可接受性測試 可接受性測試，英文是Acceptability Testing。 可接受性測試是在把測試的版本交付測試部門大范圍測試以前進行的對最基本功能的簡單測試。因為在把測試的版本交付測試部門大范圍測試以前應該先驗證該版本對於所測試的功能基本上比較穩定。必須滿足一些最低要求。比如不會很容易程序就掛起或崩潰。如果一個新版本沒通過可測試性的驗證，就應該阻攔測試部門花時間在該測試版本上測試。同時還要找到造成該版本不穩定的主要缺陷並督促盡快加以修正 邊界條件測試 邊界條件測試，英文是Boudary Testing。又稱邊界值測試。 一種黑盒測試方法，適度等價類分析方法的一種補充,由長期的測試工作經驗得知，大量的錯誤是發生在輸入或輸出的邊界上。因此針對各種邊界情況設計測試用例，可以查出更多的錯誤。 邊界條件測試是環繞邊界值的測試。通常意味著測試軟體各功能是否能正確處理最大值，最小值或者所設計軟體能夠處理的最長的字元串等等。 強力測試 強力測試，英文是Mightiness Testing。 強力測試通常驗證軟體的性能在各種極端的環境和系統條件下是否還能正常工作。或者說是驗證軟體的性能在各種極端環境和系統條件下的承受能力。比如，在最低的硬碟驅動器空間或系統記憶容量條件下，驗證程序重復執行打開和保存一個巨大的文件1000次後也不會崩潰或死機。 裝配/安裝/配置測試 裝配/安裝/配置測試是驗證軟體程序在不同廠家的硬體上，所支持的不同語言的新舊版本平台上，和不同方式安裝的軟體都能夠如預期的那樣正確運行。比如，把英文版的 Microsoft Office 2003安裝在韓文版 的Windows Me 上，再驗證所有功能都正常運行。 靜態測試 靜態測試，英文是Static Testing。 靜態測試指測試不運行的部分，例如測試產品說明書，對此進行檢查和審閱.。靜態方法是指不運行被測程序本身，僅通過分析或檢查源程序的文法、結構、過程、介面等來檢查程序的正確性。靜態方法通過程序靜態特性的分析，找出欠缺和可疑之處，例如不匹配的參數、不適當的循環嵌套和分支嵌套、不允許的遞歸、未使用過的變數、空指針的引用和可疑的計算等。靜態測試結果可用於進一步的查錯，並為測試用例選取提供指導。 靜態測試常用工具有：Logiscope、PRQA； 隱藏數據測試 隱藏數據測試在軟體驗收和確認階段是十分必要和重要的一部分。程序的質量不僅僅通過用戶界面的可視化數據來驗證，而且必須包括遍歷系統的所有數據。 假設一個應用程序要求用戶兩條信息-----用戶名和密碼來創建帳戶。這個用戶輸入這兩條數據後保存。最後，一個確認窗口將通過資料庫中找到這條數據來顯示用戶名和密碼給用戶。為了驗證所有的數據保存是否正確，一個QA測試人員會在這個確認窗口簡單的查看下用戶名和密碼。如果他們成功了？假設資料庫記錄了第三條信息----創建日期，它可能不會出現在確認窗口，而只在存檔中才出現。如果創建日期保留的不正確，而QA測試人員只驗證屏幕上的數據，那麼這個問題就不可能被發現。創建日期可能就是一個bug，由於一個用戶帳戶保存了一個錯誤的日期到資料庫中，這個問題也不可能會被引起注意，因為它被用戶界面所隱藏。這只是一個簡單的例子，但是它卻演化出了一點：隱藏數據測試的重要性。 等價劃分測試 等價劃分測試的英文是equivalence partition testing。 等價劃分測試是根據等價類設計測試用例的一種技術。是黑盒測試的典型方法之一，通過把被測試程序所有可能的輸入數據域劃分成若幹部分。從每一部分中選取少數有代表性的數據作為測試用例，可有效減少測試次數，極大提高軟體測試效率，縮短軟體開發周期．等價類劃分測試的目的就是為了在有限的測試資源的情況下，用少量有代表性的數據得到比較好的測試效果。有效等價類盒無效等價類。有效等價類中的數據代表的是一組符合需求文檔的正確的有意義數據。無效等價類則正相反。 判定表 判定表的英文是decision table，是指一個表格，用於顯示條件和條件導致動作的集合。 定義：判定表是分析和表達多邏輯條件下執行不同操作的情況的工具。 判定表的優點：能夠將復雜的問題按照各種可能的情況全部列舉出來，簡明並避免遺漏。因此，利用判定表能夠設計出完整的測試用例集合。 在一些數據處理問題當中，某些操作的實施依賴於多個邏輯條件的組合，即：針對不同邏輯條件的組合值，分別執行不同的操作。判定表很適合於處理這類問題 深度測試 深度測試的英文Depth test ，是指執行一個產品的一個特性的所有細節，但不測試所有特性。 當比較函數返回真的時候才顯示出效果來。必須啟用「#深度測試」，才能執行測試。不使用的時候需要關閉。 基於設計的測試 基於設計的測試的英文是design-based testing，是根據軟體的構架或詳細設計引出測試用例的一種方法。 一種基於設計模型的測試方法(Model Based TestIng System,MATIS).該方法利用用戶界面自動生成方法,把設計模型中的類屬性定義和實現中的控制項屬性組織在一起,構建描述界面的邏輯對照表,輔助測試腳本引擎執行自動測試腳本.藉助設計模型中擴展的類定義,MATIS方法可以自動生成測試用例和測試數據。 文檔測試 文檔測試的英文是documentation testing，測試關注於文檔的正確性。 文檔測試有三大類分別是開發文件、用戶文件、管理文件。 1. 開發文件：可行性研究報告、軟體需求說明書、數據要求說明書、概要設計說明書、詳細設計說明書、資料庫設計說明書、模塊開發卷宗。 2.用戶文件：用戶手冊、操作手冊。 3.管理文件：項目開發計劃、測試計劃、測試分析報告、開發進度月報、項目開發總結報告。 軟體測試中的文檔測試主要是對相關的設計報告和用戶使用說明進行測試，對於設計報告主要是測試程序與設計報告中的設計思想是否一致；對於用戶使用說明進行測試時，主要是測試用戶使用說明書中對程序操作方法的描述是否正確，重點是用戶使用說明中提到的操作例子要進行測試，保證採用的例子能夠在程序中正確完成操作。 域測試 域測試的英文是domain testing，定義參考等價劃分測試（equivalence partition testing）； 一般分為單域測試和多域測試，其中單域測試包括設備測試和業務測試，設備測試包括測試某個系統的軟交換設備、中繼媒體網關設備、信令網關設備、接入媒體網關和IAD等設備。 等價類劃分有兩種不同的情況：有效等價類和無效等價類。設計時要同時考慮這兩種等價類，因為軟體不僅要能接收合理的數據，也要能經受意外的考驗。 一有效等價類：是指對於程序的規格說明來說是合理的、有意義的輸入數據構成的集合。利用有效等價類可檢驗程序是否實現了規格說明中所規定的功能和性能。 二無效等價類：與有效等價類的定義恰巧相反。