[面試]中高級測試工程師必備，月薪15K+

時間 2019-11-16

標籤面試中高級測試工程師必備月薪 15k 欄目快樂工作简体版

原文原文鏈接

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

測試經驗越多，測試能力越高。因此個人職業發展是須要時間積累的，一步步向着高級測試工程師奔去。並且我也有初步的職業規劃，前3年積累測試經驗，按如何作好測試工程師的要點去要求本身，不斷更新本身改正本身，作好測試任務。程序員

二、你認爲測試人員須要具有哪些素質面試

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

三、你爲何可以作測試這一行數據庫

雖然個人測試技術還不是很成熟，可是我以爲我仍是能夠勝任軟件測試這個工做的，由於作軟件測試不只是要求技術好，還有有必定的溝通能力，耐心、細心等外在因素。綜合起來看我認爲我是勝任這個工做的。編程

四、測試的目的是什麼？數據結構

測試的目的是找出軟件產品中的錯誤，是軟件儘量的符合用戶的要求。固然軟件測試是不可能找出所有錯誤的。架構

五、測試分爲哪幾個階段？併發

通常來講分爲5個階段：單元測試、集成測試、確認測試、系統測試、驗收測試app

六、單元測試的測試對象、目的、測試依據、測試方法？

測試對象是模塊內部的程序錯誤，目的是消除局部模塊邏輯和功能上的錯誤和缺陷。測試依據是模塊的詳細設計，測試方法是採用白盒測試。

七、怎樣看待加班問題

加班的話我沒有太多意見，可是我仍是以爲若是可以合理安排時間的話，不會有太多時候加班的。

八、結合你之前的學習和工做經驗，你認爲如何作好測試。

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

九、你爲何選擇軟件測試行業

由於以前瞭解軟件測試這個行業，以爲他的發展前景很好。

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

要有架構師、開發經理、測試經理、程序員、測試員。我在裏面主要是負責所分到的模塊執行測試用例。

十一、根據你的經驗說說你對軟件測試/質量保證的理解

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

十二、軟件測試的流程是什麼？

需求調查：全面瞭解系統概況、應用領域、軟件開發週期、軟件開發環境、開發組織、時間安排、功能需求、性能需求、質量需求及測試要求等。根據系統概況進行項目所需的人員、時間和工做量估計以及項目報價。

制定初步的項目計劃。

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

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

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

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

1三、你對SQA的職責和工做活動(如軟件度量)的理解?

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

1四、說說你對軟件配置管理的理解

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

1五、怎樣寫測試計劃和測試用例

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

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

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的有機集成。

1七、你是怎樣保證軟件質量的，也就是說你以爲怎樣才能最大限度的保證軟件的質量？

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

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

出現以上的狀況，若是僅僅想經過測試來提升軟件質量，那幾乎是不可能的，緣由是沒有足夠的時間讓你去測試，少而不規範的文檔致使測試需求沒法細化到足夠且有針對行的測試。因此，做爲公司質量保證的因該和項目經理肯定符合項目自己是和的軟件生命週期模型(好比RUP的建材，原型法)，明確項目的開發流程並督促項目組按照此流程開展工做，全部項目組成員(項目經理更加劇要)都要制定出合理的工做計劃，增強代碼的單元測試，在客戶既定的產品交付日期範圍內，進行產品的持續集成等等，若是時間容許能夠再配合客戶進行必要的系統功能測試。

1九、一個測試工程師應該具有哪些素質和技能？

1-掌握基本的測試基礎理論

2-本着找出軟件存在的問題的態度進行測試，不要以挑刺的形象出現

3-可熟練閱讀需求規格說明書等文檔

4-以用戶的觀點看問題

5-有強烈的質量意識

6-細心和責任心

7-良好的有效的溝通方式(與開發人員及客戶)

8-具備以往的測試經驗可以及時準確的判斷出高危險區在何處

20、作好軟件測試的一些關鍵點

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

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

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

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

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

6-對於複雜的流程必定要進行流程分支，組合條件分析，再進行等價類劃分準備相關測試數據

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

8-我的任務平均每三個測試用例至少應該發現一個BUG，不然只能說明測試用例質量很差

