軟體測試工程師面試題合集，建議收藏一波！

看過的可以在看一下，加深記憶，面試前，看面試題，事半功倍，一般人我不告訴他的。來看看面試題吧。

Q:

1、你的測試職業發展是什麼？

A:

測試經驗越多，測試能力越高。所以我的職業發展是需要時間積累的，一步步向著高階測試工程師奔去。而且我也有初步的職業規劃，前3年積累測試經驗，按如何做好測試工程師的要點去要求自己，不斷更新自己改正自己，做好測試任務。

Q:

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

A:

做測試應該要有一定的協調能力，因為測試人員經常要與開發接觸處理一些問題，如果處理不好的話會引起一些衝突，這樣的話工作上就會不好做。還有測試人員要有一定的耐心，有的時候做測試很枯燥乏味。除了耐心，測試人員不能放過每一個可能的錯誤。

Q:

3、你為什麼能夠做測試這一行？

A:

雖然我的測試技術還不是很成熟，但是我覺得我還是可以勝任軟體測試這個工作的，因為做軟體測試不僅是要求技術好，還有有一定的溝通能力，耐心、細心等外在因素。綜合起來看我認為我是勝任這個工作的。

Q:

4、測試的目的是什麼？

A:

測試的目的是找出軟體產品中的錯誤，使軟體儘可能的符合使用者的要求。當然軟體測試是不可能找出全部錯誤的。

Q:

5、測試分為哪幾個階段？

A:

一般來說分為5個階段：單元測試、整合測試、確認測試、系統測試、驗收測試

Q:

6、單元測試的測試物件、目的、測試依據、測試方法？

A:

測試物件是模組內部的程式錯誤，目的是消除區域性模組邏輯和功能上的錯誤和缺陷。測試依據是模組的詳細設計，測試方法是採用白盒測試。

Q:

7、怎樣看待加班問題？

A:

加班的話我沒有太多意見，但是我還是覺得如果能夠合理安排時間的話，不會有太多時候加班的。

Q:

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

A:

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

Q:

9、你為什麼選擇軟體測試行業？

A:

因為之前瞭解軟體測試這個行業，覺得他的發展前景很好。

Q:

10、根據你以前的工作或學習經驗描述一下軟體開發、測試過程，由哪些角色負責，你做什麼？

A:

要有架構師、開發經理、測試經理、程式設計師、測試員。我在裡面主要是負責所分到的模組執行測試用例。

Q:

11、根據你的經驗說說你對軟體測試/質量保證的理解

A:

軟體質量保證與測試是根據軟體開發階段的規格說明和程式的內部結構而精心設計的一批測試用例(即輸入資料和預期的輸出結果)，並根據這些測試用例去執行程式，以發現錯誤的過程。它是對應用程式的各個方面進行測試以檢查其功能、語言有效性及其外觀排布。

Q:

12、軟體測試的流程是什麼？

A:

需求調查：全面瞭解系統概況、應用領域、軟體開發週期、軟體開發環境、開發組織、時間安排、功能需求、效能需求、質量需求及測試要求等。根據系統概況進行專案所需的人員、時間和工作量估計以及專案報價，制定初步的專案計劃。

測試準備：組織測試團隊、培訓、建立測試和管理環境等。

測試設計：按照測試要求進行每個測試項的測試設計，包括測試用例的設計和測試指令碼的開發等。

測試實施：按照測試計劃實施測試。

測試評估：根據測試的結果，出具測試評估報告。

Q:

13、你對SQA的職責和工作活動(如軟體度量)的理解?

A:

SQA就是獨立於軟體開發的專案組，透過對軟體開發過程的監控，來保證軟體的開發流程按照指定的CMM規程(如果有相應的CMM規程),對於不符合項及時提出建議和改進方案，必要時可以向高層經理彙報以求問題的解決。透過這樣的途徑來預防缺陷的引入，從而減少後期軟體的維護成本。SQA主要的工作活動包括制定SQA工作計劃，參與階段產物的評審，進行過程質量、功能配置及物理配置的審計等；對專案開發過程中產生的資料進行度量等等。

Q:

14、說說你對軟體配置管理的理解

A:

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

Q:

15、怎樣寫測試計劃和測試用例？

A:

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

Q:

16、說說主流的軟體工程思想(如CMM、CMMI、RUP,XP,PSP,TSP等)的大致情況及對他們的理解

A:

CMM:SW Capability Maturity Model軟體能力成熟度模型，其作用是軟體過程的改進、評估及軟體能力的評鑑。

CMMI:Capability Maturity Model Integration能力成熟度模型整合 CMMI融入了大部分最新的軟體管理實踐，同時彌補了SW-CMM模型中的缺陷。

