軟件測試面試題整理

01. 爲何要在一個團隊中開展軟件測試工做？

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

 

02. 您在以往的測試工做中都曾經具體從事過哪些工做？其中最擅長哪部分工做？

　　我曾經作過web測試，後臺測試，客戶端軟件，其中包括功能測試，性能測試，用戶體驗測試。最擅長的是功能測試

 

03. 您所熟悉的軟件測試類型都有哪些？請試着分別比較這些不一樣04. 的測試類型的區別與聯繫（如功能測試、性能測試……）

　　測試類型有：功能測試，性能測試，界面測試。

　　功能測試在測試工做中佔的比例最大，功能測試也叫黑盒測試。是把測試對象看做一個黑盒子。利用黑盒測試法進行動態測試時，須要測試軟件產品的功能，不需測試軟件產品的內部結構和處理過程。採用黑盒技術設計測試用例的方法有：等價類劃分、邊界值分析、錯誤推測、因果圖和綜合策略。

　　性能測試是經過自動化的測試工具模擬多種正常、峯值以及異常負載條件來對系統的各項性能指標進行測試。負載測試和壓力測試都屬於性能測試，二者能夠結合進行。經過負載測試，肯定在各類工做負載下系統的性能，目標是測試當負載逐漸增長時，系統各項性能指標的變化狀況。壓力測試是經過肯定一個系統的瓶頸或者不能接收的性能點，來得到系統能提供的最大服務級別的測試。

　　界面測試，界面是軟件與用戶交互的最直接的層，界面的好壞決定用戶對軟件的第一印象。並且設計良好的界面可以引導用戶本身完成相應的操做，起到嚮導的做用。同時界面如同人的面孔，具備吸引用戶的直接優點。設計合理的界面能給用戶帶來輕鬆愉悅的感覺和成功的感受，相反因爲界面設計的失敗，讓用戶有挫敗感，再實用強大的功能均可能在用戶的畏懼與放棄中付諸東流。

　　區別在於，功能測試關注產品的全部功能上，要考慮到每一個細節功能，每一個可能存在的功能問題。性能測試主要關注於產品總體的多用戶併發下的穩定性和健壯性。界面測試更關注於用戶體驗上，用戶使用該產品的時候是否易用，是否易懂，是否規範（快捷鍵之類的），是否美觀（可否吸引用戶的注意力），是否安全（儘可能在前臺避免用戶無心輸入無效的數據，固然考慮到體驗性，不能太粗魯的彈出警告）？作某個性能測試的時候，首先它多是個功能點，首先要保證它的功能是沒問題的，而後再考慮該功能點的性能測試

 

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

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

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

 

 

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

 

　　黑盒測試：已知產品的功能設計規格，能夠進行測試證實每一個實現了的功能是否符合要求。

　　白盒測試：已知產品的內部工做過程，能夠經過測試證實每種內部操做是否符合設計規格要求，全部內部成分是否以通過檢查。

 

　　軟件的黑盒測試意味着測試要在軟件的接口處進行。這種方法是把測試對象看作一個黑盒子，測試人員徹底不考慮程序內部的邏輯結構和內部特性，只依據程序的需求規格說明書，檢查程序的功能是否符合它的功能說明。所以黑盒測試又叫功能測試或數據驅動測試。黑盒測試主要是爲了發現如下幾類錯誤：

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

　　二、在接口上，輸入是否能正確的接受？可否輸出正確的結果？

　　三、是否有數據結構錯誤或外部信息（例如數據文件）訪問錯誤？

　　四、性能上是否可以知足要求？

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

 

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

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

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

　　三、在循環的邊界和運行的界限內執行循環體。

　　四、測試內部數據結構的有效性，等等。

 

　　單元測試（模塊測試）是開發者編寫的一小段代碼，用於檢驗被測代碼的一個很小的、很明確的功能是否正確。一般而言，一個單元測試是用於判斷某個特定條件（或者場景）下某個特定函數的行爲。

 

　　單元測試是由程序員本身來完成，最終受益的也是程序員本身。能夠這麼說，程序員有責任編寫功能代碼，同時也就有責任爲本身的代碼編寫單元測試。執行單元測試，就是爲了證實這段代碼的行爲和咱們指望的一致。

 

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

 

　　系統測試是將通過測試的子系統裝配成一個完整系統來測試。它是檢驗系統是否確實能提供系統方案說明書中指定功能的有效方法。（常見的聯調測試）

 

　　系統測試的目的是對最終軟件系統進行全面的測試，確保最終軟件系統知足產品需求而且遵循系統設計。

 

　　驗收測試是部署軟件以前的最後一個測試操做。驗收測試的目的是確保軟件準備就緒，而且可讓最終用戶將其用於執行軟件的既定功能和任務。

驗收測試是向將來的用戶代表系統可以像預約要求那樣工做。經集成測試後，已經按照設計把全部的模塊組裝成一個完整的軟件系統，接口錯誤也已經基本排除了，接着就應該進一步驗證軟件的有效性，這就是驗收測試的任務，即軟件的功能和性能如同用戶所合理期待的那樣。

 

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

 

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

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

 

07. 您認爲作好測試計劃工做的關鍵是什麼？

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

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

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

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

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

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

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

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

 

08. 您所熟悉的測試用例設計方法都有哪些？請分別以具體的例子來講明這些方法在測試用例設計工做中的應用。

　　1．等價類劃分

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

 

　　2．邊界值分析法

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

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

 

　　3．錯誤推測法

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

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

 

　　4．因果圖方法

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

 

09. 請以您以往的實際工做爲例，

 

10. 詳細的描述一次測試用例設計的完整的過程。

　　就說最近的此次網站功能的測試吧

　　首先：獲得相關文檔（需求文檔和設計文檔），理解需求和設計設計思想後，想好測試策略（測試計劃簡單點就OK了），考慮到測試環境，測試用例，測試時間等問題。

　　第二步：設計測試用例，測試策略是：把網站部分的功能點測試完，而後在進行系統測試（另外個模塊呢有另外一個測試人員負責，能夠進行聯調測試），網站模塊的測試基本是功能測試和界面測試（用戶併發的可能性很小，因此不考慮）：此次的網站的輸入數據呢是使用數據庫中的某張表記錄，若是表中某一數據記錄中新加進來的（尚未被處理的，有個標誌位），網站啓動後會馬上去刷那張表，獲得多條數據，而後在進行處理。處理過程當中，會經歷3個步驟，網站纔算完成了它的任務。有3個步驟呢，就能夠分別對　　這3個步驟進行測試用例的設計,儘可能覆蓋到各類輸入狀況（包括數據庫中的數據，用戶的輸入等），得出了差很少50個用例。界面測試，也就是用戶看的到的地方，包括髮送的郵件和用戶填寫資料的頁面展現。

　　第三步：搭建測試環境（爲何這個時候考慮測試環境呢？由於我對網站環境已經很熟了，只有有機器能空於下來作該功能測試就能夠作了），由於網站自己的環境搭建和其餘的系統有點不一樣，它須要的測試環境比較麻煩，須要web服務器（Apache,tomcat），不過此次需求呢，網站部分只用到了tomcat，因此只要有tomcat便可

　　第四步：執行測試

 

11. 您以往是否曾經從事過性能測試工做？若是有，請儘量的詳細描述您以往的性能測試工做的完整過程。

　　是的，曾經作過網站方面的性能測試，雖然作的時間並不久（2個月吧），當時呢，是有位網站性能測試經驗很是豐富的前輩帶着我一塊兒作。

性能測試類型包括負載測試，強度測試，容量測試等

　　負載測試：負載測試是一種性能測試指數據在超負荷環境中運行，程序是否可以承擔。

　　強度測試： 強度測試是一種性能測試，他在系統資源特別低的狀況下軟件系統運行狀況

　　容量測試：肯定系統可處理同時在線的最大用戶數  

　　在網站流量逐漸加大的狀況下，開始考慮作性能測試了，首先要寫好性能測試計劃，根據運營數據得出流量最大的頁面（若是是第一次的話，通常是首頁，下載頁，我的賬戶頁流量最大，並且以某種百分比），

 

　　Web服務器指標指標：

　　* Avg Rps: 平均每秒鐘響應次數＝總請求時間 / 秒數；

　　* Successful Rounds：成功的請求；

　　* Failed Rounds ：失敗的請求；

　　* Successful Hits ：成功的點擊次數；

　　* Failed Hits ：失敗的點擊次數；

　　* Hits Per Second ：每秒點擊次數；

　　* Successful Hits Per Second ：每秒成功的點擊次數；

　　* Failed Hits Per Second ：每秒失敗的點擊次數；

　　* Attempted Connections ：嘗試連接數；　　

 

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

 

17. 您認爲性能測試工做的目的是什麼？作好性能測試工做的關鍵是什麼？

 

18. 在您以往的工做中，19. 一條軟件缺陷（或者叫Bug）記錄都包含了哪些內容？如何提交高質量的軟件缺陷（Bug）記錄？

 

20. 您以往所從事的軟件測試工做中，是否使用了一些工具來進行軟件缺陷（Bug）的管理？若是有，請結合該工具描述軟件缺陷（Bug）跟蹤管理的流程。

 

23. 您認爲在測試人員同開發人員的溝經過程中，如何提升溝通的效率和改善溝通的效果？維持測試人員同開發團隊中其餘成員良好的人際關係的關鍵是什麼？

 

