軟體如何測試

A. 怎麼對軟體功能測試

找經理要詳細設計說明書，沒有就找開發問功能。
啥都不會呢測毛啊。功能先整明白了。然後劃分模塊，拆分功能點，自己設計用例，自己執行。有時間再加上負面測試。有能力再搞搞QTP、LR。基本就這些了。
至於你說的怎麼劃分功能要看公司要求，和項目的緊急程度，理論上是顆粒越小越好。一個組件一個用例也可以。沒事就找點測試方面的書看看吧

B. 軟體測試的測試流程是怎樣的

• 需求：閱讀需求，理解需求，與客戶、開發、架構多方交流，深入了解需求。--testing team
  2.測試計劃: 根據需求估算測試所需資源（人力、設備等）、所需時間、功能點劃分、如何合理分配安排資源等。---testing leader or testing manager
  3.用例設計：根據測試計劃、任務分配、功能點劃分，設計合理的測試用例。---testing leader, senior tester
  4.執行測試：根據測試用例的詳細步驟，執行測試用例。--every tester(主要是初級測試人員)
  5.執行結果記錄和bug記錄：對每個case記錄測試的結果，有bug的在測試管理工具中編寫bug記錄。--every tester(主要是初級測試人員)
  6.defect tracking：追蹤leader分配給你追蹤的bug.直到 bug fixed。--every tester
  7.測試報告：通過不斷測試、追蹤，直到被測軟體達到測試需求要求，並沒有重大bug.
  8.用戶體驗、軟體發布等……

C. 如何測試app軟體測試在手機中的使用情況

手機app測試主要有以下：
1.安全測試
1)軟體許可權
-扣費風險：包括發送簡訊、撥打電話、連接網路等 -隱私泄露風險：包括訪問手機信息、訪問聯系人信息等 -新增風險項
2)開發者官方許可權列表信息比對分析 2.安裝、運行、卸載測試
驗證App是否能正確安裝、運行、卸載，以及操作過程和操作前後對系統資源的使用情況，主要包括：
1)檢測軟體是否能正確安裝、運行、卸載； 2)安裝、卸載、更新錯誤報告； 3)其他輔助信息： -位置和文件夾是否合理； -組件是否正確注冊或刪除；
-評估操作前後，CPU、Memory（內存佔用）、Storage（磁碟佔用）等系統資源的使用情況。 3.UI測試
測試用戶界面(如菜單、對話框、窗口和其它可視控制項)布局、風格是否滿足客戶要求，文字是否正確，頁面是否美觀，文字，圖片組合是否完美，操作是否友好等。
UI測試的目標是確保用戶界面會通過測試對象的功能來為用戶提供相應的訪問或瀏覽功能。確保用戶界面符合公司或行業的標准。包括用戶友好性、人性化、易操作性測試。 4.功能測試
根據軟體說明或用戶需求驗證App的各個功能實現，採用如下方法實現並評估功能測試過程：
1)採用時間、地點、對象、行為和背景五元素或業務分析等方法分析、提煉App的用戶使用場景，對比說明或需求，整理出內在、外在及非功能直接相關的需求，構建測試點，並明確測試標准（若用戶需求中無明確標准遵循，則需要參考行業或相關國際標准或規則）。 2)根據被測功能點的特性列舉出相應類型的測試用例對其進行覆蓋，如：涉及輸入的地方需要考慮等價、邊界、負面、異常或非法、場景回滾、關聯測試等測試類型對其進行覆蓋。 3)在測試實現的各個階段跟蹤測試實現與需求輸入的覆蓋情況，及時修正業務或需求理解錯誤。 5.性能測試

