軟件測試工程師工作總結

 

1.、為什么要在一個團隊中開展軟件測試工作？

因為沒有經過測試的軟件很難在發布之前知道該軟件的質量，就好比ISO質量認證一樣，測試同樣也需要質量的保證，這個時候就需要在團隊中開展軟件測試的工作。在測試的過程發現軟件中存在的問題，及時讓開發人員得知并修改問題，在即將發布時，從測試報告中得出軟件的質量情況。

2.、測試能給你帶來什么樣的快樂？
    測試可以給我帶來很多快樂,如果測試出一個項目缺少東西,我會很高興,因為我對自己的工作有了新的認識,也為公司做了效益;如果測試出一個項目沒有問題,我也很高興,因為同事們都在努力,大家都希望為公司做貢獻,這就是一個很強大的團隊，這是一件多么另人振奮的事情啊!

27、文檔測試要注意什么？

文檔的讀者群、文檔的術語、文檔的正確性、文檔的完整性、文檔的一致性、文檔的易用性、樣例與示例、文檔的語言

3.、軟件測試的目的？
    測試的目的是以最少人力、物力和時間找出軟件中潛在各種錯誤和缺陷，通過修正種錯誤和缺陷提高軟件質量，回避軟件發布后由于潛在的軟件缺陷和錯誤造成的隱患帶來的商業風險。

4.、Alpha測試與beta測試的區別

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

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

5.、簡述集成測試的過程

1. 構建的確認過程。2. 補丁的確認過程。3.    Z34 。4. 測試用例設計過程。5. 測試代碼編寫過程。6. Bug的報告過程。7. 每周/每兩周的構建過程。8. 點對點的測試過程。9. 組內培訓過程。

集成測試過程:集成測試計劃->集成測試設計->集成測試實現->集成測試執行。

6.、質量的八大特性是什么？各種特性的定義？

1）功能性：軟件所實現的功能達到它的設計規范和滿足用戶需求的程度2）性能：在規定條件下,實現軟件功能所需的響應時間和計算機資源(CPU、內存、磁盤空間和數據吞吐量)的使用程度3）可靠性：在滿足一定條件的應用環境中，軟件能夠正常維持其工作的能力，在出現一些錯誤操作時，軟件可以具有容錯性，如果軟件意外退出，重新啟動后可以恢復最近的軟件數據4）安全性：為了防止意外或人為的破壞，軟件應具備的自身保護能力5）使用性：用戶在理解、學習和操作軟件的過程中的付出的努力的難易程度6）維護性：軟件在運行維護過程中，如果出現了運行故障或者擴展新功能和性能，軟件系統是否具有可分析性和良好的擴展性，重新設計后的軟件的穩定性和可測試性7）移植性：軟件從現有運行平臺向另一個運行平臺過度的適應程度和平臺可替換性8）重用性：整個軟件或其中一部分能作為軟件包而被再利用的程度

7.、系統測試計劃是否需要同行審批，為什么

需要，系統測試計劃屬于項目階段性關鍵文檔，因此需要評審。

8.、軟件質量應該從哪些方面來評價？

可靠性、安全性、性能、易用性、外觀、穩定性

9.、系統測試包含哪些方面？

1.恢復測試、2.安全測試、3.強度測試、4.性能測試

10.、區別階段評審的與同行評審

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

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

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

階段評審人數:5人左右 評審人必須是專家 具有系統評審資格

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

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

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

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

11.、測試結束的標準是什么？

1.用例全部執行。2.覆蓋率達到標準。3.缺陷率達到標準。4.其他指標達到質量標準

12.、制定測試計劃之前需要了解什么問題？

1.軟件測試計劃的目的是什么？是否所有人都知道？他們同意這個測試計劃過程嗎？

2.測試的是什么產品？是新程序還是維護升級的？是獨立程序還是由多個小程序組成的？

3.產品的質量目標是什么？產品的功能需求和性能指標必須得到所有人的一致認可。

13.、請詳述設計測試用例的方法？ （只是列出一個測試用例思考的方向，具體設計靠經驗）

①黑盒測試用例根據業務需求說明書來設計，分為：

等價劃分法邊界值分析法錯誤推測法因果圖法邏輯覆蓋法

②白盒測試用例通過研究代碼與程序結構可以分為以下兩種方式：

靜態測試：通過靜態的檢查程序代碼、界面、文檔中可能存在的錯誤的過程。

|-測試代碼編寫的規范性 |-測試界面 |-測試相關需求說明和用戶手冊是否符合實際要求

動態測試：通過路徑和分支測試。測試用例主要根據以下六種覆蓋測試方法設計

|-語句覆蓋 |-判定覆蓋 |-條件覆蓋 |-判定/條件覆蓋 |-組合覆蓋 |-路徑覆蓋

14.、比較負載測試，壓力測試，容量測試和強度測試的區別

負載測試：在一定的工作負荷下，系統的負荷及響應時間。通過逐步增加系統負載，最終確定在滿足性能指標的情況下，系統能承受的最大負載量的測試。