9-除了天天構建的重複測試能夠考慮測試自動化外，其餘暫時都不要考慮去自動話

2一、軟件測試員自身素質培養

1-首先，應對軟件測試感興趣和對本身有自信，若是具有了這兩點，那麼在開發過程當中無論遇到什麼樣的困難，相信必定能克服

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

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

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

5-作測試時要細心，不是全部的BUG都能很容易找出，必定要細心才能找到這些BUG。

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

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

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

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

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

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

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

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

2二、爲什要在一個團隊中開展測試工做？

由於沒有通過測試的軟件很難在發佈以前知道該軟件的質量，就比如ISO質量認證同樣，測試一樣也須要質量認證，這個時候就須要在團隊中開展軟件測試的工做。在測試的過程當中發現軟件中存在的問題，及時讓開發人員得知並修改問題，在即將發佈時，從測試報告中得出軟件的質量狀況。

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

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

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

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

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

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

2四、你認爲作好測試用例設計工做的關鍵是什麼

白盒測試用例設計的關鍵是以較少的用例覆蓋儘量多的內部程序邏輯結構。黑盒測試用例設計的關鍵一樣也是以較少的用例覆蓋模塊輸出和輸入接口。不可能作到徹底測試，以最少的用例在合理的時間內發現最多的問題。軟件的黑盒測試意味着測試要在軟件的接口處進行，這種方法是把測試對象看做是一個黑盒子，測試人員徹底不考慮程序內部的邏輯結構和內部特性，只依據程序的需求規格說明書，檢查程序的功能是否符合它的功能說明。所以黑盒測試又叫功能測試或者數據驅動測試。黑盒測試主要是爲了發現如下幾類錯誤：、

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

2-在接口上，輸入是否能正確的接受？可否輸出正確的結果。

3-是否有數據結構錯誤或外部信息(例如數據文件)訪問錯誤

4-性能上是否可以知足要求

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

軟件的白盒測試是對軟件的過程性細節作細緻的檢查。這種方法是把測試對象看做一個打開的盒子，它容許測試人員利用程序內部的邏輯結構和有關信息，設計或者選擇測試用例，對程序全部邏輯路徑進行測試。經過在不一樣點檢查程序狀態，肯定實際狀態是否與預期的狀態一直。所以白盒測試又稱爲結合測試或邏輯驅動測試。白盒測試主要是想對程序模塊進行以下檢查：

1-對程序模塊的全部獨立的執行路徑至少測試一遍。

2-對全部的邏輯斷定，取「真」與取「假」的兩種狀況都能至少測一遍。

3-在循環的邊界和運行的界限內執行循環體。

4-測試內部數據結構的有效性，等等。

2五、請詳細介紹一下各類測試類型的含義

1-單元測試(模塊測試)是開發者編寫的一小段代碼，用於檢驗被測試代碼的一個很小的、很明確的功能是否正確。一般而言，一個單元測試是用於判斷某個特定條件(或者場景)下某個特定函數的行爲。單元測試是由程序員本身來完成，最終受益的也是程序員本身。能夠這麼說，程序員有責任編寫功能代碼，同時也就有責任爲本身的代碼編寫單元測試。執行單元測試，就是爲了證實這段代碼的行爲和咱們指望的一致。

2-集成測試(也叫組裝測試、聯合測試)是單元測試的邏輯擴展。它最簡單的形式是：兩個已經通過測試的單元組合成一個組件，而且測試它們之間的接口。從這一層上講，組件是指多個單元的集成聚合。在現實方案中，許多單元組合成組件，而這些組件又聚合成程序的更大部分。方法是測試片斷的組合，並最終擴展進程，將您的模塊與其餘組的模塊一塊兒測試。最後，將構成進程的全部模塊一塊兒測試。

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

4-驗收測試是部署軟件以前的最後一個測試操做。驗收測試的目的是確保軟件準備就緒，而且可讓用戶將其執行軟件的既定功能和任務。驗收測試是向將來的用戶代表系統可以像預訂要求那樣工做。經集成測試後，已經按照設計把全部的模塊組裝成一個完整的軟件系統，接口錯誤也已經基本排除了，接着就應該進一步驗證軟件的有效性，這就是驗收測試的任務，即軟件的功能和性能如同用戶所合理期待的那樣。

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

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

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