評估App的時間和空間特性
1)極限測試：在各種邊界壓力情況下（如電池、存儲、網速等），驗證App是否能正確響應。
2)響應能力測試：測試App中的各類操作是否滿足用戶響應時間要求 3)壓力測試：反復/長期操作下，系統資源是否佔用異常； 4)性能評估：評估典型用戶應用場景下，系統資源的使用情況。
5)Benchmark測試（基線測試）：與競爭產品的Benchmarking,產品演變對比測試等。 6.中斷測試
針對智能終端應用的服務等級劃分方式及實時特性所提出的測試方法，如：App在前/後台運行狀態時與來電、文件下載、音樂收聽等關鍵運用的交互情況測試等。 7.兼容測試
主要測試內部和外部兼容性，包括：
與本地及主流App是否兼容； 檢驗在各種網路連接下(WiFi、GSM、GPRS、EDGE、WCDMA、CDMA1x、CDMA2000、HSPDA等)，App的數據和運用是否正確；
與各種設備是否兼容（若有跨系統支持則需要檢驗是否在各系統下，各種行為是否一致）。
8.安全測試
安全測試顯得尤為重要，粗心、不謹慎的數據存儲或傳輸方式使得非法、惡意目的有可乘之機。
智能終端安全涉及各信息交互、存儲接點，借鑒於網路傳輸和相關安全測試經驗，App安全測試大概劃分為以下幾類：
1)從數據的本地存儲到數據的傳輸、處理以及遠程訪問等各個環節，基於相應的安全標准/行業標准評估App的安全特性；
2)借鑒在Web App和網路安全測試的一些成功經驗在智能終端App測試中進行裁減或適配；
3)檢測App的用戶授權級別，數據泄漏，非法授權訪問等；
4)對App的輸入有效性校驗、認證、授權、敏感數據存儲、數據加密等方面進行檢測,以期發現潛在的安全問題；
5)基於各種通信協議或相應的行業安全標准檢視App是否滿足相應的要求

D. 如何進行軟體測試

1、轉分析階段
需求分析人員完成《需求規格說明書》之後，測試人員參加《需求規格說明書》的評審
2、轉設計階段
設計人員完成《界面原型規范》之後，測試人員參加《界面原型規范》的評審
3、計劃階段
測試組長編寫《系統測試計劃》、《項目進度計劃》，測試人員參加評審，評審之後，由組長召開項目開工會
4、設計階段
測試工程師編寫《系統測試方案》，並由測試工程師組織相關人員對《系統測試方案》評審
5、實現階段
測試工程師編寫《系統測試用例》，並由測試工程師組織相關人員對《系統測試用例》評審
6、預測試階段
代碼寫完之後，由開發工程師以《系統演示》的方式進行預測試，由開發工程師組織相關人員參加系統演示會議
7、全面測試階段
系統演示通過的模塊，由測試工程師根據測試方案、用例執行全面測試，提交缺陷
8、發布階段
全面測試通過之後，由發布人員將產品打包發給現場實施人員，進行現場的環境搭建組裝
9、回歸測試階段
實施人員發現問題的，將問題陳訴打包回公司，由配置工程師統一進行分配給開發工程師進行修改，修改完成後，再由測試工程師進行回歸測試，回歸測試之後，由配置工程師將增量打包發回現場。

E. 如何選擇軟體測試方法