強度測試：又稱疲勞強度測試，在系統穩定運行的情況下能夠支持的最大并發用戶數，持續執行一段時間業務，通過綜合分析，確定系統處理最大工作量強度性能的過程。一定負荷條件下，在較長時間跨度內的系統連續運行給系統性能所造成的影響。

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

壓力測試：通過逐步增加系統負載，最終確定在什么負載條件下系統性能將處于崩潰狀態，以此獲得系統能提供的最大服務級別的測試。

 

15.、測試人員需要何時參加需求分析？

如果條件允許，原則上來說是越早介入需求分析越好。因為測試人員對需求理解越深刻，對測試工作的開展越有利，可以盡早的確定測試思路，減少與開發人員的交互，減少對需求理解上的偏差。

16.、軟件的缺陷等級應如何劃分？

嚴重：1.由于程序所引起的死機,非法退出 2.死循環 3.數據庫發生死鎖 4.因錯誤操作導致的程序中斷 5.功能錯誤 6.與數據庫連接錯誤 7. 數據通訊錯誤。 較嚴重：1.程序錯誤 2.程序接口錯誤 3.數據庫的表、業務規則、缺省值未加完整性等約束條件。一般性：1.操作界面錯誤（包括數據窗口內列名定義、含義是否一致） 2.打印內容、格式錯誤 3.簡單的輸入限制未放在前臺進行控制 4.刪除操作未給出提示 5.數據庫表中有過多的空字段。建議：1.界面不規范 2.輔助說明描述不清楚 3.輸入輸出不規范 4.長操作未給用戶提示 5.提示窗口文字未采用行業術語 6.可輸入區域和只讀區域沒有明顯的區分標志 。

17.、你自認為測試的優勢在哪里？

　　優勢在于我對測試堅定不移的信心和熱情，雖然經驗還不夠，但測試需要的基本技能我有信心在工作中得以發揮。

18.、你在測試中發現了一個bug，但是開發經理認為這不是一個bug，你應該怎樣解決。

   1. 如果不是錯誤則應該主動承認不是缺陷。

   2. 如果是需求不明確的則應和開發加強溝通補充需求。

   3. 如果和開發爭論不休應該邀請上級判斷。

19.、 您認為做好測試計劃工作的關鍵是什么？
　　1. 明確測試的目標，增強測試計劃的實用性

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

3．采用評審和更新機制，保證測試計劃滿足實際需求
    4. 分別創建測試計劃與測試詳細規格、測試用例

20.、風險和問題

◆市場的壓力◆ 測試時間不夠◆ 測試資源的及時到位◆ 測試人員的技能需求◆ 開發進度的變化，需求的變更◆ 開發部門的版本控制◆ 短時間上線。這個是已經定好的，沒有參考測試人員的意見。時間短往往不能得到充分的測試，測試策略必須根據可用的時間進行調整。盡快指出這樣的問題非常重要，只有這樣才能調整時間表，確定快速開發的風險并制定降低風險的策略。◆ 新的設計過程。引入新的設計過程會增加風險，新的設計過程包括新的工具和設計技術。如果采用新的技術，能否像我們預期的那樣運轉，都存在很大的風險◆ 復雜性。我們應該進行一些分析工作來確定哪個功能最復雜，哪個功能最容易出錯，錯誤會對系統的哪些地方造成重大的影響。◆ 使用頻率。軟件最常用功能中隱藏的問題可能給用戶造成嚴重的損失。◆ 不可測試的需求。不可測試的需求會對系統的成功造成巨大的威脅。如果測試組在需求階段就驗證了需求的可測試性，對需求進行了評審，那么此類問題會減少很多。

21.、軟件都有多少種分類?

  固件、支持軟件、系統軟件、應用軟件

22.、你認為軟件測試過程中較常見的困難是什么？如何有效克服這些困難？ （根據自己實際測試中遇到的情況來寫的）

①?Bug的重現問題：有些Bug只是偶爾出現的，根本就不知道具體需要什么條件          才能重現Bug.

?解決方法：將不能重現的Bug，利用截圖的方式記錄下來。并說明一系列的操作步驟

②?Bug的更新：舊的Bug修改好之后，很多時候會引發更多Bug的出現。

?解決方法：對更新的功能模塊重點的測試之后，再重新測試和更新的功能密切的模塊，會不會產生新的Bug.

③?與開發人員的溝通和對業務流程理解的分歧，經常缺少需求文檔

?解決方法：根據需求說明書和Bug情況，多多和開發人員進行交流

23.、測試計劃工作的目的是什么？測試計劃工作的內容都包括什么？其中哪些是最重要的？

軟件測試計劃是指導測試過程的綱領性文件，對測試工作的計劃和安排包含了產品概述、測試策略、測試方法、測試區域、測試配置、測試周期、測試資源、測試交流、風險分析等內容。借助軟件測試計劃，參與測試的項目成員，尤其是測試管理人員，可以明確測試任務和測試方法，保持測試實施過程的順暢溝通，跟蹤和控制測試進度，應對測試過程中的各種變更。

