初級軟件測試工程師面試題匯總2020

第一章軟件測試理論基礎

1.軟件測試的概念？

使用人工或者自動手段來運行或者測試某個系統的過程。在規定條件下對程序進行操作從而發現問題，對軟件質量進行評估的過程。

簡而言之就是：為了發現程序中錯誤而執行程序的過程。

2.軟件測試的目的？

1）軟件測試為了發現程序存在的代碼或業務邏輯錯誤；

2）軟件測試為了檢驗產品是否符合用戶需求；

3）軟件測試為了提高用戶的體驗

3.軟件測試主要測似乎用例設計方法？

1、白盒測試：邏輯覆蓋、循環覆蓋、基本路徑覆蓋

2、黑盒測試：等價類划分、邊界值、因果圖、判定表、場景法、流程分析法、錯誤推測法、正交表排序法。

4.軟件測試的原則？

1）所有測試都應追溯到用戶需求。

2）應當把盡早測試和不斷測試作為座右銘。

3）2：8原則，測試80%的錯誤可能來源於20%的新增模塊

4）對測試發現的錯誤結果寫一個缺陷報告。

5）完全測試是不可能的，測試需要終止。

6）設計測試用例時應全面考慮各種情況。

7）制定嚴格的測試計划。

8）注意回歸測試，對修改過的代碼，重新測試確保沒有引入新的錯誤。

5.  測試計划？

1）測試范圍（功能性測試；非功能性測試）

2） 測試通過/失敗的標准（通過准則；失敗准則）

3）測試掛起恢復條件

4）測試進度人力分布計划

5） 測試交付物

6.  測試方案？

1) 測試環境（軟硬件構成；網絡構成；環境搭建；測試工具）

2) 測試策略

3) 測試風險評估與預防

4) 測試報告：

測試BUG記錄

測試BUG統計分析

測試用例執行情況清單

遺留問題清單

7.  測試流程？

1）需求分析（用戶\產品經理）

2) 編寫測試計划（測試經理）

2）編寫測試用例（測什么\怎么測）

3）評審測試用例

4）搭建測試環境

5）等待開發提交測試包

6）部署測試包

7）冒煙測試（對軟件主體基本功能進行測試）

8）執行測試用例

9）Bug跟蹤處理

8.  軟件產品質量模型？

 軟件產品質量模型對產品設計時需要考慮的地方進行高度概括。

1）功能性：在指定情況下，提供滿足明確的功能。

2）可靠性：在指定條件下使用時，產品維持規定的性能級別。

第一：系統最好不出故障

第二：出故障不影響主要的功能和業務

第三：如果影響主要功能及業務，系統可以盡快恢復。

3)    易用性：易懂易學易用，漂亮好看（用戶體驗）

4)    效率性：產品性能

5)    可維護性：產品被糾正改進的能力

6)    可移植性：能從一種環境遷移到另一種環境

9.  單元測試？

單元測試又稱模塊測試，需要從程序的內部結構出發設計測試用例，多個模塊可以平行的進行單元測試。

10.集成測試？

集成測試又稱組裝測試，通常是在單元測試的基礎上，將所有程序進行有序，遞增的測試，重點測試不同模塊的接口部分。

11.系統測試？

將整個軟件系統看作一個整體進行測試，包括對功能、性能、以及對軟件所運行的軟硬件環境測試。前期主要是測試功能是否滿足需求，后期主要測試性能是否滿足要求。系統在不同軟硬件環境中的兼容性。

13.驗收測試？

驗收測試是最后一個階段的測試操作，在軟件產品投入正式運行前的所要進行的測試工作。和系統測試相比而言，驗收測試與之的區別就只是測試人員不同，驗收測試則是由用戶來執行這一操作的。

（1）a測試：Alpha測試是在軟件開發環境下由用戶進行的測試，或者模擬實際操作環境進而進行的測試。Alpha測試主要是對軟件產品的功能、局域化、界面、可使用性以及性能等等方面進行評價。

（2）B測試：Beta測試是在實際環境中由多個用戶對其進行測試，並將在測試過程中發現的錯誤有效反饋給軟件開發者。所以在測試過程中用戶必須定期將所遇到的問題反饋給開發者。

 v模型優缺點？

1、優點：

1.包含了底層測試（單元測試）和高層測試（系統測試）；

2.清楚的標識了開發和測試的各個階段；

3.自上而下逐步求精，每個階段分工明確，便於整體項目的把控。

2、缺點：

1.自上而下的順序導致了，測試工作在編碼之后，就導致錯誤不能及時的進行修改；

2.實際工作中，需求經常變化，導致v模型步驟，反復執行，返工量很大，靈活度較低。

3.改良：每個步驟都可以進行小的迭代工作。

14.w模型優缺點？

定義：開發一個v；測試一個v組合起來的模型（w模型也叫雙v模型）

優點：

　　   1.測試伴隨着整個開發周期，需求和設計同樣要測試；

　　   2.更早的介入測試，可以發現初期的缺陷，修復成本低；

　　   3.分階段工作，方便項目整體管理。

缺點：

　　   1.開發和測試依然是線性的關系，需求的變更和調整，依然不方便；

　　   2.如果沒有文檔，根本無法執行w模型；對於項目組成員的技術要求更高！

15.H模型優缺點？

H模型的優點：

　　>開發的H模型揭示了軟件測試除測試執行外，還有很多工作；

　　>軟件測試完全獨立，貫穿整個生命周期，且與其他流程並發進行；

　　>軟件測試活動可以盡早准備、盡早執行，具有很強的靈活性；

　　>軟件測試可以根據被測物的不同而分層次、分階段、分次序的執行，同時也是可以被迭代的。

H模型的缺點：

　　>管理型要求高：由於模型很靈活，必須要定義清晰的規則和管理制度，否則測試過程將非常難以管理和控制；

　　>技能要求高：H模型要求能夠很好的定義每個迭代的規模，不能太大也不能太小；

　　>測試就緒點分析困難：測試很多時候，你並不知道測試准備到什么時候是合適的，就緒點在哪里，就緒點的標准是什么，這就對后續的測試執行的啟動帶來很大困難；

　　>對於整個項目組的人員要求非常高：在很好的規范制度下，大家都能高效的工作，否則容易混亂。例如：你分了一個小的迭代，但是因為人員技能不足，使得無法有效完成，那么整個項目就會受到很大的干擾。

總結：

　　v模型適用於中小企業，

　　w模型適用於中大型企業（因為人員要求高），

h模型人員要求非常高，很少有公司使用。

16. 測試用例定義？

測試用例是為特定的目的而設計的一組測試輸入，執行條件，和預期的結果。簡而言之：測什么，怎么測

17. 等價類划分法？

等價類划分屬於黑盒測試，將不能窮舉的測試過程進行分類，從而保證完整性和代表性。

（1）分類：

有效等價類：符合需求規格說明書，輸入合理的數據集合。

無效等價類：不符合需求規格說明書，輸入不合理數據。

（2）細節

考慮輸入長度

考慮輸入類型

組成規則

是否為空

是否區分大小寫

是否重復

是否去除空格

18. 邊界值？

邊界值是指對於輸入等價類和輸出等價類而言，稍高於其邊界值和稍低於邊界值的情況。

19. 因果圖法？

因果圖法是一種利用圖解法分析輸入的各種組合情況設計測試用例的方法。

特點：

（1）考慮輸入條件的相互制約及組合關系

（2）考慮輸出條件對輸入條件的依賴關系

因：輸入條件

果：輸出條件

20.判定表法？

因果圖只是一種輔助工具，通過分析最終得到判定表，再通過判定表編寫測試用例。

判定表的組成：

（1）條件樁：問題的所有條件

（2）動作樁：問題的所有輸出

（3）條件項：針對條件樁的取值

（4）動作項：各種條件區取值情況下輸出的結果

20. 場景發？

場景發就是模擬用戶操作軟件的場景，主要用於測試系統的業務流程。

（1）基本流：按照正確的業務流程實現操作

