基于度量的軟件測試體系建設

                                                    2023年8月8日 1464點熱度 0人點贊 0條評論

                                                    背景

                                                    2008年12月23號,應邀在中國質量年會上進行了發言,會議現場由于有賽迪傳媒的現場速錄,借此這份發言得以保存下來。

                                                    正好借著改版領測軟件測試網的契機,將這篇文章也保留了下來。

                                                    中國軟件質量年會主辦方

                                                    信息產業部軟件與集成電路促進中心(CSIP)已成功地主辦了兩屆中國軟件質量年會。本屆年會將以“軟件質量創新 助力兩化融合”為主題,繼續深化我們已取得的成績,把軟件質量年會做實,為增強我國軟件企業競爭能力、振興我國軟件產業,助力信息化與工業化融合做出積極貢獻。

                                                     

                                                    速記發言稿

                                                    開場

                                                    時間也比較晚了,希望最后一個內容對大家來說有一定的幫助。

                                                    今天跟大家分享的題目是基于軟件度量的測試體系建設。

                                                    下面是我的一個介紹,大家都上過測試時代網站,所以掠過了。

                                                    在以下半個小時的時間大家有任何疑問或者不明白的,你就舉手說,會場可以產生互動,沒有任何問題。

                                                    在座有多少測試人員,很高興,大概是百分之百,大家都是同行,看有沒有這樣的問題。

                                                    測試團隊遇到的問題

                                                    雖然覺得軟件測試很重要,但苦于沒有辦法組建規范的測試中心。什么叫規范的測試中心?有章有法,你的技術是可控的,你的人是可控的,很少有這樣的公司,我做過企業內訓的公司有上百家了,但很少,大多數認為是成本中心,或者是花錢,公司一直在不停的投入,但是對產品的質量沒有多少幫助。有多少幫助?你能說出來的,老板持續給你買工具,組建團隊,招聘新人,由于你的存在,由于你的團隊的存在,你為公司創造了很多效益,有嗎?你隱隱約約覺得有,但沒有辦法拿數字說明,所以沒有辦法證明你存在的價值,或者你部門存在的價值。

                                                    無法衡量軟件測試工作的成果,你說我的測試工作很規范,很努力,我寫了一千的測試用力,工作成果好不好?很難說,因為你的老板會說,才寫了一千個???我認為應該是上萬個,因為我的系統很復雜??赡苓€會問什么呢?你怎么能寫一千個呢?我認為咱們系統有一兩個足夠了,你用力怎么寫的,是不是花了很多無用功,都有這樣的疑問。你還沒辦法說明它。

                                                    總感覺測試工作,或者測試團隊的工作是不可控的。不可控在什么程度,在座有這么多測試人員,大家都會有這樣的感覺,我可能今天很累,累在什么地方,我好好測試我的軟件一個BUG都沒有發現,你的老板問你工作成果是什么,你沒辦法說。你可能今天很閑,你心情不好,不想干活,你可能上了一天網,被測的軟件沒有打開,雖然今天沒干活,但是對整個質量也沒產生影響,你可以心安理得的回家,第二天再說,對嗎?可能都有這樣的經歷。作為公司,作為部門經理如何對你監控,從公司的角度來說,這是一件很可怕的事情。

                                                    測試過程混亂,無法進行有效的持續改進。什么叫持續改進,沒有人有能力,沒有公司有能力,一次把所有的事情都做正確,都做好,做對,沒有人,沒有公司。你要知道你現在目標在哪兒,而且能判斷到你持續向你的目標邁進。

                                                    測試的目標是什么?

                                                    我們這么多做軟件測試的,軟件測試的目標是什么?上午和下午有很多嘉賓說,保證產品質量,認為是保證產品質量的我看看,很遺憾,保證不了,誰可以說經過你的測試,這個軟件質量就可以保證,誰敢說?那么多第三方的評測機構,哪個評測機構敢說這個軟件經過它的評測,質量就沒問題,誰敢說,你保證不了。

                                                    做一個簡單的數學題,一個軟件有一百個功能點,這個軟件大嗎?很小。如果從測試的角度來說,它可能有的功能點組合有多少?概率,C100/100,C100/100的數學計算結果等于多少?等于100的階乘,已經是天文數字了,從數學模型來講,測試無法建立,這個目標你可以影響,但保證不了。

                                                    驗證需求和實際軟件的相符程度,同意這個舉手我看看?同意嗎?軟件和需求相符就證明軟件的質量高嗎?需求就做錯了,你怎么辦?

                                                    對開發團隊進行有效的考核?行嗎?好象都不對。

                                                    軟件測試的目標是什么?可能是一個很大的問號。

                                                    我現在提出兩個目標

                                                    這兩個目標可能在其他的書上,或者在網上都看不到,最近才提出來的,兩個什么目標?

                                                    第一個,穩定控制軟件產品質量的振幅,ISO做了那么多質量管理體系,它能保證單一的產品進來就肯定出去是一個優秀的產品嗎?不可能。它能做什么?是以統計學的觀點控制軟件產品質量的振幅,你通過我的流程,出現一個高品質產品的概率高,同意嗎?是概率高,不可能完全控制。

                                                    穩定控制軟件產品質量的振幅這件事情不歸測試人員管,歸誰管?通常是通過SEPG組,建立度量體系,進行有效跟蹤和監控實現,是統計學。

                                                    第二個,測試做什么?高效的提高軟件測試用例的覆蓋率。好的測試人員和差的測試人員有什么區別?放在日常工作中,就是你想不到,同意嗎?你的組長或者你的老板永遠比你想的多一點,多的那點是什么?就是測試用例的覆蓋度,同意嗎?我們找了兩個關鍵字,一是高效,二是覆蓋度,后面我會證明這兩個怎么度量。

                                                    怎么樣能高效?通過測試用例的復用來達到高效,以數據驅動的形式自動化測試用例可以提高效率,通過有效的測試用例設計方法,擴大覆蓋率。

                                                    我現在要做什么事情?首先我把軟件測試的質量分解為一個目標,這個目標是高效提高軟件測試用例的覆蓋度,把一個復雜的問題簡單化,簡單為一個明確的問題。

                                                    下面我又做了分解,我把高效提高軟件測試用例的覆蓋度分為三個指標。

                                                    • 通過測試用例的復用
                                                    • 以數據驅動的形式自動化測試用例
                                                    • 通過有效的測試用例設計方法擴大覆蓋率。

                                                    這是典型軟件測試過程文檔體系結構,我們來看通常情況下,我會把整個軟件測試劃分為幾個步驟,首先最關鍵是軟件測試策略的制訂,測試策略提供幾個信息,項目實施范圍,可見可衡量的指標,驗證方法和階段。通常情況下,我們會把整個軟件測試過程劃分為單元集成系統。從所有的軟件工程或者從所有方法來說,都需要怎么做呢?都需要單元集成系統,一個都不能少。通常在不同企業里面做不同程度的裁減,單元測試必須要做嗎?

                                                    WPS1.0你相信第一個版本出現的時候會通過單元集成系統測試,我不相信,你們相信嗎?我肯定也不相信,但是不影響這個產品。產品在每個階段有不同的競爭要求。WPS剛出現的時候,是功能上的競爭,填補市場空白,只要有就OK,只要能用就OK,當競爭到一定程度,WPS到現在你能相信它不進行單元集成系統測試就可以賣嗎?不可想象。你現在就是選擇適合你的過程,當我們明確完策略以后,我們一般會把測試分為計劃、方案、實施、報告幾個階段。計劃主要解決五個W問題,誰,什么時間、什么地點,干什么事,由誰來完成,就是做資源合理分配,然后進行專項測試方案。專項測試方案就是性能測試方案,安全測試方案,易用性測試方案,加密狗測試方案等等,然后進行測試實施,測試實施主要做兩個內容,首先是測試記錄,通過寫記錄證明你執行到哪兒,沒通過的寫缺陷報告,整個階段完成寫階段完成報告,包括測試評估,然后做測試結論。

                                                    測試策略

                                                    通常情況下測試策略我們會明確以下幾個內容:

                                                    1、明確測試需求,你要對什么進行測試,這個點很重要,重要到什么程度?這么多人做軟件測試,我問大家一個問題,如果產品發布了以后,產生了質量問題,誰的問題?是測試員的問題嗎?是嗎?同意是測試員的問題,舉手我看看,不同意是測試員的問題我看看。經過你最后一道手發布出去了,產品出現問題了,你說不是你的問題,你能解釋嗎?很重要一個問題要明確測試的工作范圍,如果在你測試范圍內發現問題,肯定是你的問題,在你測試范圍外發現的問題,就不是你的問題嗎?不一定。我們要明確測試工作范圍,需要測試的對象,達到的目標等,可以來源于軟件需求,個人經驗,以前發生的錯誤等。我們要確定測試目標,確定測試類型和方法,測試風險分析。

                                                    策略完成以后,大家一定要注意,策略里面不包括人和時間,為什么不包括這兩項,從項目的角度來講,這兩項變化的風險太大。測試策略中一定不包含可能變化比較頻繁的要素,目的就是測試策略不允許隨便修改,它確定了該項目最關鍵的要素,當我們確定測試策略以后,將進行測試計劃的制訂。測試計劃包括什么呢?目標、方法、環境、工具,確定時間段,確定資源,自動化測試分析。一個項目里一定要進行自動化測試分析嗎?完全沒必要,自動化測試不能幫助你解決發現BUG的問題。首先大家要對自動化或者功能類自動化工具產生明確的認識,它不能幫助你發現新的BUG,它能幫助你提高效率,提高測試用例覆蓋效率。

                                                    但計劃完成以后,我們要進行專項測試方案制訂,我們要把計劃策略中所有需求拿出來,進行備案,然后細化測試規矩等等。

                                                    測試實施包括測試記錄和測試報告。

                                                    階段總結報告要提供測試執行依據,證明測試過程完整的執行了測試計劃內容,提供測試分析數據,證明系統的質量達到要求或未達到要求,如果比較重要的系統要提供模擬測試,比如說銀行或者電信系統,當它一個周期是一個月的數據,如果你隨意切換,你的系統不行怎么辦,有一種方式就是這一個月的數據,原來的系統跑一遍,新上線的系統在另外一套系統跑一遍,兩個出現的結果對比一下,走一個月就可以順利切換了。

                                                    其次提供遺留問題及后續的解決辦法,剛才都問到一個問題,測試什么時候結束,測試結束有兩個必要條件,缺陷處于收斂狀態,所有遺留問題都有了明確的解決方案。

                                                    剛才跟大家簡要的說了一下我們認可的,或者我們覺得比較合適的一個軟件測試過程控制方法,談到度量,談到對過程的控制,我們首先要明確過程是什么,剛才我們過程擺在那兒了,我們再來看。

                                                    測試流程解決的兩個問題

                                                    我們把復雜的問題明確為兩個問題,一是質量振幅,二是高效提高軟件測試用例覆蓋率。質量振幅如何控制,針對軟件測試過程的符合度進行控制,通過由EPG組進行監控,SQA進行檢查,檢查報告就是振幅的一個指標,不在我們討論范圍之內。

                                                    我們談測試相關的東西,高效提高軟件測試用例的覆蓋率,高效和覆蓋度是我們關注的目標。通過這兩個目標,我們去抓整個的軟件測試過程,我們看怎么抓。

                                                    軟件測試工作如何提出效率,可能的指標有什么?我只能說可能的指標,因為度量也好,過程也好,針對每個公司都是個性化的過程,比如說我們通常在網上能拿到的數據,最完備的過程是什么?是RUP,一張光盤,上頭有整個從項目需求一直到最后部署,整套的文檔,整套的模板,你能用嗎?我跟IBM的工程師聊過,RUP的精華在什么?精華在裁減,你只有了解的全部,了解到本企業的現狀才知道自己用什么,不要盲目套用任何一套你看的好的方法或者模板,必須要個性化定制。這塊談到的目標只是參考??蓮陀玫漠a品多,可能提高效率吧,如果每次做項目能用到復用的產品很多,一定會提高效率,我們的指標就是測試資源復用率,包括計劃、方案、用例,自動化測試腳本等等一系列,你在一個項目中產生的所有文檔、代碼或者思想,這些復用率有多高,拿一個指標控制。

                                                    無用的工作少,上禮拜我們在對面開測試時代的交流會,有幾個人,測試用例我們寫到什么程度,大家想象,如果你只有一個禮拜的測試時間,五個工作日,你花三天寫測試用例,兩天做測試執行,合理嗎?五天全部做測試執行,我不寫測試用例,合理嗎?假設一年我八個月寫測試用例,四個月做執行,合理嗎?我一年不寫測試用例,只執行,合理嗎?所以當你看你項目的時候,絕對沒有一個統一的方法、指標讓你去做,要根據目標來決定。

                                                    目標決定過程,過程決定質量

                                                    上午在說我推崇一句話,這句話是兩部分,第一部分是目標決定過程,一定要注意,目標決定過程,第二部分,過程決定質量。為什么目標決定過程?跟敏捷開發方法的理念是一樣的,你想做什么,想達成什么樣的結果,就讓過程不多不少的配合你,你要做什么,完全跟你的目的有關系,不要做過多或者過少的工作。所以它都是定制化的過程。無用的工作少,你要做度量,比如說以前我作為測試組,或者你們作為測試人員,有多少測試人員在寫文檔,我指的文檔是用戶使用手冊說明書,舉手我看看。在小組織小工作量下是沒問題的,如果你的測試工作或者測試有效工時三分之一以上都被明顯跟工作質量無關的工作就有問題了,所以我們要拿到有效測試工時率。

                                                    和開發的配合好,在研發過程中,測試是輔助流程,還是主流程?輔助流程,如果你是輔助流程,你當然要跟主流程配合。跟主流程如何配合,首先協作點的數量,你跟開發人員有多少次交互,我指的正式交互,不是你平常沒事吃飯、打球、聊天,而是在技術方案中你跟開發人員做的交互有多少點,協作點的正確率,正確率主要指時間和質量,1月1號說給你協作點,1月1號沒給你,這個協作點沒有成功,如果給了你,你沒有評估,這也沒有成功。

                                                    測試項目進度貼合度

                                                    測試項目進度貼合度好,什么叫貼合度好?第一,我沒看到過沒有發現BUG的項目,有沒有這樣的測試人員,我測試一個產品壓根沒發現BUG。項目變化率,你作為項目經理,你寫了份測試計劃,你的計劃會有多少次變化,變化的程度會是怎樣的,也是判斷你的效率。工期貼合率,你們之間的工期是否有很好的貼合。

                                                    自動化測試不能發現BUG

                                                    自動化測試提高效率,首先自動化測試不能發現BUG,它可以把你的手工測試用例自動化,自動化手工測試用例的數量,跟手工用例的比例,這個比例越高越好,但一定要考慮成本和產出,值不值得這樣做。以前我看一個項目,它的測試經理給我們展示QTP做的自動化測試,從頭到尾自動化,所有的操作不用人工干預,我看了挺高興,后來我問他,它發現過BUG嗎?沒發現,你平常測試用它嗎?也不用。做它干什么?演示。你就看到鼠標在那兒點,一個流程一個流程完成。為什么這么做?處于測試人員自我的愛好,他覺得這個有意思,技術含量高,想學這門技術,也給老板做演示,老板看了很高興,它不產生實際的效率。

                                                    測試用例的覆蓋度

                                                    測試用例的覆蓋度是一個求積分的過程,什么叫求積分的過程?可以無線接近,但是永遠到達不了,只可能無限接近,但不可能等于。

                                                    有效度量測試用例覆蓋度增加的條件:

                                                    • 1、現有測試用例進行了有效的管理,首先測試用例你需要用工具或者手段管理起來,一條一條放在那兒,做一個基線。
                                                    • 2、明確測試用例編寫的顆粒度,大家都有這種感覺,你寫測試用例,你測試這個產品的時候,你十條測試用例就測試完了,有人寫三十條,你就覺得奇怪,我覺得十條已經是局限了,怎么你能寫到三十條,你去看他的用例,發現這也能算一條,這是組織內部測試用例顆粒度沒有達成一致,顆粒度你可以跟代碼行數對應,跟功能點對應,組織內部測試用例顆粒度要統一,保證所有人員大致是一致的。
                                                    • 3、單個功能點都進行了有效的規整,確定最小測試范圍。你如果做測試用例的度量,需要保證單一個功能點進行了規整。
                                                    • 4、提高的方式放在功能點的組合和測試數據的增加上,如果你想提高效果,很重要的兩個目標,就是功能點的組合增加了多少,測試數據又增加了多少。
                                                    • 5、每輪新增測試用例量和率,通常情況下測試一個軟件,你的測試用例要跑好幾輪,三到五輪,有的可能更多,每輪會新增一些用例,這些新增的量和率是多少,如果在組織穩定的時候,新增數量不會太大,如果組織不穩定,或者產生新的功能點比較多的時候,新的功能點組合比較大,這個率就會比較高。對于你進行一個項目控制也是有借鑒意義的。

                                                    軟件測試過程的定制是一個個性化很強的工作,每個企業都應該不一樣,如果一樣了,就會有問題,指標確定確立不能照抄,你抄沒問題,你照著人家的進行,就有很大問題,需要根據能力成熟度進行有效的分析和定制。

                                                    質量的提高,工作的改進是一個漸進的過程,絕不能一蹴而就。

                                                    通過分析,要先解決重要的事情,要有總體的規劃,而不是頭痛醫頭,腳痛醫腳。

                                                    我大致的發言就到這兒,謝謝大家。

                                                    領測老賀

                                                    領測軟件測試網站長,ISTQB認證高級培訓師,TMMi認證咨詢師。深耕軟件測試行業20余年,領測老賀聊軟件測試制造者。

                                                    文章評論

                                                    99久久精品国产免费看|日韩国产成人无码AV毛片蜜柚|精品国产高清a毛片|无码国产色欲XXXXX