OSI7層模型
TCP/IP五層模型
OSI7層模型的特點
- 下層為上層提供服務(wù)
- 同層次之間使用相同的協(xié)議
應(yīng)用層有哪些協(xié)議？
http、https
傳輸層有哪些協(xié)議？
TCP、UDP
TCP與UDP的區(qū)別與聯(lián)系
面向連接的服務(wù)(TCP)
- 先建立連接再傳輸數(shù)據(jù)
- 數(shù)據(jù)傳輸過程中，數(shù)據(jù)包不需要攜帶目的地址
- 保證數(shù)據(jù)傳輸?shù)目煽啃?/li>
無連接的服務(wù)(UDP)
- 不需要事先建立連接，直接發(fā)送數(shù)據(jù)
- 每個報文都帶有完整的目的地址
- 不保證報文傳輸?shù)目煽啃?/li>
TCP如何建立連接
通過三次握手建立連接
A 發(fā)送連接請求 B
B 回復(fù)確認(rèn)連接 A
A 收到回復(fù)后，建立連接 B
啟動/關(guān)閉/ tomcat服務(wù)
'''cd 到tomcat目錄下的bin目錄'''
./startup.sh #啟動tomcat服務(wù)
./shutdown.sh #關(guān)閉tomcat服務(wù)
'''使用catalina.sh同樣也可以啟動或者關(guān)閉tomcat服務(wù)'''
'''cd 到tomcat目錄下的bin目錄'''
./catalina.sh stop #關(guān)閉tomcat服務(wù)
./catalina.sh start #啟動tomcat服務(wù)
bin用來存放tomcat的命令的地方
webapps用來存放軟件包的目錄
啟動/關(guān)閉/重啟 http服務(wù)
service httpd start
service httpd stop
service httpd restart
啟動/關(guān)閉/重啟 mysql服務(wù)
service mysqld start
service mysqld stop
service mysqld restart
B/S架構(gòu)和C/S架構(gòu)
- B/S架構(gòu)需要重點考慮系統(tǒng)在不同的瀏覽器中的兼容性問題(瀏覽器的內(nèi)核不同)
- C/S 架構(gòu)需要考慮系統(tǒng)在不同平臺的安裝、卸載、升級
HTTP協(xié)議
HTTP協(xié)議,超文本傳輸協(xié)議,應(yīng)用層協(xié)議，由請求和響應(yīng)構(gòu)成
常見的請求方式（get，post）
post請求與get請求的區(qū)別
- get請求，發(fā)送的數(shù)據(jù)跟隨網(wǎng)址(URL),一起傳輸。
- post請求，發(fā)送的數(shù)據(jù)，在請求體里單獨傳輸。
Cookie和Session的區(qū)別與聯(lián)系
- cookie數(shù)據(jù)存放在客戶的瀏覽器上，session數(shù)據(jù)放在服務(wù)器上。
- cookie不是很安全，別人可以分析存放在本地的COOKIE并進(jìn)行COOKIE欺騙考慮到安全應(yīng)當(dāng)使用session。
- session會在一定時間內(nèi)保存在服務(wù)器上，當(dāng)訪問增多，會比較占用你服務(wù)器的資源。
HTTP狀態(tài)碼
| 狀態(tài)碼 | 含義 |
|---|---|
| 200 | ok |
| 301 | 永久移動 |
| 302 | 臨時移動 |
| 404 | 找不到資源 |
| 500 | 服務(wù)器內(nèi)部錯誤 |
常見默認(rèn)端口
| 軟件 | 默認(rèn)端口 |
|---|---|
| oracle | 1521 |
| mysql | 3306 |
| http | 80 |
| https | 443 |
| tomcat | 8080 |
| ssh | 22 |
| ftp | 21 |
瀑布模型
V模型
軟件測試流程/生命周期
測試需求分析
測試需求評審
編寫測試計劃
設(shè)計測試用例
測試用例評審
搭建測試環(huán)境
測試執(zhí)行
回歸測試
測試報告
軟件測試的定義
在規(guī)定的條件下對程序進(jìn)行操作，以發(fā)現(xiàn)程序的錯誤，并對軟件質(zhì)量進(jìn)行評估。
測試的目的
不僅僅是為了發(fā)現(xiàn)軟件缺陷與錯誤，而且也是對軟件質(zhì)量進(jìn)行度量和評估，以提高軟件的質(zhì)量。
軟件測試原則
所有的軟件測試都應(yīng)追溯到用戶需求。
應(yīng)當(dāng)盡早地和不斷地進(jìn)行軟件測試。
完全測試是不可能的，測試需要終止。
充分注意測試中的群集現(xiàn)象。
程序員應(yīng)避免檢查自己的程序。
盡量避免測試的隨意性
軟件測試風(fēng)險
進(jìn)度風(fēng)險、質(zhì)量風(fēng)險、人員風(fēng)險、需求變更、成本風(fēng)險等
按階段劃分
單元測試
集成測試
系統(tǒng)測試
驗收測試
單元測試關(guān)注點
對軟件中的最小可測試單元進(jìn)行檢查和驗證
集成測試關(guān)注點
在把各個模塊連接起來時，穿越模塊接口的數(shù)據(jù)是否會丟失
集成測試級別
- 子系統(tǒng)間的數(shù)據(jù)集成測試。
- 不同系統(tǒng)間的數(shù)據(jù)集成測試。
什么是系統(tǒng)測試
系統(tǒng)測試是針對整個產(chǎn)品系統(tǒng)進(jìn)行的測試
系統(tǒng)測試的范圍
功能測試、用戶體驗測試、性能測試、UI測試、兼容性測試、安裝測試、文檔測試、穩(wěn)定性測試等
驗收測試
主要確認(rèn)軟件是否滿足軟件需求規(guī)格說明書中的要求。
alpha測試、beta測試的區(qū)別
alpha測試：公司內(nèi)部員工組織的測試
beta測試：由典型客戶進(jìn)行的測試
白盒測試、黑盒測試、灰盒測試
白盒：對程序內(nèi)部結(jié)構(gòu)和算法進(jìn)行測試
黑盒：在完全不考慮程序內(nèi)部邏輯的情況下，檢查程序是否滿足用戶需求
灰盒：關(guān)注系統(tǒng)接口所實現(xiàn)的功能，是否和需求一致
回歸測試
全量回歸：對軟件的新版本測試時，重復(fù)執(zhí)行上一個版本測試時使用的測試用例，防止出現(xiàn)以前應(yīng)用沒有的問題現(xiàn)在出問題了
部分回歸：當(dāng)在測試過程中，發(fā)現(xiàn)某個模塊存在缺陷，開發(fā)修復(fù)后，測試人員重新驗證該缺陷是否被修復(fù)，以及驗證相關(guān)聯(lián)的模塊是否受影響
冒煙測試/預(yù)測試
目的是確認(rèn)軟件基本功能正常，可以進(jìn)行后續(xù)的正式測試工作
質(zhì)量六大特性
需求分析的目的
澄清需求，提取測試點
需求評審的目的
- 完整性審查
- 準(zhǔn)確性審查
需求評審那些人會參與
開發(fā)人員、開發(fā)經(jīng)理、測試人員、測試經(jīng)理、產(chǎn)品經(jīng)理
測試計劃的目的/為什么要編寫測試計劃
為了規(guī)范軟件測試內(nèi)容、方法和過程，在對軟件進(jìn)行測試之前，必須創(chuàng)建測試計劃。
什么時間開始編寫測試計劃？
需求分析后編寫測試計劃，在整個測試工作過程中，不斷修改
由誰來編寫測試計劃
一般來說都是測試經(jīng)理、測試組長來編寫,經(jīng)驗豐富的測試人員
測試的結(jié)束條件
需求覆蓋率、用例執(zhí)行率、缺陷遺留率達(dá)到預(yù)定質(zhì)量目標(biāo)。
測試計劃的內(nèi)容
測試項目的背景、測試范圍、測試方式/策略、測試資源、測試開始和結(jié)束條件、進(jìn)度安排、測試組織，以及與測試有關(guān)的風(fēng)險方面
常見web服務(wù)器
apache、tomcat、nginx、weblogic
常見DB服務(wù)器
mysql、oracle
常見編程語言
Java、PHP、Python
常見linux系統(tǒng)
redhat、centos、ubuntu、aix
測試用例的要素/元素
用例編號/id，用例標(biāo)題，用例的級別，預(yù)置條件，操作步驟，預(yù)期結(jié)果，實際結(jié)果
如何劃分/確定用例的級別
- 依據(jù)用戶使用該場景的頻率
- 該功能對系統(tǒng)的影響程度來確定
寫好測試用例的關(guān)鍵 /寫好用例要關(guān)注的維度
- 覆蓋用戶的需求；
- 考慮用戶的各種正常和異常的使用場景；
- 用例的顆粒大小要均勻。通常，一個測試用例對應(yīng)一個場景；
- 用例各個要素要齊全，步驟應(yīng)該足夠詳細(xì)，操作應(yīng)該明確，容易被其它測試工程師讀懂，并能順利執(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服務(wù)器用的是Tomcat8，MySQL版本是5.7，程序是JAVA編寫的，首先我們向開發(fā)拿到編譯好的安裝包，然后用xshell(或CRT)遠(yuǎn)程連接上Unix系統(tǒng)，把tomcat服務(wù)器停掉，把程序包放到webapps目錄下，然后再啟動tomcat服務(wù)器就可以了。
偶然性問題的處理
- 確定是偶然性的bug之后，收集相關(guān)的日志，連同截圖一起提單給開發(fā)定位；
- 如果沒有日志記錄，缺陷在當(dāng)前版本無法復(fù)現(xiàn)，且缺陷的影響程度比較低，可以提交問題單進(jìn)行跟蹤，跟蹤三個版本，如果后三個版本都無法復(fù)現(xiàn)，就可以關(guān)閉該缺陷；
- 如果這些不可復(fù)現(xiàn)的Bug是很嚴(yán)重的Bug，比如導(dǎo)致系統(tǒng)崩潰等，并且，實在沒有再次出現(xiàn)，除了要及時反饋給上級之外，最后還要寫到測試報告中，說明出現(xiàn)了什么現(xiàn)象，但無法再現(xiàn)！
當(dāng)我們認(rèn)為某個地方是bug，但開發(fā)認(rèn)為不是bug，怎么處理？
- 先跟開發(fā)溝通，確認(rèn)系統(tǒng)的實際結(jié)果是不是和需求有不一致的地方；有些地方可能需求沒提及，但是用戶體檢不好，我們也可以認(rèn)為是bug。
- 如果開發(fā)以不影響用戶使用為理由，拒絕修改，我們可以和產(chǎn)品經(jīng)理，測試經(jīng)理等人員進(jìn)行討論，確定是否要修改，如果大家都一致認(rèn)為不用改，就不改。
產(chǎn)品在上線后用戶發(fā)現(xiàn)bug，這時測試人員應(yīng)做哪些工作？
- 測試人員復(fù)現(xiàn)問題后，提交問題單進(jìn)行跟蹤；
- 評估該問題的嚴(yán)重程度，以及修復(fù)問題時的影響范圍，回歸測試需要測試哪些功能；
- 問題修復(fù)后，先在測試環(huán)境上回歸，通過后再在生產(chǎn)環(huán)境上打補丁，然后再進(jìn)行回歸測試；
- 總結(jié)經(jīng)驗，分析問題發(fā)生的原因，避免下次出現(xiàn)同樣問題。
二八定理:80%的缺陷出現(xiàn)在 20%的模塊。
bug的等級
致命，嚴(yán)重，一般，輕微
缺陷的狀態(tài)
激活，確認(rèn)，已解決，關(guān)閉
如何跟蹤缺陷
當(dāng)發(fā)現(xiàn)缺陷后，我們要在禪道上提交問題單給開發(fā)，并每隔一段時間(間隔一個小時，或兩個小時都可以)去檢查缺陷是否被處理，如果沒及時處理，就要提示開發(fā)，讓開發(fā)及時修復(fù)問題，問題修復(fù)后，要及時進(jìn)行回歸測試。
缺陷單應(yīng)該包含這些要素
缺陷標(biāo)題，嚴(yán)重級別，問題所屬模塊，復(fù)現(xiàn)步驟，預(yù)期結(jié)果，實際結(jié)果，有關(guān)的日志和截圖。
測試報告的主要內(nèi)容
數(shù)據(jù)統(tǒng)計
遺留bug情況
測試風(fēng)險
測試對象評估
測試結(jié)論
