【導(dǎo)讀】Q1：請你分別劃劃OSI的七層網(wǎng)絡(luò)結(jié)構(gòu)圖，和TCP/IP的五層結(jié)構(gòu)圖？5應(yīng)用層;4運(yùn)輸層;3網(wǎng)絡(luò)層;2鏈路層;1物理層。TCP/IP協(xié)議組之所以流行，部分原因是因?yàn)樗梢杂迷诟鞣N各樣的信道和底層協(xié)議之上。確切地說，TCP/IP協(xié)議是一組包括TCP協(xié)議和IP協(xié)議，UDP協(xié)議、ICMP協(xié)議和其他一些協(xié)議的協(xié)議組。TCP/IP協(xié)議并不完全符合OSI的七層參考模型。傳統(tǒng)的開放式系統(tǒng)互連參考模型，是一種通信協(xié)議的7層抽象的參考模型,其中每一層執(zhí)行某一特定任務(wù)。該模型的目的是使各種硬件在相同的層次上相互通信。一般意義上說交換機(jī)是工作在數(shù)據(jù)鏈路層。主要是選址和路由。在C++中,結(jié)構(gòu)是特殊的類?！truct保證成員按照聲明順序在內(nèi)存中存儲。表示指令中操作數(shù)所在的方法稱為尋址方式?！　?.錯(cuò)誤推測法：基于經(jīng)驗(yàn)和直覺推測程序中所有可能存在的各種錯(cuò)誤,從而有針對性的設(shè)計(jì)測試用例的方法.

　　

