軟件開發(fā)心得總結(jié)
有感于網(wǎng)盤開發(fā)過程
有感于網(wǎng)盤開發(fā)過程..............................................................................................................................1一、軟件開發(fā)個人體會:.................................................................................................................2二、做軟件開發(fā)我覺得要明白:.....................................................................................................2三、在開發(fā)中遇到問題應(yīng)該怎么去解決?......................................................................................2四、怎么樣才能提高自身的能力?..................................................................................................2五、怎么樣才能做好軟件開發(fā)?.....................................................................................................2六、文檔的重要性.............................................................................................................................3七、我的收獲.....................................................................................................................................3八、網(wǎng)盤項目開發(fā)的最大體會.........................................................................................................4九、軟件測試(單體測試和連接測試)..........................................................................................4
常熟理工學(xué)院SIG小組3/28/20
一、軟件開發(fā)個人體會:
1.軟件領(lǐng)域中的知識在于積累。
2.做軟件開發(fā),就類似算數(shù)學(xué)題和世界杯足球賽一樣:重在結(jié)果,而不在乎過程。3.軟件服務(wù)于人類,軟件是在解決一些生活中的問題和錯誤,問題決定解決方案。
二、做軟件開發(fā)我覺得要明白:
1.職業(yè)的樂趣:
(A)用自己的智慧去創(chuàng)建新事物的快樂(B)開發(fā)對別人有用的東西(C)不斷學(xué)習(xí)來充實自己2.職業(yè)的苦惱:(A)總是追求完美
(B)所有要實現(xiàn)的功能由他人而定
(C)概念設(shè)計計是有趣的,但找Bug總是很苦惱的
三、在開發(fā)中遇到問題應(yīng)該怎么去解決?
1.2.3.4.
不明白就多問,不要自已一直去琢磨。
一個問題如果30分鐘還沒有解決就應(yīng)該考慮是不是問問別人。一個問題在沒有用過3種以上的方法解決過就不要去問別人。解決問題思路是關(guān)鍵:
相信問題總歸有解決的辦法,就算連技術(shù)上都沒法實現(xiàn)的問題,相信通過良好的溝通終究也會有解決的方法。
5.解決問題的前提是:理解別人的意思,理解別人的需求,多溝通,及時給客戶反饋信息。
四、怎么樣才能提高自身的能力?
1.程序員怎么樣進步最快?-理論結(jié)合實踐
2.不要怕出錯,不怕遇到錯誤,有錯誤就有挑戰(zhàn),這樣才可以進步,但不要讓同一個石頭
把你絆倒2次。
五、怎么樣才能做好軟件開發(fā)?
1.首先要明白解決的問題是什么,理解問題,其次再決定怎么解決這個問題2.碰到很復(fù)雜的問題,我們就簡單想,把問題簡單化,細化到能夠?qū)崿F(xiàn)為止
常熟理工學(xué)院SIG小組3/28/20
3.出了問題,我們要先分析問題,然后知道引起問題的原因,最后并想出問題的解決辦法4.我們應(yīng)該從2個方面去把握一個項目:從業(yè)務(wù)角度和項目的關(guān)鍵問題上去把握一個項目
(A)從不同的系統(tǒng)場景
(B)從不同的用戶角色(充當(dāng)什么角色)(C)從不同的系統(tǒng)使用角度(擁有那些權(quán)限)
5.其實我覺得開發(fā)人員說實在應(yīng)該要比使用系統(tǒng)的人更了解系統(tǒng)需求,只有真正徹底的了
解了項目的業(yè)務(wù)需求,我們才能做真的做好這個項目
六、文檔的重要性
記得我當(dāng)初剛開發(fā)項目的時候都是寫個大致的需求說明書,做一個E-R圖,畫幾個大致的數(shù)據(jù)流程圖,然后建立數(shù)據(jù)字典和表結(jié)構(gòu)關(guān)系。再接著搭建一個開發(fā)環(huán)境,配置幾臺服務(wù)器,劃分一下模塊,分工,我們就可以Coding了,一直到項目結(jié)束了,也沒有完整的設(shè)計文檔,更沒有完整的測試文檔,雖然這樣的確是很快的完成了Coding工作,感覺上好像節(jié)省了好多成本和開發(fā)時間,但后期的維護和Bug就是經(jīng)常出現(xiàn)的事。
小項目沒有文檔關(guān)系不大,但如果遇到一個大項目的時候,那這樣的開發(fā)方式就很有問題很危險的。
大項目沒有文檔:首先維護就很麻煩,也很亂,寫的代碼,過幾天都不知道它是完成什么功能的了,其次系統(tǒng)的穩(wěn)定性和可靠性也讓人懷疑,擴展性就不用說了。
七、我的收獲
A.程序員大多都不喜歡寫文檔,我們以前也是特討厭,記得以前都是系統(tǒng)開發(fā)完了,為了應(yīng)付項目驗收,就匆匆忙忙的一組人在那里補文檔。在我們的思想里,所謂的文檔就是一些廢話,一句話硬是用十句話來代替的無聊透頂。B.代碼風(fēng)格要規(guī)范
以前做項目,我們都是不怎么去注意代碼風(fēng)格和寫代碼的規(guī)范,都是稍微想一下就直接開始寫代碼了。注釋也很少用,總感覺我們自己寫的代碼,我們怎么會不知道它做了些什么事呢?總覺得我們自己寫的代碼我們怎么會不知道它是用來做什么的呢。一直都不相信這是個事實,但事實上,項目驗收后,系統(tǒng)剛開始使用的人少,也就不會出現(xiàn)潛在的錯誤,隨著時間的增加,久而久之,當(dāng)大量用戶并發(fā)訪問的時候,系統(tǒng)的Bug就暴漏出來了,那時你再用熟悉的Eclipse打開整個項目的源碼時,再去看自己寫的代碼的時候,真的發(fā)現(xiàn),我們定義的這個變量名是什么意思?我們的這個Flag是用來判斷什么的啊?我們的if()中條件不知道是判斷什么?Function()也忘記是什么功能了?想想好可怕啊。難道真的都忘記了嗎?回答是肯定的:真的忘了。C.心得體會:
通過做該網(wǎng)盤項目,在這2年的鍛煉中,我們才真的體會到,良好的文檔是正規(guī)研發(fā)流程中非常重要的環(huán)節(jié),一個好的程序是先寫好設(shè)計文檔再進行編程的,在設(shè)計文檔的指導(dǎo)下,才能寫出安全的代碼。如果你不寫文檔,一開始就寫程序,這樣你就不會按已設(shè)計好的路線走,而是想到哪寫到哪。小功能還好說,要是大功能,就容易混亂.
常熟理工學(xué)院SIG小組3/28/20
剛開始我們還很不習(xí)慣這一系列的編程風(fēng)格,很多的規(guī)范,尤其是命名,方法和注釋,都有這著很多限制,讓我們覺得真羅唆,寫個程序完成功能不就可以了嗎,明明1小時做完的事情非得讓人用3、4個小時去做,我們現(xiàn)在真的明白這樣做的好處了,我們已經(jīng)習(xí)慣這樣的編程風(fēng)格了,這也養(yǎng)成了我們的一個編程習(xí)慣了,深有體會啊。
最忙的時候就是我們成長和收獲最多的時候。
八、網(wǎng)盤項目開發(fā)的最大體會
我們覺得項目開發(fā)的開始時候,應(yīng)該由項目負責(zé)人很好的對項目是什么項目,具體大概做什么事情,是誰提出來的,目的是解決什么問題,以及里面用到的很多專有名詞做個細致的說明,而不是從一開始就分幾本式樣書,給個靜態(tài)Html的Demo看看,然后搭建好開發(fā)環(huán)境就按照式樣設(shè)計書來開發(fā)。
九、軟件測試(單體測試和連接測試)
我們首先認為,編寫程序的時候不要想出了問題再解決,而是要想如何不會出現(xiàn)問題,要根據(jù)經(jīng)驗來預(yù)測可能出現(xiàn)的問題,然后避免出現(xiàn)。測試,說的直接點就是給軟件找錯誤。
很多人認為發(fā)現(xiàn)錯誤是軟件測試的唯一目的,查找不出錯誤的測試就是沒有價值的測試,實際上我們不這么認為。
我們覺得對開發(fā)人員來說,我們要把測試出來的Bug都應(yīng)該做個分析,知道錯的原因之后,我們就應(yīng)該在下個項目中防止類似的錯誤發(fā)生,而真正來提高我們開發(fā)的效率。
常熟理工學(xué)院SIG小組3/28/20
擴展閱讀:軟件開發(fā)心得(設(shè)計篇)
論文題目:軟件測試
摘要..................................................................................................................................................2第一章介紹.....................................................................................................................................3
1.1軟件測試簡介....................................................................................................................3
1.1.1軟件測試的概念.....................................................................................................31.1.2軟件測試的原則.....................................................................................................31.2軟件測試的心理學(xué)............................................................................................................51.3軟件測試的內(nèi)容................................................................................................................71.4軟件測試的分類................................................................................................................81.5軟件測試模型..................................................................................................................131.6軟件測試職業(yè)發(fā)展前景..................................................................................................171.7軟件測試的誤區(qū)..............................................................................................................181.8軟件測試的前景..............................................................................................................20第二章軟件測試工作的經(jīng)驗和心得...........................................................................................21
2.1軟件測試用例的規(guī)范......................................................................................................212.2自動化測試......................................................................................................................252.3測試中的問題..................................................................................................................28
2.3.1測試運用的是認識論...........................................................................................282.3.2測試無法發(fā)現(xiàn)所有的程序問題...........................................................................28
參考資料.........................................................................................................................................29論文信息.........................................................................................................................................摘要
隨著軟件產(chǎn)業(yè)的發(fā)展,軟件產(chǎn)品的質(zhì)量控制與質(zhì)量管理正逐漸成為軟件企業(yè)生存與發(fā)展的核心。幾乎每個大中型IT企業(yè)的軟件產(chǎn)品在發(fā)布前都需要大量的質(zhì)量控制、測試和文檔工作,而這些工作必須依靠擁有嫻熟技術(shù)的專業(yè)軟件人才來完成。軟件測試工程師就是這樣的一個企業(yè)重頭角色。目前的現(xiàn)狀是:一方面企業(yè)對高質(zhì)量的測試工程師需求量越來越大越大,另一方面國內(nèi)原來對測試工程師的職業(yè)重視程度不夠,使許多人不了解測試工程師具體是從事什么工作。故寫此論文,對軟件測試的概念、理念、方法、技術(shù)等進行一下表述,并總結(jié)一個多月中軟件測試工作的心得和經(jīng)驗。
論文主要分兩個部分講述了軟件測試:
第一章,從理論上介紹軟件測試的定義、理念等。
第二章,從一個多月的軟件測試工作中獲得的經(jīng)驗和心得。第一章介紹
1.1軟件測試簡介
軟件測試就是利用測試工具按照測試方案和流程對產(chǎn)品進行功能和性能測試,甚至根據(jù)需要編寫不同的測試工具,設(shè)計和維護測試系統(tǒng),對測試方案可能出現(xiàn)的問題進行分析和評估。執(zhí)行測試用例后,需要跟蹤故障,以確保開發(fā)的產(chǎn)品適合需求。
1.1.1軟件測試的概念
使用人工或者自動手段來運行或測試某個系統(tǒng)的過程,其目的在于檢驗它是否滿足規(guī)定的需求或弄清預(yù)期結(jié)果與實際結(jié)果之間的差別.
它是幫助識別開發(fā)完成(中間或最終的版本)的計算機軟件(整體或部分)的正確度(correctness)、完全度(completeness)和質(zhì)量(quality)的軟件過程;是SQA(softwarequalityassurance)的重要子域。
軟件測試工程師GrenfordJ.Myers曾對軟件測試的目的提出過以下觀點:(1)測試是為了發(fā)現(xiàn)程序中的錯誤而執(zhí)行程序的過程;
(2)好的測試方案是極可能發(fā)現(xiàn)迄今為止尚未發(fā)現(xiàn)的錯誤的測試方案;(3)成功的測試是發(fā)現(xiàn)了至今為止尚未發(fā)現(xiàn)的錯誤的測試。
然而,這種觀點指出測試是以查找錯誤為中心,而不是為了演示軟件的正確功能.但是只從字面意思理解,可能會產(chǎn)生誤導(dǎo),認為發(fā)現(xiàn)錯誤是軟件測試的唯一目的,查找不出錯誤的測試就是沒有價值的測試,實際上并非如此!
(1)測試并不僅僅是為了找出錯誤.通過分析錯誤產(chǎn)生的原因和錯誤的發(fā)生趨勢,可以幫助項目管理者發(fā)現(xiàn)當(dāng)前軟件開發(fā)過程中的缺陷,以便及時改進;
(2)這種分析也能幫助測試人員設(shè)計出有針對性的測試方法,改善測試的效率和有效性;(3)沒有發(fā)現(xiàn)錯誤的測試也是有價值的,完整的測試是評定軟件質(zhì)量的一種方法
1.1.2軟件測試的原則
軟件測試的幾大原則:
1.軟件開發(fā)人員即程序員應(yīng)當(dāng)避免測試自己的程序
不管是程序員還是開發(fā)小組都應(yīng)當(dāng)避免測試自己的程序或者本組開發(fā)的功能模塊。若條件允許,應(yīng)當(dāng)由獨立于開發(fā)組和客戶的第三方測試組或測試機構(gòu)來進行軟件測試。但這并不是說程序員不能測試自己的程序,而且更加鼓勵程序員進行調(diào)試,因為測試由別人來進行可能會會更加有效、客觀,并且容易成功,而允許程序員自己調(diào)試也會更加有效和針對性。
2.應(yīng)盡早地和不斷地進行軟件測試
應(yīng)當(dāng)把軟件測試貫穿到整個軟件開發(fā)的過程中,而不應(yīng)該把軟件測試看作是其過程中的一個獨立階段。因為在軟件開發(fā)的每一環(huán)節(jié)都有可能產(chǎn)生意想不到的問題,其影響因素有很多,比如軟件本身的抽象性和復(fù)雜性、軟件所涉及問題的復(fù)雜性、軟件開發(fā)各個階段工作的多樣性,以及各層次工作人員的配合關(guān)系等。所以要堅持軟件開發(fā)各階段的技術(shù)評審,把錯誤克服在早期,從而減少成本,提高軟件質(zhì)量。
3.對測試用例要有正確的態(tài)度:第一,測試用例應(yīng)當(dāng)由測試輸入數(shù)據(jù)和預(yù)期輸出結(jié)果這兩部分組成;第二,在設(shè)計測試用例時,不僅要考慮合理的輸入條件,更要注意不合理的輸入條件。因為軟件投入實際運行中,往往不遵守正常的使用方法,卻進行了一些甚至大量的意外輸入導(dǎo)致軟件一時半時不能做出適當(dāng)?shù)姆磻?yīng),就很容易產(chǎn)生一系列的問題,輕則輸出錯誤的結(jié)果,重則癱瘓失效!因此常用一些不合理的輸入條件來發(fā)現(xiàn)更多的鮮為人知的軟件缺陷。
4.人以群分,物以類聚,軟件測試也不例外,一定要充分注意軟件測試中的群集現(xiàn)象。不要以為發(fā)現(xiàn)幾個錯誤并且解決這些問題之后,就不需要測試了。反而這里是錯誤群集的地方,對這段程序要重點測試,以提高測試投資的效益。
5.嚴格執(zhí)行測試計劃,排除測試的隨意性,以避免發(fā)生疏漏或者重復(fù)無效的工作。6.應(yīng)當(dāng)對每一個測試結(jié)果進行全面檢查。一定要全面地、仔細地檢查測試結(jié)果,但常常被人們忽略,導(dǎo)致許多錯誤被遺漏。
7.妥善保存測試用例、測試計劃、測試報告和最終分析報告,以備回歸測試及維護之用。
在遵守以上原則的基礎(chǔ)上進行軟件測試,可以以最少的時間和人力找出軟件中的各種缺陷,從而達到保證軟件質(zhì)量的目的。
1.2軟件測試的心理學(xué)
人類行為具有高度目標(biāo)性,確立一個正確的目標(biāo)有著重要的心理學(xué)影響。軟件測試的心理學(xué)問題就是如何擺正測試的兩個目標(biāo)的關(guān)系,使得測試活動更加富有成效。
1.程序測試的過程具有破壞性
每當(dāng)測試一個程序時,人們總希望為程序增加一些價值。利用測試來增加程序的價值,是指通過測試,找出并修改盡可能多的程序缺陷,從而提高程序的可靠性或質(zhì)量。
因此,不要只是為了證明程序能夠正確運行而去測試程序。相反,應(yīng)該一開始就假設(shè)程序中隱藏著錯誤(這種假設(shè)幾乎對所有的程序都成立),然后測試程序,發(fā)現(xiàn)盡可能多的錯誤。
事實上,如果把測試目標(biāo)定位于要證明程序中沒有缺陷,那么就會在潛意識中傾向于實現(xiàn)這個目標(biāo)。也就是說,測試人員會傾向于挑選那些使程序失效的可能性較小的測試數(shù)據(jù)。另一方面,如果把測試目標(biāo)定位于要證明程序中存在缺陷,那么就會選擇一些容易發(fā)現(xiàn)程序缺陷的測試數(shù)據(jù)。而后一種態(tài)度會比前者給程序增加更多的價值。
因此,大多數(shù)測試專業(yè)人員都贊同Myers對測試的定義:—測試是為發(fā)現(xiàn)錯誤而執(zhí)行程序的錯誤!@個定義意味著程序測試的過程是具有破壞性的,甚至是一個—施虐‖過程。開發(fā)人員可能不愿意這么做,因為人們總是傾向于建設(shè)而不是破壞。這個定義還暗示了對于一個特定的程序,應(yīng)該如何設(shè)計測試用例(測試數(shù)據(jù))、哪些人應(yīng)該而哪些人又不應(yīng)該執(zhí)行測試。
事實上,如果在測試某個程序段時發(fā)現(xiàn)了可以糾正的缺陷,或者測試最終確定在沒有其他缺陷,則應(yīng)將這次合理設(shè)計并得到有效執(zhí)行的測試稱作是—成功的‖。而所謂—不成功的‖測試,僅指未能適當(dāng)?shù)貙Τ绦蜻M行檢查,未能找出程序中潛藏缺陷的測試。因為軟件中不可能沒有缺陷,沒有找出它們,當(dāng)然測試是—不成功的‖。
—軟件測試就是證明軟件不存在錯誤的過程‖。對幾乎所有的程序而言,甚至是非常小的程序,這個目標(biāo)實際上是無法達到的。因為即使程序完全實現(xiàn)預(yù)期要求,仍可能包含有缺陷。也就是說,如果程序不按要求工作,它顯然有缺陷,但如果程序做了不要它做的事,它也有缺陷。
心理學(xué)研究告訴我們,當(dāng)人們在干一件已經(jīng)知道是不合適的或不可能做到的事時,往往他們的表現(xiàn)就相當(dāng)糟糕。把程序測試定義為在程序中找出錯誤的過程,就使測試成了可以做到的任務(wù),從而克服了心理上存在的問題。雖然這看起來像是個微妙的文字游戲,但對成功地進行軟件測試有很大的影響。
總之,軟件測試更適宜被視為試圖發(fā)現(xiàn)程序中錯誤(假設(shè)其存在)的破壞性的過程。一個成功的測試,通過誘發(fā)程序發(fā)生錯誤,可以在這個方向上促進軟件質(zhì)量的改進。當(dāng)然最終人們還是要通過軟件測試來建立某種程度的信心:軟件做了其應(yīng)該做的,而沒有做其不應(yīng)該做的。
2.程序員應(yīng)避免測試自己的程序
由開發(fā)人員來測試自己的代碼是一件很不妥當(dāng)?shù)氖虑椤i_發(fā)和測試生來就是不同的活動。開發(fā)是創(chuàng)造或者建立某種事物的行為,如一個功能模塊或整個系統(tǒng)。而測試的重要目的是證實一個模塊或者一個系統(tǒng)工作不正常。這兩個活動之間有著本質(zhì)的矛盾。一個人不太可能把兩個截然對立的角色都扮演地很好,因此應(yīng)當(dāng)限制開發(fā)人員在測試中的參與,給他們比較合適的任務(wù)是進行最底層的測試單元測試。
當(dāng)一個程序員完成了設(shè)計與編寫程序的建設(shè)性工作后,要一夜之間突然改變他的觀點,設(shè)法對程序形成一個完全否定的態(tài)度,那是非常困難的。所以,大部分程序員都由于不能使自己進入必要的精神狀態(tài)(不是抱著要揭露出自己程序中錯誤的態(tài)度),就不能有效的測試自己的程序。除了這個心理學(xué)問題之外,還有一個重要的問題:程序中可能包含由于程序員對問題的敘述或說明的誤解而產(chǎn)生了錯誤。如果是這種情況,當(dāng)程序員測試自己的程序時,往往還會帶著同樣的誤解致使問題難以發(fā)現(xiàn)。
3.程序設(shè)計組織不應(yīng)測試自己的程序在宏觀意義上,一個程序設(shè)計組織或一個工程項目是個有生命的有機體,它同樣有心理學(xué)問題。在大多數(shù)情況下,人們都以—在給定日期內(nèi),以一定代價完成程序編制任務(wù)的能力‖來衡量程序設(shè)計組織和項目管理人員的。這樣做的理由是時間和成本指標(biāo)便于衡量,而程序的質(zhì)量很難度量。要程序設(shè)計組織在測試自己的程序時持客觀態(tài)度是很困難的,因為如果用正確的定義看待測試,就不大可能按預(yù)定計劃完成測試,也不大可能把耗費的代價限制在要求的范圍以內(nèi)。
軟件生產(chǎn)的三個最重要的因素是:質(zhì)量、進度和費用。由于費用和進度的限制,要開發(fā)一種高質(zhì)量、快速交付和低成本的軟件產(chǎn)品并不容易。也就是說要同時達到三個目標(biāo)是困難的。因此在軟件產(chǎn)品的開發(fā)中要權(quán)衡它們之間的關(guān)系,是軟件的特性能滿足用戶的要求,這意味著軟件產(chǎn)品的特性的度量和預(yù)計是必要的。
軟件測試由獨立測試機構(gòu)承擔(dān)有很多好處。獨立測試是指軟件測試工作由在經(jīng)濟上和管理上獨立于開發(fā)機構(gòu)的組織進行。獨立測試可以避免軟件開發(fā)者測試自己開發(fā)的軟件,由于心理學(xué)上的問題,軟件開發(fā)者難以客觀、有效的測試自己的軟件,要找出那些因為對問題的誤解而產(chǎn)生的錯誤就更加困難。獨立測試還可以避免軟件開發(fā)機構(gòu)測試自己的軟件,軟件產(chǎn)品的開發(fā)過程受到時間、成本和質(zhì)量三者的制約,在軟件開發(fā)的過程中,當(dāng)時間、成本和質(zhì)量三者發(fā)生矛盾時,質(zhì)量最容易被忽視,如果測試組織與開發(fā)組織來自相同的機構(gòu),測試過程就會面臨來自于開發(fā)組織同一來源的管理方面的壓力,使測試過程受到干擾。
采用獨立測試方式,無論在技術(shù)上還是管理上,對提高軟件測試的有效性都具有重要意義。
客觀性對軟件測試和軟件中的錯誤抱著客觀的態(tài)度,這種客觀的態(tài)度可以解決測試中的心理學(xué)問題,既能以揭露軟件中錯誤的態(tài)度工作,也能不受發(fā)現(xiàn)的錯誤的影響。經(jīng)濟上的獨立性使測試有更充分的條件按測試要求去完成。
專業(yè)性獨立測試作為一種專業(yè)工作,在長期的工作過程中勢必能夠積累大量實踐經(jīng)驗,形成自己的專業(yè)知識。同時軟件測試也是技術(shù)含量很高的工作,需要有專業(yè)隊伍加以研究,并進行工程實踐。專業(yè)化分工是提高測試水平、保證測試質(zhì)量、充分發(fā)揮測試效應(yīng)的必然途徑。
權(quán)威性由于專業(yè)優(yōu)勢,獨立測試工作形成的測試結(jié)果更具信服力,而測試結(jié)果常常和對軟件的質(zhì)量評價聯(lián)系在一起,專業(yè)化的獨立測試機構(gòu)的評價,更客觀、公正和具有權(quán)威性。
資源有保證獨立測試機構(gòu)的主要任務(wù)是進行獨立測試工作,這使得測試工作在經(jīng)費、人力和計劃方面更有保證,不會因為開發(fā)的壓力減少對測試的投入,降低測試的有效性可以避免開發(fā)單位側(cè)重軟件開發(fā)而對測試工作產(chǎn)生不利的影響。
1.3軟件測試的內(nèi)容
軟件測試主要工作內(nèi)容是驗證(verification)和確認(validation),下面分別給出其概念:
驗證(verification)是保證軟件正確地實現(xiàn)了一些特定功能的一系列活動,即保證軟件做了你所期望的事情。(Dotherightthing)
1.確定軟件生存周期中的一個給定階段的產(chǎn)品是否達到前階段確立的需求的過程;2.程序正確性的形式證明,即采用形式理論證明程序符合設(shè)計規(guī)約規(guī)定的過程;3.評市、審查、測試、檢查、審計等各類活動,或?qū)δ承╉椞幚、服?wù)或文件等是否和規(guī)定的需求相一致進行判斷和提出報告。
確認(validation)是一系列的活動和過程,目的是想證實在一個給定的外部環(huán)境中軟件的邏輯正確性。即保證軟件以正確的方式來做了這個事件(Doitright)
1.靜態(tài)確認,不在計算機上實際執(zhí)行程序,通過人工或程序分析來證明軟件的正確性;
2.動態(tài)確認,通過執(zhí)行程序做分析,測試程序的動態(tài)行為,以證實軟件是否存在問題。
軟件測試的對象不僅僅是程序測試,軟件測試應(yīng)該包括整個軟件開發(fā)期間各個階段所產(chǎn)生的文檔,如需求規(guī)格說明、概要設(shè)計文檔、詳細設(shè)計文檔,當(dāng)然軟件測試的主要對象還是源程序。
1.4軟件測試的分類
從是否關(guān)心軟件內(nèi)部結(jié)構(gòu)和具體實現(xiàn)的角度劃分
A.白盒測試B.黑盒測試C.灰盒測試
從是否執(zhí)行程序的角度
A.靜態(tài)測試B.動態(tài)測試。
從軟件開發(fā)的過程按階段劃分有
A.單元測試B.集成測試C.確認測試D.系統(tǒng)測試E.驗收測試
*測試過程按4個步驟進行,即單元測試、集成測試、確認測試和系統(tǒng)測試及發(fā)版測試。*開始是單元測試,集中對用源代碼實現(xiàn)的每一個程序單元進行測試,檢查各個程序模塊是否正確地實現(xiàn)了規(guī)定的功能。
*集成測試把已測試過的模塊組裝起來,主要對與設(shè)計相關(guān)的軟件體系結(jié)構(gòu)的構(gòu)造進行測試。
*確認測試則是要檢查已實現(xiàn)的軟件是否滿足了需求規(guī)格說明中確定了的各種需求,以及軟件配置是否完全、正確。
*系統(tǒng)測試把已經(jīng)經(jīng)過確認的軟件納入實際運行環(huán)境中,與其它系統(tǒng)成份組合在一起進行測試。
單元測試(UnitTesting)
*單元測試又稱模塊測試,是針對軟件設(shè)計的最小單位─程序模塊,進行正確性檢驗的測試工作。其目的在于發(fā)現(xiàn)各模塊內(nèi)部可能存在的各種差錯。
*單元測試需要從程序的內(nèi)部結(jié)構(gòu)出發(fā)設(shè)計測試用例。多個模塊可以平行地獨立進行單元測試。
1.單元測試的內(nèi)容
*在單元測試時,測試者需要依據(jù)詳細設(shè)計說明書和源程序清單,了解該模塊的I/O條件和模塊的邏輯結(jié)構(gòu),主要采用白盒測試的測試用例,輔之以黑盒測試的測試用例,使之對任何合理的輸入和不合理的輸入,都能鑒別和響應(yīng)。
(1)模塊接口測試
*在單元測試的開始,應(yīng)對通過被測模塊的數(shù)據(jù)流進行測試。測試項目包括:調(diào)用本模塊的輸入?yún)?shù)是否正確;
本模塊調(diào)用子模塊時輸入給子模塊的參數(shù)是否正確;全局量的定義在各模塊中是否一致;*在做內(nèi)外存交換時要考慮:文件屬性是否正確;
OPEN與CLOSE語句是否正確;緩沖區(qū)容量與記錄長度是否匹配;在進行讀寫操作之前是否打開了文件;在結(jié)束文件處理時是否關(guān)閉了文件;正文書寫/輸入錯誤,
I/O錯誤是否檢查并做了處理。(2)局部數(shù)據(jù)結(jié)構(gòu)測試
*不正確或不一致的數(shù)據(jù)類型說明*使用尚未賦值或尚未初始化的變量*錯誤的初始值或錯誤的缺省值*變量名拼寫錯或書寫錯*不一致的數(shù)據(jù)類型*全局數(shù)據(jù)對模塊的影響(3)路徑測試
*選擇適當(dāng)?shù)臏y試用例,對模塊中重要的執(zhí)行路徑進行測試。*應(yīng)當(dāng)設(shè)計測試用例查找由于錯誤的計算、不正確的比較或不正常的控制流而導(dǎo)致的錯誤。
*對基本執(zhí)行路徑和循環(huán)進行測試可以發(fā)現(xiàn)大量的路徑錯誤。(4)錯誤處理測試
*出錯的描述是否難以理解
*出錯的描述是否能夠?qū)﹀e誤定位*顯示的錯誤與實際的錯誤是否相符*對錯誤條件的處理正確與否
*在對錯誤進行處理之前,錯誤條件是否已經(jīng)引起系統(tǒng)的干預(yù)等(5)邊界測試
*注意數(shù)據(jù)流、控制流中剛好等于、大于或小于確定的比較值時出錯的可能性。對這些地方要仔細地選擇測試用例,認真加以測試。
*如果對模塊運行時間有要求的話,還要專門進行關(guān)鍵路徑測試,以確定最壞情況下和平均意義下影響模塊運行時間的因素。
2.單元測試的步驟
*模塊并不是一個獨立的程序,在考慮測試模塊時,同時要考慮它和外界的聯(lián)系,用一些輔助模塊去模擬與被測模塊相聯(lián)系的其它模塊。
驅(qū)動模塊(driver)
樁模塊(stub)──存根模塊*如果一個模塊要完成多種功能,可以將這個模塊看成由幾個小程序組成。必須對其中的每個小程序先進行單元測試要做的工作,對關(guān)鍵模塊還要做性能測試。
*對支持某些標(biāo)準規(guī)程的程序,更要著手進行互聯(lián)測試。有人把這種情況特別稱為模塊測試,以區(qū)別單元測試。
集成測試(IntegratedTesting)*集成測試(集成測試、聯(lián)合測試)
*通常,在單元測試的基礎(chǔ)上,需要將所有模塊按照設(shè)計要求組裝成為系統(tǒng)。這時需要考慮的問題是:
在把各個模塊連接起來的時候,穿越模塊接口的數(shù)據(jù)是否會丟失;一個模塊的功能是否會對另一個模塊的功能產(chǎn)生不利的影響;各個子功能組合起來,能否達到預(yù)期要求的父功能;全局數(shù)據(jù)結(jié)構(gòu)是否有問題;單個模塊的誤差累積起來,是否會放大,從而達到不能接受的程度。在單元測試的同時可進行集成測試,發(fā)現(xiàn)并排除在模塊連接中可能出現(xiàn)的問題,最終構(gòu)成要求的軟件系統(tǒng)。*子系統(tǒng)的集成測試特別稱為部件測試,它所做的工作是要找出集成后的子系統(tǒng)與系統(tǒng)需求規(guī)格說明之間的不一致。
*通常,把模塊集成成為系統(tǒng)的方式有兩種一次性集成方式增殖式集成方式
1.一次性集成方式(bigbang)
*它是一種非增殖式組裝方式。也叫做整體拼裝。*使用這種方式,首先對每個模塊分別進行模塊測試,然后再把所有模塊組裝在一起進行測試,最終得到要求的軟件系統(tǒng)。
2.增殖式集成方式
*這種集成方式又稱漸增式集成
*首先對一個個模塊進行模塊測試,然后將這些模塊逐步組裝成較大的系統(tǒng)*在集成的過程中邊連接邊測試,以發(fā)現(xiàn)連接過程中產(chǎn)生的問題*通過增殖逐步組裝成為要求的軟件系統(tǒng)。(1)自頂向下的增殖方式
*這種集成方式將模塊按系統(tǒng)程序結(jié)構(gòu),沿控制層次自頂向下進行組裝。*自頂向下的增殖方式在測試過程中較早地驗證了主要的控制和判斷點。*選用按深度方向組裝的方式,可以首先實現(xiàn)和驗證一個完整的軟件功能。(2)自底向上的增殖方式
*這種集成的方式是從程序模塊結(jié)構(gòu)的最底層的模塊開始集成和測試。
*因為模塊是自底向上進行組裝,對于一個給定層次的模塊,它的子模塊(包括子模塊的所有下屬模塊)已經(jīng)組裝并測試完成,所以不再需要樁模塊。在模塊的測試過程中需要從子模塊得到的信息可以直接運行子模塊得到。
*自頂向下增殖的方式和自底向上增殖的方式各有優(yōu)缺點。*一般來講,一種方式的優(yōu)點是另一種方式的缺點。(3)混合增殖式測試
*衍變的自頂向下的增殖測試
首先對輸入/輸出模塊和引入新算法模塊進行測試;再自底向上組裝成為功能相當(dāng)完整且相對獨立的子系統(tǒng);然后由主模塊開始自頂向下進行增殖測試。*自底向上-自頂向下的增殖測試
首先對含讀操作的子系統(tǒng)自底向上直至根結(jié)點模塊進行組裝和測試;然后對含寫操作的子系統(tǒng)做自頂向下的組裝與測試。*回歸測試
這種方式采取自頂向下的方式測試被修改的模塊及其子模塊;然后將這一部分視為子系統(tǒng),再自底向上測試。關(guān)鍵模塊問題
*在組裝測試時,應(yīng)當(dāng)確定關(guān)鍵模塊,對這些關(guān)鍵模塊及早進行測試。*關(guān)鍵模塊的特征:①滿足某些軟件需求;②在程序的模塊結(jié)構(gòu)中位于較高的層次(高層控制模塊);③較復(fù)雜、較易發(fā)生錯誤;④有明確定義的性能要求。確認測試(ValidationTesting)*確認測試又稱有效性測試。任務(wù)是驗證軟件的功能和性能及其它特性是否與用戶的要求一致。
*對軟件的功能和性能要求在軟件需求規(guī)格說明書中已經(jīng)明確規(guī)定。它包含的信息就是軟件確認測試的基礎(chǔ)。
1.進行有效性測試(黑盒測試)
*有效性測試是在模擬的環(huán)境(可能就是開發(fā)的環(huán)境)下,運用黑盒測試的方法,驗證被測軟件是否滿足需求規(guī)格說明書列出的需求。
*首先制定測試計劃,規(guī)定要做測試的種類。還需要制定一組測試步驟,描述具體的測試用例。
*通過實施預(yù)定的測試計劃和測試步驟,確定軟件的特性是否與需求相符;所有的文檔都是正確且便于使用;
同時,對其它軟件需求,例如可移植性、兼容性、出錯自動恢復(fù)、可維護性等,也都要進行測試
*在全部軟件測試的測試用例運行完后,所有的測試結(jié)果可以分為兩類:測試結(jié)果與預(yù)期的結(jié)果相符。這說明軟件的這部分功能或性能特征與需求規(guī)格說明書相符合,從而這部分程序被接受。
測試結(jié)果與預(yù)期的結(jié)果不符。這說明軟件的這部分功能或性能特征與需求規(guī)格說明不一致,因此要為它提交一份問題報告。
2.軟件配置復(fù)查
n軟件配置復(fù)查的目的是保證u軟件配置的所有成分都齊全;u各方面的質(zhì)量都符合要求;u具有維護階段所必需的細節(jié);u而且已經(jīng)編排好分類的目錄。
n應(yīng)當(dāng)嚴格遵守用戶手冊和操作手冊中規(guī)定的使用步驟,以便檢查這些文檔資料的完整性和正確性。
驗收測試(AcceptanceTesting)
*在通過了系統(tǒng)的有效性測試及軟件配置審查之后,就應(yīng)開始系統(tǒng)的驗收測試。*驗收測試是以用戶為主的測試。軟件開發(fā)人員和QA(質(zhì)量保證)人員也應(yīng)參加。*由用戶參加設(shè)計測試用例,使用生產(chǎn)中的實際數(shù)據(jù)進行測試。
*在測試過程中,除了考慮軟件的功能和性能外,還應(yīng)對軟件的可移植性、兼容性、可維護性、錯誤的恢復(fù)功能等進行確認。
*確認測試應(yīng)交付的文檔有:確認測試分析報告
最終的用戶手冊和操作手冊項目開發(fā)總結(jié)報告。
系統(tǒng)測試(SystemTesting)
*系統(tǒng)測試,是將通過確認測試的軟件,作為整個基于計算機系統(tǒng)的一個元素,與計算機硬件、外設(shè)、某些支持軟件、數(shù)據(jù)和人員等其它系統(tǒng)元素結(jié)合在一起,在實際運行環(huán)境下,對計算機系統(tǒng)進行一系列的組裝測試和確認測試。
*系統(tǒng)測試的目的在于通過與系統(tǒng)的需求定義作比較,發(fā)現(xiàn)軟件與系統(tǒng)的定義不符合或與之矛盾的地方。
1.5軟件測試模型
軟件測試若使用經(jīng)典的V模型階段可以分為
單元測試集成測試系統(tǒng)測試
V模型是最具有代表意義的測試模型。
V模型是軟件開發(fā)瀑布模型的變種,它反映了測試活動與分析和設(shè)計的關(guān)系。從左到右,描述了基本的開發(fā)過程和測試行為,非常明確地標(biāo)明了測試過程中存在的不同級別,并且清楚地描述了這些測試階段和開發(fā)過程期間各階段的對應(yīng)關(guān)系。
左邊依次下降的是開發(fā)過程各階段,與此相對應(yīng)的是右邊依次上升的部分,即各測試過程的各個階段。
用戶需求驗收測試
需求分析和系統(tǒng)設(shè)計確認測試和系統(tǒng)測試概要設(shè)計集成測試詳細設(shè)計單元測試編碼
V模型問題:
1.測試是開發(fā)之后的一個階段。2.測試的對象就是程序本身。
3.實際應(yīng)用中容易導(dǎo)致需求階段的錯誤一直到最后系統(tǒng)測試階段才被發(fā)現(xiàn)。4.整個軟件產(chǎn)品的過程質(zhì)量保證完全依賴于開發(fā)人員的能力和對工作的責(zé)任心,而且上一步的結(jié)果必須是充分和正確的,如果任何一個環(huán)節(jié)出了問題,則必將嚴重的影響整個工程的質(zhì)量和預(yù)期進度
W模型
W模型由Evolutif公司公司提出,相對于V模型,W模型增加了軟件各開發(fā)階段中應(yīng)同步進行的驗證和確認活動。W模型由兩個V字型模型組成,分別代表測試與開發(fā)過程,圖中明確表示出了測試與開發(fā)的并行關(guān)系。W模型強調(diào):測試伴隨著整個軟件開發(fā)周期,而且測試的對象不僅僅是程序,需求、設(shè)計等同樣要測試,也就是說,測試與開發(fā)是同步進行的。W模型有利于盡早地全面的發(fā)現(xiàn)問題。例如,需求分析完成后,測試人員就應(yīng)該參與到對需求的驗證和確認活動中,以盡早地找出缺陷所在。同時,對需求的測試也有利于及時了解項目難度和測試風(fēng)險,及早制定應(yīng)對措施,這將顯著減少總體測試時間,加快項目進度。但W模型也存在局限性。在W模型中,需求、設(shè)計、編碼等活動被視為串行的,同時,測試和開發(fā)活動也保持著一種線性的前后關(guān)系,上一階段完全結(jié)束,才可正式開始下一個階段工作。這樣就無法支持迭代的開發(fā)模型。對于當(dāng)前軟件開發(fā)復(fù)雜多變的情況,W模型并不能解除測試管理面臨著困惑。
H模型
H模型中,軟件測試過程活動完全獨立,貫穿于整個產(chǎn)品的周期,與其他流程并發(fā)地進行,某個測試點準備就緒時,就可以從測試準備階段進行到測試執(zhí)行階段。軟件測試可以盡早的進行,并且可以根據(jù)被測物的不同而分層次進行。
這個示意圖演示了在整個生產(chǎn)周期中某個層次上的一次測試—微循環(huán)‖。圖中標(biāo)注的其它流程可以是任意的開發(fā)流程,例如設(shè)計流程或者編碼流程。也就是說,只要測試條件成熟了,測試準備活動完成了,測試執(zhí)行活動就可以進行了。
H模型揭示了一個原理:軟件測試是一個獨立的流程,貫穿產(chǎn)品整個生命周期,與其他流程并發(fā)地進行。H模型指出軟件測試要盡早準備,盡早執(zhí)行。不同的測試活動可以是按照某個次序先后進行的,但也可能是反復(fù)的,只要某個測試達到準備就緒點,測試執(zhí)行活動就可以開展。
X模型
X模型也是對V模型的改進,X模型提出針對單獨的程序片段進行相互分離的編碼和測試,此后通過頻繁的交接,通過集成最終合成為可執(zhí)行的程序。X模型的左邊描述的是針對單獨程序片段所進行的相互分離的編碼和測試,此后將進行頻繁的交接,通過集成最終成為可執(zhí)行的程序,然后再對這些可執(zhí)行程序進行測試。己通過集成測試的成品可以進行封裝并提交給用戶,也可以作為更大規(guī)模和范圍內(nèi)集成的一部分。多根并行的曲線表示變更可以在各個部分發(fā)生。由圖中可見,X模型還定位了探索性測試,這是不進行事先計劃的特殊類型的測試,這一方式往往能幫助有經(jīng)驗的測試人員在測試計劃之外發(fā)現(xiàn)更多的軟件錯誤。但這樣可能對測試造成人力、物力和財力的浪費,對測試員的熟練程度要求比較高。
1.6軟件測試職業(yè)發(fā)展前景
隨著我國軟件業(yè)的發(fā)展,專業(yè)的軟件測試人員成為了眾多知名公司追逐的對象,軟件測試有著廣闊的發(fā)展前景,具體可以分為:
初級測試工程師:初級職位,開發(fā)測試腳本,執(zhí)行測試測試工程師/程序分析員:編寫自動測試腳本程序
高級測試工程師/程序分析員:確定測試過程并指導(dǎo)初級測試工程師測試組負責(zé)人:監(jiān)管1-3人工作,負責(zé)規(guī)模/成本估算
測試/編程負責(zé)人:監(jiān)管4-8人,安排和領(lǐng)導(dǎo)任務(wù)完成,提出技術(shù)方法
測試/質(zhì)量保證/項目經(jīng)理:負責(zé)8名以上人員的一個或多個項目,負責(zé)全生存期業(yè)務(wù)/產(chǎn)品經(jīng)理:負責(zé)多個項目的人員管理,負責(zé)項目方向和業(yè)務(wù)盈虧1.7軟件測試的誤區(qū)
市場對軟件質(zhì)量重要性的認識逐漸增強。所以,軟件測試在軟件項目實施過程中的重要性日益突出。但是,現(xiàn)實情況是,與軟件編程比較,軟件測試的地位和作用,還沒有真正受到重視,對于很多人(甚至是軟件項目組的技術(shù)人員)還存在對軟件測試的認識誤區(qū),這進一步影響了軟件測試活動開展和真正提高軟件測試質(zhì)量。
(1)誤區(qū)之一:軟件開發(fā)完成后進行軟件測試
人們一般認為,軟件項目要經(jīng)過以下幾個階段:需求分析,概要設(shè)計,詳細設(shè)計,軟件編碼,軟件測試,軟件發(fā)布。據(jù)此,認為軟件測試只是軟件編碼后的一個過程。這是不了解軟件測試周期的錯誤認識。軟件測試是一個系列過程活動,包括軟件測試需求分析,測試計劃設(shè)計,測試用例設(shè)計,執(zhí)行測試。因此,軟件測試貫穿于軟件項目的整個生命過程。在軟件項目的每一個階段都要進行不同目的和內(nèi)容的測試活動,以保證各個階段的正確性。軟件測試的對象不僅僅是軟件代碼,還包括軟件需求文檔和設(shè)計文檔。軟件開發(fā)與軟件測試應(yīng)該是交互進行的,例如,單元編碼需要單元測試,模塊組合階段需要集成測試。如果等到軟件編碼結(jié)束后才進行測試,那么,測試的時間將會很短,測試的覆蓋面將很不全面,測試的效果也將大打折扣。更嚴重的是如果此時發(fā)現(xiàn)了軟件需求階段或概要設(shè)計階段的錯誤,如果要修復(fù)該類錯誤,將會耗費大量的時間和人力。
(2)誤區(qū)之二:軟件發(fā)布后如果發(fā)現(xiàn)質(zhì)量問題,那是軟件測試人員的錯
這種認識很打擊軟件測試人員的積極性。軟件中的錯誤可能來自軟件項目中的各個過程,軟件測試只能確認軟件存在錯誤,不能保證軟件沒有錯誤,因為從根本上講,軟件測試不可能發(fā)現(xiàn)全部的錯誤。從軟件開發(fā)的角度看,軟件的高質(zhì)量不是軟件測試人員測出來的,是靠軟件生命周期的各個過程中設(shè)計出來的。出現(xiàn)軟件錯誤,不能簡單地歸結(jié)為某一個人的責(zé)任,有些錯誤的產(chǎn)生可能不是技術(shù)原因,可能來自于混亂的項目管理。應(yīng)該分析軟件項目的各個過程,從過程改進方面尋找產(chǎn)生錯誤的原因和改進的措施。
(3)誤區(qū)之三:軟件測試要求不高,隨便找個人多都行
很多人都認為軟件測試就是安裝和運行程序,點點鼠標(biāo),按按鍵盤的工作。這是由于不了解軟件測試的具體技術(shù)和方法造成的。隨之軟件工程學(xué)的發(fā)展和軟件項目管理經(jīng)驗的提高,軟件測試已經(jīng)形成了一個獨立的技術(shù)學(xué)科,演變成一個具有巨大市場需求的行業(yè)。軟件測試技術(shù)不斷更新和完善,新工具,新流程,新測試設(shè)計方法都在不斷更新,需要掌握和學(xué)習(xí)很多測試知識。所以,具有編程經(jīng)驗的程序員不一定是一名優(yōu)秀的測試工程師。軟件測試包括測試技術(shù)和管理兩個方面,完全掌握這兩個方面的內(nèi)容,需要很多測試實踐經(jīng)驗和不斷學(xué)習(xí)精神。
(4)誤區(qū)之四:軟件測試是測試人員的事情,與程序員無關(guān)開發(fā)和測試是相輔相成的過程
需要軟件測試人員、程序員和系統(tǒng)分析師等保持密切的聯(lián)系,需要更多的交流和協(xié)調(diào),以便提高測試效率。另外,對于單元測試主要應(yīng)該由程序員完成,必要時測試人員可以幫助設(shè)計測試樣例。對于測試中發(fā)現(xiàn)的軟件錯誤,很多需要程序員通過修改編碼才能修復(fù)。程序員可以通過有目的的分析軟件錯誤的類型、數(shù)量,找出產(chǎn)生錯誤的位置和原因,以便在今后的編程中避免同樣的錯誤,積累編程經(jīng)驗,提高編程能力。
(5)誤區(qū)之五:項目進度吃緊時少做些測試,時間富裕時多做測試這是不重視軟件測試的表現(xiàn),也是軟件項目過程管理混亂的表現(xiàn),必然會降低軟件測試的質(zhì)量。一個軟件項目的順利實現(xiàn)需要有合理的項目進度計劃,其中包括合理的測試計劃,對項目實施過程中的任何問題,都要有風(fēng)險分析和相應(yīng)的對策,不要因為開發(fā)進度的延期而簡單的縮短測試時間、人力和資源。因為縮短測試時間帶來的測試不完整,對項目質(zhì)量的下降引起的潛在風(fēng)險,往往造成更大的浪費?朔@種現(xiàn)象的最好辦法是加強軟件過程的計劃和控制,包括軟件測試計劃、測試設(shè)計、測試執(zhí)行、測試度量和測試控制。
(6)誤區(qū)之六:軟件測試是沒有前途的工作,只有程序員才是軟件高手由于我國軟件整體開發(fā)能力比較低,軟件過程很不規(guī)范,很多軟件項目的開發(fā)都還停留在—作坊式‖和—壘雞窩‖階段。項目的成功往往靠個別全能程序員決定,他們負責(zé)總體設(shè)計和程序詳細設(shè)計,認為軟件開發(fā)就是編寫代碼,給人的印象往往是程序員是真正的牛人,具有很高的地位和待遇。因此,在這種環(huán)境下,軟件測試很不受重視,軟件測試人員的地位和待遇自然就很低了,甚至軟件測試變得可有可無。隨著市場對軟件質(zhì)量的不斷提高,軟件測試將變得越來越重要,相應(yīng)的軟件測試人員的地位和待遇將會逐漸提高。在微軟等軟件過程比較規(guī)范的大公司,軟件測試人員的數(shù)量和待遇與程序員沒有多大差別,優(yōu)秀測試人員的待遇甚至比程序員還要高。軟件測試將會成為一個具有很大發(fā)展前景的行業(yè),軟件測試大有前途,市場需要更多具有豐富測試技術(shù)和管理經(jīng)驗的測試人員,他們同樣是軟件專家。這兩年來國內(nèi)軟件測試人員的需求不斷增大,越來越多的IT企業(yè)認識到了軟件測試的重要性,這種可喜的現(xiàn)狀與發(fā)展趨勢讓筆者對我國軟件業(yè)的發(fā)展重新抱有較大的希望。
盡管這是一門嶄新的學(xué)科,目前在國內(nèi)的發(fā)展仍處于"嬰兒"階段,但看到越來越多的軟件公司為軟件測試招兵買馬,看到越來越多的技術(shù)人員投入到軟件測試中,我就情不自禁地感嘆:機會來了!這機會不僅僅是某一個人的,而是所有人的,它對每個人都是公平的,學(xué)的領(lǐng)域需要新的理論新的工具新的方法,由于國內(nèi)的軟件測試還處在一個比較初級的階段,沒有人確切地知道它需要什么樣的基礎(chǔ),也沒有人確切地知道它應(yīng)該怎樣發(fā)展,因此這個領(lǐng)域需要大家來共同革命,以促進它的深入發(fā)展。1.8軟件測試的前景
隨著軟件產(chǎn)業(yè)的發(fā)展,軟件產(chǎn)品的質(zhì)量控制與質(zhì)量管理正逐漸成為軟件企業(yè)生存與發(fā)展的核心。幾乎每個大中型IT企業(yè)的軟件產(chǎn)品在發(fā)布前都需要大量的質(zhì)量控制、測試和文檔工作,而這些工作必須依靠擁有嫻熟技術(shù)的專業(yè)軟件人才來完成。軟件測試工程師就是這樣的一個企業(yè)重頭角色。業(yè)內(nèi)人士分析,該類職位的需求主要集中在沿海發(fā)達城市,其中北京和上海的需求量分別占去33%和29%。民企需求量最大,占19%,外商獨資歐美類企業(yè)需求排列第二,占15%。然而,目前的現(xiàn)狀是:一方面企業(yè)對高質(zhì)量的測試工程師需求量越來越大越大,另一方面國內(nèi)原來對測試工程師的職業(yè)重視程度不夠,使許多人不了解測試工程師具體是從事什么工作。這使得許多IT公司只能通過在實際工作中進行淘汰的方式對測試工程師進行篩選,因此國內(nèi)在短期將出現(xiàn)測試工程師嚴重短缺的現(xiàn)象。根據(jù)對近期網(wǎng)絡(luò)招聘IT人才情況的了解,許多正在招聘軟件測試工程師的企業(yè)
很少能夠在招聘會上順利招到合適的人才。在具體工作過程中,測試工程師的工作是利用測試工具按照測試方案和流程對產(chǎn)品進行功能和性能測試,甚至根據(jù)需要編寫不同的測試用例,設(shè)計和維護測試系統(tǒng),對測試方案可能出現(xiàn)的問題進行分析和評估。對軟件測試工程師而言,必須具有高度的工作責(zé)任心和自信心。任何嚴格的測試必須是一種實事求是的測試,因為它關(guān)系到一個產(chǎn)品的質(zhì)量問題,而測試工程師則是產(chǎn)品出貨前的把關(guān)人,所以,沒有專業(yè)的技術(shù)水準是無法勝任這項工作的。同時,由于測試工作一般由多個測試工程師共同完成,并且測試部門一般要與其他部門的人員進行較多的溝通,所以要求測試工程師不但要有較強的技術(shù)能力而且要有較強的溝通能力。第二章軟件測試工作的經(jīng)驗和心得
2.1軟件測試用例的規(guī)范
一個好的測試用例,是測試人員能夠迅速、準確找出程序中潛在問題的良好開端。此所謂:工欲善其事,必先利其器。只有一個好的測試用例,才能使測試人員在測試過程中少走歪路,在最短的時限內(nèi),找出程序中潛在的Bug;只有一個好的測試用例,才能使測試人員更準確、更有效地找出Bug。下面是我在對郵件服務(wù)系統(tǒng)進行測試時,縮寫的測試用例表(包含測試的場景/條件、測試的方法/操作、預(yù)期結(jié)果、實際結(jié)果和備注說明)
測試用例示例
正如前面所說的,好的測試用例左右了測試的過程。那是否一個好的測試用例能適合所有的測試對象呢?
答案是否定的,就從我對軟件測試接觸和實踐,個人認為:“沒有最好的測試用例,只有最合適的測試用例”;就好比我們無法用“漏勺”去取“水”一樣,一個程序的測試用例,我們往往無法運用到另一個程序上,即便兩個程序十分相似,也不能保證一個測試用例能夠覆蓋兩個程序中的所有場景。遺漏場景就意味著測試工作尚未完成用錯了工具,“水”永遠也取不上來。下面就給出了,一個與上面用例完全不同的測試用例。這個測試用例,是我在測試WebService方法時所用的用例之一,使用了自動化測試的方法(關(guān)于自動化測試,詳見下一節(jié))。這個WebService方法有一個參數(shù),名叫“rightNumber”,此處,我為這個方法寫了3組用例,case001和case003分別是兩組參數(shù)正確的用例條件,而case002則使用了一組無效數(shù)據(jù)。(一般用例都要考慮空數(shù)據(jù),但此處因為是調(diào)用WebService方法,方法參數(shù)填寫為空不具備任何意思,故不作考慮)
根據(jù)以上測試用例,我調(diào)用了自己編寫的名為WebServiceTest的測試小工具,先進行測試用例的加載,分析測試用例格式的合法性。格式合法,則可進行測試(測試過程自動)。
結(jié)果如下圖:
圖2.1.1
圖2.1.2
結(jié)果分析:
圖2.1.1為WebService方法GetRightByNumber正確數(shù)據(jù)的結(jié)果圖,圖中標(biāo)簽下的為該方法返回結(jié)果類型,標(biāo)簽下的標(biāo)簽為返回值的各項數(shù)據(jù)。
圖2.1.2為WebService方法GetRightByNumber無效數(shù)據(jù)的結(jié)果圖,圖中的標(biāo)簽說明該項測試條件有誤,并顯示詳細的錯誤信息:
下圖為Bug表單的示例
圖2.1.3
通常來說測試用例完成后,測試人員根據(jù)已有的測試用例對目標(biāo)項目進行包含以下步驟的測試:
1.新的缺陷被測試人員提交;
2.項目經(jīng)理確定該缺陷的優(yōu)先級、分配開發(fā)人員來修復(fù);3.開發(fā)人員根據(jù)缺陷的優(yōu)先級去修復(fù)缺陷,使該缺陷被修復(fù);4.開發(fā)人員發(fā)布一個新的內(nèi)部版本;
5.測試人員確認這個新版本中的被修復(fù)缺陷;
6.被修復(fù)的缺陷被關(guān)閉;沒有被修復(fù)缺陷被再次打開,返回1。
2.2自動化測試
概念:利用軟件測試工具自動實現(xiàn)全部或部分測試,自動測試是軟件測試的一個重要組成部分,它能完成許多手工測試無法實現(xiàn)或難以實現(xiàn)的測試。正確、合理的實施自動測試,能夠快速、全面的對軟件進行測試,從而提高軟件質(zhì)量,節(jié)省經(jīng)費,縮短軟件發(fā)布周期
自動化測試的優(yōu)點:
(1)改進所有的測試領(lǐng)域
a)測試用例設(shè)計改進b)性能測試改進c)壓力測試改進
d)質(zhì)量度量與測試優(yōu)化
(2)改進測試工作質(zhì)量
a)BVT測試改進b)回歸測試改進
c)多平臺兼容性測試改進d)軟件配置測試改進e)普通測試執(zhí)行改進
f)集中于高級測試問題改進g)執(zhí)行手工測試無法完成的測試h)定時啟動測試
(3)減輕測試工作量并加快測試進度
階段測試計劃測試設(shè)計測試執(zhí)行測試結(jié)果分析缺陷監(jiān)控測試報告生成總體
自動化軟件測試的優(yōu)勢已經(jīng)十分明顯了,那么,是否所有的工作都能進行自動化測試呢?
答案也是否定的。因為有點時候,我們沒有辦法實現(xiàn)自動化或不合適使用自動化測試。以下是自動化測試的適用范圍
工作量增加減少減少減少減少減少減少(1)(2)(3)(4)執(zhí)行回歸測試
執(zhí)行手工很難達到或手工無法完成的測試枯燥乏味的重復(fù)性工作一致的,可重復(fù)的測試
自動測試常見的錯誤
(1)實施一項測試設(shè)計時,不遵循任何設(shè)計標(biāo)準,結(jié)果產(chǎn)生了不可重復(fù)的測試腳本,
因而不可重用
(2)試圖將測試需求100%自動化(3)使用錯誤的工具
(4)在應(yīng)用程序開發(fā)周期中啟用測試工具太晚(5)測試工程師參與應(yīng)用開發(fā)生存周期太晚,導(dǎo)致不能很好的了解應(yīng)用和系統(tǒng)設(shè)計,
因而無法完成測試
在上一節(jié)中,我在測試WebService方法時就使用了自動化測試,下面進行詳細的說明測試中,我使用了多個測試用例同時加載,并挨個進行測試的方法,對所有的WebService方法進行了測試。
雖然網(wǎng)上也提供了現(xiàn)成的WebService方法測試工具。但這種工具只能一次測試一個WebService方法的一組數(shù)據(jù),無法進行批量測試,效率不高。所以,我自己寫了一個小工具,提供了批量測試的可能。這一點也符合自動化測試靈活、合理實施的理念。
下面是批量測試時測試用例文件。
圖2.2.1
測試時,先將該文件夾下的所有用例文件進行加載,然后進行測試。下面是測試結(jié)果安放文件夾
圖2.2.2
根據(jù)分析以上測試結(jié)果,將問題及時反饋給開發(fā)人員。
2.3測試中的問題2.3.1測試運用的是認識論
認識論是探討人類認識的本質(zhì)、結(jié)構(gòu),認識與客觀實在的關(guān)系,認識的前提和基礎(chǔ),認識發(fā)生、發(fā)展的過程及其規(guī)律,認識的真理標(biāo)準等問題的哲學(xué)學(xué)說。又稱知識論。根據(jù)認識論的運用我們可以給軟件測試提出以下問題:
(1)怎么知道軟件足夠好?
(2)如果軟件并不是足夠好,怎樣才能知道?(3)怎么知道已經(jīng)完成了足夠的測試?
這些看似簡單的問題,都是科學(xué)家,心理學(xué)家的通過研究認識論才總結(jié)出來的,對我們測試提供了重要的指導(dǎo)思想。
2.3.2測試無法發(fā)現(xiàn)所有的程序問題
測試人員的任務(wù)是找出并報告重要的程序問題,但是不會發(fā)現(xiàn)所有的程序問題。為了發(fā)現(xiàn)全部程序錯誤,測試人員必須檢查所有可能有問題的地方,而事實上是不可能做到的。如果測試人員認為自動能夠做到,要么產(chǎn)品太簡單,要么是測試人員的想象力太差。因此,測試人員只能發(fā)現(xiàn)軟件存在問題,卻無法確定軟件不存在問題。參考資料
【1】百度知道【2】測試用例設(shè)計【3】《軟件測試經(jīng)驗與教訓(xùn)》,作者:CemKaner、JamesBach、BretPettichord【4】《硅谷的測試在中國》【5】《軟件開發(fā)的科學(xué)和藝術(shù)》節(jié)選,撰文/陳宏剛【6】其他網(wǎng)絡(luò)資料論文信息
論文作者:姚斌
撰寫時間:201*-11-29
撰寫目的:對軟件測試的心得和經(jīng)驗的總結(jié)
友情提示:本文中關(guān)于《軟件開發(fā)心得總結(jié)》給出的范例僅供您參考拓展思維使用,軟件開發(fā)心得總結(jié):該篇文章建議您自主創(chuàng)作。
來源:網(wǎng)絡(luò)整理 免責(zé)聲明:本文僅限學(xué)習(xí)分享,如產(chǎn)生版權(quán)問題,請聯(lián)系我們及時刪除。