27. 在您以往的測試工做中，最讓您感到不滿意或者不堪回首的事情是什麼？您是如何來對待這些事情的？

 

31. 在即將完成此次筆試前，您是否願意談一些本身在以往的學習和工做中得到的工做經驗和心得體會？（能夠包括軟件測試、過程改進、軟件開發或者與此無關的其餘方面）

 

33. 你對測試最大的興趣在哪裏？爲何？

　　最大的興趣就是測試有難度，有挑戰性！作測試越久越能感受到作好測試有多難。曾經在無憂測試網上看到一篇文章，是關於如何作好一名測試工程師。一共羅列了11，12點，有部分是和人的性格有關，有部分須要後天的努力。但除了性格有關的1，2點我沒有把握，其餘點我都頗有信心作好它。

　　剛開始進入測試行業時，對測試的認識是從無憂測試網上了解到的一些資料，當時是衝着作測試須要不少技能才能作的好，雖然入門容易，但作好很難，比開發更難，雖然當時我很想作開發（學校專業課我基本上不缺席，由於我喜歡個人專業），但看到測試比開發更難更有挑戰性，想作好測試的意志就更堅決了。

　　不到一年半的測試工做中，當時的感動和熱情沒有減退一點（即便環境問題以及自身經驗，技術的不足，作測試的你必定也能理解）。

　　我以爲作測試整個過程當中有2點讓我以爲頗有難度（對我來講，有難度的東西我就很是感興趣），第一是測試用例的設計，由於測試的精華就在測試用例的設計上了，要在版本出來以前，把用例寫好，用什麼測試方法寫？（也就是測試計劃或測試策略），若是你剛測試一個新任務時，你得花必定的時間去消化業務需求和技術基礎，業務需求很好理解（多和產品經理和開發人員溝通就能達到目的），而技術基礎可就沒那麼簡單了，這須要你自覺的學習能力，好比說網站吧，最基本的技術知識你要知道網站內部是怎麼運做的的，後臺是怎麼響應用戶請求的？測試環境如何搭建？這些都須要最先的學好。至少在開始測試以前能作好基本的準備，可能會遇到什麼難題？需求細節是否是沒有肯定好？這些問題都能在設計用例的時候發現。

　　第二是發現BUG的時候了，這應該是測試人員最基本的任務了，通常按測試用例開始測試就能發現大部分的bug，還有一部分bug須要測試的過程當中更瞭解所測版本的狀況得到更多信息，補充測試用例，測試出bug。還有如何發現bug？這就須要在測試用例有效的狀況下，經過細心和耐心去發現bug了，每一個用例都有可能發現bug，每一個地方都有可能出錯，因此測試過程當中思惟要清晰（測試過程數據流及結果都得看仔細了，bug都在裏面發現的）。如何描述bug也頗有講究，bug在什麼狀況下會產生，若是條件變化一點點，就不會有這個bug，以哪些最少的操做步驟就能重現這個bug，這個bug產生的規律是什麼？若是你夠厲害的話，能夠幫開發人員初步定位問題。

 

34. 你的測試職業發展是什麼？

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

 

35. 你自認爲測試的優點在哪裏？

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

 

36. 你之前工做時的測試流程是什麼？

　　公司對測試流程沒有規定如何作，但每一個測試人員都有本身的一套測試流程。我說下我1年來不斷改正（本身總結，吸收同行的方法）後的流程吧。需求評審（有開發人員，產品經理，測試人員，項目經理）－>需求肯定(出一份肯定的需求文檔)－>開發設計文檔（開發人員在開始寫代碼前就能輸出設計文檔）－>想好測試策略，寫出測試用例－>發給開發人員和測試經理看看（非正式的評審用例）－>接到測試版本－>執行測試用例（中間可能會補充用例）－>提交bug（有些bug須要開發人員的肯定（嚴重級別的，或忽然發現的在測試用例範圍以外的，難以重現的），有些能夠直接錄製進TD）－>開發人員修改（能夠在測試過程當中快速的修改）－>迴歸測試（可能又會發現新問題，再按流程開始跑）。

 

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

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

 

23．你爲何想離開目前的職務？

　　由於公司運做狀況並不理想，公司須要調整部門體系，公司考慮到縮減部門人員，因此大批量的裁人（有6，7個），這是個人第一份工做，對公司也有較深的感情，由於在這裏我找到了職業理想（就是測試），因此公司須要精簡人員，我自願退出。雖然很捨不得，但我將會有新的發揮能力的舞臺。

 

24：你對咱們公司瞭解有多少？

 

25：你找工做時，最重要的考慮因素爲什麼？

　　工做的性質和內容是否能讓我發揮所長，並不斷成長。

 

26：爲何咱們應該錄取你？

　　您能夠由我過去的工做表現所呈現的客觀數據，明顯地看出我盡心盡力的工做態度。

 

27：請談談你我的的最大特點。

　　個人堅持度很高，事情沒有作到一個使人滿意的結果，毫不罷手。

 

28.白箱測試和黑箱測試是什麼?什麼是迴歸測試?

 

29。單元測試、集成測試、系統測試的側重點是什麼？

 

30。設計用例的方法、依據有那些？

 

31。一個測試工程師應具有那些素質和技能？

 

32.集成測試一般都有那些策略？

 

33.你用過的測試工具的主要功能、性能及其餘？

 

34.一個缺陷測試報告的組成

 

35.基於WEB信息管理系統測試時應考慮的因素有哪些？

 

36.軟件測試項目從何時開始，？爲何？

 

37.需求測試注意事項有哪些？

 

38.簡述一下缺陷的生命週期

 

39.測試分析測試用例注意（事項）？

　　你在你所在的公司是怎麼開展測試工做的？是如何組織的？

　　你認爲理想的測試流程是什麼樣子？

　　你是怎樣工做的？

　　軟件測試活動的生命週期是什麼？

　　請畫出軟件測試活動的流程圖？

　　針對缺陷採起怎樣管理措施？

　　什麼是測試評估？測試評估的範圍是什麼？

　　若是可以執行完美的黑盒測試，還須要進行白盒測試嗎？爲何？

　　測試結束的標準是什麼？

　　軟件驗收測試除了alpha,beta測試之外,還有哪種?

　　作測試多久了？

　　之前作過哪些項目？

　　大家之前測試的流程是怎樣的？

　　<答：測試計劃－測試用例設計－測試執行－測試分析報告>

　　用過哪些測試工具？

　　爲何選擇測試這行？

　　<答：它是一個新興的行業，有發展潛力，並且很鍛鍊人，須要掌握更多的技能，比作開發要更難>

　　爲何值得他們公司僱用？

　　若是我僱用你，你能給部門帶來什麼貢獻？

　　如何從工做中看出你是個自動自覺的人

　　你的工做一般能在時限內完成嗎.（我想問一下就是她問這個問題的動機是什麼）

　　一般你對於別人批評你會有什麼樣的反應

　　若是明知這樣作不對，你還會依主管的指過去作嗎

　　若是你接到一個客戶抱怨的電話，你確知沒法解決他的問題，你會怎麼處理

　　你以爲什麼樣的人最難相處

　　爲何值得他們公司僱用？

　　　　幫助公司提升軟件質量和測試部門的技術水平

　　若是我僱用你，你能給部門帶來什麼貢獻？

　　　　分享個人測試經驗和測試技能，提升測試部門技術水平

　　如何從工做中看出你是個自動自覺的人

　　　     自動自覺範圍太廣

　    1. 工做成果

    　2. 工做質量 

　　你的工做一般能在時限內完成嗎.（我想問一下就是她問這個問題的動機是什麼）

　　　　在有足夠的資源和合理的工做量的狀況下，徹底能夠按時完成，並能比通常人作的更好

　　一般你對於別人批評你會有什麼樣的反應

　　　　有錯即改，無措勉之

 

　　若是明知這樣作不對，你還會依主管的指過去作嗎

　　　　在公司內部下級是否有申訴渠道？

 

　　若是你接到一個客戶抱怨的電話，你確知沒法解決他的問題，你會怎麼處理

　　　　爲何抱怨？是怎麼樣的問題？

　　　　若是是客服問題，提交客服部門解決

　　　　若是是質量問題，分析緣由，下一版本改進

　　你以爲什麼樣的人最難相處

　　　　自覺得是的人

 

　　什麼叫單元測試？

　　　　請就軟件測試人員應該具有什麼樣的基本素質說說你的見解。

 

　　請就如何在開發中進行軟件質量控制說說你的見解

　　 簡述軟件測試的意義，以及軟件測試的分類

 

一、功能測試，性能測試，界面測試，安全測試（能夠簡單點，好比只涉及到COOKIES裏的內容），壓力測試（商業性質的網站） 等等，B/S軟件也要根據其具體功能採用不一樣的測試策略。

二、態度、責任心、自信、敏銳的觀察力、良好的發散思惟

三、先設計後開發模式，增強單元測試，增強代碼走查，有一套完整的白盒測試方法。關鍵是增強開發人員的質量意識，增進程序員向工程師水平發展。

四、意義嘛，就本身想吧。軟件測試的分類，這個不少人都按各類方法去分。無明確答案給你。

 

對測試的理解——基本的測試知識，對測試是否定可？ 75。

   三、談一談過去本身的工做——瞭解經歷、提供進一步提問的素材，表達能力  