【正文】 黑盒測試：已知產(chǎn)品的功能設(shè)計(jì)規(guī)格，可以進(jìn)行測試證明每個(gè)實(shí)現(xiàn)了的功能是否符合要求。 白盒測試：已知產(chǎn)品的內(nèi)部工作過程，可以通過測試證明每種內(nèi)部操作是否符合設(shè)計(jì)規(guī) 格要求，所有內(nèi)部成分是否以經(jīng)過檢查。 軟件的黑盒測試意味著測試要在軟件的接口處進(jìn)行。這種方法是把測試對象看做一個(gè)黑 盒子，測試人員完全不考慮程序內(nèi)部的邏輯結(jié)構(gòu)和內(nèi)部特性，只依據(jù)程序的需求規(guī)格說明書， 檢查程序的功能是否符合它的功能說明。因此黑盒測試又叫功能測試或數(shù)據(jù)驅(qū)動測試。黑盒 測試主要是為了發(fā)現(xiàn)以下幾類錯(cuò)誤： 是否有不正確或遺漏的功能？ 在接口上，輸入是否能正確的接受？能否輸出正確的結(jié)果？ 是否有數(shù)據(jù)結(jié)構(gòu)錯(cuò)誤或外部信息（例如數(shù)據(jù)文件）訪問錯(cuò)誤？ 性能上是否能夠滿足要求？ 是否有初始化或終止性錯(cuò)誤？ 軟件的白盒測試是對軟件的過程性細(xì)節(jié)做細(xì)致的檢查。這種方法是把測試對象看做一個(gè) 打開的盒子，它允許測試人員利用程序內(nèi)部的邏輯結(jié)構(gòu)及有關(guān)信息，設(shè)計(jì)或選擇測試用例， 對程序所有邏輯路徑進(jìn)行測試。通過在不同點(diǎn)檢查程序狀態(tài)，確定實(shí)際狀態(tài)是否與預(yù)期的狀 態(tài)一致。因此白盒測試又稱為結(jié)構(gòu)測試或邏輯驅(qū)動測試。白盒測試主要是想對程序模塊進(jìn)行 如下檢查： 對程序模塊的所有獨(dú)立的執(zhí)行路徑至少測試一遍。 對所有的邏輯判定，取“真”與取“假”的兩種情況都能至少測一遍。 在循環(huán)的邊界和運(yùn)行的界限內(nèi)執(zhí)行循環(huán)體。 測試內(nèi)部數(shù)據(jù)結(jié)構(gòu)的有效性，等等。 單元測試（模塊測試）是開發(fā)者編寫的一小段代碼，用于檢驗(yàn)被測代碼的一個(gè)很小的、 很明確的功能是否正確。通常而言，一個(gè)單元測試是用于判斷某個(gè)特定條件（或者場景）下 某個(gè)特定函數(shù)的行為。 單元測試是由程序員自己來完成，最終受益的也是程序員自己。可以這么說，程序員有 責(zé)任編寫功能代碼，同時(shí)也就有責(zé)任為自己的代碼編寫單元測試。執(zhí)行單元測試，就是為了 證明這段代碼的行為和我們期望的一致。 集成測試（也叫組裝測試，聯(lián)合測試）是單元測試的邏輯擴(kuò)展。它的最簡單的形式是： 兩個(gè)已經(jīng)測試過的單元組合成一個(gè)組件，并且測試它們之間的接口。從這一層意義上講，組 件是指多個(gè)單元的集成聚合。在現(xiàn)實(shí)方案中，許多單元組合成組件，而這些組件又聚合成程 序的更大部分。方法是測試片段的組合，并最終擴(kuò)展進(jìn)程，將您的模塊與其他組的模塊一起 測試。最后，將構(gòu)成進(jìn)程的所有模塊一起測試。 系統(tǒng)測試是將經(jīng)過測試的子系統(tǒng)裝配成一個(gè)完整系統(tǒng)來測試。它是檢驗(yàn)系統(tǒng)是否確實(shí)能 提供系統(tǒng)方案說明書中指定功能的有效方法。（常見的聯(lián)調(diào)測試） 系統(tǒng)測試的目的是對最終軟件系統(tǒng)進(jìn)行全面的測試，確保最終軟件系統(tǒng)滿足產(chǎn)品需求并 且遵循系統(tǒng)設(shè)計(jì)。 驗(yàn)收測試是部署軟件之前的最后一個(gè)測試操作。驗(yàn)收測試的目的是確保軟件準(zhǔn)備就緒， 并且可以讓最終用戶將其用于執(zhí)行軟件的既定功能和任務(wù)。 驗(yàn)收測試是向未來的用戶表明系統(tǒng)能夠像預(yù)定要求那樣工作。經(jīng)集成測試后，已經(jīng)按照設(shè)計(jì) 把所有的模塊組裝成一個(gè)完整的軟件系統(tǒng)，接口錯(cuò)誤也已經(jīng)基本排除了，接著就應(yīng)該進(jìn)一步 驗(yàn)證軟件的有效性，這就是驗(yàn)收測試的任務(wù)，即軟件的功能和性能如同用戶所合理期待的那 樣。 07. 您認(rèn)為做好測試計(jì)劃工作的關(guān)鍵是什么？ 1. 明確測試的目標(biāo)，增強(qiáng)測試計(jì)劃的實(shí)用性 編寫軟件測試計(jì)劃得重要目的就是使測試過程能夠發(fā)現(xiàn)更多的軟件缺陷，因此軟件測試 計(jì)劃的價(jià)值取決于它對幫助管理測試項(xiàng)目，并且找出軟件潛在的缺陷。因此，軟件測試計(jì)劃 中的測試范圍必須高度覆蓋功能需求，測試方法必須切實(shí)可行，測試工具并且具有較高的實(shí) 用性，便于使用，生成的測試結(jié)果直觀、準(zhǔn)確 2．堅(jiān)持“5W”規(guī)則，明確內(nèi)容與過程 “5W”規(guī)則指的是“What （做什么）”、“Why （為什么做）”、“When （何時(shí)做）”、“Where （在哪里）”、“How （如何做）”。利用“5W”規(guī)則創(chuàng)建軟件測試計(jì)劃，可以幫助測試團(tuán)隊(duì)理 解測試的目的（Why ），明確測試的范圍和內(nèi)容（What ），確定測試的開始和結(jié)束日期（When ）， 指出測試的方法和工具（How ），給出測試文檔和軟件的存放位置（Where ）。 3．采用評審和更新機(jī)制，保證測試計(jì)劃滿足實(shí)際需求 測試計(jì)劃寫作完成后，如果沒有經(jīng)過評審，直接發(fā)送給測試團(tuán)隊(duì)，測試計(jì)劃內(nèi)容的可能不準(zhǔn) 確或遺漏測試內(nèi)容，或者軟件需求變更引起測試范圍的增減，而測試計(jì)劃的內(nèi)容沒有及時(shí)更 新，誤導(dǎo)測試執(zhí)行人員。 4. 分別創(chuàng)建測試計(jì)劃與測試詳細(xì)規(guī)格、測試用例 應(yīng)把詳細(xì)的測試技術(shù)指標(biāo)包含到獨(dú)立創(chuàng)建的測試詳細(xì)規(guī)格文檔，把用于指導(dǎo)測試小組執(zhí) 行測試過程的測試用例放到獨(dú)立創(chuàng)建的測試用例文檔或測試用例管理數(shù)據(jù)庫中。測試計(jì)劃和 測試詳細(xì)規(guī)格、測試用例之間是戰(zhàn)略和戰(zhàn)術(shù)的關(guān)系，測試計(jì)劃主要從宏觀上規(guī)劃測試活動的 范圍、方法和資源配置，而測試詳細(xì)規(guī)格、測試用例是完成測試任務(wù)的具體戰(zhàn)術(shù)。 11. 您以往是否曾經(jīng)從事過性能測試工作？如果有，12. 請盡可能的詳細(xì)描述您以往的性能 測試工作的完整過程。 性能測試類型包括負(fù)載測試，強(qiáng)度測試，容量測試等 負(fù)載測試：負(fù)載測試是一種性能測試指數(shù)據(jù)在超負(fù)荷環(huán)境中運(yùn)行，程序是否能夠承擔(dān)。 強(qiáng)度測試： 強(qiáng)度測試是一種性能測試，在系統(tǒng)資源特別低的情況下軟件系統(tǒng)運(yùn)行情況 容量測試：確定系統(tǒng)可處理同時(shí)在線的最大用戶數(shù) 在網(wǎng)站流量逐漸加大的情況下，開始考慮做性能測試了，首先要寫好性能測試計(jì)劃，根 據(jù)運(yùn)營數(shù)據(jù)得出流量最大的頁面（如果是第一次的話，一般是首頁，下載頁，個(gè)人帳戶頁流 量最大，而且以某種百分比）， Web服務(wù)器指標(biāo)指標(biāo)： * Avg Rps: 平均每秒鐘響應(yīng)次數(shù)＝總請求時(shí)間/秒數(shù)； * Successful Rounds：成功的請求； * Failed Rounds ：失敗的請求； * Successful Hits ：成功的點(diǎn)擊次數(shù)； * Failed Hits ：失敗的點(diǎn)擊次數(shù)； * Hits Per Second ：每秒點(diǎn)擊次數(shù)； * Successful Hits Per Second ：每秒成功的點(diǎn)擊次數(shù)； * Failed Hits Per Second ：每秒失敗的點(diǎn)擊次數(shù)； * Attempted Connections ：嘗試鏈接數(shù)； 你認(rèn)為公司的BUG測試流程是什么？　　1）當(dāng)測試工程師發(fā)現(xiàn)了一個(gè)bug而且在bug tracking tool里面沒有相同的bug, 他需要填寫所有需要的bug信息并且把這個(gè)bug分配給test leader　　2）如果這個(gè)bug不是一個(gè)真正的bug, test leader需要close這個(gè)bug　　3）test leader需要審查bug的各種信息都完備，如果有信息不完整，他需要把狀態(tài)改成”feedback” 并重新assign給提交者　　4）如果這個(gè)bug是一個(gè)真正存在的bug, test leader需要把這個(gè)bug分配給相關(guān)的開發(fā)團(tuán)隊(duì)的PM, 并且把bug狀態(tài)改成Assigned　　5）如果這個(gè)bug屬于另外一個(gè)開發(fā)團(tuán)隊(duì)，PM需要把這個(gè)bug重新分配給那個(gè)開發(fā)團(tuán)隊(duì)的PM　　6）PM審查bug,并且分配給相應(yīng)的開發(fā)人員去改正?！　?）開發(fā)人員收到bug以后，對相關(guān)的缺陷進(jìn)行改正，并且重新分配給提交bug的測試人員并且把狀態(tài)改成”Fixed”　　8）測試人員需要對這個(gè)bug進(jìn)行重新測試，保證相關(guān)的缺陷已經(jīng)改正，測試人員可以reopen這個(gè)bug如果缺陷依然存在并且重新分配給相關(guān)的開發(fā)人員或者close這個(gè)bug如果缺陷已經(jīng)改正。準(zhǔn)備知識：1. 編程基礎(chǔ)，我不知道有多少做測試的朋友討厭編程或者做軟件開發(fā)，我個(gè)人是比較討厭的，雖然學(xué)校里學(xué)的是計(jì)算機(jī)，但是到畢業(yè)也沒正兒八經(jīng)地寫過超過百行的代碼，但沒寫過不代表讀不懂。所以選擇填空還是可以應(yīng)付的。對于可能的編程題，我是準(zhǔn)備了一些如冒泡，折半算法、strcpy/strcmp/strlen 原函數(shù)等。編程的能力是需要積累的過程，所以貴在平時(shí)。對于編程能力是否有助與測試這個(gè)論壇上討論過的問題，我的觀點(diǎn)是第一至少你找工作時(shí)用的著，第二如果做性能測試應(yīng)該也需要，第三如果有2年以上的測試經(jīng)歷應(yīng)該也會覺得非常有必要。本人也正硬著頭皮再學(xué)c，雖然學(xué)了忘忘了學(xué)?！　?，建議準(zhǔn)備好sql語言，裝個(gè)mysql自己通過敲命令，能掌握高級查詢使用基本可以應(yīng)對了。　　，這個(gè)大家都不陌生，也是必考的了，應(yīng)該可以輕松應(yīng)付。要注意準(zhǔn)備下web測試和性能測試這塊，現(xiàn)在做web的公司好多?！　?，CMMI的基礎(chǔ)知識，TCP/IP的基礎(chǔ)知識，通信的如3G網(wǎng)絡(luò)類知識等。數(shù)據(jù)庫，linux，C編程 14