1、按是否查看程序內部結構分為：
（1）黑盒測試（black-box testing）：只關心輸入和輸出的結果
（2）白盒測試（white-box testing）：去研究裡面的源代碼和程序結構
2、按是否運行程序分為：
（1）靜態測試（static testing）：是指不實際運行被測軟體，而只是靜態地檢查程序代碼、界面或文檔可能存在的錯誤的過程。
靜態測試包括：
對於代碼測試，主要是測試代碼是否符合相應的標准和規范。
對於界面測試，主要測試軟體的實際界面與需求中的說明是否相符。
對於文檔測試，主要測試用戶手冊和需求說明是否真正符合用戶的實際需求。
（5）動態測試（dynamic testing），是指實際運行被測程序，輸入相應的測試數據，檢查輸出結果和預期結果是否相符的過程
3、按階段劃分：
（1）單元測試（unit testing），是指對軟體中的最小可測試單元進行檢查和驗證。
樁模塊（stud）是指模擬被測模塊所調用的模塊，驅動模塊（driver）是指模擬被測模塊的上級模塊，驅動模塊用來接收測試數據，啟動被測模塊並輸出結果。
（2）集成測試（integration testing），是單元測試的下一階段，是指將通過測試的單元模塊組裝成系統或子系統，再進行測試，重點測試不同模塊的介面部門。
集成測試就是用來檢查各個單元模塊結合到一起能否協同配合，正常運行。
（3）系統測試（system testing），指的是將整個軟體系統看做一個整體進行測試，包括對功能、性能，以及軟體所運行的軟硬體環境進行測試。
系統測試的主要依據是《系統需求規格說明書》文檔。
（4）驗收測試（acceptance testing），指的是在系統測試的後期，以用戶測試為主，或有測試人員等質量保障人員共同參與的測試，它也是軟體正式交給用戶使用的最後一道工序。
驗收測試又分為a測試和beta測試，其中a測試指的是由用戶、 測試人員、開發人員等共同參與的內部測試，而beta測試指的是內測後的公測，即完全交給最終用戶測試。
4、黑盒測試分為功能測試和性能測試：
1)功能測試（function testing），是黑盒測試的一方面，它檢查實際軟體的功能是否符合用戶的需求。
包括邏輯功能測試（logic function testing）
界面測試（UI testing）UI=User Interface
易用性測試（usability testing）：是指從軟體使用的合理性和方便性等角度對軟體系統進行檢查，來發現軟體中不方便用戶使用的地方。
兼容性測試（compatibility testing）：包括硬體兼容性測試和軟體兼容性測試
2)性能測試（performance testing）
軟體的性能主要有時間性能和空間性能兩種
時間性能：主要指軟體的一個具體事務的響應時間（respond time）。
空間性能：主要指軟體運行時所消耗的系統資源。
軟體性能測試分為：
一般性能測試：指的是讓被測系統在正常的軟硬體環境下運行，不向其施加任何壓力的性能測試。
穩定性測試也叫可靠性測試（reliability testing）：是指連續運行被測系統檢查系統運行時的穩定程度。
負載測試（load testing）：是指讓被測系統在其能忍受的壓力的極限范圍之內連續運行，來測試系統的穩定性。
壓力測試（stress testing）：是指持續不斷的給被測系統增加壓力，直到將被測系統壓垮為止，用來測試系統所能承受的最大壓力。(Validate the system or software can allowed the biggest stress.)

F. 如何進行軟體功能測試

我是做軟體測試工作的，仁者見仁智者見智，水平有限，就你提出的問題作一個簡單的回答吧，一是期望對你的問題有所幫助，二也是對我自己的提高。
1、我對你的第一個問題表示質疑，你認為測試是保證軟體質量嗎？能保證嗎？
測試只能提高軟體質量，做不到保證，bug是永遠存在的，測試工作可以讓這
量減少、降低嚴重問題的存在；軟體過程才可能保證它的質量，不是軟體測
試，所以這一點我要明確出來。一個軟體的質量好壞不依賴於測試者，測試
再高明，軟體設計本身的水平面要品質不高，巧婦也有無米之炊的無奈。

2、測試的原本目標就是發現缺陷，挑毛病，工作性質和開發人員相反，但目標
是一致的，都是為了使軟體更完美、更穩定。

3、蓋房子的時候，先打地基，地基如果有毛病（如不夠深、不平），那以後房
蓋起來了住個幾年，你會發現樓上的梁會發裂，滲水，然後越來越讓人擔
憂。這時你要修復怎麼辦，再怎麼補都不放心，因為地基有缺陷啊！這個道
和第三個問題是一模一樣的，修復的代價太大太大了！在測試中有一個規
則，問題越早解決代價越小，單元測試發現的問題解決只要1塊錢，等到集成
測試再解決，要10塊錢，你認為比例有多大？需求分析系統設計是源頭，重
中之重，這個比例我認為要在上面我舉例中增加80%，就是說它會導致你在編
碼階段多付出8塊錢。前期可能不覺得，越到後期將發現非常頭痛，這也是我
的經驗之談，沒有太多的科學性哦。

4、對於測試員，首先是效率減低；對於項目而言，成本增加了。瞧病就錯了
診，影響大么？將導致後面的百分之八十的事情白做了，百分之二在長遠
目標中有後期幫助，同時證明另外百分之八十步入歧途。這就要在測試設計
的時候要仔細全面，但是這種事情多少都避免不了，早一點發現並改變，也
是很重要的，另外多布置一些小結會議，有利到測試的工作方向和目標。

usfo，希望我的回答對你稍有幫助哦。

G. 怎麼軟體測試啊

軟體測試方法

軟體測試的基本方法
單元測試的基本方法
綜合測試的基本方法
確認測試的基本方法
系統測試的基本方法
軟體測試的基本方法

