软件测试流程进阶----两年软件测试总结[转]
工作兩年了,我一直希望讓自己每年對測試的理解更深入一層。工作一年的時(shí)候我寫了《談軟件測試---一年工作總結(jié)》 ,談輪了自己對各種測試的理解,這一年來,雖然對那些理概念的有所加強(qiáng),自我感覺沒有什么質(zhì)的變化。前些天聽我們公司的一位測試經(jīng)理講《敏捷測試》豁然開朗。他在學(xué)造飛機(jī),而我一直在學(xué)造飛機(jī)里的一個(gè)發(fā)動機(jī)。我從來沒想過,一個(gè)完整飛機(jī)的架構(gòu)應(yīng)該是怎樣的。
如果想讓測試在公司的項(xiàng)目中發(fā)揮出它最大的價(jià)值,并不是招兩個(gè)測試技術(shù)高手,或引入幾個(gè)測試技術(shù),而是測試技術(shù)對項(xiàng)目流程的***,以及測試流程的改進(jìn)與完善。雖然,當(dāng)然測試行業(yè)前景樂觀,許多中小企業(yè)也都在引入測試,但一百個(gè)公司就有一百種測試,每個(gè)公司對測試的看法不同,公司對測試的定位也不完全一樣。本人前后經(jīng)歷兩個(gè)公司,以自己的拙見淺談一下對測試流程的看法。
這幾天整理思路,回顧了前兩份測試工作的流程與架構(gòu)。
簡陋的測試流程 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
先說筆者入職的第一個(gè)家公司,筆者是第一個(gè)入職的專職測試人員,相信一兩個(gè)測試的公司還是不少的,入職后各種項(xiàng)目都在進(jìn)行當(dāng)中,上面給我的定位是并沒完全融入到項(xiàng)目中去。而通過指派任務(wù)的方式。
下面是簡陋的流程圖:
需求分析與架構(gòu)設(shè)計(jì):
我們做的是某一移動公司內(nèi)部使用的項(xiàng)目,需求分析與架構(gòu)全部由項(xiàng)目經(jīng)理完成,之后由項(xiàng)目經(jīng)理給具體某個(gè)開發(fā)人員分配任務(wù),具體對某個(gè)功能模塊的實(shí)現(xiàn)。這個(gè)對項(xiàng)目經(jīng)理的經(jīng)驗(yàn)與技術(shù)要求很高,他既然擔(dān)任了需求分析師,又擔(dān)任架構(gòu)師的角色。
程序員編碼:
因?yàn)槲覀冮_發(fā)語言用的是JAVA 語言,IDE用myeclipse 中自帶的CVS版本管理工具,開發(fā)人員完成代碼后,提交到版本庫中。
測試:
筆者入職后的第一個(gè)任務(wù)是搭建缺陷管理工具,禪道項(xiàng)目管理,通過推廣對發(fā)現(xiàn)的問題進(jìn)行跟蹤。后來正明效果并不好,因?yàn)閷τ谝粋€(gè)六七人的開發(fā)團(tuán)隊(duì)項(xiàng)目,開發(fā)人員更喜歡測試人員能當(dāng)面反饋,這樣更能提高效率。對一個(gè)小bug 通過當(dāng)面交流的方式就可以將問題修復(fù)。
對于當(dāng)時(shí)的環(huán)境,并沒有測試線。開發(fā)人員在本機(jī)上將項(xiàng)目進(jìn)行部署運(yùn)行。測試人員通過局域網(wǎng)訪問開發(fā)人員的機(jī)子進(jìn)行訪問。或在測試人員本機(jī)上進(jìn)行部署測試。這也是一個(gè)致命的缺點(diǎn)。因?yàn)殚_發(fā)人員測試人員使用的電腦存在太多不穩(wěn)定性,這些都會造成問題的出現(xiàn),有時(shí)候難以判定是系統(tǒng)問題還是環(huán)境問題。
上線:
經(jīng)過測試人員測試通過后,開發(fā)人員部署上線。
A程序員流程
你會發(fā)現(xiàn)在流程圖中,A程序員是先發(fā)上線之后,再進(jìn)行測試。這是我們一個(gè)面向大眾用戶的網(wǎng)站,上面給于測試人員的定位是測試員兼用戶體驗(yàn)員,測試員將發(fā)現(xiàn)的bug和體驗(yàn)問題提交到缺陷管理系統(tǒng),由經(jīng)理對問題進(jìn)行分析,指派開發(fā)人員解決。定期對系統(tǒng)進(jìn)行更新。
流程分析:
這個(gè)流程唯一的優(yōu)點(diǎn),就是能快速的發(fā)現(xiàn)并修復(fù)問題。
缺點(diǎn)就非常多了,相信許多小軟件公司也有類似的流程。
這個(gè)流程中,項(xiàng)目經(jīng)理是核心,項(xiàng)目經(jīng)理也確實(shí)是有多年開發(fā)與項(xiàng)目經(jīng)驗(yàn)的牛人,他喜歡不定期分享上些前沿的技術(shù)。我很崇拜他。
對于測試來說,需求很不明確,測試文檔與用例也是可有可無的產(chǎn)物,沒有需求文檔,或非常簡陋,根據(jù)需求文檔根本無法編寫用例。筆者只能收集一些通用的測試用例,如登錄、文件上傳下載、列表翻頁、日期選擇、輸入框驗(yàn)證、搜索等有一些“通用型”用例,以便在測試過程中做參考。功能測試的多了,拿到一個(gè)功能,測試思路也就出來了。
規(guī)范的測試流程 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
放棄上份悠閑的工作,感謝那個(gè)帶我入行公司,我想了解真正的測試在公作中如何進(jìn)行的。所以,來到了現(xiàn)在這家公司。我很欣喜的是這測試有自己的團(tuán)隊(duì),專業(yè)(對當(dāng)時(shí)的我來說)的流程,以及與開發(fā)等同的地位。
現(xiàn)在的測試流程:
需求分析:
需求分析由產(chǎn)品人員制定,他們要做的不是一份簡單的文檔,而是細(xì)化每一個(gè)功能的細(xì)節(jié),每一個(gè)按鈕的位置,對于稍大或復(fù)雜一點(diǎn)的需求都進(jìn)行建模。
需求評審:
這里會叫上所有參與項(xiàng)目人員進(jìn)行,開發(fā)人員、測試人員、QA人員。測試人員提出需求,開發(fā)人員考慮功能實(shí)現(xiàn)的方案與可行性、當(dāng)然開發(fā)負(fù)責(zé)也是要參與的。測試人員主要是對需求的理解提出疑問,以便才能根據(jù)需求寫用例。QA人員是最終對軟件質(zhì)量進(jìn)行驗(yàn)證的人,所以也需求了解需求
開發(fā)人員編寫排期:
開發(fā)人員需求根據(jù)需求功能點(diǎn)進(jìn)行排期。然后將開計(jì)劃轉(zhuǎn)交給測試人員。
測試計(jì)劃排期:
測試人員根據(jù)開發(fā)計(jì)劃,對測試具體測試時(shí)間,也就是開發(fā)功能完成后的時(shí)間,進(jìn)行幾輪測試等。然后,把項(xiàng)目的開發(fā)與測試計(jì)劃發(fā)送給各部門負(fù)責(zé)人及參與項(xiàng)目的所有人員。
編寫測試用例:
? ? 根據(jù)詳細(xì)的需求分檔,開始進(jìn)行用例的編寫。
用例評審:
? ? ?在用例進(jìn)行評審之間,先以郵件形式將用例發(fā)送給相關(guān)人員,以便他們事先了解用例對哪些功能進(jìn)行驗(yàn)證以及驗(yàn)證的細(xì)節(jié)。
然后,測試人員組進(jìn)行用例評審,開發(fā)人員對用例與實(shí)際功能不符合有哪些,產(chǎn)品人員對會通過用例對功能的具體實(shí)現(xiàn)進(jìn)行把握等等。
提交基線:
? ?開發(fā)人員完成所有功能后,會對自己的功能進(jìn)行一個(gè)自測。自測完成后提交測試人員進(jìn)行基線。
具體測試流程:
? ? ?開發(fā)人員對于基到測試線的功能進(jìn)行測式,發(fā)現(xiàn)的問題通過缺陷管理工具進(jìn)行反饋,開發(fā)人員對問題進(jìn)行修復(fù),然后,準(zhǔn)備第二輪基。
測試人員完成第一輪測試后,需要寫測試結(jié)論,發(fā)到相關(guān)人員。然后對基線后的第二輪進(jìn)行測試,第二輪會對第一輪中發(fā)現(xiàn)的問題進(jìn)行重點(diǎn)回歸。
測試通過:
經(jīng)過兩到三輪或四輪的測試后,直到?jīng)]發(fā)現(xiàn)新的問題,或暫時(shí)無法解決,或不緊急的問題。通過上級確認(rèn),可以通過。編寫測試報(bào)告與驗(yàn)收方案。
驗(yàn)收方案是交由QA進(jìn)行驗(yàn)證的。在現(xiàn)公司的流程中是將測試與QA分開的,測試人員重點(diǎn)關(guān)注的是功能是否可以正常運(yùn)行。QA關(guān)注的是整個(gè)流程的質(zhì)量以及最終用戶的質(zhì)量。有些公司QA與測試是不區(qū)分的,但這對測試的要求會更高,除了關(guān)心功能,還需要關(guān)心整體流程與質(zhì)量。
流程分析:
對于剛接觸這個(gè)流程的我來說,這個(gè)流程是規(guī)范的,測試真正融入了整個(gè)流程,而且還擔(dān)任了很重的角色,從而也有效的保證了軟件產(chǎn)品的整體質(zhì)量。
那么這個(gè)流程是不是完美的呢?不,這個(gè)項(xiàng)目流程太強(qiáng)化各種文檔。我們來看測試的工作內(nèi)容,測試計(jì)劃、測試用例、測試結(jié)論、測試報(bào)告、驗(yàn)收方案、問題的提交跟蹤。其實(shí),我們真用于測試的時(shí)間是非常少的,在一周的時(shí)間,也許只有一天或不到一天的時(shí)間是在進(jìn)行測試的。測試人員只有在測試的時(shí)候才會體現(xiàn)出他的價(jià)值。而大部分工作卻不能體現(xiàn)他的價(jià)值。
當(dāng)然,我這里會省略與測試主流程無關(guān)的東西,真正的測試工作中瑣事很多。
敏捷測試流程 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
下面來看敏捷測試,本人并沒有接觸過敏捷,對敏捷也沒花時(shí)間學(xué)習(xí)與研究。唯一接觸就是聽我們測試經(jīng)理對測度流程講了兩個(gè)半小時(shí),聽講的人很多,我站著聽的。受益匪淺,憑著記憶也簡單談?wù)劇?
前面講的第一種流程,還是第二種流程都是瀑布式的,嚴(yán)格來說第一種簡陋的都不能稱為瀑布式,對于一個(gè)三個(gè)月的項(xiàng)目說,產(chǎn)品把需求分析完了給開發(fā),然后產(chǎn)品就沒事兒了;開發(fā)開發(fā)完成之后給測試,然后開發(fā)人員也不忙了。測試完成之后上線。那么在產(chǎn)品分析的階段,開發(fā)和測試都是沒事干的(這里只對單一項(xiàng)目)。開發(fā)階段,產(chǎn)品和測試也基本沒事兒。同樣在測試階段,產(chǎn)品與開發(fā)也是沒什么事兒的。
敏捷測試的一個(gè)核心是迭代,在每個(gè)時(shí)間點(diǎn)上,所有項(xiàng)目人員都是有事可做的。
1、下面是我理解中的敏捷測試流程圖:
第一階段:
通過上面的流程圖,對于一個(gè)月的需求分析,在敏捷中,可能三五天就確定下來。這個(gè)需求定得會很模糊,但整體框架確定。產(chǎn)品對其中某一模塊功能確認(rèn),開發(fā)人員開始對確認(rèn)的功能編碼,開發(fā)人員編碼的過程中,測試進(jìn)行功能分解,因?yàn)楦鶕?jù)模糊的需求很難寫出具體的用例,所以,只能盡量對功能進(jìn)行分析得細(xì)些,標(biāo)注需要驗(yàn)證的內(nèi)容。
第二階段:
開發(fā)完成后交給測試人員進(jìn)行測試,開發(fā)人員繼續(xù)開發(fā)新的功能。那么測試人員發(fā)現(xiàn)的問題怎么辦呢?會從開發(fā)團(tuán)隊(duì)中抽出一個(gè)人員來用于解決測試發(fā)現(xiàn)的問題。但開發(fā)進(jìn)度并沒有因?yàn)闇y試而停止。
流程分析:
在這個(gè)流程中弱化了文檔,強(qiáng)調(diào)了各個(gè)人員的溝通,通過這種迭代的方式,三個(gè)月的項(xiàng)目,可以能兩個(gè)月和兩個(gè)半月就會完成。
但這種流程并非完美,加入一個(gè)功能在需求分析階段就是錯(cuò)誤的,因?yàn)樗且粋€(gè)迭代漸進(jìn)的過程。也只能一路錯(cuò)下去。
2、對測試問題的處理
上面的圖更能清晰看出對問題的處理過程。
第一塊面板中是開發(fā)人員未實(shí)現(xiàn)的功能,第二塊面板中是開發(fā)完成功能,測試人員對其進(jìn)行測試,發(fā)現(xiàn)不通過的就放回未開發(fā)的面板中,測試通過的將放到第三塊面板中。
? ? ?需要說明的是,敏捷測試在國外很流程,在內(nèi)容,雷聲大雨點(diǎn)小,推行的人很多,真正有公司引入的不多。我們所在公司千差萬別,測試流程也可能有很大的不同。對于已經(jīng)工作兩年一個(gè)測試員來說,從來沒關(guān)注過測試流程與結(jié)構(gòu)應(yīng)該是個(gè)悲劇。我希望不被思想局限,所以,努力沖破一個(gè)又一個(gè)的局限。
轉(zhuǎn)載于:https://blog.51cto.com/ichrislee/1379488
總結(jié)
以上是生活随笔為你收集整理的软件测试流程进阶----两年软件测试总结[转]的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: Javascript PJAX 原理是什
- 下一篇: 分布式存储MooseFS的搭建