2七、您認爲作好測試計劃工做的關鍵是什麼？

1-明確測試的目標，加強測試計劃的實用性

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

2-堅持「5W」規則，明確內容與過程

「5W」規則指的是「WHAT(作什麼)」、「WHY(爲何作)」、"WHEN(什麼時候作)"、"WHERE(在哪裏)"、"HOW(如何作)"。利用「5W"規則建立軟件測試計劃，能夠幫助測試團隊理解測試的目的(WHY)，明確測試的範圍和內容(WHAT)，肯定測試的開始和結束日期(WHEN)，指出測試的方法和工具(HOW)，給出測試文檔和軟件存放的位置(WHERE)。

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

測試計劃完成後，若是沒有通過評審，直接發送給測試團隊，測試計劃內容的可能不許確或遺漏測試內容，或者軟件需求變動引發測試範圍的增減，而測試計劃的內容沒有及時更新，誤導測試執行人員。

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

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

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

開發人員說不是BUG，有2種狀況，一是需求沒有肯定，因此我能夠這麼作，這個時候能夠找來產品經理進行確認，需不須要改動。3方商量肯定好後再看要不要改。二是這種狀況不可能發生，因此不須要修改，這個時候，我能夠先儘量的說出是BUG的一句是什麼？若是被用戶發現或出了問題，會有什麼不良結果？程序員可能會給你不少理由，你能夠對他的解釋進行反駁。若是仍是不行，那我能夠給這個問題提出來，跟開發經理和測試經理進行確認，若是要修改就改，若是不要修改就不改。其實有些真的不是BUG，我也只是建議的方式寫進測試文檔中，若是開發人員不修改也沒有大問題。若是不是BUG的話，必定要堅持本身的立場，讓問題獲得最後的確認。

2九、你自認爲測試的優點在哪裏？

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

30、什麼是系統瓶頸？

瓶頸主要是指整個軟硬件構成的軟件系統某一方面或者幾個方面能力不能知足用戶的特定業務要求，「特定」是指瓶頸會在某些條件下會出現，由於畢竟大多數系統在投入前。

嚴格的從技術角度講，全部的系統都會有瓶頸，由於大多數系統的資源配置不是協調的，例如CPU使用率恰好達到100％時，內存也正好耗盡的系統不是不少見。所以咱們討論系統瓶頸要從應用的角度討論：關鍵是看系統可否知足用戶需求。在用戶極限使用系統的狀況下，系統的響應仍然正常，咱們能夠認爲改系統沒有瓶頸或者瓶頸不會影響用戶工做。

所以咱們測試系統瓶頸主要是實現下面兩個目的：

-發現「表面」的瓶頸。主要是模擬用戶的操做，找出用戶極限使用系統時的瓶頸，而後解決瓶頸，這是性能測試的基本目標。

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

3一、文檔測試主要包含什麼內容？

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

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

描述與軟件實際狀況的一致性：主要測試軟件文檔與軟件實際的一致程度。例如用戶手冊基本完整後，咱們還要注意用戶手冊與實際功能描述是否一致。由於文檔每每跟不上軟件版本的更新速度。

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

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

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

3二、功能測試用例須要詳細到什麼程度纔是合格的？

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

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

實際上，軟件測試用例的詳細程度首先要以覆蓋到測試點爲基本要求。舉個例子：「用戶登錄系統」的測試用例能夠不寫出具體的執行數據，可是至少要寫出五種以上狀況（），若是隻用一句話覆蓋了這個功能是不合格的測試用例。覆蓋功能點不是指列出功能點，而是要寫出功能點的各個方面（若是組合狀況較多時能夠採用等價劃分）。

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

所以，測試用例的編寫要根據測試對象特色、團隊的執行能力等各個方面綜合起來決定編寫策略。最後要注意的是測試人員必定不能抱怨，力爭在不斷提升測試用例編寫水平的同時，不斷地提升自身能力。

3三、配置和兼容性測試的區別是什麼？

