LoadRunner穿越防火墻測試

posted @ 2014-08-18 10:10 順其自然EVO 閱讀(460) | 評論 (0) | 編輯 收藏

用JIRA來跟進和管理項目進度

　　新增需求列表：

　　讓迭代master和測試負責人頭疼的不能及時知道需求變更的情況在這里可以得到緩解

　　首先說一下，我們可以從模板上得到神馬：

　　1、 迭代/項目的需求數量、需求列表、開發進度；

　　2、 迭代/項目的測試任務、測試進度、測試任務列表；

　　3、 缺陷數量、缺陷解決情況、缺陷列表；

　　4、 需求變更情況

　　5、 模板中的內容（列表、統計圖等所有信息），會根據項目情況實時自動更新的，不用作任何設置或變動（前提是開發和測試人員及時更新jira上的任務狀態~~這個不為過吧，本來就應該做到的~）

　　6、 導出報表（對出項目報告和測試周報等報告灰常方便，這個主要用于master、測試負責人、項目負責人、SQA）。

　　然后說一下可以改良目前的哪些狀況：

　　1、 一個項目/迭代，只需要一個人（測試負責人或者master？）做一次配置更新，造福全項目/迭代的其他人；

　　2、 項目/迭代里的任何人何以在任何時候了解到當前項目/迭代的開發和測試進度以及缺陷情況；

　　3、 Master和測試負責人以及項目負責人、SQA可以及時賬務需求變更情況，來更好的控制迭代/項目風險

　　4、 導出報表，不用手動統計需求情況和測試任務等條目，節省大量時間

　　5、 模板的通用性，可配置性

　　1）前面說了，這是一個模板，每起一個新的迭代或項目，只要更新一下過濾條件，另存為一下就OK了，一個新的迭代/項目進度dashboard就出來了

　　2）如果還想得到項目其他的一些信息，新建一個過濾器，保存在這個dashboard即可。

　　以上說的就是就是如何利用jira進行項目管理，目前已經用于各個項目和迭代中，而且起到了很好的作用，至于如何用jira建立這樣一個dashboard這里就不廢話給出了，因為會用jira的人看了這篇文章幾分鐘就可以把這樣一個項目或者迭代的dashboard建立好了~

posted @ 2014-08-18 09:43 順其自然EVO 閱讀(9783) | 評論 (0) | 編輯 收藏

怎么的技能可以讓軟件測試工程師獲得高薪？

posted @ 2014-08-18 09:41 順其自然EVO 閱讀(168) | 評論 (0) | 編輯 收藏

Web服務請求異步化測試

<Set name="ThreadPool"> <!-- Default queued blocking threadpool --> <New class="org.eclipse.jetty.util.thread.QueuedThreadPool"> <Set name="minThreads">10</Set> <Set name="maxThreads">500</Set> </Set> <Call name="addConnector"> <Arg> <New class="org.eclipse.jetty.server.nio.SelectChannelConnector"> <Set name="host"><SystemProperty name="jetty.host" /></Set> <Set name="port"><SystemProperty name="jetty.port" default="6060"/></Set> <Set name="maxIdleTime">300000</Set> <Set name="Acceptors">2</Set> <Set name="statsOn">false</Set> <Set name="confidentialPort">8443</Set> <Set name="lowResourcesConnections">20000</Set> <Set name="lowResourcesMaxIdleTime">5000</Set> </New> </Arg> </Call>

附注：

　　Asyn表示異步模式，syn表示同步。Asyn中還分成resume和complete兩種方式，后續在介紹技術背景的時候詳細描述。

　　對于服務端的load不是每一個測試都做了記錄，選取了最全面的1500并發用戶做了測試。

　　最大服務請求處理數是通過應用自身實現，具體代碼可以參考后面的代碼附件。

　　測試結果如下：

　　場景1：500 并發用戶場景下，后端服務一次請求消耗3秒鐘

　　這個場景測試的目的是比較在線程池資源足夠的時候，異步和同步的差別。（也就是TOP服務器所有的資源處于正常服務，前臺請求沒有因為前段連接被消耗完，導致服務質量降低）

