分布式服務器

一臺主機，N多臺子節(jié)點

一臺主服務器控制可以控制多臺子節(jié)點的服務，用戶分布不同的服務器上，A節(jié)服務器有100個用戶，B節(jié)點服務器存在100個用戶。

分布式壓力測試。

c/s ?：微信、釘釘、QQ

Web的項目系統(tǒng)架構:B/S

前端---功能問題

接口----性能、數(shù)據(jù)交互

后端（WEB服務器、數(shù)據(jù)庫服務）

軟件測試的定義：發(fā)現(xiàn)程序中的錯誤而執(zhí)行程序的過程。

如何定義錯誤？

判斷預期結果與實際結果是否相等，如果預期結果與實際結果相等則不是bug。

軟件測試的目的是：找bug

什么是bug？就是一個缺陷

什么是預期結果？需求規(guī)格說明嚴格規(guī)定要實現(xiàn)的功能。

實際結果：用戶通過操作軟件功能，輸入相對應的數(shù)據(jù)進行測試的過程所得出的結果。

1.打開瀏覽，輸入URL

2.點擊登錄功能

3.輸入正確的用戶與密碼登錄----預期結果：用戶登錄成功----測試用例--正向

用戶名 ? 密碼

admin ? ?admin123456666

kitty ? ? ? kitty123456

zhang ? ?zhang123456

假設登錄頁面出現(xiàn)一個bug

用戶輸入正確的用戶名與密碼---登錄失敗了---實際結果

實際結果與預期結果不相等。

異常的用例個數(shù)要大于正常的用例。

4.輸入錯誤的用戶與密碼登錄----預期結果：用戶登錄失敗----測試用例--正向

通過測試人員設計的測試案例來覆蓋需求的功能點。

bug是不分布不同層面的

基本前端的功能、界面bug----功能性問題、兼容性、性能，NAN---讀取后端接口的參數(shù)錯誤---JS的坑

基于接口層面的bug：接口不通過，性能問題---多用戶、多線程、模擬真實的用戶場景

基于代碼---JUnit---基本JAVA的單元測試,對需求的功能進行測試，測試代碼是否滿足需求規(guī)格說明書要求。

開發(fā)人員編寫單元測試案例來驗證程序的正確性。

基于V模型分類：單元測試、集成測試、系統(tǒng)測試

前端-系統(tǒng)測試

接口-集成測試

代碼-單元測試

需求文檔的測試

操作系統(tǒng)、瀏覽器等相關的軟件或者硬件的跨平臺的兼容性測試

單元測試工具一般用sonar

def add(a,b):

c=a+b

return c

軟件測試與調(diào)試的區(qū)別：

軟件測試僅發(fā)現(xiàn)問題，不修復問題--測試人員的職責

軟件調(diào)試：不但要發(fā)現(xiàn)問題而且要解決問題（修復問題）--開發(fā)人員、產(chǎn)品經(jīng)理、UI設計人員

前端寫頁面，寫JS腳本

后端：寫整個網(wǎng)站的模塊內(nèi)容，所有接口的開發(fā)，后端框架的設計、業(yè)務邏輯的處理。

測試--偏向于業(yè)務層--功能、性能、用戶體驗、處理客戶反饋的信息、測試開發(fā)----不僅要會測試還要會開發(fā)。

技術：業(yè)務方向功能測試、測試管理，技術方向 ：自動化、性能測試、測試開發(fā)、安全性測試

軟件測試的原則：

一、所有的的測試都要基于需求去驗證

二、設計的測試用例要包括有效（合理的輸入）的用例與無效（異常輸入）的用例

基于瀏覽器兼容性問題的核心原因：因為不同的瀏覽器內(nèi)核不一樣，對前面頁的代碼渲染解析不同，所以產(chǎn)生不同的展現(xiàn)效果

頁面錯亂，而格局混亂，控件不顯示。

對于兼容要求比較高的產(chǎn)品有那些？

電商網(wǎng)站：PC端、移動端-app--不同品牌的手機、型號、網(wǎng)絡等等相關的測試需求要點的覆蓋。

兼容性問題帶來的后果：用戶量的流失，造成一定的經(jīng)濟損失。

測試需要用戶參與：游戲測試--公測

疫情---回歸測試----發(fā)現(xiàn)了一個問題開發(fā)修改后，又帶來了新的bug，循環(huán)沒有結束。

做好軟件測試需要大家具備一顆追求完美的心態(tài)。

一個系統(tǒng)中模塊的業(yè)務越復雜，出現(xiàn)的bug就越多。

冒煙測試：對開發(fā)的系統(tǒng)主流程實施測試（訂購流程）

冒煙測試不通過的bug屬于嚴重及別為緊急-重要--

1.注冊（用戶名、密碼、性別、年齡、企業(yè)、電話號碼）