（2）備選流：導致程序出現錯誤的操作流程

21. 流程分析法？

流程分析法，又叫場景設計法

三個流程

（1）基本流：通過業務流程輸入都為正確的，能夠最終達到目標的流程，如atm機取款，插入銀行卡-輸入正確的密碼-輸入正確的金額-取錢-取卡

（2）備選流：通過實現業務流程時，因錯誤操作或異常輸入，導致流程存在反復，但最終能夠達到預期的操作流程，如atm機取款，插入銀行卡-輸入錯誤的密碼-重新輸入正確的密碼-輸入金額-取錢-取卡

（3）異常流：通過實現業務流程時，因錯誤操作或異常輸入，導致沒有完成業務流程，如atm機取款，插入銀行卡，輸入三次錯誤的密碼，吞卡

使用方法

（1）根據需求，確定業務流程

（2）繪制流程圖，再次明確流程路徑

（3）根據業務流程圖，抽取測試路徑，每個路徑包含一個從未走過的路徑

（4）細化路徑，抽取測試用例

22.錯誤推測法？

指利用直覺或者經驗猜出錯誤的可能，列舉出程序中容易出錯或者有可能的錯誤，常適用於經驗豐富的測試人員。

22. 正交表排序法？

使用最少的抽樣數據達到最廣的，覆蓋率最高的統計結果。

在一個界面中有多個控件，每個控件有多個取值，測試要考慮不同控件不同取值之間的組合 ，但是組合數量較大（>20種，20種以下一般用因果圖/判定表），沒有必要全部測試，如何從所有組合中挑選最少的組合測試，並能得到最優的測試效果—使用正交排列法。

正交排列法和判定表法的主要異同：

1、都是用來測控件的組合問題

2、判定表法適合測組合數量較少的情況

3、正交排列法適合測組合數量較多的情況

4、判定表（因果圖）會反映控件之間的限制和組合關系

5、正交排列表只需反映控件之間的組合關系。

三、解析正交表公式

Ln(m^k)

L：line  行

n：表示正交表有幾行，需要測試的組合的個數

n值是固定的，一旦正交表確定n值就是固定的，不需要測試人員自己計算。

m：表示正交表中允許出現的最大值

根據每個控件的取值個數來確定m值

k：表示正交表有幾列

根據組合的控件個數進行確定

四、使用正交表測試的步驟：

步驟1：分析需求--- 列出需要組合的控件以及每個控件的取值（excel）

步驟2：選擇一個合適的正交表 

選擇正交表，其實就是確定正交表的m值和k值的過程。

23. 軟件缺陷？

軟件缺陷是指軟件產品中所存在的問題。最終表現為用戶所需功能沒有完全實現，沒有滿足用戶的需求。

24. 軟件缺陷的表現形式？

（1）功能或者特性沒有實現或者部分實現。

（2）設計不合理，功能不明確，邏輯不清楚。

（3）產品實際結果與預期結果不一致。

（4）沒有達到需求規格說明書指定的性能指標。

（5）運行出錯，中斷，系統崩潰，界面混亂。

（6）數據不正確，精度不夠，格式不統一。

（7）用戶不接受的其他問題。

25. 缺陷的狀態？

（1）提交：已提交的缺陷。

（2）打開：確認提交的缺陷，等待處理

（3）拒絕：拒絕提交的缺陷，不需要修復或者不是缺陷。

（4）修復：缺陷被修復

（5）關閉：確認修復的缺陷，將其關閉。

（6）推遲：推遲到以后解決。

26. 缺陷的分類？

1、系統缺陷

（1）由程序引起的死機，異常退出。

（2）程序死循環

（3）程序錯誤，不能執行重要功能。

2、數據缺陷

（1）數據計算錯誤

（2）數據約束錯誤

（3）數據輸入，輸出錯誤。

3、數據庫缺陷

（1）數據庫發生死鎖

（2）數據庫的表未加約束條件

（3）數據庫連接錯誤

（4）數據表中有過多空字段

4、接口缺陷

（1）數據通信錯誤

（2）程序接口錯誤

5、功能缺陷

（1）功能無法實現

（2）功能實現錯誤

6、安全性缺陷

（1）用戶權限無法實現

（2）超時

（3）訪問控制

（4）加密錯誤

7、兼容性缺陷

（1）與需求規定兼容性不符

8、性能缺陷

（1）未達到預期的性能指標

（2）性能測試中的錯誤，導致無法繼續

9、界面缺陷

（1）操作界面錯誤

（2）打印內容，格式錯誤

（3）刪除未給提示

（4）界面不規范

27. 缺陷報告注意的事項？

（1）盡量保證缺陷可以重現

（2）簡潔、准確、完整。

（3）一個缺陷報告只寫一個缺陷

28. 缺陷書寫規范？

（1）標題：保持簡潔，准確

（2）步驟：重現測試的步驟，完整，有順序，明確

（3）實際結果：執行步驟后的結果

（4）預期結果：列出期望的結果

（5）提供附件：圖片或者截圖

29. 缺陷的跟蹤？

（1）新建提交的缺陷為”新建“狀態。

（2）再確認有效之后為”打開“狀態

（3）開發人員修改后”已修復“狀態。

（4）測試人員需要回歸測試，如果bug已修復，狀態改為”已解決“狀態。

30. 你會搭建測試環境？

測試環境=硬件+軟件+網絡+數據准備+測試工具

（1）硬件

計算機系統：windows系統，Linux系統，macos系統

1）Linux系統的命令和操作必須熟練。

2）Linux系統包括：centos、ubuntu

3）明確軟件對硬件的需求：cpu個數、內存大小、硬盤大小

4）了解各種操作系統：Linux命令、安裝系統、配置ip

（2）軟件

1）當前被測的軟件以及相互依賴交互的軟件

2）將被測軟件部署在linux系統上

3）依賴和交互的軟件如：JDK、tomcat、數據庫

（3）網絡

1）基本網絡協議：tcp、udp、http

2）Linux ip和路由配置

3）Linux命令抓包

（4）數據准備

1）准備測試數據

2）測試數據在測試用例階段設計好

3）少量，正常數據可以手工測試，大量數據通過測試工具。

（5）測試工具

1）接口測試：jmeter/postman

2）壓力和性能測試：loadrunner

3）抓包工具：fiddler/wireshark

4）測試管理工具：禪道、bugfree、jira、bugzilla

31. 成為優秀軟件測試工程師具備的能力？

1）認真、負責、嚴謹、耐心地態度

2）有過硬的技術本領：測試理論、測試工具、數據庫、開發知識

3）溝通能力十分重要：除了與開發溝通，還要和不同的產品、運營、客服等打交道。如何准確，簡潔，嚴謹的描述bug。

4）邏輯思維能力：重要的是去尋找bug產生的真正原因，准備找到問題的源頭。

32. fiddler抓包工具?

（1）概念？

Fiddler是位於客戶端和服務端的http代理，為目前最常用的抓包工具之一。

（3）功能？

1)   檢查所有瀏覽器的所有http/https流量

2)   查看、分析請求內容細節

3)   偽造客戶端請求和服務器響應

4)   測試網站的性能

5)   解密https的web會話

6)   全局、局部斷點

（4）使用場景？

1）接口調試

2）接口測試

3）線上環境調試

4）Web性能分析

5）判斷前后端bug

6）開發環境

7）Host 配置

8）弱網斷網測試

 

33. http協議？

超文本傳輸協議，用於從萬維網服務器傳輸超文本到本地瀏覽器。http是基於請求和響應模式的無狀態應用層協議。

完整的http包括請求和響應兩塊內容：

（1）http請求報文

主要是由請求行、請求頭部、空一行、請求正文四部分組成。

1）請求方法：

Get（請求資源），

Post（提交資源），

head（獲取響應頭），

put（替換資源），

delete（刪除資源），

option（允許客戶查看服務器性能），

url（統一資源定位符）

2）請求頭部：

Host（主機ip地址/域名）

User-agent（客戶機相關信息）