測試計劃和測試詳細規格、測試用例之間是戰略和戰術的關系，測試計劃主要從宏觀上規劃測試活動的范圍、方法和資源配置，而測試詳細規格、測試用例是完成測試任務的具體戰術。所以其中最重要的是測試測試策略和測試方法（最好是能先評審）

24.、怎樣保證你所負責的模塊通過了測試

首先是了解用戶的需求，設計好的測試用例，嚴格的進行用例的評審，認真的執行測試用例，對自己提交的Bug進行詳細的描述。

反復測試,增強測試的準確性，通過冒煙回歸隨機測試挖掘缺陷提高測試工作質量，把各個模塊整體運行發現未曾出現的錯誤，完善測試用例

25.、您認為性能測試工作的目的是什么？做好性能測試工作的關鍵是什么？

性能測試工作的目的是檢查系統是否滿足在需求說明書中規定的性能，性能測試常常需要和強度測試結合起來，并常常要求同時進行軟件和硬件的檢測。性能測試主要的關注對象是響應時間，吞吐量，占用內存大小（輔助存儲區），處理精度等。

26.、怎么編寫案例

案例的編寫與測試階段的定義有很大的關系。系統測試和unit測試的案例可能不同。總體而言測試案例根據系統的需求而定。

27.、怎么才能夠全面的測試到每一個點

測試的全面性主要需要在設計測試計劃的時候考慮，從測試策略，產品需求等等多個角度考慮從而定義全部的測試點。

28.、常用的測試工具及分類

功能測試工具 — QTP；性能測試工具 — LoadRunner；測試管理工具 — TestDirector；

白盒測試工具 — Nunit，Junit，C++Test，JTest，BoundsChecker，Logiscope

29.、軟件測試與調試的關系？

1) 測試條件已知，規程可定義，結果可預知2) 測試可以計劃，過程可控3) 測試是檢驗，調試是推理過程4) 測試表明程序失敗，調試表明正確5) 測試可不了解設計細節6) 測試由非設計人員完成7) 測試有理論依據8) 測試可自動化

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

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

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

3.設計測試用例：

功能性測試：1鏈接測試。鏈接是否正確跳轉，是否存在空頁面和無效頁面，是否有不正確的出錯信息返回等。2提交功能的測試。3多媒體元素是否可以正確加載和顯示。4多語言支持是否能夠正確顯示選擇的語言等。

界面測試：1頁面是否風格統一，美觀2頁面布局是否合理，重點內容和熱點內容是否突出3控件是否正常使用4對于必須但為安裝的空間，是否提供自動下載并安裝的功能5文字檢查

性能測試：壓力測試、負載測試、強度測試

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

安全性測試：1基本的登錄功能的檢查2是否存在溢出錯誤，導致系統崩潰或者權限泄露3相關開發語言的常見安全性問題檢查，例如SQL注入等。4如果需要高級的安全性測試，確定獲得專業安全公司的幫助，外包測試，或者獲取支持

兼容性測試：根據需求說明的內容，確定支持的平臺組合。1瀏覽器的兼容性2操作系統的兼容性3軟件平臺的兼容性4數據庫的兼容性

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

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

 

31.、您在從事性能測試工作時，是否使用過一些測試工具？如果有，請試述該工具的工作原理，并以一個具體的工作中的例子描述該工具是如何在實際工作中應用的。

有使用過LoadRunner,該工具能夠錄制測試人員的操作步驟，然后對這個操作步驟模擬出多個用戶來播放出來。1.Visural User Genertor創建腳本，選擇協議，錄制操作，編輯操作。2.中央控制器（Controller）調度虛擬用戶。創建場景，選擇腳本，建立虛擬用戶，設計shedual，設置ip spoofer。3.運行腳本。分析shedual。4.分析測試結果。

32.、怎樣做好測試計劃

1.理解系統。從整個系統的高度了解被測系統必須滿足的功能和非功能性需求。利用涉及整個系統的文檔，形成對系統的整體了解。

2.及早介入。為了深入了解項目，測試人員應該在系統的開始階段介入，可以增加對客戶需求，客戶問題，潛在風險，以及最重要的功能方面的理解

3.測試期望。程序員的期望是什么？客戶的期望是什么？銷售對測試的期望又是什么？測試目標必須是絕對的，以免說不清楚是否達到目標。

4.吸取教訓。把以前工作中學習到的經驗教訓運用過來，對確定測試策略很有作用。

5.工作量大小。完成測試需要多少工作量？需要多少人員？

6.技術選擇。系統會采取什么技術？系統會采用什么架構？這些信息有助于確定測試策略和測試工具。

7.時間表。系統開發和測試分配的時間有多長？截止日期是什么時候？

33.、您是否了解以往所工作的企業的軟件測試過程？如果了解，請試述在這個過程中都有哪些工作要做？分別由哪些不同的角色來完成這些工作？