配置測試的目的是保證軟件在其相關的硬件上可以正常運行，而兼容性測試主要是測試軟件可否與不一樣的軟件正確協做。

配置測試的核心內容就是使用各類硬件來測試軟件的運行狀況，通常包括：

（1）軟件在不一樣的硬件上的運行狀況；

（2）軟件在不一樣的組件上的運行狀況，例如開發的app要測試在不一樣廠商手機上的安裝運行狀況；

（3）不一樣的外設；

（4）不一樣的接口；

（5）不一樣的可選項，例如不一樣的內存大小；

兼容性測試的核心內容：

（1）測試軟件是否能在不一樣的操做系統平臺上兼容；

（2）測試軟件是否能在同一操做系統平臺的不一樣版本上兼容；

（3）軟件自己可否向前或者向後兼容；

（4）測試軟件可否與其它相關的軟件兼容；

（5）數據兼容性測試，主要是指數據可否共享；

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

3四、軟件文檔測試主要包含什麼？

隨着軟件文檔系統日益龐大，文檔測試已經成爲軟件測試的重要內容。文檔測試對象主要以下：

-包裝文字和圖形；

-市場宣傳材料、廣告以及其它插頁；

-受權、註冊登記表；

-最終用戶許可協議；

-安裝和設置嚮導；

-用戶手冊；

-聯機幫助；

-樣例、示範例子和模板；

-……

文檔測試的目的是提升易用性和可靠性，下降支持費用，由於用戶經過文檔就能夠本身解決問題。因文檔測試的檢查內容主要以下：

-讀者對象——主要是文檔的內容是否能讓該級別的讀者理解；

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

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

-圖標和屏幕抓圖——檢查圖表的準確度和精確度；

-樣例和示例——是否與軟件功能一致；

-拼寫和語法；

-文檔的關聯性——是否與其它相關文檔的內容一致，例如與廣告信息是否一致；

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

3五、沒有產品說明書和需求文檔地狀況下可以進行黑盒測試嗎？

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

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

3六、測試中的「殺蟲劑怪事」是指什麼？

「殺蟲劑怪事」一詞由BorisBeizer在其編著的《軟件測試技術》第二版中提出。用於描述測試人員對同一測試對象進行的測試次數越多，發現的缺陷就會愈來愈少的現象。就像老用一種農藥，害蟲就會有免疫力，農藥發揮不了效力。這種現象的根本緣由就是測試人員對測試軟件過於熟悉，造成思惟定勢。

爲了克服這種現象，測試人員須要不斷編寫新的測試程序或者測試用例，對程序的不一樣部分進行測試，以發現更多的缺陷。也能夠引用新人來測試軟件，剛剛進來的新手每每能發現一些意想不到的問題。

3七、在配置測試中，如何判斷髮現的缺陷是普通問題仍是特定的配置問題？

在進行配置測試時，測試工程師仍然會發現一些普通的缺陷，也就是與配置環境無關的缺陷。所以判斷新發現的問題，須要在不一樣的配置中從新執行發現軟件缺陷的步驟，若是軟件缺陷不出現了，就多是配置缺陷；若是在全部的配置中都出現，就多是普通缺陷。

3八、爲何儘可能不要讓時間有富裕的員工去作一些測試？

表面上看這體現了管理的效率和靈活性，但實際上也體現了管理者對測試的輕視。測試和測試的人有很大關係。測試工做人員應該是勤奮並富有耐心，善於學習、思考和發現問題，細心有條理，總結問題，若是具有這樣的優勢，作其它工做一樣也會很出色，所以這裏還有一個要求，就是要喜歡測試這項工做。若是他是專職的，那麼確定更有經驗和信心。國內的小夥子好象都喜歡作程序員，二者工做性質不一樣，待遇不一樣，地位不一樣，對自我實現的價值的認識也不一樣，這是行業的一個須要改善的問題。若是隻是爲了完成任務而完成任務，或者發現了幾個問題就以爲滿意了，這在任何其它工做中都是不行的。

3九、徹底測試程序是可能的嗎？

軟件測試初學者可能認爲拿到軟件後須要進行徹底測試，找到所有的軟件缺陷，使軟件「零缺陷」發佈。實際上徹底測試是不可能的。主要有如下一個緣由：

