1.測試分類占比
2.軟件測試的原則
1.應當把“盡早和不斷地測試”作為開發(fā)者的座右銘。
2.設計測試用例時，應該考慮到合法的輸入和不合法的輸入，以及各種邊界條件，特殊情況下要制造極端狀態(tài)和意外狀態(tài)，比如網絡異常中斷、電源斷電等情況。
3.一定要注意測試中的錯誤集中發(fā)生現(xiàn)象，這和程序員的編程水平和習慣有很大的關系。
4.對測試錯誤結果一定要有一個確認的過程。一般有A測試出來的錯誤，一定要有一個B來確認，嚴重的錯誤可以召開評審會進行討論和分析。
5.制定嚴格的測試計劃，并把測試時間安排得盡量寬松，不要希望在極短的時間內完成一個高水平的測試。
6.回歸測試的關聯(lián)性一定要引起充分的注意，修改一個錯誤而引起更多錯誤出現(xiàn)的現(xiàn)象并不少見。
7.妥善保存一切測試過程文檔，意義是不言而喻的，測試的重現(xiàn)性往往要靠測試文檔。
3.軟件的開發(fā)模式
3.1.線性模型與漸進式模型
- 線性模型：最常見的“瀑布模型”，基礎框架，但缺點在于“集成之日就是爆炸之日”。（立項分析-需求分析-設計-編碼-測試-維護）很多企業(yè)使用后使用迭代進行修改。
- 漸進式模型：最常見的“螺旋模型”，（需求分析-風險分析-設計、編碼-測試、評審），迭代開發(fā)和增量開發(fā)模式。
- 注意：每一次迭代原型出來后，測試人員都需要從原型界面，系統(tǒng)主要功能，性能等方面對原型進行評審。
3.2.迭代和增量的理解
4.軟件生命周期模型
- 軟件生命周期 同任何事物一樣，一個軟件產品或軟件系統(tǒng)也要經歷孕育、誕生、成長、成熟、衰亡等階段，一般稱為軟件生命周期（軟件生存周期） 。軟件生命周期模型是指人們?yōu)殚_發(fā)更好的軟件而歸納總結的軟件生命周期的典型實踐參考。
4.1.邊做邊改模型
- 許多產品都是使用“邊做邊改”模型來開發(fā)的。在這種模型中，既沒有規(guī)格說明，也沒有經過設計，軟件隨著客戶的需要一次又一次地不斷被修改。
- 在這個模型中，開發(fā)人員拿到項目立即根據需求編寫程序，調試通過后生成軟件的第一個版本。在提供給用戶使用后，如果程序出現(xiàn)錯誤，或者用戶提出新的要求，開發(fā)人員重新修改代碼，直到用戶滿意為止。
這是一種類似作坊的開發(fā)方式，對編寫幾百行的小程序來說還不錯，但這種方法對任何規(guī)模的開發(fā)來說都是不能令人滿意的，其主要問題在于：
（1） 缺少規(guī)劃和設計環(huán)節(jié)，軟件的結構隨著不斷的修改越來越糟，導致無法繼續(xù)修改；
（2） 忽略需求環(huán)節(jié)，給軟件開發(fā)帶來很大的風險；
（3） 沒有考慮測試和程序的可維護性，也沒有任何文檔，軟件的維護十分困難。
4.2.瀑布模型
瀑布模型是最早出現(xiàn)的軟件開發(fā)模型，在軟件工程中占有重要的地位，它提供了軟件開發(fā)的基本框架。其過程是從上一項活動接收該項活動的工作對象作為輸入，利用這一輸入實施該項活動應完成的內容給出該項活動的工作成果，并作為輸出傳給下一項活動。同時評審該項活動的實施，若確認，則繼續(xù)下一項活動；否則返回前面，甚至更前面的活動。對于經常變化的項目而言，瀑布模型毫無價值。
瀑布型簡單地說就是按照需求、設計、編碼、測試、軟件維護這個基本的順序來研發(fā)軟件，前面一個步驟不完成，后面的步驟不能開始，否則問題會滾到下個階段，帶來更多的問題
優(yōu)點：
1.為項目提供了按階段劃分的檢查點
2.當前一階段完成后，只需要去關注后續(xù)階段。
缺點：
1）各個階段的劃分完全固定，階段之間產生大量的文檔，極大地增加了工作量。
2）由于開發(fā)模型是線性的，用戶只有等到整個過程的末期才能見到開發(fā)成果，從而增加了開發(fā)風險。
3）通過過多的強制完成日期和里程碑來跟蹤各個項目階段。
4）瀑布模型的突出缺點是不適應用戶需求的變化。
4.3.原型化模型
原型化模型的第一步是建造一個快速原型，實現(xiàn)客戶或未來的用戶與系統(tǒng)的交互，經過和用戶針對原型的討論和交流，弄清需求以便真正把握用戶需要的軟件產品是什么樣子的。充分了解后，再在原型基礎上開發(fā)出用戶滿意的產品。
如圖所示：原型嚴格來說不算一種軟件生命周期模型，它只是一種獲取需求的方法，在實際工作中該方法是相當重要的方法。
- 模型要點：瀑布和原型模型相結合，強調版本升級。
該模式的特點是一次性地獲取全部的需求，然后做出分版本實現(xiàn)各需求的計劃，每個版本只實現(xiàn)一部分需求，通過多個版本逐步實現(xiàn)全部需求，而每個版本可以認為是一個“小瀑布”。
該模型的好處是可以盡快讓系統(tǒng)上線，讓客戶先使用部分功能，盡早實現(xiàn)系統(tǒng)的價值。
該模型比較能符合實際的情況，我們往往也是通過多個版本來逐步實現(xiàn)全部需求，但需求是不可能在一開始就完全確定的，實際情況是往往只能確定80%，而后期通過各版本我們還會獲取更多的新需求以及需求調整。將此模型稍微調整后，可以適用于大部分的實際項目。
4.4.增量模型
增量模型也是原型化開發(fā)方法。如圖所示
4.5.螺旋模型
螺旋模型是一個演化軟件過程模型，將原型實現(xiàn)的迭代特征與線性順序（瀑布）模型中控制的和系統(tǒng)化的方面結合起來。使得軟件的增量版本的快速開發(fā)成為可能。在螺旋模型中，軟件開發(fā)是一系列的增量發(fā)布。螺旋模型的整個開發(fā)過程如圖所示。
圖中的螺旋線代表隨著時間推進的工作進展；開發(fā)過程具有周期性重復的螺旋線形狀。4個象限分別標志每個周期所劃分的4 個階段：制定計劃、風險分析、實施工程和客戶評估。螺旋模型要點：統(tǒng)一了瀑布模型與原型模型，與增量模型相似，更強調風險分析。
1.軟件分多個版本開發(fā)，每個版本就是一次螺旋。
2.每個版本按照這樣的順序進行：
1）確定軟件目標，選取定實施方案，弄清項目開發(fā)的限制條件；（圖中左上象限）
2）分析所選取方案，考慮如何識別和消除風險；（圖中右上象限）
3）實施軟件開發(fā)；（圖中右下象限）
4）評價開發(fā)工作，提出修正建議，調整計劃。（圖中右下象限、左下象限）
3.需求不是一次獲取和實現(xiàn)的，通過多個螺旋來完善。
4.計劃也不是一次成型的，每次螺旋都需要調整。
優(yōu)點：
1）設計上很靈活，可以在項目的各個階段進行變更；
2）以小的分段來構建大型系統(tǒng)，使成本計算變得簡單容易；(國企項目)
3）客戶始終參與每個階段的開發(fā)，保證了項目不偏離正確方向以及項目的可控性；
4）隨著項目推進，客戶始終掌握項目的最新信息 , 從而能夠和管理層有效地交互；
5）客戶認可這種公司內部的開發(fā)方式帶來的良好的溝通和高質量的產品。
缺點：
螺旋模型強調風險分析，但要求許多客戶接受和相信這種分析，并做出相關反應是不容易的。
因此，這種模型往往適應于內部的大規(guī)模軟件開發(fā)。該模型建設周期長，而軟件技術發(fā)展比較快，所以經常出現(xiàn)軟件開發(fā)完畢后，和當前的技術水平有了較大的差距，無法滿足當前用戶需求。
4.6.Ｖ模型
V 模型的左邊下降的是開發(fā)過程各階段，與此相對應的是右邊上升的部分，即各測試過程的各個階段。
V 模型的優(yōu)點在于它非常明確地標明了測試過程中存在的不同級別，并且清楚地描述了這些測試階段和開發(fā)各階段的對應關系。
1、需求分析階段對應生成需求規(guī)格說明書，對應測試生成系統(tǒng)測試方案，即為系統(tǒng)測試準備的，該階段已經完成了單元測試和集成測試，主要是對軟件產品的功能與非功能進行測試，幾乎不測試代碼，所以測試方法以黑盒為主；
2、概要設計階段對應生成概要設計說明書，對應測試生成集成測試方案，該階段已完成單元測試，是將各個功能模塊組裝起來進行的測試，所以也叫組裝測試。主要看模塊調用是否正常，接口是否可用，數(shù)據傳輸是否正確等，所以用到的測試方法幾乎是白盒的方法，如路徑覆蓋，條件組合覆蓋等；
3、詳細設計階段對應生成詳細設計說明書，對應測試生成單元測試方案，該階段是開發(fā)人員編碼后的第一個測試階段，是對開發(fā)出來的單獨模塊進行測試，以確保每一個功能模塊的功能正常，可以構建樁模塊和驅動模塊來回調用，方法也是以白盒為主。
4、白盒測試的準則是盡可能覆蓋程序內部的邏輯結構，黑盒則是盡可能覆蓋所有的輸入輸出接口，包括文檔等一些靜態(tài)的測試。除常用的測試方法外，仍需補充大范圍的隨機測試，盡可能達到覆蓋率100%。
V模型的缺陷及解決思路
V模型僅僅把測試過程作為在需求分析、系統(tǒng)設計及編碼之后的一個階段，忽視了測試對需求分析,系統(tǒng)設計的驗證，需求的滿足情況一直到后期的驗收測試才被驗證。
解決的思路是，當一個軟件開發(fā)的時候，研發(fā)人員和測試人員需要同時工作，測試在軟件做需求分析的同時就會有測試用例的跟蹤，這樣，可以盡快找出程序錯誤和需求偏離，從而更高效的提高程序質量，最大可能的減少成本，同時滿足用戶的實際軟件需求。
4.7.Ｗ模型
相對于V模型，W模型更科學。W模型是V模型的發(fā)展，強調的是測試伴隨著整個軟件開發(fā)周期，而且測試的對象不僅僅是程序，需求、功能和設計同樣要測試。測試與開發(fā)是同步進行的，從而有利于盡早地發(fā)現(xiàn)問題。
5.敏捷開發(fā)和測試
敏捷開發(fā)
敏捷開發(fā)是針對傳統(tǒng)的瀑布開發(fā)模式的弊端而產生的一種新的開發(fā)模式，目標是提高開發(fā)效率和響應能力。敏捷開發(fā)以用戶的需求進化為核心，采用迭代、循序漸進的方法進行軟件開發(fā)。
由于版本節(jié)奏比較快，開發(fā)與測試幾乎并行，一個版本周期內會有兩版在推動，也就是上圖中提到的波次發(fā)布，波次發(fā)布用于嘗試新加入的功能，做小范圍快速的開發(fā)，驗證和發(fā)布，為下個大版本的功能做實驗和調研?？焖侔l(fā)版的需求要求測試快速響應，敏捷測試模式適應項目需求。
- 模型優(yōu)勢：
工作任務劃分清晰，工作效率較高
與開發(fā)和產品溝通緊密，團隊協(xié)作性強
測試介入到整個項目的所有會議中，對整體版本信息情況把控全面
迅速占有市場，添加新的功能，吸引更多用戶使用，提升用戶體驗度
- 模型的缺陷：
模塊提交較快，測試時較有壓迫感
項目規(guī)劃要合理，不然測試時會出現(xiàn)復測的現(xiàn)象，加大工作量
6.軟件質量模型
6.1.軟件的功能性
1..適用性：
所提供的功能是用戶所需要的，
用戶所需要的功能軟件系統(tǒng)是否已提供。
2.準確性：
軟件系統(tǒng)提供給用戶的功能是否滿足用戶對該功能的精確度要求。
3.互操作性：
軟件系統(tǒng)和一個或多個周邊系統(tǒng)進行信息交互的能力。
不同型號的打印機與word之間的協(xié)議可能不一致，導致消息傳遞過程中發(fā)生錯誤。
▲應該將被測軟件系統(tǒng)和周邊系統(tǒng)的各種主流型號進行互操作性測試。
4.保密安全性：
軟件系統(tǒng)保護信息和數(shù)據的能力。
Ⅰ、防止未得到授權的人或系統(tǒng)訪問相關的信息或數(shù)據
Ⅱ、保證得到授權的人或系統(tǒng)能正常訪問相關的信息或數(shù)據。
不同的系統(tǒng)對于安全性的需求差別很大
常見的安全性測試：
⑴用戶驗證：登錄密碼驗證、IP地址訪問限制等 sql注入
用戶超時:登錄超過30分鐘，重新登錄(安全設置，cookie過期時間30分鐘)
⑵用戶權限管理:驗證低級別用戶是否具有了高級別用戶的權限，各級別用戶權限都得到了實現(xiàn)。
⑶系統(tǒng)數(shù)據的保護:對例如系統(tǒng)文件、用戶密碼文件等進行隱藏、密碼驗證、內容加密、備份。
5.加密、解密：
在計算機通訊中，采用密碼技術將信息隱蔽起來，再將隱蔽后的信息傳輸出去，使信息在傳輸過程中即使被竊取或截獲，竊取者也不能了解信息的內容，從而保證信息傳輸?shù)陌踩?/p>
token
Cookie 與session的區(qū)別：
1.cookie是明文傳輸 session的是隱藏專屬
2.Cookie是存在與本機 session是存在與服務器
3.Cookie的大小是限制在4K session大小限制在5M
6.2.軟件可靠性
1.成熟性
軟件系統(tǒng)防止內部錯誤擴散而導致失效的能力。
- 子系統(tǒng)、模塊、單元模塊的設計人員應該仔細分析和自身有接口關系的子系統(tǒng)、模塊、單元模塊，識別出這些接口上可能會傳遞過來的錯誤，然后在自己子系統(tǒng)、模塊、單元模塊內部對這些可能的錯誤預先進行防范，規(guī)避這些錯誤傳遞到自身而引起自身的失效。
.2.容錯性
軟件系統(tǒng)防止外部接口錯誤擴散而導致系統(tǒng)失效的能力。
- 設計人員應該充分分析外部接口可能產生的錯誤，然后在設計上對這些錯誤一一予以防范，防止這些外部傳入的錯誤波及自身而失效。
3.易恢復性
系統(tǒng)失效后重新恢復原有功能、性能的能力
- ①原有能力恢復的程度
②原有能力恢復的速度
4.可靠性依從性
遵循相關的標準（國際標準、國家標準、行業(yè)標準、企業(yè)內部規(guī)范等)約定或法規(guī)以及類似規(guī)定的能力。
6.3.軟件易用性
1..易理解性
用戶在使用軟件系統(tǒng)的過程中，系統(tǒng)交互給用戶的信息是否準確、清晰、易懂，能幫助用戶準確理解系統(tǒng)當前真實的狀態(tài)，指導其進一步的操作。
2.易學性
軟件系統(tǒng)提供相關的輔助手段，幫助用戶學習使用它
的能力。
例如：是否有用戶手冊，用戶手冊是否有中文版，是否有在
線幫助，界面上控件是否有回顯功能等。
3.易操作性
例如：
①Nokia手機和Moto手機在編輯短消息時的方便性差異。
②GUI界面，菜單層次不要太深
③安裝軟件的過程
錯誤：給用戶大量的安裝步驟，每步又有大量分支選項
（把用戶當成本軟件的專家）測試時應該以非專業(yè)的角度來測試過程，往往需要α、β測試。
4.吸引性
美觀：GUI界面、手機外觀等
新穎：如夏新手機來電跳舞功能
5、易用性的依從性
遵循相關的標準（國際標準、國家標準、行業(yè)標準、企業(yè)內部規(guī)范等)約定或法規(guī)以及類似規(guī)定的能力。問：性能測試的標準：
吞吐量
響應時間
資源使用率 內存使用率 cpu的使用率 電量的損耗 流量使用
成功率
6.4.軟件效率（性能測試）
1.時間效率(2-5-10) 358
系統(tǒng)在各業(yè)務場景下完成用戶指定的業(yè)務請求所需的響應時間。
2..資源效率
系統(tǒng)在各業(yè)務場景下完成用戶指定的業(yè)務請求所消耗的系統(tǒng)資源，如CPU占有率 75%內存占有率80%、通信帶寬占有率、軟件內部消息包資源占有率等。
3..效率依從性
遵循相關的標準（國際標準、國家標準、行業(yè)標準、企業(yè)內部規(guī)范等)約定或法規(guī)以及類似規(guī)定的能力。
6.5.軟件可維護性
1.易分析性
軟件系統(tǒng)提供輔助手段幫助開發(fā)人員分析識別缺陷、失效產生的原因，找出待修復部分的能力。（降低缺陷定位的成本）
2.易改變性
對軟件缺陷的修復容易被實施（降低修復缺陷成本）
- 設計上封裝性好、高內聚（同層次設計時，一個實體只完成一個功能）、低耦合，為未來可能的變化留有擴充余地。
3..穩(wěn)定性
例如：代碼中的有物理含義的數(shù)字，一定用宏代替。
4.易測試性
（降低發(fā)現(xiàn)缺陷的成本）
①軟件可控制：
軟件系統(tǒng)提供輔助手段幫助測試工程師控制該系統(tǒng)的運行，實現(xiàn)其測試執(zhí)行步驟的能力（通過打點、改變內部狀態(tài)、值等手段）
②可觀察：
軟件系統(tǒng)提供輔助手段幫助測試工程師獲得充分的系統(tǒng)運行信息，以正確判斷系統(tǒng)運行狀態(tài)和測試執(zhí)行結果的力。
a、設計單獨的測試模式
b、提供單獨的測試版本
▲測試部（一般指測試系統(tǒng)工程師）應該在需求分析階段就提出可測試性需求，可測試性需求和軟件產品其他需求一起納入需求包被分析設計并實現(xiàn)。
5.維護性的依從性
遵循相關的標準（國際標準、國家標準、行業(yè)標準、企業(yè)內部規(guī)范等)約定或法規(guī)以及類似規(guī)定的能力。
6.6.軟件可移植性
1.適應性
軟件系統(tǒng)無需做任何相應變動就能適應不同運行環(huán)境（操作系統(tǒng)平臺、數(shù)據庫平臺、硬件平臺等）的能力。
- 解決平臺無關、可移植性問題的一個常用思路是構造出一個虛擬層，虛擬層將下層細節(jié)屏蔽，對上層提供統(tǒng)一口。
2.易安裝性
主流平臺 全部測試用例
非主流平臺 10%測試用例
3.共存性
軟件系統(tǒng)和在公共環(huán)境與其共享資源的其他系統(tǒng)共存的能力。
▲測試不僅需要關注自身特性的實現(xiàn)，還要關注本軟件是否影響了其他軟件的正常功能。
6.7.易替換性
軟件系統(tǒng)升級能力（在線升級、打補丁升級等）
可移植性的依從性
遵循相關的標準（國際標準、國家標準、行業(yè)標準、企業(yè)內部規(guī)范等)約定或法規(guī)以及類似規(guī)定的能力。
7.軟件測試的常識知識
1.測試部門的組織結構
8.軟件測試工具
軟件測試工具是通過一些工具能夠使軟件的一些簡單問題直觀的顯示，使測試人員更好的找出軟件錯誤所在。
軟件測試工具分為自動化軟件測試工具和測試管理(禪道)工具。
軟件測試工具存在的價值是為了提高測試效率，用軟件來代替一些人工輸入。
測試管理工具是為了復用測試用例，提高軟件測試的價值。
一個好的軟件測試工具和測試管理工具結合起來使用將會使軟件測試效率大大的提高。
Bug管理工具： 禪道 Jary
自動化 selenium appnium （ui自動化） pytest (測試用例 單元測試) innerHtml （發(fā)送測試報告）
性能測試工具 jmeter Loadrunner、
抓包工具 Fiddler charles (弱網測試的)
接口工具 postman
錄制腳本 bodyboy jmeter云測 騰訊云 模擬不同的移動端或者是web瀏覽器
命令 Linux adb monkey
數(shù)據庫 myql
語言 python