軟件測試部門配合系統分析人員軟件需求分析討論，并根據需求說明書制定《項目測試計劃》，編寫測試用例，建立測試環境。軟件測試人員負責軟件開發部門的新產品測試及原有產品的升級測試，負責軟件問題解決過程跟蹤，負責軟件開發文檔開發工作的規范化及管理開發部門的產品文檔，制作用戶手冊及操作手冊，負責產品的上線測試，監督軟件開發過程的執行，提高產品質量。需求人員連同系統分析人員&測試人員開會討論需求。系統分析人員寫出需求分析說明，并連同系統分析人員&測試人員&需求人員開會討論可行性。系統分析人員寫出詳細設計說明書，程式人員編碼，給出系統流程圖。交與測試人員，測試人員給出Bug統計表。

34.、系統測試階段低級缺陷較多怎么辦？

公司有預測試這個流程，會在開展測試活動之前對主要功能點的正常流程做一個測試，以判斷這個版本是不是可測試版本，如果低級缺陷比較多，嚴重阻礙測試執行的話，我們會打回開發部，不執行測試。

35.、缺陷流落到客戶那里怎么辦？

我們公司會盡可能的避免這種情況的出現，讓軟件缺陷在內部得到解決，萬一版本上線了才發現有問題，我們也會及時派技術人員在最短的時間內做出修改，把客戶的損失降到最低。

36.、代碼會審是什么？

對代碼的一個評審的過程，發現一些最基本的錯誤，方式是靜態的代碼走讀方式，在一些大型軟件的設計過程中，還是必不可少的。

37.、請問功能測試和性能測試的區別是什么？(只總結了兩個方面，有其他的自己補充)

①測試目的：

?功能測試：檢查實際軟件的功能是否符合用戶的需求，測功能是不是全部實現，某個實現是不是有BUG。主要為了發現以下幾類錯誤：A、是否有不正確或遺漏的功能？B、功能實現是否滿足用戶需求和系統設計的隱藏需求？ C、能否正確接收輸入？能否正確輸出結果？

?性能測試：驗證軟件質量的三個質量特性，可靠性，正確性和效率。主要是測試產品的健壯性

②測試方式：

   ?功能測試：按照系統需求說明書和測試用例，對產品的功能一步步進行測試。找出產品功能是否全部實現

   ?性能測試：一般都使用性能工具對產品的健壯性進行評估。通過創建場景和虛擬用戶來模擬真是環境，進行壓力測試和負載測試。

38.、狀態為已修改的缺陷 實際沒有修改怎么辦？

加強項目質量管理，提高項目執行能力。如果測試人員發現了這樣的問題，首先要弄清楚是什么原因導致這種情況，最終還是要督促開發人員，修改掉這些問題。如果是不能重現的問題或者是老版本中遺留下來的問題不能修改的 要做好標示。

39.、性能測試什么時候開始最合適

一般在功能測試最后階段執行 因為功能走通了 性能才有意義 總之性能測試要根據用戶實際性能指標來操作 是一個很重要的測試活動 要根據軟件的屬性以及它的實際情況來制定策略

40.、回歸測試中 未解決的缺陷如何處理

實際項目中 也會因為種種原因 出現最后一輪測試結束了 還有一些缺陷沒有解決 那么對于問題的不同 我們有不同的解決方式：嚴重性問題：必須解決，不允許上線；功能性問題：可以考慮在后續版本中解決；一般性問題：可以不解決或者升級的時候解決。

41.、集成測試通常都有那些策略？

1)在把各個模塊連接起來的時候，穿越模塊接口的數據是否會丟失；

2)各個子功能組合起來，能否達到預期要求的父功能；

3)一個模塊的功能是否會對另一個模塊的功能產生不利的影響；

4)全局數據結構是否有問題；

5)單個模塊的誤差積累起來，是否會放大，從而達到不可接受的程度。

42.軟件測試的對象

答：軟件測試并不等于程序測試。軟件測試應貫穿于軟件定義與開發的整個期間。

需求分析、概要設計、詳細設計以及程序編碼等各階段所得到的文檔，包括需求規格說明、概要設計規格說明、詳細設計規格說明以及源程序，都應成為軟件測試的對象。

43.什么是UML？

答：Unified Modeling Language

它是一種用于描述，構造軟件系統以及商業建模的語言。簡單的理解就是它可以以一種直觀的方式表示出一個系統的各項內容。

 

44.、什么是測試策略

  測試策略描述測試工程的總體方法和目標 主要包括以下三個方面：

  1 確定的測試技術和工具

  2 制定測試啟動 停止 完成標準

  3 風險分析和應對方案

其目的 是為我們更好的寫出高質量的用例 提供支撐