-徹底測試比較耗時，時間上不容許；

-徹底測試一般意味着較多資源投入，這在現實中每每是行不通的；

-輸入量太大，不能一一進行測試；

-輸出結果太多，只能分類進行驗證；

-軟件實現途徑太多；

-軟件產品說明書沒有客觀標準，從不一樣的角度看，軟件缺陷的標準不一樣；

所以測試的程度要根據實際狀況肯定。

40、軟件測試的風險主要體如今哪裏？

咱們沒有對軟件進行徹底測試，實際就是選擇了風險，由於缺陷極有可能存在沒有進行測試的部分。舉個例子，程序員爲了方便，在調試程序時會彈出一些提示信息框，而這些提示只在某種條件下會彈出，碰巧程序發佈前這些代碼中的一些沒有被註釋掉。在測試時測試工程師又沒有對其進行測試。若是客戶碰到它，這將是代價昂貴的缺陷，由於交付後才被客戶發現。

所以，咱們要儘量的選擇最合適的測試量，把風險下降到最小。

4一、發現的缺陷越多，說明軟件缺陷越多嗎？

這是一個比較常見的現象。測試工程師在沒有找到缺陷前會絞盡腦汁的思考，可是找到一個後，會連續不斷的發現不少缺陷，很有我的成就感。其中的緣由主要以下：

-代碼複用、拷貝代碼致使程序員容易犯相同的錯誤。類的繼承致使全部的子類會包含基類的錯誤，反覆拷貝同一代碼意味可能也複製了缺陷。

-程序員比較勞累是能夠致使某些連續編寫的功能缺陷較多。程序員加班是一種司空見慣的現象，所以體力不僅時容易編寫一些缺陷較多的程序。而這些連續潛伏缺陷偏偏時測試工程師大顯身手的地方。

「缺陷一個連着一個」不是一個客觀規律，只是一個常見的現象。若是軟件編寫的比較好，這種現象就不常見了。測試人員只要嚴肅認真的測試程序就能夠了。

4二、全部的軟件缺陷都能修復嗎？全部的軟件缺陷都要修復嗎？

從技術上講，全部的軟件缺陷都是可以修復的，可是沒有必要修復全部的軟件缺陷。測試人員要作的是可以正確判斷何時不能追求軟件的完美。對於整個項目團隊，要作的是對每個軟件缺陷進行取捨，根據風險決定那些缺陷要修復。發生這種現象的主要緣由以下：

-沒有足夠的時間資源。在任何一個項目中，一般狀況下開發人員和測試人員都是不夠用的，並且在項目中沒有預算足夠的迴歸測試時間，再加上修改缺陷可能引入新的缺陷，所以在交付期限的強大壓力下，必須放棄某些缺陷的修改。

-有些缺陷只是特殊狀況下出現，這種缺陷處於商業利益考慮，能夠在之後升級中進行修復。

-不是缺陷的缺陷。咱們常常會碰到某些功能方面的問題被當成缺陷來處理，這類問題能夠之後有時間時考慮再處理。

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

4三、軟件測試人員就是QA嗎？

軟件測試人員的職責是儘量早的找出軟件缺陷，確保得以修復。而質量保證人員（QA）主要職責是建立或者制定標準和方法，提升促進軟件開發能力和減小軟件缺陷。測試人員的主要工做是測試，質量保證人員平常工做重要內容是檢查與評審，測試工做也是測試保證人員的工做對象。

軟件測試和質量是相輔相成的關係，都是爲了提升軟件質量而工做。

4四、如何減小測試人員跳槽帶來的損失？

在IT行業裏跳槽已是一種司空見慣的現象，並且跳槽不管給公司仍是給我的都會帶來必定的損失。測試隊伍也無疑會面臨跳槽的威脅，做爲測試經理管理者，只有從平常工做中開始作起，最能最大限度的減小損失。建議咱們從如下兩個方面作起：

-增強部門內員工之間的互相學習，互相學習是創建學習型組織的基本要求，是知識互相轉移的過程。在此基礎上，能夠把我的擁有的技術以知識的形式沉積下來，也就完成了隱性知識到顯性知識的轉化。

