2016年終總結——測試基礎篇（一）

      2016年立刻就要過去了，做爲一個沒有測試培訓經驗就直接上崗的測試人員，感受有必要對本身這近一年的測試工做作個總結。一是回顧下這一年作了什麼，二是爲之後的工做提供個借鑑，讓本身能在測試道路上走的更加清晰。

      可是發現本身竟然無從提及......尷尬之餘想起一種另類的總結，拿幾套面試題來談一談，由於本身也沒有培訓經歷，理論方面就看過一本Software Testing，就結合本身的實際工做來檢驗下可否經過面試吧。

      

軟件測試面試題和答案

1、判斷題

1．軟件測試的目的是儘量多的找出軟件的缺陷。（Y）

2．Beta測試是驗收測試的一種。（Y）

3．驗收測試是由最終用戶來實施的。（N）

4．項目立項前測試人員不須要提交任何工件。（Y）

5．單元測試能發現約80%的軟件缺陷。（Y）

6．代碼評審是檢查源代碼是否達到模塊設計的要求。（N）

7．自底向上集成須要測試員編寫驅動程序。（Y）

8．負載測試是驗證要檢驗的系統的能力最高能達到什麼程度。（N）

9．測試人員要堅持原則，缺陷未修復完堅定不予經過。（N）

10．代碼評審員通常由測試員擔任。（N）

11．咱們能夠人爲的使得軟件不存在配置問題。（N）

12．集成測試計劃在需求分析階段末提交。（N）

判斷題解析總結：

1.軟件測試的目的。曾在Software Testing這本書中看到，軟件測試的目的不是發現全部缺陷提交一個完美的產品，軟件測試的目的是在軟件上線前儘量早的發現更多的bug。那麼這裏我還想談下爲何要儘早的發現bug。

      以咱們公司爲例，一個bug的生命週期包括提交→確認→分配→設計→處理→申請發版→已發版→測試經過→關閉，一旦在迴歸測試過程當中發現問題，那麼會將這個BUG打回到確認狀態再進行一次處理。這是時間的浪費，這是成本的增長。若是在設計及處理階段就能把問題處理的乾淨利落，那麼會省不少麻煩，而作到這一點可能就還須要在處理完成後添加單元測試，或者是Code Review，可是這樣也會增長成本，而且對測試人員的要求能力更高，否則無法體現出這個位置的價值。沒有單元測試或Code Review那就須要開發人員提升自測的質量了。

2.驗收測試：驗收測試包括alpha測試，beta測試，驗收測試。我並無這三種驗收測試的理論概念，先來看下百度是怎麼定義這三種測試的：

      Alpha測試是由用戶在開發環境下進行的測試，也能夠是開發機構內部的用戶在模擬實際操做環境下進行的測試。開發者坐在用戶旁邊，這是在開發者受控的環境下   進行的測試。由開發者隨時記錄下錯誤狀況和使用中的問題並進行修改。

     Beta測試是由軟件的多個用戶在一個或多個用戶的實際使用環境下進行的測試，它是在系統根本完成時進行的測試。開發者一般不在測試現場，這是在開發者沒法控制的環境下進行的測試。由用戶記錄下遇到的全部問題，按期向開發者報告。beta測試是一模擬真實的使用環境從而發現缺陷的一種測試

      驗收測試是以用戶爲主的測試，軟件開發和QA人員也應該參加，測試通常在用戶所在地進行，由用戶驗證軟件產品是否知足了全部的需求的一系列的驗收測試工       做。僅限於作項目的公司，部門內部測試穩定後，根據合同中需求由發包商進行驗收測試。驗收測試的目的是爲了以發現」未實現的需求」爲目的，以評估」適合使用」爲目標，   該類測試的不是以發現缺陷爲主要目的。

     我認爲不一樣公司對於驗收測試的方法是不同的。以咱們公司的項目爲例：咱們的驗收測試通常分爲兩種，普通專題類驗收測試和大型項目更新驗收測試。當客戶須要上線一個新功能（專題），當咱們測試人員測試完畢，會提供給客戶一個相對穩定的服務器環境進行測試，客戶將問題直接反饋給測試人員，再由咱們測試人員與開發溝通；大型項目更新換代測試的話，這個就須要客戶駐場測試，來到咱們公司進行驗收測試，會直接與開發及咱們測試進行溝通。結合實際工做來講，咱們的驗收測試並無說很好的吻合這三種測試的哪種，我認爲這個要根據項目的實際須要來。alpha測試有點像咱們外派測試人員，beta測試有點像咱們的專題驗收測試，而驗收測試則與客戶來咱們公司進行駐場驗收有點相像。

