① 常用的軟體測試方法和工具
工業標准級負載測試工具LoadrunnerLoadRunner 是一種預測系統行為和性能的負載測試工具。通過以模擬上千萬用戶實施並發負載及實時性能監測的方式來確認和查找問題，LoadRunner 能夠對整個企業架構進行測試。通過使用LoadRunner ，企業能最大限度地縮短測試時間，優化性能和加速應用系統的發布周期。自動化功能測試工具AutoRunnerAutoRunner是黑盒測試工具，可以用來完成功能測試、回歸測試、每日構建測試與自動回歸測試等工作。是具有腳本語言的、提供針對腳本完善的跟蹤和調試功能的、支持IE測試和Windows native測試的自動化測試工具，是目前國內最好的銀行業務測試工具。全球測試管理系統testdirectorTestDirector 是業界第一個基於Web的測試管理系統，它可以在您公司內部或外部進行全球范圍內測試的管理。通過在一個整體的應用系統中集成了測試管理的各個部分，包括需求管理，測試計劃，測試執行以及錯誤跟蹤等功能，TestDirector極大地加速了測試過程。測試用例管理工具TestCenterTestCenter是一款功能強大測試管理工具，它實現了測試需求管理、測試用例管理、測試業務組件管理、測試計劃管理、測試執行、測試結果日誌察看、測試結果分析、缺陷管理，並且支持測試需求和測試用例之間的關聯關系，可以通過測試需求索引測試用例。終端自動化測試工具TARTAR適用於VT100、VT220等標準的應用系統，支持命令行模式和窗口模式（使用Cursors編寫的應用程序）。 支持針對終端應用的自動錄制。支持連續錄制和單獨的窗口錄制。支持的窗口組件：欄位、表格、對話框、窗口等。功能測試工具Rational RobotBorland SilkTest 2006屬於軟體功能測試工具，是Borland公司所提出軟體質量管理解決方案的套件之一。這個工具採用精靈設定與自動化執行測試，無論是程序設計新手或資深的專家都能快速建立功能測試，並分析功能錯誤。 性能測試工具WASMicrosoft Web Application Stress Tool 是由微軟的網站測試人員所開發，專門用來進行實際網站壓力測試的一套工具。透過這套功能強大的壓力測試工具，您可以使用少量的Client端計算機模擬大量用戶上線對網站服務所可能造成的影響。自動化白盒測試工具JtestJtest是parasoft公司推出的一款針對java語言的自動化白盒測試工具，它通過自動實現java的單元測試和代碼標准校驗，來提高代碼的可靠性。parasoft同時出品的還有C++ test，是一款C/C++白盒測試工具。功能和性能測試的工具JMeterJMeter是Apache組織的開放源代碼項目，它是功能和性能測試的工具，100%的用java實現。性能測試和分析工具WEBLODEwebload是RadView公司推出的一個性能測試和分析工具，它讓web應用程序開發者自動執行壓力測試；webload通過模擬真實用戶的操作，生成壓力負載來測試web的性能。企業級自動化測試工具WinRunnerMercury Interactive公司的WinRunner是一種企業級的功能測試工具，用於檢測應用程序是否能夠達到預期的功能及正常運行。通過自動錄制、檢測和回放用戶的應用操作，WinRunner能夠有效地幫助測試人員對復雜的企業級應用的不同發布版進行測試，提高測試人員的工作效率和質量，確保跨平台的、復雜的企業級應用無故障發布及長期穩定運行。
測試經理和PM對TC進行Review：
敏捷測試流程總結：
在敏捷方法中，XP方法強調測試在整個項目開發過程中的重要性。針對敏捷開發方法的敏捷測試不同於以往針對傳統開發模式的測試,在敏捷團隊中,測試是整個項目組的「車頭燈」，它告訴大家現在到哪了，正在往哪個方向走。測試員為項目組提供豐富的信息，使得項目組基於這些可靠的信息作出正確的決定。不僅是測試員要保證質量，而是整個項目組的每一個人都要對質量負責。測試員不跟開發人員糾纏錯誤，而是幫助他們找到目標,共同為達到項目的最終目標而努力。敏捷測試也需要高度迭代工作、頻繁得到客戶的反饋，需要動態調整測試計劃、測試的執行。並且，敏捷測試人員參與到了更多的敏捷生產活動中，積極的影響了團隊做出的決定和計劃。
根據公司項目目前採用的敏捷開發模式，相應的敏捷測試建議採用以下流程：
1. 驗證需求和設計
需求和設計具體來說一般包括：(1)由項目經理根據需求文本而編寫的功能設計文本(Functional Design Specification);(2)由開發人員根據功能文本而編寫的實施設計文本(Implementation Design Specification)包括(Architecture Document, Project Scope Statement, Use Case )。作為測試人員，審核重點是檢查文本對用戶需求定義的完整性、嚴密性和功能設計的可測性.
在測試初期，測試人員要學會做靜態測試，做好需求分析，做好對設計邏輯的分析。測試人員要更多的思考需求的可實現性，將自身作為第一用戶積極參與項目和系統的需求分析，設計和開發。積極地參與前期工作，並迅速反饋給設計和開發其靜態測試結果。要盡早的開始測試，不要等待到功能完全做好才開始。
產出物:測試需要提交評審結果文檔,可以讓測試更多的參與DB Design,框架的評審中來
2. 測試計劃，測試用例
2.1 編寫計劃、測試用例
在敏捷開發的過程中由於是根據每個user story來估算時間的。開發人員將對本次迭代所需要的完成的user story進行評估。開發人員可以和客戶直接溝通，來確定每個user story的優先順序。
好處：
客戶可以很清楚的了解到哪些user story需要花費多長的時間，以及他們的優先順序。
問題：
在user story的時間估算上，開發人員常會估算過少。引起版本無法按時發布或者必須進行加班才能進行發布。
分析：
由於版本更新很快，任務的時間都是以小時來進行估算的。開發人員一般會忽略掉開發以外的時間，比如開發中遇到問題的時間，開會，給其他成員提供幫助的時間，等等。
舉個例子：
開發人員估算某個user story編碼的時間需要1.5天，開發人員自己估算了其他時間為半天。於是開發人員給的估算時間是2天。開發階段實際的花費時間如下，每天花費開例會的時間。在例會中項目的其他成員需要技術上的支持。於是發費了3個小時進行幫助。在開發的過程中遇到了一些沒有預見到的問題，結果解決問題花費了4個小時。(也許更多)。需要處理一些公司突發性的事務等等。所以非常建議大家在估算時間上能充分的考慮到以外的因素，某本XP相關的書上寫到，在時間估算上最好的時間是編碼時間的2-3倍。聽起來很嚇人，但是實際的過程中，的確需要這么多的時間。
測試人員根據已審核通過的需求和設計編制測試計劃，設計測試用例。在前面提到的三種文本中，功能設計文本是主要依據。測試的這兩個文本也要被項目經理和開發人員審核。
2.2 測試用例的審核
為使開發人員能參與到Test Case的Review中來，以保證TC的質量和可行性，確保測試工作的順利進行，讓開發人員迅速地了解測試的重點並給出相應的意見和建議，測試人員在出 TC的同時，應出一份TC_Matrix(Test Case跟蹤矩陣)，其中註明TC已覆蓋了哪些Features，具體每個Features對應的TC的編號，這樣在測試經理和PM對TC進行 Review的時候，能夠對TC的覆蓋率一目瞭然，對覆蓋率不足(如某個重點Feature的Test Case不夠)的地方能夠及時給出意見。
另外，在每天早上的Morning Meeting上，測試人員可以簡潔地講述一下當天測試的重點部分，以及項目中存在哪些嚴重的bug，讓開發人員了解當天測試的重點是什麼，怎樣進行測試，並提出自己的意見和建議。這樣做加強了開發與測試人員的交流和溝通，使測試工作能夠更加有效，更加順利地開展。
在迭代後期測試要抽時間更新test case。
3. 實施運行測試
在敏捷方法中，測試有兩種：單元測試和接收測試。單元測試是由開發人員來完成的，接收測試是由客戶代表來完成。
由於我們客戶無法在現場，我們採取了，開發人員做單元測試，測試人員做驗證測試，最後由客戶進行接收測試。在每個版本發布給客戶之前必須由測試人員進行測試，發布版本之後由客戶做接收測試，提出需要修改的地方。需要修改的地方將在下一個發布完成。
?? 單元測試
在daily build版本給測試前，開發首先要做單元測試，提前告知軟體中的薄弱環節，幫助測試人員調整測試重點。Unit test
做單元測試的好處是可以提高版本質量，減輕測試的工作量，減少淺層次的bug的發生率，使測試人員能夠將更多的精力投入到尋找深層次的bug上面。
?? 驗證測試
測試人員的驗證測試從總體上說就是將上一步設計的測試用例按計劃付諸實施的過程。這一階段的測試必須在周密的計劃下進行。這種計劃性首先體現在開發和測試的相互協調配合，根據產品的架構和功能模塊的依賴關系，按照項目的總體計劃共同推進。從測試的過程來看，測試執行的一開始可以是針對部分功能的，之後可以逐步擴展。接著開始採用迭代的過程完成測試任務，即將測試任務劃分為多個周期，一開始可以做些關鍵的功能性測試，可以對代碼中的可復用部分(組件，構件)做完整的測試。接著的迭代周期可以做邊緣化的功能測試和其他測試，最後的幾個迭代應該用於回歸測試，和關鍵的性能和穩定性測試。
3.1 每日提供bug趨勢
為方便衡量項目的進度，測試可每天測試完畢後提供測試的bug趨勢，即將每天新生成的Bug數和每天被解決的Bug數標成一個趨勢圖表。一般在項目的開始階段新生Bug數曲線會呈上升趨勢，到項目中後期被解決Bug數曲線會趨於上升，而新生Bug數曲線應下降，到項目最後，兩條曲線都趨向於零。PM會持續觀察這張圖表，確保項目健康發展，同時通過分析預測項目Bug，
對於每個版本的bug，開發都應該想想為什麼會出現這樣的問題，特別是很低級的bug，對於同類的bug，是否可以避免。
測試需要考慮:探索性測試用例的編寫
3.2 測試用例的維護
在執行測試階段中，測試人員需要對已有的測試用例進行及時的維護。通常以下兩種情況下要新增一些測試用例：一是對於當初測試設計不周全的領域，二是對於外部的Bug(比如從Beta客戶報告來的)，沒有被現有測試用例所覆蓋。當產品的功能設計出現更改時(敏捷項目中功能設計的更改頻繁)，所涉及的測試用例也要相應地修改，使測試用例保持和現有的功能需求同步。
3.3 根據項目不斷補充Common Sense
在項目進行過程中，測試人員需要不斷積累經驗，不斷補充、完善各類目的Common Sense標准。例如，由CTTS項目總結出的Common Sense for USA標准，在以後的美國項目中要嚴格按照它來執行測試，保證以前出現過的失誤在以後的項目測試中不會再出現。在保證項目質量的同時，不斷積累新的經驗。
3.4 控制中間版本
為更好地保證軟體質量，規避風險，必須加強對中間版本的控制。例如，客戶要求或者計劃周五要提交版本，則周三一定要提交一個中間過程的版本進行測試，也就是控制中間版本，避免所有的工作都壓到後期最緊急的時候去完成。以前的項目中出現過項目前期很輕松，到後期bug越來越多，開發人員和測試人員都異常忙碌，經常加班的情況。為減少後期工作量，規避風險，建議開發進行Daliy Build，或者按照完成一個feature就進行一次build，針對這個feature進行測試，這樣就可以有效避免後期bug越來越多的狀況發生，後期工作量也就會相應減少，項目的質量也會更有保證。
3.5 發布版本前編寫Release Note
在每次發布版本之前，測試人員要根據待發布的版本情況編寫Release Note，使客戶對發布的版本情況一目瞭然。Release Note主要包括三方面的內容：Fixed，New Features，Known Problems。其中，Fixed部分寫明此版本修復了上個版本中存在的的哪些比較大的bug;New Features部分寫明此版本新增加了哪些功能;Known Problems部分寫明此版本尚存在哪些比較大的問題，有待下個版本改善;或者列出需求不太明確的地方，有待客戶給出明確答復意見，在下個版本中完成。
4. 需求管理
採用敏捷開發模式的項目中，客戶對於需求的變更很頻繁。因此，需求管理是十分必要和重要的工作。整個項目進行過程中，對不斷變化的需求，一定要作跟蹤，每次的需求變更都要有相應的歷史記錄，方便後期的管理和維護工作。可將每次的變更整理記錄到需求跟蹤文檔中，並使該文檔始終保持最新更新的狀態，與需求的變化保持同步。
問題：
客戶可能會在一個功能點上來回修改他們的需求，也許開始需要某個功能，結果做完以後又覺得不好，於是讓去掉這個功能。後來又由於一些原因，有需要加上。在整個過程中可能來回修改了很多次。那一定要記錄下變更的內容和日期。可能後期客戶會覺得一個功能怎麼會花那麼多的時間，不是以前很早就做過了嗎?這時這些記錄才是解決客戶疑慮的最好證明。說白了，是有證據證明我們做了很多的變更。大家可能覺得，怎麼會有這個問題。其實當一個項目長達半年以上，也許大家的記憶力都不可靠了(:p)
建議：
目前採用的是vss工具，對每天的Email中提到的需求變更做一次backup，文檔以當天收到Email的日期命名
5. 項目開發末期開展「bug大掃除」
在項目開發的末期，可以開展「bug大掃除」活動。劃出一個專門的時間段，在這期間所有參與項目的人員，集中全部精力，搜尋項目的Bug。注意以下要點：
(1)盡管這是一個測試活動，但參與者並不僅限於測試人員。項目經理，開發人員甚至於高層管理人員都應參加，如同全民動員。目的是要集思廣益;(2)要鼓勵各部門，領域交叉搜索，因為新的思路和視角通常有助於發現更多的Bug;(3)為調動積極性，增強趣味性，可以適當引入競爭機制，比如當活動結束時，評出發現Bug最多，發現最嚴重Bug的個人，給以物質和精神獎勵。(4)可以分專題展開，比如安全性、用戶界面可用性、國際化和本地化等等。
② 如何使用speedtest測速軟體測試網路質量
使用speedtest測速軟體測試網路質量的步驟：
下載speedtest軟體，打開該軟體，就會看到測試界面，點擊「開始測試」；
在准備好測試後就會開始一輪新的測試，首先測試的是網路的ping值。ping值反應的是接入網路的時延情況；
然後開始測試的是下載速率，反映了你使用下載業務時的網路速度；
然後自動測試上傳速率，反映了你使用上傳業務的平均速率；
點擊「結果」就是你歷次測試的結果；
點擊「工具」就是你使用的伺服器，及內部外部的IP。
③ 軟體適應性測試如何進行
軟體的測試都需要有依據，軟體需求規格說明書也好，概要設計，詳細設計也好，哪怕是用戶需求，都可以成為依據！
軟體測試可以從質量的六大特性27個子特性開始分析，並根據操作手冊形成測試用例：
一、功能性：
1、適合性：提供了相應的功能
2、准確性：正確（用戶需要的）
3、互操作性：產品與產品之間交互數據的能力
4、保密安全性：允許經過授權的用戶和系統能夠正常的訪問相應的數據和信息，禁止未授權的用戶訪問.......
5、功能性的依從性：國際/國家/行業/企業 標准規范一致性
二、可靠性：產品在規定的條件下，在規定的時間內完成規定功能的能力
1、成熟性：防止內部錯誤導致軟體失效的能力
2、容錯性：軟體出現故障，自我處理能力
3、易恢復性：失效情況下的恢復能力
4、可靠性的依從性
三、易用性：在指定使用條件下，產品被理解、 學習、使用和吸引用戶的能力
1、易理解性：
2、易學性：
3、易操作性：
4、吸引性：
5、易用性的依從性：
四、效率性：在規定台條件下，相對於所用資源的數量，軟體產品可提供適當性能的能力
1、時間特性：平均事務響應時間，吞吐率，TPS（每秒事務數）
2、資源利用性：CPU 內存 磁碟 IO 網路帶寬 隊列 共享內存
3、效率依從性：
五、軟體維護性："四規"， 在規定條件下，規定的時間內，使用規定的工具或方法修復規定功能的能力
1、易分析性：分析定位問題的難易程度
2、易改變性：軟體產品使指定的修改可以被實現的能力
3、穩定性：防止意外修改導致程序失效
4、易 測試性：使已修改軟體能被確認的能力
5、維護性的依從性
六、軟體可移植性：從一種環境遷移到另一種環境的能力
1、適應性：適應不同平台
2、易安裝性：被安裝的能力
3、共存性：
4、易替換性
5、可移植性的依從性：HI.南湖水草如有幫助，別忘了採納喲！goto365testing,測評網,
④ 軟體測試是怎麼運用的
軟體製作完成後，要對它的運行狀況和運行結果進行測試，以驗證軟體編寫得是否正確。
測試時要對軟體的輸入、輸出、設置等方面進行全面的測試，要特意搞一些錯誤的數據、錯誤的設置進行測試，看軟體在這樣的情況下出不出問題，有問題就要改
⑤ 如何使用軟體測試技術對雲產品進行測試
在雲環境下，軟體技術開發方面和軟體測試的結構方面都發生了較大變化，具體體現在幾個方面：
（1）軟體的研究人員和其所開發的軟體都要與雲適應，要保證開發的軟體能夠在雲平台上進行相關測試，雲端的計算能力及存儲能力呈現動態變化，因此軟體要能夠適應這種變化。
（2）雲測試技術不僅能夠滿足多用戶的數量，同時對於用戶的個性化需求也能夠包租，例如數據存儲結構需求及相關處理能力需求等。
（3）雲測試以互聯網為依託，因此其能夠在互聯網情況下進行相關測試數據的傳輸，實現了軟體測試的互聯網化。
（4）雲計算的軟體測試對安全性能有著一定的要求，互聯網環境相對開放，這就對用戶的隱私造成一定威脅，因此雲測試要能夠抵抗黑客攻擊且主動保護用戶的相關隱私信息。
（5）雲計算軟體測試十分便利快捷，不僅能在計算機上實現測試，還能夠搭載於手機移動終端，其操作環境更加靈活。總的來說，雲測試環境下，相關軟體的開發工作模式及開發環境都出現了相應的變化。
⑥ 應用性軟體如何測試
白盒測試是把程序看做放在一個白盒子中，即能看到程序代碼，針對代碼的測試；黑盒測試是看不到內部程序，對於輸入是否有正確輸出的檢測。肯定是黑盒應用性最大了，做白盒測試的除非是對軟體質量的要求是非常高的。一般的公司很少做的。
⑦ 初學者如何學習軟體測試
學軟體測試沒有太多硬性要求，最好是有中專以上學歷。
首先，要看你學得怎麼樣，學的知識和技能扎實了，那麼必定會有更多的機會。
其次，找工作的話，建議還是到北上廣深等者省會城市，軟體企業比較多，經濟發展好薪資待遇也高。我有全套軟體測試視頻課可以發給你自學。
課程內容主要有：
搭建Windows測試環境，JAVA編程，軟體測試基礎，資料庫技術，用戶界面技術，高效設計測試用例，階段項目實訓，搭建 Linux 測試環境，白盒測試，WEB技術，高效使用自動測試工具，軟體質量保證，流行測試基礎，企業級項目實訓用例等！
學完可以從事：
功能測試工程師，性能測試工程師，安全測試工程師，白盒測試工程師，自動化測試工程師，介面測試工程師，測試開發工程師等。
互聯網行業目前還是最熱門的行業之一，學習IT技能之後足夠優秀是有機會進入騰訊、阿里、網易等互聯網大廠高薪就業的，發展前景非常好，普通人也可以學習。
想要系統學習，你可以考察對比一下開設有相關專業的熱門學校，好的學校擁有根據當下企業需求自主研發課程的能力，能夠在校期間取得大專或本科學歷，中博軟體學院、南京課工場、南京北大青鳥等開設相關專業的學校都是不錯的，建議實地考察對比一下。
祝你學有所成，望採納。
⑧ 如何用軟體測試電腦的好壞
簡單點就是用優化大師裡面的工具測試
高級點就用3dmark2005
再就是看內存和cpu,二手電筒腦內存最好是256m以上的，
不少朋友在新裝電腦以後不能確定自己的電腦性能究竟如何。究竟應該如何測試自己愛機的性能呢？常看電腦評測文章的朋友可能了解，很多朋友評測電腦都會採用運行大量的評測軟體來評價自己的電腦。但是這並不一定適合所有的朋友。很多朋友面對繁多的數據，可能都會頭疼，可能完全不明白這些數據究竟代表了什麼樣的性能。更何況我們手頭不一定有這樣齊全的測試軟體。難道沒有簡單一點的測試方法么？有！
其實，最簡單的測試方法就是讓電腦運行一下我們常用的軟體來檢查電腦有沒有什麼問題，簡單的判斷一下電腦性能是否滿足要求。一般來說，測試可以分成幾類：游戲測試、播放電影測試、圖片處理測試、拷貝文件測試、壓縮測試、網路性能測試。這些測試基本上包括了對電腦性能的整體測試。
游戲性能測試。買電腦的朋友很少有不玩游戲的，而且游戲可以說是對電腦性能的綜合測試，包含了對CPU、內存、顯卡、主板、顯示器、光碟機、鍵盤滑鼠、音效卡、音箱等的測試。所以，電腦首先應該進行的就是游戲測試。我們可以選擇幾款常見的游戲來測試愛機。例如：極品飛車、古墓麗影、QUAKE、CS、虛幻競技場、魔獸爭霸。不一定要把這些游戲都試用一下，可以選擇其中的幾款來測試電腦性能。電腦配置高一些的朋友可以選擇高一些的游戲版本來測試，配置低一些的朋友可以選擇版本低一些的游戲來測試。測試主要應該注意游戲安裝速度、游戲運行速度、游戲畫質、游戲流暢程度、游戲音質等幾方面。可以更改顯示器設置、顯卡設置、BIOS設置、系統設置、游戲設置來感受不同設置下電腦的不同表現。例如改變顯示器的亮度、對比度，改變游戲的解析度，改變顯卡的頻率，改變內存的延時，改變CPU頻率，改變系統硬體加速比例，改變系統緩存設置等等。大家要注意的是在測試以前最好把所有的補丁程序安裝齊全，改變設置測試完成以後要把設置改回來(或者改到最佳狀態)。有條件的朋友可以和配置相近的電腦對比一下，相信能感受出自己愛機的性能。
接下來可以考慮播放一段電影來測試自己的電腦。建議選擇常用的播放器和比較熟悉的電影這樣可能不用和其他電腦對比就能看出自己愛機的「優勢」。這時候應該注意的是播放有沒有異常、畫面的鮮艷程度、調整顯示器亮度後的畫面變化情況、電影畫面的清晰程度等等。
再下來可以考慮測試一下電腦的圖片處理能力。筆者推薦用常用的圖形處理軟體來測試，例如PHOTOSHOP、FIREWORKS、AUTOCAD、3D MAX等等。可以試著打開多個圖片文件、更改圖片或者編輯圖片來測試電腦圖片處理速度、觀察畫質。
拷貝文件測試比較簡單，應該盡量選擇大一些的文件拷貝，大家可以選擇拷貝VCD或者DVD。壓縮測試可以選擇我們常用的WINZIP或者WINRAR來壓縮大一些的文件。也可以通過壓縮CD、VCD來測試電腦，選擇我們常用的超級解霸軟體來測試。以上測試重點查看速度。
網路性能測試相對來說簡單一些，主要檢查網路是否能正常連接、連接速度是否正常。
除了上面幾方面以外，大家也可以運行一些常用的測試軟體來看看電腦得分。例如3DMARK2001SE、3DMARK03、PCMARK04等。然後可以和網上的參考得分來比較得到出對電腦的評價。
⑨ 軟體測試的方法一共有幾種
1、從是否關心內部結構來看
（1）白盒測試：又稱為結構測試或邏輯驅動測試，是一種按照程序內部邏輯結構和編碼結構，設計測試數據並完成測試的一種測試方法。
（2）黑盒測試：又稱為數據驅動測試，把測試對象當做看不見的黑盒，在完全不考慮程序內部結構和處理過程的情況下，測試者僅依據程序功能的需求規范考慮，確定測試用例和推斷測試結果的正確性，它是站在使用軟體或程序的角度，從輸入數據與輸出數據的對應關系出發進行的測試。
（3）灰盒測試：是一種綜合測試法，它將「黑盒」測試與「白盒」測試結合在一起，是基於程序運行時的外部表現又結合內部邏輯結構來設計用例，執行程序並採集路徑執行信息和外部用戶介面結果的測試技術。
2、從是否執行代碼看
（1）靜態測試：指不運行被測程序本身，僅通過分析或檢查源程序的語法、結構、過程、介面等來檢查程序的正確性。
(2)動態測試：是指通過運行被測程序，檢查運行結果與預期結果的差異，並分析運行效率、正確性和健壯性等性能指標。
3、從開發過程級別看
（1）單元測試：又稱模塊測試，是針對軟體設計的最小單位----程序模塊或功能模塊，進行正確性檢驗的測試工作。其目的在於檢驗程序各模塊是否存在各種差錯，是否能正確地實現了其功能，滿足其性能和介面要求。
(2)集成測試：又叫組裝測試或聯合，是單元測試的多級擴展，是在單元測試的基礎上進行的一種有序測試。旨在檢驗軟體單元之間的介面關系，以期望通過測試發現各軟體單元介面之間存在的問題，最終把經過測試的單元組成符合設計要求的軟體。
（3）系統測試：是為判斷系統是否符合要求而對集成的軟、硬體系統進行的測試活動、它是將已經集成好的軟體系統，作為基於整個計算機系統的一個元素，與計算機硬體、外設、某些支持軟體、人員、數據等其他系統元素結合在一起，在實際運行環境下，對計算機系統進行一系列的組裝測試和確認測試。
在系統測試中，對於具體的測試類型有：
（1）功能測試：對軟體需求規格說明書中的功能需求逐項進行的測試，以驗證功能是否滿足要求。
（2）性能測試：對軟體需求規格說明書的功能需求逐項進行的測試，以驗證功能是否滿足要求。
（3）介面測試：對軟體需求規格說明中的介面需求逐項進行的測試。
（4）人機交互界面測試：對所有人機交互界面提供的操作和顯示界面進行的測試，以檢驗是否滿足用戶的需求。
（5）強度測試：強制軟體運行在異常乃至發生故障的情況下（設計的極限狀態到超出極限），驗證軟體可以運行到何種程序的測試。
（6）餘量測試：對軟體是否達到規格說明中要求的餘量的測試。
（7）安全性測試：檢驗軟體中已存在的安全性、安全保密性措施是否有效的測試，
（8）可靠性測試：在真實的或模擬的環境中，為做出軟體可靠性估計而對軟體進行的功能（其輸入覆蓋和環境覆蓋一般大於普通的功能測試）
（9）恢復性測試：對有恢復或重置功能的軟體的每一類導致恢復或重置的情況，逐一進行的測試。
（10）邊界測試：對軟體處在邊界或端點情況下運行狀態的測試。
（11）數據處理測試：對完成專門數據處理功能所進行的測試。
（12）安裝性測試：對安裝過程是否符合安裝規程的測試，以發現安裝過程中的錯誤。
（13）容量測試：檢驗軟體的能力最高能達到什麼程度的測試。
（14）互操作性測試：為驗證不同軟體之間的互操作能力而進行的測試。
（15）敏感性測試：為發現在有效輸入類中可能引起某種不穩定性或不正常處理的某些數據的組合而進行的測試。
（16）標准符合性測試：驗證軟體與相關國家標准或規范（如軍用標准、國家標准、行業標准及國際標准）一致性的測試。
（17）兼容性測試：驗證軟體在規定條件下與若干個實體共同使用或實現數據格式轉換時能滿足有關要求能力的測試。
（18）中文本地化測試：驗證軟體在不降低原有能力的條件下，處理中文能力的測試。
4、從執行過程是否需要人工干預來看
（1）手工測試：就是測試人員按照事先為覆蓋被測軟體需求而編寫的測試用例，根據測試大綱中所描述的測試步驟和方法，手工地一個一個地輸 入執行，包括與被測軟體進行交互（如輸入測試數據、記錄測試結果等），然後觀察測試結果，看被測程序是否存在問題，或在執行過程中是否會有一場發生，屬於比較原始但是必須執行的一個步驟。
（2）自動化測試：實際上是將大量的重復性的測試工作交給計算機去完成，通常是使用自動化測試工具來模擬手動測試步驟，執行用某種程序設計語言編寫的過程（全自動測試就是指在自動測試過程中，不需要人工干預，由程序自動完成測試的全過程；半自動測試就是指在自動測試過程中，需要手動輸入測試用例或選擇測試路徑，再由自動測試程序按照人工指定的要求完成自動測試）
5、從測試實施組織看
（1）開發測試：開發人員進行的測試
（2）用戶測試：用戶方進行的測試
（3）第三方測試：有別於開發人員或用戶進行的測試，由專業的第三方承擔的測試，目的是為了保證測試工作的客觀性
6、從測試所處的環境看
（1）阿爾法測試：是由一個用戶在開發環境下進行的測試，也可以是公司內部的用戶在模擬實際操作環境下進行的測試
（2）貝塔測試：是用戶公司組織各方面的典型終端用戶在日常工作中實際使用貝塔版本，並要求用戶報告
(9)怎樣使用軟體測評擴展閱讀
軟體測試的內容：
1 得到需求、功能設計、內部設計說書和其他必要的文檔
2 得到預算和進度要求
3 確定與項目有關的人員和他們的責任、對報告的要求、所需的標准和過程 ( 例如發行過程、變更過程、等等 )
4 確定應用軟體的高風險范圍，建立優先順序、確定測試所涉及的范圍和限制
5 確定測試的步驟和方法 ── 部件、集成、功能、系統、負載、可用性等各種測試
6 確定對測試環境的要求 ( 硬體、軟體、通信等 )
7 確定所需的測試用具 (testware) ，包括記錄 / 回放工具、覆蓋分析、測試跟蹤、問題 / 錯誤跟蹤、等等
8 確定對測試的輸入數據的要求
9 分配任務和任務負責人，以及所需的勞動力
10 設立大致的時間表、期限、和里程碑
11 確定輸入環境的類別、邊界值分析、錯誤類別
12 准備測試計劃文件和對計劃進行必要的回顧
13 准備白盒測試案例
14 對測試案例進行必要的回顧 / 調查 / 計劃
15 准備測試環境和測試用具，得到必需的用戶手冊 / 參考文件 / 結構指南 / 安裝指南，建立測試跟蹤過程，建立日誌和檔案、建立或得到測試輸入數據
16 得到並安裝軟體版本
17 進行測試
18 評估和報告結果
19 跟蹤問題 / 錯誤，並解決它
20 如果有必要，重新進行測試
21 在整個生命周期里維護和修改測試計劃、測試案例、測試環境、和測試用具
⑩ 如何測試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是否滿足相應的要求