RUP:rational unified process是軟體工程話過程。

XP:extreme program，即極限程式設計的意思，適用於小型團隊的軟體開發，像上面第三個問題就可以結合原型法採用這樣的開發流程。要明白測試對於xp開發的重要性，強調測試(重點是單元測試)先行的理念。程式設計可以明顯提高程式碼的質量，持續整合對於快速定位問題有好處。

PSP，TSP分別是個體軟體過程和群體軟體過程。大家都知道，CMM只是告訴你做什麼但並沒有告訴你如何做，所以PSP/TSP就是告訴你企業在實施CMM的過程中如何做，PSP強調建立個人技能(如何制定計劃、控制質量及如何與其他人相互協作等等)。而TSP著重於生產並交付高質量的軟體產品(如何有效的規劃和管理所面臨的專案開發任務等等)。總之，實施CMM，永遠不能真正做到能力成熟度的提升，只有將實施CMM與實施PSP和TSP有機結合起來，才能發揮最大的效力。因此，軟體過程框架應該是CMM/PSP/TSP的有機整合。

Q:

17、你是怎樣保證軟體質量的，也就是說你覺得怎樣才能最大限度的保證軟體的質量？

A:

測試並不能夠最大限度的保證軟體的質量，軟體的高質量是開發和設計出來的，而不是測試出來的，它不僅要透過對軟體開發流程的監控，使得軟體開發的各個階段都要按照指定的規程進行，透過對各個階段產物的評審，QA對流程的監控，對功能及配置的審計來達到開發的最最佳化。當然測試也是保證軟體質量的一個重要方式，是軟體質量保證工程的一個重要組成部分。

Q:

18、基於目前中國的國情，大多數公司的專案進度緊張、人員較少、需求文件根本沒有或者很不規範，你認為在這種情況下怎樣保證軟體的質量？(大多數公司最想知道的就是在這種困難面前你該怎麼保證軟體的質量，因為這些公司一般就是這種情況--既不想投入過多又想保證質量)

A:

出現以上的情況，如果僅僅想透過測試來提高軟體質量，那幾乎是不可能的，原因是沒有足夠的時間讓你去測試，少而不規範的文件導致測試需求無法細化到足夠且有針對行的測試。所以，作為公司質量保證的因該和專案經理確定符合專案本身是和的軟體生命週期模型(比如RUP的建材，原型法)，明確專案的開發流程並督促專案組按照此流程開展工作，所有專案組成員(專案經理更加重要)都要制定出合理的工作計劃，加強程式碼的單元測試，在客戶既定的產品交付日期範圍內，進行產品的持續整合等等，如果時間允許可以再配合客戶進行必要的系統功能測試。

Q:

19、一個測試工程師應該具備哪些素質和技能？

A:

• 掌握基本的測試基礎理論
• 本著找出軟體存在的問題的態度進行測試，不要以挑刺的形象出現
• 可熟練閱讀需求規格說明書等文件
• 以使用者的觀點看問題
• 有強烈的質量意識
• 細心和責任心
• 良好的有效的溝通方式(與開發人員及客戶)
• 具有以往的測試經驗能夠及時準確的判斷出高危險區在何處

Q:

20、做好軟體測試的一些關鍵點

A:

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

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

測試要有計劃，而且測試方案要和整個專案計劃協調好

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

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

對於複雜的流程一定要進行流程分支，組合條件分析，再進行等價類劃分準備相關測試資料

測試設計的一個重要內容是要準備好具體的測試資料，清楚這個測試資料是測試那個場景或分支的。

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

除了每天構建的重複測試可以考慮測試自動化外，其他暫時都不要考慮去自動話

Q:

21、軟體測試員自身素質培養

A:

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

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

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

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

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

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

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

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

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

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

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

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

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

Q:

22、為什要在一個團隊中開展測試工作？

A:

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

Q:

23、你所熟悉的軟體測試型別有哪些?

A:

測試型別有：功能測試、效能測試、介面測試

功能測試在測試工作中佔有比例最大，功能測試也叫黑盒測試

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

介面測試，介面是軟體與使用者互動的最直接的層，介面的好壞決定使用者對軟體的第一印象

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

Q:

24、你認為做好測試用例設計工作的關鍵是什麼?

A:

白盒測試用例設計的關鍵是以較少的用例覆蓋儘可能多的內部程式邏輯結構。黑盒測試用例設計的關鍵同樣也是以較少的用例覆蓋模組輸出和輸入介面。不可能做到完全測試，以最少的用例在合理的時間內發現最多的問題。軟體的黑盒測試意味著測試要在軟體的介面處進行，這種方法是把測試物件看作是一個黑盒子，測試人員完全不考慮程式內部的邏輯結構和內部特性，只依據程式的需求規格說明書，檢查程式的功能是否符合它的功能說明。因此黑盒測試又叫功能測試或者資料驅動測試。 黑盒測試主要是為了發現以下幾類錯誤：