測試技能

測試設計的方法並舉例說明——測試技術的使用

測試工具——熟悉程度，可否與當前工做匹配？

如何作計劃？如何跟蹤計劃？——平常工做能力

若是開發人員提供的版本不知足測試的條件，如何作？——與開發人員協做的能力

熟悉unix系統、oracle數據庫嗎？——是否具有系統知識

作過開發嗎？寫過哪些代碼？——開發技能

閱讀英語文章，給出理解說明？——部分英語能力

文檔的意義——是否善於思考？（最簡單的概念，不一樣層次的理解）

假如進入咱們公司，對咱們哪些方面會有幫助？——講講本身的特長

隨便找一件物品，讓其測試——測試的實際操做能力

軟件測試的方法有？

軟件測試的過程？

有一個新的軟件，假如你是測試工程師，該如何作？

 

軟件測試分哪兩種方法？分別適合什麼狀況？

2。一套完整的測試應該由哪些階段組成？分別闡述一下各個階段。

3。軟件測試的類型有那些？分別比較這些不一樣的測試類型的區別與聯繫。

4。測試用例一般包括那些內容？着重闡述編制測試用例的具體作法

5。在分別測試winform的C/S結構與測試WEB結構的軟件是，應該採起什麼樣的方法分別測試？他們存在什麼樣的區別與聯繫？

6。在測試winform的C/S結構軟件時，發現這個軟件的運行速度很慢，您會認爲是什麼緣由？您會採起哪些方法去檢查這個緣由？

7。描述使用bugzilla缺陷管理工具對軟件缺陷（BUG）跟蹤的管理的流程

你在五年內的我的目標和職業目標分別是什麼？

　　分析這個問題是用來了解你的計劃能力的，經過這個問題，面試人同時還能夠知道你的目標是否符合企業對你的安排。

　　錯誤回答我想在未來的某個時候考慮這個問題。現在企業的領導者更換頻繁，我認爲作太多的我的計劃是荒謬好笑的，不是嗎？

　　評論這種回答屬於使人反感的一類。首先，當有人想了解你的目標時，"未來的某個時候"這種通俗說法並不奏效。其次，認爲企業很脆弱，領導者更換頻繁，這種說法毫無疑問會使人反感，並且也是不合理的。最後，認爲作計劃好笑，看不起這個問題，並且反問面試人，這些都註定了這樣的求職者最終會失敗。

　　正確回答從如今起的五年以內，我但願可以在一個很好的職位上待幾年，並且最好有一次晉升，而後就期待着下一步。無論是向上提高，仍是在企業內橫向調動，對我我的來講，我但願找到一家企業——一家願意作相互投入的企業——待上一段時間。

　　評論這個問題沒有回答得過度具體（那樣可能會產生漏洞），並且它代表你有雄心，而且思考過在企業中的成長方式。經過表達橫向調動和向上提高的願望，代表你是一個有靈活性的人。

　問題23　你怎樣作出本身的職業選擇？

　　分析 面試人提出這個問題是爲了瞭解求職者的動機，看看他（她）應聘這份工做是否有什麼歷史淵源，是否有職業規劃，是否是僅僅在漫無目的地申請不少工做。

　　錯誤回答 我一直都想在企業界工做。自孩提時代起，我就夢想本身至少也要成爲大企業的副總裁。

　　評論 除了難以使人相信以外，這種回答還存在一個問題：它代表求職者會對副總裁如下的職位不感興趣。

　　正確回答 在上大學四年級前的那個夏天，我決定集中精力在某一領域謀求發展。儘管我是學商業的，可是我不知道本身最終會從事哪一行業的工做。我花了必定的時間考慮本身的目標，想清楚了本身擅長作的事情以及想從工做中獲得的東西，最後我得出了一個堅決的結論，那就是這個行業是最適合個人。

　　評論 這種回答代表，求職者認真地作過一些計劃，縮小了本身的關注點，並且也認準了前進的方向。這種回答還代表，求職者理解我的職業規劃的重要性，而且有能力作出認真的我的決策。

1. 你都用什麼測試方法

2.怎麼編寫案例

3.怎麼纔可以全面的測試到每個點

1. 你都用什麼測試方法

針對不一樣的產品或者系統或者模塊，有不一樣的測試方法。整體而言有白盒測試和黑盒測試。

2.怎麼編寫案例

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

3.怎麼纔可以全面的測試到每個點

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

一、談談軟件測試技術，以及如何提升

二、談談軟件測試職業發展，以及我的的打算

三、談談軟件測試在企業的地位，也能夠結合軟件生命週期來談

有可能清晰的思路比確切的答案更重要

在這裏，主要說下筆試和麪試的問題，但願你們共同參考。

    1，通常公司裏實際的軟件測試流程是什麼樣的？大家公司又是怎樣的？

    2，軟件工程師要具備那些素質？

    3，你會哪些測試工具？怎麼操做？

    4，你能不能說下你的3到5年的職業計劃（規劃）

    5，你以爲你來應聘有那些優點？

其他的還好說，但就第4個問題，我感到很差說哦！但願你們給個意見

第一關：首先要自我介紹，本身的性格怎麼樣，目前的工做經歷積累了一些什麼經驗取得了些什麼值得一說的成果。而後要說說對軟件測試怎麼看？還有對於軟件測試有什麼本身的想法。爲何會想到要作這行（由於個人簡歷上的工做經歷沒有關於測試方面的）。哦，還有指望薪資。

第二關：認爲軟件測試人員所要具有的基本素質，若是遇到問題會怎樣處理，若是得不到研發人員的配合（就是研發說這個不是問題）你又會怎麼處理？而後就是一些基本概念，好比軟件測試的流程有哪些？若是我上任了，首先會怎麼開始本身的工做計劃。

（前兩關經過了後面這個就好過多了）

第三關：像我介紹了一下公司的狀況，告訴我主要針對什麼內容的測試，會不會使用數據庫。告訴我大概要作哪些內容，詳細的能夠上崗之後慢慢熟悉。

大概就這麼多了，這對沒有通過這一關的不知道有沒有幫助，僅供參考吧

我以爲就像李波說的，關鍵是要給對方留下好印象:)

 

面試官最後會問你有什麼問題要問嗎。做爲應聘者的你通常不要說沒問題問，這會給面試官留下你不過重視這份工做的壞印象。因此若是你想獲得這份工做的話應該抓住這最後的表現本身的機會：

你能夠問：

1.        貴公司近期和遠期的發展目標是什麼？

2.        貴公司的主要競爭對手有哪些？

3.        貴公司有多少開發人員有多少測試人員？

4.        貴公司又進一步擴充測試人員的計劃嗎?

5.        若是我有幸能進入貴公司的話，我有怎麼樣的發展？

6.        測試人員的溝通能力很重要，貴公司有規範的溝通渠道嗎？

7.        請介紹一下貴公司的福利狀況。

8.        請問我何時能知道結果？

 

用友面試：

1． 內聯接和外鏈接，自聯接有什麼區別？

內聯接一般是2個表存在主外鍵關係時使用的，

內聯接查詢有2種方式實現，

1是在WHERE 子句中指定聯接條件

2是在FROM子句中使用join...on

內聯接查詢一般不只僅聯接2表，能夠3表甚至更多的表

參與內聯接的表的地位是平等的

 

而外聯接中參與聯接的表有主從之分。以主表的每行數據去匹配從表的數據列，符合條件的數據將直接返回到結果集中，不符合的用NULL（空值）填充後再返回到結果集中。

 

2． SQL中 /'group by/'和/'order by /'有什麼不一樣呢

一個是對處理的數據進行分組，一個是對處理的數據進行排序

 

 

自動測試的好處：

若是你須要反覆運行一組測試，那麼自動測試將會對你很是有用。

自動測試使你可以應對頻繁改變的代碼從而跟上週期性迴歸測試的腳步。

自動測試能夠使你可以自動運行主流業務場景從而跟上週期性迴歸測試的腳步。（原文：It gives you the ability to run automation in main stream scenarios to catch regressions in a timely manner）

自動測試能夠幫助你測試大量測試矩陣（在不一樣操做系統上的不一樣語言）。自動測試能夠使你的測試同時運行在不一樣的機器上，而手動測試必須不斷地繼續執行。

自動測試的限制：

花費大。編寫測試用例，編寫和配置自動化測試框架將會在測試開始時花費比手動測試更多的費用。

沒法自動測試一些可視的場景。例如，若是你沒法經過代碼告訴自動測試工具字體顏色，那麼只好使用手動測試。

手動測試的好處：

若是一個測試用例在編碼階段只運行兩次，那最好使用手動測試，它將比自動測試花費少得多的費用。

手動測試容許測試員進行更多的隨機測試。以個人經驗來看，更多的bug將會由隨機測試發現，而不是自動測試。而且，一個測試員花費越多的時間進行隨機測試，發現真正的用戶bug的概率就越大。

手動測試的限制：

手動進行測試將花費大量的時間。

每次有了新的build，測試員必須從新運行測試-通過一段時間之後將會很是繁瑣和疲憊。

其餘的因素：

你將哪些部分進行自動測試也由你使用的工具決定。若是該工具備不少限制，那麼這些部分仍是手動測試吧。

是否投資的回報值得運行自動測試？是否你自動化測試的產出值得創建和支持測試用例，自動框架和運行測試用例的系統？

