第一篇:測(cè)試經(jīng)驗(yàn)總結(jié)
6年測(cè)試工作的思考
前言
在公司已經(jīng)干了6年的測(cè)試了,干測(cè)試經(jīng)理也5年了。正好趁此機(jī)會(huì)把自己6年來一直想寫但沒寫的東西寫出來。這篇文件純粹是對(duì)自己工作的回顧。由于時(shí)間倉促基本上是想到什么些什么,有點(diǎn)兒亂,也請(qǐng)大家多多擔(dān)待了。只要還有些人能從中找到些兒同感,或從中得到一些幫助,一些經(jīng)驗(yàn),我就知足了。
1.什么是測(cè)試
首先我要談?wù)勈裁词菧y(cè)試。相信好多測(cè)試人員跟我一樣,來公司之前也沒有從事過任何測(cè)試工作。對(duì)于測(cè)試都是從零開始的。也有好多人跟我一樣,從各種書上或是培訓(xùn)中得到過有關(guān)測(cè)試的各種定義。但不知道大家有沒有凈下心思考一下。什么是測(cè)試。在公司公司測(cè)試工作的定義是什么,測(cè)試的工作范圍是什么。
測(cè)試的定義根據(jù)測(cè)試技術(shù)的發(fā)展,歷經(jīng)了3個(gè)主要的階段。第一個(gè)階段,認(rèn)為測(cè)試就是找產(chǎn)品中的bug。第二個(gè)階段,除了找bug以外,又增加測(cè)試是對(duì)軟件質(zhì)量的度量這一概念。第三個(gè)階段,明確了測(cè)試是指為了度量和提高被測(cè)試軟件的質(zhì)量,對(duì)測(cè)試件進(jìn)行工程設(shè)計(jì),使用和維護(hù)的并發(fā)生命周期。注意其中提高的測(cè)試件,其主要是與軟件這個(gè)詞進(jìn)行對(duì)應(yīng)。明確測(cè)試也是一種開發(fā)過程。他的工作成果就是測(cè)試件,好像平時(shí)我們所謂的測(cè)試案例、測(cè)試腳本等等都可以稱為測(cè)試件。然后使用測(cè)試件去度量和提高被測(cè)試軟件的質(zhì)量。
目前,在中國(guó)大部分軟件企業(yè),尤其是中小型的軟件企業(yè)還停留在第一階段。我個(gè)人覺得公司稍微好一點(diǎn)兒,處于一、二階段之間。因?yàn)槲覀兤綍r(shí)做的最多的一件事,還是找bug。至于測(cè)試案例和測(cè)試腳本等等,只占用工作量的很小一部分。而且我看不到大家在平時(shí)的測(cè)試工作中是完全依據(jù)測(cè)試案例進(jìn)行測(cè)試的。目前測(cè)試案例等工作更多的成為了一種形式上的產(chǎn)物。從有些部分所有產(chǎn)品的測(cè)試案例在一個(gè)下午就能評(píng)審?fù)昃湍芸吹贸鰜怼?/p>
說到這里順便在談一句測(cè)試計(jì)劃。目前的測(cè)試計(jì)劃是作為產(chǎn)品計(jì)劃的一部分。先明確大概發(fā)版時(shí)間,然后是各個(gè)階段的里程碑,其中提交集成的里程碑是死的。開發(fā)需要的時(shí)間就是那么多,剩下倒推的時(shí)間就是測(cè)試的時(shí)間。這樣定出的計(jì)劃是否能夠起到計(jì)劃的作用就不好說了?,F(xiàn)在的計(jì)劃更多的是羅列聯(lián)調(diào)測(cè)試的各種內(nèi)容,至于時(shí)間,不說也罷。所以從中也可以開出公司的測(cè)試也就停留在一、二階段之間。
明確了公司測(cè)試的定義(個(gè)人理解),也就不難理解公司給測(cè)試人員的定位了。在測(cè)試人員中經(jīng)常流傳的一種說法就是國(guó)外測(cè)試人員的地位多么多么的高,開發(fā)就是coding。咱們公司開發(fā)比測(cè)試多拿多少多少,測(cè)試人員地位是開發(fā)序列中最低的。大家也要看看人家公司測(cè)試人員的素質(zhì),測(cè)試在開發(fā)過程中的重要性。再看看自己所從事的工作,就是找軟件的bug。當(dāng)然我也個(gè)人認(rèn)為有經(jīng)驗(yàn)極其豐富的測(cè)試人員對(duì)產(chǎn)品的貢獻(xiàn)比開發(fā)和需求大。明確了這些,心里也就能少點(diǎn)兒不平衡感。
2.測(cè)試方法的思考
說完個(gè)人對(duì)測(cè)試含義的理解,再說說個(gè)人對(duì)測(cè)試方案的一些思考。
個(gè)人認(rèn)為在公司6年,測(cè)試方法沒有什么提高。主要還是以黑盒測(cè)試為主。中間也曾經(jīng)引入過各種各種工具,但測(cè)試人員真正用起來的也就是robot。而且robot主要是進(jìn)行回歸測(cè)試,再加上一些人并沒有真正認(rèn)識(shí)到其價(jià)值,應(yīng)用范圍也極其有限。對(duì)整體測(cè)試效率的提升影響不大。所以目前的測(cè)試方案還主要是以需求為依據(jù)的黑盒測(cè)試。至于什么極限值了,成對(duì)測(cè)試法等等,都是建立在黑盒測(cè)試的基礎(chǔ)上,而且從我一來公司就有相應(yīng)的測(cè)試項(xiàng)目,只不過沒有明確概念而已。
另一個(gè)說個(gè)人覺得6年來公司測(cè)試方法沒有什么提高的原因是,6年前測(cè)試是以人為主,靠得是測(cè)試人員的經(jīng)驗(yàn),對(duì)產(chǎn)品的熟悉程度,對(duì)業(yè)務(wù)的理解程度。6年后測(cè)試還是以人為主,人就是測(cè)試的主體,產(chǎn)品質(zhì)量的保證。還沒有過渡到測(cè)試案例就是測(cè)試的主體,測(cè)試案例的完整性是產(chǎn)品質(zhì)量的保證。只要測(cè)試還是以人為本,我覺得測(cè)試的效率就不會(huì)有太大提高,產(chǎn)品質(zhì)量的信心來源也是對(duì)相關(guān)測(cè)試人員的信任。我個(gè)人覺得以黑盒測(cè)試為主要的測(cè)試方法沒錯(cuò),而且也比較符合目前公司的測(cè)試現(xiàn)狀。但一定要注意各種經(jīng)驗(yàn)的總結(jié)、積累,更重要的是共享。雖然目前測(cè)試案例在測(cè)試工作過程中的地位不重要,但其畢竟是編寫者的經(jīng)驗(yàn)積累。匯總起來也是一筆可觀的財(cái)富??涩F(xiàn)在如果有人問我850的測(cè)試方案在那里,其中還有多大比例能夠用在現(xiàn)在的產(chǎn)品中,在現(xiàn)在的測(cè)試工作中有多少以前的案例能夠復(fù)用。其他產(chǎn)品中的測(cè)試案例中有多少是關(guān)于接口功能,有多少我可以借鑒。我不知道,這也是自己工作不到位的地方。所以我要說的作為黑盒測(cè)試為主要的測(cè)試方法,一定要注意測(cè)試經(jīng)驗(yàn)的總結(jié)和共享。
而且我認(rèn)為一個(gè)人如果黑盒測(cè)試能做到位,做到最后培養(yǎng)的是一種測(cè)試的感覺。測(cè)到最后,產(chǎn)品你一看就能知道那里可能有問題,那里應(yīng)該沒什么問題。這樣有重點(diǎn)地投入測(cè)試力量可以收到事半功倍的效果。可這是需要大量測(cè)試經(jīng)驗(yàn)的積累的,不是我告訴你,你就知道的能力。在此前提上加強(qiáng)測(cè)試人員之間的橫向溝通,形成經(jīng)驗(yàn)貢獻(xiàn)。可以較快的培養(yǎng)測(cè)試人員的測(cè)試感覺。
最為測(cè)試經(jīng)驗(yàn)積累的另一個(gè)重要方法就是加強(qiáng)對(duì)測(cè)試案例的要求和管理。每版測(cè)試案例不僅要包括新增功能,還需要包括上一版本中繼承的案例,修改或刪除上版案例中變更的內(nèi)容。從而形成一份完整的關(guān)于產(chǎn)品所有功能點(diǎn)、接口、升級(jí)、年結(jié)等等各方面的測(cè)試案例。真正做到測(cè)試案例是測(cè)試的主體,從而提高測(cè)試效率,提高產(chǎn)品質(zhì)量。
3.測(cè)試工具的概念和作用
測(cè)試工具,什么叫測(cè)試工具。我認(rèn)為任何能提高你測(cè)試效率的工具都可以稱之為測(cè)試工具。不僅僅指robot或是loadrunner這類專門的測(cè)試工具,也不僅僅指使用各種編程工具編寫的測(cè)試工具。像總賬工具、eai等,即使只是幫我們導(dǎo)入一些常用檔案,也可以節(jié)約我們的測(cè)試時(shí)間也可以稱之為測(cè)試工具。
我個(gè)人現(xiàn)在公司測(cè)試在測(cè)試工具開發(fā)上還很不足。在公司里一提起測(cè)試工具,大家第一個(gè)想到的可能就是robot。即使是robot應(yīng)用的也不夠深入。大家經(jīng)常認(rèn)為robot主要錄制gui的腳本,跟產(chǎn)品界面聯(lián)系緊密。每次回放成功率不高,各個(gè)版本間腳本復(fù)用率也較低。而且每次總是以各種理由將腳本錄制放到最后,經(jīng)常就不了了之了。最后階段的測(cè)試任務(wù)實(shí)在太緊。我想說的是robot的應(yīng)用雖然有各種各樣的局限性,但其畢竟提高了測(cè)試效率。比如說安裝盤驗(yàn)證,使用robot驗(yàn)證,每天都可以節(jié)約一半以上的驗(yàn)證時(shí)間,這就是效率。認(rèn)識(shí)了它的好處,才能想盡辦法解決或避免在robot使用中的各種問題。以前同事有一套robot腳本規(guī)范就很好,使用后不僅提高了回放成功率,而且回放中斷后,繼續(xù)回放也變得很容易。所以說使用robot后,想100%回放成功不可能,想不再進(jìn)行腳本的調(diào)試也不可能。認(rèn)識(shí)這兩個(gè)問題后,就需要加強(qiáng)robot使用經(jīng)驗(yàn)的總結(jié)和共享,有針對(duì)性地加強(qiáng)robot使用問題的研究,每版測(cè)試開始時(shí)針對(duì)上版robot腳本的復(fù)用問題進(jìn)行研究。這樣才能用好它,真得使之成為一個(gè)工具,而不是一項(xiàng)任務(wù)。
一種工具也不是萬能,有許多針對(duì)產(chǎn)品特性的測(cè)試工具。只能自己開發(fā),大家應(yīng)該積極提需求。凡是認(rèn)為有可能提高測(cè)試效率的工具需求都可以提。能從網(wǎng)上找到現(xiàn)成的工具解決需求更好。不能,如果是普遍性的需求,可以專門進(jìn)行開發(fā)。因?yàn)樵蹅儺a(chǎn)品的特性,每版間測(cè)試工具的復(fù)用度很大。從長(zhǎng)遠(yuǎn)看就是節(jié)約開發(fā)成本,縮短開發(fā)周期。
在現(xiàn)階段加大測(cè)試工具的適用范圍和力度,用好各種測(cè)試工具,可能是提高整體測(cè)試效率最快最好的方法。但一定要加大推廣的力度。否則有了好的工具,沒人用或用不起來也是沒用。
4.如何看待各種規(guī)則和執(zhí)行
可能大家覺得平時(shí)開發(fā)過程中有好多規(guī)則、制度。這些除了一些自己公司內(nèi)根據(jù)各種情況制定的外,大部分都是跟cmm體系相關(guān)的一些規(guī)則??梢哉f是已經(jīng)被許多軟件公司驗(yàn)證過,可以提高開發(fā)和測(cè)試效率的規(guī)則。但好多人覺得起沒有什么用,就是在浪費(fèi)時(shí)間??偸且砸环N完成任務(wù)或是應(yīng)付差事的心情去做。我覺得大家之所以覺得其沒用,恰恰就是由于你去做這件事的動(dòng)機(jī)不對(duì)??傄詰?yīng)付差事的心情去做,你就不可能真正理解這么做的目的,這樣做能給你帶來什么好處,你從中會(huì)得到什么收益。所以我個(gè)人認(rèn)為,既然有規(guī)則,不管是公司自創(chuàng)的或是借鑒其他標(biāo)準(zhǔn),都是為了解決開發(fā)過程中的問題,為了提高開發(fā)的效率,保證產(chǎn)品質(zhì)量。也許這些規(guī)則中有這樣那樣的不合理,但只有你認(rèn)真地去做了,才能發(fā)現(xiàn)其中的不妥之處,才能改進(jìn),才能更有助于你的工作。
執(zhí)行也是我覺得在工作中需要進(jìn)一步加強(qiáng)的環(huán)節(jié)。許多規(guī)則就是因?yàn)閳?zhí)行力度不足,才容易讓一些人找到空子,應(yīng)付了事。但怎樣加強(qiáng)執(zhí)行力度,還是一個(gè)需要大家一起進(jìn)行探討的問題。
5.作為一名測(cè)試人員應(yīng)該具有的素質(zhì)
測(cè)試人員應(yīng)該具有什么樣的素質(zhì),相信好多人都有自己的理解,不同書上的觀點(diǎn)也不盡相同。我就說說我在公司工作了六年,覺得一個(gè)合格的測(cè)試人員應(yīng)該具有什么樣的素質(zhì)。業(yè)務(wù)和測(cè)試方面的能力就不說了。
測(cè)試人員應(yīng)該具有的素質(zhì)包括: 1.踏實(shí)細(xì)心和積極主動(dòng)
我覺得作為一名測(cè)試人員首先要踏實(shí)細(xì)心。測(cè)試人員每天都要面對(duì)著枯燥的程序,從事著大量的重復(fù)工作,還要盡量發(fā)現(xiàn)產(chǎn)品中的bug。如果不踏實(shí),你就坐不住,總想干別的,就無法凈下心來想用戶有可能怎么用,需求對(duì)產(chǎn)品是怎么要求的,現(xiàn)在產(chǎn)品中是怎么做的,哪里可能存在問題。不細(xì)心,就特別容易一些產(chǎn)品中微笑的錯(cuò)誤,而恰恰就是這些錯(cuò)誤是最影響產(chǎn)品形象的問題。
至于積極主動(dòng)就不多說了。這是每個(gè)人都應(yīng)該具有的素質(zhì)。2.懷疑一切
不抱著懷疑一切的態(tài)度就不是一名合格的測(cè)試人員。經(jīng)過你手測(cè)試的產(chǎn)品面對(duì)的是直接用戶。你不認(rèn)真負(fù)責(zé),不抱著懷疑一切的態(tài)度??傁胫@個(gè)功能本版沒動(dòng)應(yīng)該沒什么問題,這個(gè)功能沒什么用戶用不用認(rèn)真測(cè)了。這樣發(fā)出的產(chǎn)品,我是不敢讓用戶用。因?yàn)橛脩粲闷甬a(chǎn)品來是千奇百怪,有些用戶的水平和對(duì)產(chǎn)品的理解比咱們還要深。所以一定要抱著懷疑一切的態(tài)度,認(rèn)為產(chǎn)品每個(gè)功能都可能有問題,認(rèn)真地測(cè)試產(chǎn)品的每一個(gè)測(cè)試點(diǎn)。
3.協(xié)作和團(tuán)隊(duì)感
協(xié)作和團(tuán)隊(duì)感也是十分重要的。要意識(shí)到測(cè)試、開發(fā)、需求是一個(gè)團(tuán)隊(duì),一個(gè)整體。離了誰,產(chǎn)品的質(zhì)量都無法保證。誠(chéng)然有個(gè)別開發(fā)人員責(zé)任心不強(qiáng),經(jīng)常將未經(jīng)任何驗(yàn)證的代碼編譯后發(fā)給測(cè)試進(jìn)行驗(yàn)證。耽誤了測(cè)試人員不少的時(shí)間。但越這樣,測(cè)試人員越應(yīng)該負(fù)責(zé),否則產(chǎn)品發(fā)出去影響的是公司的形象。
還有個(gè)別開發(fā)人員開不起測(cè)試。此時(shí)就需要你通過各種方法去證明你自己的能力。比如測(cè)試出他根本就沒考慮過的問題等等。以實(shí)際行動(dòng)證明你離不開我,咱們是一個(gè)水平的。只有這樣加強(qiáng)協(xié)作和團(tuán)隊(duì)建設(shè),加強(qiáng)整個(gè)團(tuán)隊(duì)的質(zhì)量意識(shí),才能提高開發(fā)效率,保證產(chǎn)品質(zhì)量。
4.自我提高和總結(jié)的能力
測(cè)試人員經(jīng)常很迷茫,不知道自己的發(fā)展方向在哪里。測(cè)試技術(shù)還是專業(yè)知識(shí)。領(lǐng)導(dǎo)們所謂的個(gè)人發(fā)展方向考慮也經(jīng)常是畫一個(gè)餅在那里。這時(shí)就只能靠我們自己了。看你想今后從事哪方面的工作。一般情況下,如果升不到管理層就只有兩條路可選了。一是業(yè)務(wù)精通,將來可以向需求或是售前、實(shí)施方向發(fā)展。一是技術(shù)精通,多掌握幾種測(cè)試工具,又能力可以學(xué)習(xí)一些編程方面的知識(shí)。將來還繼續(xù)從事測(cè)試方面的工作。隨著中國(guó)軟件開發(fā)的規(guī)范化,這條路也是很有發(fā)展的。
另外,我覺得作為一名合格的測(cè)試人員,一定要注意進(jìn)行總結(jié)。通過總結(jié)可以對(duì)自己的工作進(jìn)行一個(gè)回顧分析,看看那些做得不錯(cuò),下次還繼續(xù)這么做。那些工作還有改進(jìn)的余地。對(duì)自己能力的提高是一個(gè)很好的幫助。
6.作為一名測(cè)試經(jīng)理應(yīng)該具有的能力
作為一名測(cè)試經(jīng)理,我覺得除了具備一個(gè)測(cè)試人員應(yīng)該具備的素質(zhì)外,還應(yīng)具備以下能力。
1.出色的溝通和協(xié)調(diào)能力
由于測(cè)試人員和開發(fā)人員的工作性質(zhì),必然導(dǎo)致測(cè)試人員和開發(fā)人員在工作中會(huì)產(chǎn)生沖突,對(duì)同一問題會(huì)產(chǎn)生不同的看法。這時(shí),你怎么去協(xié)調(diào),去溝通,解決這種矛盾,讓自己所在的開發(fā)團(tuán)隊(duì)中極少的受此影響,就是考驗(yàn)?zāi)隳芰Φ臅r(shí)候。
2.條理性和計(jì)劃性
作為測(cè)試經(jīng)理,要負(fù)責(zé)帶領(lǐng)團(tuán)隊(duì)內(nèi)的其他測(cè)試人員全面的測(cè)試產(chǎn)品。由于測(cè)試項(xiàng)目很多,不僅包括產(chǎn)品功能,還要包括效率,性能,壓力,并發(fā)互斥,環(huán)境等等方方面面。此時(shí)你如何去安排這些測(cè)試項(xiàng)目,哪些可以先做,哪些可以并行。與開發(fā)人員在一些項(xiàng)目的測(cè)試中如何協(xié)調(diào)就是考驗(yàn)?zāi)阕鍪碌臈l理性和計(jì)劃性。
3.從全局考慮產(chǎn)品測(cè)試的能力
每一個(gè)測(cè)試人員在產(chǎn)品測(cè)試中,重點(diǎn)肯定是自己負(fù)責(zé)產(chǎn)品的功能,此時(shí)就容易遺漏其他的一些測(cè)試項(xiàng)目。有可能是接口的部分功能,又可能是升級(jí)或年結(jié)的部分功能。此時(shí),你如何提請(qǐng)他們還有漏測(cè)的功能點(diǎn)。在有限時(shí)間內(nèi),能找出他產(chǎn)品測(cè)試上的薄弱點(diǎn),就是考驗(yàn)?zāi)阃ūP考慮產(chǎn)品測(cè)試的能力。
后記
上面就是我對(duì)6年測(cè)試工作的一個(gè)回顧。這些都是我個(gè)人的一些觀點(diǎn),很不全面,也有不正確和遺漏的地方。大家看后,能從中得到一些自己需要的東西,我就知足了。
再次感謝在這6年中給了我許多幫助和支持的各位兄弟姐妹們。
附錄A、QA工作心得
看過許多同行兄弟姐妹的工作感受,反映了一些從事QA工作過程中的困惑,心里也很有同感。之前做過幾年的測(cè)試工作,到了新的公司開始做QA工作,雖說測(cè)試工作也是屬于質(zhì)量工作范疇,但是真正干起來才發(fā)現(xiàn),還是有很大的不同的,尤其是思想方法和工作方法上。所以也是邊學(xué)邊干,這邊和大家分享一點(diǎn)心得。
1、調(diào)整好自己的心態(tài)。
尊重開發(fā)人員、產(chǎn)品經(jīng)理、項(xiàng)目經(jīng)理等項(xiàng)目組內(nèi)同事,不要把自己定位為監(jiān)工,要把自己定位為服務(wù)員。如果你真的是從心里想幫助大家把事情做好,而不是教訓(xùn)別人,大家會(huì)感受到的。很多時(shí)候,調(diào)整好自己的心態(tài)才是難點(diǎn)。
2、有的放矢 不要盲目的發(fā)表意見,要做到有理有據(jù),這也是避免項(xiàng)目組內(nèi)成員產(chǎn)生爭(zhēng)執(zhí)和不理解的前提。在提出意見和建議前,最好做一下調(diào)查,收集一些資料和數(shù)據(jù),或者和大家深入的聊一聊,開一些交流會(huì),座談會(huì),收集到一線開發(fā)人員的真實(shí)感受,不要自己一覺得有問題就沖出來,這樣肯定會(huì)被別人反感,也會(huì)降低大家對(duì)QA的認(rèn)同和信任感。
3、數(shù)據(jù)說話
質(zhì)量工作相對(duì)務(wù)虛不假,之前做測(cè)試好歹還有很多的bug擺在那里,剛開始做QA工作確實(shí)覺得虛了很多。自己的產(chǎn)出在哪里?后來發(fā)現(xiàn),其實(shí)還是可以有很多的,呵呵。你可以給相關(guān)人員進(jìn)行培訓(xùn)(質(zhì)量知識(shí)、軟件工程知識(shí)、產(chǎn)品開發(fā)知識(shí)、質(zhì)量制度和規(guī)范等等),會(huì)議記錄和培訓(xùn)資料算是你的產(chǎn)出的一部分。另外,對(duì)于項(xiàng)目過程中產(chǎn)生的問題,變更等,要有記錄,一定周期內(nèi)作出分析和報(bào)告,比如,變更發(fā)生率,項(xiàng)目延期的原因分布,與計(jì)劃的不符合程度等等。進(jìn)一步提出改進(jìn)建議,有了這些數(shù)據(jù)支持,你提出建議也就更有說服力。
4、溝通再溝通
其實(shí)很多問題都是發(fā)生在溝通上,我覺得溝通好了,起碼可以解決70%的問題。多為大家提供交流和溝通的機(jī)會(huì),比如,發(fā)起一個(gè)交流會(huì),讓組內(nèi)同事互相培訓(xùn),形成一個(gè)良好的內(nèi)部學(xué)習(xí)交流氣氛。另外,什么也比不過面對(duì)面的溝通,拋棄聊天工具和email吧,走過去,和你的同事一起好好聊聊,吃飯的時(shí)候,坐車的時(shí)候,你會(huì)發(fā)現(xiàn)很多深入的問題的,呵呵。
5、循序漸進(jìn)
規(guī)范制定好了,不要一下子就想完全推行到底。畢竟要改變別人已有的習(xí)慣,是會(huì)讓別人不舒服的,呵呵。所以要循序漸進(jìn),分期分批,一點(diǎn)點(diǎn)來,習(xí)慣慢慢的就被改變了,這樣大家就不會(huì)太抵觸。而且,在分期分批推行規(guī)范的過程中,別忘了不斷收集反饋意見,不斷改進(jìn)和修正規(guī)范,規(guī)范可不是qa說是什么就是什么的,一定要收集大家的意見,達(dá)成共識(shí),這樣才有被大家執(zhí)行的基礎(chǔ)。
6、展示自己
QA工作務(wù)虛,但是可以落到實(shí)處,是有很多實(shí)際工作要做的,比如文檔編寫,規(guī)范起草。培訓(xùn)、評(píng)審、跟進(jìn)問題。這些工作的成果如何體現(xiàn),效果如何,可以通過一些問卷調(diào)查,來收集大家的反饋,舉個(gè)例子,如果推行產(chǎn)品開發(fā)流程規(guī)范前大家對(duì)流程的滿意度是50%,推行規(guī)范兩個(gè)月以后,滿意度成了90%,你說這是誰的功勞呢?呵呵,這也是數(shù)據(jù)說話的一個(gè)方面,也是QA工作成績(jī)的展現(xiàn)。說了這么多,其實(shí)我做QA工作也只有3個(gè)月,還有很多的不足,希望能和大家多多的交流,如果自己的一點(diǎn)心得,能夠給大家一些幫助或啟發(fā),就深感欣慰了,呵呵。歡迎拍磚!
附錄B、SQA之Q&A 軟件質(zhì)量保證,即 SQA,全稱是 Software Quality Assurance。
問: SQA 目的是什么?
答: 對(duì)于任何的行業(yè),講到質(zhì)量控制,歸根結(jié)底都是為客戶提供更高品質(zhì)的產(chǎn)品,更好地滿足客戶的需求。質(zhì)量有問題的話就不能滿足客戶的需求。在 CMMI 里邊就有 “ 集成流程產(chǎn)品開發(fā) IPPD(Integrated Product & Process Development)”,為什么要集成呢?就是說產(chǎn)品的研發(fā)不僅僅是開發(fā)團(tuán)隊(duì)的工作,還要把市場(chǎng)團(tuán)隊(duì)、銷售團(tuán)隊(duì)、整個(gè)的流程、包括客戶的反饋都要考慮進(jìn)來、集成進(jìn)來。目的是為了什么?其實(shí)就是為了更好地滿足客戶的需求。六西格瑪里面說 DPMO(Defect Per Million Opportunities),百萬產(chǎn)品里有缺陷的產(chǎn)品只有三個(gè)。這是為什么?就是為了減少差錯(cuò),從而讓客戶享受非常高質(zhì)量的服務(wù)。
問: SQA 等于測(cè)試?
答: 測(cè)試其實(shí)只是 SQA 的一個(gè)環(huán)節(jié),SQA 的全稱是軟件質(zhì)量保證。在國(guó)外很多的大型的企業(yè),比如說摩托羅拉、愛立信,他們的研發(fā)團(tuán)隊(duì)里面都專門有一個(gè) QA 部門,其實(shí)他們并不是做測(cè)試工作的。QA 部門其實(shí)是管理開發(fā)流程的執(zhí)行,并專門負(fù)責(zé)制定產(chǎn)品開發(fā)流程。比如說 RUP 里面有一個(gè)角色,叫 Process Engineer,過程工程師,他就屬于 QA 部門,他的工作就是負(fù)責(zé)制定整個(gè)軟件開發(fā)的流程。因?yàn)槿绻f要保證質(zhì)量的話,不能只靠測(cè)試來保證。而必須在整個(gè)開發(fā)流程的各個(gè)環(huán)節(jié)都要做得很好,才能夠真正地提升軟件的質(zhì)量。而測(cè)試只是整個(gè)開發(fā)流程最后的一個(gè)階段。所以說一個(gè)好的流程就決定了一個(gè)軟件的開發(fā)能不能按時(shí)交貨,能否保證軟件質(zhì)量。這個(gè)流程就是由 QA 部門來制定的。QA 部門還有另外一個(gè)職責(zé),就是保證整個(gè)研發(fā)團(tuán)隊(duì)能夠嚴(yán)格按照這個(gè)流程來運(yùn)作。在項(xiàng)目到達(dá)每一個(gè)里程碑的時(shí)候,QA 部門的 QA 經(jīng)理就會(huì)介入,對(duì)項(xiàng)目做一個(gè)審核,檢查前一階段的工作是否按照公司制定的流程來運(yùn)作??纯丛撚械墓ぜ遣皇嵌加辛耍撚械牟襟E是不是都有了。開發(fā)團(tuán)隊(duì)要證明給 QA 人員看。只有過了這一關(guān),QA 部門才會(huì)同意說開發(fā)團(tuán)隊(duì)可以往下走,進(jìn)行下一步的工作。所以嚴(yán)格來講,眾廣義上理解,SQA 是針對(duì)整個(gè)軟件開發(fā)流程的,它關(guān)心的是怎樣在軟件開發(fā)生命周期中來保證好軟件的質(zhì)量。這是一個(gè)非常大的概念。
問: SQA 在 RUP 中是如何體現(xiàn)的?
答: 其實(shí) RUP 整個(gè)流程都在講 SQA。業(yè)界常見的模型,譬如 CMM/CMMI,六西格瑪,ISO9000,RUP,它們做的基本上是同一件事情--都是在做流程改進(jìn),都在做質(zhì)量控制,但是各自的側(cè)重點(diǎn)不一樣。像 RUP 和 SDP 專門側(cè)重于從軟件開發(fā)的整個(gè)生命周期來保證軟件質(zhì)量,所以對(duì)軟件開發(fā)商特別適合。而其它的模型,側(cè)重點(diǎn)則在其它的環(huán)節(jié),比如說 ISO9000,用在制造業(yè)比較多一些; CMM,原來是應(yīng)用在軟件這個(gè)行業(yè)的,后來擴(kuò)展到 CMMI,就擴(kuò)展到其它行業(yè)它也適用。但適用面越廣,它拉的層次就越高,可實(shí)際操作的東西就越少。RUP 是專門側(cè)重于軟件項(xiàng)目開發(fā)的。怎樣來保證做好 QA 呢? RUP 里定義了一個(gè)軟件生命周期模型,分成四個(gè)階段--初始階段、細(xì)化階段、構(gòu)造階段、交付階段,每個(gè)階段有不同的側(cè)重點(diǎn),通過多次的迭代,每次迭代里面都要做質(zhì)量控制。
質(zhì)量控制從需求開始,有很多需求分析和需求管理方面的技巧和技術(shù)方法,它們從需求方面來保證軟件的質(zhì)量;到了設(shè)計(jì),就有很多成熟的設(shè)計(jì)方法,例如可視化建模,基于構(gòu)件的架構(gòu)設(shè)計(jì)和現(xiàn)在提出的模型驅(qū)動(dòng)開發(fā)方法;再到實(shí)現(xiàn),到測(cè)試等方面,都有很多的方法和技巧來提高軟件的質(zhì)量。這里面每一個(gè)環(huán)節(jié)的目的都是為了提高整個(gè)軟件開發(fā)的質(zhì)量。
開發(fā)過程中,什么樣的問題會(huì)造成質(zhì)量問題呢?其實(shí)最主要的就是溝通方面的問題,以及對(duì)系統(tǒng)復(fù)雜度把握程度的問題。我們逐漸發(fā)展了一些技術(shù)來幫助我們解決這些方面的問題,例如用 UML 這種標(biāo)準(zhǔn)化的語言來增強(qiáng)團(tuán)隊(duì)的溝通,用面向?qū)ο蟮募夹g(shù)來幫助加強(qiáng)對(duì)復(fù)雜度的控制能力。
原來這個(gè)系統(tǒng)很復(fù)雜,使用面向?qū)ο蟮姆椒?,本身就是為了?jiǎn)化系統(tǒng)構(gòu)建的復(fù)雜度。改變你看問題的角度,你對(duì)問題的把握程度就會(huì)不一樣。譬如人看一個(gè)二維迷宮很容易就能找到出路,但螞蟻在里面就走不出來,因?yàn)榭磫栴}的角度不一樣。面向?qū)ο蠓椒ê涂梢暬<夹g(shù)可以讓開發(fā)人員可以更好地去把握系統(tǒng),增強(qiáng)對(duì)系統(tǒng)的可控制能力,從而從這些維度上來提高和保證軟件的質(zhì)量。
現(xiàn)在有很多自動(dòng)化的工具,如 IBM Rational RAD(Rational Application Developer)/ RSA(Rational Software Architect),都是支持 MDA 的開發(fā)方法,在模型這一級(jí)進(jìn)行開發(fā),從模型直接生成代碼。在開發(fā)方面我們有很多輔助工具,幫助開發(fā)人員盡量將人工做的工作、復(fù)雜的重復(fù)性的工作、不具有創(chuàng)造性的工作讓工具來做。讓人去關(guān)注他應(yīng)該關(guān)注的方面,比如開發(fā)人員應(yīng)該關(guān)注業(yè)務(wù)邏輯的處理,但是軟件的構(gòu)建方面我們是盡量讓工具來降低構(gòu)建細(xì)節(jié)上的難度。這樣也是有助于提高質(zhì)量的。
然后產(chǎn)品出來了,需要進(jìn)行測(cè)試,有測(cè)試流程、測(cè)試規(guī)范來幫助保證質(zhì)量,這是最直接的。然后還有很多的環(huán)節(jié)還會(huì)發(fā)生錯(cuò)誤,比如配置管理、版本的管理,也需要相關(guān)的支持來保證軟件的質(zhì)量。所以說軟件質(zhì)量保證不應(yīng)該只是在一個(gè)環(huán)節(jié)上,比如測(cè)試環(huán)節(jié)來保證,而應(yīng)該是整個(gè)的流程,我們應(yīng)該全面地去改進(jìn)流程來保證質(zhì)量。
問: 做 SQA 這方面的人員,在溝通方面需要的什么樣技巧和能力?
答: 首先從大的方面說,整個(gè)團(tuán)隊(duì)的溝通,首先是大家要講同樣的語言。UML 只是這種語言的一部分,我們不要狹義地理解這種溝通語言就是 UML。它還包括采用一個(gè)什么樣的流程方法,整個(gè)團(tuán)隊(duì)都要理解。譬如你說項(xiàng)目正處于 “ 精化(Elaboration)” 階段,這個(gè)團(tuán)隊(duì)都要能理解這個(gè)術(shù)語。
還有就是整個(gè)組織機(jī)構(gòu)內(nèi)部大家采用的流程都是要一樣的。舉個(gè)例子來說,Rational 有很多產(chǎn)品,其中很多都是收購來的。不同的產(chǎn)品團(tuán)隊(duì)采用的開發(fā)方法、開發(fā)工具都是不一樣的,他們到了 Rational 之后做的第一件事就是整合。這個(gè)整合一方面是說產(chǎn)品要整合起來(我們有 Suite 產(chǎn)品);同時(shí)也是針對(duì)開發(fā)團(tuán)隊(duì)開發(fā)方法的整合,例如 Rational 花了一兩年的時(shí)間把所有產(chǎn)品團(tuán)隊(duì)統(tǒng)一到 RUP 和 ClearCase/ClearQuest平臺(tái)之上,這是我們的首選。實(shí)際上到了 IBM 之后也是一樣,IBM 現(xiàn)在正在做的計(jì)劃就是讓所有的實(shí)驗(yàn)室、研發(fā)團(tuán)隊(duì)都要使用 IBM Rational 自己的開發(fā)工具,他們都在使用 IBM 自己的開發(fā)方法、開發(fā)平臺(tái)。這就是讓大家的溝通基于一個(gè)統(tǒng)一的基礎(chǔ)架構(gòu) ―― 統(tǒng)一的軟件開發(fā)平臺(tái),這也是增強(qiáng)溝通的一種方式。另外,講到 SQA 的人員,在 RUP 里對(duì)應(yīng)的就應(yīng)該是 Process Engineer。他的主要的職能就是定義流程,保證流程的執(zhí)行,并且不斷地改進(jìn)流程。對(duì)他的要求就是要對(duì)流程要比較了解,有實(shí)際項(xiàng)目的開發(fā)經(jīng)驗(yàn),不然沒有辦法理解流程,這是技能方面;另外就是與人的溝通能力要強(qiáng),跟一般的開發(fā)人員和項(xiàng)目經(jīng)理是有區(qū)別的,溝通的能力一定要強(qiáng),他要負(fù)責(zé)說服項(xiàng)目團(tuán)隊(duì)來遵循標(biāo)準(zhǔn)。
問: QA 人員與目經(jīng)理和開發(fā)人員之間的關(guān)系是怎樣的?
答: 首先彼此之間是一個(gè)合作的關(guān)系。如果片面理解 QA 人員只是 “ 過程警察 ” 的話,就可能把他和其他的角色對(duì)立起來了。實(shí)際上在一個(gè)團(tuán)隊(duì)內(nèi)部要避免這種認(rèn)識(shí)。因?yàn)榇蠹叶际窃谝粋€(gè)組織架構(gòu)內(nèi)部的,大家的目標(biāo)是一致的,就是要把公司的業(yè)務(wù)做好。所以 QA 人員的職責(zé)和任務(wù)就是幫助這個(gè)項(xiàng)目團(tuán)隊(duì)更好地進(jìn)行軟件的開發(fā)。既然已經(jīng)定義的流程是比較適合企業(yè)的,項(xiàng)目就應(yīng)該遵守這個(gè)流程來進(jìn)行開發(fā)。如果有時(shí)候項(xiàng)目因?yàn)橼s工,或是其它的原因違背一些流程上的規(guī)定的話,就會(huì)對(duì)軟件的質(zhì)量會(huì)造成一定影響,他就有責(zé)任來幫助開發(fā)團(tuán)隊(duì)來糾正這方面的一些錯(cuò)誤。還有就是進(jìn)度方面的問題。如果不按照流程來走的話,短期內(nèi)看起來進(jìn)度是快了一點(diǎn),但從整個(gè)項(xiàng)目的周期來看,有可能是給以后的工作帶來隱患,客觀上肯定是延長(zhǎng)整個(gè)開發(fā)的進(jìn)度的。所以對(duì)于一些流程管理得比較好的企業(yè),你會(huì)發(fā)現(xiàn)他們的 QA 部門和開發(fā)團(tuán)隊(duì)是相處得比較融洽的,配合是比較緊密的。在我們的客戶里就看到過他們的開發(fā)團(tuán)隊(duì)非常感謝自己的質(zhì)量控制人員,覺得他們對(duì)自己是給了很大的幫助。
QA 人員跟每一個(gè)角色的關(guān)系,如果你對(duì)應(yīng)到 RUP 的話,RUP 里就定義好每一個(gè)角色是做什么工作的。RUP 里分了 9 個(gè)規(guī)程(discipline),流程工程師是在環(huán)境規(guī)程里邊,項(xiàng)目經(jīng)理是在項(xiàng)目管理規(guī)程里邊。每一個(gè)規(guī)程其實(shí)就是一類開發(fā)活動(dòng),其中的角色和他們所產(chǎn)生的工件集合,是一個(gè)分類??梢园秧?xiàng)目經(jīng)理相關(guān)的工作,他所涉及到的工件,比如說軟件開發(fā)計(jì)劃、風(fēng)險(xiǎn)管理計(jì)劃、質(zhì)量保證計(jì)劃都放在一起,放在這個(gè)規(guī)程里面。所以 QA 人員跟項(xiàng)目經(jīng)理的關(guān)系就是去檢查項(xiàng)目經(jīng)理在這個(gè)崗位上所做的職責(zé)是否到位,是不是跟流程相符合。其他的角色也是一樣的,譬如一個(gè)測(cè)試人員,就要看你有沒有根據(jù)規(guī)定把缺陷按正確的測(cè)試流程匯報(bào),發(fā)現(xiàn)缺陷之后是否能夠得到改正,并作一個(gè)復(fù)審,還有回歸測(cè)試的時(shí)候有沒有考慮測(cè)試的完備性等問題,就是看測(cè)試人員有沒有做好具體的工作。QA 人員和整個(gè)項(xiàng)目團(tuán)隊(duì)在工作中的關(guān)系就是看每一個(gè)角色是不是很好地完成了自身角色所應(yīng)該完成的開發(fā)任務(wù)。標(biāo)準(zhǔn)是什么?就是這個(gè)組織的流程,流程是保證質(zhì)量很重要的一個(gè)依據(jù)。
問: QA 人員如何判斷其工作效果和質(zhì)量?
答: 最直接就是 RUP 里的工件??梢匀z查這些工件,可以根據(jù)檢查的結(jié)果來判斷角色是否達(dá)到了要求。既然是檢查這個(gè)結(jié)果的話,就有必要涉及到統(tǒng)一流程和工具的問題。就是說開發(fā)團(tuán)隊(duì)有必要采用統(tǒng)一的開發(fā)方法和流程。不然的話每一個(gè)開發(fā)團(tuán)隊(duì)各自采用不同的開發(fā)流程,流程工程師就很難去評(píng)價(jià),沒有一個(gè)可對(duì)照的標(biāo)準(zhǔn),沒有可比性。另外,和采用的工具也有關(guān)系,就是說團(tuán)隊(duì)要盡量采用統(tǒng)一的開發(fā)平臺(tái)。采用統(tǒng)一的開發(fā)平臺(tái),工具會(huì)幫助自動(dòng)收集很多的信息。比如說我們的 Project Console 可以幫助收集很多量化的指標(biāo);現(xiàn)在有 Portfolio Manager,項(xiàng)目組合管理平臺(tái),可以幫助了解項(xiàng)目進(jìn)度還有項(xiàng)目進(jìn)行過程中產(chǎn)生的各種結(jié)果;還有包括測(cè)試的報(bào)告等等,這些都最好有一個(gè)統(tǒng)一的標(biāo)準(zhǔn)。打個(gè)比方來說,現(xiàn)在的航空公司都會(huì)選擇相同飛機(jī)制造廠商的機(jī)型,就是要降低維護(hù)的成本。因?yàn)闄C(jī)型比較統(tǒng)一的話,就比較好進(jìn)行管理。在一個(gè)軟件企業(yè)的話,在內(nèi)部采用統(tǒng)一的軟件開發(fā)平臺(tái)也能有助于企業(yè)判斷項(xiàng)目的情況,判斷的方法也會(huì)相對(duì)比較簡(jiǎn)單,工作量會(huì)降低。
這是從 QA 的角度來看,其次從整個(gè)團(tuán)隊(duì)的角度來說,今天是做這個(gè)項(xiàng)目,明天做另外一個(gè)項(xiàng)目,作為企業(yè)的管理人員肯定不希望員工今天做這個(gè)項(xiàng)目用一個(gè)工具,明天做另外一個(gè)項(xiàng)目用另外的工具,這樣學(xué)習(xí)成本就太高了。
第二篇:測(cè)試經(jīng)驗(yàn)總結(jié)
1.測(cè)試人員和用戶的聯(lián)系與區(qū)別
黑盒測(cè)試人員和用戶,都是站在實(shí)際應(yīng)用層進(jìn)行操作,因此他們對(duì)應(yīng)用層的可用性、實(shí)用性非常關(guān)注。用戶不懂的是軟件的使用,而相對(duì)用戶來說,測(cè)試人員對(duì)軟件比較了解,但不熟悉業(yè)務(wù)本身。
八個(gè)字歸納:用戶是用,測(cè)試是測(cè)。
用戶不懂使用就需要技術(shù)支持人員去培訓(xùn),而測(cè)試人員在測(cè)試初期經(jīng)過開發(fā)人員和項(xiàng)目負(fù)責(zé)人的簡(jiǎn)單培訓(xùn)后,就應(yīng)該通過所學(xué)的理論知識(shí)和相關(guān)的業(yè)務(wù)知識(shí)獨(dú)立去了解、深入到軟件的功能點(diǎn)中。
應(yīng)該做到:由測(cè)試人員培訓(xùn)技術(shù)支持人員,由技術(shù)支持人員實(shí)施時(shí)給用戶培訓(xùn)。
2.帶著問題去測(cè)試
阿豬工作守則第一條:帶著問題去測(cè)試
測(cè)試中會(huì)遇到很多問題,沒關(guān)系,沒有腦子里面的一個(gè)個(gè)問號(hào),是不能很好的發(fā)現(xiàn)問題的。往往發(fā)現(xiàn)一些藏的很深的bug都是在測(cè)試人員一步步解決這些問號(hào)的過程中,切忌遇到問題就問,不僅因?yàn)樵黾硬槐匾呐c開發(fā)人員、負(fù)責(zé)人等的交流時(shí)間可能延誤項(xiàng)目進(jìn)度,而且自己對(duì)問題的印象也不會(huì)很深刻,畢竟在相對(duì)較短的測(cè)試時(shí)間內(nèi),聽不如記,記不如自己去發(fā)現(xiàn)規(guī)律。
3.測(cè)試期間提問題和交流的時(shí)機(jī)
什么時(shí)候應(yīng)該提問題?
我們都知道,作為測(cè)試人員,并不是測(cè)試期間什么時(shí)候遇到問題就要馬上問,那什么時(shí)候是提問的時(shí)間?
培訓(xùn)
培訓(xùn)時(shí),一般在講解內(nèi)容的間歇允許打斷,由培訓(xùn)人員解答測(cè)試人員的疑惑。培訓(xùn)的過程其實(shí)就是一個(gè)傳輸新知識(shí)并答疑的時(shí)間,這個(gè)期間的提問是歡迎的,也可以增加參與性和調(diào)動(dòng)積極性。所以希望大部分的問題能在這個(gè)階段提出來。受時(shí)間、環(huán)境等條件制約,有時(shí)培訓(xùn)的人講的也不一定細(xì)致和全面,這時(shí)就需要自己多想,想想這個(gè)功能是干什么的,為什么這么做,對(duì)應(yīng)的業(yè)務(wù)是什么。
阿豬工作守則第二條:培訓(xùn)時(shí)腦子靈活轉(zhuǎn)動(dòng),多想多問
以前大家可能有過參加辯論會(huì)的經(jīng)歷,就算沒有其實(shí)和人聊天也是一個(gè)交互的過程。參加辯論會(huì)要求快速思考,然后放慢語速說出自己的觀點(diǎn),因?yàn)椴荒苷f錯(cuò)。我們?cè)趨⒓优嘤?xùn)時(shí)前者相同,后者相反。腦子嘴巴都要快,說錯(cuò)了也沒有關(guān)系,自己的想法被糾正的過程中也是加深印象和理解的過程。
計(jì)劃評(píng)審
提出對(duì)于軟件不理解、安排的任務(wù)不明白的地方。
測(cè)試期間
這個(gè)時(shí)期最主要的問題應(yīng)該集中在影響測(cè)試流程和進(jìn)度的問題,而不是說明書或其它文檔上已有的內(nèi)容,或者與自己負(fù)責(zé)模塊無關(guān)的內(nèi)容。開發(fā)人員和其他測(cè)試人員都有自己的進(jìn)度安排,因此,影響測(cè)試流程和進(jìn)度的問題,馬上問!
不影響流程的問題,記下來統(tǒng)一問!
不必要的問題(說明書或其它文檔上已有的內(nèi)容、講過三遍以上的問題、今晚去哪里吃飯的問題),不問!
好處:避免不必要的時(shí)間支出,不打亂自己的測(cè)試思路,一氣呵成,并且使項(xiàng)目成本得到控制
壞處(?):腦子里、筆記本上留下一堆待解決的問號(hào)吧,浪費(fèi)腦細(xì)胞和公司的筆和紙
張等資源
阿豬工作守則第三條:先做事,后學(xué)習(xí)
在有限的時(shí)間內(nèi)先完成該做的事,有空閑的時(shí)間再去補(bǔ)充自己的知識(shí)。
要很好的把握上述內(nèi)容,也要求提高培訓(xùn)期間培訓(xùn)人員培訓(xùn)內(nèi)容的完善性,要求前期培訓(xùn)人員強(qiáng)調(diào)出軟件的重點(diǎn)、難點(diǎn)和注意事項(xiàng)。這個(gè)期間適合于上面提到的“帶著問題去測(cè)試”的方法。
但有一點(diǎn)需要注意:不要為了一個(gè)地方的卡殼在那耗上一天半天的,這就不值得了。測(cè)試中期評(píng)審測(cè)試問題
答疑解惑的時(shí)間。
測(cè)試報(bào)告評(píng)審
對(duì)一些結(jié)論有疑惑和不解的地方,提!
4.記筆記
一個(gè)老生常談的話題。
阿豬工作守則第四條:好記性不如爛筆頭
測(cè)試培訓(xùn)的時(shí)候?qū)τ谝恍┲攸c(diǎn)應(yīng)該記下來,即使當(dāng)時(shí)聽懂了;沒聽明白的更應(yīng)該記下來,到測(cè)試軟件的時(shí)候去驗(yàn)證自己的疑問。如果培訓(xùn)時(shí)特別強(qiáng)調(diào)的地方,測(cè)試時(shí)再去問,這就不好了。
養(yǎng)成一個(gè)良好的習(xí)慣,會(huì)使以后的工作更加順利。
5.在公司和學(xué)校的學(xué)習(xí)的區(qū)別
學(xué)校是專門學(xué)習(xí)的地方,公司就是工作的地方,因此,它們的性質(zhì)決定了其學(xué)習(xí)內(nèi)容和方法的不同。
學(xué)校 公司 備注
內(nèi)容上 主要是系統(tǒng)的理論知識(shí) 主要是和項(xiàng)目相關(guān)的業(yè)務(wù)知識(shí) 如果在測(cè)試中感到自己部分理論知識(shí)欠缺時(shí),就應(yīng)該回家多補(bǔ)充了
時(shí)間上 大塊時(shí)間的連續(xù)學(xué)習(xí)相對(duì)鄰散 在公司一般不會(huì)拿出大塊時(shí)間來學(xué)習(xí)和講解 形式上 老師授課+自學(xué) 培訓(xùn)+交流+測(cè)試過程中自學(xué)
個(gè)人覺得,一個(gè)高效的測(cè)試流程應(yīng)該如下:
a.花幾個(gè)小時(shí)至多半天時(shí)間快速閱讀瀏覽軟件說明書、設(shè)計(jì)文檔;
這個(gè)階段要讓腦子里面形成對(duì)軟件的整體印象感,能夠讓自己把握全局,因此,測(cè)試負(fù)責(zé)人安排時(shí)間看文檔時(shí),決不能忽視它的重要性,否則就會(huì)出現(xiàn)后續(xù)階段磕磕碰碰的情況。注重速讀,把握軟件說明,忽略具體的數(shù)據(jù)庫設(shè)計(jì)、功能點(diǎn)設(shè)計(jì)、計(jì)算、規(guī)則和輔助工具(相關(guān)軟件)說明文檔,囫圇吞棗的方法在這里就顯得很有效。
如果項(xiàng)目時(shí)間緊或沒有文檔,這個(gè)步驟所做的事可以在下面完成。
b.利用培訓(xùn)時(shí)間消化吸收的知識(shí)
c.軟件上手
幾個(gè)小時(shí)至多半天時(shí)間,熟悉軟件框架和基本功能,不要求所有功能都會(huì)操作,自己負(fù)責(zé)的模塊可以多側(cè)重一些。
d.細(xì)測(cè)
主要癥對(duì)計(jì)劃中安排給自己做的模塊,這時(shí)就要相對(duì)放慢節(jié)奏,每一步操作、每個(gè)對(duì)話框(操作界面)都要深究,別放過任何情況。這時(shí)會(huì)遇到一些錯(cuò)誤或不理解的地方,明顯的如報(bào)錯(cuò)就提到開發(fā)過程論壇,不明顯的就先記下來,等這個(gè)功能點(diǎn)測(cè)完再回頭去看,你會(huì)發(fā)現(xiàn):
50%的問題可以自己分析出來和解決,有的問題不是問題,只是開始還沒有完全理解。阿豬工作守則第五條:軟件不是一次能測(cè)透的Rome is not built in one day.工期、人力、環(huán)境資料等,都制約著測(cè)試的深度和廣度,因?yàn)椴灰谕淮文芡耆盐漳硞€(gè)軟件。
綜合測(cè)試的優(yōu)勢(shì)在于,我們負(fù)責(zé)公司產(chǎn)品的把關(guān),而項(xiàng)目由產(chǎn)品延伸而來;測(cè)試產(chǎn)品會(huì)不斷出新的版本,一次沒有理解,可以在下一次中彌補(bǔ),溫故而知新。
一口吃不成一個(gè)胖子,看我這么瘦又這么能吃就知道了^^
要結(jié)合自己的實(shí)際情況決定本次測(cè)試的深度,不要看著別人進(jìn)度快了就打亂自己的節(jié)奏,只要安排合理,應(yīng)該按照計(jì)劃來。特別忌諱認(rèn)為自己這塊沒問題了就馬上去看看別人負(fù)責(zé)的功能,期望全能。這樣一般來說除了ljl這種全能性人物外都會(huì)造成最后自己的問題留了一堆,別人的也沒搞懂。
新人特別注意,踏踏實(shí)實(shí)的搞懂每個(gè)自己負(fù)責(zé)的模塊,打陣地站,這種方法很有效。評(píng)價(jià)自己是否可以轉(zhuǎn)入下個(gè)模塊的幾個(gè)因素:自我提問與別人提問、測(cè)試進(jìn)度
如果大多數(shù)相關(guān)人員(主要是測(cè)試負(fù)責(zé)人、其他部分相關(guān)測(cè)試人員特別是開發(fā)組集成測(cè)試人員和技術(shù)支持人員)對(duì)于自己負(fù)責(zé)模塊的問題都能解答,搞定!NEXT-->轉(zhuǎn)入下個(gè)模塊。
否則,還是再回頭想想思路和遺漏的地方。當(dāng)然,要綜合考慮測(cè)試進(jìn)度。請(qǐng)組長(zhǎng)對(duì)自己提幾個(gè)軟件的問題,他會(huì)很樂意的。
e.小結(jié)
一個(gè)階段就進(jìn)行一次小結(jié),這個(gè)小結(jié)可以是書面的,比如測(cè)試問題記錄、測(cè)試用例補(bǔ)充、測(cè)試模塊設(shè)計(jì)等,但大多是自己分析,為了方便接下來模塊的測(cè)試.f.性能測(cè)試
性能測(cè)試不僅是測(cè)試性能,同時(shí)也加深自己對(duì)軟件應(yīng)用的理解,因?yàn)樾阅軠y(cè)試往往和實(shí)際應(yīng)用或用戶需求結(jié)合的很緊密,避免造成軟件功能都會(huì)用,但不知用來干麻的尷尬情況。g.安裝盤測(cè)試
安裝盤程序測(cè)試,簡(jiǎn)單過一下軟件功能有無錯(cuò)誤。
安裝盤程序文件、庫文件、組件等的完整性、正確性,這個(gè)非常重要,要不返工就浪費(fèi)時(shí)間了。這個(gè)階段要積極與開發(fā)負(fù)責(zé)人和GJ溝通,確保最后的勝利。
h.測(cè)試總結(jié)
測(cè)試接近尾聲,總結(jié)自己對(duì)軟件的掌握情況,得出測(cè)試結(jié)論、歸納測(cè)試方法、提出修改建議,為軟件以后版本的修改提供依據(jù),也為以后再測(cè)類似軟件提供捷徑。
5.小結(jié)
? 用戶用軟件,測(cè)試測(cè)軟件
培訓(xùn)時(shí)多想多問?
好記性不如爛筆頭?
帶著問題去測(cè)試,在測(cè)試中解決問題?
? 先做事,后學(xué)習(xí),爭(zhēng)取雙贏
軟件不是一次能測(cè)透的?
第三篇:測(cè)試工作經(jīng)驗(yàn)總結(jié)
測(cè)試工作經(jīng)驗(yàn)總結(jié)
功能測(cè)試最重要的是理解業(yè)務(wù)和需求。知道系統(tǒng)要實(shí)現(xiàn)什么功能,業(yè)務(wù)流程是怎樣的,然后就可以根據(jù)需求編寫測(cè)試計(jì)劃和測(cè)試用例了。測(cè)試書籍上介紹常用的編寫測(cè)試用例的方法有:等價(jià)類、邊界值、因果圖、判定表等,在實(shí)際工作中,我使用較多的有等價(jià)類、邊界值、場(chǎng)景法和錯(cuò)誤猜測(cè)法。在這里需要提一點(diǎn),將測(cè)試用例按測(cè)試目的進(jìn)行分類,比如用戶界面、功能點(diǎn)、業(yè)務(wù)場(chǎng)景等,會(huì)讓測(cè)試用例的結(jié)構(gòu)看起來更清晰,執(zhí)行測(cè)試用例的效率也更高。
要做好功能測(cè)試,還需要對(duì)整個(gè)系統(tǒng)的數(shù)據(jù)庫結(jié)構(gòu)比較清楚,每個(gè)功能點(diǎn)涉及哪些數(shù)據(jù)表,對(duì)數(shù)據(jù)的操作方式是怎樣的。這樣就不單從前臺(tái)頁面來進(jìn)行測(cè)試,通過對(duì)數(shù)據(jù)庫中數(shù)據(jù)的驗(yàn)證,可以發(fā)現(xiàn)隱藏的一些bug。比如庫表沒有進(jìn)行關(guān)聯(lián)刪除,從前臺(tái)頁面是看不出來的,但實(shí)際可能導(dǎo)致程序出現(xiàn)問題。對(duì)一些比較復(fù)雜的組合查詢或數(shù)據(jù)排序,也可以自己編寫sql語句對(duì)結(jié)果進(jìn)行驗(yàn)證。
了解程序的框架結(jié)構(gòu)和一些開發(fā)知識(shí)也有助于更好地測(cè)試程序和定位錯(cuò)誤。
測(cè)試用例的編寫經(jīng)驗(yàn)步驟和數(shù)據(jù)的分離
將輸入的各種數(shù)據(jù)已參數(shù)的形式表達(dá)在操作步驟中,而不需要為每一種輸入數(shù)據(jù)創(chuàng)建一個(gè)測(cè)試用例。
例如:atm存款
好的測(cè)試用例,在執(zhí)行的步驟(Step)的表達(dá)上應(yīng)該是盡可能和數(shù)據(jù)相分離。舉例來講,有一個(gè)ATM機(jī)取款的功能,可能有以下幾個(gè)場(chǎng)景:
1.密碼正確的登錄
2.密碼錯(cuò)誤的登錄
3.密碼輸入三次錯(cuò)誤,卡被鎖定
4.取少于余額的款項(xiàng)
5.嘗試取大于余額的款項(xiàng)
6.嘗試取等于余額的款項(xiàng)(考慮手續(xù)費(fèi))
6.取款額度大于當(dāng)次的限制
7.取款額度大于當(dāng)天的限制
7.取款次數(shù)大于限制次數(shù)
等等
不管你用什么用例設(shè)計(jì)的方法論來做指導(dǎo),作為這個(gè)簡(jiǎn)單的例子,有經(jīng)驗(yàn)的人都應(yīng)該能看出,此處的很多步驟是可以重用的,總結(jié)下來如下(此處只列出了操作的步驟,略去了系統(tǒng)的交互中的反饋結(jié)果):
1.插入卡->A:輸入密碼->B:按“確定”鍵->重復(fù)A-B
2.A:選擇取款功能->B:填寫取款金額->C:點(diǎn)擊“確定取款”的按鈕->D:取現(xiàn)金->重復(fù)A-D
因此,我們只需要寫出兩套比較完整的步驟,將密碼和取款金額多數(shù)字用參數(shù)來表達(dá)即可。這樣是不是簡(jiǎn)單了很多呢?單獨(dú)的測(cè)試基礎(chǔ)數(shù)據(jù)準(zhǔn)備工作
將測(cè)試基礎(chǔ)數(shù)據(jù)提前準(zhǔn)備好,寫到你單獨(dú)的測(cè)試數(shù)據(jù)準(zhǔn)備文檔中,而不是分散到 所有使用到它的case中才去描述。測(cè)試用例的前后置條件
除了第二點(diǎn)中談到的數(shù)據(jù)需要準(zhǔn)備外,在測(cè)試用例這個(gè)Level,必須有一些條件滿足,您才能開始執(zhí)行它。集中的把這些步驟整理成一個(gè)相對(duì)獨(dú)立的操作單元,具體用例中只要引用就可以了,這樣會(huì)便于對(duì)用例的理解和在多處復(fù)用。
順便說一下,對(duì)于一些類似軟件運(yùn)行環(huán)境的條件,比如安裝和配置測(cè)試中,需要3種操作系統(tǒng)和3種瀏覽器的組合等,我們可以把他放在Test Set這個(gè)Level上來,不用寫多個(gè)用例,只是在測(cè)試計(jì)劃和執(zhí)行的管理系統(tǒng)中作為測(cè)試集的一個(gè)環(huán)境參數(shù),恰當(dāng)?shù)乇磉_(dá)出來就可以。
第四篇:手機(jī)測(cè)試經(jīng)驗(yàn)總結(jié)
手機(jī)測(cè)試經(jīng)驗(yàn)總結(jié)
VPM主要是激勵(lì)團(tuán)隊(duì)成員測(cè)試和學(xué)習(xí),而不是自己去執(zhí)行用例。當(dāng)被委派為一個(gè)項(xiàng)目的測(cè)試經(jīng)理時(shí),VPM應(yīng)該清楚項(xiàng)目計(jì)劃和轉(zhuǎn)折點(diǎn)、軟件發(fā)布時(shí)間表、產(chǎn)品定義特征列表。
1、作為VPM應(yīng)具備以下幾方面能力:
(1)、用不同的方式看待問題
(2)、制定計(jì)劃,滿足項(xiàng)目上市時(shí)間
(3)、依據(jù)質(zhì)量、時(shí)間、成本對(duì)PR進(jìn)行判斷和決定
(4)、增進(jìn)溝通,總結(jié)不同項(xiàng)目的經(jīng)驗(yàn)
(5)、和團(tuán)隊(duì)的密切合作
2、測(cè)試工作點(diǎn):
(1)、測(cè)試軟件機(jī)制
(2)、分析問題
(3)、對(duì)產(chǎn)品進(jìn)行認(rèn)證并得到相應(yīng)證書
(4)、評(píng)估對(duì)于返修率、最終用戶和運(yùn)營(yíng)商抱怨的影響
若做歐洲市場(chǎng)的產(chǎn)品,一定要做CE認(rèn)證。FCC認(rèn)證在Latam市場(chǎng)是必須的,CTA認(rèn)證在中國(guó)是必須的。
一、相關(guān)測(cè)試知識(shí)學(xué)習(xí)
1、軟件測(cè)試包括測(cè)試計(jì)劃、測(cè)試設(shè)計(jì)、測(cè)試執(zhí)行、測(cè)試評(píng)估這幾個(gè)階段;
測(cè)試計(jì)劃:
了解軟件當(dāng)前狀態(tài)及客戶對(duì)軟件的需求;
了解產(chǎn)品規(guī)格書:按鍵定義及菜單樹;
管控和跟催軟件方案商的版本發(fā)布時(shí)間;
測(cè)試設(shè)計(jì):根據(jù)客戶需求和產(chǎn)品規(guī)格說明書來編寫測(cè)試用例;
測(cè)試執(zhí)行:測(cè)試策略包括基本功能測(cè)試、UI測(cè)試、沖突測(cè)試、壓力測(cè)試、兼容性測(cè)試、驗(yàn)收測(cè)試
測(cè)試評(píng)估:進(jìn)行三次全面測(cè)試,由方案商發(fā)出軟件和報(bào)告,TMC和SZ Team
同時(shí)測(cè)試并反饋給方案商,如此反復(fù)數(shù)次,方案商改善結(jié)果并商討最終結(jié)論。
2、場(chǎng)測(cè)
在硬件成熟、軟件基本成熟的情況下做場(chǎng)地測(cè)試,主要測(cè)試這幾項(xiàng):尋網(wǎng)時(shí)間、呼通率數(shù)據(jù)、通話質(zhì)量、Wap測(cè)試、FM測(cè)試、信息、緊急呼叫、基本功能測(cè)試。
3、說明書測(cè)試
驗(yàn)證說明書基本功能是否正確,是否清晰易懂、排版規(guī)范、無錯(cuò)別字等。
4、認(rèn)證分類
按照銷售地區(qū)分為國(guó)內(nèi)認(rèn)證和國(guó)外認(rèn)證,國(guó)內(nèi)認(rèn)證是CTA認(rèn)證,國(guó)外認(rèn)證是CE認(rèn)證和FCC認(rèn)證。CTA認(rèn)證需要拿到國(guó)家無委頒發(fā)的入網(wǎng)證書、受理中心頒發(fā)的許可證書、3C認(rèn)證頒發(fā)的3C證書。
第五篇:軟件測(cè)試經(jīng)驗(yàn)總結(jié)
軟件生命周期(SDLC)的六個(gè)階段
1、問題的定義及規(guī)劃
此階段是軟件開發(fā)方與需求方共同討論,主要確定軟件的開發(fā)目標(biāo)及其可行性。
2、需求分析
在確定軟件開發(fā)可行的情況下,對(duì)軟件需要實(shí)現(xiàn)的各個(gè)功能進(jìn)行詳細(xì)分析。需求分析階段是一個(gè)很重要的階段,這一階段做得好,將為整個(gè)軟件開發(fā)項(xiàng)目的成功打下良好的基礎(chǔ)?!拔ㄒ徊蛔兊氖亲兓旧??!?,同樣需求也是在整個(gè)軟件開發(fā)過程中不斷變化和深入的,因此我們必須制定需求變更計(jì)劃來應(yīng)付這種變化,以保護(hù)整個(gè)項(xiàng)目的順利進(jìn)行。
3、軟件設(shè)計(jì)
此階段主要根據(jù)需求分析的結(jié)果,對(duì)整個(gè)軟件系統(tǒng)進(jìn)行設(shè)計(jì),如系統(tǒng)框架設(shè)計(jì),數(shù)據(jù)庫設(shè)計(jì)等等。軟件設(shè)計(jì)一般分為總體設(shè)計(jì)和詳細(xì)設(shè)計(jì)。好的軟件設(shè)計(jì)將為軟件程序編寫打下良好的基礎(chǔ)。
4、程序編碼
此階段是將軟件設(shè)計(jì)的結(jié)果轉(zhuǎn)換成計(jì)算機(jī)可運(yùn)行的程序代碼。在程序編碼中必須要制定統(tǒng)一,符合標(biāo)準(zhǔn)的編寫規(guī)范。以保證程序的可讀性,易維護(hù)性,提高程序的運(yùn)行效率。
5、軟件測(cè)試
在軟件設(shè)計(jì)完成后要經(jīng)過嚴(yán)密的測(cè)試,以發(fā)現(xiàn)軟件在整個(gè)設(shè)計(jì)過程中存在的問題并加以糾正。整個(gè)測(cè)試過程分單元測(cè)試、組裝測(cè)試以及系統(tǒng)測(cè)試三個(gè)階段進(jìn)行。測(cè)試的方法主要有白盒測(cè)試和黑盒測(cè)試兩種。在測(cè)試過程中需要建立詳細(xì)的測(cè)試計(jì)劃并嚴(yán)格按照測(cè)試計(jì)劃進(jìn)行測(cè)試,以減少測(cè)試的隨意性。
6、運(yùn)行維護(hù)
軟件維護(hù)是軟件生命周期中持續(xù)時(shí)間最長(zhǎng)的階段。在軟件開發(fā)完成并投入使用后,由于多方面的原因,軟件不能繼續(xù)適應(yīng)用戶的要求。要延續(xù)軟件的使用壽命,就必須對(duì)軟件進(jìn)行維護(hù)。軟件的維護(hù)包括糾錯(cuò)性維護(hù)和改進(jìn)性維護(hù)兩個(gè)方面。
2、軟件生命周期模型
從概念提出的那一刻開始,軟件產(chǎn)品就進(jìn)入了軟件生命周期。在經(jīng)歷需求、分析、設(shè)計(jì)、實(shí)現(xiàn)、部署后,軟件將被使用并進(jìn)入維護(hù)階段,直到最后由于缺少維護(hù)費(fèi)用而逐漸消亡。這樣的一個(gè)過程,稱為“生命周期模型”(Life Cycle Model)。
典型的幾種生命周期模型包括瀑布模型、快速原型模型、迭代模型。
瀑布模型的特點(diǎn)(文檔是主體),很多的問題在最后才會(huì)暴露出來。迭代模型比瀑布模型問題暴露的要早;快速原型法比瀑布模型直觀。
3.軟件測(cè)試概念
廣義概念:指軟件生存周期中所有的檢查、評(píng)審和確認(rèn)工作,其中包括了對(duì)分析、設(shè)計(jì)階段,以及完成開發(fā)后維護(hù)階段的各類文檔、代碼的審查和確認(rèn)
狹義概念:識(shí)別軟件缺陷的過程,即實(shí)際結(jié)果與預(yù)期結(jié)果的不一致
4.軟件測(cè)試目的測(cè)試的目的就是發(fā)現(xiàn)軟件中的各種缺陷
測(cè)試只能證明軟件存在缺陷,不能證明軟件不存在缺陷
測(cè)試可以使軟件中缺陷降低到一定程度,而不是徹底消滅
以較少的用例、時(shí)間和人力找出軟件中的各種錯(cuò)誤和缺陷,以確保軟件的質(zhì)量
5.軟件測(cè)試原則
Good-enough: 一種權(quán)衡投入/產(chǎn)出比的原則
保證測(cè)試的覆蓋程度,但窮舉測(cè)試是不可能的所有的測(cè)試都應(yīng)追溯到用戶需求
越早測(cè)試越好,測(cè)試過程與開發(fā)過程應(yīng)是相結(jié)合的測(cè)試的規(guī)模由小而大,從單元測(cè)試到系統(tǒng)測(cè)試
為了盡可能地發(fā)現(xiàn)錯(cuò)誤,應(yīng)該由獨(dú)立的第三方來測(cè)試
不能為了便于測(cè)試擅自修改程序
既應(yīng)該測(cè)試軟件該做什么也應(yīng)該測(cè)試軟件不該做什么
6.軟件測(cè)試的的重點(diǎn)
測(cè)試用例的設(shè)計(jì)
測(cè)試用例的設(shè)計(jì)是整個(gè)軟件測(cè)試工作的核心
測(cè)試用例反映對(duì)被測(cè)對(duì)象的質(zhì)量要求,決定對(duì)測(cè)試對(duì)象的質(zhì)量評(píng)估
測(cè)試工作的管理
尤其是對(duì)包含多個(gè)子系統(tǒng)的大型軟件系統(tǒng),其測(cè)試工作涉及大量人力和物力,有效的測(cè)試工作管理是保證有效測(cè)試工作的必要前提
測(cè)試環(huán)境的建立
測(cè)試環(huán)境應(yīng)該與實(shí)際測(cè)試環(huán)境一致
7.黑盒測(cè)試
什么是黑盒測(cè)試
又稱功能測(cè)試或數(shù)據(jù)驅(qū)動(dòng)測(cè)試,是針對(duì)軟件的功能需求/實(shí)現(xiàn)進(jìn)行測(cè)試,通過測(cè)試來檢測(cè)每個(gè)功能是否符合需求,不考慮程序內(nèi)部的邏輯結(jié)構(gòu)
黑盒測(cè)試方法
功能劃分
等價(jià)類劃分
邊界值分析
因果圖
錯(cuò)誤推測(cè)等
8.什么是白盒測(cè)試
白盒測(cè)試也稱結(jié)構(gòu)測(cè)試或邏輯驅(qū)動(dòng)測(cè)試,必須知道軟件內(nèi)部工作過程,通過測(cè)試來檢測(cè)軟件內(nèi)部是否按照需求、設(shè)計(jì)正常運(yùn)行
白盒測(cè)試的主要方法
對(duì)應(yīng)于程序的一些主要結(jié)構(gòu):語句、分支、邏輯路徑、變量;白盒測(cè)試的主要方法是: 語句覆蓋方法
分支覆蓋方法
邏輯覆蓋方法
什么是動(dòng)態(tài)測(cè)試
動(dòng)態(tài)測(cè)試需要在開發(fā)/測(cè)試環(huán)境或?qū)嶋H運(yùn)行環(huán)境中運(yùn)行軟件,并使用測(cè)試用例去查找軟件缺陷;動(dòng)態(tài)測(cè)試包括功能確認(rèn)與接口測(cè)試、覆蓋率分析、性能分析、內(nèi)存分析等
10.什么是靜態(tài)測(cè)試
靜態(tài)測(cè)試不實(shí)際運(yùn)行軟件,主要是對(duì)軟件的編程格式、結(jié)構(gòu)等方面進(jìn)行評(píng)估.靜態(tài)測(cè)試包括代碼檢查、程序結(jié)構(gòu)分析、代碼質(zhì)量度量等。它可以由人工進(jìn)行,也可以借助軟件工具自動(dòng)進(jìn)行
11.手工測(cè)試和自動(dòng)測(cè)試
a.手工測(cè)試缺點(diǎn)在于測(cè)試工作量大,重復(fù)多,回歸測(cè)試難以實(shí)現(xiàn)
b.自動(dòng)測(cè)試?yán)密浖y(cè)試工具自動(dòng)實(shí)現(xiàn)全部或部分測(cè)試工作:管理、設(shè)計(jì)、執(zhí)行和報(bào)告;節(jié)省大量的測(cè)試開銷,并能夠完成一些手工測(cè)試無法實(shí)現(xiàn)的測(cè)試
手工完成測(cè)試的全部過程無法保證測(cè)試的科學(xué)性與嚴(yán)密性:
修改的缺陷越多,回歸測(cè)試越困難
沒有人能向決策層提供精確的數(shù)據(jù)以度量當(dāng)前的工作進(jìn)度及工作效率
反復(fù)測(cè)試帶來的倦怠情緒及其他人為因素使得測(cè)試標(biāo)準(zhǔn)前后不一
測(cè)試花費(fèi)的時(shí)間越長(zhǎng),測(cè)試的嚴(yán)格性也就越低
自動(dòng)測(cè)試將測(cè)試人員從反復(fù)、煩雜的測(cè)試執(zhí)行中解放出來,用更多的時(shí)間進(jìn)行測(cè)試設(shè)計(jì)和結(jié)果分析
軟件測(cè)試不可能完全自動(dòng)化
不能完成所有手工測(cè)試任務(wù)
無創(chuàng)造性且靈活性差,不能改進(jìn)測(cè)試的有效性
過程中可能會(huì)遇到許多意想不到的問題,特別是當(dāng)軟件不穩(wěn)定時(shí)
測(cè)試腳本的維護(hù)高
12.測(cè)試流程
單元測(cè)試
集成測(cè)試
系統(tǒng)測(cè)試
用戶驗(yàn)收測(cè)試
回歸測(cè)試
確認(rèn)測(cè)試報(bào)告
13.單元測(cè)試
完成對(duì)最小的軟件設(shè)計(jì)單元—模塊的驗(yàn)證工作
目標(biāo)是確保模塊被正確地編碼
使用過程設(shè)計(jì)描述作為指南,對(duì)重要的控制路徑進(jìn)行測(cè)試以發(fā)現(xiàn)模塊內(nèi)的錯(cuò)誤
通常情況下是面向白盒的對(duì)代碼風(fēng)格和規(guī)則、程序設(shè)計(jì)和結(jié)構(gòu)、業(yè)務(wù)邏輯等進(jìn)行靜態(tài)測(cè)試,及早地發(fā)現(xiàn)和解決不易顯現(xiàn)的錯(cuò)誤
單元測(cè)試的內(nèi)容
接口測(cè)試
內(nèi)部數(shù)據(jù)結(jié)構(gòu)
全局?jǐn)?shù)據(jù)結(jié)構(gòu)
邊界
語句覆蓋,錯(cuò)誤路徑
14.集成測(cè)試
通過測(cè)試發(fā)現(xiàn)與模塊接口有關(guān)的問題
目標(biāo)是把通過了單元測(cè)試的模塊拿來,構(gòu)造一個(gè)在設(shè)計(jì)中所描述的程序結(jié)構(gòu)
應(yīng)當(dāng)避免一次性的集成(除非軟件規(guī)模很小),而采用增量集成集成測(cè)試主要內(nèi)容
API(Application Programming Interface,應(yīng)用程序編程接口)
API/參數(shù)組合15.系統(tǒng)測(cè)試
根據(jù)軟件需求規(guī)范的要求進(jìn)行系統(tǒng)測(cè)試,確認(rèn)系統(tǒng)滿足需求的要求
系統(tǒng)測(cè)試人員相當(dāng)于用戶代言人
在需求分析階段要確定軟件的可測(cè)性,保證有效完成系統(tǒng)測(cè)試工作
系統(tǒng)測(cè)試主要內(nèi)容
所有功能需求得到滿足
所有性能需求得到滿足
其他需求(例如安全性、容錯(cuò)性、兼容性等)得到滿足
16.用戶驗(yàn)收/確認(rèn)測(cè)試
Alpha測(cè)試
是由用戶在開發(fā)者的場(chǎng)所來進(jìn)行的,Alpha測(cè)試是在一個(gè)受控的環(huán)境中進(jìn)行的Beta測(cè)試
由軟件的最終用戶在一個(gè)或多個(gè)用戶場(chǎng)所來進(jìn)行的,開發(fā)者通常不在現(xiàn)場(chǎng),用戶記錄測(cè)試中遇到的問題并報(bào)告給開發(fā)者
17.壓力測(cè)試VS性能測(cè)試
性能測(cè)試的目的不是去找bugs,而是排除系統(tǒng)的瓶頸,以及為以后的回歸測(cè)試建立一個(gè)基準(zhǔn)。而性能測(cè)試的操作,實(shí)際上就是一個(gè)非常小心受控的測(cè)量分析過程。在理想的情況下,被測(cè)軟件在這個(gè)時(shí)候已經(jīng)是足夠穩(wěn)定了
性能測(cè)試是為了檢查系統(tǒng)的反映,運(yùn)行速度等性能指標(biāo),他的前提是要求在一定負(fù)載下,如檢查一個(gè)網(wǎng)站在100人同時(shí)在線的情況下的性能指標(biāo),每個(gè)用戶是否都還可以正常的完成操作等。
概括就是:在不同負(fù)載下(負(fù)載一定)時(shí),通過一些系統(tǒng)參數(shù)(如反應(yīng)時(shí)間等)檢查系統(tǒng)的運(yùn)行情況;
壓力測(cè)試是為了發(fā)現(xiàn)系統(tǒng)能支持的最大負(fù)載,他的前提是要求系統(tǒng)性能處在可以接受的范圍內(nèi),比如經(jīng)常規(guī)定的葉面3秒鐘內(nèi)響應(yīng);概括就是:在性能可以接受的前提下,測(cè)試系統(tǒng)可以支持的最大負(fù)載。
舉例說明:針對(duì)一個(gè)網(wǎng)站進(jìn)行測(cè)試,模擬10到50個(gè)用戶就是在進(jìn)行常規(guī)性能測(cè)試,用戶增加到1000乃至上萬就變成了壓力/負(fù)載測(cè)試。如果同時(shí)對(duì)系統(tǒng)進(jìn)行大量的數(shù)據(jù)查詢操作,就包含了強(qiáng)度測(cè)試。
18.主流測(cè)試工具的測(cè)試流程
========winrunner啟動(dòng)時(shí)選擇要加載的插件進(jìn)行一些設(shè)置(如錄制模式等)識(shí)別應(yīng)用程序的GUI,即創(chuàng)建map(就是學(xué)習(xí)被測(cè)試軟件的界面)建立測(cè)試腳本(錄制及編寫)對(duì)腳本除錯(cuò)及調(diào)試(保證能夠運(yùn)行完)插入各種檢查點(diǎn)(圖片,文字,控件等)在新版應(yīng)用程序中執(zhí)行測(cè)試腳本分析結(jié)果,回報(bào)缺陷
=========quicktestpro========準(zhǔn)備錄制
打開你要對(duì)其進(jìn)行測(cè)試的應(yīng)用程序,并檢查QuickTest中的各項(xiàng)設(shè)置是否適合當(dāng)前的要求。2 進(jìn)行錄制
打開QuickTest的錄制功能,按測(cè)試用例中的描述,操作被測(cè)試應(yīng)用程序。編輯測(cè)試腳本
通過加入檢測(cè)點(diǎn)、參數(shù)化測(cè)試,以及添加分支、循環(huán)等控制語句,來增強(qiáng)測(cè)試腳本的功能,使將來的回歸測(cè)試真正能夠自動(dòng)化。調(diào)試腳本
調(diào)試腳本,檢查腳本是否存在錯(cuò)誤。在回歸測(cè)試中運(yùn)行測(cè)試
在對(duì)應(yīng)用程序的回歸測(cè)試中,通過QuickTest回放對(duì)應(yīng)用程序的操作,檢驗(yàn)軟件正確性,實(shí)現(xiàn)測(cè)試的自動(dòng)化進(jìn)行。分析結(jié)果,報(bào)告問題
查看QuickTest記錄的運(yùn)行結(jié)果,記錄問題,報(bào)告測(cè)試結(jié)果。
====TestDirect============
安裝好后,先進(jìn)入站點(diǎn)管理創(chuàng)建域及工程添加用戶編輯licenses及本服務(wù)器編輯數(shù)據(jù)庫
--TD選擇新建的工程進(jìn)行定制(列表,用戶,組,版本等)在require中增加需求把需求轉(zhuǎn)化為plan在testlab中由計(jì)劃新建測(cè)試具體用例與執(zhí)行發(fā)現(xiàn)bug,在defect中提交bug
(每一部分都可以相對(duì)獨(dú)立地使用)
======loadrunner制定負(fù)載測(cè)試計(jì)劃
(分析應(yīng)用程序,確定測(cè)試目標(biāo),計(jì)劃怎樣執(zhí)行LoadRunner)開發(fā)測(cè)試腳本
(錄制基本的用戶腳本,完善測(cè)試腳本)創(chuàng)建運(yùn)行場(chǎng)景
(選擇場(chǎng)景類型為Manual Scenario,選擇場(chǎng)景類型,理解各種類型,場(chǎng)景的類型轉(zhuǎn)化)監(jiān)視場(chǎng)景(MEMORY 相關(guān),PROCESSOR相關(guān),網(wǎng)絡(luò)吞量以及帶寬,磁盤相關(guān),WEB應(yīng)用程
序,IIS5.0,SQL SERVER,NETWORK DELAY等)
分析測(cè)試結(jié)果
7(分析實(shí)時(shí)監(jiān)視圖表,分析事務(wù)的響應(yīng)時(shí)間,分解頁面,確定WEBSERVER的問題,其他有
用的功能)