是否有不正確或遺漏的功能

在介面上，輸入是否能正確的接受？能否輸出正確的結果

是否有資料結構錯誤或外部資訊(例如資料檔案)訪問錯誤

效能上是否能夠滿足要求

是否有初始化或終止性錯誤

軟體的白盒測試是對軟體的過程性細節做細緻的檢查。這種方法是把測試物件看作一個開啟的盒子，它允許測試人員利用程式內部的邏輯結構和有關資訊，設計或者選擇測試用例，對程式所有邏輯路徑進行測試。透過在不同點檢查程式狀態，確定實際狀態是否與預期的狀態一直。因此白盒測試又稱為結合測試或邏輯驅動測試。 白盒測試主要是想對程式模組進行如下檢查：

對程式模組的所有獨立的執行路徑至少測試一遍

對所有的邏輯判定，取“真”與取“假”的兩種情況都能至少測一遍

在迴圈的邊界和執行的界限內執行迴圈體

測試內部資料結構的有效性等等

Q:

25、請詳細介紹一下各種測試型別的含義

A:

單元測試(模組測試)是開發者編寫的一小段程式碼，用於檢驗被測試程式碼的一個很小的、很明確的功能是否正確。通常而言，一個單元測試是用於判斷某個特定條件(或者場景)下某個特定函式的行為。單元測試是由程式設計師自己來完成，最終受益的也是程式設計師自己。可以這麼說，程式設計師有責任編寫功能程式碼，同時也就有責任為自己的程式碼編寫單元測試。執行單元測試，就是為了證明這段程式碼的行為和我們期望的一致

整合測試(也叫組裝測試、聯合測試)是單元測試的邏輯擴充套件。它最簡單的形式是：兩個已經經過測試的單元組合成一個元件，並且測試它們之間的介面。從這一層上講，元件是指多個單元的整合聚合。在現實方案中，許多單元組合成元件，而這些元件又聚合成程式的更大部分。方法是測試片段的組合，並最終擴充套件程式，將您的模組與其他組的模組一起測試。最後，將構成程式的所有模組一起測試

系統測試是將經過測試的子系統裝配成一個完整系統來測試。它是檢驗系統是否確實能提供系統方案說明書中制定功能的有效方法。(常見的聯調測試)。系統測試的目的是對最終軟體系統進行全面的測試，確保最終軟體系統滿足產品需求而遵循系統設計

驗收測試是部署軟體之前的最後一個測試操作。驗收測試的目的是確保軟體準備就緒，並且可以讓使用者將其執行軟體的既定功能和任務。驗收測試是向未來的使用者表明系統能夠像預訂要求那樣工作。經整合測試後，已經按照設計把所有的模組組裝成一個完整的軟體系統，介面錯誤也已經基本排除了，接著就應該進一步驗證軟體的有效性，這就是驗收測試的任務，即軟體的功能和效能如同使用者所合理期待的那樣

Q:

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

A:

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

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

Q:

27、您認為做好測試計劃工作的關鍵是什麼？

A:

明確測試的目標，增強測試計劃的實用性

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

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

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

採用評審和更新機制，保證測試計劃滿足實際需求

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

分別建立測試計劃與測試詳細規格、測試用例

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

Q:

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

A:

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

Q:

29、你自認為測試的優勢在哪裡？

A:

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

Q:

30、什麼是系統瓶頸？

A:

瓶頸主要是指整個軟硬體構成的軟體系統某一方面或者幾個方面能力不能滿足使用者的特定業務要求，“特定”是指瓶頸會在某些條件下會出現，因為畢竟大多數系統在投入前。

嚴格的從技術角度講，所有的系統都會有瓶頸，因為大多數系統的資源配置不是協調的，例如CPU使用率剛好達到100％時，記憶體也正好耗盡的系統不是很多見。因此我們討論系統瓶頸要從應用的角度討論：關鍵是看系統能否滿足使用者需求。在使用者極限使用系統的情況下，系統的響應仍然正常，我們可以認為改系統沒有瓶頸或者瓶頸不會影響使用者工作。

因此我們測試系統瓶頸主要是實現下面兩個目的：

發現“表面”的瓶頸。主要是模擬使用者的操作，找出使用者極限使用系統時的瓶頸，然後解決瓶頸，這是效能測試的基本目標