45. 軟件測試按過程分為三個步驟

     單元測試：單元測試又稱模塊測試，是針對軟件設計的最小單位 ─ 程序模塊，進行正確性檢驗的測試工作。其目的在于發現各模塊內部可能存在的各種差錯。

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

     集成測試：在運行（可能是不完整）的應用中保證軟件單元被結合后能正常操作的測試執行的階段

     系統測試：當應用作為整體運行時的測試執行階段

46.       軟件測試員和組長的職責分工

普通測試員：

?    創作相關的測試計劃和測試案例

?    識別可自動測試的區域

?    參與組內的測試計劃和測試案例以及測試腳本分析工作

?    手動或自動測試

?    按照需求規格說明查證并驗證各項功能

?    發現并報告bug，跟蹤其狀態

?    初步評估bug對產品其他部分的影響

 

 測試組長：

?    確定測試的策略

?    參與對整個產品的完整測試計劃的制定

?    參與并管理測試

?    評估bug對用戶的影響

?    跟蹤關鍵bug狀態

?    管理測試工作和對象的資源

?    參與面試新人

?    交流狀態和存在問題，并驅動問題的解決

?    促進組內的交流

47.  什么是bug？

   軟件的Bug指的是軟件中（包括程序和文檔）不符合用戶需求的問題。

   常見的軟件Bug分為以下三類：

?    沒有實現的功能

?    完成了用戶需求的功能，但是運行時會出現一些功能或性能上的問題

?    實現了用戶不需要的多余的功能

 

48.什么是CMM？

             CMM：Capability Maturity Model，即“能力成熟度模型”。

   它是一個分 5 級的、可以描述結構完善程度的模型，用它來說明所交付的軟件的效能。 

     49. 您認為在測試人員同開發人員的溝通過程中，如何提高溝通的效率和改善溝通的效果？維持測試人員同開發團隊中其他成員良好的人際關系的關鍵是什么？

         盡量能有面對面的溝通，如果做不到，那么盡量能直接通過電話溝通，如果只能通過Email等非及時溝通工具的話，強調必須對特性的理解深刻以及能表達清楚。

       一是真誠，二是團隊精神，三是在專業上有共同語言，當然也可以通過直接指出一些小問題，而不是進入BUG Tracking System來增加對方的好感。

     50. 你們以前的測試流程是怎樣的？

         明確需求——測試計劃——制定測試策略和測試用例——搭建測試環境、執行測試用例、提交缺陷報告——對測試過程和版本質量評估得出測試總結報告——最后驗收測試

      51. 請試著比較一下黑盒測試、白盒測試、單元測試、集成測試、系統測試、驗收測試的區別與聯系。

黑盒測試：把測試對象當成一個黑盒子，測試人員完全不考慮邏輯結構和內部特性，只依據程式的需求說明書來檢查程式的功能是否滿足它的功能說明。

白盒測試：把測試對象當成一個透明的盒子，允許測試人員利用程序內部邏輯結構及相關信息，設計或選擇測試用例，對程式所有邏輯路徑進行測試。

單元測試：白盒測試的一種，對軟件設計中的單元模塊進行測試。

集成測試：在單元測試的基礎上，對單元模塊之間的連接和組裝進行測試。

系統測試：在所有都考慮的情況下，對系統進行測試。

驗收測試：第三方進行的確認軟件滿足需求的測試。

52. 您以往的工作中是否曾開展過測試用例的評審工作？如果有，請描述測試用例評審的過程和評審的內容。

 

53. 軟件本地化測試和功能測試都有那些方面要注意？

     本地化就是將軟件版本語言進行更改，比如將英文的windows改成中文的windows就是本地化。

     本地化測試過程中的測試工作集中在：

?    受本地化影響的方面，如 UI 和內容

?    區域性或區域設置特定的、語言特定的和地區特定的方面

?    基本功能測試

?    在本地化環境中運行的安裝和升級測試

?    根據產品的目標地區計劃應用程序和硬件兼容性測試。

   54. 什么是軟件質量？

    高質量的軟件是適當的、無錯誤的，能在預算內按時交貨，滿足需求/或期望，并且是可維護的。所以，質量是一個主觀的術語。它取決于誰是客戶以及客戶對項目計劃的影響。對一個軟件開發項目來說，“客戶”的范圍很廣，包括最終用戶、客戶所接受的測試者、與客戶合同有關的官員、客戶管理、開發機構的管理者/會計/測試人員/銷售人員、未來的軟件維護工程師、股票持有者、雜志專欄記者，等等。每一類客戶對“質量”都有自己的傾向性 – 會計部門判斷質量會從其收益來考慮，而最終用戶則重視友好的用戶界面和沒有錯誤。

 

 55． 為什么軟件會有毛病？

     1.交流錯誤或者沒有進行交流，需求不明確

     2. 軟件的復雜性  編程錯誤 

    3. 需求變更   客戶恐怕不明白改變需求的影響，也許是知道但依然需要變更 ── 會導致重新設計、重訂工程進度表、對其他項目的影響、已完成的工作需要重做或者放棄、對硬件需求的影響等等。如果在項目中出現許多小的改變或一個大的改變，在項目各部分中出現已知或未知的相關的問題，可能會相互影響并導致出現問題。而且，不斷地變更也會增加軟件的復雜性，可能會導致錯誤的出現。這樣就會影響技術人員的積極性。在一些快速變化的商業環境里，持續變更需求的影響是致命的。在這種情況下，管理者必須知道它的危險性。質量保障和測試工程師必須與此相適應，并安排持續的廣泛的測試，以克服不可避免產生的問題。

  4. 時間壓力

     因為有許多猜測成分，軟件開發項目的進度很難安排得理想。當最后期限快到的時候，壓力逐漸增大，錯誤隨之產生

 5. 自負心理、 代碼文檔質量差、 軟件開發工具

 56.  什么是驗證、評價、預排 、檢查？