Accept（指定客戶端接收數據類型比如：.jpg/html）

Accept-charset(客戶端接受的字符集比如：gbk/utf-8)

Accept-language(可接受的語言)

Cookie（攜帶的cookie信息）

Referer（當前文檔url）

Content-type(請求內容類型)

content-length（數據長度）

（2）http響應報文

主要是由狀態行、響應頭部、空行、響應正文組成。

1）狀態行：請求的協議及版本

狀態碼：服務器響應狀態的3位數字代碼

1xx：提示信息，請求被成功接收

2xx：成功，請求被成功處理 200

3xx:重定向 304

4xx：客戶端錯誤 404

5xx：服務端錯誤 500

 

2）響應頭部

Server（http服務器軟件信息）

Date（響應報文時間）

Exprise(緩存過期時間)

set-cookie（設置cookie）

Last-modified（最后修改時間）

Content-type/content-length

 

 

第二章 Linux環境安裝部署及基本命令

Linux目錄結構如下：

• bin (binaries)存放二進制可執行文件
• sbin (super user binaries)存放二進制可執行文件，只有root才能訪問
• etc (etcetera)存放系統配置文件
• usr (unix shared resources)用於存放共享的系統資源
• home 存放用戶文件的根目錄
• root 超級用戶目錄
• dev (devices)用於存放設備文件
• lib (library)存放跟文件系統中的程序運行所需要的共享庫及內核模塊
• mnt (mount)系統管理員安裝臨時文件系統的安裝點
• boot 存放用於系統引導時使用的各種文件
• tmp (temporary)用於存放各種臨時文件
• var (variable)用於存放運行時需要改變數據的文件

linux命令基本格式

cmd [options] [arguments]，options稱為選項，arguments稱為參數

選項和參數都作為Shell命令執行時的輸入，它們之間用空格分隔開。

• Linux是區分大小寫的

一般來說，后面跟的選項如果單字符選項前使用一個減號-。單詞選項前使用兩個減號--

• 這是一般的情況，有些命令還是不歸屬這種規律的(相對較少)~~~
• 例子：ls -a和ls -all，a 單個字符使用一個-，一個單詞all 使用兩個--

在Linux中，可執行的文件也進行了分類：

• 內置命令：出於效率的考慮，將一些常用命令的解釋程序構造在Shell內部。
• 外置命令：存放在/bin、/sbin目錄下的命令
• 實用程序：存放在/usr/bin、/usr/sbin、/usr/share、/usr/local/bin等目錄下的實用程序
• 用戶程序：用戶程序經過編譯生成可執行文件后，可作為Shell命令運行
• Shell腳本：由Shell語言編寫的批處理文件，可作為Shell命令運行

通配符：

學過一些正則表達式的或者有點基礎的同學對通配符應該就不陌生的了，在Linux也有通配符(在搜索的時候挺有用的)

• *：匹配任何字符和任何數目的字符
• ?：匹配單一數目的任何字符
• [ ]：匹配[ ]之內的任意一個字符
• [! ]：匹配除了[! ]之外的任意一個字符，!表示非的意思

常見的文件操作命令：

1）可用 pwd命令查看用戶的當前目錄

2)   可用 cd 命令來切換目錄

　　.表示當前目錄

　　.. 表示當前目錄的上一級目錄（父目錄）

　　-表示用 cd 命令切換目錄前所在的目錄

　　~ 表示用戶主目錄的絕對路徑名

3）ls命令（查看當前目錄下的內容）

　　ls-l   顯示詳細列表相當於ll

　　ls-lh  將數據大小按人性化顯示

　　ls-a    顯示所有文件，包含隱藏文件

4）mkdir 創建文件夾

　　mkdir  tupian在當前目錄下創建文件夾

　　mkdir /home/admin/tupian 以絕對路徑創建文件夾

　　mkdir /home/admin/a/tupian -p 如果上級目錄不存在，加上-p會自動創建父目錄

　　mkdir a b  在當前目錄下創建多個文件夾

5）touch 創建空文件

　　touch  a.txt  在當前目錄下創建文件

　　gedit a.txt  使用記事本打開文件

6）rm刪除文件或者文件夾

　　rm  a.txt   刪除文件

　　rm abc -r       刪除文件夾

　　rm *   刪除所有（不能刪除隱藏文件）

7）cp  拷貝文件

　　cp  1.txt   2.txt  將1.txt內容復制到2.txt

　　cp   abc   abcx  -r   拷貝文件夾

8）mv  移動文件（相當於剪切）

　　mv  1.txt  2.txt  剪切文件

　　mv  abc    abx  剪切文件夾

9）cat 查看文件內容或者合並內容

　　cat 1.txt 把文件的內容顯示到窗口中

　　cat 1.txt  2.txt  將兩個文件合並的內容顯示到窗口中

10） grep  查找文件內容

　　grep  hello  a.txt  在文件a.txt中查找“hello”　　