發現潛在的瓶頸並解決，保證系統的長期穩定性。主要是考慮使用者在將來擴充套件系統或者業務發生變化時，系統能夠適應變化。滿足使用者目前需求的系統不是最好的，我們設計系統的目標是在保證系統整個軟體生命週期能夠不斷適應使用者的變化，或者透過簡單擴充套件系統就可以適應新的變化

Q:

31、文件測試主要包含什麼內容？

A:

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

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

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

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

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

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

Q:

32、功能測試用例需要詳細到什麼程度才是合格的？

A:

這個問題也是測試工程師經常問的問題。有人主張測試用例詳細到每個步驟執行什麼都要寫出來，目的是即使一個不瞭解系統的新手都可以按照測試用例來執行工作。主張這類寫法的人還可以舉出例子：歐美、日本等軟體外包文件都是這樣做的。

另外一種觀點就是主張寫的粗些，類似於編寫測試大綱。主張這種觀點的人是因為軟體開發需求管理不規範，變動十分頻繁，因而不能按照歐美的高標準來編寫測試用例。這樣的測試用例容易維護，可以讓測試執行人員有更大的發揮空間。

實際上，軟體測試用例的詳細程度首先要以覆蓋到測試點為基本要求。舉個例子：“使用者登陸系統”的測試用例可以不寫出具體的執行資料，但是至少要寫出五種以上情況（），如果只用一句話覆蓋了這個功能是不合格的測試用例。覆蓋功能點不是指列出功能點，而是要寫出功能點的各個方面（如果組合情況較多時可以採用等價劃分）。

另一個影響測試用例的就是組織的開發能力和測試物件特點。如果開發力量比較落後，編寫較詳細的測試用例是不現實的，因為根本沒有那麼大的資源投入，當然這種情況很隨著團隊的發展而逐漸有所改善。測試物件特點重點是指測試物件在進度、成本等方面的要求，如果進度較緊張的情況下，是根本沒有時間寫出高質量的測試用例的，甚至有些時候測試工作只是一種輔助工作，因而不編寫測試用例。

因此，測試用例的編寫要根據測試物件特點、團隊的執行能力等各個方面綜合起來決定編寫策略。最後要注意的是測試人員一定不能抱怨，力爭在不斷提高測試用例編寫水平的同時，不斷地提高自身能力。

Q:

33、配置和相容性測試的區別是什麼？

A:

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

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

軟體在不同的硬體上的執行情況

軟體在不同的元件上的執行情況，例如開發的app要測試在不同廠商手機上的安裝執行情況

不同的外設

不同的介面

不同的可選項，例如不同的記憶體大小

相容性測試的核心內容：

測試軟體是否能在不同的作業系統平臺上相容

測試軟體是否能在同一作業系統平臺的不同版本上相容

軟體本身能否向前或者向後相容

測試軟體能否與其它相關的軟體相容

資料相容性測試，主要是指資料能否共享

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

Q:

34、軟體文件測試主要包含什麼？

A:

隨著軟體文件系統日益龐大，文件測試已經成為軟體測試的重要內容。 文件測試物件主要如下：

• 包裝文字和圖形
• 市場宣傳材料、廣告以及其它插頁
• 授權、註冊登記表
• 終端使用者許可協議
• 安裝和設定嚮導
• 使用者手冊
• 聯機幫助
• 樣例、示範例子和模板

文件測試的目的是提高易用性和可靠性，降低支援費用，因為使用者透過文件就可以自己解決問題。 因文件測試的檢查內容主要如下：

讀者物件——主要是文件的內容是否能讓該級別的讀者理解

術語——主要是檢查術語是否適合讀者

內容和主題——檢查主題是否合適、是否丟失、格式是否規範等

圖示和螢幕抓圖——檢查圖表的準確度和精確度

樣例和示例——是否與軟體功能一致

拼寫和語法

文件的關聯性——是否與其它相關文件的內容一致，例如與廣告資訊是否一致

文件測試是相當重要的一項測試工作，不但要給予充分的重視，更要要認真的完成，象做功能測試一樣來對待文件測試。

Q:

35、沒有產品說明書和需求文件地情況下能夠進行黑盒測試嗎？

A:

這個問題是國內測試工程師經常遇到的問題，根源就是國內軟體開發文件管理不規範，對變更的管理方法就更不合理了。實際上沒有任何文件的時候，測試人員是能夠進行黑盒測試的，這種測試方式我們可以稱之為探索測試，具體做法就是測試工程師根據自己的專業技能、領域知識等不斷的深入瞭解測試物件、理解軟體功能，進而發現缺陷。

在這種做法基本上把軟體當成了產品說明書，測試過程中要和開發人員不斷的進行交流。尤其在作專案的時候，進度壓力比較大，可以作為加急測試方案。最大的風險是不知道有些特性是否被遺漏。