自動測試的標準

有兩個問題能夠用來判斷是否應該爲你的測試用例進行自動化。

Q1:是否測試場景能夠自動化？

A1:是的，而且花費不多。

A2:是的，可是花費不少。

A3:不，不可能進行自動化。

Q2:該測試場景有多麼重要？

A1:我必須在任何可能的時候都對其進行測試。

A2:我須要有規律地對該場景進行測試。

A3:我只須要測試該場景一次。

若是這兩個問題你的答案都是#1，那麼你確定須要自動化該測試。

若是這兩個問題你的答案是一個#1和一個#2，那麼你最好自動化該測試。

若是這兩個問題你的答案都是#2，那麼你應該好好考慮一下是否你值得爲自動化測試投資。

若是你沒法自動測試，會有什麼結果

 

讓咱們假設若是你有一個測試必須在任何可能的時間運行，可是卻沒法自動化它，你的選擇是：

再評估 - 是否我真的須要如此頻繁地運行它？

若是手動測試它會有多大的花費？

尋找新的測試工具。

考慮使用test hooks.

 

 

 

四款主流測試工具的測試流程

主流測試工具的測試流程

========winrunner

1　啓動時選擇要加載的插件

2　進行一些設置（如錄製模式等）

3　識別應用程序的GUI，即建立map(就是學習被測試軟件的界面）

4　創建測試腳本（錄製及編寫）

5　對腳本除錯及調試（保證可以運行完）

6　插入各類檢查點（圖片，文字，控件等）

7　在新版應用程序中執行測試腳本

8　分析結果，回報缺陷

　

=========quicktestpro========

1　準備錄製

打開你要對其進行測試的應用程序，並檢查QuickTest中的各項設置是否適合當前的要求。

2　進行錄製

打開QuickTest的錄製功能，按測試用例中的描述，操做被測試應用程序。

3　編輯測試腳本

經過加入檢測點、參數化測試，以及添加分支、循環等控制語句，來加強測試腳本的功能，使未來的迴歸測試真正可以自動化。

4　調試腳本

調試腳本，檢查腳本是否存在錯誤。

5　在迴歸測試中運行測試

在對應用程序的迴歸測試中，經過QuickTest回放對應用程序的操做，檢驗軟件正確性，實現測試的自動化進行。

6　分析結果，報告問題

查看QuickTest記錄的運行結果，記錄問題，報告測試結果。

 

＝＝＝＝TestDirect============

安裝好後，先進入站點管理

1　建立域及工程

2　添加用戶

3　編輯licenses及本服務器

4　編輯數據庫

－－TD

1　選擇新建的工程進行定製(列表，用戶，組，版本等)

2　在require中增長需求

3　把需求轉化爲plan

4 在testlab中由計劃新建測試具體用例與執行

5　發現bug，在defect中提交bug

（每一部分均可以相對獨立地使用）

 

======loadrunner

1　制定負載測試計劃

(分析應用程序， 肯定測試目標，計劃怎樣執行LoadRunner）

2　開發測試腳本

（錄製基本的用戶腳本，完善測試腳本）

3　建立運行場景

（選擇場景類型爲Manual Scenario，選擇場景類型，理解各類類型，場景的類型轉化）

4　運行測試

5　監視場景

（MEMORY 相關，PROCESSOR相關，網絡吞量以及帶寬，磁盤相關，WEB應用程序 ，IIS5.0，SQL SERVER，NETWORK DELAY等)

6　分析測試結果

(分析實時監視圖表,分析事務的響應時間,分解頁面,肯定WEBSERVER的問題,其餘有用的功能)

 

 

軟件測試面試題

2007-02-28 17:17

軟件測試的目的？

測試的目的是想以最少的人力、物力和時間找出軟件中潛在的各類錯誤和缺陷，經過修正種錯誤和缺陷提升軟件質量，迴避軟件發佈後因爲潛在的軟件缺陷和錯誤形成的隱患帶來的商業風險。

Beta 測試：在客戶場地，由客戶進行的對產品預發佈版本的測試。

軟件驗收測試合格經過準則：1軟件需求分析說明書中定義的全部功能已所有實現，性能指標所有達到要求。2全部測試項沒有殘餘的一級二級三級的錯誤。3立項審批表、需求分析文檔、設計文檔和編碼實現一致。4驗收測試工件齊全（測試計劃，測試用例，測試日誌，測試通知單，測試分析報告）

軟件驗收測試包括正式驗收測試、alpha測試、beta測試三種測試。

系統測試的策略：功能測試，性能測試，外部接口測試，界面測試，強度測試，冗餘測試，可靠性測試，恢復測試等

設計系統測試計劃須要參考的項目文檔有軟件測試計劃、軟件需求工件、和迭代計劃。

利用因果圖導出測試用例須要通過的通常步驟

1.分析程序規格說明的描述中，哪些是緣由，哪些是結果。

2.分析程序規格說明的描述中語義的內容，並將其表示成鏈接各個緣由與各個結果的因果圖

3.在因果圖上使用若干個特殊的符號標明特定的約束條件

4.把因果圖轉換成斷定表

5.把斷定表中每一列表示的狀況寫成測試用例

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

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

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

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

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

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

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

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

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

什麼是軟件測試？

使用人工或自動手段來運行或測定某個系統的過程，其目的在於檢驗它是否知足規定的需求或是弄清預期結果與實際結果之間的差異。

軟件測試就是在軟件投入運行前，對軟件需求分析、設計規格說明和編碼的最終複審，是軟件質量保證的關鍵步驟。軟件測試是爲了發現錯誤而執行程序的過程。

簡述集成測試的過程

根據IEEE標準 集成測試劃分爲4個階段：計劃階段，設計階段，實現階段，執行階段（實施階段）

計劃階段

1）時間安排        概要設計完成評審後大約一個星期

2）輸入            需求規格說明書 概要設計文檔   產品開發計劃路標

3）入口條件        概要設計文檔已經經過評審

4）活動步驟       1.定被測試對象和測試範圍 2.評估集成測試被測試對象的數量及難度，即工做量 3.肯定角色分工和做任務4.標識出測試各階段的時間，任務，約束等條件5.考慮必定的風險分析及應急計劃6.考慮和準備集成測試須要的測試工具，測試儀器，環境等資源7.考慮外部技術支援的力度和深度，以及相關培訓安排8.定義測試完成標準

5）輸出            集成測試計劃

6）出口條件        集成測試計劃經過概要設計階段基線評審

設計階段

1）時間安排 詳細設計階段開始

2）輸入   需求規格說明書   概要設計   集成測試計劃

3）入口條件   概要設計基線經過評審

4）活動步驟   1.被測對象結構分析 2.集成測試模塊分析3.集成測試接口分析4.集成測試策略分析

    5.集成測試工具分析6.集成測試環境分析7.集成測試工做量估計和安排。

5）輸出   集成測試設計（方案）

6.出口條件   集成測試設計經過詳細設計基線評審。

實現階段

1）時間安排 在編碼階段開始後進行

2）輸入 需求規格說明書   概要設計   集成測試計劃 集成測試設計

3）入口條件 詳細設計階段

4）活動步驟   集成測試用例設計 集成測試程設計 集成測試代碼設計（若是須要）   集成測試腳本（若是須要）   集成測試工具（若是須要）

5）輸出   集成測試用例 集成測試規程 集成測試代碼 集成測試腳本 集成測試工具

6）出口條件   測試用例和測試規程經過編碼階段基線評審

執行階段

1）時間安排 單元測試已經完成後就能夠開始執行集成測試了

2）輸入      需求規格說明書 概要設計   集成測試計劃   集成高度設計   集成測試例 集成測試規程   集成測試代碼（若是有）   集成測試腳本 集成測試工具 詳細設計   代碼   單元測試報告 

3）入口條件 單元測試階段已經經過基線化評審

4）活動步 驟 執行集成測試用例 迴歸集成測試用例   撰寫集成測試報告 

5）輸出   集成測試報告

6）出口條件   集成測試報告經過集成測試階段基線評審

文檔測試？

文檔審覈測試目前愈來愈引發人們的重視，軟件質量不是檢查出來的，而是融進軟件開發中來。文檔審覈測試主要包括需求文檔測試，設計文檔測試，爲前置軟件測試中的一部分。

需求文檔測試：主要測試需求中是否存在邏輯矛盾以及需求在技術上是否能夠實現；

設計文檔測試 ：測試設計是否符合所有需求以及設計是否合理。

白盒測試有哪幾種方法？

白盒測試也稱結構測試或邏輯驅動測試，它是知道產品內部工做過程，可經過測試來檢測產品內部動做是否按照規格說明書的規定正常進行，按照程序內部的結構測試程序，檢驗程序中的每條通路是否都有能按預約要求正確工做，而不顧它的功能，白盒測試的主要方法有邏輯驅動、基路測試等，主要用於軟件驗證。「白盒」法全面瞭解程序內部邏輯結構、對全部邏輯路徑進行測試。「白盒」法是窮舉路徑測試。

 

 

軟件測試面試題(軟通動力,博彥科技,奇虎,瑞星,中軟)

2007-07-27 14:34

1。軟通動力面試筆答

 

1.白箱測試和黑箱測試是什麼?什麼是迴歸測試?

白箱測試是在看懂程序代碼和設計方案的前提下，進行軟件的測試。這種測試注重於源代碼的覆蓋率，同時須要測試者具有較高的技術水平。白箱測試的優勢是能夠對代碼有詳細的審查，能找出隱藏在代碼中的錯誤，從而確保高質量的代碼；缺點是不少時候不能看完全部的代碼，不能找出欠缺的代碼，同時白箱測試和用戶如何使用軟件無關。

 

黑箱測試的優勢是測試者無需熟悉軟件內部結構，而且根據藍圖在早期就能夠制定測試方案，並不依賴於開發者的工做進展，並且黑箱測試簡單易行，對測試者的技術要求不高；可是，黑箱測試主要是功能上的測試，只能覆蓋只有一小部分的輸入，不能保證程序的全部部分都被測試到。

 

迴歸測試是指修改了舊代碼後，從新進行測試以確認修改沒有引入新的錯誤或致使其餘代碼產生錯誤。自動迴歸測試將大幅下降系統測試、維護升級等階段的成本。

 

迴歸測試包括兩部分：函數自己的測試、其餘代碼的測試。

在對被修改的函數從新測試。若是函數的設計功能沒有變化，直接運行函數測試就能夠了。若是修改了設計功能，則要根據增減的功能點，增長或刪除測試用例。另外，還要完成白盒覆蓋。

 

函數代碼的修改可能致使調用該函數的代碼產生錯誤，因此須要測試其餘代碼。若是函數是私有函數而且未涉及到全局變量，應運行類測試，不然應運行工程測試。在函數列表中選擇類測試或工程測試，編譯運行測試工程，便可執行對其餘代碼的迴歸測試。

 

2.單元測試、集成測試、系統測試的側重點是什麼？

單元測試：以代碼檢查、邏輯覆蓋

集成測試：增長靜態結構分析、靜態質量度量

系統測試：根據黑盒測試結果，採用白盒測試

 

單元測試是在軟件開發過程當中要進行的最低級別的測試活動，在單元測試活動中，軟件的獨立單元將在與程序的其餘部分相隔離的狀況下進行測試。 

集成測試，也叫組裝測試或聯合測試。在單元測試的基礎上，將全部模塊按照設計要求，組裝成爲子系統或系統，進行集成測試。實踐代表，一些模塊雖然可以單獨地工做，但並不能保證鏈接起來也能正常的工做。程序在某些局部反映不出來的問題，在全局上極可能暴露出來，影響功能的實現。 

系統測試是將通過測試的子系統裝配成一個完整系統來測試。它是檢驗系統是否確實能提供系統方案說明書中指定功能的有效方法。

 

3.設計用例的方法、依據有那些？

白盒測試用例設計有以下方法:基本路徑測試/等價類劃分/邊界值分析/覆蓋測試/循環測試/數據流測試/程序插樁測試/變異測試.這時候依據就是詳細設計說明書及其代碼結構吧,恩,這個真不肯定

 

黑盒測試用例設計方法:基於用戶需求的測試/功能圖分析方法/等價類劃分方法/邊界值分析方法/錯誤推測方法/因果圖方法/斷定表驅動分析方法/正交實驗設計方法.依據是用戶需求規格說明書,詳細設計說明書

 

4.一個測試工程師應具有那些素質和技能？

   掌握基本的測試基礎理論

本着找出軟件存在的問題的態度進行測試,即客觀吧,不要以挑刺形象出現

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

以用戶的觀點看待問題

有着強烈的質量意識

細心和責任心

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

具備以往的測試經驗

可以及時準確地判斷出高危險區在何處

①、       、溝通能力

 

　　一名理想的測試者必須可以同測試涉及到的全部人進行溝通，具備與技術（開發者）和非技術人員（客戶，管理人員）的交流能力。既要能夠和用戶談得來，又能同開發人員說得上話，不幸的是這兩類人沒有共同語言。和用戶談話的重點必須放在系統能夠正確地處理什麼和不能夠處理什麼上。而和開發者談相同的信息時，就必須將這些活從新組織以另外一種方式表達出來，測試小組的成員必須可以同等地同用戶和開發者溝通。

 

②、移情能力

 

　　和系統開發有關的全部人員都處在一種既關心又擔憂的狀態之中。用戶擔憂未來使用一個不符合本身要求的系統，開發者則擔憂因爲系統要求不正確而使他不得不從新開發整個系統，管理部門則擔憂這個系統忽然崩潰而使它的聲譽受損。測試者必須和每一類人打交道，所以須要測試小組的成員對他們每一個人都具備足夠的理解和同情，具有了這種能力能夠將測試人員與相關人員之間的衝突和對抗減小到最低程度。

 

③、技術能力

 

　　就整體言，開發人員對那些不懂技術的人持一種輕視的態度。一旦測試小組的某個成員做出了一個錯誤的判定，那麼他們的可信度就會馬上被傳揚了出去。一個測試者必須既明白被測軟件系統的概念又要會使用工程中的那些工具。要作到這一點須要有幾年以上的編程經驗，前期的開發經驗能夠幫助對軟件開發過程有較深刻的理解，從開發人員的角度正確的評價測試者，簡化自動測試工具編程的學習曲線。

 

④、自信心

 

　　開發者指責測試者出了錯是常有的事，測試者必須對本身的觀點有足夠的自信心。若是允許別人對本身指東指西，就不能完成什麼更多的事情了。

 

⑤、外交能力

 

　　當你告訴某人他出了錯時，就必須使用一些外交方法。機智老練和外交手法有助於維護與開發人員的協做關係，測試者在告訴開發者他的軟件有錯誤時，也一樣須要必定的外交手腕。若是採起的方法過於強硬，對測試者來講，在之後和開發部門的合做方面就至關於「贏了戰爭卻輸了戰役」。

 

⑥、幽默感

 

　　在遇到狡辯的狀況下，一個幽默的批評將是頗有幫助的。

 

⑦、很強的記憶力

 

　　一個理想的測試者應該有能力將之前曾經遇到過的相似的錯誤從記憶深處挖掘出來，這一能力在測試過程當中的價值是沒法衡量的。由於許多新出現的問題和咱們已經發現的問題相差無幾。

 

⑧、耐心

 

　　一些質量保證工做須要難以置信的耐心。有時你須要花費驚人的時間去分離、識別和分派一個錯誤。這個工做是那些坐不住的人沒法完成的。

 

⑨、懷疑精神

 

　　能夠預料，開發者會盡他們最大的努力將全部的錯誤解釋過去。測式者必須聽每一個人的說明，但他必須保持懷疑直到他本身看過之後。

 

⑩、自我督促

 

　　幹測試工做很容易使你變得懶散。只有那些具備自我督促能力的人才可以使本身天天正常地工做。

 

十一、洞察力

 

　　一個好的測試工程師具備「測試是爲了破壞」的觀點，捕獲用戶觀點的能力，強烈的質量追求，對細節的關注能力。應用的高風險區的判斷能力以便將有限的測試針對重點環節。

 

5.集成測試一般都有那些策略？

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

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

三、一個模塊的功能是否會對另外一個模塊的功能產生不利的影響； 

四、全局數據結構是否有問題； 

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

6.你用過的測試工具的主要功能、性能及其餘？

WinRunner (WR) 是一個基於Windows的企業級功能測試工具，它在業務應用正式部署以前，經過自動捕獲、檢測和重放用戶對應用系統的交互操做，來發現系統缺陷，確保那些跨越多個應用程序和數據庫的業務流程在初次發佈就能避免故障的出現，保證系統對全部關鍵業務處理功能、處理流程的正確，保障應用的質量和準備工做的最優化

主要功能:

1) 輕鬆建立測試：用WinRunner建立一個測試，只需在應用軟件中操做記錄下一個標準的業務流程，例以下一張訂單或創建一個新的商家帳戶，WinRunner將直觀地記錄該流程。即便技術知識有限的用戶，也能經過在GUI上單擊鼠標而生成完整的測試。用戶還能夠直接編輯測試指令來知足各類複雜測試的需求