　　可以看到，在TPS和Response Time上兩者基本上沒有太大差別，TPS就等于500/3=167左右（3秒一個請求，因此用這種簡單算式可以算出），響應時間也較為正常。當時我發現在每秒吞吐量上有些差別，后來單個測試case跑了一下，發現是返回的http header比較大，應該是在做異步化時重入等作的一些標識（后面其他容器的異步化也是一樣）。

　　最大處理請求數都在服務端后臺看到是500，等同于最大的并發用戶數。

　　場景2：1000 并發用戶場景下，后端服務一次請求消耗3秒鐘

　　場景2就在資源不足的情況下，比較異步服務請求與同步請求處理能力。（例如由于后端某些服務比較慢，導致前段的服務器能夠承載的請求數目超過了線程數）

　　這個場景的結果可以看到TPS在異步模式下與并發用戶數呈現同步增長，就好比配置了1000個線程作為線程池一樣，同樣在后端打出的最大請求數上也證明了這一點，因此前段線程池的服務能力在異步的情況下充分復用（當然這里使用的異步服務處理使用的是NIO而不是BIO的Connector）。同樣在吞吐量上依然是增加的，由于異步附加的內容。

　　場景3：1500 并發用戶場景下，后端服務一次請求消耗3秒鐘

　　場景三比對了現有TOP的部署模式（Apache + modjk + Jboss）和Jetty7的同步模式，兩種異步模式，Tomcat同步模式，Tomcat的servlet3.0異步模式的處理情況。根據測試可以得到的信息如下：

　　1.              現有部署方式在后端服務處理耗時較大的情況下，處理能力不如Jetty7和Tomcat6，同時出錯率很高。

　　2.              Jetty7的同步處理測試結果和Tomcat6的同步處理測試結果很類似，但是load方面jetty7更好。

　　3.              異步處理方面Jetty7的兩種方式基本上差別不大（后續還需要深入源碼看看對于數據緩存資源復用的狀況），Tomcat7的異步處理成功率有些問題（錯誤多半是在獲取response回寫的時候，response已經被提前釋放，看來Tomcat7還是需要一些時間來考驗），load上來說tomcat結果比較好。

　　4.              異步請求在提高處理能力的情況下，對于資源消耗也較大（線程切換較為頻繁），不過還是在承受范圍。

　　三個場景組合比較：

　　最后將三個場景合并起來做一個簡單的比較，得到信息如下：

　　1.       隨著并發用戶的增加，本身異步處理也會有衰減，同時對于性能消耗（線程切換）也會不斷增長。

　　2.       異步化在消息頭上會增加一些數據，會增加回寫的帶寬消耗（不過量不大），一個請求增加了100byte左右的消息數據。

　　測試總結：

　　1.       Web請求異步化在TOP很合適。

　　重復兩個條件：

　　a.       處理耗時大多消耗在于對后端或者外部服務資源的請求上。

　　b.       后端或者外部資源在更多的流量下不會成為瓶頸。

　　2.       Web請求異步化在Jetty6到7上已經經歷了2年多的成長（Google App Engine , Yahoo Hadoop），穩定性和效率較好。（同時很多優化可以通過擴展自行定制，jetty的可擴展性很好）Tomcat7在servlet3上處于剛發布階段，還有待繼續完善。（Servlet3的另一種模式尚未執行成功，直接導致jvm退出）

　　后續需要繼續跟進的：

　　1.       對于大數據量請求的容器間性能對比。（圖片上傳或者大數據量的Post請求）

　　2.       容器安全性。（是否容易被攻擊）

　　3.       代碼遷移成本。

posted @ 2014-08-18 09:39 順其自然EVO 閱讀(485) | 評論 (0) | 編輯 收藏

Android單元測試方法與步驟

　點擊下一步，選擇要測試的方法：

　　點擊完成。

　　將新產生的單元測試的類放入test/項目包名下。

　　在單元測試方法中添加實現：

　　展開test/cn.ycmoon.test.activity下單元測試類，選擇要測試的方法，點右鍵，選擇Run As->Android JUnit Test，就會打開單元測試結果界面。

