qileilove

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

          淺談軟件項目管理之測試

           筆者從事軟件行業相關工作將近十年,其中與測試相關時間有7年之久,現淺談軟件項目管理中測試的必要性,供大家參考。

            一、測試的必要性

            為什么需要測試,那是因為由于分工的精細化,軟件開發必須經歷客戶、需求、設計、開發多個環節。為了保證最終的結果符合要求,上下游是需要確認的。

            用戶告訴我們:我需要什么?軟件企業需要在理解正確、表達正確的情況下完成需求規則說明書,把客戶的原始需求轉變為IT需求,表達出能夠提供什么

            需求的下一環節是設計,設計主要是要要說清楚:我要讓軟件做什么。需要與前一環節確認理解正確了、設計正確了、表達也正確了

            接下來就是實現了,程序告訴計算機怎么做,最終保證能夠運行出結果,而且運行的結果與用戶要求是相符的。

            正式因為一個項目參與環境眾多,為了保證客戶需求在傳遞過程中盡可能少的丟失,我們需要反復的校驗、確認,也就產生了測試。

            傳統的觀念中把測試定位于從程序員到運行結果這一段,實際上強化每個階段的確認、特別是用戶需求到需求規格的確認,是更能節省時間和成本的方法。

            二、測試管理質量管理之間的關系

            首先回顧一下PMI協會關于質量管理的一些觀點:

            第一點就是質量管理的最終目標是使客戶滿意,質量管理的定義就是理解、評估、定義和管理客戶需求,以達到客戶期望;能使客戶滿意的標準就是符合要求且易于使用。這是一個從項目角度出發提出的概念,針對產品研發也應該是吻合的。研發出的產品是為了賣給客戶的,不是為了孤芳自賞的,所以研發成果是否滿足客戶要求也是至關重要的。

            另外一點就是關于功能性符合度和易用性符合的強調,現在很多企業很容易聚焦于功能而忽視軟件最終是給人使用,是給不同文化層次的客戶使用的,軟件的易用性往往能夠推翻軟件企業為了實現功能所做的一切努力。

            舉例來說,有一個項目,需要實現兩種產品單據的傳遞,因為交付工期很短,我們的開發人員加班加點的完成了功能,但是客戶卻拒絕接收。原因在于引入單據之前需要進行兩種產品基礎資料的匹配,開發實現了這個功能,卻忽視了客戶有大概2000條基礎資料需要匹配,沒有提供批量匹配的功能,最終客戶試用中感覺工作量無法接受,拒絕驗收了。前面所有加班所有的努力都白費,原因就是忽略客戶的易用性需求。

            可能對于產品研發而言,沒有這么強硬的結果,但是一些功能不好用對客戶滿意度的影響還是相當多的。所以個人認為把產品通過測試的標準定位與符合要求且易于使用是非常恰當的。

            第二個觀點是預防勝于檢查,這是很容易明白,但是實際過程中又不大容易做到的。因為客戶的壓力,很多企業的發版是很頻繁的,發版之后是否有人來總結這次版本研發中碰到了什么問題,哪些缺陷影響了發版時間,下次版本中需要一些什么預防措施?如果沒有這樣的一個過程,沒有缺陷的一套分析和預防機制,很多類似的問題會不斷的出現,版本的質量以及補丁的壓力會像滾雪球一樣越滾越大,最終使得整個研發團隊難以負荷。

            第三個觀點是關于管理層責任的,提出PDCA循環的戴明就說,85%的質量問題應該由管理層負責,只有15%的責任是團隊負責。很淺顯易懂的一個道理,假設公司老板對你說,這個版本你一定要保證質量,有一個問題都不能放行!你想這個版本質量能差嗎?


            換一種場景,你告訴老板有幾個核心問題還沒有解決,沒有達到發版條件,老板卻說,客戶壓力大,你先發出去,后面再出補丁!結果又會如何呢?

            老板當然不可能忽視客戶對工期的要求,不惜一切代價的保證質量,但是當成本和質量進行權衡的時候,老板會偏重哪一個,直接影響最終產品的質量;

            老板在質量文化減少方面、過程改進方面重視的程度,也將直接影響這個公司所有產品的質量。

            這就是管理層的責任!

            提出這個觀點的戴明還有一個觀點與PMP相關體系非常符合,即質量并不是由工作人員的能力決定的,而是取決于如何開展工作的程序和制度。之所以要進行項目管理的認證,就是要讓項目管理的整體能力不因為個人能力產生較大起伏,如果都能按照組織確定的流程進行相關活動,最低水平也能被保證。

            第四個觀點是持續改進原則,持續地、漸進地改變來改善情況,中國的俗話也說的好:飯要一口一口的吃,別想一口吃成一個胖子。

            那測試管理到底與質量管理有什么關系呢?

            在量管理活動中,測試是質量控制的重要手段。

            三、測試相關原則

            上圖中也提到了測試的基本原則,在此做簡單描述,歡迎大家拍磚。

            1、盡早測試原則

            盡早測試原則與馬丁分析出來的結論有非常大的關系,一個缺陷在需求階段被發現所產生的糾正費用是產品交付后維護階段發生費用的兩百分之一。

            有軟件公司也曾經做了簡單測算,1個缺陷留到客戶處被發現,所耗費的成本在50萬左右。

            或許引起客戶怨聲載道的嚴重缺陷,在需求環節解決只需要增加一行字的清晰描述,在編碼階段只需要多增加幾行代碼,可是一旦到了客戶哪里,便成了投訴、安撫、補丁、責任追究等一系列的緊急事件。

            2、Good-enough原則

            Good-enough原則其實是針對測試本環節來說的,也體現了項目管理思想中關于質量和成本直接的關系。如果以精益求精的思想,能夠到底“零缺陷”是最為完美的一種狀態。可是從投入產出的衡量來說,零缺陷是很不劃算的。理想狀態下的測試系統,根據帕累托的二八原則,研發測試應該至少發現80%的bug,而最好只有5%的缺陷是由客戶發現的。之所以要推行good-enough的原則,是因為在項目中時間、成本、質量是永遠不可調和的矛盾,不論是高層還是基層的測試負責人,軟件項目管理人員都需要對自己負責領域進行一定平衡和妥協。

            總而言之,做好了測試的管理,對于軟件項目的成本、工期和質量管理都有非常大的好處,但是目前國內的很多軟件企業卻不重視,特別是針對客戶的定制項目,希望未來一段時間能夠得到改觀。

          posted @ 2011-11-21 13:44 順其自然EVO 閱讀(143) | 評論 (0)編輯 收藏

          跨出編寫300個用例的第一步

          接到一個項目,一個大日常,跨很多應用,形成了標準的開發測試N:1,滿心歡喜覺得自己終于可以獨當一面了。可是當拿到N個UC的時候,就有種瞬間傻眼的感覺。

            但是由于越覺得這個工程很龐大,越想早點開始啟動自己的工作,遂會好不容易找到一個突破口就急于開始寫用例。

            剛冥思苦想出第一個文件夾的名字后,在這個模塊下,想到什么寫什么,想不出來的時候,又開始想第二個文件夾的名字,想下一個模塊要寫什么。當寫到第十幾個文件夾的時候突然想起第N個文件夾中好像少了一個用例,又每個文件夾,點開看里面的內容,回顧這個文件夾大致覆蓋了哪些用例,看看缺少的這個用例該怎么補。也許慶幸的是,找到了那個文件夾補充好這個用例,但是當你寫到第幾十個文件夾時,過了幾天以后,想到好像漏覆蓋了什么功能點,那可能不是就僅僅浪費幾分鐘去找這個文件夾,而是可能會花上大段的時間去回想自己寫了什么,這個時候的思路打斷就會讓你覺得不知道下一步該怎么走,思路越來越亂,下面的用例到底應該以什么緯度進行下去,還有多少的用例被遺漏掉了,什么用例是不需要寫,什么用例是需要覆蓋的,突然就會對用例有種不可控的感覺。

            但是,如果一個測試人員對自己的用例都無法控制,那還有誰可以來了解用例的覆蓋度,用例的緯度。后面的回歸測試同學,如何來有序的進行回歸,用例的遷移該會是多么痛苦的一件事。

            其實每個人的測試思路會不同,測試習慣也會不同,所以用例可能就會用不同的方式來寫。這些都固然沒錯,但是用例必須要有個緯度劃分,有個整體的一個流線。有利于測試,也有利于用例的review及評審,思維可以順著下來。

            老人是一個很好的燈塔,他可以指引你怎么前進,有時候自己真的一點沒有頭緒的時候,可以看看以前的用例以怎樣的緯度劃分,找個較熟悉該應用的老大,問問如果是你,會怎么著手寫這些用例。千萬不要在自己沒有頭緒的時候就開始寫第一個用例,有可能會越寫越亂,寫到最后漏了一大片,冗余了一大片。先確定好用例大體以怎么樣的幾個大方向來寫,比如,按照應用來分,sell一塊,mickley一塊,forest一塊;按照測試順序,先后臺建類目,再前臺發布,等等。

            確定一個方案還不夠的,這個只是個骨架,這些只是好讓你定好一級的文件夾名字。不要就開始寫用例了,要不然你定好了幾個文件夾名字后又會開始不知道怎么入手了,文件夾下要測試哪些東西呢?所以下面的測試設計很重要,列好幾個一級文件夾,對照UC看下一級文件夾是什么,一直設計到葉子文件夾要寫哪些功能點。最好可以進行測試設計評審,讓開發和老人一起評估下,有沒有測試用例覆蓋漏掉的點,這個時候修改方向,補充漏寫的點,很容易,一目了然。

            雖然這可能會花去你一天的時間,你會覺得很可惜,但是這對后面的工作將會有很大的作用,對功能點已經比較熟悉,對用例編寫的思路也很清晰,只要對照設計一步一步往下寫就可以了,就不用說動不動就停下來絞盡腦汁在想要寫什么東西,尤其是對新人來說,對已有的用例也不熟悉,不知道到底應該寫哪些用例,需要測試哪些點,這個就尤為重要了。

            300個用例并不可怕,但是不可控的100個用例就會讓人很昏頭轉向。定好方向,做好設計,建好層級,個個攻破,500個用例都將是可控的。

          posted @ 2011-11-21 13:44 順其自然EVO 閱讀(146) | 評論 (0)編輯 收藏

          B/S架構測試環境搭建_SybaseASE篇(Win32系統)

           前言:測試過程中需要使用SybaseASE數據庫,抽空安裝測試下,由于是摸索,也遇到些問題,剛入門,不對之處還請多多指教。

            一、創建服務器:

            (1)在安裝的結束階段Sybase ASE已經提示創建服務器了。如果接手的是別人的環境,那么先創建,在開始-->所有程序—>Sybase—>Sybase Central v4.3,打開Sybase Central界面如圖一,點擊“實用程序”,查看其詳細,雙擊“服務器配置”打開其配置服務器的對話框。

          圖1 Server服務器配置頁面

            (2)點擊創建服務器,輸入服務器名稱,進入服務器頁大小,這個根據Sybase的使用情況來選擇,如果使用量比較大的話建議選擇8K或者16K,只是一般使用的話4K就可以了。

            (3)接下來是設置Master(系統數據庫)設備大小和位置,此處有Master的初始數據,你可以使用,不過如果你不是第一個建立這個服務器的話,還是選擇一個自定義的比較好。如果使用別的服務器的Master,其他服務器的系統數據庫將被覆蓋,導致別人的服務器無法被正常使用。

          圖2 設置Master的大小和位置

            (4)接下來設置系統過程設備大小,系統都提供了缺省值,如果需要修改又不知道是否正確,幫助中有有關此處的詳細說明。繼續后設置系統DB的大小,個人覺得設置5M就可以了。畢竟系統數據庫在創建完成后不會有大的動作了。

            (5)接下來就是配置缺省的XP服務器了(網絡地址),默認情況下當然是指向本機了,除非你保證你的默認Server永久性開機,否則最好還是本機,方便出問題時快速檢查。點擊“配置默認服務器”-->網絡地址—>增加,協議選擇TCP,輸入本機IP,兩次確定后設置完成。

            創建數據大約需要一分鐘,創建完成,在Sybase Central頁面上測試連接。

          圖3 測試連接

            系統有默認的用戶sa,沒有密碼。

           二、創建數據庫:

            (1)前面已經提及,在創建服務器過程中附帶創建的是系統數據庫,日常測試使用的用戶數據庫需要單獨創建。在創建數據庫之前,我們需要先創建數據庫設備,相當于表空間(和Oracle有那么點區別,Oracle是建用戶(Schema)時用的Default Tablespace,此處是建數據庫時選擇存儲空間),填寫對應的大小,序號系統會默認分配,不用管。

          圖4 使用創建的數據庫設備

            (2)創建數據庫,此處即沒什么需要注意的地方了,選擇剛剛創建的數據庫設備,并填寫該數據庫需要使用的大小,其他按照提示一步步走完數據庫就創建成功了。

            三、創建用戶及授權:

            (1)首先創建登陸名,在登錄選項中添加新的登錄名,輸入密碼,選擇默認的數據庫,提交完成。

            (2)雙擊剛剛創建的登錄名,在“角色”一欄中給其授權。

            (3)我們可以看到在登錄名最后一欄中的用戶,用于該登錄名映射的用戶名。再打開數據庫查看,果然,里面有用戶和允許對用戶的CRUD和對用戶的分組(缺省的是public組)、授權。和什么數據庫很像?對咯,SQLServer。登錄名和用戶名的區別和聯系已經在前一篇講過,不再啰嗦。

            至此,SybaseASE的表空間(數據庫設備)、數據庫,登錄名、用戶已經創建完成,以后會把常用的SQL語句總結放上來,方便我們的環境更好的工作。

          posted @ 2011-11-21 13:37 順其自然EVO 閱讀(236) | 評論 (0)編輯 收藏

          B/S架構測試環境搭建_SybaseASE篇(Win32系統)

           序言:什么是自動化測試平臺?這個是沒有一個好的定義的,個人拙見,自動化測試平臺就是根據自身公司或者部門的流程,將自動化測試的需求融于上述測試流程,然后提供一個軟件平臺的形式表現出來,也就是用規范和協議的形式表現出的一套自動化測試體系。

            一、編程工具中的“即插即用”型

            Eclipse平臺是IBM向開發源碼社區捐贈的開發框架,其是一個成熟的、精心設計的以及可擴展的體系結構。這個平臺允許任何人構建與環境和其它工具無縫集成的工具。工具與Eclipse無縫集成的關鍵是插件。除了小型的運行時內核之外,Eclipse中的所有東西都是插件。從這個角度來講,所有功能部件都是以同等的方式創建的。

            你可以在安裝好的eclipse的文件夾下有一個plugins的文件夾中有其各種插件,eclipse的核心較小,幾乎都是由插件組成,而所有的插件庫有四個基礎庫:

            ● 標準Widget工具包(SWT):Eclipse中處處使用的圖形化組件:按鈕,圖像、光標、標簽等等。布局管理類。通常這個庫被用于代替Swing。

            ● JFace:菜單、工具條、對話框、參數選擇、字體、圖像、文本文件的類和向導基類。

            ● 插件開發環境(PDE):輔助數據操作、擴展、建立過程和向導的類。

            ● Java開發者工具包(JDT):用于編程操作Java代碼的類。

            基于這個基礎庫,然后遵照其eclipse開發插件的過程,你就可以將自己的工具與eclipse集成起來,即根據自己的需要去定制自己的開發平臺的需求。

            二、軟件交付平臺的“即插即用”型

            IBM其軟件產品有一個詞叫jazz,之前很不理解這種想法,后來慢慢的為其龐大的理念而感到心動,雖心動卻也只能研究一下。

            Jazz是一個用于整個軟件生命周期的團隊協作平臺,旨在支持跨所有軟件生命周期階段的任務的無縫集成。Jazz平臺的主要作用是為工具編寫人員提供要使用的機制和要遵循的規則,這些機制和規則可產生無縫集成的生命周期工具。這些機制通過定義良好的API來公開。

            Jazz是一個基于客戶端-服務器體系結構的平臺。通常在受保護的服務器級計算機上運行的Jazz服務器承載一組服務,并在其存儲庫中存放數據。遠程客戶端通過網絡使用HTTP與Jazz服務器通信。

            個人理解的話:jazz提供了一個開放式的平臺,其中基于了一些國際上的組件規范(例如:OSGi等,OSGi稱做Java語言的動態模塊系統,它為模塊化應用的開發定義了一個基礎架構。這樣,一個大的系統可以被劃分為很多模塊或組件,其通過標準化的接口進行交互通信),然后,IBM的大多數工具可以集成到這個平臺上成為軟件交互生命周期的一個整體,盡量使得各個工具在使用上能夠進行交互,之后,可以根據自身的開發流程情況,基于軟件實現定制自己的開發和交付流程。

            三、自動化測試平臺的“即插即用”型

            自動化測試中因為其應用特殊性,所以,會有各種工具的使用(界面測試工具、命令行測試工具等)以及各種自動化測試的模式(例如:回歸測試、例行測試等)來提高測試效率。所以,個人覺得,自動化測試也需要提供一個開放式的平臺來集成這些工具和測試模式。

            可以參考的是:開源的自動化測試框架STAF,其提供了一個“即插即用”型的概念,任何工具或者模塊只要遵從其規范,則能作為其中的一個服務與構建與其上的各種服務進行通信。其還是作為一個分布式的框架,其意思即每臺運行STAF的機器都是等同的,都可以擁有各自的功能模塊與數據,也可以在分布式網絡中進行共享與交互。或者,不基于STAF也可以自己進行類似框架的開發,需要的是提供一個標準的接口形式,各個模塊能通過這個標準的接口互相進行交互。

            當然,以上的形式需要根據自身的情況來定,是在自動化測試需求發展到一定程度上,如果連自動化測試需求和流程都沒有定義下來,那么,開發這套平臺的意義將會變得很空洞,而且容易脫離實際需求,反而越走越遠,浪費了成本,所以,“效率為上、需求為導”,不同的時候應該采取不同的策略來應用自動化測試來提高自身的測試效率。

          posted @ 2011-11-21 13:24 順其自然EVO 閱讀(654) | 評論 (0)編輯 收藏

          我對軟件測試行業的看法

           有幾個文章大概的題目如:

            軟件測試行業缺口多少多少萬;
            軟件測試人員比博士還值錢;
            軟件測試越老越吃香;
            軟件測試是金飯碗;

            等等等等。

            以下是我的一些個人看法。

            1、行業

            我們都知道媒體的報到都是因為一些利益驅動的,并不是為了良心和行業的良性發展,要是從工作的角度來說,我覺得他們很到位,但是少了一點,就是社會責任心。做為一個有良知的知識分子,我覺得應該說點事實,不要把一個本來挺好的行業最后糟蹋的不像樣子。做為一個軟件測試從業人員(我從一畢業就開始做軟件測試),我覺得這些都不靠譜。

            在我的記憶中,跟測試同行聊天時,軟件測試行業的缺口是一個所謂的牛人被媒體采訪時問到的。但是這個牛人,自己也沒有做過統計,于是乎,兩眼一轉,把心一橫,在我不知道別人也不可能知道的心態下說出了這么一個數據:大概30萬吧。實際上,這個數據沒有經過任何公開的媒體調查(如果調查了后,就是這個數據,我覺得還有點借鑒意義)。結果就被一些寫手們越扯越大。反正寫錯了,也沒人打屁股,要寫就要引人眼球,可勁的造吧。這種鼓吹的結果就是讓一群人很盲目的進入了這個行業,結果發現根本不是那么一回事。于是經常看到有人問,我什么什么經歷,轉測試行不行呀?就有些人很不負責任的回答:只要努力,就行!我靠,也不想想,人家那么多年的其他行業的經驗,為什么還要轉測試呀?工資也不見得就高(這個問題稍后細說),也不見得輕松,上升空間也不見得有原來的行業多,干嗎要鼓勵人家換這個行業呀?(排除有些人骨子里就喜歡測試這個行業的。另:大部分人工作還是工作,并不是當成事業來做的,所以談不上對哪個行業有非常深的興趣)。

            所以在選擇這個行業的時候,還是需要理智的思考的,曾經有一個朋友,工作大概四五年了,做過:網管、保安、保險推銷等等的工作,技術基本沒有積累。問我:我能不能轉行做測試?我問了他一些基本的計算機知識和測試的基本知識,我說:你還是別轉了,不如做點其他的事情。不過我也說了,我只是提個你不要轉的建議,你要是非想轉,我也可以告訴你要學什么。在很多情況下,我覺得更理性的思考才說出建議和決定比較合理,不要以為有了一份心就什么都有了,兩碼事。因為人的激情是有時間間隔的。

            測試人員的素質要求。可能是因為我進入了這個行業,老是有人在說這個行業的人需要什么樣的技術和素質。大多數的都會提到一個字眼:浮躁。就是測試人員切忌浮躁。我暈,什么人不忌浮躁呀?這是對人的基本素質要求,而不是對測試行業的人的素質要求。可能有人說了,測試嘛,要細心,浮躁了就不能細心了。這種說法貌似合理了。但是,這絕不是測試人員的核心要求。極端一些說(因為極端的假設可以讓問題更清晰),如果一個人只有細心,你是測試招聘人員,你會招嗎?那這里就涉及到另一個問題了:就是要有技術。什么是技術呢?測試行業什么是技術呢?突然有這個問題似乎讓人不知道怎么回答,有一種滿肚子都是話突然之間倒不出來的感覺。于是,冷靜一會,這種喜歡吹噓的人就會擺出一堆話來:測試理論呀、測試方法呀、測試工具呀、測試流程呀等等等不都是技術嗎?在我有限的知識體系里,個人覺得,這些都不是技術,只是測試人員應該有的常識。測試工具的使用只是測試人員應該掌握的技巧。

            2、薪水

            薪水的誘惑。我看到過很多次說軟件測試行業薪水如何如何高?XX出來不是八千就是五千的。還有人說,軟件測試行業是IT中最高薪的行業,越老越值錢!我個人覺得軟件測試行業絕對不是常青樹。也不可能越老越值錢。現在做軟件測試,找工作的人,一堆一堆的。好好看看這個市場,它不是缺少要做軟件測試的人,而是缺少有經驗的人。并且一般的經驗,也不值什么錢。工作三四年(甚至更多)的人,5-6千的人,大有人在,而不是像有些廣告上說的,這個行業進來就是萬兒八千的。以為是找BUG是撿錢玩呀?我遇到的做測試的,工作十年左右的,也不過是在萬元左右。人家這么多年都是白混的呀?在軟件測試行業,從純技術的角度來說:能拿到2萬/月的人,很少很少。(請不要以某個個例來反駁,因為個例沒有意義)。有些人擠破的頭皮進外企。從大局來看(僅個人觀點),外企在國內就沒有真正把技術拿進來過(這里應該說大部分,不能一棍子全打了),所做的也無非是些邊邊角角的苦力活。所以外包才有市場,才會發展起來。幾乎我認識的所有的測試行業的人都說外包沒有技術含量,國內的外企難道不像外包嗎?只是形式不同罷了。就拿中國的某些制造業來說,也有一部分屬于這種狀況,結果金融風暴來了,人家倒了,你也倒了。曾經有不止兩個在軟件業混了十幾年的人跟我說:中國沒有什么技術(我知道這句話有失偏頗,但它反應了一些現狀)。再回到軟件測試這個行業,首先,我認為剛畢業的大學生,不要指望一下子能爬多高。走的不穩總有一天摔倒。如果家里特有錢,像我一華為的同學跟我說的,那里有開著奔馳去上班的,一個月拿幾千塊錢的。人家那是自我實現追求。而我們大部分的人,還是老老實實的,想想這一生應該怎么過,才能買得起房子,買得起個二十萬以下的車吧。軟件測試從業人員,自己把自己一輩子能賺的錢都算算。你這一輩子的閑錢能達到十萬嗎?你敢亂花亂玩嗎?你沒有先消費后還貸嗎?這是時尚,還是不得已而為之?是你的能力不足,還是這個行業已經限制了你的上限?就算是你到了級別,有多少人可以到副總?有多少人是技術總監?就算你是技術總監,又有多少公司的技術總監一年超過30W?我出來工作兩三年之后,就有人說,我的工資漲的飛快。我個人在想,這些錢,還不夠我的生活。因為我也要買房,買車,生兒育女,贍養老人。有沒有想過這些事情,如果全壓在你和你老婆(老公)身上的時候,多少的薪水夠用的?有人也說了,有錢就過有錢人的生活,沒錢就過沒錢人的生活,反正過窮富不是一樣過嗎?一輩子很快就過去了。這種說法是無奈還是滿足現狀?說的時候心酸嗎?看著自己的孩子和別人的孩子上的不一樣的學校。玩的游戲沒有人家玩的好,你什么感覺?就告訴自己,我的能力只能是這樣了嗎?選擇一個行業,你就要知道,這個行業的薪水段在什么樣的層次,就像一個同事跟我說的:一個片警拿一個包出去賭錢,里面都是幾百萬的人民幣。你是不是遺憾自己選錯了行呢?當然不能這樣對比對吧。因為我們靠自己的能力,吃自己的飯。呵呵,這么對比一下就是要看這個文章的人想清楚,你想拿多少工資?這個行業能給你的只有這么多,你自己選擇去吧。當然,也要看清楚的是,這個行業,比出去在大太陽下搬磚強多了。

            好吧,薪水暫時靠一段落。


           3、技術

            技術,真實認真做軟件測試的人應該有這樣一種感覺。軟件測試不容易做。它需要的知識太多了。如果僅玩數據庫,只要把oracle搞的特別精通,我想一年工資二十萬應該沒有什么問題吧。但是軟件測試行業是你要把好幾種工具和語言都玩精通可能才值那么多錢。就拿性能測試來說吧(因為這一塊是我一直做的,拿來打比方應該偏差不會太大),你只會性能測試工具就敢出去要萬元/月以上的工資了嗎?你敢要,誰愿意給呀?別以為自己可以是根蔥了,其實還沒發芽。我們都知道,在軟件測試行業的JD一般都是:OS/network/DB/tools/applications/middleware、還有一些語言呀,腳本(腳本也是一種語言這里分開一下)呀,都包括的,就算不全包括,也要有一部分。你得懂呀?不懂全部,你得懂幾個吧?你不懂,有人懂呀。那工作機會不就沒了嗎?怎么辦呢?學吧。每天晚上搞到一兩點,死勁的玩這些東西,大概找工作的時候,可以跟人侃了。我這個也會了那個也會了。但是呢,不能問深。因為學的廣嘛。所以哪有時間細細的琢磨呢。所以問深了就暈了。人家一看,唉,這個人不求甚解,算了吧。也許很巧合,面試了一家公司,人家問的,也都被你忽悠上來了。總算找一工作。也是刷了好多人的。要是能把上面所說的每個東西,都玩了個精通,那出去找工作,問什么會什么,太牛B了。但是公司毛了,這樣的人,我們能養得起嗎?這種情況很少出現,我們就不去說它了。還要說軟件測試行業。其實我們也知道,軟件測試行業,在要求廣泛的同時,也開始慢慢細化。越來越強調專向發展的人。所以,在進入這個行業的人,不要指望能把所有的公司JD都拿得下來,你只需要考慮是不是能滿足其中一兩種就可以了。并且僅這一兩種也大概夠你玩個十多二十年的。到那時,你已經不值錢了,因為還有一堆堆的年輕人在嗷嗷的叫著找這類的工作。國內工作到四十歲的技術人員,還有純干技術的嗎?(當然是有的,這里我說的是大部分情況下)我也有純技術做了一二十年的同事,他自己也說他這種現象不正常。(這個和國家的福利待遇等都有關系,我這里不再展開說了。)

            4、追逐

            追逐,如果從現在的大學生失業率來看的話,進入這個尚末成熟的軟件測試行業,不見得是件壞事,因為亂世出英雄嘛。當然,在出英雄的前提下,就會有些懷才不遇的人很快的被糊里糊涂地砍倒在戰場上。所以進入這個戰場,就做好看清流彈的準備。不要報怨,認真的走好自己的路,不要和別人對比,因為不成熟的市場是沒有什么可比性的。技術路線和泡沫市場的路線差距還是很大的。當然IT的技術路線和傳統工業的技術路線差距也是很大的。我們基本上也算是產業工人的一部分,但是,我們并不是越老越值錢,如果不盡快在自己老到被人推倒在沙灘上之前趕緊找到自己的位置,相信在自己沒有可利用的價值之后,很快就被淘汰。一個人被利用并不悲哀,悲哀的是沒有可利用的價值。從比較職場的語言來說,我們之所以有工作,是因為老板們或者領導們認為我們還可用,想拿的工資更多,就讓領導們覺得我們還有更多可用的地方。所以,盡量的去追逐那些在市場上看來有價值的知識,從而讓自己的打工路,更平坦。(如果不想打工的話,那就追逐當老板應該有的知識。)不過,要注意這條路上,重點要知道自己追逐的是什么,而不是隨大潮,看著別人玩什么自己也玩什么。很快那些大眾型的知識都不值錢了(IT的更新也是很快的),所以要找準自己的位置。

            謹以此文,描述個人對測試行業的看法。如果打擊到某些人或某類人,請見諒。

          posted @ 2011-11-21 11:59 順其自然EVO 閱讀(1168) | 評論 (0)編輯 收藏

          敏捷測試理論以及實踐(6)

            2、編碼階段:

            完成了需求設計階段,就要開始進入編碼階段了,雖然說開發與測試需要同步的,但是功能還沒做完也沒法同步去測吧,不過還是有事做的,就是可以同步開始寫測試用例,這個就用到DevTest工具了。DevTest主要用于管理測試用例,以及根據測試用例來進行在不同環境下、不同時間下和不同的范圍里進行的手動測試與自動測試,并且可以生成報表供評估測試質量和產品質量。

            也許有人有疑問,敏捷測試還需要測試用例?我的答案還是“是”又“不是”。

            先說“不是”,對于敏捷測試本身而言,我們實際新功能測試中其實沒有用到測試用例,完全是根據設計文檔來進行測試的(也許又有人來問敏捷好像不需要測試文檔,這個在這里不多說,詳見我另外一篇文章《結合工具來實現敏捷開發》),所以這個時候是不需要測試用例的;

            而為什么又說“是”呢?因為敏捷在不同的公司不同的情況可以有不同的實現方式,我們公司不是做項目的而是做產品的,也就是說像微軟Windows一樣,我們公司的產品也是1.0,2.0這樣做下去,現在已經9.0了,在這期間,或多或少有很多功能是在不同版本里都有的,特別是那些基本功能,為了測試新功能是否破壞原有功能,我們需要測試這些老功能是否能正常工作,也許有人說,那我只要在測試新功能時測一下老功能就行了,測試用例也不需要吧?是的,也許你們公司不需要,但是對于我們公司而言,特別對于9.0而言,之前所有版本的功能都是老功能,之前的老功能有幾百個,幾千個,你能在測試新功能時測一下嗎?很顯然,這個是很難做到的,新功能做完時,一般情況,測試人員會檢查是否能正常工作,是否對一些基本功能沒影響,至于對其他看起來不怎么搭嘎的功能其實不太會去關注,而且時間上也不允許。這樣子的話,測試用例就顯得很重要了,因為測試用例從本質上來說就是介紹需要測試的功能點以及怎么去測試它們,把每個版本的每個的功能點都通過測試用例的方式保存下來,測試時想漏掉一個測試點都難。所以測試新功能時沒測到的地方,都可以在用測試用例生成測試任務時重新覆蓋全面,不過這一步由于測試覆蓋面太廣,也就意味著所花時間會很多,所以一般情況下,一部分測試點會用自動化測試工具跑掉,另一部分只能人工來跑的也只在最后系統測試的時候做掉。

            看了這個“是”與“不是”,大家應該知道我們公司的“敏捷測試”其實是結合了敏捷測試與傳統測試,也即是兼顧速度與質量,所以有時候我們稱之為有我們公司特色的敏捷測試,呵呵。

            在寫測試用例的時候,測試人員需要和設計人員進行大量的溝通,以徹底理解這個功能為接下來的實際測試做好準備,“溝通”在敏捷里是一個重要的原則,在實際工作,我們也真正體驗到它的好處,只有通過溝通,幾個部門之間對于產品才有一個認識高度上統一,才能設計出、開發出、測試出一個好的產品來。不過這點,我覺得大家也只能真正通過實踐才能體驗,我說得太多,其實也沒法讓大家信服的。

            3、敏捷測試階段:

            好了,寫完測試用例了,開發也做完幾個功能了,咱們也可以開始測試了,《結合工具來實現敏捷開發》里也講過,我們公司是采用Scrum方式的,所以會生成很多迭代周期(Sprint),每個迭代周期中會從Backlog里分配一些Story來做,咱們測的也就是做好的Story,其實也就是功能點了。

            這部分工作主要在DevTrack中完成

            DevTrack的主要用于開發完成功能點編碼以及測試人員完成敏捷測試。當需求設計完成后,項目經理會通過DevSpec/DevPlan來分配開發任務給相應的開發人員,并且同時生成敏捷測試任務,而開發一旦完成功能以后,就會在DevTrack中把相應的敏捷測試任務打到“可測試”狀態,這樣子,測試人員就開始進行測試了,測試完了,就把任務關掉,這個功能點就算測試完成了,項目經理會通過檢查測試任務是否已經關掉來判斷這個功能是否已經完成。

            由于之前測試人員已經把當前迭代周期中的功能點寫成測試用例了,對于做好的功能點其實已經從理論上很了解了,所以測試起來就“輕車熟路”了。測試總會發現Bug,但是Bug有嚴重和不嚴重之分,我們現在處理Bug的原則是,對于影響到這個功能讓客戶評估的Bug都必須在這個迭代周期和下個迭代周期中修復,這些Bug可能包括報錯,功能徹底沒法工作,也可能包括一些頁面上的美觀,因為我們的產品會定期給客戶做評估,以讓客戶看看做完的功能是否符合他們的要求,所以對于做好的功能點起碼需要能讓客戶能用起來,所以客戶會最直接用到的看到的地方就需要優先處理掉。而對于其他普通的Bug,DevTrack會有專門的一個文件夾保存,這些Bug會在Release之前通過優先級來一一進行修復,有些實在優先級很低的或者暫時不能完成的可能就會推遲到下個版本再做或者直接就不修了,因為有時候修一個Bug可能會帶來一些意想不到的問題,如果可修可不修的Bug,就不需要冒影響產品質量的風險去修了。

            不知道大家有沒有注意到,上面說了Bug需要在這個迭代周期與下個迭代周期中修復,為什么不在這個迭代周期中修復呢,其實是這樣的,因為測試總是在開發后面開始的,如果一個功能點在一個迭代周期的后期完成,從時間上可能測試無法在這個迭代中完成,但是迭代周期的時間又不是想改就可以改的,所以這種情況下,我們就會在下個迭代周期中把這個功能點測完。不過一般情況下,我們還是建議不要延遲到下個迭代周期中完成,因為一個迭代完成后,我們會給一個Build給客戶做評估,如果有沒測試完的功能,可能就有一些潛在的影響客戶使用的Bug,這樣子對銷售就會產生不好的影響。所以,解決的方法就是一個功能點開發完成就必須馬上讓測試測,發現Bug馬上修復,如果有功能點到了迭代末期才做好,則已經Check In代碼確保沒有嚴重Bug(主要是表明和這個功能最基本的使用),沒有Check In 代碼的就等到下一個迭代周期再Check In代碼,測試也推遲到下個迭代中測試。

            就這樣子,迭代周期一個個進行中,開發做了一個個的功能點,然后測試就會把這些測完,在這個周期中,開發與測試的工作量都會在DevTrack中被記錄,主要是花費時間與剩余時間,從而得到了產品未來的一個進度趨勢圖,也就是所謂的燃盡圖。

            4、需求變更:

            敏捷是歡迎變更的,客戶有啥想法可以隨時提出隨時改進,我們公司的產品是定期給客戶一個Build來進行評估的,所以客戶經常會要求做一些更改,對于還沒有測的功能點稍微好一點,因為只要改設計文檔,但是對于已經做完或者正在做的,已經測完或者正在測的呢?答案當然是也得更改,做好的重做,測好的做完重測,對于瀑布模型來說,這個也許是難以想象的,但是對于敏捷來說,這個是家常便飯了。

            在實際操作中,我們可能會用到一個DevSpec的功能,這個功能比較不錯,所以我單獨提出來說一下。有些時候,如果一個功能已經在測試了,如果突然有了改動,而這個改動也已經做完了,如何通知測試人員重新測一下呢?口頭通知?Email?其實都可以,只是有些時候,改動太多,需要知會的人太多,或者改功能的人不知道要通知哪些人,那怎么辦?DevSpec有個功能可以自動提醒跟這個功能點有關任何開發、測試人員,讓他們知道他們做的事情有改變了。

          posted @ 2011-11-21 11:50 順其自然EVO 閱讀(177) | 評論 (0)編輯 收藏

          操作系統之死鎖

           死鎖其實在信號量時已經提到過,當一個進程想要申請資源A,擁有資源B,而另一個進程想申請資源B,但是擁有資源A,那么就會產生死鎖。

            信號量本身就是個資源,有一定數量。資源分為很多很多,如內存空間,CPU周期,I/O設備等,每個資源有一定數量的資源實例。

            資源和信號量一樣,有等待隊列,當一個進程想要申請資源,但需要其他進程釋放此資源,則進入該資源的等待隊列。

            死鎖的必要條件:

            1、互斥。即資源不能被多個進程所占有。這點其實除了只讀文件,其他基本都滿足。

            2、占有并等待:A進程占有一些資源,還需要的一些資源被其他進程占有,所以處在等待狀態。

            3、非搶占:資源不能被中途搶占。

            4、循環等待:{P0,P1,P2....}進程隊列,P0等待P1占用的資源,類似。

            只要4個條件滿足,則說明必定死鎖。

            資源分配圖:為了清晰的看是否有死鎖。P->R實線 申請;R->P實線 分配;P->R虛線 需求。

            當每個資源類型只有一個實例,則有環等價于死鎖。

            當存在資源類型有多個實例,則死鎖必有環,有環不一定死鎖。

            死鎖處理:

            1.1 死鎖預防。通過不滿足四個必要條件之一。

            (1)互斥:很難不滿足。

            (2)占有并等待:第一,可要求進程創建就要申請好全部的資源;或第二,進程申請資源時要釋放占有的資源。

            但是第一種情況會發生饑餓。因為如果一個進程需要很多很多進程,這些資源幾乎不會同時有,則這個進程永遠不會執行。

            (3)非搶占:如果A進程想要申請資源a,但是a被B進程占有,且B進程在等待資源b,則A進程可以搶占B進程的資源a執行。等到B進程得到原本

            擁有的資源a和申請的b,則執行。 搶占和被搶占

            (4)循環等待:規定資源被申請的順序,每個進程申請資源的順序被規定了。如果需要Rj(j<i)則需要先釋放Ri。

            1.2 死鎖避免。前面討論的預防死鎖的解決方案中包括限制資源的申請,但是這對資源的利用率來說下降太多了。

            所以引出了死鎖避免:要求事先得到進程申請資源和擁有的資源的信息 來判定是否值得等待。(想起了管程的條件變量選擇重啟進程的解決方

            法就是得知進程的最大需求)

            最簡單的方法是事先告訴每個進程對于每個資源類型的最大需求。從而使得循環等待不成立。

            (1)安全狀態:能確定一個進程序列<p1,p2...>,按照這種順序執行進程就不會死鎖(一個結束一個開始)。使得當Pi申請資源時,申請的資

            源一定要小于剩余可用資源+pi隊列前面的進程所占有的資源,則稱為安全的。因為你想,Pi最多就等的長一點時間,但是最終還是能行的。

            安全則不會死鎖。不安全不一定會死鎖。

            只有資源分配后能安全狀態,才允許申請。

            (2)資源分配圖算法:適用于每個資源類型只有一個實例。

            分配邊釋放就變成需求邊。

           2、允許進入死鎖,但可以檢測并恢復。

            3、忽略死鎖。

            銀行家算法: 銀行有一些資源,一個客戶一會要一點資源,一會要一點資源,銀行耐著性子分配。 預先知道Max,Allocation,Available

            在新進程進入時,必須說明需要資源類型的種類和數量,但是不能超過系統總資源。

            n為進程個數,m為資源類型種類,available為長度為m的向量,表示每種資源擁有多少的資源。

            Max是n*m的矩陣,Max[i]表示特定進程需要的每個資源的最大需求。

            Allocation是n*m的矩陣,Allocation[i]表示特定進程已經分配的每個資源的數量。

            Need是n*m的矩陣,Need[i]是特定進程需要的剩余資源。

            兩個向量比較,只有每個分量都大,才大。

            安全性算法:

            設work是長度m的向量,finish是長度n的向量

          work=available;
          for(int i=0;i<n;i++)
           finish[i]=false;
          for(int i=0;i<n;i++) O(n)
          {
           if(finish[i]==false&&Need[i]<work)  O(m)   //如果進程i的最大剩余需求小于系統剩余的資源量
           {
            work=work+allocation[i];  O(m)   //執行完后釋放,則系統剩余資源變多
            finish[i]=true;                  //進程i執行結束
           }
           else break;
          }
          for(int i=0;i<n;i++)
          {
           if(finish[i]==false) return false;
          }
          return true;

            資源請求算法:

            Request[i]是進程i的請求向量。

            if Request[i]<Need[i] 說明能申請
            if Request[i]<Available 說明能分配
            if能分配
            {
            Available-=Request[i]; //系統剩余減少
            Allocation[i]+=Request[i];  //已分配增多
            Need[i]-=Request[i];  //剩余需求減少
            }

            分配完執行安全性算法,即看看是不是安全。

            系統不采用預防或避免提前去除死鎖時,可以

            1、有一個算法可以檢索死鎖的發生。

            2、有一個算法可以讓死鎖恢復。

            當資源類型只有一個資源實例時,可以用等待圖(只有進程)解決。當有環時,則死鎖。

            當資源類型可以有多個實例時,則可以用銀行家算法解決。

            有一個好辦法解決死鎖,就是當CPU使用率低于多少多少時,才調用死鎖檢測,再去除死鎖。

            恢復死鎖可以:

            1、隨便終止一個進程打破循環等待。

            當選擇進程的終止時,需要考慮很多方面,就像CPU調度里的優先隊列法,可以以不同方面考慮優先。可以以進程執行時間、進程還需資源多少、進程是交互的還是批處理的。

            2、搶占死鎖進程資源。

            搶占要搶占誰的又是個問題。自己選唄~而被搶占資源的進程必須回滾到不會發生死鎖的時刻。而且不能一直欺負一個進程,這樣該進程會發生饑餓。

          posted @ 2011-11-21 10:27 順其自然EVO 閱讀(247) | 評論 (0)編輯 收藏

          步步學LINQ to SQL:將類映射到數據庫表

           該系列教程描述了如何采用手動的方式映射你的對象類到數據表(而不是使用象SqlMetal這樣的自動化工具)以便能夠支持數據表之間的M:M關系和使用實體類的數據綁定。即使你選擇使用了自動生成類的工具,理解這一實現過程可以讓你更加方便地對你的應用程序加以擴展。

            下面闡述本文的目標以及該示例程序為初級開發人員介紹如何學習LINQ的基本要點:

            ·使用LINQ to SQL將SQL Server數據庫表映射到與之關聯的對象上。

            ·執行一些簡單的LINQ查詢來檢索數據。

            本文詳細為你闡述了如何在你的應用程序中實現LINQ to SQL。附件的示例程序包括了這里探討的所有代碼,還提供了一個簡單的WPF圖形界面程序來顯示通過數據綁定返回的結果集。

            開始部分:LINQ to SQL是一種對象關系隱射工具,該工具允許你在.NET 3.5框架平臺上將SQL Server數據庫映射成對象類。

            數據庫:該示例使用SQL Server Express作為數據庫,在該數據庫中包涵了Books, Authors, 和 Categories三張數據表。每本書僅僅屬于某一圖書類別,但是每本書可有多個作者,每個作者可以寫多本書。BookAuthors表用于處理books表和authors表之間的多對多關系。為簡單起見,除了Books.Category列以外,其余列都不允許為空。

            這些表可以允許我們針對每個主類型進行關系(1:M,M:1,和M:M)之間的映射。

            本文的其余部分將描述如何將應用程序的數據表與它們的對象類關聯起來以及如何使用LINQ來檢索結果集。LINQ將使用這些數據表作為示例來闡述這些概念。

            應用程序:使用LINQ to SQL, 創建一個.NET 3.5框架之上的工程并添加對程序集 System.Data.Linq的引用。

            1、映射DataContext到數據庫

            如果你為數據庫創建了一個強類型的DataContext,則該類只會對外提供一個單一的入口點,使得外界可以方便地的訪問你的數據。該類將負責處理數據庫的連接并定義你需要連接的每張數據庫表。

            *注意: 在DataContext類中你可以忽略M:M的表連接(例如:BookAuthor),因為它們僅僅使用they're only used behind the scenes to hook up M:M relationships(在本文的后半部分會進行闡述)。

            (1)創建一個使用了 [Database]特性的類來擴展 DataContext

            創建一個擴展自DataContext的數據庫類,并為其添加[Database]特性以表明該類被映射到了數據庫。

            如果你使用的類名與數據庫的名稱不一樣,那么你可以通過使用特性的Name參數進行設定([Database (Name="BookCatalog")])。如果名稱是相同的,此時你可以忽略該參數。

          using System.Data.Linq.Mapping;
          namespace LINQDemo
          {
          [Database]
          public class BookCatalog : DataContext{}
          }


          (2)添加一個帶數據庫連接字符串的構造函數

            添加一個帶有數據庫連接字符串為參數的構造函數,并調用base()方法以告訴父類如何連接你的數據庫。

            該構造函數的數據庫連接字符串以參數的形式讀取,它可以是從一個屬性文件讀取,或者直接硬編碼到函數中,在本文的示例中我們就采用了硬編碼這樣的方式(假設這里的字符串連接到SQL Server Compact數據庫,BookCatalog.sdf,該文件與BookCatalog.mdf位于相同的目錄):

          public BookCatalog( ) : base( "Data Source=.\\SQLEXPRESS;" +
          "AttachDbFilename=|DataDirectory|\\BookCatalog.mdf;" +
          "Integrated Security=True;User Instance=True" ) { }

            注意,在工程中,Book Catalog示例包括了數據庫,和BookCatalog.sdf文件。對于使用LINQ to SQL來說,這不是必要的,在這里僅僅只是加以說明而已。

            (3)申明數據表

            最后,你可以為每張數據表創建一個類型為Table的對象類集合。

            通常,你可以先創建這些類,下面我們來看看這一創建過程。我們將創建三個類(Author, Book, 和Category)--每個類對應一張數據表。因此,我們將為每個類類型添加一個Table集合并將這些集合命名為一個有意義的名字。注意,為數據庫表名對應的類或集合命名不是必須的。我們將在下一節了解如何為數據表指定名稱。

          using System.Data.Linq;
          using System.Data.Linq.Mapping;
          namespace LINQDemo
          {
          [Database]
          public class BookCatalog : DataContext
          {
          public BookCatalog( ) : base( ... );
          public Table Authors;
          public Table Books;
          public Table Categories;
          }
          }

            2、將實體類映射到數據庫表

            為連接到應用程序的每張數據庫表創建類對象。我們將以Book表為例子闡述這一實現過程。

            (1)創建帶有[Table]特性的類

            創建一個特性為Table的Book類將其映射到對應的數據庫表。

            為數據庫表的Name參數指定名稱([Table( Name = "Books" )])。這里我們這樣做是因為表的名稱(Books)和我們的類名(Book)不同。如果它們相同,可以忽略該Name參數的設置。

          using System.Data.Linq.Mapping;
          namespace LINQDemo
          {
          [Table( Name = "Books" )]
          public class Book{}
          }

            (2)使用[Column( IsPrimaryKey = true )]特性添加一個字段作為表的主鍵。

            如果你喜歡,你也可以為為其添加一個Column特性,這也是Book Catalog應用程序所采用的方式。

            如果你的主鍵在數據庫中設置成了Identity,那么需要添加一個參數IsDbGenerated = true。

           相對于數據庫列名,如果你想為字段或屬性設置成不同的名字,可以使用(Name="")標簽來實現.否則程序會默認以你的字段或屬性名稱作為列名,正如我們這里的Book's主鍵:Id那樣。

          [Column( IsPrimaryKey = true, IsDbGenerated = true )]
          public int Id { get; set; }

            (3)使用[Column]特性為表添加其他非關系列

            后面部分我們將會回到關系對象上來。現在,咱們開始了解表對象的非主鍵,外鍵列。Book有兩個這樣的列:Title 和 Price。其數據類型由數據庫的money類型轉換到了.NET的decimal類型,以及由varchars類型轉換到了.NET的string類型。LINQ會自動為你處理這些數據類型之間的轉換。

          [Column] public string Title { get; set; }
          [Column] public decimal Price { get; set; }

            Book Catalog應用程序的Author和Category也進行了這樣的處理,即這三個類對象都對應于自己的數據表:

          using System.Data.Linq.Mapping;
          namespace LINQDemo
          {
          [Table( Name = "Books" )]
          public class Book
          {
          [Column( IsPrimaryKey = true, IsDbGenerated = true )] public int Id { get; set; }
          [Column] public string Title { get; set; }
          [Column] public decimal Price { get; set; }
          }
          [Table (Name="Authors")]
          public class Author
          {
          [Column (IsPrimaryKey = true, IsDbGenerated = true )] public int Id { get; set; }
          [Column] public string Name { get; set; }
          }
          [Table (Name="BookCategories")]
          public class Category
          {
          [Column (IsPrimaryKey = true, IsDbGenerated = true )] public int Id { get; set; }
          [Column] public string Name { get; set; }
          }
          }

          posted @ 2011-11-21 10:22 順其自然EVO 閱讀(313) | 評論 (0)編輯 收藏

          類的生命周期回顧篇

           一、JAVA虛擬機和JAVA程序的生命周期

            JAVA虛擬機的生命周期和JAVA程序的生命周期一致,當我們在命令行中敲入java命令運行java程序時,java虛擬機進程啟動,程序運行,當程序終止時,則JAVA虛擬機的生命也結束。

            二、類的生命周期

            1、加載:將.class文件的二進制數據放到內存方法區中,并在堆區中創建一個Class對象,這個Class對象封裝了方法區的數據結構,用戶能通過Class對象訪問到方法區中。

            2、連接

            (1)驗證:驗證.class文件是否是通過JAVA程序編譯出來的,因為有可能這個.class文件是黑客特意制造出來的。

            (2)準備:為類中的靜態變量分配空間,并初始化為默認值。

            (3)解析:把類的符號引用變為直接引用。

            3.初始化:為靜態變量和靜態塊賦予值。

            JAVA程序對于類的使用方式:

            (1)主動使用。

            (2)被動使用。

            這里注意:

            JAVA虛擬機對于加載和連接的時間節點是很寬松的,沒有嚴格規定,可以提前加載也可以;但是對于初始化,JAVA虛擬機規定當某個類被主動使用時才能初始化。

            我們把3個步驟細講一下:

            1、類的加載:類是通過類加載器進行加載。

            類加載的來源:

            (1)文件系統中的class文件

            (2)jar包

            (3)網絡中下載。

            類加載目的地:內存。

            類加載器分類:

            (1)根類加載器:沒有父類,加載java.lang.*。

            (2)擴展類加載器:父類是根類加載器,用于加載jre\lib\ext的jar包。

            (3)系統類加載器:父類是擴展類加載器,用于加載classpath的jar包。Class scl = Class.getSystemClassLoader();

           (4)自定義加載器:自定義加載,通常父類是系統類加載器。

            注意:通過類虛擬機自帶的(1)(2)(3)加載器是JAVA虛擬機創建的,而他們加載的類,他的生命周期是虛擬機的生命周期,因為始終被加載器鎖引用。

            2、類的解析

            將符號引用轉換成直接引用。比如:

            A函數調用了B函數,原本只是符號引用即標明引用了B函數,直接引用是將符號改成指針指向B函數。

            3、類的初始化

            規則:

            (1)初始化的靜態變量都是運行時變量,即不能在編譯時就能判斷值是多少。

            (2)初始化的順序就是按照代碼的順序執行。

            (3)如果初始化子類時父類還沒有被初始化,則先初始化父類。

            初始化時機:當遇到以下情況會進行初始化。

            (1)new創建實例、反射創建實例、clone創建實例、反序列化創建實例。

            (2)訪問靜態變量,即讀和寫。

            (3)調用靜態方法。

            (4)啟動類需要首先初始化。

            (5)Class.forName();

            注意:

            (1)當遇到編譯時常量,則直接用數字替換,而不會導致類初始化。比如public static final int a= 3;這就是一個編譯時常量。

            (2)當子類對象調用父類的靜態變量或方法,則只對父類進行初始化。比如:Sub.a,其中a是父類的靜態變量,則只對Base初始化。

            (3)當子類被初始化時,父類一定要先初始化;

            但是如果一個類實現了一個接口,當類被初始化時,不用初始化父接口。

            只有對這個接口進行訪問時,才會對接口進行初始化。

            (4)loader.loadClass("....");只是對類的加載,而不是初始化。

            類加載過程采用“父親委托機制”,即如果loader2的父類是loader1,loader2想要加載test類,則先會檢查loader1是否能夠加載test類,如果能,則通過父類加載。

            運行時包的概念:包名相同,類加載器相同。


          posted @ 2011-11-21 10:17 順其自然EVO 閱讀(233) | 評論 (0)編輯 收藏

          異曲同工 WinForm和ASP.NET如何選?

          在.NET平臺開發中,我們經常使用WinForm進行C/S架構的開發,也用過ASP.NET作為B/S架構開發。那么有些人可能糊涂了,不知道在這兩者之間如何做選擇了。其實作為將來要在.NET平臺上做開發的工作者來說,無論如何都要同時掌握WinForm編程和ASP.NET編程。

            當我們開始開發帶有用戶界面的應用程序時,可以使用WinForm或ASP.NET。兩者在開發環境(Visual Studio系列)中都具有完全的設計時支持,并且可以提供豐富的用戶界面和高級應用程序功能解決現實業務問題。由于這種“相似”,要決定采用哪種技術來實現軟件可能有些困難。

            關注軟件的最終用途可以使選擇變得相對容易。如果我們要開發的是一個公眾可以通過Internet訪問的電子商務網站,肯定采用ASP.NET來開發軟件項目。如果我們要充分發揮客戶端電腦的計算能力,并且客戶端的處理工作量很大,需要快速響應用戶請求,無疑應該使用WinForm。但是在其他情況下,選擇也真的不是很明晰。

            何時選擇WinForm

            如果客戶端應用程序負責應用程序中的大部分處理任務,應該使用WinForm開發應用程序。這些客戶端應用程序包括傳統上在早期版本的VB和VC中開發的Win32桌面應用程序。繪圖或圖形應用程序、數據輸入系統、POS系統和游戲都屬于這類應用程序。

            這些應用程序都依靠桌面計算機的處理能力和高性能數據顯示。有些應用程序可能完全獨立,它們在用戶的計算機上執行所有的應用程序處理。通常以這種方式來編寫游戲。其他應用程序可能是大型系統的一部分,它們主要使用桌面計算機來處理用戶輸入。例如,POS系統常要求在桌面計算機上創建具有響應能力的復雜用戶界面,同時將該界面鏈接到其他執行后端處理的組件。

            使用WinForm的應用程序是在Windows框架中生成的,因此它可以訪問客戶端計算機上的系統資源,包括本地文件、系統注冊表、打印機等。可限制該訪問級別,以消除由不希望的訪問引起的任何安全性風險或潛在問題。另外,WinForm可以利用.NET Framework GDI+圖形類創建豐富界面,而這常常是數據挖掘或游戲應用程序所必需的。

            何時選擇ASP.NET

            使用ASP.NET創建主要由瀏覽器用戶界面組成的應用程序。這自然包括希望讓公眾可通過萬維網使用的應用程序,比如電子商務應用程序。但是ASP.NET并不僅僅用于創建網站,許多其他應用程序同樣適用于“瘦客戶端”,如基于Internet的雇員手冊或津貼應用程序。任何ASP.NET應用程序都有一個重要的優點,就是沒有客戶端安裝和維護的成本。用戶已經安裝了所需的唯一一個應用程序——瀏覽器。

            ASP.NET應用程序與平臺無關,即它們是“延伸”的應用程序。不論用戶的瀏覽器類型是什么,也不論使用的計算機類型是什么,他們都可以與應用程序進行交互。同時,可優化ASP.NET應用程序,以利用最新瀏覽器中的內置功能來增強性能和響應能力。在許多情況下,此優化內置于使用的Web窗體組件。這些組件可以自動檢測瀏覽器級別,并相應檢測呈現頁。

            ASP.NET應用程序提供了一些即使在非Web環境中依然有用的功能。因為這些功能依賴于HTML,ASP.NET應用程序適合任何種類的文本密集型應用程序,尤其適合那些文本格式設置對其很重要的應用程序。基于瀏覽器的應用程序對用戶的系統資源的訪問權限有限,在希望防止用戶訪問某些應用程序的情況下,這種限制使ASP.NET應用程序很有價值。

            WinForm與ASP.NET的比較

          功能/標準WinFormASP.NET
          安裝部署WinForm允許使用ClickOnce進行“非接觸”部署,即可以直接在用戶的計算機上下載、安裝和運行應用程序,而不必改變注冊表。ASP.NET沒有客戶端部署;客戶端只需要一個瀏覽器。服務器必須運行Microsoft .NET Framework。對應用程序的更新通過在服務器上更新代碼來完成。
          圖形WinForm包括 GDI+,它使得游戲和其他有非常豐富的圖形的環境可以有復雜的圖形。在ASP.NET時,交互式圖形或動態圖形需要來回訪問服務器以進行更新。可以在服務器上使用GDI+來創建自定義圖形。
          響應WinForm可以完全在客戶端計算機上運行;它們能夠為需要高度交互的應用程序提供最快的響應速度。如果用戶用較新的瀏覽器(IE5.0以上),ASP.NET應用程序可以利用瀏覽器的動態HTML(DHTML)功能來創建豐富的、具有響應能力的用戶界面(UI)。如果用戶有其他瀏覽器,大多數處理(包括與用戶界面相關的任務,比如驗證)需要往返于Web服務器,而這會影響響應,當然我們可以采用AJAX技術來改善應用體驗。
          窗體和文本流控制WinForm網格定位可以對控件的位置提供精確的二維(x和y坐標)控制。若要在Windows窗體上顯示文本,一般將文本插入到控件(例如 Label控件、TextBox控件或RichTextBox控件)中。格式化將受到限制。ASP.NET界面基于HTML樣式流布局,因此支持網頁面布局的所有功能。它在文本格式設置方面的功能尤其強大。可以充分地管理控件布局(有某些限制,例如不能重疊控件)。如果用戶有支持DHTML的瀏覽器,可以用二維(x和y坐標)布局來指定更精確的布局。
          對于.NET Framework的依賴WinForm需要在客戶端計算機上運行.NET Framework。ASP.NET客戶端只需要一個瀏覽器。支持DHTML的瀏覽器可以利用額外的功能,而Web窗體可以被設計為適用于所有的瀏覽器。ASP.NET系統只需要在服務器運行.NET Framework。
          訪問本地資源(文件系統、系統注冊表等)如果允許,應用程序對本地計算機資源可擁有完全訪問權。如果需要,可以精確地限制應用程序,使其不能使用特定的資源。瀏覽器安全性防止應用程序訪問本地計算機上的資源。
          編程模型WinForm基于客戶端Win32消息轉儲模式,開發人員在此模式中創建、使用和銷毀組件的實例。ASP.NET依賴于在很大程度上異步的斷開連接模型,在此模型中,組件松散地耦合到應用程序前端。通常,應用程序組件通過HTTP協議調用。此模型可能不適合要求用戶端有極大吞吐量的應用程序或具有大量事務處理的應用程序。同樣,ASP.NET應用程序可能不適合需要高級別并發控制的數據庫應用程序。
          安全性WinForm在其代碼訪問安全性實現中使用權限,以保護計算機資源和敏感信息。這使功能得以被小心公開,同時保留安全性。例如打印權限,在某一級別上只允許在默認打印機上打印,在另一級別上則允許在任何一臺打印機上打印。使用ClickOnce部署技術,開發人員可以輕松地配置應用程序應該和不應該向客戶端要求什么權限。通常,通過驗證請求者的憑據(例如,名稱/密碼對),按URL控制獲得訪問ASP.NET應用程序資源的授權。ASP.NET允許開發人員控制執行服務器應用程序代碼所使用的標識。應用程序可以用請求實體的標識來執行代碼。應用程序也可以根據請求者的標識或角色來動態調整內容。例如,經理可以訪問某一站點或更高級別的內容,而擁有較低權限的人則不能這樣做。

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

          僅列出標題
          共394頁: First 上一頁 361 362 363 364 365 366 367 368 369 下一頁 Last 
          <2025年7月>
          293012345
          6789101112
          13141516171819
          20212223242526
          272829303112
          3456789

          導航

          統計

          常用鏈接

          留言簿(55)

          隨筆分類

          隨筆檔案

          文章分類

          文章檔案

          搜索

          最新評論

          閱讀排行榜

          評論排行榜

          主站蜘蛛池模板: 胶州市| 康定县| 花莲市| 集贤县| 虞城县| 南陵县| 平塘县| 伊宁县| 文山县| 银川市| 兴隆县| 沭阳县| 郧西县| 咸宁市| 日土县| 八宿县| 蒙自县| 蒙山县| 明溪县| 科技| 花莲市| 洱源县| 连云港市| 滁州市| 夏河县| 许昌市| 怀来县| 宣汉县| 高阳县| 北碚区| 白银市| 嘉鱼县| 洛隆县| 定襄县| 响水县| 浠水县| 梁平县| 田林县| 建水县| 黔西县| 云南省|