qileilove

          blog已經轉移至github,大家請訪問 http://qaseven.github.io/

          MySQL數據庫性能優化之存儲引擎選擇

           InnoDB

            1、特性

            具有較好的事務支持:支持4個事務隔離級別,支持多版本讀

            行級鎖定:通過索引實現,全表掃描仍然會是表鎖,注意間隙鎖的影響

            讀寫阻塞與事務隔離級別相關

            具有非常高效的緩存特性:能緩存索引,也能緩存數據

            整個表和主鍵以Cluster方式存儲,組成一顆平衡樹

            所有Secondary Index都會保存主鍵信息

            2、適用場景

            需要事務支持(具有較好的事務特性)

            行級鎖定對高并發有很好的適應能力,但需要確保查詢是通過索引完成

            數據更新較為頻繁的場景

            數據一致性要求較高

            硬件設備內存較大,可以利用InnoDB較好的緩存能力來提高內存利用率,盡可能減少磁盤 IO

            3、最佳實踐

            主鍵盡可能小,避免給Secondary index帶來過大的空間負擔

            避免全表掃描,因為會使用表鎖

            盡可能緩存所有的索引和數據,提高響應速度

            在大批量小插入的時候,盡量自己控制事務而不要使用autocommit自動提交

            合理設置innodb_flush_log_at_trx_commit參數值,不要過度追求安全性

            避免主鍵更新,因為這會帶來大量的數據移動

            NDBCluster

            1、特性

            分布式:分布式存儲引擎,可以由多個NDBCluster存儲引擎組成集群分別存放整體數據的一部分

            支持事務:和Innodb一樣,支持事務

            可與mysqld不在一臺主機:可以和mysqld分開存在于獨立的主機上,然后通過網絡和mysqld通信交互

            內存需求量巨大:新版本索引以及被索引的數據必須存放在內存中,老版本所有數據和索引必須存在與內存中

            2、適用場景

            具有非常高的并發需求

            對單個請求的響應并不是非常的critical

            查詢簡單,過濾條件較為固定,每次請求數據量較少,又不希望自己進行水平Sharding

            3、最佳實踐

            盡可能讓查詢簡單,避免數據的跨節點傳輸

            盡可能滿足SQL節點的計算性能,大一點的集群SQL節點會明顯多余Data節點

            在各節點之間盡可能使用萬兆網絡環境互聯,以減少數據在網絡層傳輸過程中的延時

            注:以上三個存儲引擎是目前相對主流的存儲引擎,還有其他類似如:Memory,Merge,CSV,Archive等存儲引擎的使用場景都相對較少,這里就不一一分析了,如果有朋友感興趣,后面再補充吧。

            MySQL 的存儲引擎可能是所有關系型數據庫產品中最具有特色的了,不僅可以同時使用多種存儲引擎,而且每種存儲引擎和MySQL之間使用插件方式這種非常松的耦合關系。

           

            由于各存儲引擎功能特性差異較大,這篇文章主要是介紹如何來選擇合適的存儲引擎來應對不同的業務場景。

            系列的第五篇文章:MySQL數據庫性能優化之存儲引擎選擇

            系列的第四篇文章:MySQL數據庫性能優化之SQL優化

            系列的第三篇文章:MySQL數據庫性能優化之索引優化

            系列的第二篇文章:MySQL 數據庫性能優化之表結構優化

            系列的第一篇文章:MySQL 數據庫性能優化之緩存參數優化

            MyISAM

            1、特性

            不支持事務:MyISAM存儲引擎不支持事務,所以對事務有要求的業務場景不能使用

            表級鎖定:其鎖定機制是表級索引,這雖然可以讓鎖定的實現成本很小但是也同時大大降低了其并發性能

            讀寫互相阻塞:不僅會在寫入的時候阻塞讀取,MyISAM還會在讀取的時候阻塞寫入,但讀本身并不會阻塞另外的讀

            只會緩存索引:MyISAM可以通過key_buffer緩存以大大提高訪問性能減少磁盤IO,但是這個緩存區只會緩存索引,而不會緩存數據

            2、適用場景

            不需要事務支持(不支持)

            并發相對較低(鎖定機制問題)

            數據修改相對較少(阻塞問題)

            以讀為主

            數據一致性要求不是非常高

            3、最佳實踐

            盡量索引(緩存機制)

            調整讀寫優先級,根據實際需求確保重要操作更優先

            啟用延遲插入改善大批量寫入性能

            盡量順序操作讓insert數據都寫入到尾部,減少阻塞

            分解大的操作,降低單個操作的阻塞時間

            降低并發數,某些高并發場景通過應用來進行排隊機制

            對于相對靜態的數據,充分利用Query Cache可以極大的提高訪問效率

            MyISAM的Count只有在全表掃描的時候特別高效,帶有其他條件的count都需要進行實際的數據訪問

           InnoDB

            1、特性

            具有較好的事務支持:支持4個事務隔離級別,支持多版本讀

            行級鎖定:通過索引實現,全表掃描仍然會是表鎖,注意間隙鎖的影響

            讀寫阻塞與事務隔離級別相關

            具有非常高效的緩存特性:能緩存索引,也能緩存數據

            整個表和主鍵以Cluster方式存儲,組成一顆平衡樹

            所有Secondary Index都會保存主鍵信息

            2、適用場景

            需要事務支持(具有較好的事務特性)

            行級鎖定對高并發有很好的適應能力,但需要確保查詢是通過索引完成

            數據更新較為頻繁的場景

            數據一致性要求較高

            硬件設備內存較大,可以利用InnoDB較好的緩存能力來提高內存利用率,盡可能減少磁盤 IO

            3、最佳實踐

            主鍵盡可能小,避免給Secondary index帶來過大的空間負擔

            避免全表掃描,因為會使用表鎖

            盡可能緩存所有的索引和數據,提高響應速度

            在大批量小插入的時候,盡量自己控制事務而不要使用autocommit自動提交

            合理設置innodb_flush_log_at_trx_commit參數值,不要過度追求安全性

            避免主鍵更新,因為這會帶來大量的數據移動

            NDBCluster

            1、特性

            分布式:分布式存儲引擎,可以由多個NDBCluster存儲引擎組成集群分別存放整體數據的一部分

            支持事務:和Innodb一樣,支持事務

            可與mysqld不在一臺主機:可以和mysqld分開存在于獨立的主機上,然后通過網絡和mysqld通信交互

            內存需求量巨大:新版本索引以及被索引的數據必須存放在內存中,老版本所有數據和索引必須存在與內存中

            2、適用場景

            具有非常高的并發需求

            對單個請求的響應并不是非常的critical

            查詢簡單,過濾條件較為固定,每次請求數據量較少,又不希望自己進行水平Sharding

            3、最佳實踐

            盡可能讓查詢簡單,避免數據的跨節點傳輸

            盡可能滿足SQL節點的計算性能,大一點的集群SQL節點會明顯多余Data節點

            在各節點之間盡可能使用萬兆網絡環境互聯,以減少數據在網絡層傳輸過程中的延時

            注:以上三個存儲引擎是目前相對主流的存儲引擎,還有其他類似如:Memory,Merge,CSV,Archive等存儲引擎的使用場景都相對較少,這里就不一一分析了,如果有朋友感興趣,后面再補充吧。

          posted @ 2012-05-09 10:04 順其自然EVO 閱讀(1473) | 評論 (0)編輯 收藏

          如何在15分鐘內掌握JavaScript面向對象編程

               摘要: 導讀:經??吹揭恍㎎avaScript的代碼臟亂得無法理解,到處都是屬性和方法,或者一個循環套著一個循環。但如果使用面向對象就能很好的理清代碼,并方便理解和修改代碼。如果你不希望自己的代碼只有上帝理解的話,就請盡量考慮使用面向對象的模式?! ∽g文正文:  到處都是屬性、方法,代碼極其難懂,天哪,我的程序員,你究竟在做什么?仔細看看這篇指南,讓我們一起寫出優雅的面向對象的JavaScript代碼吧!...  閱讀全文

          posted @ 2012-05-09 10:02 順其自然EVO 閱讀(802) | 評論 (2)編輯 收藏

          什么讓驗收測試的簽收時間不斷推遲?

            做項目的時候,我們都有很好的計劃,也在不斷的強化風險承受力等等~~~ 但事實上,Devolpment完了,到了test和UAT的時候了,通常時間處于這個階段的時間都比計劃安排或者領導認為需要的時間要長的多。程序員一次又一次的收到bug report 和new changes。這里面new changes 當然是新添加的修改了,可以要客戶再算錢的,bug就不是了。優秀的程序員團隊的code中一般的range異常阿,null異常阿,分支阿,算法阿等等真正的技術bug是很少的。最常見的,也最難修改的是logic error和實現情況與真正需求不一致。

            最讓整個團隊懊惱的就是實現和真正需求不一致的情況,程序員抱怨:需求文檔明明就是這么寫的,我這么做是對的。需求分析人員則抱怨更多,我明明是這么寫的,怎么他們做成了那個樣子?。靠蛻舢敵蹙褪沁@么說的啊,怎么現在到測試了,他們說不是這個意思啊,都快變的面目全非了?.......

            總結一下個人對于實現與需求不一致現象出現的原因:

            1、需求文檔表述不明確,這個包含2個意思,一是需求條款含義模糊;二是需求信息不全面。這導致分析人員與設計人員理解出現較大偏差。而且,一般公司如果有專業的分析人員和職位,他們做完一個項目的分析后可能馬上就接收下一個項目的需求了,這導致在開發中間需要需求再討論和澄清的時候,分析員可能自己都不能完全確定需求或者表示錯誤了。

            2、需求挖掘不深,記錄的未能表達客戶真正需要的。這通常表現為將產品拿到客戶那里測試時,客戶沒看完幾眼,就說:這個***怎么是這樣的? 這個報表要加*** ........

            3、分析人員未能引導客戶那邊決策人員與實際操作人員的需求統一。這表現為時常的,我們按照客戶項目負責人的表述完成了需求分析。最后UAT的時候幾乎都是由實際的操作人員參入的,于是很多操作人員開始7嘴8舌的表述自己的要求 ??蛻舻捻椖控撠熑嗽谶@時候表現出極高的尊重下屬意見的素質:這個是他們用的,當然他們都說是那樣,當然要改成那個樣子了,不然我買來干嘛~~~~ 云云

            4、不斷的發現問題和小修小改,導致最后如果要查詢一個部分的最終詳細需求,可能需要參考n個相關文檔.人之常情,即使假設所有人都知道這些文檔并能獲得,那也不如去找一個人問,所以問下 程序經理/分析人員/項目經理,而對被改動過的需求,他們(被問者)是否都對修改了然于胸呢?就算他/她很明確,他/她的表述力如何?

            出現test和UAT不斷延期的狀況后影響是極大的,幾乎你見到的每個人都在抱怨.領導開始不滿,怎么拖了這么久阿,原計劃將人馬投入下一個項目的計劃不得不變更了.項目成本不斷增加,而項目的總訂單額倒不一定增加了多少.程序員開始在bug-fix的過程中情緒低落,因為項目拖的久了,修改的東西有沒有新意,而且對所有人都一樣的會催化情緒的是,要做的(實現的)變來變去.分析人員面對著壓力,但很多人會把責任推到程序員和客戶.項目經理最為倍受煎熬.一個現象也可能出現了: 加班,加班,再加班.....

            那么我們應該怎樣來減少這種事件的概率呢?這里列舉1,2所想:

            1、需求表述一定要保留文字描述,不要以為使用了OOA和UML后就不寫描述性需求了。

            2、需求表述每項盡量簡短明確,意思單一,進出唯一。

            3、分析人員要保管好未整理前的需求調研材料。

            4、分析人員對需求的理解盡量要達到與分析人員每一項都一樣,可以采用講解,復述,確認等手段。

            5、分析人員最好能在詳細設計文檔初步完成后和設計人員一起討論確認詳細設計。

            6、保持紀錄和維護需求文檔.這一點非常重要。

          posted @ 2012-05-09 09:52 順其自然EVO 閱讀(196) | 評論 (0)編輯 收藏

          LR 細節解析,為什么LR腳本會去訪問“腳本中不存在的“資源?

            結論

            到這里結論其實也就出來了。(結論只針對HTML-Based Mode錄制方式)

            HTML頁面中的資源,如頁面里寫的<img>(跟是不是在表格中無關...),是不會顯示在腳本中的。

            而外部鏈接中的資源,如<link type="text/css>連接的CSS文件中使用的圖片,是會通過EXTRARES屬性顯示在腳本中的。

            運行上面這個腳本,Replay Log中會顯示:

          Action3.c(8): Downloading resource http://search.thunisoft.com/skins/default/images/bg_top.gif (specified by argument number 9)     [MsgId: MMSG-26577] 
          Action3.c(8): Downloading resource http://search.thunisoft.com/skins/default/images/nav_bg.gif (specified by argument number 11)     [MsgId: MMSG-26577]
          Action3.c(8): Downloading resource http://search.thunisoft.com/skins/default/images/nav_right.jpg (specified by argument number 13)     [MsgId: MMSG-26577]
          Action3.c(8): Downloading resource http://search.thunisoft.com/skins/default/images/search_m.gif (specified by argument number 15)     [MsgId: MMSG-26577]
          Action3.c(8): Downloading resource http://search.thunisoft.com/skins/default/images/button02.gif (specified by argument number 17)     [MsgId: MMSG-26577]
          Action3.c(8): Downloading resource http://search.thunisoft.com/skins/default/images/nav_r.gif (specified by argument number 19)     [MsgId: MMSG-26577]
          Action3.c(8): Downloading resource http://search.thunisoft.com/skins/default/images/button01.gif (specified by argument number 21)     [MsgId: MMSG-26577]
          Action3.c(8): Downloading resource http://search.thunisoft.com/skins/default/images/nav_l.gif (specified by argument number 23)     [MsgId: MMSG-26577]
          Action3.c(8): Downloading resource http://search.thunisoft.com/skins/default/images/search_l.gif (specified by argument number 25)     [MsgId: MMSG-26577]
          Action3.c(8): Downloading resource http://search.thunisoft.com/skins/default/images/search_r.gif (specified by argument number 27)     [MsgId: MMSG-26577]

            細心的人可以發現,這個日志和第一步實驗中的不一樣呢。再次對比上面寫出的兩種Replay Log,可以發現一個是"Found resource ... in HTML ...",一個是"Downloading resource ..."(標記藍色兩處)

            這樣也可以解釋了。

            HTML文件內部的資源,不需要顯示在腳本中就可以下載,因為會在訪問這個頁面時“發現”。

            而外部鏈接的資源,必須在腳本中顯式寫出,才會去“下載”。

            所以EXTRARES屬性下面的資源,只要注釋掉相應的腳本,就可以避免該請求。

            而HTML頁面文件中的資源,則只能通過修改MODE="HTTP"屬性,或者改為URL-Based Mode錄制方式,才能避免請求。

            說到這,基本都清楚了,最后再翻一下官方文檔(Function Reference)吧。

          web_url

          EXTRARES:
          A demarcation parameter indicating that the next parameter will be a list of resource attributes.

          List of Resource Attributes:
          A list of resources generated by non–HTML mechanisms in the Web page. These include the resources requested by Javascript, ActiveX, Java applets and Flash. VuGen's Recording Options allow these elements either to be recorded within the current script step (the default mode) or recorded as separate steps (see "Recording in HTML–Based Mode" in the VuGen Online Book).

            再次驗證了我們的結論,EXTRARES中只顯示非HTML文件中的資源。

            問題描述

            同事遇到的一個問題,LR執行性能測試腳本時,總報出錯誤,無法訪問一個圖片的地址,但腳本中明明沒有對該資源的請求。

          Action4.c(12): Warning -27796: Failed to connect to server "10.11.204.35:80": [10060] Connection timed out      [MsgId: MWAR-27796]Action4.c(12): Warning -26000: Empty or no response for URL=http://10.11.204.35/iwebfiles/yqlj/26/107/10/4/361.gif      [MsgId: MWAR-26000]

            我查了一下,確實腳本中看不出問題,所有不相干的請求都刪掉了,頁面的請求中EXTRARES屬性中的資源列表也都刪掉了,只保留了主頁面的請求。但只要一執行,就會去訪問那個無法連接的資源。

            分析與實驗

            查看了該頁面的源文件,確實可以看到那個有問題的圖片鏈接,是寫在一個表格里的。于是很自然的猜測,是不是表格中的資源,錄制不到腳本中、但是又訪問了呢?

            這種問題,其實確信只要把錄制方式轉換為URL-Based Mode就肯定能解決,因為可以顯式的錄下所有請求。但還是想把HTML-Based Mode下的問題解決,于是做了一些測試。

            模擬那個問題頁面,創建測試用頁面。特意寫了兩個圖片資源做對比,一個普通的圖片,一個是放置在表格中的圖片超鏈接,測試訪問這個頁面錄制的腳本。

          <html> 
              <head>
                  <meta http-equiv="content-type" content="text/html;charset=gb2312">
                  <title>測試頁面</title>
              </head>
           
              <body>
                  <p>
                  普通的圖片
                  <img src=http://172.16.1.3/bbs/attachments/month_1110/20111008_3f1828e9b28294cb7f23Wu3TykOUV9RM.jpg width="126" height="45" border="0"/>
                  </p>
                  <p>
                      <table border=2>
                      <tr>
                          <td>
                          表格中的圖片跳轉鏈接
                          </td>
                      </tr>
                      <tr> 
                          <td>
                          <a href=http://172.16.1.3/bbs/viewthread.php?tid=44597&extra=page%3D1###zoom target="_blank"><img src=http://172.16.1.3/bbs/attachments/month_1110/20111008_67cebe2ca85b66fe580cGUGESOM05AWo.jpg width="126" height="45" border="0"/></a>
                          </td>
                    </tr>
                      </table>
                  </p>
              </body>
          </html>

            創建如上的HTML,放到TOMCAT的ROOT目錄中,則可以通過tomcat訪問該頁面。

            測試:

            1、默認的HTML-Based Mode方式進行錄制,只錄到一個請求。

          web_url("test_mode.html", 
                  "URL=http://172.16.6.17:8080/test_mode.html",
                  "Resource=0",
                  "RecContentType=text/html",
                  "Referer=",
                  "Snapshot=t12.inf",
                  "Mode=HTML",
                  LAST);

            腳本中看不到對資源的請求,但實際運行時,還是會去獲取兩個圖片資源。通過Replay Log可以看到請求的證據:

          Action_HTML.c(7):Found resourcehttp://172.16.1.3/bbs/attachments/month_1110/20111008_3f1828e9b28294cb7f23Wu3TykOUV9RM.jpg in HTML http://172.16.6.17:8080/test_mode.html     [MsgId: MMSG-26659]
          Action_HTML.c(7): Found resource http://172.16.1.3/bbs/attachments/month_1110/20111008_67cebe2ca85b66fe580cGUGESOM05AWo.jpg in HTML http://172.16.6.17:8080/test_mode.html     [MsgId: MMSG-26659]

           2、URL-Based Mode錄制方式,可以錄制到所有的請求,包括一個頁面請求,兩個圖片請求。

          web_url("test_mode.html",  
                  "URL=http://172.16.6.17:8080/test_mode.html", 
                  "Resource=0", 
                  "RecContentType=text/html", 
                  "Referer=", 
                  "Snapshot=t13.inf", 
                  "Mode=HTTP", 
                  LAST);

              web_concurrent_start(NULL);

              web_url("20111008_3f1828e9b28294cb7f23Wu3TykOUV9RM.jpg", 
                  "URL=http://172.16.1.3/bbs/attachments/month_1110/20111008_3f1828e9b28294cb7f23Wu3TykOUV9RM.jpg", 
                  "Resource=1", 
                  "RecContentType=image/jpeg", 
                  "Referer=http://172.16.6.17:8080/test_mode.html", 
                  "Snapshot=t14.inf", 
                  LAST);

              web_url("20111008_67cebe2ca85b66fe580cGUGESOM05AWo.jpg", 
                  "URL=http://172.16.1.3/bbs/attachments/month_1110/20111008_67cebe2ca85b66fe580cGUGESOM05AWo.jpg", 
                  "Resource=1", 
                  "RecContentType=image/jpeg", 
                  "Referer=http://172.16.6.17:8080/test_mode.html", 
                  "Snapshot=t15.inf", 
                  LAST);

              web_concurrent_end(NULL);

            對比兩種錄制方式可以發現,對主頁面的請求,兩個腳本的唯一差別就在Mode屬性為"HTML"還是"HTTP"(代碼中標記黃色處)。通過修改測試1(HTML-Based Mode),可以很容易的獲得以下信息:

            如果MODE="HTML",那么訪問頁面的請求,會自動去請求頁面上的資源。

            如果MODE="HTTP",那么會只請求這個頁面的HTML文件。

            但熟悉LR的人又肯定記得,在默認的HTML-Based Mode錄制模式下,web_url腳本中應該會記錄所請求的資源文件啊?在EXTRARES屬性后經常會看到"Url=/image/test.jpg"這樣的語句,那為什么出現問題的那個頁面,和我們的測試頁面錄下來的腳本確實沒記錄資源文件呢?

            要查明這點很容易,只要隨便找一個網站錄制一下,去看看腳本中記錄的資源文件有什么特點就知道了。

            用我們公司的搜索平臺做一下實驗,錄制主頁面如下。果然得到了我們期望的EXTRARES屬性,下面列出了很多資源文件。

          web_url("search.thunisoft.com",  
                  "URL=http://search.thunisoft.com/", 
                  "Resource=0", 
                  "RecContentType=text/html", 
                  "Referer=", 
                  "Snapshot=t16.inf", 
                  "Mode=HTML", 
                  EXTRARES, 
                  "Url=/skins/default/images/bg_top.gif", ENDITEM, 
                  "Url=/skins/default/images/nav_bg.gif", ENDITEM, 
                  "Url=/skins/default/images/nav_right.jpg", ENDITEM, 
                  "Url=/skins/default/images/search_m.gif", ENDITEM, 
                  "Url=/skins/default/images/button02.gif", ENDITEM, 
                  "Url=/skins/default/images/nav_r.gif", ENDITEM, 
                  "Url=/skins/default/images/button01.gif", ENDITEM, 
                  "Url=/skins/default/images/nav_l.gif", ENDITEM, 
                  "Url=/skins/default/images/search_l.gif", ENDITEM, 
                  "Url=/skins/default/images/search_r.gif", ENDITEM,
                  LAST);

            分析一下頁面的源文件,搜索腳本中出現的各個圖片名,居然發現一個都找不到!而源文件中出現的圖片文件,在腳本中又都沒記錄。

            那么繼續尋找腳本中圖片的來源吧。其實到這應該很自然的想到了CSS文件了吧,于是隨著源文件中的<link>找到連接文件,果然EXTRARES中的所有資源文件都找到了。

          posted @ 2012-05-09 09:48 順其自然EVO 閱讀(529) | 評論 (0)編輯 收藏

          說說軟件的質量控制

           引用:

            軟件質量得控制牽涉到很多變量。關鍵是在每個步驟都需要管理和控制。需要規范化整個軟件開發過程。

            1、需求得時候做需求評審。但是怎樣引導客戶來提出確切得需求,就需要很好得溝通技巧,在客戶需求了解得前提下,針對開發項目所做得技術需求,應該進行評審。

            2、概要設計時體系結構的評審、多次討論。并保證足夠的時間和精力來充分討論所做的概要設計是否真正滿足需求。不能以進度太緊等借口將概要做的馬馬乎乎,直接開始代碼編寫。(這也是以前做項目時最常犯的毛病。)項目經理必須有膽量有信心頂住老板的壓力,很多BOSS衡量進度就會問,你編了幾行代碼了?怎么還在這里什么都沒做?

            3、詳細設計盡可能統一、規范。編碼時要有統一的編碼規則。命名規則等約束。即使天才程序員也應遵循適當的規范。否則大家以后在維護天才的代碼的同時,肯定會在心里大罵。

            4、測試要在需求和設計階段就開始,不能等到編碼結束再進行。再編碼過程中的單元測試應得到重視,程序員之間的交換測試可以取得一定的效果。發現問題越早,麻煩越少。

            5、對重要的功能實現代碼做CODEREVIEW。為避免流于形式,在會前要充分協調,作好準備。

            6、版本控制。需求變動控制。適當地使用工具進行版本和需求變更的控制。避免后期版本混亂,做無用功。

            7、當然還有文檔,要做就做規范,做踏實。應付檢查和交差的文檔不做也罷,浪費時間而已。文檔太難控制的話,在編碼時作好注釋也可作為一種方法。

            而現實中是:

            1、產品中沒有白盒測試的概念,從最底層代碼開始,經過多年的修改,已經是千瘡百孔。具體一個函數有多少隱含的問題要進行測試、統計一下。

            2、代碼不進行重構,公司領導不重視重構,導致代碼腐爛很嚴重。很簡單的事實,一個配置變量在多處進行維護著 ,一旦進行修改,就要去修改很多處。再加上模塊充斥著幾千行的類和幾千行的文件。最大的一個類triadapter達到了16258行,welldatamanager 17055行,類使用起來倒是很方便,要數據相關的東西,你只要找welldatamanager就好了,然后你就在幾萬行的代碼中徘徊吧。其他的代碼重復、過度依賴等等問題就更多了。

            3、黑盒測試力度不夠。七八個人編碼,兩個人進行測試。并且隨著時間長了,固定的兩個人對軟件產生了習慣性,導致很多地方測試不到。

            4、沒有規范的軟件開發流程。軟件設計、測試用例編寫

            5、測試時間不足,軟件發布前一周還在進行軟件功能的開發。

            6、需求不穩定。需求反復修改帶來的問題。比如繪制刻度的時候,現實垂直畫、后來水平畫、再后來還是垂直畫

          posted @ 2012-05-09 09:31 順其自然EVO 閱讀(173) | 評論 (0)編輯 收藏

          把你的軟件測試用例當作一幅畫

            Kevin Fjelsted是一個盲人,他曾寫了一篇文章《A Brief History of the Accessibility of Computers by Blind People》,收錄在《Amplifying Your Effectiveness》一書中。文中從一個盲人的視角描述了幾十年來計算機的演進和變化。

            我對Kevin所描述的一個小細節很感興趣:由于看不見,Kevin經常聽別人為他描述一些圖畫或者畫面。他發現,絕大部分人描述一幅畫的時候,實際上是在描述一些畫的特征,比如“畫里有三個人”、“這是一副關于房子的畫”。人們很少會描述畫的細節部分,這就為聽者留下了廣泛的思考和遐想空間。

            當你用文字表述一件事情或一個事務的時候,不論你用多少文字、多么精雕細琢,當讓接收者親自去體驗這件事情的時候,比如親自用眼睛看這幅畫、或者親自動手去實驗一下,接收者總是會有新的感受、會發現一些文字之外的東西。這就是一副圖畫可能勝過萬語千言的道理了。

            對照我們的測試,寫作測試用例的時候,不就是試圖用文字向測試執行人員傳達測試設計人員的想法嗎?從傳遞者的角度,也許你期望不同的執行人員拿到這個用例,其執行結果都是一樣的,希望測試效果受測試執行人員經驗的影響降到最低,因此你試圖準確而詳細地描述每一個步驟。然而你的測試用例是不可能寫得事無巨細的,因為不會有那么多的時間允許你這么做(假如你真的有這么多的時間,我倒建議你多做做探索性測試、多想想更有價值的測試內容);另外一方面,即使真的給你這么多時間寫詳盡的測試用例,你仍然無法保證囊括每一個與之相關的細節。從接收者的角度,優秀的測試執行人員閱讀測試用例,就要像欣賞一幅畫一 樣,不僅僅靠聽--這樣只能接到別人描述的表面特征,更重要的是靠看--用你的眼睛去觀察,去想一想設計人員是怎么想的?設計這個用例的目的是什么?為什么要這樣設計用例?我怎樣測試才能保證最優的測試效果?和用例相關的部分哪些也值得我關注?哪些是我所知道的重要信息但用例卻沒有提到?我應該以怎樣的順序執行這些用例為佳?我以大概怎樣的進度執行這些用例比較合適?最重要的是靠動手--用你的心去思考,當你拿到一份待執行的用例,如果上述問題,你通過審視用例,就基本了然于胸,那很好。如果不是這樣,比如你對被測特性還不大了解,也沒有關系,你可以在執行用例的過程中進一步思考這些問題,通過動手操作,你得到了被測對象的一些最真實的反饋,你對測試用例有了更深刻的認識,你也在隨時調整著自己的測試策略。

            所以,傳統的腳本化測試(Scripted Testing)方法,即先花一段時間設計測試用例、再依據用例去執行的測試方法,不僅僅對測試設計人員有很高的要求(這里體現了大量的創造性的勞動),同時對測試執行人員也提出了相當高的要求:你得通過測試用例盡可能準確猜測出測試設計人員的心思,還得高于測試設計人員,找到測試用例文字以外的被忽略的但同時也是很重要的信息 --除非你不想得到更好的測試效果。所以測試執行也是體現了大量的創造性思維的勞動。記得昨日在某一ISTQB-FL課程研討會上,某位講師講到了一頁膠片,膠片上赫然把測試執行等之后的環節歸為“機械式的活動”,而把之前的一系列測試設計活動歸為“創造性活動”,如果你的測試執行都是工具在自動化的做,也許這樣分類是說得通的吧。

            很多組織都過分地看重測試用例,認為測試用例是測試人員最核心的資產,讓最優秀的人專職設計測試用例(他們從不或很少做測試執行了),花大量的時間去創建并維護這些用例,這些前端的活動投入非常大。而在最后一段路程,投入反而不那么大了:請一些缺乏經驗的測試人員或者干脆雇傭一些對特性不熟的外包人員,依據用例做測試執行即可。當版本發布,用戶反饋一些問題后,開始分析這些問題為什么會漏測,準確地說,應該是分析為什么會漏測試設計,因為鮮有人關注測試執行環節能力的提升。人們開始在測試設計階段運用更多、更復雜的測試設計方法,開始添加更冗長的測試設計流程,開始采用更為詳細要求的測試設計模板。。。

            我時常聽到來自測試設計人員的求助,希望我告訴他們“如何才能提升測試用例的有效性?”“如何確保我設計的用例漏測率最低?” 在他們心中,很有責任感地認為:測試漏測,首先是我沒有設計好的緣故。我常常會告訴這些測試設計人員:單單依靠測試用例沒有必要也不可能發現大部分的bug,很多bug要依賴執行人員在測試執行階段發現,這是正常的測試現象--你不可能要求盲人通過聽得來的對一副畫的理解和一個正常人通過看對一副畫的理解一致;我不建議測試設計人員長期不做測試執行,不建議測試設計和測試執行的分離,如果你的組織還沒有辦法做到這一點,請你--測試設計人員--一定要時常和測試執行人員溝通,向他請教對你的用例的看法,實時收到反饋信息,調整你的設計;過分重視測試設計而忽視測試執行,就如同“行百里者半九十”一樣,最終的測試效果很可能會輸在“測試的最后一公里”上。

            探索性測試也許就是看中了人在測試中發揮的作用要大于文檔在測試中發揮的作用這一點吧。

          posted @ 2012-05-09 09:29 順其自然EVO 閱讀(205) | 評論 (0)編輯 收藏

          如何讓軟件測試更理性?

            一、前二天在寫一份PPT,看到波普爾哲學:

            卡爾.波普爾的哲學:科學理論和人類所掌握到的一切知識,都不過是推測和假想,人在解決問題的過程中不可避免地摻入了想象力和創造性,人們只能依靠僅有的數據來證明一條科學理論。這一“可錯性”原則所推演出的“真偽不對稱性”(真不能被證明,只有偽可以被證明)。

            二、軟件測試是一份非理性的職業

            1、軟件測試能證明軟件存在Bug,不能證明軟件不存在Bug。

            2、軟件測試無止境,但測試周期有嚴格限制。

            3、軟件質量是一步一步積累、提高的。

            4、《軟件測試的藝術》,雖然當前還是很苦逼的職業。

            三、舉例個人經歷過的3個不同行業的故障

            ● 故障:

            1、2008年,同一個版本,上海、成都同時割接(通信行業專有說法)新版本,成都用戶投訴,手機不能訪問網站,上海正常。

            2、2011年,新版本(金融行業)上線后,4個用戶扣款失敗。

            3、2012年,版本(團購)發布后商品價格設置為19.9,顯示變成18.89。

            ● 原因:

            1、成都的無線信號比上海的差,網絡大量重發包,導致句柄耗盡。

            2、新版本部署過程中,有4個正在扣款的任務;部署完成后,補償處理扣款任務失敗。接口有一個備注參數調整(英文->中文),支付方校驗前后參數不一致,扣款失敗。

            3、19.9–>18.99,Java的浮點計算精度丟失。

            ● 總結:特定環境、特定用戶、特定場景下發生的bug,測試人束手無策。

            四、如何讓測試更理性

            ● 系統實現透明–>代碼質量提高

            1、告別黑盒。

            2、學習代碼、框架,理解實現(一個月)。

            3、code review開發代碼(長期)。

            4、充分了解與外部的交付細節。

            5、促進代碼質量(長期)

            ● 測試設計更全面–>自動化持續積累

            1、擁有:測試理論 + 業務知識 + 系統實現。

            2、用最少的用例達到業務覆蓋。

            3、用最多的思考,追求場景的豐富。

            4、長期積累,如果實現自動化更佳。

            五、做到什么程度才理性

            1、本身就是一個非理性的職業,沒有答案。

            2、測試覆蓋率要多少?缺陷密度要多少?轉測試標準要如何?code review要多少?自動化率要多少?探索性測試多少?沒有答案。

            3、根據公司、產品、團隊情況,做到當前的理性就可以,慢慢積累向更理性努力。

            4、不過,如果一個人堅持理性主義,那么他本身就是有非理性主義因素的。

          posted @ 2012-05-09 09:28 順其自然EVO 閱讀(181) | 評論 (0)編輯 收藏

          軟件測試自動化

            最近公司在搞大規模弄自動化測試,所以今天想來談談測試自動化這個問題,當然我說的“測試自動化”跟“自動化測試”是不同概念,一樣的字,不同的順序。

            所謂的“自動化測試”,一般是說用一些工具來幫助測試,比如LoadRunner可以幫忙測試負載,QTP可以幫忙做功能測試,當然很多公司還自己寫一些腳本做單元測試。這些工具的幫忙,可以極大地提高公司的測試效率,從而可以解放很多資源去做更加復雜、高級的測試。(所以“自動化測試”只是一個工具或者技術)

            而所謂的“測試自動化”,主要是說我們的測試流程,應該怎樣來充分地結合各種工具/系統(測試管理工具、自動化測試工具等等工具/系統),使得這個測試流程更加合理、更加高效。前面說的LoadRunner這類“自動化測試”工具對于“測試自動化”而言只是一個幫助因素。(所以“測試自動化”是一個方向,一個理論,一門科學研究)

            在像LoadRunner這類工具出現之前,其實我們對于“測試自動化”的理論早已存在,出現的原因是由于軟件發展速度太快,帶來了越來越多光靠人力難解決的問題,比如:

            1、性能問題:很多軟件都是很多人一起使用的,比如股票系統,可能會幾百萬、幾千萬人在用,但是股票系統開發公司不可能用人力來模擬這么多人一起使用

            2、功能問題:軟件功能和邏輯是越來越多、越來越復雜,但是有不少舊的邏輯其實一直沒怎么變,比如新建項目,備份項目等操作,但是這些雖然不變化,但是在每個Release時,總是需要測試的,這樣子,就需要人力和時間了

            3、變更問題:很多功能雖然表面上看起來樣子沒啥變化,但是其實內在邏輯什么都可能在不斷變化,優化算法啊,修Bug,都可能帶來改變,怎么去保證能Catch到每次改變呢?這個是問題。

            4、……

            就這樣子,大家為了解決這種問題,推出了各種各樣的工具,而且也解決地很不錯,不過其實很多公司還是繼續存在著問題,什么原因呢?過度地認為工具能幫忙解決一切,整天叫囂著工具代替人,而忽視了一個重要因素:人的思維。

            我們知道工具雖然很厲害,但是思維絕對無法超過人,工具里面的邏輯都是人編進去的,而人的思維確實無限的,如果工具真的解決一切,為啥這些工具還不斷經常推出新版本,不正是說明還有很多事情工具做不到,需要人來幫忙去讓它們實現嗎?

            所以在“測試自動化”的理論體系中,人總是在“訓練”工具,而不是在“使用”工具。

            在測試自動化現有理論體系中,主要由以下幾部分組成:

            1、人

            2、自動化測試工具(LoadRunner,QTP,Selenium,Test Complete……)

            3、測試管理工具 (DevTest, TestDirector ……)

            關于“人”,我最后介紹了,先把2和3介紹一下,2其實已經介紹過了,對于3而言,雖然表面上可能沒2厲害,但是其實起得作用可能比2還大,因為自動化測試工具只能測試產品的一個部分,而怎樣能保證整個產品的所有部分都能被測好呢,這個就需要用到測試管理工具,比如TechExcel的DevTest,它的測試用例可以綁定自動化測試工具,而所有的測試用例就代表了一個完整的產品了,當這些測試用例去觸發綁定的自動化測試工具運行后返回結果以后,相當于這個產品全部測完了。

            而最重要的“人”的作用呢?其實我不說,大家應該都能想出很多作用來,接下來我來總結一下:

            1、維護產品的完整性:需要根據功能的變化,Bug的發現、自動化測試工具的局限性,經常地更新測試用例、測試腳本。這個是最基本的。

            2、發揮人的能動性、發散性:自動化工具永遠無法把一個產品測好,所以作為人而言,不要以為懂了自動化測試工具而驕傲,也不用因為只懂手工測試而感到沮喪,關鍵是要了解測試的內涵,從而就能了解產品的內涵,最后讓產品在你的腦海中能融會貫通,這樣子,你自己的腦袋就是無敵的自動化測試工具了。

            3、吸收+創新+創造:相信我,即使一個完美的產品的測試,如果真正意義上說完成了是永遠無法做到的,更何況普通產品了。所以這也就意味著這里面會有大量的地方可以得到加強,吸收以往經驗,發掘與加強遺漏點,追尋潛在點,創造新方法,都是一個“人”都能做到的,當然你需要大量地去思考、去探索。

            4、更新體系:我們說“測試自動化”是一個方向,是一個理論,是一個科學研究,這個就意味著它可以不斷進步,至于進步到什么程度,我也無法想象,有可能會出現類似自動分析產品邏輯從而得到測試用例與腳本這樣子,不過唯一能知道的是,人還是會占主導地位,無論更新到什么樣子,人會一直帶領著這個系統前進!

          posted @ 2012-05-09 09:26 順其自然EVO 閱讀(193) | 評論 (0)編輯 收藏

          6年軟件測試總結

          先講個引子:

            上個工作部門:測試環境是測試工程師自己部署和維護;

            現在工作部門:測試環境是開發工程師部署和維護;

            剛開始的一個月非常不爽,偶爾服務異常(尼瑪)、偶爾測試執行失?。ㄔ幃悾?、偶爾測試過程被中斷(暴躁)、偶爾自動化執行失敗(Fuck),強烈覺得這些情況打斷我的測試思想、甚至測試的持續性,開始思考通過什么方式拿回測試環境的維護權。

            可以尼瑪兩個月過去之后,我放棄了。因為當服務異常、執行失敗的時候,肯定開發在部署新版本,那我去刷刷微博、刷刷豆瓣。換句話說:我用測試工程師維護測試環境的時間刷微博去了,為什么不呢?不過增加了一個約定:開發部署環境的時候先通知,測試工程師同意才可以部署。

            結論:

            開發維護測試環境的優勢:快速與準確。如果有問題的話,測試還是需要找開發解決,這是一種浪費。

            最終結論:PD、PM、Dev、Test,在產品研發過程中,大家都做自身角色最高效的工作,緊密合作。

            6年總結正文開始:

            思想 > 技術:

            技術實現你的思想,思想推動你的技術成長。如果技術視野不夠開闊,將嚴重限制你的技術。

            技術更新太快,你不能保持技術的更新,但是思想可以,需要的時候你進行學習與實現。

            典型的反面教材:#鄙視鏈# 性能測試->自動化測試->手工測試。

            產品 > 質量:

            產品興,測試興;產品亡,測試亡。作為測試工程師,守護產品(架構、需求、方向),守護產品質量。

            如果產品提前上線一天,收入多100w,提前n天就是n*100w,作為測試工程師你什么測試策略?

            合作 > 爭斗:

            如引子中所講,不同的角色會有一些交互點的磨合,減少爭斗,多多合作。

            亞馬遜有個很好模式:先從客戶的需求開始,然后再往后推,立項、申請資源、開發,大家都只做這個產品,直到產品下線,解散到下一個產品,沒有資源共享的情況(甚至UXD也是獨占式)。

            綜合 > 精通:

            未來以產品劃獨立團隊,未來開發自測質量越來越高,QA將轉移至集成測試、性能測試、自動化、工具開發、也參與白盒測試。技術能力上和開發處于同一水平,只是開發代碼熟練,QA測試熟練。

            我們有一個測試數據中心,用于造各種測試數據。由所有的測試同學開發和維護,完成自己所測試的系統的造數據功能,沒有工具組。

            團隊 > 個人:

            團隊的短板,代表團隊的水平。提高團隊的整體水平,才是一個高水平的團隊。

            自我方向調整:

            1、不再糾結測試技術、不再糾結測試流程、不再糾結個人,視角投向產品。

            2、關注測試技術動態、關注行業數據、關注團隊成長、關注生活。

            補充:

            1、舊:一周5天,2天在研究技術細節,1天開會,2天項目相關工作,周末沒有生活安排。

            2、新:一周5天,0.5天關注技術動態,1.5天關注團隊成員,1天開會,2天項目相關工作,周末生活安排。

          posted @ 2012-05-07 09:54 順其自然EVO 閱讀(666) | 評論 (0)編輯 收藏

          軟件測試對質量負主要責任?

            你的公司,產品發布時,是否要求測試說出個“產品質量是XX的”論斷,如果發到用戶那里出了問題,就首先打測試的板子,老大都在問“測試為什么沒有測試出來”,仿佛測試是最后一道關、是質量警察?測試應該對質量負主要的責任嗎?

            我的觀點:測試不對質量負主要責任,測試只起到質量輔助的作用;測試是一種服務,為其他角色提供服務,提供關于質量的信息。

            為了說清這個觀點,有必要先討論一下:什么是質量、什么叫做對質量負責、對誰負責、誰定義的質量。

             當然質量的定義有很多種,我比較贊賞Jerry Weinberg的定義”Quality is value to someone who matters“,測試最主要的目的就是要找到那些削弱產品價值(value)的點,將這些與產品質量相關的重要的信息提供給項目決策者,以便他們做出更 準確的決策。

            正如Michael Bolton所言,”Consider quality not as something simple, objective, and abstract, but as something messy, subjective and very human.“ 質量不是什么簡單的事務,而是一個關乎產品、人、系統之間的復雜關系。

            為了提升質量或保證質量,需要有方方面面的考慮,是那些產品的管理者們真正有權利決定使用什么開發方法和流程、雇傭什么樣的人員、采用什么樣的質量目標、如何度量、花多大成本等等來確保產品的質量,而不是測試人員。

            作為測試人員,不要努力去影響別人做什么、怎么做,而是要聚焦于提供實時的、準確的有關產品的信息(問題和風險),以有助于別人做出更恰當的提升質量的決策。

            測試是一種服務,為項目其他角色提供服務。當然,每一個角色都是為其他角色提供服務的。開發人員為測試人員提供”軟件可測試“的服務,使得軟件更容易測試;測試人員幫助開發人員測試他們的代碼,使用專業的測試技能和測試思維。

            測試人員、包括QA,都不應該將某種方法強加于開發人員,那是質量警察干的事。一是因為測試人員和QA都沒有優勢告訴開發如何開發質量更好的產品;二是因為當你強加某種東西給別人的時候,你獲得的往往是假的數據。

            征得Michael Bolton的同意,轉譯了他的一篇博文:http://www.51testing.com/html/24/n-812424.html

            其實,“負責”是個很重的詞。對質量負主要責任的人,得有一定的權力做各種質量有關的決定。測試是否有權力或能力做這些決定呢?

             質量本身是一系列活動的結果,當然最重要的是設計和編碼,如果設計和編碼都完全符合需求和用戶期望,那也就不需要測試了。然而,我們的認知和智力都是有 限的,不可能那么完美,而且有時候用戶都不知道自己的需求,還需要我們去引導(喬布斯理論),所以還是需要一個中立的或者第三方的組織來判斷產品的實 現是否符合用戶和我們最初的需求和期望,這就需要測試來給相關的利益關系者提供客觀、準確的質量信息和評估了。

            測試活動本身不能帶來產品質量的變化。測試就是一個信息提供方,精確反映出產品需求的實現和在哪種情況可能給客戶帶來的風險就是測試的職責,當做一個質量播報員,就像最近的牛奶風波一樣,我們只要把牛奶中成分的真實情況反映出來,剩下的就由用戶或制造者來做決定吧。

             質量是設計出來的,但設計者是人,也有考慮不足的,需要通過測試發現,發現后設計者進行改進,測試的職責是發現問題。設計和實現是有差距的,沒有缺 陷的設計只是一個終極目標,只是一種理想,因此測試必須進行一種權衡,判斷哪些缺陷是必須改進的,哪些是現在可以忽略的,這種決定不是僅由測試說了算的。 我不知道哪個團隊的測試人員可以做這個決策?除非你比開發人員還懂業務、你比項目經理還了解風險、你比客戶還了解需求?

            產品“零缺陷”只能是一個理想,即使排除時間和投入成本也是不可能達到的。但我們要把產品可能存在的潛在風險和失效條件找出來,發布與否這樣的決定就不是測試說了算了,要看客戶能否容忍這樣的風險和失效,由決策者做成最終決定。

             當然,測試這把尺子,只能提供有關產品質量的“相對”的信息,不是“絕對”的信息。實際上,“XX產品的質量就是什么樣子的“這個論斷沒有人能給得出。 如果你能準確無誤地說出”XX產品的質量現在就是這樣“, 很快就會發現一個反例的出現將打破你原來對它的認識–當然,你根本無法準確無誤地說出質量的樣子,那是一個無窮的集合,就像測試是一個永遠測不完的活一 樣。因此,測試提供的信息只是相對準確的,不是絕對準確的,這個局限性也正是測試所面臨的挑戰。

            不過,測試努力做到的是,用我們的專業技能和測試思維,盡可能學習了解真實的產品、發現別的角色意想不到的問題和風險,并報告給他們:”在XXX的 背景/上下文/場景下,XXX產品在XXX質量屬性方面表現正常;在當前進行了XXX的測試后,目前XXX產品存在XXX的問題,如果XXX使用該產品, 會存在XXX的風險。“

            說“測試對質量負主要責任”這樣的說法是錯誤的,不是代表測試就和質量沒有關系,實際上測試非常關心質量,并且測試的工作對質量有很大的影響。但同時我們認為其他角色關心質量的程度一點也不 比我們小,或者不應該比我們小,大家共同對質量負責。但是像敏捷里的“完整團隊”的說法,每個人都對質量負責、大家是個自組織團隊的做法在現實中還是遇到 很多問題的,還是得有人做決策,做那些為了提升質量而采取什么動作的決策,這個決策者,首先得有權利做決策,才能控制了項 目,才能控制了質量,才能對質量負責。

            也許在很多公司,是項目管理者 有這樣的權力吧。測試像一把尺子衡量產品質量后會給出測試知道的有關質量的信息,同時我們也很清楚,管理者那里還有很多測試不知道的、同樣也很重要的、有 關質量的信息,管理者會基于所有信息作出最終的質量決策,可能是發布產品、可能是更改流程、可能是更改需求、可能是引入工具......管理者有做這些決 策的權利和能力,他們會想辦法讓所有角色關心質量,所以,不是測試對質量負主要責任,而是決策者要對他做的決定負責。

          posted @ 2012-05-07 09:51 順其自然EVO 閱讀(232) | 評論 (0)編輯 收藏

          僅列出標題
          共394頁: First 上一頁 329 330 331 332 333 334 335 336 337 下一頁 Last 
          <2025年7月>
          293012345
          6789101112
          13141516171819
          20212223242526
          272829303112
          3456789

          導航

          統計

          常用鏈接

          留言簿(55)

          隨筆分類

          隨筆檔案

          文章分類

          文章檔案

          搜索

          最新評論

          閱讀排行榜

          評論排行榜

          主站蜘蛛池模板: 百色市| 正镶白旗| 阜新市| 股票| 琼海市| 烟台市| 德江县| 林口县| 石渠县| 海原县| 嘉义县| 牙克石市| 玉门市| 调兵山市| 吴川市| 招远市| 阿拉善左旗| 定日县| 荥经县| 弋阳县| 长沙市| 凤阳县| 乡宁县| 广西| 全南县| 正镶白旗| 循化| 宾川县| 淄博市| 西贡区| 临沧市| 霍邱县| 温宿县| 哈尔滨市| 呼图壁县| 西乌珠穆沁旗| 松滋市| 陆丰市| 沐川县| 彭山县| 大竹县|