软件测试流程进阶----两年软件测试总结[转]
工作兩年了，我一直希望讓自己每年對測試的理解更深入一層。工作一年的時(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的搭建