　　右該方法無錯誤，則結果會顯示綠色狀態條：

posted @ 2014-08-18 09:34 順其自然EVO 閱讀(425) | 評論 (0) | 編輯 收藏

Web應用軟件功能測試

posted @ 2014-08-18 09:32 順其自然EVO 閱讀(164) | 評論 (0) | 編輯 收藏

Win7下的內置FTP組件的設置詳解

　在局域網中共享文件，FTP是比較方便的方案之一。Win7內部集成了FTP，只是設置起來頗費一番功夫。著文以記之。

　　一、安裝FTP組件

　　　　由于Win7默認沒有安裝FTP組件。故FTP的設置第一步就是安裝FTP組件

　　　　點擊：控制面板—》程序和功能—》打開或關閉Windows功能。勾選“FTP服務器”及“FTP服務”“FTP擴展性”，點擊“確定”，安裝FTP組件。如下圖所示

　　二、添加FTP站點

　　　　點擊：控制面板—》管理工具。選中“Internet信息服務(IIS)管理器”，如圖

　　　　雙擊“Internet信息服務(IIS)管理器”。彈出管理器界面，如下圖所示：

　　　　單擊選中“網站”，并且在其上右擊，選擇“添加FTP站點”，出現“站點信息”界面，如下所示：

　　　　給FTP取名（本例是：zhu），以及設置FTP站點的物理路徑（本例是：c:\ftp），點擊“下一步”，出現“綁定和SSL設置”界面，如下圖所示

　　　　IP設置為本機的IP地址，端口用FTP默認的21，SSL勾選“無”。點擊“下一步”，出現“身份驗證和授權信息”界面，如下圖所示：

　　　　如果只是想設置簡單的FTP，則“身份驗證”和“授權”都勾選“匿名”，并且給匿名設置相應的權限。本例中，還要給FTP配置帳號，以及帳號的權限，故“身份驗證”勾選“基本”，“授權”勾選“未選定”，點擊“完成”，完成FTP站點的設置。

　　三、設置FTP帳號以及權限

　　　　由于Win7下的FTP帳號是Windows用戶帳號。所以，先得添加兩個用戶帳號，一個是View，可以瀏覽、下載FTP內容；一個是Admin，完全控制FTP。

　　　　點擊：控制面板—》管理工具—》計算機管理。在計算機管理的界面的左側，點擊：系統工具—》本地用戶和組—》用戶，右側顯示所有用戶。如下圖所示：

　　　　在“用戶”上右擊，出現“新用戶”，如下所示：

　　　　在用戶名中輸入View，設置好密碼，去掉勾選“用戶下次登陸時須更改密碼”，勾選“用戶不能更改密碼”和“密碼永不過期”。點擊“創建”，完成用戶View的創建。同樣的步驟，創建Admin用戶。由于Windows默認將用戶添加到Users組，你可以將剛才的兩個用戶從Users組中刪除。方法是在“計算機管理”中點擊“組”，在右側的列表中找到Users，雙擊之，出現如下界面，點中用戶View，點“刪除”，點中用戶Admin，點“刪除”。將兩個用戶從Users組中刪除。

　　　　接下來，在FTP站點中，給View和Admin添加權限。

　　　　點擊：控制面板—》管理工具—》Internet信息服務(IIS)管理器。點中剛才新建的FTP站點。點中“FTP授權規則”。如下圖所示：

　　　　點擊右側的“編輯權限”，對FTP站點文件夾添加用戶權限。在彈出的窗口中，點擊“安全”標簽。，如下圖所示：

　　　　點“編輯”，出現權限的窗口，如下：

　　　　點“添加”，在“輸入對象名稱來選擇”中輸入View，點“確定”，添加View用戶。如下所示：

　　　　添加的View用戶，默認是只有讀取、列出的權限。在依法添加Admin用戶，給Admin用戶添加完全控制的權限。如下所示：

　　　　再回到“Internet信息服務(IIS)管理器”窗口，雙擊剛才選中的“FTP授權規則”，在FTP站點中對View和Admin授權。如下所示：