軟體測試的方法和技術是多種多樣的。
對於軟體測試技術，可以從不同的角度加以分類：

從是否需要執行被測軟體的角度，可分為靜態測試和動態測試。
從測試是否針對系統的內部結構和具體實現演算法的角度來看，可分為白盒測試和黑盒測試；

1、黑盒測試

黑盒測試也稱功能測試或數據驅動測試，它是在已知產品所應具有的功能，通過測試來檢測每個功能是否都能正常使用，在測試時，把程序看作一個不能打開的黑盆子，在完全不考慮程序內部結構和內部特性的情況下，測試者在程序介面進行測試，它只檢查程序功能是否按照需求規格說明書的規定正常使用，程序是否能適當地接收輸入數鋸而產生正確的輸出信息，並且保持外部信息（如資料庫或文件）的完整性。黑盒測試方法主要有等價類劃分、邊值分析、因果圖、錯誤推測等，主要用於軟體確認測試。 「黑盒」法著眼於程序外部結構、不考慮內部邏輯結構、針對軟體界面和軟體功能進行測試。「黑盒」法是窮舉輸入測試，只有把所有可能的輸入都作為測試情況使用，才能以這種方法查出程序中所有的錯誤。實際上測試情況有無窮多個，人們不僅要測試所有合法的輸入，而且還要對那些不合法但是可能的輸入進行測試。

2、白盒測試

白盒測試也稱結構測試或邏輯驅動測試，它是知道產品內部工作過程，可通過測試來檢測產品內部動作是否按照規格說明書的規定正常進行，按照程序內部的結構測試程序，檢驗程序中的每條通路是否都有能按預定要求正確工作，而不顧它的功能，白盒測試的主要方法有邏輯驅動、基路測試等，主要用於軟體驗證。

「白盒」法全面了解程序內部邏輯結構、對所有邏輯路徑進行測試。「白盒」法是窮舉路徑測試。在使用這一方案時，測試者必須檢查程序的內部結構，從檢查程序的邏輯著手，得出測試數據。貫穿程序的獨立路徑數是天文數字。但即使每條路徑都測試了仍然可能有錯誤。第一，窮舉路徑測試決不能查出程序違反了設計規范，即程序本身是個錯誤的程序。第二，窮舉路徑測試不可能查出程序中因遺漏路徑而出錯。第三，窮舉路徑測試可能發現不了一些與數據相關的錯誤。

3．ALAC(Act-like-a-customer)測試

ALAC測試是一種基於客戶使用產品的知識開發出來的測試方法。ALAC測試是基於復雜的軟體產品有許多錯誤的原則。最大的受益者是用戶，缺陷查找和改正將針對哪些客戶最容易遇到的錯誤。

單元測試的基本方法

單元測試的對象是軟體設計的最小單位模塊。單元測試的依據是詳細設描述，單元測試應對模塊內所有重要的控制路徑設計測試用例，以便發現模塊內部的錯誤。單元測試多採用白盒測試技術，系統內多個模塊可以並行地進行測試。
單元測試任務

單元測試任務包括：1 模塊介面測試；2 模塊局部數據結構測試；3 模塊邊界條件測試；4 模塊中所有獨立執行通路測試；5 模塊的各條錯誤處理通路測試。

模塊介面測試是單元測試的基礎。只有在數據能正確流入、流出模塊的前提下，其他測試才有意義。測試介面正確與否應該考慮下列因素：
1 輸入的實際參數與形式參數的個數是否相同；
2 輸入的實際參數與形式參數的屬性是否匹配；
3 輸入的實際參數與形式參數的量綱是否一致；
4 調用其他模塊時所給實際參數的個數是否與被調模塊的形參個數相同；
5 調用其他模塊時所給實際參數的屬性是否與被調模塊的形參屬性匹配；
6調用其他模塊時所給實際參數的量綱是否與被調模塊的形參量綱一致；
7 調用預定義函數時所用參數的個數、屬性和次序是否正確；
8 是否存在與當前入口點無關的參數引用；
9 是否修改了只讀型參數；
10 對全程變數的定義各模塊是否一致；
11是否把某些約束作為參數傳遞。