2)插入檢查點：在創建一個測試的過程當中能夠插入檢查點，以在查找潛在錯誤的同時，將預想的結果和實際測試結果進行比較。在插入檢查點後，WinRunner會收集相應的性能指標，在測試運行時對其一一驗證。WinRunner容許使用幾種不一樣類型的檢查點，包括文本、GUI、位圖和數據庫等。例如用一個位圖檢查點，能夠確認一個位圖圖像是否出如今指定的位置上。WinRunner的數據庫檢驗功能可以自動標示出被修改的數據

3) 檢驗數據：除了建立並運行測試，WinRunner還能驗證數據庫的數值，從而確保交易的準確性。例如，在測試建立時，能夠設定哪些數據庫表格和記錄資料須要檢測。在重放時，測試程序就會覈對數據庫內的實際數值與預想的數值。WinRunner能自動顯示檢測結果，在有更新/修改、刪除或插入的記錄上會用突出標識引發注意

4) 加強測試：爲了完全全面地測試一個應用程序，用戶須要瞭解對於不一樣類型的數據它是如何運行的。WinRunner的DataDriver Wizard使用戶只需單擊幾下鼠標，就能簡單地將一個記錄下的業務流程轉化爲一個數據驅動的測試，來反映多個用戶各自獨特且真實的操做行爲