　　grep -niv   hello  a.txt  (n:顯示行號，i:不區分大小寫，v:反向查找，查找不含hello的內容）

11） find  查找文件　　

　　find  /home  -name 1.txt   查找名為1.txt的文件

　　find /home -name  "*txt"    查找所有以txt結尾的文件

12）tar 打包歸檔

　　tar  cvf  a.tar   1.txt  2.txt (f必須放在最后，a.tar指打包后的文件）

　　tar  tf   a.tar  列出包里的文件

　　tar   xvf    a.tar     解開文件並放到當前目錄

13）less| more  分頁顯示文件文檔內容，可以向前后翻

14）head  顯示文檔前面的內容，默認顯示前十行

常見的系統操作命令

1）top 顯示當前系統資源消耗最多的進程

2）date 顯示當前系統時間

3）ps -e   顯示當前所有進程、環境變量

4）ps -ef  全格式顯示

5）ps  -a  顯示所有用戶所有進程

6 ）kill -9 ss 強制殺死一個進程

7）壓縮、解壓　

gzip 涉及參數說明：

-k 保留源文件 -d 解開壓縮文件 -r 遞歸處理，將指定目錄下的所有文件及子目錄一並處理 -v 顯示指令執行過程

壓縮：

gzip -k ./* #當前目錄下所有文件進行壓縮，每個文件一個gz包

gzip -rkv ./* 遞歸壓縮

解壓：

gzip -dv test.gz 

bzip2:

bzip2 -zk test #壓縮test文件

bzip2 -dk test.bz2 #解壓

其他命令：

1)、啟動mysql服務：systemctl start mysql；service mysqld start

2)、解壓文件：tar –zxvf 文件名

3)、創建用戶分組：groupadd 分組名

4)、創建新用戶：useradd 用戶名

5)、下載安裝文件：yum install -y文件名

6)、編輯文件：vi 文件名

7)、保存： :wq

8)、強制退出：:q!

9)、創建文件：mkdir 文件名

10)、本機復制文件：cp file /remote_file/file

11)、移動文件：mv file /remote_file/file

12)、多台主機傳輸文件：scp local_file remote_username@remote_ip:remote_folder（需要注意的是需要知道目標主機的密碼密碼以及網絡通暢）

13)、刪除文件：rm –rf file

14)、查看主機信息：top

15)、查看進程：ps –ef | grep mysql

16)、查看端口：netstat -tunlp | grep 3306

17)、殺死進程：kill -9 進程號

18)、切換目錄：cd

19)、顯示磁盤信息：df –h

20)、Docker

 

 

 

 

第三章  測試相關面試題

1、你的測試職業發展是什么?

1）測試經驗越豐富，測試能力越高。所以我覺得的職業發展是需要時間積累的，一步步向着高級測試工程師奔去。

2）而且我也有初步的職業規划，前3年積累測試經驗，按如何做好測試工程師的要點去要求自己，不斷更新自己改正自己，做好測試任務。

1、鞏固基礎測試知識，提高理解需求能力。

2、學習自動化測試，並且運用。技術到尾后學習帶領測試團隊。

3、最后爭取達到測試經理水平。

2、你認為測試人員需要具備哪些素質？

1）做測試應該要有一定的溝通協調能力，因為測試人員經常要與開發，產品接觸處理一些問題，如果處理不好的話會引起一些沖突，這樣的話工作上就會不好做。

2）還有測試人員要有一定的耐心，有的時候做測試很枯燥乏味。

3）除了耐心，測試人員不能放過每一個可能的錯誤。

3、軟件測試工程師需要具備的能力？

1）業務分析能力：分析整體業務流程、分析被測業務數據、分析被測系統架構、分析被測業務模塊、分析測試所需資源、分析測試完成目標；

2）缺陷洞察能力：一般缺陷的發現能力、隱性問題的發現能力、發現連帶問題的能力、發現問題隱患的能力、盡早發現問題的能力、發現問題根源的能力；

3）團隊協作能力：合理進行人員分工、協助組員解決問題、配合完成測試任務、配合開發重現缺陷、督促項目整體進度、出現問題勇於承擔；

4）專業技術能力：掌握測試基礎知識、掌握計算機知識、熟練運用測試工具；

5）邏輯思考能力：判斷邏輯的正確性、對可行性邏輯分析、站在客觀角度思考；

6）問題解決能力：技術上的問題、工作中的問題、溝通問題；

7）溝通表達能力：和技術人員、產品人員、上下級的溝通；

8）宏觀把控能力：有效控制測試時間、有效控制測試成本、有效制定測試計划、有效進行風險評估、有效控制測試方向。

4、結合你以前的學習和工作經驗，你認為如何做好測試？

　根據我以前的工作和學習經驗，我認為做好工作首先要有一個良好的溝通，只有溝通無障礙了，才會有好的協作，才會有更好的效率，再一個就是技術一定要過關，做測試要有足夠的耐心，和一個良好的工作習慣，不懂的就要問，實時與同事溝通這樣的話才能做好測試工作。

5、說說你對軟件配置管理的理解？

　項目在開發過程中要用相應的配置管理工具對配置項(包括各個階段的產物)進行變更控制，配置管理的使用取決於項目規模和復雜性及風險的水平。軟件的規模越大，配置管理就越顯得重要。還有在配置管理中，有一個很重要的概念，那就是基線，是在一定階段各個配置項的組合，一個基線就提供了一個正式的標准，隨后的工作便基於此標准，並只有經過授權后才能變更這個標准。配置管理工具主要有CC，VSS,CVS,SVN等，我只用過SVN，對其他的工具不是很熟悉。

6、怎樣寫測試計划和測試用例？

　簡單點，測試計划里應有詳細的測試策略和測試方法，合理詳盡的資源安排等，至於測試用例，那是依賴於需求(包括功能與非功能需求)是否細化到功能點，是否可測試等。

7、做好軟件測試的一些關鍵點？

　1-測試人員必須經過測試基礎知識和理論的相關培訓

　2-測試人員必須熟悉系統功能和業務

　3-測試要有計划，而且測試方案要和整個項目計划協調好

　4-必須實現編寫測試用例，測試執行階段必須根據測試用例進行

　5-易用性，功能，分支，邊界，性能等功能行和非功能性需求都要進行測試

　6-對於復雜的流程一定要進行流程分支，組合條件分析，再進行等價類划分准備相關測試數據

　7-測試設計的一個重要內容是要准備好具體的測試數據，清楚這個測試數據是測試那個場景或分支的。

　8-個人任務平均每三個測試用例至少應該發現一個BUG，否則只能說明測試用例質量不好。

 

8、軟件測試員自身素質培養？

　1-首先，應對軟件測試感興趣和對自己有自信，如果具備了這兩點，那么在開發過程中不管遇到什么樣的困難，相信一定能克服

　2-善於懷疑，實際上沒有絕對正確的，總有錯誤的地方，具有叛逆心理，別人認為不可能發生的事情，我卻認為可能發生，別人認為是對的，我卻認為不是對的。

　3-打破沙鍋問到底的精神，對於只出現過一次的BUG一定要找出原因，不解決誓不罷休。

　4-保持一個良好的心情，否則可能無法把測試做好。不要把生活中的不愉快的情緒帶到工作中來。

　5-做測試時要細心，不是所有的BUG都能很容易找出，一定要細心才能找到這些BUG。

　6-靈活一些，聰明一點，多造一些容易產生BUG的例子。

　7-在有條件的情況下，多和客戶溝通，他們身上有你所需要的。

　8-設身處地為客戶着想，從他們的角度去測試系統。

　9-不要讓程序員，以“這種情況不可能發生”這句話說服你，相反，你應該去說服他，告訴他在客戶心理，並不是這樣的

　10-考慮問題要全面，結合客戶的需求，業務流程和系統的架構等多方面考慮問題。

　11-提出問題不要復雜化，這點和前面矛盾，如果你是一個新手，暫時不要管這點，因為最終將有你的小組成員討論解決。

　12-追求完美，對於新測試員來說，努力追求完美，這對你很好，盡管有些事情無法做到，但你應該嘗試。

　13-幽默感，能和開發小組很好的溝通是關鍵，試着給你的開發小組找一個BUG殺手，或對他們說“我簡直不敢相信，你寫的程序居然到現在沒有找到BUG”。

9、你所熟悉的軟件測試類型有哪些?

　測試類型有：功能測試、性能測試、界面測試

　1）功能測試在測試工作中占有比例最大，功能測試也叫黑盒測試。

　2）性能測試是通過自動化的測試工具模擬多種正常、峰值以及異常負載條件來對系統的各項性能指標進行測試。負載測試和壓力測試都屬於性能測試，兩者可以結合進行。

　3）界面測試，界面是軟件與用戶交互的最直接的層，界面的好壞決定用戶對軟件的第一印象。

　4）區別在於，功能測試關注產品的所有功能，要考慮到每個細節功能，每個可能存在的功能問題。性能測試主要關注產品整體的多用戶並發下的穩定性和健壯性。界面測試則關注與用戶體驗相關內容，用戶使用該產品的時候是否已用，是否易懂，是否規范(用戶無意輸入無效的數據，當然考慮到體驗性，不能太粗魯的彈出警告)。做某個性能測試的時候，首先它可能是個功能點，首先要保證她的功能是沒有問題的，然后再考慮性能的問題。

10、您認為做好測試計划工作的關鍵是什么?

　1）明確測試的目標，增強測試計划的實用性

　編寫軟件測試計划的重要目的就是使測試過程能夠發現更多的軟件缺陷，因此軟件測試計划的價值取決於它對幫助管理測試項目，並且找出軟件潛在的缺陷。因此，軟件測試計划中的測試范圍必須高度覆蓋功能需求，測試方法必須切實可行，測試工具並且具有較高的實用性，便於使用，生成的測試結果准確

　2）堅持“5W”規則，明確內容與過程

　“5W”規則指的是“WHAT(做什么)”、“WHY(為什么做)”、"WHEN(何時做)"、"WHERE(在哪里)"、"HOW(如何做)"。利用“5W"規則創建軟件測試計划，可以幫助測試團隊理解測試的目的(WHY)，明確測試的范圍和內容(WHAT)，確定測試的開始和結束日期(WHEN)，指出測試的方法和工具(HOW)，給出測試文檔和軟件存放的位置(WHERE)。

　3）采用評審和更新機制，保證測試計划滿足實際需求

　測試計划完成后，如果沒有經過評審，直接發送給測試團隊，測試計划內容的可能不准確或遺漏測試內容，或者軟件需求變更引起測試范圍的增減，而測試計划的內容沒有及時更新，誤導測試執行人員。

　4）分別創建測試計划與測試詳細規格、測試用例

　應把詳細的測試技術指標包含到獨立創建的測試詳細規格文檔，把用於指導測試小組執行過程的測試用例放到獨立創建的測試用例文檔或測試用例管理數據庫中。測試計划和測試詳細規格、測試用例之間是戰略和戰術的關系，測試計划主要從宏觀上規划測試活動的范圍、方法和資源配置，而測試詳細規格、測試用例是完成測試任務的具體戰術。

11、當開發人員說不是BUG時，你如何應付?

　開發人員說不是BUG，有2種情況，一是需求沒有確定，所以我可以這么做，這個時候可以找來產品經理進行確認，需不需要改動。3方商量確定好后再看要不要改。二是這種情況不可能發生，所以不需要修改，這個時候，我可以先盡可能的說出是BUG的一句是什么?如果被用戶發現或出了問題，會有什么不良結果?程序員可能會給你很多理由，你可以對他的解釋進行反駁。如果還是不行，那我可以給這個問題提出來，跟開發經理和測試經理進行確認，如果要修改就改，如果不要修改就不改。其實有些真的不是BUG，我也只是建議的方式寫進測試文檔中，如果開發人員不修改也沒有大問題。如果不是BUG的話，一定要堅持自己的立場，讓問題得到最后的確認。

12、文檔測試主要包含什么內容?

　在國內軟件開發管理中，文檔管理幾乎是最弱的一項，因而在測試工作中特別容易忽略文檔測試也就不足為奇了。要想給用戶提供完整的產品，文檔測試是必不可少的。文檔測試一般注重下面幾個方面：

　1）文檔的完整性：主要是測試文檔內容的全面性與完整性，從總體上把握文檔的質量。例如用戶手冊應該包括軟件的所有功能模塊。

　2）描述與軟件實際情況的一致性：主要測試軟件文檔與軟件實際的一致程度。例如用戶手冊基本完整后，我們還要注意用戶手冊與實際功能描述是否一致。因為文檔往往跟不上軟件版本的更新速度。

　3）易理解性：主要是檢查文檔對關鍵、重要的操作有無圖文說明，文字、圖表是否易於理解。對於關鍵、重要的操作僅僅只有文字說明肯定是不夠的，應該附有圖表使說明更為直觀和明了。

　4）文檔中提供操作的實例：這項檢查內容主要針對用戶手冊。對主要功能和關鍵操作提供的應用實例是否豐富，提供的實例描述是否詳細。只有簡單的圖文說明，而無實例的用戶手冊看起來就像是軟件界面的簡單拷貝，對於用戶來說，實際上沒有什么幫助。

　5）印刷與包裝質量：主要是檢查軟件文檔的商品化程度。有些用戶手冊是簡單打印、裝訂而成，過於粗糙，不易於用戶保存。優秀的文檔例如用戶手冊和技術白皮書，應提供商品化包裝，並且印刷精美。

13、配置和兼容性測試的區別是什么?

　配置測試的目的是保證軟件在其相關的硬件上能夠正常運行，而兼容性測試主要是測試軟件能否與不同的軟件正確協作。

　配置測試的核心內容就是使用各種硬件來測試軟件的運行情況，一般包括：

　(1)軟件在不同的主機上的運行情況，例如Dell和Apple;

　(2)軟件在不同的組件上的運行情況，例如開發的撥號程序要測試在不同廠商生產的Modem上的運行情況;

　(3)不同的外設;

　(4)不同的接口;

　(5)不同的可選項，例如不同的內存大小;

　兼容性測試的核心內容：

　(1)測試軟件是否能在不同的操作系統平台上兼容;

　(2)測試軟件是否能在同一操作系統平台的不同版本上兼容;

　(3)軟件本身能否向前或者向后兼容;

　(4)測試軟件能否與其它相關的軟件兼容;

　(5)數據兼容性測試，主要是指數據能否共享;

　配置和兼容性測試通稱對開發系統類軟件比較重要，例如驅動程序、操作系統、數據庫管理系統等。具體進行時仍然按照測試用例來執行。

14、完全測試程序是可能的嗎?

　軟件測試初學者可能認為拿到軟件后需要進行完全測試，找到全部的軟件缺陷，使軟件“零缺陷”發布。實際上完全測試是不可能的。主要有以下一個原因：

　1）完全測試比較耗時，時間上不允許;

　2）完全測試通常意味着較多資源投入，這在現實中往往是行不通的;

　3）輸入量太大，不能一一進行測試;

　4）輸出結果太多，只能分類進行驗證;

　5）軟件實現途徑太多;

　6）軟件產品說明書沒有客觀標准，從不同的角度看，軟件缺陷的標准不同;

　因此測試的程度要根據實際情況確定。

15、所有的軟件缺陷都能修復嗎?

　從技術上講，所有的軟件缺陷都是能夠修復的，但是沒有必要修復所有的軟件缺陷。測試人員要做的是能夠正確判斷什么時候不能追求軟件的完美。對於整個項目團隊，要做的是對每一個軟件缺陷進行取舍，根據風險決定那些缺陷要修復。發生這種現象的主要原因如下：

　1）沒有足夠的時間資源。在任何一個項目中，通常情況下開發人員和測試人員都是不夠用的，而且在項目中沒有預算足夠的回歸測試時間，再加上修改缺陷可能引入新的缺陷，因此在交付期限的強大壓力下，必須放棄某些缺陷的修改。

　2）有些缺陷只是特殊情況下出現，這種缺陷處於商業利益考慮，可以在以后升級中進行修復。

　3）不是缺陷的缺陷。我們經常會碰到某些功能方面的問題被當成缺陷來處理，這類問題可以以后有時間時考慮再處理。

　最后要說的是，缺陷是否修改要由軟件測試人員、項目經理、程序員共同討論來決定是否修復，不同角色的人員從不同的角度來思考，以做出正確的決定。

16、軟件測試人員就是QA嗎?

　軟件測試人員的職責是盡可能早的找出軟件缺陷，確保得以修復。而質量保證人員(QA)主要職責是創建或者制定標准和方法，提高促進軟件開發能力和減少軟件缺陷。測試人員的主要工作是測試，質量保證人員日常工作重要內容是檢查與評審，測試工作也是測試保證人員的工作對象。

　軟件測試和質量是相輔相成的關系，都是為了提高軟件質量而工作。

17、測試產品與測試項目的區別是什么?

　習慣上把開發完成后進行商業化、幾乎不進行代碼修改就可以售給用戶使用的軟件成為軟件產品，也就是可以買“賣拷貝”的軟件，例如Windows2000。而通常把針對一個或者幾個特定的用戶而開發的軟件成為軟件項目，軟件項目是一種個性化的產品，可以是按照用戶要求全部重新開發，也可以修改已有的軟件產品來滿足特定的用戶需求。項目和產品的不同特點，決定我們測試產品和測試項目仍然會有很多不同的地方：

　1）質量要求不同。通常產品的質量要高一些，修復發布后產品的缺陷成本較高，甚至會帶來很多負面的影響。而做項目通常面向某一用戶，雖然質量越高越好，但是一般只要滿足用戶要求就可以了。

　2）測試資源投入多少不同。做軟件產品通常是研發中心來開發，進度壓力要小些。同時由於質量要求高，因此會投入較多的人力、物力資源。

　3）項目最后要和用戶共同驗收測試，這是產品測試不具有的特點。

　此外，測試產品與測試項目在缺陷管理方面、測試策略制定都會有很大不同，測試管理者應該結合具體的環境，恰如其分的完成工作。

18、如何編寫提交給用戶的測試報告?

　隨着測試工作越來越受重視，開發團隊向客戶提供測試文檔是不可避免的事情。很多人會問：“我們可以把工作中的測試報告提供給客戶嗎?”答案是否定的。因為提供內部測試報告，可能會讓客戶失去信心，甚至否定項目。

　測試報告一般分為內部測試報告和外部測試報告。內部報告是我們在測試工作中的項目文檔，反映了測試工作的實施情況，這里不過多討論，讀者可以參考相關教材。這里主要討論一下外部測試報告的寫法，一般外部測試報告要滿足下面幾個要求：

　-根據內部測試報告進行編寫，一般可以摘錄;

　-不可以向客戶報告嚴重缺陷，即使是已經修改的缺陷，開發中的缺陷也沒有必要讓客戶知道;

　-報告上可以列出一些缺陷，但必須是中級的缺陷，而且這些缺陷必須是修復的;

　-報告上面的內容盡量要真實可靠;

　-整個測試報告要仔細審閱，力爭不給項目帶來負面作用，尤其是性能測試報告。

　總之，外部測試報告要小心謹慎的編寫。

19、測試工具在測試工作中是什么地位?

國內的很多測試工程師對測試工具相當迷戀，尤其是一些新手，甚至期望測試工具可以取代手工測試。測試工具在測試工作中起的是輔助作用，一般用來提高測試效率。自動化測試彌補了手工測試的不足，減輕一定的工作量。實際上測試工具是無法替代大多數手工測試的，而一些諸如性能測試等自動化測試也是手工所不能完成的。

對於自動測試技術，應當依據軟件的不同情況來分別對待，一般自動技術會應用在引起大量重復性工作的地方、系統的壓力點、以及任何適合使用程序解決大批量輸入數據的地方。然后再尋找合適的自動測試工具，或者自己開發測試程序。一定不要為了使用測試工具而使用。

　20、詳細的描述一個測試活動完整的過程？

1）項目經理通過和客戶的交流，完成需求文檔，由開發人員和測試人員共同完成需求文檔的評審，評審的內容包括：需求描述不清楚的地方和可能有明顯沖突或者無法實現的功能的地方。項目經理通過綜合開發人員，測試人員以及客戶的意見，完成項目計划。然后sqa進入項目，開始進行統計和跟蹤

2）開發人員根據需求文檔完成需求分析文檔，測試人員進行評審，評審的主要內容包括是否有遺漏或者雙方理解不同的地方。測試人員完成測試計划文檔，測試計划包括的內容上面有描述。

3）測試人員根據修改好的需求分析文檔開始寫測試用例，同時開發人員完成概要設計文檔，詳細設計文檔。此兩份文檔成為測試人員撰寫測試用例的補充材料。

4）測試用例完成后，測試和開發需要進行評審。

5）測試人員搭建環境

6）開發人員提交第一個版本，可能存在未完成功能，需要說明。測試人員進行測試，發現bug后提交給bugzilla。

　 7）開發提交第二個版本，包括bug fix以及增加了部分功能，測試人員進行測試。

　 8）重復上面的工作，一般是3-4個版本后bug數量減少，達到出貨的要求。

　 9）如果有客戶反饋的問題，需要測試人員協助重現以及回歸測試。

　21、在您以往的工作中，一條軟件缺陷(或者叫bug)記錄都包含了哪些內容?如何提交高質量的軟件缺陷(bug)記錄?

　1）在傳統的bugzilla中，bug描述應該包括以下的信息

　2）和bug產生對應的軟件版本

　3）開發的接口人員

　4）bug的優先級

　5）bug的嚴重程度

　6）bug可能屬於的模塊，如果不能確認，可以用開發人員來判斷

　7）bug標題，需要清晰的描述現象

　8）bug描述，需要盡量給出重新bug的步驟

　9）bug附件中能給出相關的日志和截圖。

　高質量的bug記錄就是指很容易理解的bug記錄，所以，對於描述的要求高，能提供的信息多且准確，很好的幫助開發人員定位。

22.軟件的生命周期（prdctrm）？

計划階段（planning）-〉需求分析（requirement）-〉設計階段（design）-〉編碼（coding）->測試（testing）->運行與維護（running maintrnacne）

23.給你一個網站，你如何測試？

首先，查找需求說明、網站設計等相關文檔，分析測試需求。

制定測試計划，確定測試范圍和測試策略，一般包括以下幾個部分：功能性測試；界面測試；性能測試；數據庫測試；安全性測試；兼容性測試

設計測試用例：

①功能性測試可以包括，但不限於以下幾個方面：

鏈接測試。鏈接是否正確跳轉，是否存在空頁面和無效頁面，是否有不正確的出錯信息返回。

提交功能的測試。

多媒體元素是否可以正確加載和顯示。

多語言支持是否能夠正確顯示選擇的語言等。

②界面測試可以包括但不限於一下幾個方面：

頁面是否風格統一，美觀

頁面布局是否合理，重點內容和熱點內容是否突出

控件是否正常使用

對於必須但未安裝的控件，是否提供自動下載並安裝的功能

文字檢查

③性能測試一般從以下兩個方面考慮：

壓力測試；負載測試；強度測試

④數據庫測試要具體決定是否需要開展。數據庫一般需要考慮連結性，對數據的存取操作，數據內容的驗證等方面。

⑤安全性測試：

基本的登錄功能的檢查

是否存在溢出錯誤，導致系統崩潰或者權限泄露

相關開發語言的常見安全性問題檢查，例如SQL注入等

如果需要高級的安全性測試，確定獲得專業安全公司的幫助，外包測試，或者獲取支持

⑥兼容性測試，根據需求說明的內容，確定支持的平台組合：

瀏覽器的兼容性；

操作系統的兼容性；

軟件平台的兼容性；

數據庫的兼容性

開展測試，並記錄缺陷。合理的安排調整測試進度，提前獲取測試所需的資源，建立管理體系（例如，需求變更、風險、配置、測試文檔、缺陷報告、人力資源等內容）。

定期評審，對測試進行評估和總結，調整測試的內容.

24.軟件產品質量特性是什么?

功能性：適應性、准確性、互操作性、依從性、安全性。

可靠性：成熟性、容錯性、易恢復性。

可使用性：易理解性、易學習性、易操作性。

效率：時間特性、資源特性。

可維護性：易分析性、易變更性、穩定性、易測試性。

25.測試計划編寫6要素（5W1H）？

why——為什么要進行這些測試；

what—測試哪些方面，不同階段的工作內容；

when—測試不同階段的起止時間；

where—相應文檔，缺陷的存放位置，測試環境等；

who—項目有關人員組成，安排哪些測試人員進行測試；

how—如何去做，使用哪些測試工具以及測試方法進行測試

26.BUG管理工具的跟蹤過程（用BugZilla為例子）

1.測試人員發現了BUG，提交到Bugzilla中，狀態為new，BUG的接受者為開發接口人員。

2.開發接口將BUG分配給相關的模塊的開發人員，狀態修改為已分配，開發人員和測試確認BUG，如果是本人的BUG，則設置為接收；如果是別的開發人員的問題，則轉發出去，由下一個開發人員來進行此行為；如果認為不是問題，則需要大家討論並確認后，拒絕這個BUG，然后測試人員關閉此問題。

3.如果開發人員接受了BUG，並修改好以后，將BUG狀態修改為已修復，並告知測試在哪個版本中可以測試。

4.測試人員在新版本中測試，如果發現問題依然存在，則拒絕驗證；如果已經修復，則關閉BUG。

27.LoadRunner分為哪三個模塊？請簡述各模塊的主要功能。

Virtual User Generator：用於錄制腳步

Mercury LoadRunner Controller：用於創建、運行和監控場景

Mercury LoadRunner Analysis：用於分析測試結果

28：你所了解的的軟件測試類型都有哪些？

（1）按測試策略分類：1、靜態與動態測試2、黑盒與白盒測試 3、手工和自動測試 4、冒煙測試 5、回歸測試；

（2）按測試階段分類：單元測試、集成測試、系統測試、驗收測試；

（3）其他常見測試方法：1、功能測試 2、性能測試 3、壓力測試 4、負載測試 5、易用性測試 6、安裝測試 7、界面測試 8、配置測試 9、文檔測試 10、兼容性測試 11、安全性測試 12、恢復測試

29、您是否了解以往所工作的企業的軟件開發過程？如果了解，請試述一個完整的開發過程需要完成哪些工作？分別由哪些不同的角色來完成這些工作？您在以往的測試工作中都曾經具體從事過哪些工作？其中最擅長哪部分工作？

開發過程---需求調研（需求人員）、需求分析（需求人員）、概要設計（設計人員）、詳細設計(設計人員)、編碼（開發人員）

測試過程---需求評審、系統測試設計、概要設計評審、集成測試設計、詳細設計評審、單元測試設計、測試執行

測試工作的整個過程都做過，擅長做測試設計

過程決定質量，軟件的過程改進正是為了提高軟件的質量，將過往的種種經驗教訓積累起來。

30、如何理解壓力、負載、性能測試測試?

性能測試是一個較大的范圍，實際上性能測試本身包含了性能、強度、壓力、負載等多方面的測試內容。

（1）壓力測試是對服務器的穩定性以及負載能力等方面的測試，是一種很平常的測試。增大訪問系統的用戶數量、或者幾個用戶進行大數據量操作都是壓力測試。

（2）負載測試是壓力相對較大的測試，主要是測試系統在一種或者集中極限條件下的相應能力，是性能測試的重要部分。100個用戶對系統進行連續半個小時的訪問可以看作壓力測試，那么連續訪問8個小時就可以認為負載測試，1000個用戶連續訪問系統1個小時也可以看作是負載測試。

實際上壓力測試和負載測試沒有明顯的區分。測試人員應該站在關注整體性能的高度上來對系統進行測試。

31、在搜索引擎中輸入漢字就可以解析到對應的域名，請問如何用LoadRunner進行測試？

1、建立測試計划，確定測試標准和測試范圍

2、設計典型場景的測試用例，覆蓋常用業務流程和不常用的業務流程等

3、根據測試用例，開發自動測試腳本和場景：

4、錄制測試腳本：新建一個腳本（Web/HTML協議）；點擊錄制按鈕，在彈出的對話框的URL中輸入”about:blank”；在打開的瀏覽器中進行正常操作流程后，結束錄制；調試腳本並保存，可能要注意到字符集的關聯。

5設置測試場景：針對性能設置測試場景，主要判斷在正常情況下，系統的平均事務響應時間是否達標；針對壓力負載設置測試場景，主要判斷在長時間處於滿負荷或者超出系統承載能力的條件下，系統是否會崩潰；執行測試，獲取測試結果，分析測試結果

32、STAR法則？

S（situation）：項目屬於什么類型，周期多長

T（task）：團隊分工，你的角色

A（action）：具體實施，自己做了什么

R（result）：最后成果，你的收獲

33、問：我現在有個程序，發現在Windows上運行的很慢，怎么判別是程序存在問題還是軟硬件系統存在問題？

1、檢查系統是否有中毒的特征

2、檢查軟件/硬件的配置是否符合軟件的推薦標准

3、確認當前的系統是否獨立，即沒有對外提供什么消耗CPU資源的服務

4、如果是C/S或者B/S結構的軟件，需要檢查是不是因為與服務器的連接有問題，或者訪問有問題造成

5、在系統沒有任何負載的情況下，查看性能監視器，確認應用程序對CPU/內存的訪問情況

 

34、針對添加購物車這個測試點說一下你要怎么測試“添加購物車”？

參考答案（從增刪改查角度思考）

1、購物車的初始狀態（即GUI）。

2、能否加入購物車，同一件商品能否再次添加到購物車。

3、購物車商品件數的上限限制。

4、購物車是否可以正常移除商品，移除商品后，能否再添加回來。

5、添加的每種商品是否可以正常增減數量，數量大於0。

6、退出購物車，再去查詢購物車，商品是否正常。

7、購物車的商品可以全選，取消全選，可以復選，選中的商品和數量可以正常下單。

8、商品添加到購物車以后，已下架，購物車是否會提示此寶貝已失效。

9、商品添加到購物車以后，庫存不足了，是否會有提示。

 

35互聯網第三方基金銷售公司，你們要做哪些測試？

　　答：這個好像內容較多，具體我們做了哪些類型測試，我可以說這個系統什么樣的測試都做了，比如：

          1. 業務規則測試

          2.功能測試

          3.用戶界面測試

          4. 接口測試

          5. 性能測試

          6.遷移測試

          7.兼容性測試和安全測試等，

其中我認為做的比較好的是性能測試、遷移測試和接口測試，因為中間碰到過非常多的坑，而且也成功挑戰；其中也踩過很多坑，也有太多的酸甜苦辣，當然對我和團隊來講，能力的成長也是幾何式的增長；就像我的技術大領導說的，如果你能成功挑戰這么復雜的業務系統，和這么龐大的系統架構，其它公司系統測試你在看，你會發現都是非常輕松的，想想也是這個道理；有句話說的話，要想做一件事非常容易，哪你應是非常努力去做，才能看起來很容易，好像這話很繞，道理就是這樣的。

36.測試類型分類？

1 用戶界面測試，用戶界面測試是對所有人機交互界面提供的操作和顯示界面進行的測試，一般我們都是對照需求文檔及設計稿進行檢查；

2 功能測試，針對軟件需求規格說明書中的功能進行逐項進行的測試驗證，檢查是否滿足要求；

3 性能測試，通過用采用工具模擬系統，並發一定虛擬用戶，對系統造成一定負載，來檢查系統的各項性能指標進行測試，這里的性能測試我們更側重講的是整個系統性能測試來談，當然性能測試常見的分類一般會分為基准測試，負載測試，壓力測試，容量測試和穩定性測試；

3.1 基准測試，簡單理解就是檢查系統在並發1個用戶時，各系統性能指標是否正常，以次做為一個基線，來檢查后續修改是否造成系統倒退；

3.2 負載測試，更側重要系統所處於某個固定負載，各系統性能指標是否正常；

3.3 壓力測試，系統處於一定並發用戶時，性能的拐點，系統所能承受到的最大壓力是多少？

3.4 容量性測試，通常是檢查系統在承受具體業務量時，是否可以支持，如：最常見的短信容量，存儲空量容量，數據增長容量達到多少時處理效率降低；

3.5 穩定性測試，通常是和可靠性測試聯系在一起，一般我們會檢查系統在一定並發值范圍內，掛續72小時來檢查系統是否可以正常，當然內部測試一般采用8小時制；

4 接口測試，接口測試主要用於檢測外部系統與系統之間以及內部各個子系統之間的交互點；數據的交換，傳遞和控制管理過程，以及系統間的相互邏輯依賴關系等；

備注：有些公司接口測試是屬於開發人員工作，測試人員不用需接觸，但從個人發展來看，接觸越多，測試人員才有更多的發展機會 

5 兼容性測試，是指測試軟件在特定的硬件平台上、不同的應用軟件之間、不同的操作系統平台上、不同的網絡等環境中是否能夠很友好的運行的測試；

6 安全測試，是有關驗證應用程序的安全服務和識別潛在安全性缺陷的過程；

7 邊界測試或極限測試，就是用來探測和驗證代碼在處理極端的或偏門的情況時會發生什么，通常針對輸入域/輸出域的邊界，當然還有（1、數據結構的邊界；2、狀態轉換的邊界；3、功能界限的邊界或端點。）

備注：邊界測試其實更應是一種測試方法或是思維，嚴格來講不應算是一種測試類型，所以我增加叫“極限測試”

8 可安裝性測試和反安裝性測試，在目標環境安裝軟件的安裝程序所進行的測試，比如安裝QQ，需要在各操作系統環境下檢查，這個很好理解；

9 可靠性測試，也稱軟件的可靠性評估，指根據軟件系統可靠性結構(單元與系統間可靠性關系)、壽命類型和各單元的可靠性試驗信息，利用概率統計方法，評估出系統的可靠性特征量；

備注：這個一般做的比較少，通常一般在偏像通訊行業比較多，我平時所接觸到朋友中；

10 可恢復性測試，檢查系統的容錯能力。當系統出錯時，能否在指定時間間隔內修正錯誤並重新啟動系統，也有人叫自愈測試，其實就是當我們系統出現問題時，系統是否可以恢復到正常。 

11  配置測試，檢查系統在某種配置下是否可以正常運行，這個很好理解，如大家經常談買什么樣的電腦？什么樣的配置才是最好的，性價比最高的？我這里更強調的系統的配置，比如我接觸過有的系統當我們在上線前，通常對線程開幾個，在某個特定系統下進行檢查驗證，會有一個合理值，好像和兼容性測試很類似，其實並不是一回事；

12  敏感性測試，發現在有效輸入類中可能引起某種不穩定性或不正常處理的某些數據的組合而進行的測試。例：輸入敏感詞匯

13 標准符合性測試，驗證軟件與相關國家標准或規范（如軍用標准、國家標准、行業標准及國際標准）一致性的測試，如：通訊行業或是航天等都有各自標准，這個也很好理解，就像我們日常生活用品一樣，你不會買沒達到標准的產品吧，萬一有毒呢？

14 中文本地化測試，就是將軟件版本語言進行更改，檢查是否符合當地語言，在特定環境下是否正常，如微信的操作系統，這個估計很好理解，大家都接觸過；

15  文檔測試，檢查系統交付給用戶時，所附屬的文檔測試，通常是照着文檔進行驗證，如：系統幫助、用戶使用手冊、用戶安裝手冊，這個很好理解；

16 易用性測試，系統是否用學習，易用使用，易於理解，通常由專有的用戶體驗師團隊負責；

17 數據完整性測試，檢查針對系統對數據進行操作，重點是檢查數據一致性，完整性，正確性測試，如果你做過支付測試，估計對這塊是非常敏感，我目前做支付測試，數據庫測試可以說是我們工作的重中之中；

18  遷移測試，檢查系統從某個環境遷移到另一個環境，重點是檢查新舊系統之間數據是否兼容，各業務是否可以正常，如：將oracle數據庫切換成mysql，或是將歷史會員數據遷移升級成新系統架構中

 

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　第四章  數據庫相關知識

數據庫（視圖、事務、存儲過程、函數） && 數據庫備份

1. 視圖：

 視圖就是通過查詢得到一張虛擬表，然后保存下來，下次直接使用即可 （視圖就是查詢得到的虛擬表）

視圖的特點：

　　1.視圖的列可以來自不同的表，是表的抽象和邏輯意義上建立的新關系；

　　2.視圖是由基本表（實表）產生的表（虛表）；

　　3.視圖的建立和刪除不影響基本表；

　　4.對視圖內容的更新（添加、刪除和修改）直接影響基本表；

　　5.當視圖來自多個基本表時，不允許添加和刪除數據。

  注意：1、在硬盤中，視圖只有表結構文件，沒有表數據文件，數據來源於原始表  

       2、視圖一般只用於查詢，一般不修改表中的數據，在公司一般不使用視圖

-- 創建視圖

　　create view 視圖名 as sql語句;

　　create view v1 as select id,name from userinfo;

-- 使用視圖

　　select * from 視圖名;

　　select * from v1;

-- 更新視圖

　　alter view 視圖名 as sql語句;

　　alter view v1 as select id,name from userinfo where id<10;

-- 刪除視圖

    drop view 視圖名;

    drop view v1;

2. 事務

事務：開啟一個事務可以包含一些sql語句，這些sql語句要么同時成功  要么一個都別想成功，稱之為事務的原子性

（1）原子性（atomicity）。一個事務是一個不可分割的工作單位，事務中包括的諸操作要么都做，要么都不做。

（2）一致性（consistency）。事務必須是使數據庫從一個一致性狀態變到另一個一致性狀態。一致性與原子性是密切相關的。

（3）隔離性（isolation）。一個事務的執行不能被其他事務干擾。即一個事務內部的操作及使用的數據對並發的其他事務是隔離的，並發執行的各個事務之間不能互相干擾。

（4）持久性（durability）。持久性也稱永久性（permanence），指一個事務一旦提交，它對數據庫中數據的改變就應該是永久性的。接下來的其他操作或故障不應該對其有任何影響。

create table user(

id int primary key auto_increment,

name char(32),

balance int

);

 

insert into user(name,balance)

values

('wsb',1000),

('egon',1000),

('ysb',1000);

start transaction;

 

# 修改操作

update user set balance=900 where name='wsb'; #買支付100元

update user set balance=1010 where name='egon'; #中介拿走10元

update user set balance=1090 where name='ysb'; #賣家拿到90元

# 回滾到上一個狀態

rollback;

# 開啟事務之后，只要沒有執行commit操作，數據其實都沒有真正刷新到硬盤

commit;

"""開啟事務檢測操作是否完整，不完整主動回滾到上一個狀態，如果完整就應該執行commit操作"""

3. 觸發器

觸發器：監視某種情況，並觸發某種操作；對某個表進行【增/刪/改】操作的前后如果希望觸發某個特定的行為時，可以使用觸發器，觸發器用於定制用戶對表的行進行【增/刪/改】前后的行為。

觸發器創建語法四要素：

　　1.監視地點(table)

　　2.監視事件(insert/update/delete)

　　3.觸發時間(after/before)

　　4.觸發事件(insert/update/delete)

創建觸發器語法        

create trigger 觸發器名 after/before insert/update/delete

　　on 表名 for each row  -- 這句是固定的

begin

　　-- begin和end中間放置需要執行的sql語句

end

 

after/before：只能選一個 , after(后置觸發), before(前置觸發)

insert/update/delete：只能選一個

 

使用觸發器

-- 商品表

create table goods_tb(

  id int primary key auto_increment,

  name varchar(20),

  num int

); 

-- 訂單表

create table order_tb(

    oid int primary key auto_increment,

    gid int,

    gnum int

); 

-- 添加3條商品數據

insert into goods_tb(name,num) values('商品1',10),('商品2',10),('商品3',10);

4. 存儲過程

存儲過程：存儲過程是為了完成某個數據庫中的特定功能而編寫的語句集合；該語句集包括SQL語句（對數據的增刪改查）、條件語句和循環語句等......當主動去調用存儲過程時，其中內部的SQL語句會按照邏輯執行。

無參數存儲過程

-- 看現有的存儲過程

    show procedure status; 

-- 創建存儲過程（無參數示例）

    create procedure p1()

    begin

    select * from t1;

    end

-- 調用存儲過程

    call 存儲過程名稱(參數類型 參數名 數據類型);

-- 刪除存儲過程

    drop procedure 存儲過程名稱;

有參數存儲過程

create procedure p2(in i int,inout io varchar(50))

begin

update goods_tb set name=io where id=i;

end

set @io="商品100";   # 設置初始值

call p2(3,@io);     # 執行存儲調用

select @io;         # 拿到結果

create procedure p3(in i int,out o varchar(50))

begin

select name into o from teacher where id = i;

end

set @name=null;

call p3(1,@name);

select @name;

對於存儲過程，可以接收參數，其參數有三類：
in           僅用於傳入參數用
out         僅用於返回值用
inout      既可以傳入又可以當作返回值

# 存儲過程優點：

    1.存儲過程增強了SQL語言靈活性

        存儲過程可以使用控制語句編寫，可以完成復雜的判斷和較復雜的運算，有很強的靈活性

    2.減少網絡流量，降低了網絡負載

        存儲過程在服務器端創建成功后，只需要調用該存儲過程即可，而傳統的做法是每次都將大量的SQL語句通過網絡發送至數據庫服務器端然后再執行

    3.存儲過程只在創造時進行編譯，以后每次執行存儲過程都不需再重新編譯

        一般SQL語句每執行一次就編譯一次，所以使用存儲過程可提高數據庫執行速度

# 存儲過程缺點：    

    1.擴展功能不方便

2.不便於系統后期維護

 

5. 函數

MySQL中提供了許多內置函數

-- 創建自定義函數

create function func1(

    i1 int,

    i2 int)

returns int  -- 設置返回類型

begin

    declare num int;  -- 聲明num類型

    set num=i1+i2;

    return(num);

end

 

-- 調用自定義函數

select func1(1,5);

在sql語句中使用自定義函數

select func1(參數1,參數2),字段名 from 表名;

刪除自定義函數

drop function 自定義函數名;

函數與存儲過程的區別：