　　　　點擊右側的“添加允許規則”，在彈出的窗口中，勾選“指定的用戶”，輸入View，在下方的“權限”中，勾選“讀取”。如下所示：

　　　　點“確定”，給FTP站點添加View用戶，相應的權限是讀取。再給FTP站點添加Admin用戶，相應的權限是讀取和寫入。

　　　　至此，FTP的站點設置就完成了。站點文件夾是c:\ftp，View用戶有讀取（瀏覽和下載）的權限，Admin用戶有讀取和寫入（上傳和刪除）的權限。當然，還可以根據實際的情況添加用戶及相應的權限，也可以將用戶添加進組，再給組設置權限。還可以添加匿名用戶等等，不一而足了。

　　　　然而，事情遠遠沒有結束。如果，你急于做測試的話。會發現，在本機上測試正常，但是用別的機器測試FTP的話，會發現連接不上。問題出在Win7下的防火墻。如果你把防火墻關掉，你會發現FTP恢復了正常，但你也不能因為要用FTP，就把Win7的防火墻關掉。要想在Win7開著防火墻的時候還要正常使用，還必須得在防火墻中進行一番設置

　　四、Win7的防火墻設置

　　　　點擊：控制面板—》Windows防火墻。點擊左側的“允許程序或功能通過Windows防火墻”，選中“FTP服務器”，將后面的兩個框都勾選，如下所示：

　　　　這是網上絕大多數介紹的防火墻設置。然而還不夠，你做測試的話會發現，還是連接不上。還必須在防火墻中進一步做設置。

　　　　點擊下方的“允許運行另一程序”，在彈出窗口里，點“瀏覽”，找到C:\Windows\System32\inetsrv\inetinfo.exe，點添加，也就是上圖中的Internet Infomation Services。將后面的兩個框也都選中。因為在Win7下，FTP是IIS的一個組件，因此也必須在防火墻中將IIS設置為允許。而IIS又不在默認的列表中，因此得手動添加。

　　　　遺憾的是，這樣設置，FTP還是不能正常使用。由于FTP用的是21端口，因此在防火墻中還得添加出站和入站的端口規則。

　　　　在Windows防火墻窗口里，點擊左側的“高級設置”，彈出高級安全防火墻窗口，點擊左側的“入站規則”，如下圖所示：

　　　　點擊右側的“新建規則”，出現向導界面，勾選“端口”，如圖：

　　　　點擊“下一步”，勾選TCP（FTP用的是TCP協議），再勾選特定本地端口，輸入21（FTP用的是21端口）如圖所示：

　　　　點擊“下一步”，勾選“允許連接”，如圖：

　　　　點擊“下一步”，默認的都選上，如圖：

　　　　點擊“下一步”，在名稱里輸入名字，本例中是21，如圖

　　　　點擊“完成”，完成入站規則的設置，在用同樣的方法，完成出站規則的設置，同樣是21端口。

　　　　至此，在Win7的防火墻就已經設置好了。現在測試基本上就正常了。

　　不過，還有個小問題：

　　在用IE瀏覽FTP的時候，雖然可以登錄，但是沒法顯示FTP內容。這個是IE的設置問題。在Internet選項中，將“使用被動FTP（用于防火墻和DSL調制解調器的兼容性）”勾掉就解決了不能瀏覽的問題。如下圖所示：

　　后序。總體來說，Win7的內置FTP設置比一些第三方的FTP軟件設置要繁瑣一些。但是在某些場合下，還只能用Win7的內置FTP。以上的內容都是網上搜集來的，加上本人的親測。如果誰在FTP設置上還有什么問題，歡迎交流。

posted @ 2014-08-15 16:18 順其自然EVO 閱讀(187) | 評論 (0) | 編輯 收藏

缺陷上報統一模板及缺陷管理流程

posted @ 2014-08-15 09:56 順其自然EVO 閱讀(214) | 評論 (0) | 編輯 收藏

ASA防火墻基本配置管理

posted @ 2014-08-15 09:55 順其自然EVO 閱讀(375) | 評論 (0) | 編輯 收藏