如果模塊內包括外部輸入輸出，還應該考慮下列因素：
1 文件屬性是否正確；
2 OPEN/CLOSE語句是否正確；
3 格式說明與輸入輸出語句是否匹配；
4緩沖區大小與記錄長度是否匹配；
5文件使用前是否已經打開；
6是否處理了文件尾；
7是否處理了輸入/輸出錯誤；
8輸出信息中是否有文字性錯誤；

檢查局部數據結構是為了保證臨時存儲在模塊內的數據在程序執行過程中完整、正確。局部數據結構往往是錯誤的根源，應仔細設計測試用例，力求發現下面幾類錯誤：
1 不合適或不相容的類型說明；
2變數無初值；
3變數初始化或省缺值有錯；
4不正確的變數名（拼錯或不正確地截斷）；
5出現上溢、下溢和地址異常。

除了局部數據結構外，如果可能，單元測試時還應該查清全局數據（例如FORTRAN的公用區）對模塊的影響。

在模塊中應對每一條獨立執行路徑進行測試，單元測試的基本任務是保證模塊中每條語句至少執行一次。此時設計測試用例是為了發現因錯誤計算、不正確的比較和不適當的控制流造成的錯誤。此時基本路徑測試和循環測試是最常用且最有效的測試技術。計算中常見的錯誤包括：
1 誤解或用錯了算符優先順序；
2混合類型運算；
3變數初值錯；
4精度不夠；
5表達式符號錯。

比較判斷與控制流常常緊密相關，測試用例還應致力於發現下列錯誤：
1不同數據類型的對象之間進行比較；
2錯誤地使用邏輯運算符或優先順序；
3因計算機表示的局限性，期望理論上相等而實際上不相等的兩個量相等；
4比較運算或變數出錯；
5循環終止條件或不可能出現；
6迭代發散時不能退出；
7錯誤地修改了循環變數。

一個好的設計應能預見各種出錯條件，並預設各種出錯處理通路，出錯處理通路同樣需要認真測試，測試應著重檢查下列問題：
1輸出的出錯信息難以理解；
2記錄的錯誤與實際遇到的錯誤不相符；
3在程序自定義的出錯處理段運行之前，系統已介入；
4異常處理不當；
5錯誤陳述中未能提供足夠的定位出錯信息。

邊界條件測試是單元測試中最後，也是最重要的一項任務。眾的周知，軟體經常在邊界上失效，採用邊界值分析技術，針對邊界值及其左、右設計測試用例，很有可能發現新的錯誤。

單元測試過程

一般認為單元測試應緊接在編碼之後，當源程序編制完成並通過復審和編譯檢查，便可開始單元測試。測試用例的設計應與復審工作相結合，根據設計信息選取測試數據，將增大發現上述各類錯誤的可能性。在確定測試用例的同時，應給出期望結果。

應為測試模塊開發一個驅動模塊（driver）和（或）若干個樁模塊（stub）,下圖顯示了一般單元測試的環境。驅動模塊在大多數場合稱為「主程序」，它接收測試數據並將這些數據傳遞到被測試模塊，被測試模塊被調用後，「主程序」列印「進入-退出」消息。

驅動模塊和樁模塊是測試使用的軟體，而不是軟體產品的組成部分，但它需要一定的開發費用。若驅動和樁模塊比較簡單，實際開銷相對低些。遺憾的是，僅用簡單的驅動模塊和樁模塊不能完成某些模塊的測試任務，這些模塊的單元測試只能採用下面討論的綜合測試方法。

提高模塊的內聚度可簡化單元測試，如果每個模塊只能完成一個，所需測試用例數目將顯著減少，模塊中的錯誤也更容易發現。

H. 怎樣做好軟體測試

