可接受的應用程式反應時間v.s. 業界標準 - David Ko的學習之旅

這是因為根本沒有業界標準. 為什麼會這樣呢? 想想你如何使用網站. 你會願意去花多久時間, 去等一個網頁被載入? 你會 ... DavidKo的學習之旅 跳到主文 歡迎光臨DavidKo在痞客邦的小天地 部落格全站分類：不設分類 相簿 部落格 留言 名片 Jun23Tue200909:30 可接受的應用程式反應時間v.s.業界標準 可接受的應用程式反應時間v.s.業界標準 Acceptableapplicationresponsetimesvs.industrystandard ScottBarber 03.13.2007 http://searchsoftwarequality.techtarget.com/tip/0,289483,sid92_gci1243574_mem1,00.html 過去六年間,還沒有一天有人停止過問我:"一個網頁的業界標準反應時間是多久?" 而這六年來,答案一直沒改變過,甚至一點修改也沒有.所以如果答案沒有改變,那為什麼我每天仍然一直被問到這個問題? 這個答案相當簡單.這是因為根本沒有業界標準.為什麼會這樣呢?想想你如何使用網站.你會願意去花多久時間,去等一個網頁被載入?你會願意去花多久時間,在線上等待去看你家庭的照片?你會願意去花多久時間,去等待報稅軟體回應整個交易已經成功了?如果在家或是在公司時,這樣等待的時間也會相同嗎?或是你在機場使用無線網路連到Internet時,你會等多久呢? 所以你真實等待的時間並不重要.重點是沒有一個數字會是可能的答案--至少直到網頁反應時間變成平均是小於0.25秒.否則在此之前,你的答案是結合了目前你對網頁反應時間的期望,以及你要藉由網路完成工作的決心有多大,兩者合在一起就是你想要的答案. 這是因為早在1980年代時,認知心理學家認為,一個action和其相對的response,之間的延遲若超過0.25秒,將會明顯地影響到人類的效能.會造成錯誤率增加,以及導致人們要切換到其他工作的機率.所以,到目前為止我所關心的,是如何超過使用者所預期的,直到我們的網頁滿足到0.25秒這個障礙,而不是去管業界標準這件事. 多年來,最普遍被引用的標準是"8-secondrule".這份報告是根據NielsenMedia,在1990年代後期的一些研究報告所產生出來的,它指出大部分Internet的使用者,在網站的反應時間是8秒內時,他們不會放棄他們試圖想要完成的工作.有趣的地方是,它並沒有考量使用者滿意的狀況,也沒有試圖去把它當作是業界標準.它所做的只是去衡量,如果人們要在網站上完成工作,所能接受的時間.而用33.6kbsmodem的狀況下,8秒是一個可以接受的答案.當然啦,如果有一個網站是8秒反應時間,而另一個對手的網站反應時間是3秒,我可以保證大家一定想都不想就去那個3秒鐘的網站. 在2006年十一月,一份新的報告顯示出"8-secondrule"已經被"4-secondrule"所取代.這篇報導的標題是"AkamaiandJupiterResearchIdentify'4Seconds'astheNewThresholdofAcceptabilityforRetailWebPageResponseTimes".(http://www.akamai.com/html/about/press/releases/2006/press_110606.html) 並且他第一行寫著: "CAMBRIDGE,MA—November6,2006--FoursecondsisthemaximumlengthoftimeanaverageonlineshopperwillwaitforaWebpagetoloadbeforepotentiallyabandoningaretailsite." 這個宣言把現存的規則的結果減半.可是我卻發現一個有趣的地方,所以我下載了整份報告加以研究,卻發現這個"新的"規則,只是根據下面這個問題,所收集到的1058份結果所歸納出來的 "Question:Typically,howlongareyouwillingtowaitforasingleWebpagetoloadbeforeleavingtheWebsite?(Selectone.) A.Morethan6seconds. B.5-6seconds. C.3-4seconds. D.1-2seconds. E.Lessthan1second." 顯然地,這份"新的規則"並沒有比十年前的Nielsenresearch,更有資格當做為業界標準.Nielsenresearch至少看起來更精準,如果沒有被有些人拿來濫用的話.這份新的報告只是簡單的說明了,在高中時遇到選擇題,我們都會採用的一個準則:"Whenyouhavenoideawhatthecorrectansweris,pickC;youmightgetlucky." 你可以自己試試看.問一下辦公室某個人這個問題,去看看他或她的答案是什麼.接著要求這個人去上網,找出一個網頁載入的時間,是他或她所講的這麼久.然後用碼表來量,看看有多靠近他或她所預估的載入時間.找10個人來做這樣的事,看看你會得到怎樣精確的結果 我已經做了很久的效能測試,因此知道網頁的使用者,其實是不了解4秒是有多長的.事實上,我敢說如果有坐在電腦面前,問他們這些網頁個別的載入時間,"大部分"的使用者是不會猜對的.並且我們發現到,實際載入的時間,比"大部份"猜錯的人,所"認為"的一個網頁所載入的時間,還要短的很多. 所以真正的問題不是"Whatistheindustrystandard?",而是"WhatresponsetimewilltheusersofmyWebsiteorapplicationfindacceptable?"真正挑戰的事情是,決定你的客戶會認為"可接受的"這件事,是既困難,又容易在短時間內變化很大的.軟體開發商不會想要經常性,去對客戶代表作做usabilitystudies,因為這是既浪費時間又浪費金錢.對大部分的人來說,即使如果他們需要,他們也沒有資源或是訓練,去處理這樣的usabilitystudies.這也就是為什麼這麼多人會閉門造車,自行宣布一個標準.所以真正的問題是,默認為一個錯誤的標準,用它來開發和發佈的網站,使得使用者對網站效能感到十分挫折.與其這樣,還不如請這些使用者坐下,試用一下系統,根據他們的感覺來決定效能是否夠好.可能同樣系統都很慢,但是遇到後者的狀況時,使用者的心情還會比較好一點. 全站熱搜 創作者介紹 kojenchieh DavidKo的學習之旅 kojenchieh發表在痞客邦留言(0)人氣() E-mail轉寄 全站分類：不設分類個人分類：PerformanceTesting此分類上一篇：為什麼我們要對效能做測試? 此分類下一篇：要多快才是夠快 上一篇：ScrumandXP的實戰經驗Ch12(2) 下一篇：Agile實務(Practices)的調查 歷史上的今天 2020:精實企業書摘-HPLaserJet的持續改善 2014:retro事件簿-agile是否有比較快的疑問 ▲top 留言列表 發表留言 文章搜尋 熱門文章 最新留言 動態訂閱 文章分類 正念(2)DevOps(13)AgileHR(1)課程介紹(12)retrospective(15)敏捷需求探索(21)自媒體(2)TOC(4)GoogleSprint(31)敏捷轉型(68)LeSS(3)KanbanExperienceReport(20)引導/教練(29)Spotify(4)Pretotyping(7)LeanStartup(22)ImpactMapping(4)AgileUX(35)Kanban(115)LeanfromtheTrenches(11)Estimation(7)Scaling&DistributedAgile(9)StandupMeeting(18)FeatureTeam(10)scrum教學(5)過敏(9)魚油(3)Hadoop(1)Scrum入門手冊(4)KanbanandScrum(44)健康(46)TDD(41)CloudComputing(1)我的Scrum新體驗(4)Innovation(14)TestingBooks/Magazine/WebSite(12)RegressionTest(6)測試管理(18)讀書心得(27)UserStory(19)ContinuousIntegration(16)Scrum(122)AgileConcept(203)勵志(44)ScrumandXP的實戰經驗(65)MSServer(3)PerformanceTesting(38)AgileTesting(41)投資理財(25)ExploratoryTesting(22)C#(1)專案管理(25)測試自動化(62)測試基本知識(108)未分類文章(37) 文章精選 文章精選 2022四月(2) 2022一月(2) 2021十二月(4) 2021十一月(3) 2021十月(1) 2021八月(3) 2021七月(1) 2021五月(1) 2021四月(1) 2021三月(5) 2021二月(4) 2021一月(4) 2020十二月(1) 2020十一月(3) 2020十月(1) 2020九月(4) 2020八月(8) 2020七月(7) 2020六月(13) 2020五月(7) 2020四月(5) 2020三月(3) 2020一月(3) 2019十二月(6) 2019十一月(4) 2019十月(2) 2019九月(3) 2019六月(1) 2019三月(6) 2019二月(7) 2019一月(4) 2018十二月(10) 2018十一月(7) 2018十月(8) 2018九月(4) 2018八月(10) 2018七月(1) 2018六月(8) 2018五月(17) 2018四月(5) 2018三月(5) 2018二月(5) 2017十二月(6) 2017十一月(2) 2017十月(9) 2017九月(2) 2017八月(1) 2017七月(6) 2017六月(1) 2017五月(4) 2017四月(3) 2017三月(6) 2017二月(8) 2017一月(6) 2016十二月(2) 2016十一月(4) 2016十月(6) 2016九月(7) 2016八月(4) 2016七月(9) 2016六月(7) 2016五月(5) 2016四月(2) 2016三月(7) 2016二月(8) 2016一月(12) 2015十二月(12) 2015十一月(8) 2015十月(10) 2015九月(14) 2015八月(17) 2015七月(16) 2015六月(13) 2015五月(13) 2015四月(13) 2015三月(15) 2015二月(12) 2015一月(14) 2014十二月(18) 2014十一月(16) 2014十月(18) 2014九月(18) 2014八月(20) 2014七月(19) 2014六月(14) 2014五月(21) 2014四月(20) 2014三月(19) 2014二月(17) 2014一月(21) 2013十二月(13) 2013十一月(4) 2013九月(5) 2013八月(6) 2013七月(3) 2013五月(2) 2013四月(1) 2013三月(8) 2013二月(4) 2013一月(2) 2012十二月(7) 2012十一月(7) 2012十月(15) 2012九月(4) 2012八月(4) 2012七月(1) 2012六月(3) 2012三月(1) 2012二月(11) 2012一月(1) 2011十二月(3) 2011十一月(4) 2011十月(1) 2011九月(10) 2011八月(4) 2011七月(2) 2011六月(3) 2011五月(10) 2011四月(3) 2011三月(4) 2011二月(7) 2011一月(8) 2010十二月(9) 2010十一月(6) 2010十月(12) 2010九月(4) 2010八月(11) 2010七月(13) 2010六月(16) 2010五月(24) 2010四月(35) 2010三月(40) 2010二月(16) 2010一月(20) 2009十二月(26) 2009十一月(25) 2009十月(26) 2009九月(27) 2009八月(23) 2009七月(29) 2009六月(26) 2009五月(29) 2009四月(29) 2009三月(31) 2009二月(25) 2009一月(26) 2008十二月(29) 2008十一月(29) 2008十月(35) 2008九月(23) 2008八月(13) 2008七月(5) 2008六月(2) 所有文章列表 新聞交換(RSS) 參觀人氣 本日人氣： 累積人氣： QRCode POWEREDBY (登入) 回到頁首 回到主文 免費註冊 客服中心 痞客邦首頁 ©2003-2022PIXNET 關閉視窗 PIXNET Facebook Yahoo! Google MSN {{guestName}} (登出) 您尚未登入，將以訪客身份留言。

亦可以上方服務帳號登入留言 請輸入暱稱(最多顯示6個中文字元) 請輸入標題(最多顯示9個中文字元) 請輸入內容(最多140個中文字元) 請輸入左方認證碼： 看不懂,換張圖 請輸入驗證碼 送出留言