1.1 測試步驟總覽
1.2 測試模型分析
如下的測試模型來簡單的說明測試中需要關注的點和測試的目的
拐點分析：
（1）第一條虛線處的拐點代表著隨著併發數的增加，資源利用率(cpu資源等)和吞吐量也在伴隨著遞增， 這個時候我們的響應時間有小幅度的增加，但是在可接受的範圍之內；在這個點是做容量規劃最好的參考點
（2）第二條虛線處的拐點表示隨著併發數的繼續增加，系統資源已經到達了瓶頸，吞吐量開始明顯下降，響應時間會大幅增加，也就是說已經到達了效能的瓶頸，請求佇列開始擠壓，這個時候已經嚴重影響使用者體驗或者有系統崩潰的風險。
2.1 需求分析與測試設計（效能需求目標+業務模型拆解）注：在後面的演示中，會以新系統上線的容量測試為例，目標為獲取系統最大容量
uv：或者外賣產品則集中在午飯和晚飯的2個小時時間段，假如uv為1000w/天，那麼高峰時段佔了總使用者數的80%：
1000w * 80% / (4*3600) = 每秒的併發使用者數
pv：pv可以直接對應到qps指標，好比乙個電商產品，產品分別給出了首頁、商品頁、訂單頁的pv，便可依此來進行效能測試的基準設計，例如粗略的按24小時算qps的話就是qps = pv(天)/24/3600
2、根據具體的效能測試需求，確定測試型別以及壓測的模組(web/mysql/redis/系統整體)
3、前期要與相關人員充分溝通，初步確定壓測方案及具體效能指標
4、qa完成效能測試設計後，需產出測試方案文件傳送郵件到專案組，並且再次與相關人員溝通(或者組織效能測試評審)，確認是否滿足需求
2.2、測試資料準備和構造(基於模型的資料準備)
資料的準備可以如下幾點：
2、資料表的資料填充：
可以利用jmeter的高併發通過介面來提前建立資料
3、如果是多介面，則需要結合業務場景設計請求比例：
比如使用者瀏覽主頁的pv和瀏覽商戶的比例為1：2，那麼介面的比例設計也就按照1：2來設計
2.3、效能指標預期(效能需求目標)
2.4、髮壓工具配置及指令碼編寫（壓力策略）
2.指令碼編寫
(2) 其他
3.命令啟動，jmeter本身也是軟體，也有自己的承載限制，所以真正測試過程還是要以命令列執行的方式，ui可以作為編寫和除錯指令碼使用
啟壓：./jmeter -n -t hb.jmx-l hb.jtl
2.5 測試過程（預計的前置準備過程和壓測時間點規劃）
2.6 結果分析與測試報告以上只是做了個效能測試的基礎知識鋪墊，後續在此理論基礎上，以電商業務為背景，結合docker+jmeter+influx+grafana完成乙個例項壓測與監控~
敏捷測試（6） 基於story的敏捷基礎知識
站會的目的有三個 1 周知進度 僅從使用者故事和任務的層面周知進度，任務進度只有兩種狀態 完成或未完成 完成百分比 2 周知計畫 你將會在下次會議之前做哪些工作？3 丟擲問題 哪些東西阻礙你的進度？沒有問題 意味著你能夠交付自己當前的任務，而且符合估算的時間範圍 如果遇到需要解決的問題，可以在每日立...
敏捷測試（7） 基於story的敏捷基礎知識
除需求講解意外，需要所有團隊成員參加的會議僅有兩個，分別是 迭代啟動會 和 迭代回顧會 在迭代開始之前，需要召開迭代啟動會，目的有以下兩個 明確迭代週期，即上線時間 明確迭代目標，即以什麼樣的優先順序，交付哪些story。在明確了迭代週期和上線時間後，按照前面提到的 迭代規劃 來開迭代啟動會即可，在...
關於軟體測試的一些基礎知識
1.什麼是軟體測試？軟體測試是指在規定的條件下對程式進行操作，發現程式錯誤，衡量軟體質量，驗證軟體功能是否滿足使用者需求。2.什麼是bug 如果有需求規格說明並且正確 程式與規格說明之間不匹配 當沒有需求規格說明判斷標準以使用者為準 當程式沒有實現其終端使用者合理預期的功能要求時，就是軟體錯誤 級的...