好的產品經理，差的產品經理

　　Ben Horowitz這篇不朽的杰作誕生于1996年，但時間的久遠絲毫不影響其對當前的警示作用。那時，作為Netscape產品管理部門經理的Ben，沒有假大空地介紹產品經理的角色和責任，而是很直觀地對比了一個好的產品經理和差的產品經理。

　　好的產品經理，差的產品經理

　　——Ben Horowitz

　　好的產品經理了解市場、產品、產品線和劇烈的（市場）競爭，并基于自身強大的知識基礎和自信進行角色扮演和職責履行。好的產品經理是產品的CEO。好的產品經理能全力履行職責并以產品的成功進行衡量。他們對正確的產品、正確的時機以及所有相關細節負有責任。好的產品經理了解公司、收入基本、競爭等種種情況的相關信息，他們負責制定并毫無托詞地執行一個成功的計劃。

　　差的產品經理有眾多借口。比如，資金不足、技術經理很白癡、微軟擁有10倍的工程師致力于開發同樣的產品、我超負荷了、我得不到直接充分的指導。Barksdale不會制造這些借口，同樣產品CEO也不會。

　　好的產品經理不會被需要共事交付正確產品、履行正確時間的其他各類組織占用全部時間。他們不會耗掉所有產品團隊的時間、不會制定管理各種職能、不會成為產品隊的一部分；相反，他們管理產品團隊。技術團隊不會將好的產品經理當成營銷資源。好的產品經理是技術經理的營銷同行。好的產品經理清晰地定義目標、做什么（需求），并管理交付什么。而差的產品經理在指出“怎么做”的時候自我感覺最棒。好的產品經理能以書面方式清晰地溝通工作上的事，即便在口頭形式上也能做到清晰溝通。好的產品經理不會隨便給出指示。但是，好的產品經理會非正式性地（不刻板）收集信息。

　　好的產品經理會制作可參考的附加材料、常見問題解答、簡報、白皮書。差的產品經理抱怨他們整天回復銷售團隊的問題，以至于頭暈腦脹。好的產品經理期望嚴重的產品缺陷，并建立真實可靠的解決方案。而差的產品經理整日跟蹤消除缺陷。好的產品經理對于重要問題（強競爭力的絕招、結實的架構抉擇、艱難的產品決策、市場攻擊或收益）進行書面記錄。而差的產品經理口頭陳述觀點并悲嘆類似問題不要在發生。一旦差的產品經理失敗了，他們則指出自己已經預測到會失敗。

　　好的產品經理使團隊關注收益和客戶層面。而差的產品經理則讓團隊聚焦微軟正構建的功能數。好的產品經理定義可暴力執行的好產品。差的產品經理則定義這樣的“好產品”：不能執行或無法讓技術人員構建他們想要的行為（比如，解決最大難度的問題）。

　　好的產品經理會考慮：在發布計劃中向市場交付高價值的東西，并在發布之后獲取市場份額、取得收益目標。而差的產品經理對于交付價值、匹敵的競爭性功能、定價和普遍性之間的區別，卻混淆不清。好的產品經理分解問題，而差的產品經理將所有問題捆綁為一個大難題。

　　好的產品經理考慮想讓媒體書寫的故事。而差的產品經理跟媒體一同思考覆蓋每個功能、考慮在真實技術上確保（描述）準確。好的產品經理咨詢媒體問題，而差的產品經理回答媒體的任何問題。好的產品經理假定媒體和分析師是聰明的。差的產品經理則假定媒體和分析人員是外行人——（認為他們不理解“推動”和“擬推動”的區別）。

　　好的產品經理在“‘明確’對比‘解釋淺顯問題’”方面犯錯。而差的產品經理則從不解釋顯而易見的問題。好的產品經理定義他們的工作和成功，而差的產品經理經常需要被告知做什么。

　　好的產品經理每周及時發送他們的現狀報告，因為他們遵守紀律。而差的產品經理忘記及時發送，因為他們不重視紀律。

posted @ 2014-08-15 09:54 順其自然EVO 閱讀(154) | 評論 (0) | 編輯 收藏