| 如何提高測試效率的一些看法 | |
| 作者：佚名 來(lái)源：中國自學(xué)編程網(wǎng)收集整理 發(fā)布日期：2008-11-14 | |
個(gè)人認為可以從軟件測試的活動(dòng)中的以下指標綜合考評，去評估衡量測試效率，每項指標都高，自然能夠說(shuō)明一些問(wèn)題： 1.發(fā)現缺陷的質(zhì)量： 同一個(gè)項目組內，我們一般運用測試管理工具TD, 按優(yōu)先級和嚴重等級，把每個(gè)人的缺陷做成柱狀圖和餅圖，放到一個(gè)文檔中，郵件發(fā)給大家，讓組內成員了解自己的工作情況和其他人的工作情況。同時(shí)也讓開(kāi)發(fā)人員，對每個(gè)測試人員的工作，做出評估，供績(jì)效考核時(shí)參考。特別是發(fā)現非常隱蔽缺陷的測試人員，一定要重賞。 2. 測試的有效性： 一般來(lái)說(shuō)，遞交Bug的有效性，體現了測試員是否能夠正確理解系統，并發(fā)現問(wèn)題，是否能夠發(fā)現有效的問(wèn)題。很多時(shí)候，測試人員沒(méi)有弄準確需求，或者是沒(méi)搞清楚設計，一旦出現異常，就提交Bug。不是和前面的缺陷相同，重復遞交相同類(lèi)型的缺陷，就是遞交無(wú)效的Bug，導致后來(lái)很多缺陷，都被項目評審時(shí)拒絕，既耽誤了時(shí)間，效率自然不高。 3.測試組員交叉測試，發(fā)現漏測問(wèn)題數量： 經(jīng)常是這樣，一個(gè)測試人員測試結束，修復了全部的缺陷。這個(gè)時(shí)候，測試的模塊和測試人員交叉一下，再測試，很有可能又發(fā)現很多問(wèn)題。這樣我們可以對測試發(fā)現問(wèn)題數量，進(jìn)行統計。這樣做，就迫使測試人員認真執行每一輪測試，每次測試都不敢懈怠。 4.遺漏到客戶(hù)缺陷的比例： 一旦版本測試通過(guò)，發(fā)布給客戶(hù)以后，客戶(hù)要對發(fā)布的版本進(jìn)行驗收測試。同樣會(huì )發(fā)現一些問(wèn)題，我們也會(huì )對測試過(guò)程中發(fā)現的Bug分配到每個(gè)模塊和具體的人。但是，如果缺陷在測試環(huán)境中不能重現，只能在實(shí)際工作環(huán)境中出現，則不屬于遺漏給客戶(hù)的Bug，不計入漏測統計里面。有時(shí)候，客戶(hù)系統在使用中也會(huì )發(fā)現缺陷，我們同樣做好記錄。 5.遞交的缺陷數量： 在同一個(gè)項目組內，每天遞交的Bug數量，每周遞交的Bug數量，每個(gè)版本測試結束，總共遞交的Bug數量。最終測試結束，算出每個(gè)人遞交有效缺陷的百分比。 6.執行用例的數量： 同一天，每個(gè)測試人員，執行用例的數量。但是一定要去除那些不能夠測試的功能模塊，或者是被阻塞的模塊，這些一定要考慮到。否則大家意見(jiàn)就大了呢！ 7.編寫(xiě)測試文檔的速度和質(zhì)量： 每次編寫(xiě)測試用例時(shí)，大家都要編寫(xiě)部分模塊的測試用例，我們也可以通過(guò)單位時(shí)間內編寫(xiě)case的數量、速度和質(zhì)量，來(lái)區分每個(gè)人的效率，我覺(jué)得也是一種好方法。 8.評審發(fā)現問(wèn)題的效率： 在組織部門(mén)內部的case評審時(shí)，同一個(gè)測試文檔的評審，如果提出的修改建議比較多，并且很有參考價(jià)值。這樣的測試人員，效率應該比較高，得考慮考慮加薪，呵呵。 9.測試工具使用的熟練程度： 當然，一個(gè)測試人員，對測試工具的熟練程度越高，使用技巧越強，一般來(lái)說(shuō)，測試的效率就越高。按常理來(lái)說(shuō)，每個(gè)人不可能了解全部的自動(dòng)化測試工具，我們只對常用的測試工具進(jìn)行考核就可以了，還算人性化吧。并且后面懂得較多的同事，給組內成員集體培訓，使大家迅速掌握測試工具的基本使用，這才是我們的真正目的。 10.測試結果的分析水平： 對自動(dòng)化的測試工具來(lái)說(shuō)，特別是性能測試結束之后，我們要分析部分測試結果，如果你都不熟悉測試工具的分析，何談效率呢？所以測試結果的分析水平，也可以作為衡量測試效率的一個(gè)指標。 如何提高測試效率？ 1.首先要有一個(gè)合理的詳細的測試計劃： 沒(méi)有詳細的測試計劃，測試部的每個(gè)成員都在那兒盲無(wú)目的測試，何談提高測試效率？當然測試計劃也不能夠太細，太細了，編寫(xiě)測試計劃同樣浪費時(shí)間，做到時(shí)可而止。最好是測試任務(wù)盡量能細化到測試的功能和測試的case這個(gè)級別去監控進(jìn)度，較為理想。 2.測試盡早介入項目詳細了解項目的業(yè)務(wù)需求，做好測試的前期準備： 目前來(lái)說(shuō)，可能大家都有類(lèi)似的感受，接觸到的大多數的項目，都是測試周期比較短，開(kāi)發(fā)人員耽誤了時(shí)間，為了不拖延項目進(jìn)度，留給測試人員做測試的時(shí)間都非常緊張。如果項目測試的前期了解業(yè)務(wù)需求、了解產(chǎn)品屬性和準備測試數據不充分，往往測試效率很低，測試時(shí)間變長(cháng)，測試效率急劇下降。 3.對測試項目前景充滿(mǎn)信心，調整最佳心態(tài)，保持愉悅的工作心情： 一般來(lái)說(shuō)，如果大家認為測試的項目沒(méi)什么發(fā)展前景，當然測試也不會(huì )很賣(mài)命，測試效率不用說(shuō)。如果某個(gè)測試人員碰到什么不順心的事，當天的工作效率肯定比平常低。所以，要保證測試效率，測試負責人要察言觀(guān)色，及時(shí)找不開(kāi)心的下屬談心，了解并幫忙消除部分員工的不良情緒，讓員工有更好的心情投入到測試工作中去。 4.提高測試接受的標準，減少測試版本送測次數： 大部分公司的開(kāi)發(fā)人員都有一種惰性，一旦公司成了測試部，他們自己測試時(shí)，都不會(huì )那么認真，以為有了測試人員，就自己就解放了。很多時(shí)候都是調試編譯通過(guò)，實(shí)際上開(kāi)發(fā)人員沒(méi)有做完整的自測，就拿到測試部進(jìn)行測試。如果測試部門(mén)有嚴格的測試接受標準，一旦發(fā)現有重大問(wèn)題，立即拒絕測試，送回開(kāi)發(fā)人員修改?？梢詼p少很多次反復測試，重復測試，明顯提高了測試效率。 5.測試負責人認真做好測試文檔的評審： 測試經(jīng)理一定要認真做好測試用例的評審，盡量使用較少的測試用例，發(fā)現較多的Bug，無(wú)疑是最佳提高效率的一種方式。很多時(shí)候，經(jīng)驗較少的測試人員在設計測試用例的時(shí)候，寫(xiě)了很多的測試用例，測試時(shí)幾乎沒(méi)有發(fā)現缺陷。還有一種：比如說(shuō)等價(jià)類(lèi)的測試，只要具備代表性就可以了，如果寫(xiě)了很多測試用例，執行了半天，臃腫的測試用例，未發(fā)現任何問(wèn)題，也很不值。這些主要是靠測試用例評審的時(shí)候，測試Leader去把握了。盡量做到在滿(mǎn)足需求的情況下，精簡(jiǎn)測試用例數量，提高測試覆蓋率。很多時(shí)候，測試人員寫(xiě)好用例就自己測試,根本沒(méi)人評審,有些地方理解有偏差,測試點(diǎn)沒(méi)測試到,導致發(fā)給客戶(hù)版本被退回，給公司也會(huì )帶來(lái)巨大經(jīng)濟損失。 6.加強項目組成員的相互溝通工作和項目信息收集工作： 測試工作是一項溝通要求比較高的工作，一般需要同項目經(jīng)理、產(chǎn)品經(jīng)理、開(kāi)發(fā)人員、業(yè)務(wù)人員、客戶(hù)溝通。很多時(shí)候，由于測試介入較晚，測試時(shí)間短，測試初期測試人員了解需求不及開(kāi)發(fā)人員，為了迅速熟悉需求，需要項目組成員之間相互培訓和溝通。 |
聯(lián)系客服
