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