3.測試流程規範：上面已經提到了咱們bug管理生命週期，其實這也是一個測試流程規範。在bug處理完成階段，開發會進行代碼評審；在測試階段，咱們會有測試案例評審；在發版上線階段，咱們還會有開發和測試共同的bug評審。通過這一系列工做，一個bug的修改或者一個新功能纔會提交到生產環境。那麼一樣也會遇到這樣一個尷尬的問題，若是一個功能已經到了計劃上線日期，還有缺陷存在，那究竟是上仍是不上。相信不少測試人員都會遇到這樣的問題。那在咱們這邊是怎麼處理的呢？在這裏首先咱們還要有這樣一個概念：軟件缺陷等級。在簡答題中也有問到。

A類—嚴重錯誤，包括如下各類錯誤： 1． 因爲程序所引發的死機,非法退出 2． 死循環 3． 數據庫發生死鎖 4． 因錯誤操做致使的程序中斷 5． 功能錯誤 6． 與數據庫鏈接錯誤 7． 數據通信錯誤

B類—較嚴重錯誤，包括如下各類錯誤： 1． 程序錯誤 2． 程序接口錯誤 3． 數據庫的表、業務規則、缺省值未加完整性等約束條件

C類—通常性錯誤，包括如下各類錯誤： 1． 操做界面錯誤（包括數據窗口內列名定義、含義是否一致） 2． 打印內容、格式錯誤 3． 簡單的輸入限制未放在前臺進行控制 4． 刪除操做未給出提示 5． 數據庫表中有過多的空字段

D類—較小錯誤，包括如下各類錯誤： 1． 界面不規範 2． 輔助說明描述不清楚 3． 輸入輸出不規範 4． 長操做未給用戶提示 5． 提示窗口文字未採用行業術語 6． 可輸入區域和只讀區域沒有明顯的區分標誌

E類—測試建議

     對於一個不完美的功能，咱們會評審是否知足上線需求，在不影響正常的用戶體驗的狀況下，是可讓軟件帶着缺陷上線的，可是若是有重大缺陷BUG級別，那是沒辦法上線的。若是非要上線，測試人員必定要記得寫一份測試報告，將軟件缺陷及影響程度詳細記錄發給上級領導，這個鍋不能隨便背!

2、選折

1．軟件驗收測試的合格經過準則是：（ABCD）

A．軟件需求分析說明書中定義的全部功能已所有實現，性能指標所有達到要求。

B．全部測試項沒有殘餘一級、二級和三級錯誤。

C．立項審批表、需求分析文檔、設計文檔和編碼實現一致。

D．驗收測試工件齊全。

2．軟件測試計劃評審會須要哪些人員參加？（ABCD）

A．項目經理

B．SQA負責人

C．配置負責人

D．測試組

3．下列關於alpha測試的描述中正確的是：（AD）

A．alpha測試須要用戶表明參加

B．alpha測試不須要用戶表明參加

C．alpha測試是系統測試的一種

D．alpha測試是驗收測試的一種

4．測試設計員的職責有：（BC）

A．制定測試計劃

B．設計測試用例

C．設計測試過程、腳本

D．評估測試活動

5．軟件實施活動的進入準則是：（ABC）

A．需求工件已經被基線化

B．詳細設計工件已經被基線化

C．構架工件已經被基線化

D．項目階段成果已經被基線化

3、添空

1.軟件驗收測試包括：正式驗收測試，alpha測試，beta測試。

2.系統測試的策略有：功能測試，性能測試，可靠性測試，負載測試，易用性測試，強度測試，安全測試，配置測試，安裝測試，卸載測試，文擋測試，故障恢復測試，界面測試，容量測試，兼容性測試，分佈測試，可用性測試，（有的能夠合在一塊兒，分開寫只要寫出15就滿分哦）

3.設計系統測試計劃須要參考的項目文擋有：軟件測試計劃，軟件需求工件和迭代計劃。

4.對面向過程的系統採用的集成策略有：自頂向下，自底向上兩種。

5.（這題出的有問題哦，詳細的5步驟爲~~）經過畫因果圖來寫測試用例的步驟爲：

（1）分析軟件規格說明描述中，哪些是緣由（即輸入條件或輸入條件的等價類），哪些是結果（即輸出條件），並給每一個緣由和結果賦予一個標識符。

（2）分析軟件規格說明描述中的語義，找出緣由與結果之間，緣由與緣由之間對應的是什麼關係?根據這些關係，畫出因果圖。

（3）因爲語法或環境限制，有些緣由與緣由之間，緣由與結果之間的組合狀況不可能出現。爲代表這些特殊狀況，在因果圖上用一些記號標明約束或限制條件。

