<meter id="pryje"><nav id="pryje"><delect id="pryje"></delect></nav></meter>
          <label id="pryje"></label>

          關(guān) 閉

          新聞中心

          EEPW首頁 > 工控自動化 > 設(shè)計應(yīng)用 > 軟件測試中對于測試計劃有效性問題的分析

          軟件測試中對于測試計劃有效性問題的分析

          作者: 時間:2011-12-20 來源:網(wǎng)絡(luò) 收藏

          近半年以來,我們部門大大小小的項目也做了不少。對于如何組織工作,各個組長/測試負(fù)責(zé)人都積極發(fā)揮著自己的主觀能動性,為提高測試質(zhì)量和測試效率而積極思考。

          本文引用地址:http://www.ex-cimer.com/article/202401.htm
          但是,唯一有個問題讓一些組織者絞盡腦汁,那就是:如何讓自己的工作能盡量小的偏離自己的預(yù)定計劃目標(biāo),從而提高自己測試計劃的有效性呢?對于這個問題,我有一點自己的想法,可供參考。
          由于測試計劃是一個測試項目必不可少的項目管理性文檔。它或簡單或復(fù)雜,其目 的都是為了讓項目能在預(yù)先計劃好的軌跡上運作,以盡量減少測試工作的過大投入,從而拉大投入成本與軟件利潤的比差,達(dá)到項目的最大收益。除了這個主要原因外,制定測試計劃還有一些附加原因,也就是:
          1)讓測試工作盡量的可視化和可控化。
          2)為更好的對測試團(tuán)隊的工作能力有更真實的考核(即,執(zhí)行者在預(yù)定的時間和環(huán)境下完成任務(wù)的能力和質(zhì)量)。
          3)為測試的過程改進(jìn)工作提供依據(jù)。
          4)軟件開發(fā)流程中必要的文檔。
          可見測試計劃的必要性。既然他是必要的,而且目的也說的很清楚了。那么我們不能把自己制定的測試計劃當(dāng)成一紙空文,而應(yīng)該把他更好的利用起來,以真正的體現(xiàn)它的價值所在。
          下面是我對如何提高其利用率的幾點建議:
          1、不要過渡的依賴于測試計劃模板。
          現(xiàn)狀:
          我們在拿到一個測試項目以后,我們一般的做法是:先看文檔;然后根據(jù)文檔系統(tǒng)功能;然后在要求的時間里就開始寫計劃了。寫測試計劃的過程是邊想邊寫,好像都不知道該寫些什么好。有的人就干脆把其他項目的測試計劃拿來,修改一下進(jìn)度表和人員表,增刪一些測試方法等就完了事。我們做測試計劃的目的幾乎就成了應(yīng)付檢查,不在于使用。
          建議:
          我們通過需求和系統(tǒng)功能,我們就應(yīng)該對如何計劃測試工作胸有成竹了。制定測試計劃,我們必須先要做好以下幾件事情(那是我們制定計劃的時候所必須的東西):
          a)確定測試范圍。
          b)根據(jù)測試項目的工作強(qiáng)度和難度來組織測試人員。
          c)根據(jù)項目所提供的各項數(shù)據(jù)以及成員能力,評估風(fēng)險,時間和資源消耗。
          d)根據(jù)質(zhì)量保證計劃以及項目所提供的數(shù)據(jù)資料,確定可行的測試方案(必要的話,還需對測試方案的可行性和風(fēng)險性進(jìn)行審查,使實施的風(fēng)險可控化。)
          e)在預(yù)計的測試時間段里,根據(jù)制定的測試方案確定時間進(jìn)度。
          f)測試過程中,對測試版本的控制(大型的項目,應(yīng)該考慮附加《配制計劃》)
          當(dāng)我們把這些事情做好后,我們就可以正式的擬定測試計劃文檔了。在計劃文檔中寫清楚測試的對象、范圍,測試的時間、進(jìn)度,測試所需要的人力和物力,測試方案說明,測試工作的各項標(biāo)準(zhǔn)定義,測試的風(fēng)險評估以及預(yù)防措施等。
          尤其在確定時間的進(jìn)度時,最好不要把時間剛好排滿,要在時間的后期留有一個緩沖時間段,以應(yīng)對意外突發(fā)事件。
            
          2、重把測試計劃的審核關(guān)。
          現(xiàn)狀:
          一個測試計劃文檔生成后,還不能算是完成計劃工作了,還必須對計劃進(jìn)行評審,將其合法化。那么我們公司的評審者到底評審些什么呢?他們拿到要評審的計劃書,就主要關(guān)注一下文檔的書寫結(jié)構(gòu)(看目錄),再看看進(jìn)度安排和實施方案,但就是不提出該實施方案在這個預(yù)定的進(jìn)度中能否可行,以及風(fēng)險評估是否合理,可能在他們的評審檢查項里就缺少“對計劃可信性和可行性的檢查”以及“計劃方案實施的風(fēng)險性”的考慮。
          建議:
          計劃是拿來實施的,不是拿來當(dāng)擺設(shè)的。計劃是否可行,是否行之有效,實施的風(fēng)險是否可控制等等問題是我們在檢查的時候必須考慮的。如果我們只是在文檔字面上去檢查那些文字錯誤的東西,是否太不負(fù)責(zé)任了呢?試問,如果在通過這樣的計劃評審后,在實施中,遇到風(fēng)險過大等諸多問題,這個責(zé)任是誰來擔(dān)呢?
          所以我們檢查計劃,字面錯誤這種不痛不癢的問題幾乎可以忽略它,這個計劃能不能用才是關(guān)鍵。所以,我們應(yīng)該主要檢查:
          1)我們測試的對象是什么?
          2)在什么環(huán)境下實施我們的測試工作?
          3)我們的測試所要花費的時間、經(jīng)費和資源(最好還是不要超出預(yù)算的為好,不然可能老板不支持我們的工作,反倒是個麻煩了!嘿嘿)?
          4)制定的實施方案是否可行性?
          5)制定的實施方案所擔(dān)當(dāng)?shù)娘L(fēng)險系數(shù)有多高?
          6)是否還有更好的可降低風(fēng)險的實施方案?
          7)我們的測試工作以什么樣的來衡量我們的工作成績?(甚至是對工作的獎懲辦法等)
          8)是否有對于工作風(fēng)險的控制方案。
          9)工作中,任務(wù)交代的是否夠清楚?以免讓執(zhí)行者隨意瞎搞,導(dǎo)致對其測試工作不可控。
          10)項目成員對這個要測試的對象的理解程度有多深?
            
          11)測試人員的組織和管理方案是否可靠?
          3、測試計劃不是一紙空文。
          現(xiàn)狀:
          一個很讓人懷疑其可行性的測試計劃通過之后,下一步工作就是把它放到共享服務(wù)器上,供項目管理部檢查,最后——結(jié)束了。直到項目結(jié)項的時候,才把這個都快“發(fā)霉”的計劃文檔翻出來,準(zhǔn)備結(jié)項工作。而且對于計劃中沒有完成的任務(wù)也不怎么提(因為大家都在擔(dān)心一個問題:如果提出來,結(jié)不了項,怎么辦?)。因為我們似乎都是很盡職的在發(fā)揚“揚長避短”的“優(yōu)良”作風(fēng)。
          建議:
          QA人員必須嚴(yán)格按制定的計劃進(jìn)行過程檢查工作。一旦發(fā)現(xiàn)實施的計劃與預(yù)定的計劃有出入。應(yīng)及時通報相關(guān)人員,了解其偏離計劃的原因,盡快處理好計劃實施不到位的問題。
          4、實行計劃跟蹤。
          現(xiàn)狀:
          計劃中編寫的時間進(jìn)度表,在真正的實施中是很少用的。每個時間段里要生成什么工作成果,要評審什么文檔,項目管理部似乎也在關(guān)心。但他們似乎只關(guān)心成果數(shù)量,而工作成果質(zhì)量工作似乎被項目管理工作所取代了(QA被項目部同化了)。試問,一個項目真正是想要十幾個甚至更多的沒有實際意義的文檔,還是要一個高質(zhì)量的可使用的文檔呢?對于這個問題,似乎走入了一個面子工程的地步(過程進(jìn)行的風(fēng)風(fēng)火火,結(jié)果是一塌糊涂)。比如:在評審各項工作成果的時候,只檢查字面的東西,而對于這個工作成果到底是不是這個項目的工作成果他們也不怎么懷疑?難怪很多項目文檔描述的東西和實際開發(fā)出來的東西對不上號呢!(如:SRM系統(tǒng))
          建議:
          對于在計劃中提到的各階段必須生成的工作成果是否存在的問題,項目管理部也必須嚴(yán)格監(jiān)督。而最重要的工作成果質(zhì)量問題,應(yīng)該由QA人員組織評審人員進(jìn)行評審。如果工作成果評審未通過,堅決不能啟動下一階段的工作(但如果時間不充裕的話,為了不耽誤下一階段工作的如期進(jìn)行,可以提前準(zhǔn)備下階段的資料)。不能因為時間緊迫,而放寬對工作成果質(zhì)量的檢查。
          5、計劃變更,必須可控(如:變更的風(fēng)險性審查和變更通知等)。
          現(xiàn)狀:
          當(dāng)計劃實施過程中,需要變動計劃的時候,根本不走變更流程,直接由經(jīng)理修改了事。他們的理由是:走變更流程太麻煩,很浪費時間,怕拖延計劃進(jìn)度。如果項目順利完成到好,但如果項目出現(xiàn)任何閃失,那就在這個責(zé)任問題上,可能會激化各部門之間的矛盾。而且修改過的計劃即不通過評審,也不加以通知報告了,不知情的人還在努力的在原計劃中奮斗工作著呢!有可能導(dǎo)致項目就此失去項目管理部的控制(難怪項目管理部的項目管理控制工作是如此的困難)。
          建議:
          對計劃中的重大變動問題,必須向項目管理部提出變動申請。項目管理部必須對該申請進(jìn)行嚴(yán)格審核,考慮其變動的風(fēng)險性問題,而不能一有申請來,就通通的給通過了。通過審核的申請,就可以修改計劃了,計劃在做出相應(yīng)變動修改之后,必須進(jìn)行再次評審?fù)ㄟ^才可生效。再次評審?fù)ㄟ^后的計劃,必須及時替換原有計劃文件,并通知所有項目成員按新的計劃實施。
          6、定期在報告中匯報計劃執(zhí)行情況。
          現(xiàn)狀:
          在計劃實施過程中,執(zhí)行者們很少有自覺寫工作日志或階段工作報告的習(xí)慣。
          建議:
          在每個階段結(jié)束后,應(yīng)該向管理部門提交一份關(guān)于該階段的計劃任務(wù)完成情況的報告。管理部應(yīng)嚴(yán)格審查該階段的工作匯報,及時處理工作所遇到的問題,以避免問題在以下的階段中繼續(xù)擴(kuò)散或延續(xù)。
          7、當(dāng)計劃無法繼續(xù)實施時,及時通報相關(guān)人員(不能擅自自定義計劃)。
          現(xiàn)狀:
          在計劃實施過程中,遇到無法在現(xiàn)有的環(huán)境下繼續(xù)執(zhí)行計劃時,經(jīng)理開始想辦法另辟蹊徑了,從而放棄原方案,開辟一條新道路給大家走??赡苤钡浇Y(jié)項的那一天,項目管理部才發(fā)現(xiàn)我們實際所做的工作于我們的原計劃上有很大的出入。(難怪項目管理部對我們測試甚至整個項目的計劃實施管理控制上,像個局外人呢!)
          建議:
          在計劃實施過程中,遇到無法在現(xiàn)有的環(huán)境下繼續(xù)執(zhí)行計劃時,不能擅自調(diào)整計劃方案,應(yīng)該及時通報上級管理部門,以便及時處理計劃方案調(diào)整的問題。對于計劃方案的調(diào)整,必須通知其他相關(guān)人員,做好調(diào)整工作。加強(qiáng)各個部門的溝通。以免項目失控。
          以上是幾點關(guān)于測試計劃的實施有效性問題的微薄見解,希望以此引起相關(guān)人員/部門的重視,并做出更好的方案,以完善此方面的問題。而對于其中提到的各項審查的檢查項等問題的定義,在以后的工作中,再繼續(xù)加以完善。也希望公司的每個人都為了以后更好的做好項目而積極努力。


          關(guān)鍵詞: 軟件測試 測試 分析

          評論


          相關(guān)推薦

          技術(shù)專區(qū)

          關(guān)閉
          看屁屁www成人影院,亚洲人妻成人图片,亚洲精品成人午夜在线,日韩在线 欧美成人 (function(){ var bp = document.createElement('script'); var curProtocol = window.location.protocol.split(':')[0]; if (curProtocol === 'https') { bp.src = 'https://zz.bdstatic.com/linksubmit/push.js'; } else { bp.src = 'http://push.zhanzhang.baidu.com/push.js'; } var s = document.getElementsByTagName("script")[0]; s.parentNode.insertBefore(bp, s); })();