ü  驗證 (verification) 涉及了回顧和會議，以評估文檔、計劃、代碼、需求和說明書。可以通過檢查表、調查表、排練、和檢查會來進行。

ü  評價 (validation) 則指在檢察完成之后的實際測試。術語“IV”和“V”分別代表驗證和評價。

ü  “預排”是一個非正式的會議，用來進行評估和信息交流。通常不需要或者只需很少一點準備。

ü  檢查比預排更正式一點，通常有 3-8 個人參加會議，包括一個仲裁者 (moderator)、讀者 (可以是作者或者任何評論者)、一個記錄員作記錄。典型的檢查對象是一個文件，例如需求說明或者測試計劃，目的在于發現問題和查找遺漏，而不是去對任何東西進行實際的修改。會議的參加者應當有準備，應當通讀文件，大多數的問題會在準備的過程中被發現。檢查會的結果應寫成書面報告。對檢查會進行全面準備是困難而艱苦的工作，但它是保證質量最有用的方法。在檢查過程中，最有經驗的雇員的作用就向‘大哥哥’一樣，他們的技能也許不大顯眼，但對任何軟件開發機構是最重要的，這是因為預防錯誤要比發現錯誤在費用方面更加有效。

 

 

57.  介紹一下整體項目流程。

  我們公司的測試流程是圍繞著測試的五個階段展開的，測試計劃、設計測試、執行測試、評估測試、驗收測試。只是在不同的階段有自己的一套做法。在接到項目單后，我們會召開一個項目開工會，要求各部門的相關人員都參與，會議我們主要是了解一下項目的背景、目的和資料。確定開始時間和結束時間和項目參與人員，測試部和開發商量好開發轉系統測試時間，然后就進入計劃階段，開發和測試都有自己的計劃，我們測試計劃由測試經理編寫，測試計劃中主要是制定可采用的測試策略和范圍，評估項目風險和規避措施，制定時間進度表，合理的分配人力、物力資源。之后進入設計階段，設計階段我們會參考開發的需求說明書、詳細設計、概要設計去設計測試用例。接到開發的新版本就進入了測試執行階段，首先是搭建測試環境，對軟件實施預測試主要是驗證系統的正常功能是否可用，然后就是系統測試，執行用例并提交缺陷報告，至于系統測試的輪次則要根據項目的復雜度和版本質量決定的。后期我們進入測試評估階段對軟件測試的過程和版本質量進行評估得出測試總結報告，最后我們進入測試驗收階段，我們會出用戶手冊、操作指引等文檔，我們公司在每個階段的輸出都有一個評審階段，保證輸出有效，從而使測試順利進行。

 

58.       在實際項目中你是如何做測試計劃的

做測試計劃前必須先了解項目的背景、目的等資料，然后合理劃分測試范圍，制定可采用的測試策略，評估項目中可能存在的風險和規避措施，制定好時間進度表，合理分配項目的人力、物力資源。

59.        你是如何制定時間進度表的

  首先確定三個大的時間段 項目開始時間 項目結束時間 開發轉系統測試時間，在根據測試各個階段的工作量和項目資源制定計劃、設計、執行、評估、驗收階段的時間。設計和執行的時間一般較多。

60.        測試計劃都包括那些項

項目基本信息 、總體測試策略、項目風險分析和規避措施、項目資源分配 （人力、物力、軟硬件環境）、項目時間進度表、 系統優先級

61.        測試用例如何設計

     根據開發的需求說明書 、詳細設計說明、和概要設計說明書設計測試用例遇見那里不明確的可以直接和開發人員溝通討論。

    設計的時候我們會綜合運用黑盒測試法，如運用等價類劃分、邊界值分析、錯誤推測法等。

62.        如何保證用例覆蓋到罕見缺陷

1.預留足夠的時間理解需求說明在設計用例

2.采用評審和更新機制，保證每一步的輸出都是有效的，從而保證測試順利進行。

3.對覆蓋不全面的或是沒有覆蓋到的，在版本間歇期追加測試用例

63.  缺陷處理流程！

1.      測試員提交新的缺陷入庫設置狀態為 New

