qileilove

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

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

           前言:Teradata數據庫在數據倉庫領域的優勢還是相當的巴適,測試需要,而且該數據庫好多SQL都是自備,很強大,有這方面興趣的朋友可以一起研究。

            一、創建數據庫:

           ?。?)Teradata安裝好之后,最好安裝一個Assitant,不過沒有這個也沒什么,純手工SQL也能寫。如果不是第一次使用環境,先開啟Windows的服務,然后在開始菜單的Teradata的選項中選擇“Teradata multiTool”選項,將兩個后臺服務PDE和DBS啟動。具體啟動界面如下:

          圖1 啟動PDE和DBS

           ?。?)正常啟動后臺服務完成后,需要在文件hosts中配置步驟(3)需要的創建數據庫的信息,配置文件在Teradata安裝完成之后放在C:\WINDOWS\system32\driver\etc下面,名稱為hosts,修改最后一行的設置,設置成啟動Teradate的ip和對應的數據庫信息,如在本機啟動了Teradata的服務,同時我想創建一個gusl的數據庫,那么在此行應設置成127.0.0.1 guslcop1。

           ?。?)在開始菜單的Teradata選項中選擇“Database Setup”用來創建數據庫和用戶。彈出如圖2的窗口,輸入數據庫的名稱gusl和對應的Super user的用戶名和密碼,同時創建一個管理用戶,密碼設置什么的都在這。

          圖2 創建數據庫圖形頁面方式

           ?。?)確定后Teradata會在控制臺打印對應的創建信息,正確無誤后該數據庫就可以正常使用了,如果出錯,可以查看對應的信息糾正(剛開始搞很容易出錯,不過熟練了就好多了)。

          ?。?)使用BTEQ登陸,這個具體的安裝和配置網上一堆,很實用的Teradata的工具。不過建議裝個BTEQ的windows版的,這個能復制建表語句,直接的BTEQ不能(很悲?。?。使用Super user和剛才新建的用戶登錄。在BTEQ彈出輸入“Enter your Logon or BTEQ command”時輸入.logon database_name/user_name(注意前面的點必須要),提示輸入密碼,完成登錄。如圖3

          圖3 測試創建完成的數據的登錄

           ?。?)登陸完成后需要創建對應的用戶同時給對應的用戶授權,具體的命令和圖解如下:

            創建用戶命令: create user "gusl" from DBC as password=gusl,account='$DBC',permanent=3000000,fallback;

            Teradata的命令不全是以點(.)開始,但是一定是以分號結尾。上傳的是我第一次留下來的截圖,上面還有當時的犯錯記錄。


          圖4 創建用戶

          ?。?)用戶創建成功后給用戶授權,同理SQL的grant命令,和Oracle的有一點區別。

            grant select,delete,insert,update on database to user。(授予某一個用戶在某一個數據庫中的權限)。

          圖5 給用戶授權

            用戶創建完成之后我們可以嘗試著使用該用戶登錄數據庫,看是否能正常登陸。

          圖6 新創建的用戶登錄系統

            PS:補充創建創建數據庫的SQL,正常登陸后即可。在Teradata中數據庫就是少了密碼的用戶,這一點很獨特,或者你認為他是對應的Schema也行,看你怎么理解了。

            create database database_name from mib as permanent=3000000,spool=4000000,account = '$mib',fallback ;

            數據庫環境搭建就告一段落,我是按照我從事測試行業接觸知識的先后順序將對應的內容分享,有點偏技術了,畢竟這些都是數據庫的基本操作,掌握了可以為我們的測試工作更好的開展





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

          [分享]解讀軟件外包

           1、對大學生談軟件外包的原因

            中國軟件外包行業這幾年成為發展最為迅速的行業之一,無論你是在校的大學生,還是即將畢業的同學,都有必要了解這個行業。如果你是軟件相關專業的同學,或者畢業后準備從事軟件行業,那么更應該關注軟件外包這個行業。

            盡管網上已經有很多關于軟件外包的信息,但是這些信息很多都是媒體記者的報道,他們只是從旁觀者的角度看待軟件外包,缺乏一定的深度和實踐感受。還有一些來自非軟件外包的人士,基于他們主觀的理解和推測,認為軟件外包是很低級的工作,為軟件外包工作潑冷水,影響了對軟件外包工作的正確認識,造成了軟件外包的“中國式誤會”。

            大學生接受了系統的高等教育,具有牢固的知識基礎,而且具有極強的可塑性和學習能力,是未來軟件外包行業的主力軍。但是,他們參加軟件外包實際項目的機會和經驗畢竟很少,對于軟件外包有很多模糊的認識。由于教材的更新需要更長的周期,高校教師如果沒有豐富的外包企業經驗,很難把軟件外包的實際知識傳授給學生,因此,外包企業從業人員有必要向這些高校學生交流一些軟件外包企業的實際情況。

            那么什么是軟件外包?軟件為什么要外包?中國軟件外包的現狀如何?將來做軟件外包是否有前途?這些問題可能很多同學不是很清楚,如果今后打算進入這個行業,則從現在開始就需要先了解這些問題的答案。

            筆者具有多年的軟件外包公司工作經驗,對于軟件外包行業一直積極關注,并且積極與國內外同行交流,對軟件外包有些自己的體會,借此機會與個位同學進行交流。

            2、軟件外包介紹

            軟件外包就是軟件開發商(簡稱“發包方”)將軟件開發的一部分或者全部,發給別的軟件公司(簡稱“接包方”)去完成。

            我們通常說的中國外包公司很多都是“接包方”,主要從日本和歐美等國承接軟件外包項目的技術工作。現在軟件行業比較發達的美國、歐洲和日本是最大的“發包方”市場。

            由于軟件外包是軟件全球性生產方式,所以存在很多關于外包的英文術語。外包的英文單詞是“Outsourcing”。站在“發包方”的角度,把“接包方”成為“Vendor(外包服務商)”。站在“接包方”角度,把“發包方”成為“Client(客戶)”

            軟件外包與其他外包其實沒有本質區別,就是雙方合作把一個很復雜的、較大的軟件項目分工合作,共同做好。其實在其他行業,外包已經實施了很長時間,例如汽車行業,生產汽車的公司(比如一汽集團)他們先設計好汽車的結構,完成主要部件的生產,把很多零件外包給很多廠家加工,然后采用完成整個車輛的安裝和制造。

            現在人們很關注軟件外包,就是因為外包在軟件行業應用的時間還很短,而且軟件生產存在很多不可見因素,軟件外包的優勢和好處,還沒有被普遍了解和感受。

            總結一句話,軟件外包就是軟件生產的分工和合作,主要目標就是生產出好的軟件。

            3、軟件外包的理由

            同學們可能都聽說了,現在印度和中國做軟件外包“火得不得了”,越來越多的歐美大型軟件公司都把軟件外包給印度和中國。為什么會出現這種現象呢?

            要回答這個問題,不能簡單的從發包方或者接包方一個方面尋找答案。因為“一個巴掌拍不響”,要實現軟件外包,必須雙方都有需求、有能力、愿合作才行。而且不能把目光只盯在中國一個國家,還需要從全球軟件行業的整體來看待和理解。

            為什么軟件外包能發展的這么快呢?主要原因在于通過軟件外包,發包方和接包方都獲得了可觀的利益,非常具有現實意義。說得更簡單一點,就是雙方都獲得了好處,大家是互相合作的伙伴。

            作為發包方,可以獲得下列好處:

            ● 降低軟件項目成本
            ● 提高軟件質量
            ● 縮短軟件開發周期

            怎么理解軟件外包能較低軟件項目成本呢?

            大家可能聽說過,美國的軟件技術人員的工資比中國同等水平的人員要高5到10倍,所以不少美國的軟件開發公司都把軟件開發和測試的工作,發到中國的軟件外包公司來作,可以大幅度的降低成本。對于中國的軟件外包公司,他們從國外客戶承接外包項目,可以獲得很穩定也很好的項目價格,所以很樂意做軟件外包服務商(Vendor)。

           說到通過軟件外包提高軟件質量,可能很多人不理解。舉個例子就明白了。

            美國微軟(Microsoft)公司是全球最大的軟件公司,現在正在開發的Windows Vista新操作系統,需要同時發布多個語言的本地化軟件,例如英語、簡體中文、繁體中文、日語、韓語、德語、法語、阿拉伯語等。這些語言的本地化版本的翻譯、編譯、測試,如果全部在微軟公司內部完成,那么微軟需要招聘大量的精通每種語言和軟件技術的工程師,否則語言質量肯定不能保證。如果把這些工作外包給專業的軟件本地化外包公司,軟件本地化是這些外包公司的強項,所以可以顯著的提高軟件質量。

            軟件外包能縮短軟件開發周期的道理很容易理解,如果很復雜的軟件開發工作都在一個公司內部完成,那么可能耗費1年甚至幾年的時間。例如,如果Microsoft Windows Vista的軟件需求分析、框架設計、詳細設計、軟件編碼、軟件測試、軟件多語言本地化等工作都在Microsoft公司內部實現,那么微軟可能需要招聘很多的內部員工,動用很多的項目經理管理這些人員,對這些人員進行技術、語言和流程培訓,花費的時間肯定比外包更長。這樣的軟件即使開發出來了,等到能夠發布這些技術可能過時了,其他競爭對手的相似產品肯定已經早已占領了市場。

            現在是網絡信息時代,時間就是金錢,速度就是效益,“快魚吃慢魚”,實現搶先推出新產品,誰就可能占領更多的市場份額。

            4、做軟件外包的前途是啥?

            俗話說:“男怕入錯行”,如果你進入了一個沒有前途的行業,即使你的能力再高,你的發展空間也很有限。對于,剛剛畢業的大學生,第一份工作非常重要,甚至會影響一生的職業生涯。

            軟件外包是全球軟件行業新興的行業,是經濟全球化和軟件產業全球分工的產物。大家知道全球化已經深入到我們生活的每個方面,我國的改革開放就是順應了時代潮流。

            對于中國而言,軟件外包的發展更是如火如荼,屬于典型的IT“朝陽行業”。每年的增長速度都在50%以上,特別對于中國的軟件外包公司,他們每年的業務都是100%的速度增長,發展勢頭不可阻擋。

            從事軟件外包工作的好處之一是可以在短期內獲得職業提升的機會。現在中國軟件外包行業如果具有5年以上的工作經驗,就可以成為外包的有經驗專才了。很多大學生進入軟件外包公司工作2到3年,如果學習能力和交流能力好,可以成為項目經理或者部門經理。

            從事軟件外包工作的好處之二是可以學習和培養國際化思維方式和工作方式。前面已經談到,軟件外包是全球合作的工作方式。做軟件外包工作,有機會學習先進的軟件設計和測試方法,學會管理大型的、多個團隊協作的軟件項目,要和多個國家和地區的技術人員和管理人員進行英語或者日語交流。這樣可以提高語言表達能力,團隊交流能力,遵守科學的生產流程,成為熟悉國際市場和技術的職業人士,對于將來的職業發展大有幫助。

            而如果畢業后到一個小的軟件公司工作,由于中國的小軟件公司很多都是10多個或者幾十個人的手工作坊式公司,企業內部缺乏完善的流程,管理混亂,粗放式經營,依靠個別高手的能力,這樣的環境很不容易學習到關鍵技術,而且還會養成隨意的、不善交流的獨立自我的工作習慣。這種習慣一旦養成對于今后的職業發展是大為不利的。

            因此,大學畢業生投身做軟件外包,就是進入了一個發展前途十分可觀的“朝陽行業”,通過自身的不斷努力,有希望在短期內,成為熟悉國際化行業規則的技術和管理人才,成為職場上非常有競爭力的軟件專家。

            5、外包公司是怎么工作的?

            進入軟件外包企業后,為了盡快適應新環境,完成日常工作,需要了解軟件外包公司是如何安排工作的。

            從外包的內容看,現在大多數中國軟件外包公司從事兩種內容的工作,第一是軟件設計和編碼的外包(即開發外包),第二類是軟件測試外包。

            從工作的地點看,軟件外包公司的員工的工作形式分為兩種,第一是被派遣到發包方(客戶)的公司進行工作,這種形式稱為“On-site外包”。第二式在軟件外包公司內部工作,稱為“In-house外包”。

            如果同學們到人才招聘網站看看外包公司的招聘廣告,經常能看見赴微軟,赴IBM從事軟件開發或測試的招聘職位。這種形式就是“On-site外包”。舉個例子,軟件外包公司A招聘了從事軟件外包測試的同學小李到微軟亞洲工程院從事微軟的軟件測試,雖然小李在微軟的公司工作,但是他隸屬于A公司,工作上受到A公司和微軟公司的領導,A公司每個月按照A公司的工資標準給小李發工資。一般來說,“On-site外包”的工程師的技術水平要求的更高些。

            在筆者看來,“On-site外包”工作方式只是軟件外包的初級形式,如果軟件外包的服務模式成熟之后,越來越多的外包將以“In-house外包”的形式實現。下面介紹“In-house外包”的工作方式。

            所有的軟件外包公司都是以“項目”的形式,組建項目團隊開展外包工作。一個“項目”就是一個有著明確的任務,明確的開始和結束時間,以及明確的質量要求的工作。項目團隊就是為了完成一個項目組建的有不同角色的多個人的小組,一般安排一個項目經理,一個或幾個組長,多個工程師。

          項目經理主要制定項目計劃、資源安排、內部交流和外包的客戶交流。組長為每個工程師分結和安排具體的任務,跟蹤項目進度,解決技術問題。工程師根據組長分配的任務按照進度和質量完成每天的工作,并且報告進展和遇到的問題。

            項目經理負責周期性的向“客戶”報告項目進展情況,同時把客戶反應的問題和來自客戶的最新文件和要求等傳達給項目組。

            通常項目經理和組長都是由具有管理和技術經驗的員工擔任,對于剛剛加入軟件外包公司的大學生來說,絕大多數都是從工程師的職位做起的,先經過外包公司的內部培訓,然后進入項目組實習,轉正之后稱為工程師,負責具體的開發或測試工作。

            順便說說,不少優秀的大學生,專業技術非常好,學習能力由特別強,善于思考和總結,也善于與其他人交流和合作,這樣的學生很快就可以在項目團隊中脫穎而出,經過一年或者兩年可以從普通工程師晉升到測試組長甚至項目經理。我的不少同事就是這樣過來的,這是因為軟件外包發展得非常快,客戶發來的軟件外包項目越來越多,項目團隊越來越多,每個項目都需要項目經理,所以從事軟件外包具有很大的職業發展空間。

            現在總結一下軟件外包公司的工作方式:

            ● “On-site外包”或者“In-house外包”方式
            ● 按照項目團隊的方式工作
            ● 剛進入外包公司的大學生絕大多數要從工程師做起

            6、有哪些好的外包公司?

            對于正在找工作的同學來說,都希望到一個規模較大的公司工作,一般來說,大公司比較規范,待遇也較高,倒閉的風險小。對于軟件外包公司來說也是這樣子。

            同學們可以猜猜看,全球著名的高端軟件外包公司有哪些?據媒體報道,比較公認的全球高端外包公司分別是IBM,HP和EDS,前兩家同學們肯定耳熟能詳,有些同學可能懷疑IBM,HP能算是軟件外包公司嗎?它們算不算外包公司不是我說的,反正做軟件外包多年的老外都這么人為,人家可是全球知名的外包專家,可不是信口胡說的呀。

            有的同學經常問我,國內有哪些規模較大的外包公司?哪個外包公司最好?我一般都回答不好。為什么呢?因為每個人看問題的角度不同。比如,什么是“規模較大”?是按照正是員工的人數比較呢還是按照每年的總收入確定?什么樣的外包公司是“好公司”?給員工發的工資搞就是好公司嗎?給員工提供專業的技術培訓,而且具有很大的職業發展空間的是否就是“好公司”呢?

            因此,在你問這些問題前,先要搞清楚你心目的好公司應該具有什么樣的特征。

            我還是從國內外包公司的普遍特征來給出這個問題的一些參考信息。

            前面已經提到,我國軟件外包公司屬于新興的行業,真正從事軟件外包的員工如果人數超過1000人在中國就可以算是比較大的外包公司了。據了解國內最大人數的外包公司現在不超過3000人(這里需要說明一點,有些公司一開始是做系統集成的,最近才開始做軟件外包業務,雖然他們的全體員工超過5000人,但是真正做軟件外包的還不超過3000人)。所以同印度的某些大的軟件外包公司項目,我國的軟件外包公司規模普遍弱小。印度的軟件外包公司超過10000人的很多,有些超過了5萬人。所以有些國內的軟件外包的朋友,把中國軟件外包公司比作“螞蟻”,把印度外包公司比作“大象”。

            如果同學們打算做軟件外包,肯定要問哪個省市的軟件外包公司最多?我要告訴大家的是,中國的軟件外包在各個省市的發展很不平衡。大連、北京、上海、深圳、蘇州、西安等發展的相對快些。其他各個地方今年開始從政府到企業都開始提出要發展軟件外包了。

            關于國內軟件公司的規模,同學們可以參考我國政府權威部門發布的“中國軟件歐美出口工程”試點企業名單。這些公司都具有一定的規模和實力,有些記者把這些公司比喻成“中國外包的國家隊”,言外之意其他的外包公司只能算是“地方武裝”了。 。

            大連的軟件外包發展的最為快速,特別是對日外包做的最為成功,因為大連的政府支持,地理位置靠日本很近,可以找到很多掌握日語的軟件技術人員。北京和上海的軟件外包發展的時間更長,這兩個直轄市憑借經濟和政治的影響,吸引了大量的國外客戶,人才資源很豐富,所以外包做的很早,很多歐美的大型軟件公司都在這兩個城市成立的研發中心。

            說到外包公司,很多人首先想到的是中國本土的外包公司,其實出了本土外包公司,國外外包公司在中國的分公司也不可忽視。這些國外外包公司有的進入中國較早,有的最近一兩年才在中國落戶。他們憑借國外市場的良好客戶關系,全球的專業品牌,先進的外包管理技術,豐富的外包經驗,加上國際化的工作環境,良好的薪資待遇,吸引著很多大學生前去應聘。

            最后給同學們一點建議,大家在找工作的時候與要單純追求規模大的外包公司,中小規模的外包公司有可能發展速度更快,有可能提供很大的職業發展空間。關鍵是通過各種方式綜合了解軟件外包公司的發展前景、工作環境和個人發展空間,可以通過打聽在外包公司工作的同學、朋友、親戚、老鄉,也可以上網看看外界對這家公司的報道和評論。

           7、軟件外包公司需要什么樣的人?

            剛畢業的同學如果沒有考研或出國留學,都有過找工作應聘的經歷,不少同學都感覺找到合適的工作單位不是一件容易的事情。有些同學雖然得到了軟件外包公司的應聘機會,但是面試后就沒有消息了。

            而一些軟件外包公司的招聘人員卻為找不到合適的人員而苦惱,只好發動一切可以調動的因素,解決企業人才困乏的問題。所以有人把這種現象歸納為:“高校有人沒事干,企業有事沒人干”。

            這種現象的本質是大部分高校畢業生的綜合素質達不到軟件外包企業的用人要求。那么軟件外包公司需要什么樣的人呢?為了能夠進入軟件外包企業,在校學生應該如何學習和學習什么呢?

            說的簡單一點,企業需要的是能馬上融入外包項目團隊,獨立承擔實際外包項目任務的人。所以很多企業在招聘啟事中都有“x年軟件外包相關工作經驗”等的硬性指標,而這些都是在校學生欠缺的地方。

            現在一些外包公司都提供兼職崗位(Freelancer),這是在校學生(尤其是即將畢業的學生)參與社會實踐的好機會,應該抓住這些實習機會,積累工作經驗。另外,如果在這些企業實習期間表現優秀,畢業后有機會成為公司的正式員工。

            軟件外包企業對待大學畢業生更看重學生的學習能力。剛畢業的大學生就像一塊好的毛坯鋼材,材質優良,如果這些學生有較好的主動學習能力,進入企業后經過幾個外包項目的實踐,積極思考,善于總結,成長很快。企業不歡迎凡事不經過大腦思考,大小問題都要向主管求助的“懶漢”員工。

            企業需要具有職業精神的員工。職業精神包括很多方面的內容,包括對工作的熱情投入,積極與團隊成員交流,具有合作精神,以企業利益為重。而不歡迎喜歡與企業討價還價,抱怨企業提供的發展空間不夠大的學生。

            由于軟件外包服務行業是為客戶提供服務的行業,很多外包項目的具體任務一般比較瑣碎、枯燥,例如按照客戶提供的軟件框架進行編碼,按照客戶提供的測試用例執行軟件測試。對于剛剛畢業的學生他們都需要從這些很基礎的技術崗位做起,這是對他們職業精神和做事風格的考驗。

            軟件外包服務的很多工作就像生產流水線上的公司在擰螺絲釘,需要遵守嚴格的生產流程和一絲不茍的嚴謹精神。把這些基本工作做好了,才能取得企業的管理人員的信任,才有機會承擔更復雜更大責任的工作。

            一些剛畢業的學生經常心高氣傲,很鄙視這些繁瑣枯燥的工作,感嘆埋沒他們的才華,這是沒有擺正工作心態的表現。外包公司非常歡迎愿意做看似瑣碎的工作同時有能力做好的同學。其實做好這些看似瑣碎的工作,當好擰螺絲的工人,就是不簡單,他的未來就會不平凡。道理很簡單:基礎打好了,萬丈高樓平地起。

            總結起來,外包企業需要具有一定的外包工作經驗,主動學習能力強,團隊合作精神好,愿意從瑣碎的技術工作做起,而且有能力做好“小事”的人。

            海爾公司總裁張瑞敏有句名言說得非常好,對于準備到軟件外包公司工作的同學非常有啟發,他說:“把一件簡單的事做好就是不簡單,把每一件平凡的事做好就是不平凡”。

            8、哪些人不適合做軟件外包技術人員?

            大千世界,無限精彩。作為軟件行業的新領域,軟件外包吸引著越來越多的人投入這個行業。每個行業都有行業的行規和準則,并不是任何人都適合從事軟件外包行業的。

            哪些人不適合從事軟件外包呢?由于本文的讀者針對即將畢業的大學生,也適用于準備加入軟件外包公司的新人,所以我們可以把問題縮小范圍:哪些人不適合做軟件外包服務的技術人員?

            回答什么人不能做軟件外包,也就是哪些人做不好軟件外包,需要先了解軟件外包服務行業的工作性質和對人的綜合要求。軟件外包是為客戶提供專業技術服務的行業,而且現在的軟件外包企業的客戶大都來自國外,客戶對外包公司人員要求比較嚴格。另外,外包公司的工作非常具體和瑣碎,需要一絲不茍。

            軟件外包行業的這些特點,決定了以下三種類型的人不適合做軟件外包的技術人員:

            第一種人是外語不過關的人。

            語言是交流工具。如果客戶是歐美客戶,英語交流是必不可少的。如果客戶是日本公司,對日語要必須熟悉。作為初級的外包技術人員,需要閱讀和寫作大量的文檔和郵件,這些都需要良好的英語能力。很多英語不過關的人員不容易通過外包公司的筆試。對英語的要求,需要達到熟練閱讀英文文檔,寫作專業的測試缺陷報告和日常郵件寫作的程度。

            外包公司強調英語的重要性,這是做好工作的基礎,因此,請在學校里、公司里利用一切條件自覺學習英語,養成習慣,從閱讀理解學習。把英語閱讀和寫作養成一個習慣,終生受益。

           第二種人是癡迷于鉆研軟件高深技術的人。

            軟件外包服務的很多工作都是非?,嵥榈模瓷先]有多少高深新技術的事務性工作。例如,對日軟件外包的項目,客戶已經編制好了程序框架,需要變成人員根據他們的規范編寫代碼和每天工作進度日志。不少外包編程人員抱怨客戶限定的過于嚴格,沒有足夠的自我創造的空間。對于軟件外包測試人員,最常見的工作就是執行客戶編寫好的測試用例,報告軟件缺陷,很少有機會從軟件項目的全局高度制定測試計劃,確定測試方案和策略,安排資源和進度。

            如果你對軟件編程的各種新技術無限熱愛,習慣于一個人無拘無束的從事軟件產品的開發,最好不要去軟件外包公司,否則很難發揮你的聰明才智。這樣的人更適合自己創業開發獨立的軟件產品,或者到中國中小型軟件公司當軟件開發工程師。

            第三種人是大事做不來,小事不愿做的人。

            正如前面說過的,很多軟件外包工作非常具體和瑣碎,需要非常好的做事態度,滿足客戶各種合理的和不合理的要求。有些同學到軟件外包公司工作不久就感到失望了,抱怨工作枯燥,看不到前途。這些都是剛參加不久的人容易產生的錯誤認識。

            在任何軟件外包公司,如果個人的工作能力非常突出,很容易被領導賞識和提升,因為軟件外包發展太快了,對人才的需求非常強烈。但是如果不從具體的瑣碎的小事做起,并且把小事做好,怎么能證明你可以把大事做好呢。

            任何公司之所以能夠生存、發展、壯大,必尤其成功之處,不要覺得你必老板高明很多。比較聰明的同學會放平心態,從學徒學起,把每一件工作都做好了,自己的長處得到發揮,對自己的前途發展大有幫助。

            總結起來,不善于外與交流的,癡迷于鉆研軟件高新技術,不能踏踏實實工作的人,不適合到軟件外包公司從事軟件技術工作。

            9、如何通過軟件外包公司的面試?

            如何通過軟件外包公司的面試?這是很多同學都很關注的問題。面試成功來自于應聘者自身的綜合實力和運氣。為了提高面試成功率,請按照以下幾個方面進行準備。

            (1)制作有吸引力的求職簡歷

            外包公司的招聘專員每天都會收到幾十封甚至上百封求職簡歷,如果你的簡歷很平淡,可能很快從招聘專員的眼下溜走,失去了面試的機會。

            什么是有吸引力的簡歷? 簡單地說就是讓看到你簡歷的招聘專員相信你就是他們正在尋找的最合適的人。因此,你的簡歷要簡明扼要,列舉出符合他們要求的條件和相應的客觀證據。要明白求職簡歷目的就是獲得面試的機會,否則你的水平再高,也不可能進入招聘專員的“法眼”。

            如何寫出具有吸引力的簡歷,現在很多資料都比較詳細,但是最重要的一點是實事求是,反對夸張和吹噓。把你的技能和經驗按照招聘職位的要求進行內容和形式的組織即可。

            (2)準備面試

            ● 了解要去面試的公司,可以瀏覽公司的網站,媒體報道,同學和朋友的介紹。
            ● 了解公司的行業,規模,現狀和發展概況。
            ● 技術準備,準備應聘職位要求的技能
            ● 模擬面試場景(包括英語自我介紹和書面答題)
            ● 準備自我介紹、各種證書、筆試和面試解答問題
            ● 計劃乘車路線和穿著打扮等外表形象

           ?。?)參加面試

            ● 準時
            ● 誠實
            ● 積極
            ● 友好
            ● 不必不亢
            ● 注意細節
            ● 沉著冷靜
            ● 避免爭論
            ● 小心“陷阱”
            ● 充分發揚長處
            ● 展示個人綜合能力









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

          軟件測試管理給我的三大啟示

          軟件測試管理給我的三大啟示

           1、軟件測試團隊組成應該是技術背景的人員為基礎

            現在大部分的國內軟件公司測試人員基本對于編程的了解非常的淺顯,像專業性很強的軟件產品可能更多的是業務人員組成的測試團隊,比如我目前的ERP產品測試團隊大部分人以往都是從事財務、供應鏈和生產制造的從業經驗,他們在業務流程以及行業知識上較為豐富,但對于軟件開發基本都沒有概念。專業的公司例如google,微軟等他們的測試人員都是由開發人員轉入的,測試人員甚至能力強于開發,因為開發不會測試,但測試會開發。業務人員主導的團隊和技術人員主導的團隊截然不同,從思維還是方法上都有較大的差異。業務主導的測試會從業務的角度去驗證產品,但他們可能選擇的是“最笨”的辦法去一遍又一遍去驗證業務流程,當業務流程有成千上萬或者網狀業務流的時候就傻眼了,因為你永遠不可能完成所有的業務驗證。技術主導的測試就不一樣了,技術人員的天性決定了,他們從測試的第一步開始就想著如何能夠使用最為簡單,更為聰明的方式去驗證業務流程,他們甚至會絞盡腦汁的去設計測試腳本,通過最高效的技術手段去使用最為聰明的方式來全面驗證業務流程,因為他們有良好的技術。很多深層的缺陷從黑盒的角度可能是永遠無法發現的,但對于技術測試人員來說可能就是輕而易舉的事情。測試團隊的構成應該更加合理,技術測試和業務測試的結合是非常必要的,這也是目前國內軟件公司最為欠缺的,這也是為什么現在測試在國內無法得到足夠的尊重的重要原因,因為缺乏技術含量!

            2、開發人員對于產品質量的保證是核心關鍵

            當我們的測試人員每天隨隨便便就能輕松發現數十上百的缺陷,并甚至以此為優秀測試人員評價標準的時候,google的測試人員卻在為每天能發現2個缺陷而高興,甚至為了這2個缺陷還要編寫大量的測試腳本和測試模型。因為他們在前段編碼環節就已經做到了良好的質量控制,對于測試已經是精益求精的。現在國內的很多軟件公司開發人員管的就是開發,好一點的公司可能會要求一些單元測試,但要求的深度缺乏衡量的標準。老師問了我,我們公司編碼的效率,我說人均200行/天,他非常的驚詫,因為他們公司的編碼效率是40行/天。因為他們每天除了編碼,還要做好多質量保證的事情,首先開發人員要對需要編碼的功能做設計分析,思路清晰后才開始編碼,編碼完成后要花將近一半的時間去做單元測試,來保證編碼的質量。所以到了測試環節,每天就只能發現零星的幾個bug。這個太讓我吃驚了。對于我們經常會以任務緊,沒時間等客觀因素壓縮設計和單元測試的時間,短期的效率換取的是長期的痛苦,甚至是用犧牲品牌的價值而換取的。

            3、自動化測試要做前后端分離的測試,UI的自動化測試不可取

            聽到這個其實對我是一種打擊,因為我們風風火火的自動化目前較多還是基于UI的測試,確實由于業務的復雜度以及更新的頻度對于我們自動化的測試沖擊非常大,用例更新維護的成本甚至超過了自動化測試本身帶來的價值。對于功能、界面頻繁變動的產品不太適合大量使用UI自動化測試。但產品的現狀又不可能為了自動化測試的需求而進行大幅的更改。這個問題還在冥思苦想中。自動化測試4年了,從無到有,取得了突破性的進展,但目前卻是一個轉折點,如果最大化體現自動化測試的價值任重道遠。從UI自動化到底層自動化突破是扭轉自動化測試的關鍵。

            突然好想去微軟、谷歌、甲骨文、IBM這樣的卓越企業,想去接受高成熟度的IT公司的洗禮。相信能從他們那里學到很多很多。唉,可惜只怪自己英文太爛!進這樣的跨國企業沒什么機會。

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

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

           5、傳統測試階段

            當開發完成了所有的功能點,測試那個時候也差不多完成了這些功能點的測試,我們就會有一個階段性的最終版給客戶評估,讓客戶看看需要的功能是不是都已經可以了,如果覺得沒什么問題,一般情況下就不進行功能添加與更改了。(當然,真的要更改我們還是會歡迎的,不過一般客戶也知道,頻繁的更改不能保證產品的質量,所以到最后他們一般有不緊急的更改也會要求放在下一個版本里的)

            到目前為止,真正意義上的敏捷測試階段其實已經完成了,要開始進入一些傳統的測試了,比如系統測試性能測試,壓力測試等。這些就會用到之前說的DevTest里管理的測試用例,通過這些測試用例,我們會生成測試任務,然后通過手工和自動的方式,把這些任務完成,當然,可能要進行幾輪,第一輪測試最仔細,覆蓋面最大,所以時間也最長,第二輪主要是對開發修Bug的確認以及可能影響到的功能的測試,最后還有一輪驗收測試,主要對基本的功能進行測試,確保不會出現明顯的問題。

            這些測試都完成以后,差不多產品也就可以發布了,當然能不能發布,領導們還是會有一個會議研究通過的,不過也就是通過 DevTrack 和 DevTest 來導出一些報表看看測試情況來了解產品質量。

            以上差不多就是我們公司現在的一個流程,從嚴格意義上來說,不是完全的敏捷測試,只是算一部分,但是如果從以前的瀑布來看看,已經算很敏捷了。而且,從現在這個流程分析,如果把那些傳統意義上的測試繼續敏捷化,我們覺得對產品的質量沒法保證,所以基本上,目前這個模式,可以算是我們公司特色的敏捷測試了,之后應該不太會有大的更改了。

            接下來我再總結一下我們公司的模式,以及補充一些之前沒提到的,因為之前寫得太急,有時候很難想得太全。

            我們公司測試模式按照順序主要有以下這么幾步組成:

            1)需求階段測試研究設計方案是否符合要求

            2)開發編碼期間完成測試用例

            3)開發完成一個功能的編碼,測試就需要開始測試,并且確保能在一個迭代周期中完成測試,并且確認嚴重Bug的修復

            4)所有迭代周期完成后,開始進入集成測試,系統測試,驗收測試以及壓力測試,性能測試

            差不多測試需要參與的工作就是這幾步了,下面就是有一些細節點討論一下,我會以問答形式來介紹:

           ?。?)問:發現了很多Bug,測試人員怎么知道哪些Bug要馬上修,哪些可以推遲修呢?

            答:首先,我們會規定什么樣子的Bug需要什么樣的優先級,比如報錯優先級就會比較高,每個測試人員都有這么一個文檔讓他們來判斷這個 Bug 是什么級別。其次,我們會有專門的人員對這些Bug進行二次過濾,由他們來覺得這個Bug是否需要在這個迭代周期中進行修復,這種專門的人員的能力需要很高,因為他們需要能了解這個Bug的重要性以及這個Bug修復起來所需人力物力是否能在這個迭代中解決,所以一般這個角色會有測試主管或者項目經理來承擔。

           ?。?)問:整個測試期間,就專職的測試人員參與測試就行了嗎?

            答:不是的,首先開發肯定需要進行單元測試;然后設計人員和項目經理也要參與測試,因為只有他們最清楚這個功能設計的初衷,才能真正知道現在做完的是不是真的符合當初的初衷;再次,客戶也會參與測試,因為產品說到底最終是給客戶使用的,他們當然想拿到一個他們滿意的產品,所以我們會定期給客戶版本,讓他們對做好的功能點進行簡單的試用,讓他們來看看產品是否符合他們的需要,這樣就是最直接的用戶體驗了,發現的問題也是最真實的。 
          (3)問:測試過程中是否需要開會?

            答:需要,測試人員也會有每日立會,跟開發差不多,也是介紹,昨天做了什么,今天要做什么,之前碰到什么問題。會議效果很好,首先讓大家知道其他人在測啥,然后如果有問題的話,大家一起討論就可以共同進步。另外測試也需要有反思會,看看這一輪發生的問題,為什么有些Bug沒有找到之類的。

           ?。?)問:敏捷是否需要特別的測試技術?

            答:不需要,敏捷只是一種思想,有一些價值觀,它不會教你用什么方法去測試一個產品,只會教你以怎么樣的一種態度去做測試,以怎么樣的時間安排去開展測試。

           ?。?)問:敏捷是否還是需要回歸測試?

            答:需要,回歸測試仍然屬于一個比較重要的環節,不管是敏捷還是傳統的測試,只是由于敏捷測試中對時間的要求越來越高,使得本來需要大量時間的回歸測試越來越難實施,所以目前的趨勢是盡可能把回歸測試用自動化測試來實現。對于我們公司而言,這也是一個方向,有些部分也在開始,但是由于產品邏輯比較復雜,很多功能有自動化測試實現會比較麻煩,所以現在我們的回歸測試有相當一部分還是人工的方式,當然最終必然是會大部分采用自動化測試的。

           ?。?)問:對于重復的Bug,怎么去處理?

            答:其實我也咨詢過不少公司,很多公司是不允許重復提交Bug的,所以提交之前需要先去確認是否其他人提交過,我相信這個確認過程應該會花費不少時間,不過對于開發而言應該會減少時間,因為不會出現重復的Bug;當然也有一些公司允許重復提交的Bug,原因也很簡單,覺得對于Bug而言,只要是必須修的,發現了就得提,別人提過當然最好,但是就怕別人沒提過,你卻認為提過就不提了,最后客戶發現就慘了。所謂“寧可錯殺一千,不可放過一個”就是這個道理了,呵呵。我們公司是允許提重復Bug的,當然是在不知道有其他人提過的前提的,你如果已經知道別人提過了,當然就不能再去提了。

            敏捷測試差不多就講到這里了,也許有人清楚有人迷惑,水平有限,也沒法講得太好,望見諒。如有問題,可以私聊。謝謝大家一直看完!

           ?。ㄈ耐辏?/p>

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

          軟件項目管理實踐之如何實施質量控制?

            質量控制包括對項目管理過程績效和項目可交付成果的質量控制。質量控制主要通過文檔評審、技術評審、代碼走查和測試檢查實現。

            一、技術評審

            技術評審包括技術文檔評審、技術實現評審和代碼走查。

            1、文檔評審

            實施過程前期產生的需求規格說明書、系統設計說明書、測試用例等文檔是后期編碼、測試的主要依據和輸入,這些文檔的質量直接決定了軟件系統的好壞、系統返工的多寡以及客戶滿意度。因而對這些文檔的評審尤為重要,評審的目的在于在交付給下游開發或測試時及早發現問題,修正錯誤,以免問題和錯誤在系統中的蔓。

            文檔評審采用同行評審會議的方式進行,由項目經理組織,開發相關文檔參與的角色包括其他子系統的系統分析員、質量控制部相關人員、其他兄弟部門有類似經驗的系統分析員等;測試相關文檔則由項目經理、測試經理、系統分析員和其他測試人員參與。評審過程中,主要從以下幾方面考察文檔的質量:

            ● 可讀性。主要從文檔是否符合公司模板規范、邏輯結構層次是否清晰明確、文字表達是否無歧義等方面判斷;

            ● 完整性。主要從文檔是否完全滿足要求,是否已覆蓋所有的功能點等方面判斷;

            ● 一致性。主要判斷文檔表述是否前后不一、是否有矛盾等;

            ● 技術可行性。主要判斷目前的技術框架是否支持,是否有類似的經驗,是否有技術風險等。

            2、技術實現評審

            技術實現評審包括項目技術框架選型評審、具體某個模塊的技術實現方法評審。技術框架的評審目的是為了在進入大規模編碼開發前確認選擇何種技術框架、判斷現有的技術框架是否滿足項目功能和性能需求、框架是否足夠穩定以及可能存在的風險等;具體某個模塊的技術實現方式評審目的是為了保證選擇的實現方式目前來說是最優的、可以推廣到其他模塊使用的。技術評審通過評審會議的方式進行,參與的人員包括項目經理、系統分析員、開發人員、公司內部相關技術的專家、有同類項目經驗的實施人員、質量控制人員等。

            3、代碼走查

            代碼走查主要是對軟件代碼進行復審,主要以高級程序員復審代碼或同級別的程序員交叉檢查的形式進行。代碼走查的目的是通過抽查,保證代碼的編寫和注釋符合編碼規范,編碼邏輯符合系統設計要求,減少測試返工以及因測試返工引起的來回溝通、回歸測試等問題,降低管理成本,提高開發效率。

            二、測試檢查

            測試檢查是由測試人員根據測試用例對軟件產品進行功能測試以及使用壓力測試工具對系統進行壓力測試。測試檢查的目的是確保交付給客戶執行驗收測試前軟件產品經內部嚴格測試,檢查系統是否滿足用戶需求和符合實際應用環境的需要,從而增強客戶對項目成功的信心。

            我們定義了五個測試檢查過程,包括單元測試、集成測試、系統測試、客戶驗收測試以及確認缺陷已正確修復的回歸測試。

            單元測試由開發人員自行負責,測試通過標準由系統分析員制定,測試團隊核準,確保開發人員在提交代碼前在本地已經過測試,主流程可以跑通,可以進入集成測試階段。主要目的是通過自查自糾減少返工以及降低后續測試階段中開發人員與測試人員之間的來回溝通成本。

            集成測試由系統分析員負責,通過集成開發人員提交的代碼,利用Ant等自動化工具發布到測試環境。系統分析員選取典型的測試用例對軟件產品進行測試,確保業務模塊在操作過程中沒有出現重大的業務邏輯錯誤以及頁面方面的低級錯誤,可以提交到測試團隊進行進一步的深入測試。測試過程如出現問題,進一步分析產生原因和影響分析后提交到JIRA系統中交由開發人員處理,同時在JIRA系統上進行缺陷跟蹤。

            系統測試由測試團隊負責,依照經過評審的測試用例對已發布可用于測試的軟件產品進行全面的功能性測試,確保系統滿足功能需求。測試過程中,發現的問題連同問題出現時的系統截圖一并提交到JIRA系統中,由系統分析員分析后轉由開發人員實施缺陷修復,同樣的,在JIRA系統中進行缺陷跟蹤。

            客戶驗收測試由客戶需求負責人負責,測試團隊配合完成。測試的過程也是對客戶系統操作培訓的過程,必要時,由系統分析員給客戶演示和解釋。客戶需求負責人往往是業務骨干,精通業務規則,熟悉業務流程和操作,可以對系統進行更深入的功能測試,發現隱藏較深的缺陷或者因為考慮不周引致的設計缺陷。

            回歸測試由測試團隊負責,根據JIRA系統上的缺陷修復狀態,對已包含缺陷修復的版本進行驗證測試。測試過程不單是對缺陷修復進行驗證,同時對因修復缺陷影響到的其他模塊進行回歸測試,確保缺陷被正確修復的同時不影響原有模塊以及不引入新的缺陷。由于回歸測試的工作量很大,我們使用QTP工具,通過錄制測試腳本,使回歸測試可以自動化執行,減輕測試團隊的負擔,提高工作效率。

            每周的測試情況以測試周報的形式體現,周報內容包括測試范圍、測試過程中遇到的問題以及解決方法等。另外,周報還報告了缺陷的統計信息,包括缺陷總數(其中:本周新增的缺陷)、已關閉的缺陷總數(其中:本周關閉的缺陷)、已處理但未關閉的缺陷總數、正在處理的缺陷總數以及未處理的缺陷總數。通過這些信息基本上可以看出軟件系統的缺陷趨勢,從而為后續的決策提供量化支持。

            測試發現的缺陷我們使用JIRA系統進行跟蹤和監控。測試人員在系統上提bug,由相應的系統分析員負責對缺陷進行原因分析和影響分析,必要時與程序員一起確認問題產生的原因和可能影響的模塊,分析后轉交由相應的開發人員進行修改,缺陷修復并經單元測試后發布到測試環境交由測試人員進行驗證測試并關閉此問題,最后由客戶進行驗收測試后并確定發布版本和發布時間后予以發布。在這個流程中,測試人員驗證測試時需要對該缺陷涉及的本模塊其他功能和其他模塊進行一輪回歸測試,確保已修復的缺陷不再重復產生,其他功能不受影響。

            另外,為了確保已發現的缺陷不再重復出現,對于頻繁出現的,如界面顯示的是代碼而非中文、缺乏信息提示、沒有進行邏輯檢查、后臺計算結果有誤等缺陷進行進一步的分析,找出是因為系統設計文檔的缺陷、人為疏忽還是沒有按照設計文檔設計或其他原因所導致,從而制定相應的改進措施。

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

          初探團隊基于session的探索性測試

          如果你是一名測試人員,那么不管你對探索性測試的了解是多是少,我肯定你一定用過探索性測試的方法。想想看,你是否曾經這樣測試過?不僅僅按照測試案例或者腳本上寫什么,就完全使用那一套相同的數據、一模一樣的流程,而是根據你執行時的所見,臨時有所想和所動,進行一定程度的自由發揮?我想你肯定有過,這就是探索性測試,它將你的測試與純基于腳本的測試(script. based testing)區分開來。而這種自由發揮,因為是有大致方向和范圍的,所以也與完全盲目亂點的猴子測試(monkey testing)不同。

            換言之,因為你是人,所以你比猴子和機器人都聰明,你懂得在學習中不斷完善自己,而不是漫無目的或者按圖索驥。因為你是測試人員,所以探索性測試是你必備的職業技能。而如果不經過一定的理論指導和系統實踐,我想憑著那點探索的本能,你還不足以成為一名高效的測試人員。如果想快速提高探索測試的技能,我認為最好的方法是和你測試組的伙伴一起來實踐和提高,而不是一個人練習。如果你所在的團隊還沒有過這方面的實踐,那么你可以從本文當中了解到我們團隊中基于session的探索性測試的實踐和感悟。

            為什么我們選擇基于session的探索性測試?

            基于session的探索性測試在2000年由James Bach和Jonathan Bach兄弟倆創建。這里的Session其實就是一段指定的時間,比如從8:30到10:00的一個半小時。探索性測試可以不基于session。至少在讀完J Whitter的“探索性測試”一書后我完全沒有覺得session是探索性測試中的一個關鍵詞。但是查閱探索性測試資料,你會發現實踐中的探索性測試很多都是基于session展開的。我們實踐了以下三個基于session的探索性測試的要點,并感受到了它的益處。

            1、因為session,更專注

            因為每個session都有確定的開始和結束時間,一般長度為一小時、一個半小時或者兩小時,所以在這有限的且不算太長的時間里,測試人員會更專注,從而效率更高。

            我清楚地記得,有一天下午我們小組(4個測試人員)計劃了兩個各一個半小時的session。第一個session結束,當我們做debrief(下面會介紹debrief)的時候,有兩個人明確提出下面即將開始的新的session能否改成一個小時,因為過去的一個半小時太累了,“大腦都要缺氧了!”當然,剛收獲了近40個缺陷和近30個疑問的這個session,無疑大家都是很辛苦的。但是,從另一個方面,我們也看到,平時如果沒有session,大家的專注程度是否還可以提高一點呢?對我而言,雖然感到這次和我平時個人做探索性測試的專注程度類似,但在一個集體做探索性測試的氛圍下,似乎也更有時間的緊迫感了。我想這就象自己在家做模擬卷和在學校里和同學一起模擬考一樣,總有那么點不同的壓力。

            2、因為charter,強迫思考

            在一個既定的方向或者說章程(Charter)上一定要發現缺陷,這其實是強迫你思考和挑戰自己的思維局限。

            我喜歡看釣魚比賽的節目,也感到它和測試的相通之處很有意思。例如,釣魚的挑戰在于:如何在你已經非常熟悉、覺得無魚可釣的水域找到魚;如何在一個你不熟悉的水域,快速釣到大魚;如果你可以自由選擇,你將換到哪個水域(因為根據經驗你猜想那里可能有大家伙)?精明的垂釣者不單有專業的釣竿(測試輔助工具),對天氣、水域(軟件工作環境)和魚生活習性(被測系統的功能)的了解,還要有一些很重要的臨場判斷(根據前面幾條魚的大小和難易程度判斷今天在這個地方釣上大家伙的概率,以決定下一步是繼續在這里守株待兔還是馬上轉移)和一點點的運氣。關于運氣,我覺得測試中也一定是有的,但是我更相信機遇或者運氣是比較垂青有準備的頭腦的。所以,我總是愿意花時間去多測測,花心思去少測測。

            想想測試中,我們是否也面臨和釣魚類似的挑戰?如何在你已經測試了一段時間,覺得比較穩定的功能上找到新的缺陷?如何在你不熟悉的模塊,快速找到缺陷?如果一種方法找不到缺陷,接下來該換種什么樣的思路?

            突破自己思維的局限,我們團隊中每個人都在實踐多種不同的方法。比如,探索性測試一書中的各種方法(遍歷法、強迫癥法、取消法、超模法。。。),自創或者借鑒的各種測試的常用方法(web測試要點、安全測試常用方法。。。)以及Test Explorer工具的小提示等等。

            當我們設定所有測試人員都采用同一種方法來測試的時候,報出的不同的缺陷往往非常令人印象深刻。我們也在一起分享、總結、積極尋找測試某個軟件的最管用的探索性測試方法是哪一兩個。強迫自我突破,學習他人突破,三個臭皮匠頂個諸葛亮!

            3、因為匯報(debrief),團隊力量勝于個人

            我個人覺得,個人的探索性測試和團隊的探索性測試在流程上最大的差別就是匯報(debrief)。這是一個session結束后的短暫討論環節。我們采用的是Jon Bach提出的PROOF模式。PROOF即Past, Results, Obstacles, Outlook, Feelings的首字母縮寫。按照這個形式,我們會逐個分享過去這個session自己完成的工作、得到的結果、碰到的困難、接下來需要進行的工作(可以作為下一個session的目標)、自己的感覺。在這個環節里,我們會對一些公共的問題或者大的障礙進行一些溝通,但不會太長時間討論,而主要是讓團隊成員知曉一些我們認為重要的信息。這里,我們經常能夠發現共鳴或者別人輕易就解釋了我們的疑惑。如果我們做的charter是同一性質的,如易用性,那么我們會在每個人都以PROOF模式做簡要匯報后,按照session報告中缺陷和問題的記錄,快速過一遍每個缺陷和問題。這對于我們能夠及時學習和借鑒別人的測試思路,馬上運用到自己接下來的測試過程有一定的幫助。我感到:通過debrief環節的及時溝通和互相學習,我們將探索測試的精髓也擴展到了我們的團隊學習和實踐中,即在一個很短的周期內,學習和執行是融為一體的,而不是順序的、隔離的。

          用ET測試自己的模塊和別人的模塊

            1、測試自己的模塊

            當用探索性測試方法測試自己的模塊時,在功能方面能更為有效地發現缺陷,尤其是那些復雜功能。另外,我們覺得有些探索性測試的方法應該被本模塊負責的測試人員優先采用而保證其質量,不應該由別的測試人員來嘗試。比如,確保所有按鈕都可以工作,所有報錯信息都正常顯示,所有字段最大長度檢查都通過等。因為如果一個別的測試人員隨機地去檢查字段長度,而結果是被測的正好沒問題,漏測的地方正好有問題,這就可能給團隊一個錯誤的信息。這種情況屬于基于腳本的測試沒有到位?;蛘邉e的測試人員逐個檢查每個字段長度而發現全部都沒有問題,最后才知道這是因為已經被本模塊測試人員測試過并且缺陷被修復過了,這就是一種資源的浪費。

            2、測試別人的模塊

           ?。?)為什么要測試別人的模塊?

            有人也許會問:“如果每個測試人員都可以熟練有效地運用探索性測試方法來測試自己的模塊,那為什么要互相交換,去測試別人的模塊呢?”這是個很好的問題。帶著這個疑問,我們嘗試了測試別人的模塊,并發現了以下的必要性和好處。

            ● 避免自己難以發現的問題被遺漏

            人無完人,測試人員也不例外。每個人每次測試中的盲點并不都能被自己及時發現。而換個人,這樣的問題容易很快被發現。對于團隊來說,這是一種高效的做法。

            ● 利于知識傳遞和儲備

            測試別人的模塊,利于及時深入了解被測對象的詳細復雜邏輯。當你被要求去探索性測試一個不熟悉的復雜功能時,如果事先不做一些功課,相信你甚至都很難訂出一個自己覺得合理的charter。硬著頭皮上的后果是在一個明明有大貝殼的沙灘,花了時間卻只撿到一些零零碎碎的小貝殼。這對組織是危險的,對自己也是令人沮喪的。

            ● 有很多好的問題(issue)被提出,或者再次被提出

            不難理解,因為視角不同,交換測試的時候會有很多好的問題被提出。再次被提出是指原來測試的人員也有類似的感覺,但不那么強烈;或者曾被諸如“用戶不會這么做或者這樣想”而遭到過開發人員的拒絕。這種問題一旦被再次提出,往往就更具有說服力,值得舊話重提。

           ?。?)測試別人的模塊時如何選擇charter?

            經過實踐,我們發現利用探索性測試測試別人的模塊時,在易用性、用戶界面顯示、模塊交互、類似功能的一致性等方面能夠高效地發現有價值的缺陷。

           ?。?)測試別人的模塊時應避免的情況

            為了避免資源的浪費,我建議在測試別人的模塊的時候先告知原來負責測試這個模塊的人員你接下來的session里測試的范圍和方向。盡量不要去測試那些已經做過大量測試的非主要功能,而主要功能則可以運用以前沒有運用過的探索性方法再深入測試。比如,原來的測試人員在主要功能的數據多樣性方面已經進行過大量測試,而按照操作順序這種探索性測試方法相對運用得比較少,這就將是你的更好的方向。

            另外,測試時報告的缺陷數量固然重要,但我們的目標不是報告更多的缺陷,而是報告更多有商業價值的缺陷,所以應該避免在一些很邊緣的或者細小的地方報很多類似的缺陷,同一類型的小缺陷算一個缺陷就夠了。

           ?。?)如何看待別人在你的模塊報告的缺陷?

            正如在你的一畝三分地上,當你自己已經覺得收割完畢,而看到別人仍然收獲頗豐的時候,除了不敢相信,我很難想像你會有更開心的第一反應。而我覺得人與人的差別往往在于第二反應,在于不敢相信之后你會做什么。當別人在你的模塊報告較多的缺陷時,大多數人會仔細看一下,確認到底是什么問題,接著以“了解了”結束。有一部分人會想“如果也給我一個同樣charter的session,我能報出這個缺陷么?為什么?”還有人會去匯總背后的原因,分享這些心得,以后測試的時候能提醒自己和團隊朝這些方面改進。

            經過初步嘗試團隊的基于session的探索性測試,我感到了其與個人的基于session的探索性測試的互為補充之處,也實踐了如debrief這樣的團隊實踐。下一步,我們將對測試的結果進行分析,持續探索利用探索性測試提高測試有效性和效率的有效方法。

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

          步步學LINQ to SQL:使用LINQ檢索數據

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

            第一篇:步步學LINQ to SQL:將類映射到數據庫

            一旦你將數據庫表映射到對應的類對象上并在DataContext中申明了到數據庫的映射關系,你就可以不需要使用一行數據庫代碼(SQL語句)訪問數據了。

            通過一個簡單的示例BookCatalog(強類型的DataContext)來說明,你可以通過使用在Authors,Books和 Categories中定義的集合從數據庫中訪問book,author和category。

            例如,要查找書的類別,你所要做的就是循還bookCatalog.Books對象并且LINQ會自動地查找數據庫(通過映射關系)并填充你使用的集合---使用Book類為要查找的每本書創建一個實例:

          BookCatalog bookCatalog = new BookCatalog( );
          foreach( Book book in bookCatalog.Books){
          string title = book.Title;
          decimal price = book.Price;
          }

            你也可以使用LINQ來過濾這些結果集,因為大多數時候,你并不要一次返回所有的書或者基于性能方面的考慮也不會這么做。

            LINQ提供了一套完整的類似于SQL語法的語言,該語言已經被集成到了.NET語言(C#,Visual Basic)。對該語法的描述超出了本文的范圍,下面我們一起看兩個例子以了解它們是如何使用的。

            因為BookCatalog返回一個集合對象,我們使用的查詢語法將會查找這些對象(意味著你將直接使用對象名以及它們包涵的字段或屬性而不是數據表的字段)。因此,例如,如果你僅僅想查找價格低于$30的書籍,你可以使用一個LINQ where從句,該從句可以僅僅只從bookCatalog.Books集合對象上查找價格低于$30的書:

          IEnumerable cheapBooks = from book in bookCatalog.Books
          where book.Price.CompareTo( 30m ) < 0
          select book;

            LINQ的延期執行意味著對books集合的檢索不會即時從數據庫取得直到實際需要時才進行(例如,使用一個foreach循還),因此我們可以保持應用的過濾條件,然后限制查詢的數據以確保讀取數據的效率。

            例如,你以后可以使用LINQ提供的orderby語法來定義上面的結果集將數據按書的標題進行排序。

          IEnumerable sortedBooks = from book in cheapBooks
          orderby book.Title
          select book;

            現在,如果你在執行了LINQ查詢鏈之后通過sortedBooks執行循還,僅僅只會執行一次數據庫查詢。其結果仍然會返回價格低于$30并且按照書的標題排序的所有書。

          BookCatalog bookCatalog = new BookCatalog( );
          IEnumerable cheapBooks = from book in bookCatalog.Books
          where book.Price.CompareTo( 30m ) < 0
          select book;
          IEnumerable sortedBooks = from book in cheapBooks
          orderby book.Title
          select book;
          foreach( Book book in sortedBooks ) { ... }

            現在我們一起看看如何映射對象之間的關系以便你能夠操作這些對象(例如book.Author.Name)。

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

          以小見大、由淺入深-談如何面試Javascript工程師

           面試Javascript工程師難嗎?Javascript工程師的水平參差不齊,如何評定他們技術水平的高低?如何確定Javascript工程師適合承擔哪方面的任務?我在騰訊時的面試經驗是,通過不同緯度的結構化問題、由淺入深的進行考查。

            基礎

            如何判斷一個對象是方法?這個問題簡單有簡單的答案,復雜有復雜的答案,但可能都不是最好的答案。

            頁面加載和渲染的過程:簡單一點只考查JS、CSS、IMG的加載順序和過程,復雜一些則涉及內核間的差異以及并發處理。對于這個問題是否理解是寫出高效率代碼和結構的必須。

            冒泡與捕獲:它們的定義,它們的區別,如何阻止冒泡?基礎知識,經典題目。但是不是每個人都能完整全面的回答出這個問題,面試者需要對DOM tree有自己的理解。

            閉包:閉包是一個很好的面試題目,能夠很好的考查出不同水平的面試者。了解什么是閉包、如何使用閉包、閉包的原理、閉包的真正原理,只有對JS的作用域鏈、垃圾回收機制有深入了解的工程師才能正確無誤的完整回答這個問題。

          Scope Chain是了解Closure原理的關鍵

            工具庫

            jQuery:考查編程習慣和經驗。jQuery作為現在使用最為廣泛而且最簡單的JS庫,能夠很好的測出使用者的開發經驗和JS水平。一個有著真正開發經驗的工程師,應當能正確的寫出各種類型的選擇器,回答為什么用bind來進行事件綁定、mouseover和mouseenter的區別。如果這些考不倒他,別急,live方法的實現原理、ready方法的實現機制這兩個問題足以考查出他對DOM、瀏覽器差異的認識。

            extJS、YUI、Prototype:這些工具庫或框架都有各自的特點,可以采用像上面類似的問題從淺入深進行了解。

            實際問題

            解決實際問題考查的是你把知識融會貫通的能力、解決問題的能力、理解能力以及學習能力,這對綜合素質的考查是一種很好的方式。第一次面對一個問題,面試者是否能迅速給出思路、由過程推導出結果,能否在一些提示下一步步得到最終的完整答案,這都是很好的考察點。

            Autopager:自動翻頁功能是一個由淺入深考查面試者能力的好例子。對滾動條事件的了解,pageHeight、windowHeight、scrollY的區別和關系是兩個關鍵點,而最后對于事件的clearTimeout優雅處理是隱藏的考查點。

           Lazyloader:許多人見過圖片延遲加載的產品,但是他們是否有了解過背后的實現原理?從功能抽象到具體實現,onresize的考慮、延遲觸發的考慮,這道題目有一定難度,和上面的例子也有一定相似之處。

            經過了前三個方面的了解,你應該已經對這個面試者的基本水平有了一個大致的判斷。下面的步驟可以讓你了解這個人能夠承擔什么樣的工作,他的發展潛力多大。

            項目

            通過之前的項目經歷可以認識他的Team work能力、解決問題的能力,在項目中的角色和承擔的責任也可以反襯他的個人能力。

            如果他沒有做過跨瀏覽器開發,那么這種需要長期積累的任務就不適合分派給他來解決;如果他曾經有瀏覽器插件的開發經歷,那么瀏覽器App的工作也許能夠利用他的現有經驗;如果他用過jQuery Mobile、sencha touch或者XUI,那么他可能適合開發移動Web App。作為管理者高明的地方在于,把合適的人用在合適的地方。

            技術視野

            具有技術視野的人一般具有很大的發展潛力,他們未來不會僅僅只是一個普通的工程師,而有可能會成長為技術專家或者技術管理者。

            在HTML5方面應當對新的語義標簽、Canvas、Webworker、Drag & Drop有所經驗或者了解;在CSS3方面,應當或多或少嘗試過Radius、Gradient、Transform。當然,如果能夠了解Mask,甚至能夠知道Flexible Box的使用方法和原理,那么這個人對盒子模型的理解和對新知識的學習能力可以得到很好的體現。

            JS開發工程師是最容易的職位,也是最難的職位。新的技術和框架層出不窮、瀏覽器版本日新月異、越來越多API的出現,好的JS開發工程師需要隨時學習和更新許多知識,包括后臺(Webworker、Websocket、Node.js)、UI(Canvas、Transparent)、動畫(Transform、Transition、Animation)等方面。面試者是否有自我更新意識,他的技術視野多高決定了他能夠涵蓋的范圍多大,他的未來發展潛力多大。

          HTML5已經戰勝移動Flash,前途無量

            如果能夠把以上所有問題清楚、順利的回答完整,我相信他的表達能力、溝通能力應該是相當優秀的,同時值得欣喜的是,我們又找到了一位優秀的同伴。

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

          挨踢項目求生法則-戰略篇

          挨踢項目求生法則-戰略篇

            摘要:

            知道什么是挨踢項目吧?什么!不知道?那IT項目知道了吧?為了不讓客戶踢、不讓老板踢、項目組成員之間不互相踢,俺為大家分享一些減少被踢機會的心得體會。就算不能讓項目成功,也至少不會死得那么慘吧!我將分戰略篇、團隊建設篇、需求篇、設計篇、編碼篇、測試篇、實施篇和計劃篇為你分享。

            什么叫挨踢項目?

            IT項目,特別是軟件開發項目,都屬于“挨踢”項目的范疇。挨踢項目的幾大特點:

            1、需求不確定。
            2、技術不確定。
            3、工期限死。
            4、預算限死

            兩大不確定和兩大限死,你想不“挨踢”都難!

            指揮戰爭可能是最復雜的項目管理

            做挨踢項目可能比較杯具,但最復雜、難度最高、代價最大的項目管理可能是戰爭的管理了。戰爭靠什么取勝呢?如果你是這場戰爭其中一方的統帥,你會如何指揮這樣戰爭呢?你可能會說:你不是在扯淡嗎?說挨踢項目管理,怎么跑到戰爭去了?讓我們先看看戰爭的戰略管理,然后再回到項目的戰略管理吧。

            白起的故事

            白起你不會沒有聽說過吧?就是那個殺死幾十萬趙國俘虜的殺人狂魔。但我說的不是他殺俘虜的事情,而是白起被稱為戰神,一生沒有打過敗仗,他是如何做到的?因為他只選擇打戰略上能打贏的仗!

            當時只有趙國有實力和秦國一戰,雙方幾十萬大軍對峙在長平一帶。秦軍統帥是白起,趙軍統帥是廉頗。白起對于此戰的戰略上的判斷是這樣的:兩國實力、軍力相當,如果全力出戰,秦國能勝,但只能是慘勝,這樣的后果只能是削弱了自己,反而讓其他戰國有機可乘。秦國的優勢在于全國上下一心,特別是秦王和大臣們眾志成城。而趙國雖然軍力不錯,但趙國內部權力斗爭厲害,各派只為自己利益不顧國家利益。因此白起定下的戰爭策略是:對外稱病不能擔當統帥,隱藏自己做統帥的事實,以拖待變,尋找有利戰機再出擊。另一方面,秦國使出反間計,成功讓趙國更換主帥,換了那個很出名的只會“紙上談兵”的趙括。

            趙括上任后,全軍出擊,結果中了白起埋伏,白起利用地形,用基本相等的數量的士兵困住了幾十萬趙軍,不與之決戰,消耗趙軍的糧草,最后趙軍被迫投降。后面就是白起殺死幾十萬降兵的事情了。白起成功地用比較少的代價,給趙國帶來致命的打擊。

            白起殺死幾十萬降兵后,立馬建議秦王馬上揮軍滅掉趙國。秦王認為此時出擊必會促使六國合縱,這樣秦國會招架不?。坏灼鹫J為,剛殺掉幾十萬降兵,其他五國還在震驚之中,沒有這么快緩過氣來,一時無法合縱,此時正是滅掉趙國的好時機!但秦王堅持自己的想法,白起只有退兵。后來秦王后悔了,想讓白起率軍滅掉趙國。這時白起認為:其他五國已經緩過氣來了,此時攻擊趙國,六國必會合縱。但秦王一意孤行,白起托病不統軍,秦王另找人統帥,結果六國果然合縱,出現了“信陵君盜取帥印”促使魏國出兵的著名歷史事件,秦軍大敗。秦王再次要求白起統帥,認為只要白起統帥必能獲勝,但白起仍然推辭,最后秦王惱羞成怒,殺了白起。

            白起在戰略上的判斷是相當準確的,可惜他的老板和他想法不一樣,白起拒絕執行戰略上注定失敗的決策,雖然避免了自己打敗仗,但得罪了老板,下場凄慘啊!咱們這些做項目的,如果遇到一個戰略上有問題的項目,你是做還是不做呢?

            龐涓的故事

            說起龐涓,大家可能馬上想到的是他如何害孫臏,然后孫臏又如何設計殺之報復。其實龐涓是一個戰略上判斷正確的人,只是被迫執行了戰略上有問題的決策。

            龐涓是魏國的大將,他對魏王建議的國策是:先西進滅掉秦國,解除后顧之憂后再圖其他。秦國當時并不強大,多年與魏國爭奪河西河東,“三十年河西三十年河東”的故事就是這樣來的。但魏王認為:秦國很窮,但秦人很彪悍,滅掉秦國代價太大,沒啥好處。魏王最想做的事情是滅掉趙國和韓國,所謂的“三晉合一”,魏、趙、韓原本同屬晉國,后來他們將之瓜分掉。龐涓認為:滅掉趙國、韓國是不可行的,因為附近的戰國,特別是齊國不會讓魏國成功的,其他戰國必會出兵。但魏王執意要先滅趙國,然后是韓國,讓龐涓統帥。龐涓只能堅決執行老板的決策,率軍猛攻趙國,就快攻克邯鄲之時,齊國突然出兵突襲魏國的大梁,這就是“圍魏救趙”的故事。龐涓只能回師救大梁,途中遇到伏擊,損失慘重,但還不至于戰死。

            魏王仍然不甘心,再次要龐涓統帥滅韓國,故事再次上演,這次是“圍魏救韓”。龐涓再次回師,孫臏上演了“逐日減灶”的典故,讓龐涓判斷失誤,率大軍進入死地,被齊軍伏擊致死。

            龐涓同樣在戰略上的判斷是基本正確的,但他的老板想法不是這樣,龐涓作為老板的手下,他選擇了堅決執行老板的決策,但仍然得不到好下場!

            遇到一個戰略上有問題的項目,你不做會死,做也會死,怎么辦呢?、


            認識軟件項目的戰略管理和戰術管理

            上面兩個故事,希望我能大概說清楚什么是戰略。項目的戰略大概就是指:能決定項目成敗的宏觀因素,如:甲乙雙方在這個項目上的商業利益、雙方領導的特點、項目的預算、目標、工期等,還有就是你所帶領的團隊是否有能力有條件完成這個項目等。

            戰略上有贏的可能,加上好的戰術,項目才有機會成功。

            戰略上沒贏的可能,無論用什么好的戰術,項目都逃不過失敗。

            戰略上有贏的大好條件,但你的戰術很差,項目也會失敗,你浪費了一個大好的項目!

            希望我們能盡量選擇戰略上有機會贏的項目,萬一運氣不好,挑上了一個戰略上沒機會贏的項目,那么就要想辦法不要死得那么慘。

            下面的法則供你參考。

            法則1:從戰略高度出發

            客戶為什么要做這個項目?我們公司為什么承接這個項目?

            合同的金額是多少?我們公司對這個項目的預算是多少?項目工期有多長?

            你的項目團隊有什么人?每個人的水平和潛力怎樣?

            有沒有其他影響項目成功的重大風險?

            以上問題應該盡早搞清楚,通常來說可以在公司的高層領導那里得到很多重要信息,但如果你無法接觸高層,或者高層不鳥你,你用盡所有辦法都難以獲取以上的重要信息,那么你基本上可以判斷:這個項目死定!

            最怕遇到一些讓你自己解決所有問題的領導,這些只能是無水平、不負責任的領導!除了合同金額一些涉及公司機密的內容可能不方便透露外,其他信息是必須讓項目經理知道的,而且有些事情是需要高層出馬幫助項目組去搞定的。

            遇到高層不鳥你的情況,法則1-4都沒啥作用,你可以直接看法則5。

            法則2:盡量提高你在客戶面前的地位

            通常情況下,我們需要門當戶對地和客戶接觸,高層VS高層,基層VS基層。如果你是一位小小程序員,想和客戶高層說話,這是大忌!

            很不幸的是,項目經理能經常接觸的客戶中的最高領導,只能是對方的業務骨干,最多是部門經理,而項目經理以下的項目成員,身份更加是低微了。

            為了讓項目組將來的工作更加主動,要做好項目組成員的“包裝”,例如讓項目經理掛上副總、總監之類的頭銜,盡量讓項目成員的身份放大和提高。第一次和客戶接觸時,就要包裝好你的高大形象。例如項目啟動會上,以比較高的形象來展示項目組各成員。


          法則3:讓客戶的高層重視項目

            越是高層的客戶,越抓得住項目的目標,越是基層的客戶,越容易陷入細節,甚至提出很多匪夷所思的要求。如果客戶的高層能向下屬明確本項目的目標和范圍,那么客戶的中層基層就比較容易搞定了。

            法則2做得好,就很有機會讓項目經理可以直接接觸到客戶的高層,項目經理在掌握了項目的戰略的情況下,了解了客戶大致想法的情況下,就比較容易驅動客戶高層做事情了。如果項目經理不好接觸客戶的高層,那么就要動用法則4,讓你的高層去找客戶的高層。

            法則4:驅動你的高層做事情

            項目中很多重大問題,方向性的問題,其實是需要我們的高層去做的。例如讓我們的高層與客戶高層明確項目的目標與范圍,推動客戶配合需求調研工作,推動上線試運行,推動驗收等。項目中出現重大問題,會影響項目成功時,都應該第一時間將問題反饋給我們的高層,讓高層去處理或給出建議。

            我不覺得你能解決所有問題才叫厲害,在項目組的層面確實有些問題是無法解決的,這些問題如果不及時讓高層知道并讓高層支援你,問題將會變得更加嚴重。

            如果你的高層是那種什么事情都讓你自己搞定的話,那么本法則不適用,看“法則5:輸少當贏!”

            法則5:輸少當贏!

            如果是項目戰略上判斷覺得無贏的可能,但你的高層領導認為可以贏,執意要求你執行他的決策,那么本法則可能會讓你不會死得那么慘。

            做一個戰略上不可能贏的項目是很痛苦的,最佳選擇是不做這個項目,但通常你沒得選,你只能硬頭皮上。你應該慶幸,不是讓你做戰爭的統帥,你不會象白起或者龐涓那樣會死得很慘,你最多是辭職不干!

            萬一贏頭皮要做這樣的項目,只能是“輸少當贏”了。向你的高層隨時報告進展,遇到什么問題全部拋給他,美名其曰:向您請教應該如何處理!遇到與領導有某些分歧,你可以適當地爭論一下,然后假裝被你的領導說服,你還要裝作很受教的樣子。你只能在很有限的空間內,盡量降低這個項目的損失,盡量降低你將來需要承受后果的嚴重程度。將一些問題及時拋給高層,或許會有機會幫助高層重新思考自己的想法,逐步修正他對這個項目的戰略判斷,這樣的話會慢慢變得對你有利。

            采用法則5時,是不得已的選擇。如果想不做這個項目,恐怕只能選擇辭職;為生活,只能暫時忍一忍,接手這個燙手山芋吧。

            關鍵是心態要好,盡自己力就OK了,對得起自己,也對得起這個項目。挨領導的批可能是不可避免的了,當他唱歌吧!

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

          性能測試計劃VS測試實踐

           許多人說,面向過程的工作是成功的關鍵。雖然我非常贊成這個說法,但我總是納悶為什么人們對于性能測試的7個要點并沒有特別關注,而這7個要點能左右性能測試項目的成敗。

            當一個測試人員被分配到性能測試項目組,項目經理會讓他/她做的第一件事就是著手準備測試計劃。但在測試計劃的準備階段,測試經理及其屬下在準備文檔時通常會掉以輕心,文檔的大部分內容要么是從以前的項目中復制過來的,要么是從網上找來的任意模板;對測試計劃中提到的需求說明不予任何關注就直接轉移到下一階段了。不可否認的是:作為公司流程標準中的必須項,測試計劃通常只流于形式;因此它從來沒有真正用于連接項目的執行。

            我想說的是,用來準備測試計劃的時間是整個項目實施期間非常有價值的部分。但不幸的是,所有這些多半都只是在理論上說說,很少用于實踐。因此測試人員通常不會把測試活動和測試計劃緊密的結合到一起,因為每個測試計劃的實施都會受與此過程相關的費用影響,而且他們認為測試計劃會延緩測試活動。

            這無疑是一件壞事,但即使你否定了這個項目計劃階段—若測試工程師在項目執行階段認真遵循性能測試的7個要點,我覺得我們還是能在最后看到希望。

            7個要點:

            1、知道SLA指的是什么。


          SLA 服務等級協議

          定義

            SLA:Service-Level Agreement的縮寫,意思是服務等級協議。
            服務等級協議是關于網絡服務供應商和客戶間的一份合同,其中定義了服務類型、服務質量和客戶付款等術語。
            SLA: SoftWare License Agreement的縮寫,意思也可為軟件許可協議,像著名的GPL,BSD等均為典型代表.
            SLA: Second Language Acquisition的縮寫,意思是第二語言習得。

          項目

            典型的SLA 包括以下項目:
            分配給客戶的最小帶寬;
            客戶帶寬極限;
            能同時服務的客戶數目;
            在可能影響用戶行為的網絡變化之前的通知安排;
            撥入訪問可用性;
            運用統計學;
            服務供應商支持的最小網絡利用性能,如99.9%有效工作時間或每天最多為1分鐘的停機時間。
            各類客戶的流量優先權;
            客戶技術支持和服務;
            懲罰規定,為服務供應商不能滿足 SLA 需求所指定。

          要求

            按照 SLA 要求,服務供應商采用多種技術和解決方案去監控和管理網絡性能及流量,以滿足 SLP 中的相關需求,并產生對應的客戶結果報告。
            另一方面,客戶本身也提出了自己的技術及解決方案去監控鄰居的流量和服務,以確保提供他們答應的傳送服務項目。
            SLA概念已被大量企業所采納,作為公司 IT 部門的內部服務。大型企業的 IT 部門都規范了一套服務等級協議,以衡量、確認他們的客戶(企業其他部門的用戶)服務,有時也與外部網絡供應商提供的服務進行比較。

          編輯本段服務水平協議

          定義

            SLA 服務水平協議(簡稱:SLA,全稱:service level agreement)是在一定開銷下為保障服務的性能和可靠性,服務提供商與用戶間定義的一種雙方認可的協定。通常這個開銷是驅動提供服務質量的主要因素。

          內容

            一個完整的SLA同時也是一個合法的文檔,包括所涉及的當事人、協定條款(包含應用程序和支持的服務)、違約的處罰、費用和仲裁機構、政策、修改條款、報告形式和雙方的義務等。同樣服務提供商可以對用戶在工作負荷和資源使用方面進行規定。

          保障

            傳統上,SLA包含了對服務有效性的保障,譬如對故障解決時間、服務超時等的保證。但是隨著更多的商業應用在Internet的廣泛開展,越來越需要SLA對性能(如響應時間)作出保障。這種需要將會隨著越來越多的商業在Internet 的開展而重要起來。實際上,SLA的保障是以一系列的服務水平目標(SLO)的形式定義的。服務水平目標是一個或多個有限定的服務組件的測量的組合。一個SLO被實現是指那些有限定的組件的測量值在限定范圍里。SLO有所謂的操作時段,在這個時間范圍內,SLO必須被實現。但是由于Internet的統計特性,不可能任何時候都能實現這些保障。因此SLA一般都有實現時間段和實現比例。實現比例被定義為SLA必須實現的時間與實現時段的比值。例如:在工作負荷<100 transaction/s前提下,早上8點到下午5點服務響應時間<85ms,服務有效率>95%,在一個月內的總體實現比例 <97%。

            2、了解真實用戶的使用模式。

            3、知道如何加載服務器。

            4、知道負荷服務器的最大負荷量。

            5、明白自動化測試需要包含哪些類型。

            6、了解你的測試工具以最大化其功能。

            7、了解你的測試環境。

            你只要在腦海中牢牢記住這些要點是專業范疇內的一部分。你既不需要把這些歸檔,也不用把它們交付客戶,你只需要實踐。因為最后,客戶既不會想知道你的負載測試計劃有多好或多壞,也不會因你遵循的標準不同而生氣,相反,客戶在意的是你提交的結果的準確度和這些統計資料對改善應用程序的性能有多大幫助。相信我,深入了解這些要點的每個方面并認真執行,對得到負載測試的真實結果肯定會有所幫助。

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

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

          導航

          統計

          常用鏈接

          留言簿(55)

          隨筆分類

          隨筆檔案

          文章分類

          文章檔案

          搜索

          最新評論

          閱讀排行榜

          評論排行榜

          主站蜘蛛池模板: 光山县| 奉贤区| 满洲里市| 光山县| 韶山市| 辽宁省| 谷城县| 新津县| 成武县| 哈密市| 金华市| 西林县| 荔浦县| 中方县| 剑川县| 姚安县| 平塘县| 乐业县| 广丰县| 河北区| 万盛区| 东宁县| 探索| 乐业县| 定远县| 靖边县| 鱼台县| 垣曲县| 沐川县| 锡林浩特市| 大名县| 唐河县| 柯坪县| 萝北县| 荆州市| 禹城市| 筠连县| 灵台县| 喀喇沁旗| 南平市| 永城市|