軟件測試整理複習（簡答題）轉載請經由做者贊成

（由於未使用過kikbug這類在線測試的移動應用綜測平臺，因此16和32我也不知道怎麼寫。。。）

一、 軟件缺陷?

（1）從內部看，軟件缺陷是開發或維護過程當中所存在的錯誤

（2）從外部看，軟件缺陷是系統所須要實現的某種功能的失效

二、 黑盒測試用於檢測發現哪幾類錯誤？

（1）有錯誤的功能或遺漏了某項功能；

（2）不能正確地接受輸入數據，輸出錯誤的結果；

（3）功能操做邏輯不合理、不夠方便；

（4）界面出錯、扭曲或不美觀；

（5）安裝過程當中出現問題，安裝步驟不清晰、不夠靈活；

（6）系統初始化問題

三、 正交類測試?

（1）肯定影響功能的因子與狀態

（2）選擇一個合適的正交表

（3）利用正交表構造測試數據集

例子：書P49

四、 靜態白盒測試？

對源程序代碼的語法檢查、掃描、評審等。

五、 負載測試？

模擬實際應用的軟硬件環境及用戶使用過程系統負荷，長時間或超大負荷運行測試軟件，來測試被測系統的性能、可靠性、穩定性等。

六、 軟件測試過程模型。

M模型、TMap模型   見書P70、71

V模型:

七、 缺陷管理的目標？

(1)確保每一個被發現的缺陷都可以被解決；

(2)這裏解決的意思不必定是被修正，也多是其餘處理方式（例如，在下一個版本中修正或是不修正），總之，對每一個被發現的BUG的處理方式必須可以在開發組織中達到一致；

(3)收集缺陷數據並根據缺陷趨勢曲線識別測試過程的階段；決定測試過程是否結束有不少種方式，經過缺陷趨勢曲線來肯定測試過程是否結束是經常使用而且較爲有效的一種方式；

(4)收集缺陷數據並在其上進行數據分析，做爲組織的過程財富。

八、 軟件測試的做用？

保證軟件質量

九、 Alpha測試與beta測試的區別?

Alpha測試在開發者的場所進行，Beta測試由用戶在一個或多個客戶場所進行。

十、 什麼狀況下測試結束？

經過驗收測試，軟件產品的質量達到了客戶的要求。

十一、 測試用例設計的關鍵？

避免含糊的測試用例

儘可能將具備相相似功能的測試用例抽象並歸類

儘可能避免冗長和複雜的測試用例

十二、 黑盒測試用例的設計方法？

Ad-hoc測試方法和ALAC測試

錯誤推測法

等價類劃分法

邊界值分析法

斷定表方法

因果圖法

Pair-wise方法

正交實驗法

1三、 單元測試主要測試那幾方面的問題？

代碼規範性、正確性、安全性、性能

1四、 移動應用測試存在的困難？

App迭代速度快，測試時間少

APP測試的準確性和問題追蹤難以保證

手機機型分裂愈來愈嚴重，APP兼容問題突出

1五、 性能測試過程當中測試腳本的編寫過程。

（1）肯定性能測試需求

（2）根據需求，選擇測試工具和開發相應的測試腳本

（3）建議性能測試負載模型

（4）執行性能測試

（5）提交性能測試報告

1六、 在線測試的原理？

 

1七、 軟件質量的度量方法。

1、收集和分類軟件缺陷信息

2、找出致使每一個缺陷的緣由（如沒有正確理解客戶的需求、不符合規格說明書、設計錯誤、代碼錯誤、數據處理錯誤、違背標準、界面不友好）

3、使用Pareto規則（80%缺陷主要是由20%的主要因素形成的，20%缺陷是由另外80%的次要因素形成的），將要這20%的主要因素分離出來

4、一旦標出少數的主要因素，就比較容易糾正引發缺陷的問題。

1八、 舉例說明Fault、Failure、Error的區別

Fault：若是軟件因爲執行了某些語句致使進入某種錯誤狀態，那麼這些語句稱爲軟件錯誤

Failure：程序的實際輸出結果和預期的輸出結果不一致

Error：錯誤狀態是不一樣於程序正常行爲的一種內部狀態，會致使程序失效

1九、 灰盒測試與白盒測試及黑盒測試的區別。

灰盒測試介於白盒測試和黑盒測試之間，灰盒測試關注輸出對於輸入的正確性，同時也關注內部表現，但這種關注不像白盒測試那樣詳細完整，只是經過一些表徵性的現象、事件、標誌來判斷內部的運行狀態。

20、 Ad-hoc測試方法的基本原理。

無拘無束、思惟活躍，能發現一些隱藏比較深的缺陷，有時能夠達到出人意料的結果。

2一、 錯誤猜想方法的基本原理。

某處發現了缺陷，則可能會隱藏更多的缺陷。

2二、 常見的組合測試技術

斷定表方法

因果圖法

Pair-wise方法

正交實驗法

2三、 探索式測試？

沒有測試用例，靠頭腦想，一邊想一邊測試。

2四、 列舉你平常使用軟件時碰到的5種性能問題。

多人同時登陸，頁面的響應速度慢

查詢數據，很長時間才顯示列表

設置共享時，不能快速同步，共享好友不能即刻顯示更新後的信息

啓動系統、打開頁面愈來愈慢

網絡下載速度很低，如5kb/s

2五、 爲何要性能測試？

爲了發現系統性能問題或獲取系統性能相關指標（如運行速度、響應時間、資源利用率等）。

2六、 Fuzz 測試？

經過向目標系統提供非預期的輸入並監視異常結果來發現軟件漏洞的方法

2七、 SQL 注入攻擊 （SQL Injection）。

從客戶端提交特殊的代碼，從而收集程序及服務器的信息，從而獲取必要的數據庫信息，而後基於這些信息，能夠注入某些參數，繞過程序的保護，針對數據庫服務器進行攻擊。例如在原有URL地址後面加一個恆成立的條件（or1==1）這樣能夠繞過數據庫的保護，對數據庫進行操做。

2八、 跨站腳本攻擊（XSS）。

XSS可讓攻擊者在頁面訪問者的瀏覽器中執行JavaScript腳本，從而能夠得到用戶回話的安全信息、插入惡意的信息或植入病毒等。按照注入的途徑，通常分爲三種：反射、基於DOM文檔對象模型和存儲。

2九、 軟件響應速度的2-5-10原則？

當用戶可以在2秒之內獲得響應時，會感受系統的響應很快；當用戶在2-5秒之間獲得響應時，會感受系統的響應速度還能夠；當用戶在5-10秒之內獲得響應時，會感受系統的響應速度很慢，可是還能夠接受；而當用戶在超過10秒後仍然沒法獲得響應時，會感受系統糟透了，或者認爲系統已經失去響應，而選擇離開這個Web站點，或者發起第二次請求。

30、 實際測試用例設計應包括哪些要素。

1）測試用例必須具備表明性、典型性

2）測試用例設計時，時尋求系統設計、功能設計的弱點

3）測試用例須要考慮到正確的輸入，也須要考慮錯誤的或者異常的輸入，以及須要分析怎樣使得這樣的錯誤或者異常可以發生。

3一、 PIE模型？

PIE模型就是代碼執行到Fault，感染產生Error，傳播出去（輸出），咱們能夠觀測到Failure失效行爲

3二、 結合Kikbug移動應用綜測平臺，闡述移動應用測試的難點。