分布式服務器
一臺主機，N多臺子節點
一臺主服務器控制可以控制多臺子節點的服務，用戶分布不同的服務器上，A節服務器有100個用戶，B節點服務器存在100個用戶。
分布式壓力測試。
c/s ：某信、某釘、聊天軟件
Web的項目系統架構:B/S
前端---功能問題
接口----性能、數據交互
后端（WEB服務器、數據庫服務）
軟件測試的定義：發現程序中的錯誤而執行程序的過程。
如何定義錯誤？
判斷預期結果與實際結果是否相等，如果預期結果與實際結果相等則不是bug。
軟件測試的目的是：找bug
什么是bug？就是一個缺陷
什么是預期的結果？需求規格說明嚴格規定要實現的功能。
實際結果：用戶通過操作軟件功能，輸入相對應的數據進行測試的過程所得出的結果。
案例：給你一個登錄功能
1.打開瀏覽，輸入URL2.點擊登錄功能3.輸入正確的用戶與密碼登錄----預期結果：用戶登錄成功----測試用例--正向
用戶名 密碼
admin admin
kitty kitty
zhang
假設登錄頁面出現一個bug
用戶輸入正確的用戶名與密碼---登錄失敗了---實際結果
實際結果與預期的結果不相等。
異常的用例個數要大于正常的用例。
4.輸入錯誤的用戶與密碼登錄----預期結果：用戶登錄失敗----測試用例--正向
通過測試人員設計的測試案例來覆蓋需求的功能點。
bug是分布在不同層面的
基本前端的功能、界面bug----功能性問題、兼容性、性能，NAN---讀取后端接口的參數錯誤---JS的坑
基于接口層面的bug：接口不通過項目需求說明書模板，性能問題---多用戶、多線程、模擬真實的用戶場景
基于代碼---JUnit---基本JAVA的單元測試,對需求的功能進行測試項目需求說明書模板，測試代碼是否滿足需求規格說明書要求。
開發人員編寫單元測試案例來驗證程序的正確性。
基于V模型分類：單元測試、集成測試、系統測試前端-系統測試接口-集成測試代碼-單元測試需求文檔的測試
操作系統、瀏覽器等相關的軟件或者硬件跨平臺的兼容性測試
單元測試工具一般用sonar
def add(a,b):c=a+ c
軟件測試與調試的區別：
軟件測試僅發現問題，不修復問題--測試人員的職責
軟件調試：不但要發現問題而且要解決問題（修復問題）--開發人員、產品經理、UI設計人員
前端寫頁面，寫JS腳本
后端：寫整個網站的模塊內容，所有接口的開發，后端框架的設計、業務邏輯的處理。
測試--偏向于業務層--功能、性能、用戶體驗、處理客戶反饋的信息、測試開發----不僅要會測試還要會開發。
技術：業務方向功能測試、測試管理，技術方向 ：自動化、性能測試、測試開發、安全性測試
軟件測試的原則：
一、所有的測試都要基于需求去驗證
二、設計的測試用例要包括有效（合理地輸入）的用例與無效（異常輸入）的用例
基于瀏覽器兼容性問題的核心原因：因為不同的瀏覽器內核不一樣，對前面頁的代碼渲染解析不同，所以產生不同的展現效果
頁面錯亂，而格局混亂，控件不顯示。
對于兼容要求比較高的產品有哪些？
電商網站：PC端、移動端-app--不同品牌的手機、型號、網絡等等相關的測試需求要點的覆蓋。
兼容性問題帶來的后果：用戶量的流失，會造成一定的經濟損失。
測試需要用戶參與：游戲測試--公測
疫情---回歸測試----發現了一個問題開發修改后，又帶來了新的bug，循環沒有結束。
做好軟件測試需要大家具備一顆追求完美的心態。
一個系統中模塊的業務越復雜，出現的bug就越多。
冒煙測試：對開發的系統主流程實施測試（訂購流程）
冒煙測試不通過的bug屬于嚴重級別為緊急-重要--
1.注冊（用戶名、密碼、性別、年齡、企業、電話號碼）
post提交接口
2.登錄
3.查找商品
4.添加購物車功能---庫存不足---采購，或者商品
5、提交訂單
6.訂單支付（）
7、關注 訂單狀態流轉
8、完成收貨
9、好評度
退貨或者退款
測試設計--測試用例的設計，基于需求功能--提取的測試點--將測試點轉化為測試用例
開發過程是將需求轉化成代碼的過程
基于需求點---進行框架設計（概要設計-企業后端架構師）詳細設計 ----編碼--修復bug
開發與測試同步進行，開發人員在做好開發計劃之后，開始實施產品研發工作。
測試人員做測試計劃后，實施測試階段的工作（用例設計占比60%，30%執行用例-尋找bug）
一對多
一個功能點至少兩條用例，一條正向用例，一條反例。
訂購
1、支付成功。
2. 提交訂單失敗（商品庫存不足、沒有加入購物車用戶注冊，或者用戶未登錄，）
什么是軟件質量？
滿足需求規格說明書中明確的顯性或者隱性的需求。
什么是顯性需求？
需求規格說明書中有明確規定要實現的功能，一般來說在需求文檔中會詳細標識（需求原型圖、系統架構圖--業務模塊-子模塊）
關注功能
關注成功（條件：用戶未關注）
關注失敗-已經關注（用戶已經被關注了是不允許點擊關注功能，關注功能需要置灰）
系統提示：用戶已經被關注，不允許重復關注
關注成功后關注數量增加
取消關注數量減少，總粉絲數=關注數量+視頻的數量
什么是隱性的需求？
需求規格說明書中沒有明確規定的需求-隱含在需求內部并沒有詳細描述的需求叫做隱性需求
購物金額達到【100，200】商品打6折，隱性的需求用戶打過一次折扣后不允許再次打折
軟件測試六大特性：
功能性、可靠性、易用性、可維護性、時效性、可移植性
時效性一般是從性能的時間（以較短的時間產生更大的價值）、資源（cpu\內存、I/O、磁盤）來考慮問題
通過性能測試來節約資源，優化代碼。
例如：多線程機制就是一種時效生，在短的時間內以最少的資源產生最大的價值---服務器的資源利用率。
可移植性：一種兼容性測試。
MYSQL-存儲數據的倉庫，不同的數據庫語言的語法有區別。
軟件生命周期的：從軟件的產生到軟件被淘汰的過程。
可移植性：需要根據不同的用戶使用環境來滿足業務需求的能力。
企業的測試環境分為三個：
QA環境-測試環境---80%的bug來源于QA環境
UAT環境-用戶體驗環境--20%的bug
PRE環境--灰度發布環境--系統的數據同步來源于生產環境，是一種上線前生產的一種 模擬環境
PRD環境-生產環境-走調拔--走主體流程線上模塊測試----只允許出現嚴重級別較低的bug.
保障產品質量。
易安裝性：C/S架構，客戶端的安裝方式（軟件的安裝與刪除）。
B/S架構與C/S架構的不同點
C/S架構的系統需要用戶主動更新。
如果一個系統出現bug,軟件提供服務方將bug已經修復，用戶如果不更新軟件，這個bug一直存在。
研發成本高于B/S架構
B/S--環境的部署
只要服務更新一個bug的功能代碼，bug就能正常修復
課程總結與回顧：一、軟件測試的發展歷程（了解）二、軟件測試的重要性（了解）
羅列了軟件中常見的嚴重性bug分享。
三、軟件測試的定義（重要）
軟件測試的定義及目的。
軟件測試的定義：發現程序中的錯誤而執行程序的過程
目的：尋找bug
四、軟件測試的原則（重要）
所有問題都是依據需求而開展
五、軟件測試的六特性與27大子特性（重要）作業安排：
作業提交方式格式：軟件測試概述及特性 姓名： 學號