-一般狀況下，企業能爲員工提供足夠大的發展空間時，若是不是待遇特別低，員工都不會主動離開企業。所以咱們要想留住員工，管理者就應該把員工的我的成長和企業的發展聯繫起來，爲員工設定合理發展規劃並付諸實現。不過這項要求作起來比較，要有比較好的企業文化爲依託。

4五、測試產品與測試項目的區別是什麼？

習慣上把開發完成後進行商業化、幾乎不進行代碼修改就能夠售給用戶使用的軟件成爲軟件產品，也就是能夠買「賣拷貝」的軟件，例如Windows。而一般把針對一個或者幾個特定的用戶而開發的軟件成爲軟件項目，軟件項目是一種個性化的產品，能夠是按照用戶要求所有從新開發，也能夠修改已有的軟件產品來知足特定的用戶需求。項目和產品的不一樣特色，決定咱們測試產品和測試項目仍然會有不少不一樣的地方：

-質量要求不一樣。一般產品的質量要高一些，修復發佈後產品的缺陷成本較高，甚至會帶來不少負面的影響。而作項目一般面向某一用戶，雖然質量越高越好，可是通常只要知足用戶要求就能夠了。

-測試資源投入多少不一樣。作軟件產品一般是研發中心來開發，進度壓力要小些。同時因爲質量要求高，所以會投入較多的人力、物力資源。

-項目最後要和用戶共同驗收測試，這是產品測試不具備的特色。

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

4六、和用戶共同測試（UAT測試）的注意點有哪些？

軟件產品在投產前，一般都會進行用戶驗收測試。若是用戶驗收測試沒有經過，直接結果就是那不到「Money」，間接影響是損害了公司的形象，然後者的影響每每更嚴重。根據做者的經驗，用戶驗收測試必定要讓用戶滿意。

實際上用戶現場測試更趨因而一種演示。在不欺騙用戶的前提下，咱們向用戶展現咱們軟件的優勢，最後讓「上帝」滿意並欣然掏出「銀子」纔是咱們的目標。所以用戶測試要注意下面的事項：

（1）用戶現場測試不可能測試所有功能，所以要測試核心功能。這須要提早作好準備，這些核心功能必定要預先通過測試，證實沒有問題才能夠和用戶共同進行測試。測試核心模塊的目的是創建用戶對軟件的信心。固然若是這些模塊若是問題較多，不該該進行演示。

（2）若是某些模塊確實有問題，咱們能夠演示其它重要的業務功能模塊，必要時要向用戶作成合理的解釋。爭得時間後，及時修改缺陷來彌補。

（3）永遠不能欺騙用戶，矇混過關。道理很簡單，由於軟件是要給用戶用的，問題遲早會暴露出來，除非你能夠立刻修改。

和用戶進行測試還要注意各類交流技巧，爭取不但短時間利益獲得了知足，還要爲後面得合做打好基礎。

4七、如何編寫提交給用戶的測試報告？

隨着測試工做愈來愈受重視，開發團隊向客戶提供測試文檔是不可避免的事情。不少人會問：「咱們能夠把工做中的測試報告提供給客戶嗎？」答案是否認的。由於提供內部測試報告，可能會讓客戶失去信心，甚至否認項目。

測試報告通常分爲內部測試報告和外部測試報告。內部報告是咱們在測試工做中的項目文檔，反映了測試工做的實施狀況，這裏不過多討論，讀者能夠參考相關教材。這裏主要討論一下外部測試報告的寫法，通常外部測試報告要知足下面幾個要求：

-根據內部測試報告進行編寫，通常能夠摘錄；

-不能夠向客戶報告嚴重缺陷，即便是已經修改的缺陷，開發中的缺陷也沒有必要讓客戶知道；

-報告上能夠列出一些缺陷，但必須是中級的缺陷，並且這些缺陷必須是修復的；

-報告上面的內容儘可能要真實可靠；

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

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

4八、測試工具在測試工做中是什麼地位？

