qileilove

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

          如何保證軟件質量?淺析軟件帶來的業務風險

          如何保證軟件質量?淺析軟件帶來的業務風險

          企業在軟件質量保證上的投資是值得的,對于降低企業的業務風險也是必要的。

            軟件項目風險高、軟件質量差一直是困擾我們企業的一個大問題。根據日前由美科利(Mercury)與Economist Intelligence Unit合作撰寫、發布的報告,在中國有76%的企業IT項目沒有達成預期的業務目標。

            這份題為“管理IT業務風險,保護組織遠離IT失敗”的報告以全球性的調查為基礎、調查了全球1000多位的IT經理而成。該報告在關于中國的研究報告部分說,中國的IT項目失敗的原因主要是無法應對IT項目開發階段的變化、低質量的軟件以及項目管理中的資源和資金問題。而項目管理、應用管理以及開發工具將是許多企業明年為提高IT性能而投資的三個最重要的領域。

            事實上,由于軟件出現故障導致業務中斷的事件我們時有耳聞。2005年4月,一個軟件的小Bug讓美國航空集團公司損失了數十萬美元,當時一些機票的價格被錯誤地定為1.86美元; 更嚴重的例子是,2003年8月美國東北地區的大停電正是由軟件Bug造成的,這次停電讓數百萬人陷入黑暗。還有我國的首都機場也曾因軟件故障導致一度停運。

            “要保證軟件不出問題,有幾個關鍵環節需要控制。一個是軟件開發階段,即在項目計劃、需求分析、軟件開發等幾個關鍵環節進行軟件質量控制,另一個是在運行階段,對軟件實時監控,即進行配置和性能優化,保證軟件順利運行。” 美科利全球運營高級副總裁Jay Larson說。

            出于時間和開發資金的原因,很多企業常常讓軟件倉促上線。對此Jay Larson認為,企業不能把軟件質量控制建立在軟件供應商已滿足CMM5認證、建立在軟件供應商是業內最好的企業之上,而應該對交付的軟件進行嚴格測試

            Jay Larson 說: “不管是預算多么緊張,時間多么不夠用,測試過程是不能打折的。為了保證測試的順利,測試部分的預算應該占總預算的20%以上。更何況,與國外企業的軟件相比,中國軟件系統要大得多。因為大所以軟件復雜,軟件出錯的概率也更高,從而使得軟件質量保證更為重要。”

            據了解,重開發輕測試是很多企業常犯的錯誤。實際上,這是本末倒置。根據美科利的統計,經過美科利的測試軟件測試后,其軟件缺陷數會降低75%,單個項目的投資回報率可以達到350%.顯然,企業花在軟件測試上面的投資是值得的。而值得注意的是,由于自動化的測試工具的出現,與以前純人工的軟件測試相比,測試效率有了很大提高,同時測試成本也有了很大程度的下降。

            另外,軟件質量保證是一個長期的工作。這體現在兩個方面: 一方面,不僅在軟件部署和重大升級時需要進行測試,而且在打補丁和小的發布時都需要進行測試。而后者很容易被企業忽略。另一方面,也是更重要的,需要對軟件進行長期的監控,即生產中和生產后的監控,也就是生命周期的測試。

            值得高興的是,在一些軟件密集型企業,如金融、電信企業已經意識到軟件質量的重要性。據美科利大中國區總經理盧汝文透露,已經有企業和美科利探討組建企業軟件質量中心。盧汝文說,“我們能看到的趨勢是,越來越多的CIO開始關注軟件質量、關注其失敗后帶來的業務風險。”

          posted @ 2011-12-07 11:33 順其自然EVO 閱讀(168) | 評論 (0)編輯 收藏

          國內軟件測試發展狀況分析

          【背景】

            記憶中,自2000年以來,軟件測試在國內的興起,猶如一陣春風來,業界感知到了,在網上終于看到些許軟件測試相關的招聘信息了。接著便有了專業網站,培訓機構等,再后來是更多的崗位需求,更多的培訓機構等。那么10年后,國內的軟件測試到底發展到一種什么樣的程度,又將會走向何方?帶著這些問題,我搜集了一些資料,及結合親身經歷的一些案例,作以下總結分析,與大家分享。(了解不全面,不正確之處,歡迎拍磚!)

            【行業發展概況】

            ■ 測試專業走入高校

            1、2010年12月16日,國內知名測試專業網站51testing與鄭州輕工業學院軟件學院人才培養實訓基地簽署協議,共同培養軟件測試人才;(http://www.51testing.com/html/00/n-210000.html

            2、 目前,國內多間高校已專設有本科段軟件測試方向的專業,如廣州華軟軟件學院,如下圖所示,電子科技大學成都學院,北京民族大學信息工程學院等學校;

            3、 2011年11月12日~13日,由國家教育部軟件工程專業教學指導分委主辦的“2011年高等學校軟件測試課程教學論壇”,在上海同濟大學召開,無疑對國內軟件測試人才的培養,及測試領域的全面發展起到積極推動的作用。這里要特別感謝軟件測試領域知名專家朱少民老師的分享,下面是來自興浪微博關于此事的截圖。

            ■ 測試技術沙龍多樣化

            1、對于線下的技術沙龍活動,51testing應是國內舉辦場次最多,時間最早的一家了。自2007年開始,分別在一線城市的北京,上海,深圳輪流舉行。在深圳舉行的沙龍一般情況我都會參加,每次去叫上一些朋友,都有一些收獲。乘著國內軟件迅猛發展的態勢,社會發展步伐的需求,今年7年份在天國之府的成都也開始舉行,使得更多的同行朋友可以相互交流、分享,何嘗不是一件好事;

            2、軟件測試是軟件研發過程中不可或缺的一環,在網上不少軟件研發社區也有專門的測試版塊,在線下也組織一些演講活動,如MPD(亞太軟件研發團隊管理)峰會,自去年開始,就在全國各地作不同巡回演講,對推動軟件測試領域的發展無疑是正向的。


           ■ 測試專業微群層出不窮

            自今年以來,比較關注微博生活,幾乎在半年多的時間里,我就收到不下10個測試微群的邀請。比如敏捷測試,落地微群,軟件測試,軟件測試俱樂部等,盡管這些微群的影響力還不足夠突出,但有一點足可以說明在線上活動的測試同學非常活躍,大家都在積極討論,相互學習與分享,且這種氛圍的交流沒有國界,常能讓你感受到世界沒有距離,技術無界,非常High!(這一點也是互聯網的優勢哦J)。

            ■ 不可忽視的信息福射影響

            從今年收到的一些二三線城市,如蘇洲,桂林等地一些讀者朋友的來信中,領略到社會對軟件測試需求的變化,測試對軟件質量的重要性已從幾年前的認識層面,上升到了實施層的執行階段。現在,這股氣息已擴散到了華夏大地的大江南北。盡管目前他們那邊的軟件園才剛剛建成,公司軟件開發模式還屬小作坊等,但國內外此領域發展已有的積累一定可以使他們成長得更快,更順利。這亦是好事,也是社會發展大環境的影響,大勢所趨,信息化網絡化社會發展的必然。

            綜上,看到發生在我們身邊的這些變化,相信測試朋友們與我有一樣:高興,鼓舞倍增。然而,不時不時在網上或一些書報上,總是提及軟件測試正處于萌芽階段、初級階段云云,一年過去了,二年過去了,幾年后還是萌芽、初級階段嗎。常在想,我們現在到底走到一種什么階段,這些階段的劃分又是以什么標準來判斷的呢,并試圖通過研究國內外一些知名企業軟件測試的發展情況,嘗試給出一個比較合理的答案,以致能按圖索翼,尋找一些規律。以是有了下面的“測試領域發展階段淺析”

            【測試領域發展階段淺析】

            下面是世界頂級的軟件公司微軟的軟件測試發展歷程圖,從這個圖中或許我們可以找到一些比較、借鑒。

            ■ 圖解

            1、1975年微軟成立,1979年,招入第一個測試實習生,名叫Lloyd Frink。<<微軟的軟件測試之道>>中有相關的故事介紹,也就在那時,微軟開始意識到軟件研發團隊中需要有測試人員,屬測試認識的萌芽階段。

            2、1983,招入第一個全職的STE(Software Test Engineer)。在測試意識萌芽了近4年后,微軟件有了第一個正式的測試人員,接下來也就有第二個、第三個正式的測試人員,意味著從測試的萌芽階段邁入到測試初始階段,屬測試發展的必由路徑。

            3、1985, 招入一批STE(下圖為當時微軟刊登在西雅圖時報上的一則招聘廣告),并成立獨立的測試部門,標志著在微軟公司,軟件測試步入了正軌,開始了他們正式的軟件測試發展時期。到了2005年,他們在全球已有9000多名STE。由于公司業務的發展,及技術積累到一定程度,量變帶來一系列的質變等。STE已不能很好地表達對這個崗位人員的稱呼時,他們對測試工程師的稱謂改為SDET(Software Development Engineer in Test),這又是一個進步,是歷經了20年歷練后總結出來的給測試人員的最合適的稱謂。那么這20年,對于微軟的測試來說,它是一個高速發展變化的發展階段,而在SDET之后是邁向更高一個臺階的階段。

          (注:上圖來自于《微軟的軟件之道》)

           從宏觀的角度,縱橫國內外關于軟件測試的所見所聞所感,分享下我對國內軟件測試發展階段的看法(劃分),如下圖所示。

            ■ 圖解

            1、萌芽階段:2000年之前,國內軟件公司有專門設立軟件測試崗位的可說是少之又少,大部分情況是代碼設計人員編碼完成后,進行調試,對基本功能自行進行確認。據悉,即使是目前排名等一的軟件公司華為也是在1997年才有正式的測試崗位。

            我是在1997年開始在一家臺資企業從事軟件測試的,那時找到這份工作向同學、朋友說起,基本沒人知道是做什么的。好在自己是學計算機出身,軟件工程這門課中有一些章節專門介紹軟件測試。俗話說“既來之,則安之”,既然選擇了這份工作,還是需要把它做好,這是對工作負責的基本要求,于是到處找相關的書籍、資料進行學習,只可惜那時基本找到的仍是軟件工程類的書。后來,隨著國內互聯網產業的發展,在90年代未,在家里終于可以方便地通過電話線上網了。記憶比較深刻的是上國外的www.QAForums.com網站,也就在哪,發現了我們與國外測試領域發展的區別。

            2、初始階段:2000年后,由于互聯網信息產業的迅速掘起,不僅改變著我們的工作方式,也影響著日常生活中我們與同學、朋友之間的交流方式。也就是在互聯網上,在國內首家上線的“中國人才熱線”上,第一次看到有一家港資公司發布了招聘軟件測試員的信息。后來,每隔一段時間,我又到網上搜搜,發現關于招聘軟件測試員、甚至提到招聘軟件測試工程師的公司越來越多,甚喜!朦朧前行幾年后,終于依稀看到前方的曙光,正穿過厚厚的云層向我們走來,走來……。

            自2003年后,隨著國內軟件外包公司的快速發展,市場把對軟件測試的需求推向了一個高潮。同時,屬國內高科技領域的軟件行業一方面是受國家政策的傾斜,另方面也是社會發展之需,本土軟件公司的發展勢頭同是異常迅猛。而大家都知道,有軟件的地方,就需要有軟件測試,因為軟件測試仍是至今為止最好的提高軟件質量的手段。此階段,在互聯網上百度或google一下“軟件測試員”,“軟件測試工程師”,便有成千上萬的相關信息出來。冥冥之中,全國上下,大大小小與軟件相關的公司都開始設立軟件測試崗位,并招聘相關人才。也正因為有這些社會需求,全國各地的測試培訓、測試服務機構猶如雨后春筍般不斷地涌現,如領測軟件測試,北大青鳥、達內,51testing等,也就在這個階段的2004年,目前國內知名的測試專業網站51testing出現了。

            3、發展階段:如同其他專業領域一樣,隨著時間的推移,社會大環境的發展變化,測試專業領域的發展也在不斷地發展變化著。軟件測試是一門技術性很強的專業,與軟件開發之間的關系非常密切,在測試模式、測試方法上與開發的模式、架構直接相關。比如:由.net架構開發的軟件,測試對象分析必會涉及到.net軟件運行原理及相關知識等。如果操作系統是采用嵌入式開源Linux系統,那么采取的測試模式、方法會與Linux系統相關,等等。

            大家都知道,在IT領域,軟件的開發技術更新換代日新月異,換而言之,伴隨著不斷變化的測試對象,測試技術、測試方法、測試知識也在快速地變化著。近幾年,大家對這方面的討論比較多,或許是要學要做的事多了,在網上討論一些如薪水低,測試不受重視,技術含量低等這些方面的貼子少了,取而代之更多的是相對比較務實的貼子。如工作中的點滴總結分享,問題解決方法分享,技術應用分享,行業信息分享等。

            最后是最近這二三年,測試專業走進了高校,可以說給測試領域人才的培養起到了突破性的推進作用。為什么這么說,在學校的集中成培養,可以更系統地學習相關專業知識,例如統一的課程,用書,實習與管理,相當于批量生產。

          posted @ 2011-12-07 11:32 順其自然EVO 閱讀(880) | 評論 (0)編輯 收藏

          項目管理雜談

          項目管理有個前提,資源稀缺,如人力、時間、資金等。比如,有一個政_府官員,有一筆撥款,于是上了一個政績項 目,這類項目一般不缺資源,所以也不需要進度管理,做啥時候就啥時候,更不用項目管理軟件。如果進度拉長可以增加預算,于是得到更多灰色收入,那么效率可 能是一種負擔。我不是危言聳聽,你看中國有多少.gov的僵尸網站?

            項目管理 vs 人的管理

            其實,標題的意思是,項目管理過程中,關注于項目,還是關注于人。是人適應項目,還是項目適應人。

            偏向于人的管理,即人本管理,我認為,對于像軟件這種思考型行業更有效。因為思考型行業的管理,本質是人腦的管理,人心的管理。人腦的管 理,就是將人的智商充分發掘出來,高效率地工作;人心的管理,就是讓員工自動自發、培養其責任感和熱情。管理是因為不協調才需要約束,如果大家自動自發、 有責任感,還需要把管理掛在嘴邊嗎?

            最好的管理,是員工感覺不到被管理

            任何外在的手段,無非是讓其產生壓力、恐懼,如被淘汰、降薪、加班,通過這種力來推動項目。但人的效率,只有在充分自由的環境下才能夠發 揮。引力(激勵)比推力更有效。《人件》比任何項目管理工具書,更能從根本上解決問題。

            項目的風險,往往來源于人的風險,如溝通不暢,上下不齊心。

            信任本身就是一種約束,監督會加強團隊的隔閡。

            激勵比控制更容易規范員工行為。

            如果說在項目管理和人的管理間找到一種關系,那就是:設定目標,然后站在執行者的角度考慮問題。

            項目管理的前提,是人的管理。人的問題解決后,再來談管理項目。

            項目管理,本質上是關注如何在有限的資源下,達到設定的目標。所以,它涉及到成本管理、進度管理和人力管理等資源方面,范圍管理和質量管理 等目標方面,以及達成目標所需要的溝通管理和采購管理。

            成本管理 打個比方,計算器可以為我們DIY電腦時省錢嗎?

            人力管理和溝通管理:關鍵是處理人的關系,關注當事人的利益

            范圍管理:也許寫在紙上大家也就明白了

            質量管理:決定于流程和執行力度

            采購管理:就看PM的商務溝通水平了

            也許,項目管理軟件,最后會簡化到一個進度管理和任務分配工具,而進度管理,往往Excel甘特圖更實用。

            當然,我說的是中小型項目,大型、規范的項目和團隊,可能就很依賴于項目管理軟件來做進度。

            完成項目,需要一種方法,這種方法可能就依賴工具,也許工具本身就提供一種方法。工具有一定的使用環境,就如同我以前一篇文章中, 談到的一段經歷:

            Bug管理

            Bug管理,這兩年,我們經歷了三個階段。

            先說說使用環境吧,因為這是 決定一管理軟件是否適合的最核心條件之一。

            人員:有開發人員和不懂軟件的業務人員 問題主要是業務員提出

            距離:原來一年大家在一個辦公室,后來IT部和業務部分,距離約1km

            項目:旅游電子商務網站,包括前臺和后臺。這類網站重業務和用戶體驗,技術上沒難度

            最開始,使用的是Bug管理系統JIRA 用了約一年,基本上是推,業務人員不適應,最后我覺得反饋一個問題很煩瑣,自己主動廢棄了。

           后來,使用Excel,當然這是為bug管理定制的Excel,執行一個月就覺得不行,因為問題匯總、截圖等不方便,簡單問題這樣匯報似乎也太累。

            最后,使用Foxmail郵件用得非常順,特別是業務部和我們分開情況下。因為郵件有三個特性很受用:抄送人,延遲執行,貼圖。

            有些很小并且及時的問題,直接通過QQ完成。

            反正,在我們這個小團隊,最后一種方式,直到現在都覺得很適合我們。

            其實,在Bug管理的背后,有一個非技術支撐:信任。我們的重點不在責任界定、責任追究等和權限有關的事情上,我們只關注目標:問題被及時 發現、及時解決,以及解決過程中的低成本協作。

            開始應用一款項目管理軟件,都存在不習慣、甚至抵觸的問題。最難的是改變人的思 維習慣,其次才是行為習慣。前者需要有效的培訓和輔導,培訓的效果,取決于團隊成員多大程度的認同而不是會用,后者可 能需要痛苦的練習。

            項目管理 vs 過程管理

            能夠將這兩個概念清晰區分的人,一般都有真正的項目管理經驗。前面說過,項目管理,本質上是關注如何在有限的資源下,達到設定的目標。項目管理,本身和具體開發的實物無關,比如甘特圖幾乎可以描述任何項目。這就是為什么有些項目還會有產品經理。過程管理,本質上是實現具體實物所需的步驟或流程,而它和具體實物、以及項目團隊關系很大。

            我將兩者拿出來比較,主要是因為,我覺得項目的成功與否,與采用的過程關系很大,而這在項目管理軟件中很難體現。比如開發企業信息系統,要 建立數據庫:

            如果是大項目,可能有專門的DBA負責建庫,不需要和誰一個個字段確認。

            如果是中小項目,可能是PM或PL負責建庫,也不需要其他人確認。最混亂的情況是,各模塊開發人員自己建表。

            如果是偏產品,小團隊,比如我建立過一個流程,對我們很實用:

            引用

            1、項目經理先和某開發人員溝通需求及業務字段

            2、開發人員在一個規范的Excel表格中建表

            3、告知經理,review一下字段命名及類型等,微調

            4、開發人員在開發數據庫中建表

            5、建完后告知經理,再次review

            這樣,把本來建庫的繁瑣工作授權給開發人員,解放了經理,也提升了他,還保證了質量。過程其實非常敏捷。

            權力并不會帶來真正高效的的管理

            可能有人說,我也帶過項目呀?如果你帶的一批人,一開始都和你關系不錯,直到項目結束,你可能并沒有接觸到真正棘手的管理。當你的項目組,都是一批 有個性、工作性質不同的人,你這時候才會深刻體會到,溝通、協作有多大的挑戰,如果再加上一個項目期限,我姑且拋開項目本身的業務復雜性。比如,技術牛 人,往往很有個性,喜歡自己來一套,不遵守團隊規范,并且不太喜歡主動反饋,因為自我感覺都OK。如果強推規范和流程,往往會埋沒一位人才。

            還有一種情況,就是大公司的“資深”項目經理,這類人往往受公司高層支撐,比較強勢。如果遇到項目組某成員不服管,往往是,要么打入冷宮, 要么驅逐出隊,而不是站在員工角度,和他溝通。這種行為可以理解,因為找刺頭溝通很煩,再說替換他毫不費力。這樣的資深的項目經理,往往并沒有多少管理經 驗(管理=管人+管事),因為權力并不是領導力,權力并不會帶來真正高效的的管理:員工主動性、責任心。再說,他并沒 有利用好資源。如果該隊員是他帶入的,這樣做,是一種對己對人都不負責的行為。對于項目經理的他,選擇即責任。

          posted @ 2011-12-07 11:31 順其自然EVO 閱讀(137) | 評論 (0)編輯 收藏

          針對Linux集群的高級監控工具sinfo概述

           你是不是面臨這種情況:想搭建某種網絡集群,但又要處理許多不同的計算機,想密切跟蹤這所有計算機幾乎是不可能的事?如果你負責滿滿一屋子的計算機,還要負責使用這些機器的那些用戶,又該如何是好?sinfo也許正是你苦苦尋覓的那款工具。Freshmeat網站上的介紹如下:

            Sinfo是一款監視工具,使用廣播方案來發布關于你本地網絡上每一臺計算機的運行狀況的信息。它支持顯示多方面的內容,比如處理器、內存使用情況、網絡負載以及關于每一臺計算機上五個主要進程的信息。Sinfo使用ncurses,以一目了然的方式來顯示信息。

            Sinfo可以顯示關于多臺計算機的系統信息,以便管理。使用的時候可以通過-s選項查看更多信息。

            安裝過程

            如果你使用基于Debian的系統,比如Debian和Ubuntu等系統,可以使用二進制包,可以在你的repo中找一下。考慮到該軟件包括了一個啟動守護程序sinfod,我強烈建議使用這個可選的二進制文件,因為這個過程的許多方面實現了自動化(它也是我在這里探討的版本)。不過,為了確保發行版中立,與往常一樣,我還在安裝過程中介紹了源版本。

            說明文檔對代碼庫的要求如下:

            ● ncurses:用于終端處理的代碼庫(5.7版本)。

            ● boost:可移植的C++源代碼庫,使用Boost.Bind和Boost.Signals(1.42版本)。

            ● asio (>=1.1.0):asio是一個跨平臺的C++代碼庫,用于網絡編程(1.4.1版本)。

            如果你通過源代碼編譯,還需要上面這些代碼庫的開發包(-dev)。libboost-下的開發包的數量相當多,所以要是你在編譯過程中遇到了任何問題,請先檢查libboost是不是安裝全了。

            對于使用源代碼來運行的那些人來說,一旦你搞定了代碼庫要求,就可以獲取最新的tarball文件(下載地址)。解壓縮,在新的文件夾中打開終端,輸入以下命令:

          $ ./configure
          $ make

            如果你的發行版使用sudo:

          $ sudo make install

            如果你的發行版使用root:

          $ su
          # make install

            在我繼續下文之前,應該解釋一下:sinfo分平常的應用軟件部分和后臺守護程序這兩個部分。守護程序的安裝每個發行版都不同,這部分我就不具體說了,細節可以查看源代碼tarball文件的使用說明文件和官方網站。

            使用

            Sinfo是一款“半圖形用戶界面(GUI)”的命令行程序,使用起來實際上很容易,不過高級用戶會通過命令行的參數選項符讓它處理一些相當出色的任務。想讓該程序在基本模式下運行,只要輸入:

          $ sinfo

            如果你只是在自己的機器上安裝了sinfo,顯示的信息將僅是你這臺機器的信息。你可以從這個屏幕上看到可用內存、處理器占用率和主機名稱等信息。文末的附錄列出了適用的快捷鍵命令,只要按一個鍵,就可以切換該程序的不同部分。

            不過在這種情況下,sinfo其實只是更漂亮的top而已。使用sinfo的目的是,你可以一下子顯示來自好幾臺機器的信息,以便密切監視局域網的運行情況。

            要做到這一點也很容易:只要在網絡上的其他計算機上也安裝并運行sinfo,運行之后你就會發現兩臺計算機的信息分別在兩個計算機上都有顯示。繼續把它安裝到其他聯網計算機上,顯示列表就會越來越長。

            這些只是基本功能,更豐富的功能方面又如何呢?很顯然,因篇幅所限,我沒法在這里一一介紹(你其實應該查閱參考手冊頁,了解更多詳細內容),不妨看一下我偏愛使用的一些功能。


           在命令行,如果你添加了-W參數選項符(或者--wwwmode),就像這樣:

          $ sinfo -W

            輸出就會從平常的類似top的屏幕變出HTML輸出——對于喜歡借助自動化網頁等方面進行遠程管理的那些人來說,這非常方便。

            在編寫某種命令行腳本時,你可以添加參數選項符-s(或者--ysteminfo)輸出一大段重要的系統信息。舉例來說,我的兩臺機器顯示了以下的額外信息:

          192.168.1.2   knightro-bigdesktop i686
          ↪Linux 2.6.32-27-generic #49-Ubuntu SMP Wed De
          cpus: 4  MHz:  800.0
          RAM: 3276.5 MByte   swap: 7629.4 Mbyte
          load 1min:  0.0   load 5min:  0.1   load 15min:  0.1

          192.168.1.1   nhoj-desktop x86_64
          ↪Linux 2.6.38-8-generic #42-Ubuntu SMP Mon Apr 11 0
          cpus: 2  MHz: 1000.0
          RAM: 2007.6 MByte   swap: 2047.3 Mbyte
          load 1min:  0.1   load 5min:  0.2   load 15min:  0.1
          uptime    0 days, 19:13:03

            這樣一種信息表明sinfo有許多潛在用途,我立即想到了可以在局域網派對(LAN party)上用于監視和故障排除。要是任何一個節點有問題,主機在試圖隔離這個問題時很可能就能夠立即著手處理。

            結語

            sinfo設計精巧,安裝方便,我認為這款程序會很快闖出自己的一片天地。但愿它會像其他標準應用軟件那樣變得司空見慣,成為一款常用工具。也許對它進行移植就能實現這個目標。

            附錄:sinfo鍵盤命令

            ● q鍵—退出sinfo。

            ● Page up鍵, Page down鍵 — 滾動屏幕,每次滾動一頁。

            ● Up arrow/u鍵, down arrow/d鍵 —滾動屏幕,每次滾動一行。

            ● Home鍵—跳到最上面一行。

            ● s鍵 — 切換顯示系統信息。

            ● o鍵 — 切換顯示你自己機器的進程。

            ● n鍵 — 切換顯示網絡信息。

            ● D鍵 — 切換顯示磁盤負載。

            ● t鍵 — 切換顯示主要的X個進程。

            ● c鍵 — 將處理器負載條形圖的標度從log(對數模式)、lin(線性模式)切換至full(全模式)。

          posted @ 2011-12-07 11:30 順其自然EVO 閱讀(193) | 評論 (0)編輯 收藏

          QL Server數據庫占用過多內存的解決方法

          QL Server數據庫占用過多內存的解決方法

           經常有網友會問,SQL Server占用了太多的內存,而且還會不斷的增長;或者說已經設置了使用內存,可它沒有用到那么多,這是怎么一回事兒呢?

            下面,我們來具體看以看SQL Server是怎樣使用內存的。

            最大的開銷一般是用于數據緩存,如果內存足夠,它會把用過的數據和覺得你會用到的數據統統扔到內存中,直到內存不足的時候,才把命中率低的數據給清掉。所以一般我們在看statistics io的時候,看到的physics read都是0。

            其次就是查詢的開銷,一般地說,hash join是會帶來比較大的內存開銷的,而merge join和nested loop的開銷比較小,還有排序和中間表、游標也是會有比較大的開銷的。所以用于關聯和排序的列上一般需要有索引。

            再次就是對執行計劃、系統數據的存儲,這些都是比較小的。

            我們先來看數據緩存對性能的影響,如果系統中沒有其它應用程序來爭奪內存,數據緩存一般是越多越好,甚至有些時候我們會強行把一些數據pin在高速緩存中。但是如果有其它應用程序,雖然在需要的時候MS SQL會釋放內存,但是線程切換、IO等待這些工作也是需要時間的,所以就會造成性能的降低。這樣我們就必須設置MS SQL的最大內存使用。可以在SQL Server 屬性(內存選項卡)中找到配置最大使用內存的地方,或者也可以使用sp_configure來完成。如果沒有其它應用程序,那么就不要限制MS SQL對內存的使用。

            最后我們來看查詢的開銷,這個開銷顯然是越低越好,因為我們不能從中得到好處,相反,使用了越多的內存多半意味著查詢速度的降低。所以我們一般要避免中間表和游標的使用,在經常作關聯和排序的列上建立索引。

          posted @ 2011-12-07 11:29 順其自然EVO 閱讀(187) | 評論 (0)編輯 收藏

          從思路開始 Java如何實現條件編譯

           條件編譯絕對是一個好東西。如在C或CPP中,可以通過預處理語句來實現條件編譯。代碼如下:

        1. #IFDEF DEBUG 
        2. #UNDEF DEBUG 
        3. #ENDIF 
        4. #define DEBUG 
        5. #IFDEF DEBUUG 
        6.   /* 
        7.    code block 1 
        8.    */ 
        9. #ELSE 
        10.   /* 
        11.    code block 2 
        12.   */ 
        13. #ENDIF
        14.   但是在JAVA中卻沒有預處理,宏定義這些東西,而有時在一些項目中,我們又需要條件編譯。那么,在JAVA中,該如何實現條件編譯呢?

            我們來看一個例子。

            編寫一個helloworld程序。代碼如下:

        15. public class Hello { 
        16.     public static void main(String[] args) { 
        17.         System.out.println("Hello, world!"); 
        18.     } 
        19. }
        20.   保存為Hello.java并編譯,得到一個class文件,并且觀察到文件大小是417字節。然后我們對這個文件進行反編譯,用jd-gui。得到代碼如下:

        21. import java.io.PrintStream; 
        22. public class Hello 
        23.   public static void main(String[] paramArrayOfString) 
        24.   { 
        25.     System.out.println("Hello, world!"); 
        26.   } 
        27. }
        28.   得到這個有什么用呢?

            現在我們再來對源代碼進行修改,修改后的代碼如下。

        29. public class Hello { 
        30.     public static void main(String[] args) { 
        31.         if(false) { 
        32.             System.out.println("Hello, world!"); 
        33.         } 
        34.     } 
        35. }
        36.   進行編譯,這時我們再看它的大小,只有255字節。怎樣?想到什么了吧?沒錯,編譯器會對代碼進行優化,對于條件永遠為false的語句,JAVA編譯器將不會對其生成字節碼。下面我們再來對該class文件進行反編譯,果然代碼如下:

        37. public class Hello 
        38.   public static void main(String[] paramArrayOfString) 
        39.   { 
        40.   } 
        41. }


        42.  利用JAVA編譯的這一優化機制,我們就可以實現JAVA的條件編譯了。

        43. public class Hello { 
        44.     public static void main(String[] args) { 
        45.         if(false) { 
        46.             System.out.println("Hello, world!"); 
        47.         } 
        48.     } 
        49. }
        50.   定義一個final的變量,然后再在if語句中使用。代碼如下:

        51. public class Hello { 
        52.     public static void main(String[] args) { 
        53.         final boolean DEBUG = true
        54.         if(DEBUG) { 
        55.             System.out.println("Hello, world!"); 
        56.         } 
        57.     } 
        58. }
        59.   當條件編譯使用得多時,上面將極不利于代碼的修改及維護,這時就可以用一種更為靈活的方法。定義一個靜態類,里面專門定義用來控制條件編譯的變量。然后再在具體的代碼中導入該類,使用這些final變量。代碼如下:

        60. public class DebugConfig { 
        61.     public static final boolean BLUETOOTH_DEBUG = false
        62.     public static final boolean WIRELESS_DEBUG = false
        63. }
        64. if ( DebugConfig.BLUETOOTH_DEBUG) { 
        65.     // TODO 
        66. }
        67. posted @ 2011-12-07 11:25 順其自然EVO 閱讀(174) | 評論 (0)編輯 收藏

          測試用例之度——系列之顆粒度(上)

          測試用例是測試工作的核心。測試工作是講究投入產出比的工作,這也是測試用例設計的指導思想。

            測試用例有度的概念,正如亞里士多德在《倫理學》中討論道德為例:道德意味著過與不及之間的狀態。面向測試用例,網上流傳著這么一句話:“不同的機構會有不同的測試目的;相同的機構也可能有不同測試目的,可能是測試不同區域或是對同一區域的不同層次的測試”

            下面就列舉測試用例設計的方方面面,看不同的團隊,不同的測試目的,如何把握測試用例設計之度。

            顆粒度:

            顆粒度的粗細,有無標準?什么是粗?什么是細?

            1、以功能點劃分?

            僅僅覆蓋所有的功能性需求為粗?

            僅僅正向覆蓋所有的功能需求(功能、性能)為粗?

            正向/負向覆蓋所有的功能需求(功能、性能)以及正向覆蓋性能需求為粗?

            正向/負向覆蓋所有的需求為細?覆蓋到產品包,涵蓋兼容性、升級、安裝、易用性為細?

            2、以STEP劃分?

            每條用例有一個STEP為粗,三?五?十為細?以上為細?

            以測試設計思路的體現?

            只采用正向為粗?只采用正/負向為粗?考慮應用場景為細?考慮業務邏輯為細?

            3、以數量級?

            百條?千條?萬條?

            4、以數據覆蓋?

            等價類是粗?窮舉是細?

            每個人、每個機構判定測試用例粗細的標準都不一樣,沒有標準的答案。所以測試用例顆粒度的粗細,本身就是一個相對而言的標準。

            嘗試用圖示來表示顆粒度粗細的常規概念:




           測試用例顆粒度粗、細的特點是什么?

            用例設計分析:

            粗顆粒度面向宏觀,面向正向的功能點、大的功能模塊和整體性,體現測試用例的設計思路;細顆粒度面向微觀,面對具體的一個個功能點的正向/負向邏輯,體現測試用例的細節和完備性。

            面對測試執行人員:

            粗顆粒度用例不容易被測試新手執行,因為很多約定成俗的操作、現象,甚至行業術語都不清楚。細顆粒度用例相對較易被測試新手執行。

            覆蓋度:

            粗顆粒度覆蓋度可能小于細顆粒度用例(粗顆粒度只覆蓋全部正向和部分負向,細顆粒度覆蓋全部正向、負向、其他等);但還有一種可能性,就是粗細用例均覆蓋全面,但是深度不同。類似下雨的降雨量不同,對農作物(產品)的意義不同。

            可維護性:

            毫無疑問,測試用例和需求的匹配,測試用例本身的維護是大多數團隊的工作難點重點,粗顆粒度便于維護,方便和需求保持高度一致;細顆粒度用例,越細越不容易維護,維護成本過大,特別是需求頻繁變更會導致不可維護。

            類似的概念,比如自動化測試環節,GUI不停改變導致的腳本重寫類似。

            時間:

            粗顆粒度構架和評審的時間較短,適合周期較緊的項目;細顆粒度構建和編寫的時間較長,適合周期寬松或更傾向于質量的項目。

            資源:

            粗顆粒度占用資源較少(人力、評審、會議室等),適合小團隊或同一團隊多項目模式;細顆粒度占用資源較多,適合大團隊或單一項目模式。

            風險:

            毫無疑問,粗顆粒度用例的風險是漏測,存在很大概率漏測的風險,依賴于測試人員的個人素質;細顆粒度也存在漏測,不過相對更可能是測試人員自己的想當然跳過用例不執行。

            細顆粒度用例最大的風險就是可維護性,或者投入產出比。

          posted @ 2011-12-06 11:41 順其自然EVO 閱讀(891) | 評論 (0)編輯 收藏

          開發的自測寶典

           常常會聽到說開發自測之后主流程都走不通,常常會遇到測試同學對著開發自測的結果直搖頭,常常會自己心里覺得開發自測之說不靠譜。

            不知道這個現象是不是普遍,不過卻很讓測試同學頭痛。以開發自測為主的項目,結果測試同學還是投入大量的時間去執行測試,來保證項目質量。說開發冒煙自測通過再提交測試,結果測試同學冒煙測試時仍不通過。

            有過幾多次吐血經歷之后,有了一些小小的經驗,貌似可以提高開發自測質量。

            提供測試用例,尤其要標注冒煙用例。因為開發在做測試時往往是遵循自己開發的思路來執行,很可能遺漏一些場景及步驟,所以提供測試用例,開發就可以根據用例來進行執行。

            有了用例結果提交的代碼還是冒煙不通過,怎么辦!!看開發同學執行一個冒煙用例,要了解為什么開發根據用例來執行用例還會出現冒煙不通過,是不理解用例還是用例寫的不到位。

            提供測試數據給開發同學。開發同學可能只了解自己開發模塊的相關業務,對于準備測試數據確實不是開發同學的強項,而且開發同學準備的測試數據往往會按照代碼邏輯來準備。所以測試同學可以站在用戶的角度準備測試數據來進行測試更容易發現問題。

            測試同學把關邊緣用例。可能開發同學比較奔放吧,要不然咋體現測試同學比較細心呢。有些邊緣業務還是需要測試同學自己把關,尤其是應用間有交互的模塊,需要多關注。

            測試同學參與驗證bug,執行相關模塊用例。我想測試同學在驗證bug的時候常說的一句就是“還是有問題”,這個很難讓人淡定,所以最好還是測試同學參與一起驗證BUG。因為已經發現的問題,再未被解決發布到線上,這個就比較悲劇。還有個現象就是修復了一個BUG引發新的問題,測試同學會本身有一種慣性測試的特點——就是測試關聯模塊,這點可以比較好的避免新問題的遺漏。

            讓開發執行引發bug的用例。這個不知道有沒有效果,本身這點的出發點是為了讓開發可以bug身上找出靈感,想想代碼的其他地方有沒有缺陷或者漏洞。

            最后一點是兼容性的測試。這個是跟前端關系很大,前端出現的很多BUG就是兼容性bug了。提醒前端同學在自測的時候要注意兼容性問題,目前要求測試的瀏覽器有IE6,7,8;firefox;chrome。

            差不多使上這些絕招,相信開發的自測會變得靠譜起來的。

          posted @ 2011-12-06 11:40 順其自然EVO 閱讀(134) | 評論 (0)編輯 收藏

          如何有效實現軟件的需求管理(3)

          如何有效實現軟件的需求管理(3)

           【本篇為《如何有效實現軟件的需求管理》第三篇,(第一篇第二篇)】

            第二階段:需求分析與設計(怎么去做)

            既然需求已經獲取了,也就是說客戶已經跟我們說了要做什么或者我們自己想出來的一些需要做的功能,好了,那現在就真正開始進入需求管理階段了。

            首先就是需求分析階段了,所謂的需求分析,簡單點來說就是把獲取的需求分析一下,看看是否真的是客戶所想的,看看是否是我們產品能做的。 有時候一個需求就是客戶一句話,但是真正理解起來并不是一句話就能解決的,所以你可能需要再跟客戶確認,了解他們的真實意圖。(下面就是一張經典的需求分析出錯的圖,呵呵,我大學時老師講到過,這次碰巧又被我看到了,就借來一用)

            對于一個需求而言,它不是簡簡單單一個功能上的操作,它有可能是一個性能需求,也有可能是安全保密需求,甚至還有可能是用戶接口需求、成本消耗需求、可靠性需求等,所以在需求分析的階段,不是說跟客戶交流幾句話就能把這個需求完全搞清楚的,而且即使搞清楚了這個需求,能不能做(可行性)也不可能一下子想清楚。

            所以為了解決這種問題,各種需求分析的方法也相應而生。如果你在大學的時候學過軟件工程的話,可能你會記得像結構化分析方法之類的方法,什么數據流程圖啊、數據字典啊、判定表啊,等等,也許當初你為了應付考試,就匆匆背了一下,到現在想必也應該忘了,即使你當初很用心地去看了,去理解了,我相信沒有真正在工作中用到的話,你其實沒有真正理解它們。

            不過,如果你想從事需求分析相關的工作,我可以告訴你,這些知識還是很有用的,需求分析還是需要用到它們的,當然很多時候你應該不會直接用到這些理論,但是總是間接的用了體現它們思想的工具。(比如UML建模)

            今天談的是需求的管理,所以對于怎么做需求分析這種技術性的活,我不多說了,因為前面也說了,這個靠一篇文章是不能教會的,要真的教會我可能得出一本書了,呵呵。所以我還是側重于如何去管理。

            我們自己公司經常用到的需求分析建模工具是FreeMind,基于思維導圖原理,還行挺好用,之前用它的原因是我們用的需求管理工具TechExcel的DevSpec自帶了這個小工具,用用挺好用,而且可以與需求點以及相關文檔做關聯,實時同步需求的變更,所以就用上了,其實以前也用過Visio,也挺好的,不過白貓黑貓,能抓老鼠就是好貓,只要適合就行了。(下面是FreeMind的截圖,功能還是很強大的,下面也會具體談到)

            談到建模,也許有人問,為什么要建模,建模有啥好處,呵呵,這個問題本來不想回答,但是總是有人在問。

            一方面,咱們在開發軟件或者硬件,但是你拿到需求后不可能馬上就能給客戶看到這個產品是怎樣的,所以你有必要做個模型出來,讓客戶能看看漲什么樣子,是不是符合他們的要求,這種就是簡單的建模,對于硬件而言,你可以把縮小版的樣子給客戶看,對于軟件而言,你可以把這個軟件的架構啊,可以實現的功能啊、數據流啊、程序流啊之類的列出來讓客戶去看;

            另一方面,我們在實際開發中,可能有很多地方不能實際去驗證,需要通過建模方式模擬驗證,比如原子彈爆炸,我們不可能天天去爆炸一顆原子彈去驗證是否符合設計,而是通過仿真模擬來驗證,輸入的數據跟真實原子彈的實物數據一樣,然后配合實際的物理與化學邏輯,用工具模擬出爆炸情況。

            (未完待續

          posted @ 2011-12-06 11:35 順其自然EVO 閱讀(208) | 評論 (0)編輯 收藏

          LoadRunner前傳:壓力測試前的分析準備工作

          LoadRunner只是一個壓力測試的實施工具,相當于具體執行測試的人員。測試的執行固然重要,但其一舉一動必須按照既定的計劃進行,所以說測試計劃(方案)才是“運籌于帷幄之中”的“大將”。

            今天的話題就是在LoadRunner實施之前進行的準備工作——測試方案。在測試方案中應該存在幾幅比較重要的圖。如果沒有這幾幅圖,壓力測試的準備工作不能算完善。

            1、系統的拓撲結構圖,如:

            2、任務分布圖

            主要描述在一天內,有多少并發用戶會進行什么操作。如:

            3、Transaction Mix

            主要描述:

            ×一天內平均有多少業務,最多時會發生多少業務?




            4、User Profile

            描述的了實際的用戶使用了系統的哪些功能,以及所占比例的情況。

            有了以上的幾幅圖后,LoadRunner專家在設計腳本、安排負載時才能有章可循,這樣測試的結果才能最大程度的接近實際狀況,否則只能是盲人摸象。

            注:以上的圖形引用自LoadRunner Workbook。



          posted @ 2011-12-06 11:34 順其自然EVO 閱讀(197) | 評論 (0)編輯 收藏

          僅列出標題
          共394頁: First 上一頁 351 352 353 354 355 356 357 358 359 下一頁 Last 
          <2025年7月>
          293012345
          6789101112
          13141516171819
          20212223242526
          272829303112
          3456789

          導航

          統計

          常用鏈接

          留言簿(55)

          隨筆分類

          隨筆檔案

          文章分類

          文章檔案

          搜索

          最新評論

          閱讀排行榜

          評論排行榜

          主站蜘蛛池模板: 武安市| 桑日县| 阿拉善盟| 泽库县| 武邑县| 利川市| 横山县| 靖宇县| 东乡族自治县| 中西区| 明水县| 永登县| 精河县| 武义县| 东兰县| 丽江市| 囊谦县| 科尔| 曲水县| 丹寨县| 米林县| 马龙县| 申扎县| 南澳县| 凤山市| 龙州县| 贵港市| 安阳市| 南皮县| 凉山| 大新县| 哈尔滨市| 托里县| 沽源县| 常德市| 宜阳县| 金昌市| 怀来县| 公安县| 个旧市| 乐平市|