OSI7層模型
TCP/IP五層模型
OSI7層模型的特點
下層為上層提供服務
同層次之間使用相同的協(xié)議
應用層有哪些協(xié)議虚缎？
http捧请、https
傳輸層有哪些協(xié)議？
TCP尉共、UDP
TCP與UDP的區(qū)別與聯(lián)系
面向連接的服務(TCP)
1晨逝、先建立連接再傳輸數(shù)據(jù)
2、數(shù)據(jù)傳輸過程中捷绒，數(shù)據(jù)包不需要攜帶目的地址
3瑰排、保證數(shù)據(jù)傳輸?shù)目煽啃?/p>
無連接的服務(UDP)
1、不需要事先建立連接暖侨，直接發(fā)送數(shù)據(jù)
2椭住、每個報文都帶有完整的目的地址
3、不保證報文傳輸?shù)目煽啃?/p>
TCP如何建立連接
通過三次握手建立連接
1字逗、A? 發(fā)送連接請求 B
2京郑、B 回復確認連接 A
3、A 收到回復后葫掉，建立連接 B
啟動/關閉/ tomcat服務
'''cd 到tomcat目錄下的bin目錄'''./startup.sh#啟動tomcat服務./shutdown.sh#關閉tomcat服務'''使用catalina.sh同樣也可以啟動或者關閉tomcat服務''''''cd 到tomcat目錄下的bin目錄'''./catalina.sh stop#關閉tomcat服務./catalina.sh start#啟動tomcat服務
bin用來存放tomcat的命令的地方
webapps用來存放軟件包的目錄
啟動/關閉/重啟 http服務
service httpd start
service httpd stop
service httpd restart
啟動/關閉/重啟 mysql服務
service mysqld start
service mysqld stop
service mysqld restart
B/S架構和C/S架構
B/S架構需要重點考慮系統(tǒng)在不同的瀏覽器中的兼容性問題(瀏覽器的內核不同)
C/S 架構需要考慮系統(tǒng)在不同平臺的安裝些举、卸載、升級
HTTP協(xié)議
HTTP協(xié)議,超文本傳輸協(xié)議,應用層協(xié)議挖息，由請求和響應構成
常見的請求方式（get金拒，post）
post請求與get請求的區(qū)別
get請求，發(fā)送的數(shù)據(jù)跟隨網(wǎng)址(URL),一起傳輸套腹。
post請求绪抛，發(fā)送的數(shù)據(jù)，在請求體里單獨傳輸电禀。
Cookie和Session的區(qū)別與聯(lián)系
1幢码、cookie數(shù)據(jù)存放在客戶的瀏覽器上，session數(shù)據(jù)放在服務器上尖飞。
2症副、cookie不是很安全店雅，別人可以分析存放在本地的COOKIE并進行COOKIE欺騙考慮到安全應當使用session。
3贞铣、session會在一定時間內保存在服務器上闹啦，當訪問增多，會比較占用你服務器的資源辕坝。
HTTP狀態(tài)碼
狀態(tài)碼? ? ? ?含義
200? ? ? ? ? ? ?ok
301? ? ? ? ? ? 永久移動
302? ? ? ? ? ? 臨時移動
404? ? ? ? ? ? 找不到資源
500? ? ? ? ? ?服務器內部錯誤
常見默認端口
軟件? ? ? ? ? ? ?默認端口
oracle? ? ? ? ? ?1521
mysql? ? ? ? ? 3306
http? ? ? ? ? ? ? ?80
https? ? ? ? ? ? 443
tomcat? ? ? ? ?8080
ssh? ? ? ? ? ? ? ?22
ftp? ? ? ? ? ? ? ? ?21
瀑布模型
V模型
軟件測試流程/生命周期
測試需求分析
測試需求評審
編寫測試計劃
設計測試用例
測試用例評審
搭建測試環(huán)境
測試執(zhí)行
回歸測試
測試報告
軟件測試的定義
在規(guī)定的條件下對程序進行操作窍奋，以發(fā)現(xiàn)程序的錯誤，并對軟件質量進行評估酱畅。
測試的目的
不僅僅是為了發(fā)現(xiàn)軟件缺陷與錯誤琳袄，而且也是對軟件質量進行度量和評估，以提高軟件的質量纺酸。
軟件測試原則
所有的軟件測試都應追溯到用戶需求窖逗。
應當盡早地和不斷地進行軟件測試。
完全測試是不可能的餐蔬，測試需要終止碎紊。
充分注意測試中的群集現(xiàn)象。
程序員應避免檢查自己的程序用含。
盡量避免測試的隨意性
軟件測試風險
進度風險矮慕、質量風險、人員風險啄骇、需求變更痴鳄、成本風險等
按階段劃分
單元測試
集成測試
系統(tǒng)測試
驗收測試
單元測試關注點
對軟件中的最小可測試單元進行檢查和驗證
集成測試關注點
在把各個模塊連接起來時，穿越模塊接口的數(shù)據(jù)是否會丟失
集成測試級別
子系統(tǒng)間的數(shù)據(jù)集成測試缸夹。
不同系統(tǒng)間的數(shù)據(jù)集成測試痪寻。
什么是系統(tǒng)測試
系統(tǒng)測試是針對整個產(chǎn)品系統(tǒng)進行的測試
系統(tǒng)測試的范圍
功能測試、用戶體驗測試虽惭、性能測試橡类、UI測試、兼容性測試芽唇、安裝測試顾画、文檔測試、穩(wěn)定性測試等
驗收測試
主要確認軟件是否滿足軟件需求規(guī)格說明書中的要求匆笤。
alpha測試研侣、beta測試的區(qū)別
alpha測試：公司內部員工組織的測試
beta測試：由典型客戶進行的測試
白盒測試、黑盒測試炮捧、灰盒測試
白盒：對程序內部結構和算法進行測試
黑盒：在完全不考慮程序內部邏輯的情況下庶诡，檢查程序是否滿足用戶需求
灰盒：關注系統(tǒng)接口所實現(xiàn)的功能，是否和需求一致
回歸測試
全量回歸：對軟件的新版本測試時咆课，重復執(zhí)行上一個版本測試時使用的測試用例末誓，防止出現(xiàn)以前應用沒有的問題現(xiàn)在出問題了
部分回歸：當在測試過程中扯俱，發(fā)現(xiàn)某個模塊存在缺陷，開發(fā)修復后喇澡，測試人員重新驗證該缺陷是否被修復迅栅，以及驗證相關聯(lián)的模塊是否受影響
冒煙測試/預測試
目的是確認軟件基本功能正常，可以進行后續(xù)的正式測試工作
質量六大特性
需求分析的目的
澄清需求撩幽，提取測試點
需求評審的目的
完整性審查
準確性審查
需求評審那些人會參與
開發(fā)人員库继、開發(fā)經(jīng)理、測試人員窜醉、測試經(jīng)理、產(chǎn)品經(jīng)理
測試計劃的目的/為什么要編寫測試計劃
為了規(guī)范軟件測試內容艺谆、方法和過程榨惰，在對軟件進行測試之前，必須創(chuàng)建測試計劃静汤。
什么時間開始編寫測試計劃琅催？
需求分析后編寫測試計劃，在整個測試工作過程中虫给，不斷修改
由誰來編寫測試計劃
一般來說都是測試經(jīng)理藤抡、測試組長來編寫,經(jīng)驗豐富的測試人員
測試的結束條件
需求覆蓋率、用例執(zhí)行率抹估、缺陷遺留率達到預定質量目標缠黍。
測試計劃的內容
測試項目的背景、測試范圍药蜻、測試方式/策略瓷式、測試資源、測試開始和結束條件语泽、進度安排贸典、測試組織，以及與測試有關的風險方面
常見web服務器
apache踱卵、tomcat廊驼、nginx、weblogic
常見DB服務器
mysql惋砂、oracle
常見編程語言
Java妒挎、PHP、Python
常見linux系統(tǒng)
redhat班利、centos饥漫、ubuntu、aix
測試用例的要素/元素
1罗标、用例編號/id庸队，用例標題积蜻，用例的級別，預置條件彻消，操作步驟竿拆，預期結果，實際結果
如何劃分/確定用例的級別
1宾尚、依據(jù)用戶使用該場景的頻率
2丙笋、該功能對系統(tǒng)的影響程度來確定
寫好測試用例的關鍵 /寫好用例要關注的維度
1、覆蓋用戶的需求煌贴；
2御板、考慮用戶的各種正常和異常的使用場景；
3牛郑、用例的顆粒大小要均勻怠肋。通常，一個測試用例對應一個場景淹朋；
4笙各、用例各個要素要齊全，步驟應該足夠詳細础芍，操作應該明確杈抢，容易被其它測試工程師讀懂，并能順利執(zhí)行仑性；
做好用例評審惶楼，及時更新測試用例
測試用例的狀態(tài)
No Test未執(zhí)行狀態(tài)
Pass通過狀態(tài)
Fail失敗狀態(tài)
Block阻礙狀態(tài)。
Investigate觀察中狀態(tài)虏缸。
測試環(huán)境怎么搭建的鲫懒？
參考答案：搭建環(huán)境前，開發(fā)都會給到我們一份系統(tǒng)發(fā)布手冊刽辙，我們會根據(jù)這個手冊來搭建窥岩。比如，我這個xx系統(tǒng)宰缤，是搭建在Unix系統(tǒng)下的颂翼，web服務器用的是Tomcat8，MySQL版本是5.7慨灭，程序是JAVA編寫的朦乏，首先我們向開發(fā)拿到編譯好的安裝包，然后用xshell(或CRT)遠程連接上Unix系統(tǒng)氧骤，把tomcat服務器停掉呻疹，把程序包放到webapps目錄下，然后再啟動tomcat服務器就可以了筹陵。
偶然性問題的處理
1刽锤、確定是偶然性的bug之后镊尺，收集相關的日志，連同截圖一起提單給開發(fā)定位并思；
2庐氮、如果沒有日志記錄，缺陷在當前版本無法復現(xiàn)宋彼，且缺陷的影響程度比較低弄砍，可以提交問題單進行跟蹤，跟蹤三個版本输涕，如果后三個版本都無法復現(xiàn)音婶，就可以關閉該缺陷；
3莱坎、如果這些不可復現(xiàn)的Bug是很嚴重的Bug桃熄，比如導致系統(tǒng)崩潰等，并且型奥，實在沒有再次出現(xiàn)，除了要及時反饋給上級之外碉京，最后還要寫到測試報告中厢汹，說明出現(xiàn)了什么現(xiàn)象，但無法再現(xiàn)谐宙！
當我們認為某個地方是bug烫葬，但開發(fā)認為不是bug，怎么處理凡蜻？
1搭综、先跟開發(fā)溝通，確認系統(tǒng)的實際結果是不是和需求有不一致的地方划栓；有些地方可能需求沒提及兑巾，但是用戶體檢不好，我們也可以認為是bug忠荞。
2蒋歌、如果開發(fā)以不影響用戶使用為理由，拒絕修改委煤，我們可以和產(chǎn)品經(jīng)理堂油，測試經(jīng)理等人員進行討論，確定是否要修改碧绞，如果大家都一致認為不用改府框，就不改。
產(chǎn)品在上線后用戶發(fā)現(xiàn)bug讥邻，這時測試人員應做哪些工作迫靖？
1院峡、測試人員復現(xiàn)問題后，提交問題單進行跟蹤袜香；
2撕予、評估該問題的嚴重程度，以及修復問題時的影響范圍蜈首，回歸測試需要測試哪些功能实抡；
3、問題修復后欢策，先在測試環(huán)境上回歸吆寨，通過后再在生產(chǎn)環(huán)境上打補丁，然后再進行回歸測試踩寇；
4啄清、總結經(jīng)驗，分析問題發(fā)生的原因俺孙，避免下次出現(xiàn)同樣問題辣卒。
二八定理:80%的缺陷出現(xiàn)在 20%的模塊。
bug的等級
致命睛榄，嚴重荣茫，一般，輕微
缺陷的狀態(tài)
激活场靴，確認啡莉，已解決，關閉
如何跟蹤缺陷
當發(fā)現(xiàn)缺陷后旨剥，我們要在禪道上提交問題單給開發(fā)咧欣，并每隔一段時間(間隔一個小時，或兩個小時都可以)去檢查缺陷是否被處理轨帜，如果沒及時處理魄咕，就要提示開發(fā)，讓開發(fā)及時修復問題阵谚，問題修復后蚕礼，要及時進行回歸測試。
缺陷單應該包含這些要素
缺陷標題梢什，嚴重級別奠蹬，問題所屬模塊，復現(xiàn)步驟嗡午，預期結果囤躁，實際結果，有關的日志和截圖。
測試報告的主要內容
1狸演、數(shù)據(jù)統(tǒng)計
2言蛇、遺留bug情況
3、測試風險
4宵距、測試對象評估
5腊尚、測試結論