作為一個軟體測試工程師，首先，你要建立自己的測試思維，這個很重要，因為測試思維相當於你的軟體的世界觀，這也就是為什麼，個人不支持從 開發轉測試的原因，因為對於開發而言，他們是目標型的世界觀，即需求要完成什麼我去完成，如果你在開發中待的時間太長，容易習慣這樣目標型世界觀，而測試更多關注的是多方面的，有時候，就是一些在開發所謂的不可能、無所謂的東西最後造成軟體的失敗，而如何建立自己的軟體世界觀，那就要去通過測試的方法論的理解，很多人喜歡把黑盒測試方法論、白盒測試方法論，分得很清楚，其實兩者是相通的，看懂這些東西很快的，但是悟透，這個過程會漫長。
接下來 我們講講你需要作為一個初級功能工程師所需要基本素質吧
1、軟體測試的基本方法（邊界值、等價類、錯誤分類、流程分析等等黑盒、白盒測試方法要有了解，並且掌握）這個不難，但請務必牢記在心中，它是你去建立自己世界觀的基礎，所有的測試逃不出這些方法
2、會寫的基礎的測試文檔（測試用例、缺陷報告等）
3、會看開發文檔（需求說明書、操作手冊）
4、知道軟體工程中，測試所需要做的事情，了解性能測試、安全測試等
當你有了基礎，同時也有了自己的世界觀，祝賀你已經入門了，這個時候，我建議你可以去了解不同軟體開發不同環節人所作的事情，不單單是開發，需求、設計、運維等等，因為這樣你會知道什麼是體系、規范，為你以後的發展有著很好的幫助，這也是測試相對於開發優勢的地方，開發更關注的是點，而測試要關注的是面，所以對於測試而言，除了准確的抓住細節的同時，大局觀要好，否則做不好測試。

最後才是細節技術就是所謂的白盒測試、性能測試、自動化、安全等等，這些其實對測試而言反而是小節，技術永遠不會阻礙你前行的腳步，反而思維，這個你可以根據自己喜好去發展，沒有固定模式
順便說一句，別看不起基礎的功能測試，它沒外人看得那麼簡單，因為如果你連測試用例都不會設計就別去說做性能測試、自動化測試、安全測試等等，要做一好的功能測試工程師，寫的一手好用例（你的用例是個識字人都能執行、並且用例有效的系統覆蓋率也是很高的）、好缺陷（是個識字的人都能理解你說的是問題，並且抓住重點），很難的，真心不是普通人能做好的，要去花心思琢磨的。

I. 什麼是軟體測試，軟體怎麼測試

軟體測試定義是：為了發現程序中的錯誤而執行程序的過程 （這個行業現在比較熱門。而且好的測試員收入可觀。）

它是幫助識別開發完成（中間或最終的版本）的計算機軟體（整體或部分）的正確度(correctness) 、完全度(completeness)和質量(quality)的軟體過程；是SQA(software quality assurance)的重要子域。

軟體測試的目標：

(1)測試是為了發現程序中的錯誤而執行程序的過程；

(2)好的測試方案是極可能發現迄今為止尚未發現的錯誤的測試方案；

(3)成功的測試是發現了至今為止尚未發現的錯誤的測試。

軟體測試的內容：

軟體測試主要工作內容是驗證(verification)和確認( validation )，下面分別給出其概念：

驗證(verification)是保證軟體正確地實現了一些特定功能的一系列活動，即保證軟體做了你所期望的事情。(Do the right thing)

1.確定軟體生存周期中的一個給定階段的產品是否達到前階段確立的需求的過程；

2.程序正確性的形式證明，即採用形式理論證明程序符號設一計規約規定的過程；

3.評市、審查、測試、檢查、審計等各類活動，或對某些項處理、服務或文件等是否和規定的需求相一致進行判斷和提出報告。

確認(validation)是一系列的活動和過程，目的是想證實在一個給定的外部環境中軟體的邏輯正確性。即保證軟體以正確的方式來做了這個事件(Do it right)

1.靜態確認，不在計算機上實際執行程序，通過人工或程序分析來證明軟體的正確性；

2.動態確認，通過執行程序做分析，測試程序的動態行為，以證實軟體是否存在問題。

軟體測試的對象不僅僅是程序測試，軟體測試應該包括整個軟體開發期問各個階段所產生的文檔，如需求規格說明、概要設計文檔、詳細設計文檔，當然軟體測試的主要對象還是源程序。

從不同的角度出發，軟體測試可以劃分為不同的分類：

從是否關心軟體內部結構和具體實現的角度劃分

A.白盒測試

B.黑盒測試

C.灰盒測試

從是否執行程序的角度

A.靜態測試

B.動態測試。

從軟體開發的過程按階段劃分有

A.單元測試

B.集成測試

C.確認測試

D.驗收測試

E.系統測試

J. 軟體如何做性能測試

目前大部分性能測試工具都是基於web的，如果要測試exe執行軟體的性能，需要自己制定測試方案，並選擇何時的性能測試工具。