再回到書中來，就容易理解為什麼說效能測試是產品測試流程的必經之路了，產品的效能好壞不但關係到產品的使用者體驗，甚至關係到客戶的電商**是否有好的使用者忠誠度，從而也影響到訂單轉化率等跟客戶盈利直接相關的指標。
已經逐漸成為有經驗的小艾，正好得到了這樣乙個機會，進入到了效能測試團隊體驗效能測試的全過程，而他面臨的恰恰也是專案遇到了年終大促。
與限時搶購的分散性不同，秒殺的訪問量幾乎是在同一時間發生的，而這樣乙個舉動對硬體及軟體毫無疑問都充滿著考驗。而現在的我們，對秒殺可以說是耳熟得很，無論是雙十一還是雙十二，**都不免會有各種秒殺，相信每個人也都有遇到秒殺剛開始，網頁就各種掛的情況，這時候不知道有多少人曾想過秒殺背後的應用服務到底出什麼問題了呢？
關於效能客戶都關注些什麼？
客戶與使用者
而產品效能好壞，往往很大程度上都影響了使用者的使用感受，因此，對於乙個應用服務的效能來說，客戶一般會關注以下幾個方面。
伺服器的吞吐量：常用的是系統每小時能處理的業務量
最大併發使用者數：在響應時間合理的情況下，能承受的併發使用者數，即系統最多能承受多少使用者同時訪問且使用者感覺不到頁面響應速度變慢
能否穩定的長期執行：除了與伺服器的硬體有關之外，與軟體本身也有很大的關係
最大資料規模：能保證正常訪問的最大容忍資料規模
伺服器後台操作是否會影響前台效能
什麼情況下會導致系統崩潰
這些效能指標相互之間並非獨立存在，而是相互影響的，某些指標的提公升可能會引起其他指標的下降，因此在測試時需要綜合考量。
尾聲
了解了效能方面客戶都關心什麼，我們就大概明白了應該用什麼方法去做效能測試，即最普通的效能測試，簡單說就是給系統壓力，看系統跑得快不快，好不好。
讓系統工作在一定的負載狀態下，把系統工作的效能指標與期望的效能指標相比較。這裡的負載包括併發使用者、使用者連續兩次操作之間的間隔時間（即思考時間）以及系統中包含的業務資料規模。
效能測試策略和方法的出發點，就是要模擬使用者對系統的訪問行為，包括併發、壓力、長時間訪問等。
小艾了解了上述的內容之後，在組長的幫助下，投入到了解如何模擬使用者的訪問行為了學習中，畢竟要想讓使用者得到最好的效能體驗，最簡單有效的方法就是模擬客戶使用產品時的各種訪問行為，從而明白產品存在哪些效能瓶頸，那麼小艾到底學到了什麼呢？請聽下回分解~
重讀《從菜鳥到測試架構師》 構建測試
上一章節中，小艾已經掌握了構建測試的基本知識，其實，構建測試也稱為構建可接受性測試 build acceptance test 一般是在每乙個測試產品生成之後，構建測試團隊執行一組最基本的測試用例，來確定做成的測試產品的質量是否達到可以交到各個測試組來進行更全面 更深入的各項測試的要求。構建測試用例...
從測試小白到測試架構師之路 軟體及其開發過程的了解
今天終於抽出來時間，記錄下個人成長哈，既然進入到軟體行業，就必須對軟體相關知識進行了解，話不多說直接進度正題。一 軟體的含義 1.1能夠完成預定功能和效能的 可執行的指令 電腦程式 1.2使得程式能夠適當的操作資訊的資料結構 1.3描述程式的操作和使用的文件 軟體 程式 資料 庫 文件 服務 二 軟...
如何從程式設計師到架構師？
程式設計師是一種比較耗腦力 比較辛苦的職業。在中國，年齡比較大的程式設計師是很尷尬的，你去投簡歷，人家一看三十幾歲了，可能就把你往後排，看看有沒有那種小年輕 能夠加班的。程式設計師一定要規劃好自己的發展道路，到了某一天，你是繼續做開發，還是做技術管理，還是做產品，還是做架構師，或者說去送外賣，跑滴滴...