2.      由高級測試人員驗證缺陷，如果是缺陷則提交給項目經理設置為（Open）分配給開發部修改，并將修改后的缺陷設置為（Fixed）,如果不是缺陷則直接拒絕（Decline）

3.      對于不能夠立即解決的缺陷一般要開會議討論則設置狀態為“延期“（Derlend）

4.      最后由測試員從新檢查修改后的缺陷。不是則直接關閉（Closed）

63.        測試用例包括那些項

     基本信息、用例編號、嚴重級別、缺陷描述、操作步驟

64.        開發人員修復缺陷后，如何保證不影響其他功能

重新執行用例、看是否出現錯誤結果。并對周圍的一些相關功能點追加新的測試用例。

65          測試總結報告包括那些項

   主要有對測試過程和版本質量的評估，并有一些質量建議。還有一些數據，如用例總數，執行數量等。

65.        針對邏輯性較強的功能點你該如何設計測試用例？？？

66.        測試工作進行到一半是，發現時間不夠，你如何處理

1.可以加班加點，加派測試人員并征用有經驗的技術員

2.可以挑選優先級別高的用例先執行。

67. 怎樣保證你所負責的模塊通過了測試

1.        設計好的用例、詳細劃分用例嚴重級別，先執行優先級別高的用例，保證規定的功能都正常工作。

2.      保證用例的覆蓋率和用例的質量，最后能夠符合用戶需求說明書。并通過了內部評審。

67.        開發與測試的關系？

   測試是依托于開發的  測試同時也可以指導開發。

   開發和測試密切聯系、相互依賴，開發為測試提供產品，測試負責檢查開發的產品，測試和開發有共同的目的就是提高和改善軟件質量

 

68.        如果你是測試組長你如何對項目及組員進行管理

1.強調合作和討論，一切以圓滿完成項目為出發點

2.合理分配項目資源和技術人員，明確職責合理分工。

3.表揚和懲罰制度

4.保護測試員

 

                                    

             

網站測試總結

1.功能測試
    對于網站的測試而言，每一個獨立的功能模塊需要單獨的測試用例的設計導出，主要依據為《需求規格說明書》及《詳細設計說明書》，對于應用程序模塊需要設計者提供基本路徑測試法的測試用例。
鏈接測試
    鏈接是Web應用系統的一個主要特征，它是在頁面之間切換和指導用戶去一些不知道地址的頁面的主要手段。鏈接測試可分為三個方面：
1）測試所有鏈接是否按指示的那樣確實鏈接到了該鏈接的頁面；
2）測試所鏈接的頁面是否存在；
3）保證Web應用系統上沒有孤立的頁面，所謂孤立頁面是指沒有鏈接指向該頁面，只有知道正確的URL地址才能訪問。
    鏈接測試可以自動進行，現在已經有許多工具可以采用。鏈接測試必須在集成測試階段完成，也就是說，在整個Web應用系統的所有頁面開發完成之后進行鏈接測試。
Xenu------主要測試鏈接的正確性的工具
可惜的是對于動態生成的頁面的測試會出現一些錯誤。
表單測試
    當用戶給Web應用系統管理員提交信息時，就需要使用表單操作，例如用戶注冊、登陸、信息提交等。在這種情況下，我們必須測試提交操作的完整性，以校驗提交給服務器的信息的正確性。例如：用戶填寫的出生日期與職業是否恰當，填寫的所屬省份與所在城市是否匹配等。如果使用了默認值，還要檢驗默認值的正確性。如果表單只能接受指定的某些值，則也要進行測試。例如：只能接受某些字符，測試時可以跳過這些字符，看系統是否會報錯。
    要測試這些程序，需要驗證服務器能正確保存這些數據，而且后臺運行的程序能正確解釋和使用這些信息。
    B/S結構實現的功能可能主要的就在這里，提交數據，處理數據等如果有固定的操作流程可以考慮自動化測試工具的錄制功能，編寫可重復使用的腳本代碼，可以在測試、回歸測試時運行以便減輕測試人員工作量。
    我們對UM子系統中各個功能模塊中的各項功能進行逐一的測試，主要測試方法為：邊界值測試、等價類測試，以及異常類測試。測試中要保證每種類型都有2個以上的典型數值的輸入，以確保測試輸入的全面性。
Cookies測試
    Cookies通常用來存儲用戶信息和用戶在某應用系統的操作，當一個用戶使用Cookies訪問了某一個應用系統時，Web服務器將發送關于用戶的信息，把該信息以Cookies的形式存儲在客戶端計算機上，這可用來創建動態和自定義頁面或者存儲登陸等信息。
    如果Web應用系統使用了Cookies，就必須檢查Cookies是否能正常工作而且對這些信息已經加密。測試的內容可包括Cookies是否起作用，是否按預定的時間進行保存，刷新對Cookies有什么影響等。
設計語言測試
    Web設計語言版本的差異可以引起客戶端或服務器端嚴重的問題，例如使用哪種版本的HTML等。當在分布式環境中開發時，開發人員都不在一起，這個問題就顯得尤為重要。除了HTML的版本問題外，不同的腳本語言，例如Java、JavaScript、 ActiveX、VBScript或Perl等也要進行驗證。
