效能測試策略：
1.單一效能點，多使用者測試。測試過程可以隔離測試效能場景，先單獨測試加壓每種效能需求點，比如使用者登陸，可以單獨模擬此需求，建立比如50人併發登陸的場景。但此種場景並非是使用者實際使用情況，不可能有個系統大家只是在拼命的登陸，而不作其他事情。但是，如果在做別的事情，那麼同時再有50人併發登陸的話，那這個登陸時間會大大的延長的。所以此場景的設計僅僅為了檢查這乙個模組的效能水平。
2.隔離之後，再逐步建立混合的效能場景。比如登陸的同時有人在瀏覽、查詢、寫入系統。但是此時只載入20%的負載。這一步主要是乙個整合測試，考慮各個功能模組之間是否有影響，是否有對某些資源的搶奪等問題。同時找出top time transaction
3.如果上一步沒問題了，這次就加壓100%，看看在真正我們規定的要求下，系統各項效能指標如何，同時對本次測試結果作為base line，用來效能調優之後的比較。
4.壓力測試，看系統的最大負載能力。
效能測試 效能測試步驟
針對此次庫內作業效能測試，梳理一下期間的工作流程 梳理已有的介面指令碼，確認需要做效能測試的幾個介面，即使用率高，對效能有要求的幾個主要介面。結合頁面的操作，和確認的介面，梳理具體的業務邏輯 同時，請開發人員部署了測試環境。測試環境的伺服器指標，盡量和生產環境一致。部署的時候，負載均衡等情況也盡量和...
效能測試之前端效能測試
本次總結總共分為以下部分 1.如何衡量乙個系統是否要做壓測 2.壓測的準備過程 3.壓測工具選擇 4.壓測資料以及報告結果相關 1.如何衡量乙個系統是否要做壓測 首先需要衡量乙個系統是否需要壓測，從以下角度考慮 從兩個角度進行分析 a.業務角度 明確系統是對內使用還是對外使用，使用人數是多少，如果使...
RMAN備份測試
通過前面的若干示例，我們已經了解並嘗試了rman備份的一些命令，但是在實際環境中，不可能每次備份都要求dba一條命令一條命令來敲 dba手指頭都痙攣啦，老闆看著更是肉疼，早知道就是打幾個字母，雇個打字的，成本不是更低麼 通過前面章節的學習我們立志一定要優化的幹活，所以我們應該寫好一段指令碼，然後放在...