國內的不少測試工程師對測試工具至關迷戀，尤爲是一些新手，甚至指望測試工具能夠取代手工測試。測試工具在測試工做中起的是輔助做用，通常用來提升測試效率。自動化測試彌補了手工測試的不足，減輕必定的工做量。實際上測試工具是沒法替代大多數手工測試的，而一些諸如性能測試等自動化測試也是手工所不能完成的。

對於自動測試技術，應當依據軟件的不一樣狀況來分別對待，通常自動技術會應用在引發大量重複性工做的地方、系統的壓力點、以及任何適合使用程序解決大批量輸入數據的地方。而後再尋找合適的自動測試工具，或者本身開發測試程序。必定不要爲了使用測試工具而使用。

4九、常見的測試用例設計方法都有哪些？請分別以具體的例子來講明這些方法在測試用例設計工做中的應用。

1-等價類劃分

常見的軟件測試面試題劃分等價類: 等價類是指某個輸入域的子集合.在該子集合中,各個輸入數據對於揭露程序中的錯誤都是等效的.併合理地假定:測試某等價類的表明值就等於對這一類其它值的測試.所以,能夠把所有輸入數據合理劃分爲若干等價類,在每個等價類中取一個數據做爲測試的輸入條件,就能夠用少許表明性的測試數據.取得較好的測試結果.等價類劃分可有兩種不一樣的狀況:有效等價類和無效等價類.

2-邊界值分析法

邊界值分析方法是對等價類劃分方法的補充。測試工做經驗告訴我,大量的錯誤是發生在輸入或輸出範圍的邊界上,而不是發生在輸入輸出範圍的內部.所以針對各類邊界狀況設計測試用例,能夠查出更多的錯誤.

使用邊界值分析方法設計測試用例,首先應肯定邊界狀況.一般輸入和輸出等價類的邊界,就是應着重測試的邊界狀況.應當選取正好等於,剛剛大於或剛剛小於邊界的值做爲測試數據,而不是選取等價類中的典型值或任意值做爲測試數據.

3-錯誤推測法

基於經驗和直覺推測程序中全部可能存在的各類錯誤, 從而有針對性的設計測試用例的方法.

錯誤推測方法的基本思想: 列舉出程序中全部可能有的錯誤和容易發生錯誤的特殊狀況,根據他們選擇測試用例-例如, 在單元測試時曾列出的許多在模塊中常見的錯誤-之前產品測試中曾經發現的錯誤等, 這些就是經驗的總結。還有, 輸入數據和輸出數據爲0的狀況。輸入表格爲空格或輸入表格只有一行-這些都是容易發生錯誤的狀況。可選擇這些狀況下的例子做爲測試用例.

4-因果圖方法

前面介紹的等價類劃分方法和邊界值分析方法,都是着重考慮輸入條件,但未考慮輸入條件之間的聯繫, 相互組合等-考慮輸入條件之間的相互組合,可能會產生一些新的狀況-但要檢查輸入條件的組合不是一件容易的事情, 即便把全部輸入條件劃分紅等價類,他們之間的組合狀況也至關多-所以必須考慮採用一種適合於描述對於多種條件的組合,相應產生多個動做的形式來考慮設計測試用例-這就須要利用因果圖（邏輯模型）-因果圖方法最終生成的就是斷定表-它適合於檢查程序輸入條件的各類組合狀況.

5-正交表分析法

有時候，可能由於大量的參數的組合而引發測試用例數量上的激增，同時，這些測試用例並無明顯的優先級上的差距，而測試人員又沒法完成這麼多數量的測試，就能夠經過正交表來進行縮減一些用例，從而達到儘可能少的用例覆蓋儘可能大的範圍的可能性。

6-場景分析方法

指根據用戶場景來模擬用戶的操做步驟，這個比較相似因果圖，可是可能執行的深度和可行性更好。

50、您認爲作好測試用例設計工做的關鍵是什麼？

白盒測試用例設計的關鍵是以較少的用例覆蓋儘量多的內部程序邏輯結果

黑盒法用例設計的關鍵一樣也是以較少的用例覆蓋模塊輸出和輸入接口。不可能作到徹底測試，以最少的用例在合理的時間內發現最多的問題

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

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

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

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

4-測試用例完成後，測試和開發須要進行評審。