5) 運行測試：在創建測試，並插入檢查點和作一些必要的功能添加後，就能夠開始運行測試。當WinRunner執行測試時，它會自動操做應用程序，正如一個真實用戶根據記錄流程執行着每一步的操做，並且它的意外處理功能爲測試排除干擾，包括消息和警報

6) 分析結果：一旦測試運行後，就須要分析測試結果。WinRunner的互動式的報告工具經過提供詳盡的、易讀的報告，其中會列出在測試中發現的差錯和出錯的位置，來幫助用戶解釋所獲得的結果。這些報告對在測試運行中發生的重要事件進行描述，如出錯內容和檢查點等。單擊按鈕，還能進一步獲取任何未被包括在此測試範圍內的錯誤的詳盡資料。這些結果均可以經過MI的測試管理工具TestDirector來查閱

7) 維護測試：隨着時間推移，開發人員會對應用程序作進一步的修改，這時，須要增長額外的測試。WinRunner會幫助用戶建立可重複使用的測試，以大大節省時間和資源，充分利用測試投資

 

7.一個缺陷測試報告的組成

缺陷的標題，缺陷的基本信息，復現缺陷的操做步驟，缺陷的實際結果描述，指望的正確結果描述，註釋文字和截取的缺陷圖象。

• 缺陷的標題；
• 缺陷的基本信息；
• 測試的軟件和硬件環境；
• 測試的軟件版本；
• 缺陷的類型；
• 缺陷的嚴重程度；
• 缺陷的處理優先級。
• 復現缺陷的操做步驟；
• 缺陷的實際結果描述；
• 指望的正確結果描述；
• 註釋文字和截取的缺陷圖像。

 

8.基於WEB信息管理系統測試時應考慮的因素有哪些？

1、功能測試

    一、連接測試 

    二、表單測試

    三、Cookies測試

    四、設計語言測試 

    五、數據庫測試

2、性能測試

    一、鏈接速度測試 

    二、負載測試  

    三、壓力測試  

3、可用性測試

    一、導航測試  

    二、圖形測試

    三、內容測試

    四、總體界面測試

4、客戶端兼容性測試

    一、平臺測試   

    二、瀏覽器測試  

5、安全性測試

 

9.軟件本地化測試比功能測試都有哪些方面須要注意？

軟件本地化測試的目的： 

軟件本地化測試的測試策略：1.本地化軟件要在各類本地化操做系統上安裝並測試。2.源語言軟件安裝在另外一臺相同源語言操做系統上，做爲對比測試。3.重點測試因本地化引發的軟件的功能和軟件界面的錯誤。4.測試本地化軟件的翻譯質量。5.手工測試和自動測試相結合。

 

10.軟件測試項目從何時開始，？爲何？

軟件測試應該在需求分析階段就介入,由於測試的對象不只僅是程序編碼,應該對軟件開發過程當中產生的全部產品都測試,而且軟件缺陷存在放大趨勢.缺陷發現的越晚,修復它所花費的成本就越大.

 

11.需求測試注意事項有哪些？

一個良好的需求應當具備一下特色： 

完整性：每一項需求都必須將所要實現的功能描述清楚，以使開發人員得到設計和實現這些功能所需的全部必要信息。 

正確性：每一項需求都必須準確地陳述其要開發的功能。 

一致性：一致性是指與其它軟件需求或高層（系統，業務）需求不相矛盾。 

可行性：每一項需求都必須是在已知系統和環境的權能和限制範圍內能夠實施的。 

無二義性：對全部需求說明的讀者都只能有一個明確統一的解釋，因爲天然語言極易致使二義性，因此儘可能把每項需求用簡潔明瞭的用戶性的語言表達出來。 

健壯性：需求的說明中是否對可能出現的異常進行了分析，而且對這些異常進行了容錯處理。 

必要性：「必要性」能夠理解爲每項需求都是用來受權你編寫文檔的「根源」。要使每項需求都能回溯至某項客戶的輸入，如Use Case或別的來源。 

可測試性：每項需求都能經過設計測試用例或其它的驗證方法來進行測試。 

可修改性：每項需求只應在S R S 中出現一次。這樣更改時易於保持一致性。另外，使用目錄表、索引和相互參照列表方法將使軟件需求規格說明書更容易修改。 

可跟蹤性：應能在每項軟件需求與它的根源和設計元素、源代碼、測試用例之間創建起連接鏈，這種可跟蹤性要求每項需求以一種結構化的，粒度好（f i n e - g r a i n e d ）的方式編寫並單獨標明，而不是大段大段的敘述。

 

12.簡述一下缺陷的生命週期

·軟件缺陷的生命週期指的是一個軟件缺陷被發現、報告到這個缺陷被修復、驗證直至最後關閉的完整過程。

 簡單的軟件缺陷生命週期： 
 一、發現——打開：測試人員找到軟件缺陷並將軟件缺陷提交給開發人員； 
 二、打開——修復：開發人員再現、修復缺陷，而後提交測試人員去驗證； 
三、修復——關閉：測試人員驗證修復過的軟件，關閉已不存在的缺陷。 
可是這是一種理想的狀態，在實際的工做中是很難有這樣的順利的，須要考慮的各類狀況都仍是很是多的。 
複雜的軟件缺陷生命週期： 
一、新建一個軟件缺陷，這個軟件缺陷是（open）狀態，進行bug審查，不是代碼問題，就是設計須要修改； 
二、新建一個軟件缺陷，這個軟件缺陷是（open）狀態，進行bug審查，之後修改的，就能夠延期； 
三、新建一個軟件缺陷，這個軟件缺陷是（open）狀態，進行bug審查，實際沒有這個bug，能夠將其關閉； 
四、新建一個軟件缺陷，這個軟件缺陷是（open）狀態，看是否清楚可重現，若是不能重現，就是缺乏信息，須要返回到（open）狀態；若是可以重現，就進行修正，修正後關閉，進行迴歸測試。

 

13.測試分析測試用例注意（事項）？

1.爲何要寫用例：

咱們編寫測試用例，有以下的好處：

便於團隊交流：假如說一個測試團隊有10個成員，你們測試的時候都各自爲政，沒有統一的標準，測試的效率無疑會大打折扣；若是你們都遵循統一的用例規範去寫，就會解決這一問題。

便於重複測試 ：你們知道，軟件在實際開發過程當中是會有不一樣版本的，好比會從1.0升級到10.0，那麼若是不寫測試用例的話，在測試10.0版本的時候，你能徹底記得1.0版本時你作過哪些測試嗎？測試用例就像一個備忘錄同樣，便於重複測試。

便於跟蹤統計：這一點是針對測試經理或是項目經理來講的，項目負責人經過看測試用例的執行狀況，就能瞭解到項目目前的概況，好比已經執行了哪些測試，還有哪些測試沒有執行，測試沒有經過的地方主要集中在哪些模塊等。

便於用戶自測：尤爲是項目軟件，有的時候用戶但願本身測試一下軟件產品，可是用戶大都是非專業人士，他須要根據你寫好的用例來更好的檢驗產品的質量

說了這麼多編寫測試用例的優勢，那它有沒有缺點呢？有一個明顯的缺點就是須要花費大量的時間，一般編寫測試用例的時間比實際執行測試的時間還要長，這一點你們會在實際工做中有深入的體會

 

2.何時寫用例：

何時寫用例？這個問題沒有統一的標準答案，但有一點能夠確定，就是測試用例要儘早編寫。 你們認爲在哪一個階段開始寫用例比較好呢？

一般，咱們都會在測試設計階段來寫用例，即《需求規格說明書》和《測試計劃》都已完成以後

 

3.由誰來寫測試用例

有的讀者會說，固然是測試人員來寫用例了！

但是測試人員又會有不一樣的角色，通常分爲測試經理，測試設計人員，測試執行人員和測試工具開發人員等，通常測試用例是由測試設計人員來編寫，由測試執行人員來執行，這就要求測試設計人員有必定的用例設計經驗，並對被測試的系統有深刻的瞭解。

可是在不少小公司裏面，區分的不是這麼明顯，一個測試人員每每會身兼數職，既是測試組長，又是測試設計人員，又是測試執行人員。項目組裏就你一個測試工程師，你不寫用例誰寫啊！

 

4.根據什麼寫測試用例

咱們編寫測試用例的惟一標準就是用戶需求，具體的參考資料就是《系統需求規格說明書》和軟件原型，其中軟件原型指的是沒有嵌入所有源代碼的軟件界面，好比我作一個電子商務網站，爲了儘快能給用戶演示，我只是用html語言做一些靜態頁面，並無編寫動態的程序，這就是一個軟件原型，它也看做是需求的一部分。

 

 

 

二。瑞星筆試題(15道)

 

1.一臺計算機的IP是192.168.10.71子網掩碼255.255.255.64與192.168.10.201是同一局域網嗎?

你的子網掩碼不對。

不可能出現255.255.255.64的子網掩碼。

 

另外，這個題也不能說成「同一局域網」，局域網是針對物理的拓撲結構而言。

事實上，咱們研究的是否在同一子網的一些IP，每每都是同一個局域網內。

 

針對此題：

……

子網掩碼爲255.255.128.0時，是同一子網。

子網掩碼爲255.255.255.0時，是同一子網。

子網掩碼爲255.255.255.128時，不是同一子網。

子網掩碼爲255.255.255.192時，不是同一子網。

……

 