post提交接口

2.登錄

3.查找商品

4.添加購物車功能---庫存不足---采購，或者商品

5、提交訂單

6.訂單支付（）

7、關注 訂單狀態(tài)流轉

8、完成收貨

9、好評度

退貨或者退款

測試設計--測試用例的設計，基于需求功能--提取的測試點--將測試點轉化測試用例

開發(fā)過程是將需求轉化成代碼的過程

基于需求點---進行框架設計（概要設計-企業(yè)后端架構師）詳細設計 ----編碼--修復bug

開發(fā)與測試同步進行，開發(fā)人員在做好開發(fā)計劃之后，實施產(chǎn)品研發(fā)工作。

測試人員做測試計劃后，實施測試階段的工作（用例設計占比60%，30%執(zhí)行用例-尋找bug）

一對多

一個功能點至少兩條用例，一條正向用例，一條反例。

訂購

1、支付成功。

2. ? 提交訂單失?。ㄉ唐穾齑娌蛔恪⒓尤胭徫镘囉脩糇?，或者用戶未登錄，）

什么是軟件質(zhì)量？

滿足需求規(guī)格說明書中明確的顯性或者隱性的需求。

什么是顯性需求？

需求規(guī)格說明書中有明確規(guī)定要實現(xiàn)的功能，一般來說在需求文檔中會詳細標識（需求原型圖、系統(tǒng)架構圖--業(yè)務模塊-子模塊）

關注功能

關注成功（條件：用戶未關注）

關注失敗-已經(jīng)關注（用戶已經(jīng)被關注了是不允許點擊關注功能，關注功能需要置灰）

系統(tǒng)提示：用戶已經(jīng)被關注，不允許重復關注

關注成功后關注數(shù)量增加

取消關注數(shù)量減少，總粉絲數(shù)=關注數(shù)量+視頻的數(shù)量

什么是隱性的需求？

需求規(guī)格說明書中沒有明確規(guī)定的需求-隱含在需求內(nèi)部并沒有詳細描述的需求叫做隱性需求

購物金額達到【100，200】商品打6折，隱性的需求用戶打過一次折扣后不允許再次打折

軟件測試六大特性：

功能性、可靠性、易用性、可維護性、時效性、可移植性

時效性一般是從性能的時間（以較短的時間產(chǎn)生更大的價值）、資源（cpu\內(nèi)存、I/O、磁盤）來考慮問題

通過性能測試來節(jié)約資源，優(yōu)化代碼。

例如：多線程機制就是一種時效生，在短的時間內(nèi)以最少的資源產(chǎn)生最大的價值---服務器的資源利用率。

可移植性：一種兼容性測試。

MYSQL-存儲數(shù)據(jù)的倉庫，不同的數(shù)據(jù)庫語言的語法有區(qū)別。

軟件生命周期的：從軟件的產(chǎn)生到軟件被淘汰的過程。

可移植性：需要根據(jù)不同的用戶使用環(huán)境來滿足業(yè)務需求的能力。

企業(yè)的測試環(huán)境分為三個：

QA環(huán)境-測試環(huán)境---80%的bug來源于QA環(huán)境

UAT環(huán)境-用戶體驗環(huán)境--20%的bug

PRE環(huán)境--灰度發(fā)布環(huán)境--系統(tǒng)的數(shù)據(jù)同步來源于生產(chǎn)環(huán)境，是一種上線前生產(chǎn)的一種 模擬環(huán)境

PRD環(huán)境-生產(chǎn)環(huán)境-走調(diào)拔--走主體流程線上模塊測試----只允許出現(xiàn)嚴重級別較低的bug.

保障產(chǎn)品質(zhì)量。

易安裝性：C/S架構，客戶端的安裝方式（軟件的安裝與刪除）。

B/S架構與C/S架構的不同點

C/S架構的系統(tǒng)需要用戶主動更新。

如果一個系統(tǒng)出現(xiàn)bug,軟件提供服務方將bug已經(jīng)修復，用戶如果不更新軟件，這個bug一直存在。

研發(fā)成本高于B/S架構

B/S--環(huán)境的部署

只要服務更新一個bug的功能代碼，bug就能正常修復

課程總結與回顧：

一、軟件測試的發(fā)展歷程（了解）

二、軟件測試的重要性（了解）

羅列了軟件中常見的嚴重性bug分享。

三、軟件測試的定義（重要）

軟件測試的定義及目的。

軟件測試的定義：發(fā)現(xiàn)程序中的錯誤而執(zhí)行程序的過程

目的：尋找bug

四、軟件測試的原則（重要）

所有問題都是依據(jù)需求而開展

五、軟件測試的六特性與27大子特性（重要）

項目系統(tǒng)的講解。

作業(yè)安排：

學習內(nèi)容：軟件測試概述及特性 ? 姓名： ?學號