數據庫測試
    在Web應用技術中，數據庫起著重要的作用，數據庫為Web應用系統的管理、運行、查詢和實現用戶對數據存儲的請求等提供空間。在Web應用中，最常用的數據庫類型是關系型數據庫，可以使用SQL對信息進行處理。
    在使用了數據庫的Web應用系統中，一般情況下，可能發生兩種錯誤，分別是數據一致性錯誤和輸出錯誤。數據一致性錯誤主要是由于用戶提交的表單信息不正確而造成的，而輸出錯誤主要是由于網絡速度或程序設計問題等引起的，針對這兩種情況，可分別進行測試。
    功能測試用到的測試工具有：黑盒自動化測試工具AutoRunner；測試管理工具TestCenter。
2 性能測試
    網站的性能測試對于網站的運行而言異常重要，但是目前對于網站的性能測試做的不夠，我們在進行系統設計時也沒有一個很好的基準可以參考，因而建立網站的性能測試的一整套的測試方案將是至關重要的。
    網站的性能測試主要從三個方面進行：連接速度測試、負荷測試（Load）和壓力測試（Stress）.連接速度測試指的是打開網頁的響應速度測試。負荷測試指的是進行一些邊界數據的測試，壓力測試更像是惡意測試，壓力測試傾向應該是致使整個系統崩潰。壓力測試的區域包括表單、登陸和其他信息傳輸頁面等。

  3. 可用性測試（導航、界面、內容、圖形、）

  4.  兼容性測試（平臺測試和瀏覽器的測試）

5. 安全性測試（有無安全漏洞、socket的信息完整性、用戶名密碼是否有效等）

實際測試題參考

1、測試項目：杯子
需求測試: 查看杯子使用說明書
界面測試: 查看杯子外觀
功能度：用水杯裝水看漏不漏；水能不能被喝到
安全性：杯子有沒有毒或細菌
可靠性：杯子從不同高度落下的損壞程度
可移植性：杯子再不同的地方、溫度等環境下是否都可以正常使用
兼容性：杯子是否能夠容納果汁、白水、酒精、汽油等
易用性：杯子是否燙手、是否有防滑措施、是否方便飲用
用戶文檔：使用手冊是否對杯子的用法、限制、使用條件等有詳細描述
疲勞測試：將杯子盛上水（案例一）放24 小時檢查泄漏時間和情況；盛上汽油（案例二）放24 小時檢查泄漏時間和情況等
壓力測試：用根針并在針上面不斷加重量，看壓強多大時會穿透
跌落測試:    杯子加包裝( 有填充物), 在多高的情況摔下不破損
震動測試: 杯子加包裝( 有填充物), 六面震動, 檢查產品是否能應對惡劣的鐵路\ 公路\ 航空運輸
測試數據：測試數據具體編寫此處略（最討厭寫測試數據了）。其中應用到：場景法、等價類劃分法、因果圖法、錯誤推測法、邊界值法等方法
期望輸出：
該期望輸出需查閱國標、行標以及使用用戶的需求

2、測試項目：電梯
需求測試:查看電梯使用說明書、安全說明書等
界面測試:查看電梯外觀
功能測試：測試電梯能否實現正常的上升和下降功能．電梯的按鈕是否都可以用；
         電梯門的打開，關閉是否正常；報警裝置是否可用，報警電話是否可用；
         通風狀況如何.突然停電時的情況；是否有手機信號；
比如說上升途中的響應。電梯本來在1樓，如果有人按18樓，那么電梯在上升到5樓的時候，有人按了10樓，這時候是否會在10樓先停下來；
電梯下降到10層時顯示滿員，此時若8層有人等待電梯，是否在8層停；
可靠性：門關上的一剎那出現障礙物，同時按關門和開門按鈕，點擊當前樓層號碼，多 次點擊同一樓層的號碼等等；同時按上鍵和下鍵會怎樣；
易用性：電梯的按鈕的設計符合一般人使用的習慣嗎．
用戶文檔：使用手冊是否對電梯的用法、限制、使用條件等有詳細描述
壓力測試：看電梯的最大限度的承受重量．在負載過重時報警裝置是否有提醒．是否有超時的反應；在一定時間內不斷的讓電梯上升，下降．最大負載下平穩運行的最長時間。

3測試題目：桌子

需求測試:查看國家相關標準。

功能:桌子是辦公,或者放置用的,首先考慮桌子的面積大小是否適度.
界面:桌子的版面是否平滑,桌子有沒有凹凸不平的地方
安全:桌子肯定有它的支撐點,若支撐點不穩,容易摔壞物品,使用起來也不方便.
易用:桌子的移動性好不.它的重量是否合適
可靠性:將桌子推倒后,再檢查桌子是否很容易被損壞.
性能:將很重的物品放在桌子上,看它最大承受的重量是多少......