2.internet中e-mail協儀,IE的協儀,NAT是什麼,有什麼好處,能帶來什麼問題?DNS是什麼,它是如何工做的?

NAT全稱Network Address Translation，中文解釋爲「網絡地址轉換」。NAT是一種IETF（Internet Engineering Task Force）的標準，簡單描述其功能就是讓處於內網的計算機可以經過NAT的做用透明的訪問外網的互聯網資源。NAT的功能通常集成在路由器、防火牆或者單獨的NAT設備中。

 

DNS 全名是 Domain Name System, 透過 DNS 系統, 咱們能夠由一部機器的 domain name 查其 IP, 也能夠由機器的 IP 反查它的 domain name, 除此以外 DNS 還與 Mail System 結合, 提供 Mail routing 的功能.

 

DNS分爲Client和Server，Client扮演發問的角色，也就是問Server一個Domain Name，而Server必需要回答此Domain Name的真正IP地址。而當地的DNS先會查本身的資料庫。若是本身的資料庫沒有，則會往該DNS上所設的的DNS詢問，依此獲得答案以後，將收到的答案存起來，並回答客戶。

 

3.PROXY是如何工做的?

Proxy是什麼呢，是代理。普通的因特網訪問是一個典型的客戶機與服務器結構：用戶利用計算機上的客戶端程序，如瀏覽器發出請求，遠端WWW服務器程序響應請求並提供相應的數據。而Proxy處於客戶機與服務器之間，對於服務器來講，Proxy是客戶機，Proxy提出請求，服務器響應；對於客戶機來講，Proxy是服務器，它接受客戶機的請求，並將服務器上傳來的數據轉給客戶機。它的做用很象現實生活中的代理服務商。所以Proxy Server的中文名稱就是代理服務器。

 

Proxy Server的工做原理是：當客戶在瀏覽器中設置好Proxy Server後，你使用瀏覽器訪問全部WWW站點的請求都不會直接發給目的主機，而是先發給代理服務器，代理服務器接受了客戶的請求之後，由代理服務器向目的主機發出請求，並接受目的主機的數據，存於代理服務器的硬盤中，而後再由代理服務器將客戶要求的數據發給客戶。

 

4.win2k系統內AT命令完成什麼功能,Messenger服務是作什麼,怎麼使用?

AT命令可在指定時間和日期、在指定計算機上運行命令和程序。

Messenger服務:發送和接收系統管理員或者「警報器」服務傳遞的消息。

 

5進程,線程的定義及區別

進程是具備必定獨立功能的程序關於某個數據集合上的一次運行活動,進程是系統進行資源分配和調度的一個獨立單位.

 

線程是進程的一個實體,是CPU調度和分派的基本單位,它是比進程更小的能獨立運行的基本單位.線程本身基本上不擁有系統資源,只擁有一點在運行中必不可少的資源(如程序計數器,一組寄存器和棧),可是它可與同屬一個進程的其餘的線程共享進程所擁有的所有資源.

 

一個線程能夠建立和撤銷另外一個線程;同一個進程中的多個線程之間能夠併發執行

 

6,32位操做系統內,1進程地址空間多大,進程空間與物理內存有什麼關係?

 

7網絡攻擊經常使用的手段,防火牆如何保證安全.

8如何配靜態IP,如何測網絡內2臺計算機通不通,PING一次返幾個數據包?

9WIN9X與WINNT以上操做系統有"服務"嗎,服務是什麼,如何中止服務?

10AD在WIN2KSERVER上建需什麼文件格式,AD是什麼?XP多用戶下"註銷"與"切換"的區別.

11UDP能夠跨網段發送嗎?

12最簡單的確認遠程計算機(win2K以上)某個監聽端口是正常創建的?

13軟件測試的定義,測試工做是枯燥反覆的,你是如何理解的?黑盒,白盒,迴歸,壓力測試的定義.

14winrunner,loadrunner是什麼,區別

15磁盤分區如何分類,請舉例說明安裝操做系統的注意事項.

(1小時答題)

 

 

三。中軟的面試題

 

 

一.     簡答題.

1.     避免死鎖的方法有哪些?

產生死鎖的四個必要條件：

（1） 互斥條件：一個資源每次只能被一個進程使用。

（2） 請求與保持條件：一個進程因請求資源而阻塞時，對已得到的資源保持不放。

（3） 不剝奪條件:進程已得到的資源，在末使用完以前，不能強行剝奪。

（4） 循環等待條件:若干進程之間造成一種頭尾相接的循環等待資源關係。

這四個條件是死鎖的必要條件，只要系統發生死鎖，這些條件必然成立，而只要上述條件之

一不知足，就不會發生死鎖。

2.     在Sybase數據庫中註冊用戶與數據庫用戶有什麼區別?

3.     在MS SQL_Server 數據庫中經過什麼約束保證數據庫的實體完整性

能夠經過創建惟一的索引、PRIMARY KEY約束、UNIQUE約束或IDENTITY約束來實現實體完整性

 

4.     內存有哪幾種存儲組織結構.請分別加以說明

5.     JAVA中的Wait() 和notify()方法使用時應注意些什麼?

6.     用戶輸入一個整數.系統判斷,並輸出是負數仍是非負數,請設計測試用例.

7.     操做系統中的同步和互訴解決了什麼問題

8.     UNIX 中init

二.     編寫類String 的構造函數,析構函數和賦值函數

已知類String 的原型爲

class string

{

public:

string(const char *str=null);//普通構造函數

string(const string &other);//拷貝構造函數

---string(void);

string &operate=(const string &other);//賦值函數

private:

char * m-data;//用於保存字符串

};

請編寫string 的上述4個函數

三.     有關內存的思考題

1.     void getmemory(char *p)

{ p=(char*)mallol(100);

}

void test(void)

{

char * str =null;

getmemory(str);

strcpy(str,」hello,world」);

printf(str);

}

請問運行Test函數會有什麼樣的結果

2.     char*getmemory(void)

{ char p[]=」hello world」;

return p;

}

void test(void)

{

char *str=null;

str=Getmemory();

printf(str);

} 請問運行Test 函數會有什麼樣的結果.

 

三。奇虎面試題

 

 

 

前三道程序題

（下面的題不排序，有筆試題，也有面試題）

四、怎麼劃分缺陷的等級？

五、怎麼評價軟件工程師？

六、軟件工程師的素質是什麼？

七、怎麼看待軟件測試？

八、軟件測試是一個什麼樣的行業？

九、圖書（圖書號，圖書名，做者編號，出版社，出版日期）

   做者（做者姓名，做者編號，年齡，性別）

   用SQL語句查詢年齡小於平均年齡的做者姓名、圖書名，出版社。

十、你的職業生涯規劃

十一、測一個三角形是普通三角形、等腰三角形、等邊三角形的流程圖，測試用例。

十二、寫出你經常使用的測試工具。

1三、lordrunner分哪三部分？

1四、但願之後的軟件測試是怎麼樣的一個行業？

1五、.軟件測試項目從何時開始？

   我答：從軟件項目的須要分析開始。

     問：爲何從需求分析開始？有什麼做用？

 

四。北京博彥科技筆試＋面試

 

 

 

筆試題

 

1．文件格式系統有哪幾種類型？分別說說win9五、win9八、winMe、w2k、winNT、winXP分別支持那些文件系統。

   FAT(File Allocation Table)是「文件分配表」的意思。

對咱們來講，它的意義在於對硬盤分區的管理。FAT1六、FAT3二、NTFS是目前最多見的三種文件系統。

   Win95: FAT16和FAT32

   Win98: FAT16,FAT32

   winMe:FAT16,FAT32

   w2k: FAT(FAT16),FAT32,NTFS

   winNT: FAT16/FAT32/NTFS

   winXP:FAT16,FAT32,NTFS

 

2．分別填入一個語句，完成下面的函數，經過遞歸計算數組a[100]的前n個數之和。

Int sum ( int a[],int n )

{

   if (n>0) return_____ sum(a[], n--) + a[n] _____;

   else return_____ a[n]____; // 其實就是a[0]

}

//一直遞歸到0，而後逐級返回，實現累加

 

3．寫出你所知道的3種經常使用的排序方法，並用其中一種方法設計出程序爲數組a[100]排序。

經常使用的排序算法有不少：

冒泡，快速排序，直接插入，希爾排序，選擇排序，堆排序，歸併排序！

就舉冒泡排序(c++)：

void bubblesort()

{

    for (i = 1; i < max; i ++)

    {

       for (j = max - 1; j >= i; j --)

       if (a[j + 1] < a[j]) //小則交換

       {

          a[0] = a[j + 1];

          a[j + 1] = a[j];

          a[j] = a[0];

      }

    }

}

 

4．什麼是兼容性測試？兼容性測試側重哪些方面，請按照優先級用矩陣圖表列出。

   （這題的第二問我不會答，因此原題目記得不是很清楚，你們能看明白問什麼就好）

兼容性是指協調性，

1．硬件上就是說你的電腦的各個部件，CPU，顯卡等等組裝到一塊兒之後的狀況，會不會相互有影響，不能很好的運做．

2．軟件上就是說你的電腦的軟件之間可否很好的運作，會不會有影響啊？還有軟件和硬件之間可否發揮很好的效率工做，會不會影響致使系統的崩潰．

一、 平臺測試