（4）把因果圖轉換成斷定表。

（5）把斷定表的每一列拿出來做爲依據，設計測試用例。

4、簡答（資料是蒐集整理的，感謝前輩的解題）無

1.區別階段評審的與同行評審

同行評審目的:發現小規模工做產品的錯誤,只要是找錯誤;

階段評審目的:評審模塊階段做品的正確性可行性及完整性

同行評審人數:3-7人人員必須通過同行評審會議的培訓,由SQA指導

階段評審人數:5人左右評審人必須是專傢俱備系統評審資格

同行評審內容:內容小通常文檔<  40頁,代碼< 500行

階段評審內容:內容多,主要看重點

同行評審時間:一小部分工做產品完成

階段評審時間:一般是設置在關鍵路徑的時間點上!

2.什麼是軟件測試

爲了發現程序中的錯誤而執行程序的過程

3簡述集成測試的過程

系統集成測試主要包括如下過程：

1.構建的確認過程。

2.補丁的確認過程。

3.系統集成測試測試組提交過程。

4.測試用例設計過程。

5.測試代碼編寫過程。

6. Bug的報告過程。

7.每週/每兩週的構建過程。

8.點對點的測試過程。

9.組內培訓過程。

4怎麼作好文檔測試

仔細閱讀，跟隨每一個步驟，檢查每一個圖形，嘗試每一個示例。P142

檢查文檔的編寫是否知足文檔編寫的目的

內容是否齊全，正確

內容是否完善

標記是否正確

5白盒測試有幾種方法

整體上分爲靜態方法和動態方法兩大類。

靜態：關鍵功能是檢查軟件的表示和描述是否一致,沒有衝突或者沒有歧義

動態：語句覆蓋、斷定覆蓋、條件覆蓋、斷定條件覆蓋、條件組合覆蓋、路徑覆蓋。

6系統測試計劃是否須要同行審批，爲何

須要，系統測試計劃屬於項目階段性關鍵文檔，所以須要評審。

7Alpha測試與beta的區別

Alpha測試在系統開發接近完成時對應用系統的測試；測試後仍然會有少許的設計變動。這種測試通常由最終用戶或其它人員完成，不能由程序或測試員完成。

Beta測試當開發和測試根本完成時所作的測試，最終的錯誤和問題須要在最終發行前找到。這種測試通常由最終用戶或其它人員完成，不能由程序員或測試員完成。

8比較負載測試，容量測試和強度測試的區別

負載測試：在必定的工做負荷下，系統的負荷及響應時間。

強度測試：在必定的負荷條件下，在較長時間跨度內的系統連續運行給系統性能所形成的影響。

容量測試：容量測試目的是經過測試預先分 析出反映軟件 系統應用特徵的某項指標的極限值（如最大併發用戶數、數據庫記錄數等），系統在其極限值狀態下沒有出現任何軟件故障或還能保持主要功能正常運行。容量測試 還將肯定測試對象在給定時間內可以持續處理的最大負載或工做量。容量測試的目的是使系統承受超額的數據容量來發現它是否可以正確處理。容量測試是面向數據 的，而且它的目的是顯示系統能夠處理目標內肯定的數據容量。

9測試結束的標準是什麼？

用例所有測試。
覆蓋率達到標準。
缺陷率達到標準。
其餘指標達到質量標準

實際工做總結：測試案例執行完畢；測試覆蓋率達到標準；缺陷率達到標準；驗收測試完畢，提交驗收報告。

10描述軟件測試活動的生命週期？

測試周期分爲計劃、設計、實現、執行、總結。其中：

計劃：對整個測試周期中全部活動進行規劃，估計工做量、風險，安排人力物力資源，安排進度等；
設計：完成測試方案，從技術層面上對測試進行規劃；
實現：進行測試用例和測試規程設計；
執行：根據前期完成的計劃、方案、用例、規程等文檔，執行測試用例。

總結：記錄測試結果，進行測試分析，完成測試報告。

實際工做總結：上面談到了bug的生命週期，這裏談的是測試活動生命週期。在個人測試工做中，是這樣的：

 1.肯定測試範圍。（大致知道本身要測試哪些東西）

 2.制定測試計劃。（大致分析出須要多長時間能夠測試完成並制定計劃）

 3.若是做爲一個測試團隊來講的話，多人共同測試的話還須要進行測試分工。

 4.拿到具體的測試功能模塊，就要進行測試案例設計編寫了。

 5.進行測試案例評審。

 6.執行測試案例。

 7.測試總結。

11軟件的缺陷等級應如何劃分？

見判斷分析

 

 ------------------------------------------------------未完待續----------------------------------------------------------------