市場上有不少不一樣的操做系統類型，最多見的有Windows、Unix、Macintosh、Linux等。Web應用系統的最終用戶究竟使用哪種操做系統，取決於用戶系統的配置。這樣，就可能會發生兼容性問題，同一個應用可能在某些操做系統下能正常運行，但在另外的操做系統下可能會運行失敗。

 

所以，在Web系統發佈以前，須要在各類操做系統下對Web系統進行兼容性測試。

 

二、瀏覽器測試

 

瀏覽器是Web客戶端最核心的構件，來自不一樣廠商的瀏覽器對Java，、JavaScript、 ActiveX、 plug-ins或不一樣的HTML規格有不一樣的支持。例如，ActiveX是Microsoft的產品，是爲Internet Explorer而設計的，JavaScript是Netscape的產品，Java是Sun的產品等等。另外，框架和層次結構風格在不一樣的瀏覽器中也有不一樣的顯示，甚至根本不顯示。不一樣的瀏覽器對安全性和Java的設置也不同。

 

測試瀏覽器兼容性的一個方法是建立一個兼容性矩陣。在這個矩陣中，測試不一樣廠商、不一樣版本的瀏覽器對某些構件和設置的適應性。

 

5．我如今有個程序，發如今WIN98上運行得很慢，怎麼判別是程序存在問題仍是軟硬件系統存在問題？

多是病毒或者惡意程序啊,若是是程序運行慢那確定是軟件問題,

硬件問題主要表如今點不亮機子和報警.

解決方法,安裝殺毒軟件和優化軟件.

 

6．翻譯，中——英，有關P2P點對點文件傳輸的原理。

7．翻譯，英——中，有關互聯網的發展對商務、學習、交流的影響。

 

筆試完了是初步的面試

先問了個問題：FAT16/FAT32/NTFS 哪一個的安全性最好，爲何？（不會答）

NTFS文件系統是一個基於安全性的文件系統，是Windows NT所採用的獨特的文件系統結構，它是創建在保護文件和目錄數據基礎上，同時照顧節省存儲資源、減小磁盤佔用量的一種先進的文件系統。使用很是普遍的Windows NT 4.0採用的就是NTFS 4.0文件系統，相信它所帶來的強大的系統安全性必定給廣大用戶留下了深入的印象。Win 2000採用了更新版本的NTFS文件系統——NTFS 5.0，它的推出使得用戶不但能夠像Win 9X那樣方便快捷地操做和管理計算機，同時也可享受到NTFS所帶來的系統安全性。

 

又作了兩道題，

一題是關於C++類的繼承，看程序寫出輸出結果，A是虛類，B繼承A，跟通常C++的書上的習題差很少。

一題是寫出在32位機器下，計算幾個變量的size，

 

最後用英文介紹一下本身

 

 

黑盒測試的測試用例設計方法

 

目前黑盒測試的測試用例設計方法有5種：

1.    等價類劃分

2.    邊界值分析

3.    錯誤推測法

4.    因果圖

5.    功能圖

1、等價類劃分

等價列劃分設計方法是把全部可能的輸入數據，即程序的輸入域劃分紅若干部分（子集），而後從每個子集中選取少許具備表明性的數據做爲測試用例。

等價類是指某個輸入域的子集合。在該子集合中，各個輸入數據對於揭露程序中的錯誤都是等效的。併合理地假定：測試某等價類的表明值就等於對這一類其餘值的測試。

等價類劃分有兩種不一樣的狀況：有效等價類和無效等價類。設計時要同時考慮這兩種等價類。

下面給出6條肯定等價類的原則：

1.    在輸入條件規定了取值範圍或值的個數的狀況下，則能夠確立一個有效等價類和兩個無效等價類。

2.    在輸入條件規定了輸入值的集合或者規定了「必須如何」的條件的狀況下，則能夠確立一個有效等價類和一個無效等價類。

3.    在輸入條件是一個布爾量的狀況下，能夠確立一個有效等價類和一個無效等價類。

4.    在規定了輸入數據的一組值（假定n個），而且程序要對每個輸入值分別處理的狀況下，能夠確立n個有效等價類和一個無效等價類。

5.    在規定了輸入數據必須遵照的規則的狀況下，能夠確立一個有效等價類（符合規則）和若干個無效等價類（從不一樣角度違反規則）。

6.    在確知已劃分的等價類中各元素在程序處理中的方式不一樣的狀況下，則應再將該等價類進一步的劃分爲更小的等價類。

在確立了等價類後，可創建等價類表，列出全部劃分出的等價類。而後從劃分出的

等價類中按如下的3個原則設計測試用例：

?      爲每個等價類規定一個惟一的編號

?      設計一個新的測試用例，使其儘量多的覆蓋還沒有被覆蓋的有效等價類，重複這一步，直到全部的有效等價類都被覆蓋爲止。

?      設計一個新的測試用例，使其僅覆蓋一個還沒有被覆蓋的無效等價類，重複這一步，直到全部的無效等價類都被覆蓋爲止。

例：程序規定；輸入三個整數做爲三邊的邊長構成三角形。當此三角形爲通常三角形、等腰三角形、等邊三角形時，分別做計算。用等價類劃分方法爲該程序進行測試用例設計。

解：設a、b、c表明三角形的三條邊。

1）分析題目中給出的和隱含的對輸入條件的要求：

a) 整數

b) 3個數

c) 非零數

d) 正數

e) 兩邊之和大於第三邊

f) 等腰

g) 等邊

2）列出等價類表並編號

 

 

3）列出覆蓋上述等價類的測試用例，以下表：

 

2、邊界值分析法

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

基於邊界值分析方法選擇測試用例的原則：

1.    若是輸入條件規定了值的範圍，應取剛達到這個範圍的邊界值，以及剛剛超過這個範圍邊界的值做爲測試輸入的數據。

2.    若是輸入條件規定了值的個數，應用最大個數、最小個數、比最小個數少1、比最大個數多一的數做爲測試輸入的數據。

3.    根據規格說明的每一個輸出條件，使用前面的原則1。

4.    根據規格說明的每一個輸出條件，使用前面的原則2。

5.    若是程序的規格說明給出的輸入域或輸出域是有序集合，則應選取集合的第一個元素和最後一個元素做爲測試用例數據。

6.    若是程序中使用了一個內部數據結構，應當選擇這個內部數據結構邊界上的值做爲測試用例。

7.    分析規格說明，找出其餘可能的邊界條件。

3、錯誤推測法

錯誤推測法就是根據經驗和直覺推測程序中全部可能存在的各類錯誤，從而有針對性地設計測試用例的方法。

基本思路：列舉出程序中全部可能有的錯誤和容易發生錯誤的特殊狀況，根據他們選擇測試用例。例如：輸入數據和輸出數據爲0的狀況。

例：現有一個學生標準化考試批閱試卷，產生成績報告的程序。其規格說明以下：程序的輸入文件由一些有80個字符的記錄組成，全部記錄分爲3組，如圖：

 

 

一、標題：改組只有一個記錄，其內容是成績報告的名字。

二、各題的標準答案：每一個記錄均在第80個字符處標以數字2。該組的記錄：

第一個記錄：第1~3個字符爲試題數（1~999）。第10~59個字符是1~50題的標準答案（每一個合法字符表示一個答案）。

第二個記錄：是第51~100題的標準答案。

…….

三、學生的答案：每一個記錄均在第80個字符處標以數字3。每一個學生的答卷在若干個記錄中給出。

學號：1~9個字符

1~50題的答案：10~59。當大於50題時，在第2、3、……個記錄中給出。

學生人數不超過200，試題數不超過999。

程序的輸出有4個報告：

a)按學號排列的成績單，列出每一個學生的成績、名次。

b)按學生成績排序的成績單。

c)平均分數及標準誤差的報告

d)試題分析報告。按試題號排序，列出各題學生答對的百分比。

解答一：採用邊界值分析方法，分析和設計測試用例。分別考慮輸入條件和輸出條件，以及邊界條件。下表列出了輸入條件及相應的測試用例。

 

下表爲輸出條件及相應的測試用例表。

 

 

解答二：採用錯誤推測法還可補充設計一些測試用例：

1.    程序是否把空格做爲回答

2.    在回答記錄中混有標準答案記錄

3.    除了標題記錄外，還有一些的記錄最後一個字符即不是2也不是3

4.    有兩個學生的學號相同

5.    試題數是負數。

4、 因果圖法

因果圖法是一種適合於描述對於多種條件的組合、相應產生多個動做的形式的測試用例設計方法。

利用因果圖生成測試用例的基本步驟：

1.    分析軟件規格說明描述中那些是緣由，那些是結果，並給每一個緣由和結果賦予一個標識符。

2.    分析軟件規格說明描述的語義。找出緣由和結果之間、緣由和緣由之間的關係，根據這些關係，畫出因果圖。

3.    在因果圖上用一些記號代表約束或限制條件。

4.    把因果圖轉換爲斷定表。

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

例：第一列字符必須是A或B，第二列字符必須是一個數字，在此狀況下進行文件的修改，但若是第一列字符不正確，則給出信息L；若是第二列字符不是數字，則給出信息M。

解一、畫出因果關係表和因果圖。

 

二、根據因果圖創建斷定表。

按條件的各類組合狀況產生對應的動做。緣由1和緣由2不能同時成立，故可排除這種狀況。

從斷定表可設計出測試用例：6個測試用例是所需的數據。