對擬合趨勢的K值的分析

　　這篇文章將會介紹到對S型曲線的漸近值K值的分析。在之前介紹S型曲線的文章中，已經對K值進行了介紹：S型曲線會趨近一條漸近線（K值），即“S”型增長曲線的最大值會接近K，但不會超過K；增長率會不斷下降直至為零。以軟件缺陷預測為例，有了K值，我們就能得到該軟件系統最終應當發現的缺陷數目。這樣在發布軟件之前，根據已經檢測到的缺陷的數目，就可以得到還有多少個缺陷未被發現。因此，為我們是否可以發布這個軟件、或者說我們發布這個軟件的原因提供了依據。

　　大家都明白漸近線的含義，K值就相當于漸近線。那還有什么可討論的呢？實踐證明，在缺陷預測時，用9個實際數據預測得到的曲線，與用15個實際數據預測得到的曲線并不相同，它們的趨近值，即K值也不相同。那么，到底哪個模型更為擬合？已經有了9個數據時預測得到的模型，是否還需要用更多的數據去重新預測呢？那如果有了20個實際數據，是否還有必要用25個實際數據重新預測呢？

　　在曲線預測中，預測的結果使得我們能夠得到曲線在每個時間的分布情況以及曲線最終的逼近情況。所以，對漸近值K的預測是我們預測的目的之一。

　　從上述曲線模型的預測過程中可以看出，預測的結果是最終會得到一個K值。如果使用不同數目的樣本數據進行預測能夠得到相同的K值，那么就說明K值是穩定的。但在實際項目中，多次實驗得到的結果卻是K的值并不是唯一不變的，它也是一個隨時間趨勢、遵循一定的規律不斷發展變化的值。

　　那么，K值會如何變化呢？下面是我們針對這個問題，在實際項目中所作的實驗。

　　◆ 將預測出的數值用同樣的預測方法重新預測，比較將預測值用作樣本值進行預測得到的結果與之前的預測值之間的差別

　　◇ 結果：兩次結果并不相同，但差別很小，K值的接近度近似于100%

　　◆ 針對三點法進行實驗。普通三點法所取三點分別為起點、中點和“終點”，三點之間相距分別為M；通過比較所取的三點若稍有差別時得到的結果來分析K值，所以取三點分別為第二點、中點的后一點和“終點”（或者是類似的取法），它們之間同樣相距分別為M（這里是對Gompertz曲線和Logistic曲線做的實驗）

　　◇ 結果：兩次結果也并不完全相同，但差別同樣很小，K值的接近度近似于99%

　　上面這兩個實驗雖然得到了相近的結果，看起來幾次實驗K值也是接近的，但并不能得到K值是穩定的這一結論，要想對K值穩定度進行分析，還需要繼續針對K值進行不同的實驗來分析研究，或利用大量數據進行驗證。

　　● 預測監控

　　預測的一個十分重要的理論基礎是：一定形式的需求模式過去、現在和將來都起著基本相同的作用，即過去起作用的模型現在依然是有效的，那么如何來判斷實際情況呢，這就需要進行預測監控。

　　檢驗預測模型是否仍然有效的一個簡單方法是將最近的實際值與預測值進行比較，看偏差是否在可以接受的范圍之內，另一種方法是應用跟蹤信號（Tracking Signal，TS）。

　　所謂跟蹤信號，是指預測誤差滾動和與平均絕對誤差的比值，公式為：

　　TS=RSFE/MAD=∑（At-Ft）/MAD

　　各符號的含義見上篇文章。每當有實際需求發生時，就應當計算TS。如果預測模型仍然有效，TS應該比較接近于0。只有TS在一定范圍內（設定上下限），才認為預測模型可以繼續使用，否則，就應該重新選擇模型，如圖1。

圖1 TS范圍

　　圖1中，兩條紅色的線代表的是TS的上下限范圍，黑色曲線代表的是TS，TS不斷變化，但只有在上下限的范圍之內的TS才可以看作是有效的，可以繼續使用，否則，TS不再有效，不應繼續使用。

　時間就像馳騁在遼闊草原上的駿馬，絲毫沒有一點喘息的片刻。不知不覺，工作快3個年頭了。從早期的JAVA軟件開發到目前的軟件測試，一路可謂是“艱辛”的度過。

　　回首過去，所有的事都是無心插柳，正應了那句：life is like a box of chocalate......浮躁和貪嗔，總讓人不斷營營役役，終其一生，卻往往又一事無成，到死都未必明白自己活著是為了什么？！

　　以前，當然也包括現在，時常感到迷惘，不知道該做什么，不知道以后的路該怎么走！

　　每當看電影《阿甘正傳》時，我都不由自主的對生活充滿激情：阿甘在風中毫無意義奔跑的時候，他究竟在想什么？當那么多人跟著阿甘在陽光下奔跑時，又是怎樣的迷惘？當我們走在生活的路上時，我們又在想什么？

　　付出，終究會有回報的。人的一生也是如此。

　　從一名普通的測試員到測試精英，以下是個人的一點體會，如果不妥，敬請指正！

　　對于從事IT研發的人來說，無論是開發者、測試者甚至產品者，“思維”是非常重要的。思想的高度決定事物價值的體現。因此，作為產品質量的把關者，測試人員應培養以下思維模式：

　　【全局思維模式】

　　古語云：“不識廬山真面目，只緣身在此山中”，恰好體現出全局思維模式的重要性。世間的事物往往存在多面性，在軟件領域更具有抽象性，我們只有從多個角度去度量、分析，才能掌握其本質。在日常的軟件項目活動中，需求、測試用例以及其他文檔評審，就是借助全局思維模式，讓更多相關人員參與以補查項目解決方案的正確性，從而，可以降低或者避免風險的發生。

　　【逆向思維模式】

　　逆向思維，也稱“求異思維”。是數學領域的一個支柱。逆向思維模式在測試活動中是不可缺少的一種指導。作為測試員，當發現Bug時，進一步定位問題的所在，通過日志或者其他信息工具進行逆流而上排查，進一步分析。從而為開發人員查找、解決問題節約一定的時間。除此之外，由于開發人員思維模式定型，因此，測試人員的逆向思維可以彌補開發人員在項目中的思維漏洞。

　　【換位思維模式】

　　換位思維模式，顧名思義，就是換個空間、角度去剖析問題。在認識某一事物時，人們總是會通過和頭腦中的某些概念進行比較，找出相同、相異之處，或者歸類，從而將其加入大腦中的知識體系，可能的話，再建立好的搜索方式，以便以后使用，最明顯的例子就是“經驗”的運用。對于新的項目，某個細節，我們都會采用以往經驗去分析、處理。實際項目中，針對某個問題，我們會站在不同的角度去體驗，用戶、開發以及產品的使用者。只有通過這種方式，我們的產品才能得到市場的認可，社會的接受。

　　【極端思維模式】

　　隨著軟件產業在中國的日益成熟，越來越多的企業、用戶對產品的質量更為關注，由最初的功能，漸漸涉及性能、安全性以及其他方面。

　　在測試活動中，非功能性缺陷也越來越引起市場、用戶的重視。為了保證系統的穩定，我們引入性能測試；為了驗證系統的賬戶安全性，我們采用邊界值分析以確保產品是否滿足用戶最終需要。極端思維模式，就是在兩極條件下，驗證系統是否存在缺陷。

　　以上是測試活動中最主要的、最常用的思維模式。由于時間關系，今天先談到這里。后續有時間，續敘！

　　其實這些思維方式，大家都在有意識或者無意識的運用著，它們各自都有自己的妙處，將我們的思維發散，有意識的將他們用在問題的思考上，有時可以給我們一種“柳暗花明又一村”的感覺。

　　最后想補充一下，只知道這些原則意義不是很大，如果真想能讓它們成為思考的血液，發揮它們的真正價值，那需要很多的歷練。其實想成為一名測試精英，遠沒有那么簡單，需要的是一種堅持、一種毅力、一種（不斷學習＋不斷經歷＋不斷思考）的精神。

　一些有意義的條目：

　　1、考慮自動化是否能發現有價值的缺陷，是否經得起時間的考驗，是否值得付出維護費用

　　2、決定需要測試什么和何時測試

　　*對于每一個被發現的缺陷，明確的討論它應該在什么時候被發現

　　3、決定如何測試

　　*是否有一種特殊的路徑引導人員找到這個缺陷

　　*這種功能或特許最好用哪種給定的方法來測試

　　*知道當前已經進行了哪些測試，以及我們目前和將要進行的測試如何才能增加總體測試效果

　　*發現軟件問題，需要實際用戶在實際的環境中，用實際的數據，去做實際的工作

　　*簡單重復的工作實現測試自動化

　　4、測試中最困難的部分是：決定測什么，決定測試的完整性，確認用戶場景等

　　5、哪些是好的測試，哪些是不好的測試；完成測試后，團隊學會了什么？

　　測試修行：（很重要）

　　1、將測試分為兩部分，即“測試今天的項目，準備明天的項目”

　　*保證當前的測試項目獲得成功

　　*學習應該做些什么以便下一個測試項目更緊容易

　　2、警惕重復做一件事情，嘗試能不能自動化

　　3、思考：

　　*我們用什么技術找到了那個缺陷？

　　*我們是否可以創建一種方法來找到更多這類缺陷？

　　*是否可以記住一些實際的測試經驗并不斷加以應用來提高測試效率？

　　*軟件的哪些癥狀可以提示我們它有缺陷？

　　*我們將來能否從那些癥狀中得到更多的警示？

　　*這個缺陷教會了我們什么？

　　因而總結一系列的測試技術、建議和工具

　　4、反思：

　　*自己的測試流程是否有問題？

　　*測試流程里有沒有缺陷？

　　*這里面是否存在妨礙我提高效率的障礙

　　*例如：

　　1）收集我們發布給用戶的所有缺陷（特別是安全漏洞或者數據缺陷）：

　　反思我們是否有流程問題，思路是否有方向性錯誤，或者是否犯了錯誤

量化項目管理案例：缺陷趨勢預測利器（1）

　不知身為軟件工程師的你，在寫代碼時是不是有過這樣的經歷：一方面對自己寫的代碼信心滿滿，一方面又非常希望知道自己開發的代碼的質量到底多高。如果代碼真的沒被測出bug來或者測出的bug較少時，反而有點擔心——會不會還有隱藏的更深的bug沒被發現？或者身為測試工程師的你，可能比開發人員擔心的會更多：這些代碼該不該再繼續測試了？怎么就能斷定當前的版本算是通過驗收標準了，繼而可以被客戶和用戶認可？是不是就可以把這個版本交付使用了呢？

　　--------------------------------------------------------------------------------

　　相信這是很多開發和測試人員都曾經經歷過的。無論是開發人員、測試人員，還是項目經理、高層管理人員，都已經為版本的交付日以繼夜的加班工作，可不能在交付的時刻功虧一簣。打擊心情不說，加班加點不說，而且，誰該來為可能的返工和無休無止的變更買單呢。

　　所以，軟件版本在發布時需要有一個判定的標準——沒有預先定義的判定標準，就無法去判斷版本是否已經達到了客戶的要求。不進行判斷，或者是錯誤的判斷，都很有可能會造成該項目資源安排的不合理，甚至造成資源的浪費，那么不管是精神上還是體力上，甚至進度上、成本上，都會給項目團隊帶來不小的打擊。

　　CMMI四級的一個要求是量化的管理項目（詳見量化項目管理QPM中文版）。映射到缺陷預測活動中，也就是量化的管理缺陷。量化的退出標準就是將類似“這個版本是否能夠通過”這樣的問題，形象地轉變為“已經測出的bug數是否已經足夠多，遺留的bug是否已經少到不會影響軟件的交付”等等這樣的表述。這樣，無論是理解上還是判斷上都更加容易，版本發布標準也就變得不難理解了。

　　在決定發布版本之前，需要去統計這樣幾件事：我們已經發現了多少個bug；用量化的方法進行管理時，我們還有多少個bug沒有發現；我們統計到的未發現的bug數是否能達到客戶的要求；如果無法滿足客戶的要求，那我們至少還需要發現多少個bug。當這一系列問題都解決了以后，開發、測試人員是終于可以“收”工拿項目獎，還是需要返工加班、繼續努力，也就一目了然了。

　　知道了要做什么，接下來要考慮的就是“怎么做”。出于這樣的原因，方正國際軟件有限公司（以下簡稱方正國際）幾年來一直都在內部實施著利用統計學的原理對軟件缺陷進行管理和監控。用統計學的方法監控和預測缺陷的發展情況，從而對發現的缺陷進行管理，確定還未發現的缺陷情況、為了按時交付每一個階段應當發現的缺陷情況，以此相應調整測試工作的時間和進度。

　　這就是方正國際近兩年來一直在內部實施的基于Gompertz模型的缺陷預測與管理，以及在此基礎上開發的缺陷預測與管理的工具。在已經采集到的多個項目數據的基礎上，現在該工具已經在公司內部使用。應用這個工具，讓測試人員在測試初期就對自己大致的工作量有了比較準確的估計，并對測試的每個階段發現的bug實施分析和監控；根據預實對照的目標達成情況來調整開發、測試的進度；而且在最終交付時，給客戶一個高質量的、可靠的工作產品。簡單用個例子來說明吧。在項目A還未進入但即將進入測試階段時，測試經理就會根據歷史的情況、經驗等方法，估計出進入測試階段后的第一周，大概可以發現多少件缺陷；同樣，再估計出版本交付時可能出現的缺陷數目，以及版本交付后會出現的缺陷的數目。利用這三個數據的信息，就大致可以得到：要達到預定的目標，在進入測試階段后，每周、甚至每天大概需要發現多少缺陷。以此為依據，測試經理就可以對團隊中的測試人員的任務進行分配、對工作進行評價。當然，這僅僅是Gompertz模型使用的場景之一。

　　統計學是很強大的，統計學知識的應用也是很廣泛的。那么，在缺陷預測中的統計學原理，或者說是理論依據是什么呢？基于Gompertz模型的缺陷預測工具到底是怎樣對測試活動和質量進行監控的呢？接下來，我們會逐步與大家分享。

　　未完待續......

趨勢預測、基于時間信息的預測相關基礎知識

　　在展開Gompertz模型趨勢預測的說明前，首先給關注統計學知識在軟件行業應用的網友介紹趨勢預測的基礎知識。

　　如何理解預測技術呢？簡單來說，預測（prediction）是根據事物發展的歷史資料及當前情況，運用一定的理論和方法，對未來趨勢做出的一種科學推測。再簡單點，就像傳說中或是童話里的占卜師一樣，當你想知道將來的事情時，你需要告訴占卜師你的出生情況，他就能將你的一生預測出來。不同的是，他只能告訴你，你的一生是順利或是不順，或再詳細點告訴你可能在哪段時間會發生不尋常的事情；而我們所說的預測技術卻可以詳細到周，甚至詳細到天。當然，這里還有個本質的區別，那就是我們這里說的預測是有科學基礎的，而占卜師的預測只是常常出現在童話里或者傳說中罷了。

　　預測技術的應用主要針對未來的趨勢，即是經常講的趨勢預測？這里我們也來個“顧名思義”。“趨勢”一詞在詞典里的解釋是“事物發展的動向”，也就是會呈現出某種規律。簡單點，某一事物未來是好是壞，是多是少，是升是降，或者先好后壞，先多后少，先升后降等等，也就是對未來進行預測。再用上面的例子來說明，小李急切地想知道自己的未來，并求助于占卜師，而占卜師則預測到他在40歲時會有場災禍，那么恐怕小李緊接著要問的就是“我該怎樣做才能化解我的災禍”。趨勢預測就是要解決類似的問題。預測并不是最終目的，而是一種手段，當預測到的趨勢不符合規定的標準時，就應當及時采取措施來進行調整或緩解，這也是趨勢預測的目標之一，通過分析預測的結果，揭發它的發展趨勢，從而使得人們能夠盡早地發現問題，或得到一個科學論斷和標準。現在從童話回到現實中來。在軟件領域，缺陷的趨勢預測是預測技術應用較為廣泛的領域之一，它是利用統計的手段來預測產品或解決方案中的遺留缺陷、測試階段的單位時間內應當查出的缺陷等，因此對軟件質量的提高和測試階段的管理起著重要作用。

　　在軟件領域中，一條重要的原則就是“do it right the first time”。這條原則告訴軟件行業的工作人員：應當在第一次就將事情做對。然而實際中的情況是，軟件開發完成后總還是存在缺陷，所以才需要測試，才需要品質保證；考慮業務的復雜性、開發工具的更新、需求的不穩定性、開發人員的能力經驗欠缺等因素，幾乎不能在第一次就將事情完全的做對，取而代之的是不斷的驗證、測試、修改再確認，才能最終確保軟件產品或服務的正確性。然而有一件事可以確定，某個軟件系統中的缺陷數目應當是一定的，隨著軟件系統生命周期的推進，發現的缺陷數應當由少到多，再從多到少并趨近于零。那么，如果無法做到“第一次將事情做對”，也要“盡早將事情做對”，在缺陷可能帶來巨大的風險之前，就將它“扼殺在搖籃里”。如果沒有預測，不知道未來趨勢，也就無法判斷當前處于怎樣的狀態下，更無法知道，在當前階段，是不是已經有缺陷遺留到了下一階段。這一點其實很容易理解，本來需要在2周內每天完成30項任務，但第一周只完成了10項，那接下來的一周內就需要加班加點完成剩下的50項任務；如果未能完成，那就可能導致無法交付任務，帶來足以讓你后悔的結果。

成長曲線

　　終于要介紹到預測方法啦。有了前面兩篇文章的基礎，大家應該都對預測有了認識。還是那句話，知道了要做什么，接下來就該想要“怎么做”。明白了預測的重要性，那就該去想想，怎么去預測？不過別心急，我們一步一步來，這篇文章會介紹預測工具的基礎知識——成長曲線。

　　什么是成長曲線？成長曲線就是描繪觀測樣本從初始階段不斷發展壯大所經歷的全部過程的曲線。在軟件領域的成長曲線的過程中，要觀測的樣本值會經歷萌芽、發展、穩定等階段。成長曲線在很多方面都有應用，比如在報紙上、經濟類刊物上常常能看到的經濟成長曲線、品牌成長曲線；再比如細心的媽媽都會把寶寶出生后的成長情況記錄下來，繪成兒童成長曲線等等。

　　在軟件領域中同樣有成長曲線，軟件領域中的成長曲線反映了軟件系統中的要觀測的某個屬性隨著各種因素（如時間、成本等）變化發展的情況。成長曲線可以擬合事物發展的趨勢，曲線擬合（Curve fitting）就是用連續曲線近似地刻畫或比擬平面上離散的點表示的坐標之間的函數關系的一種數據處理方法。在數值分析中，曲線擬合就是用解析表達式逼近離散數據，即離散數據的公式化，就是選擇適當的曲線類型來擬合觀測數據，并用擬合的曲線方程分析兩變量間的關系。

　　接著回到軟件領域中的成長曲線上。對于一個系統來說，進入開發階段后，開發人員每天都要完成一定量的代碼行，而代碼行的總數在項目計劃階段就應當是估算好的，那么，開發人員應當按照怎樣的速度完成這些代碼；已經完成了一部分代碼后，能否判斷出這樣的速度是否合理、能否按期完成任務；前期完成過多代碼可能會造成后期工作量太小，而前期完成太少代碼又可能會帶來后期的工作繁重。也許這時，你就會迫切需要一個工具來對開發人員的工作進行監控。進入測試階段也是一樣。所以這里提到的軟件領域中的成長曲線的預測，就是針對軟件的開發階段和測試階段的。再以測試為例，成長曲線能夠反映缺陷從最初的測試出的缺陷較少，到中期不斷發展增多，再到最終測出的缺陷數穩定不變的全部過程。成長曲線應當是連續的，它能夠表示一段時間內事物持續發展的情況，能夠表示事物在一個持續的時間段內發展的全過程。

　　成長曲線有很多種形式。常見的線性曲線也可以看作是成長曲線的一種，只是在現實中，線性曲線的使用不如非線性曲線廣泛。下面將幾種常見的成長曲線歸納介紹，希望對大家的理解有所幫助。

　　1、Rayleigh模型

　　Rayleigh模型是Weibull分布的一種特殊形式，是一種常用的模型。Weibull分布最重要的一個特征是它的概率密度函數的尾部逐漸逼近0，但永遠達不到0，在許多工程領域都使用了很多年。Rayleigh模型既可以對軟件開發全生命周期進行預測，也可以僅對測試階段的缺陷分布進行預測，得到所期望的時間間隔t與所發現缺陷的關系。對于成熟的組織，當項目周期、軟件規模和缺陷密度已經確定時，就可以得到確定的缺陷分布曲線，并可以據此控制項目過程的缺陷率。如果項目進行中實際的缺陷值與預估的缺陷值有較大差別時，說明中間出現問題，需要加以控制。

　　1）Rayleigh模型的函數形式

　　Rayleigh模型的累積分布函數（CDF）：F（t）=K*（1-exp^（-（t/c）^2））；

　　Rayleigh模型的概率密度函數（PDF）：f（t）=2*K*t/（c^2）*（ exp^（-（t/c）^2））。

　　上面兩個函數中，t是時間自變量，c是一個常量（c=2^（1/2）tm，tm是f（t）到達峰值對應的時間），K是曲線與坐標形成的面積（總缺陷數），也是我們要估計的參數。多年的預測經驗得到缺陷在tm時間的比率（F（tm）/K）約等于0.4，即在f（t）到達最大值時，已出現的缺陷大約占總缺陷的40%。按照這個推導，在某一時間就可以估算出總的缺陷數以及具體的Rayleigh分布參數，從而將缺陷的計算過程簡化。

　　2）Rayleigh函數對應的圖

圖1 Rayleigh模型的CDF圖

圖2 Rayleigh模型的PDF圖

　　由圖1——CDF圖可以看出，累積密度最終趨近一個最大值（K）；由圖2——PDF圖可以看出，缺陷隨時間逐漸降低最終趨向于0。

）使用Rayleigh曲線來建模軟件開發質量涉及兩個假設：

　　在開發過程中觀察到的缺陷率與應用中的缺陷率成正比關系。對應于圖1來說，也就是如果開發過程中觀測到的缺陷率越高，CDF中圖的幅度越高，K值越大；

　　給定同樣的錯誤植入率，假如更多的缺陷被發現并更早將其移出，那么在后期階段遺留的缺陷就更少，應用領域的質量就更好。對應于圖2來說，曲線與X、Y軸圍成區域的面積是一定的（總的缺陷數是確定的），如果在前期移除較多缺陷，即曲線的峰值點前移，那么后期曲線的面積就會小，代表后期遺留的缺陷數減少。

　　4）使用場景：收集數據應當越早越好；且需要持續的追蹤缺陷數。

　　5）優勢：隨時間信息的缺陷密度可預測，因此在測試階段使得找到并驗證缺陷的估計成為可能。

　　6）Rayleigh模型沒有考慮到變化調整的機制，所以可能會影響到缺陷的預測。

　　2、指數模型

　　指數模型是針對測試階段，尤其是驗收類測試階段的缺陷分布的模型，其基本原理是在這個階段出現的缺陷（或者失效模式，我們這里討論的是缺陷）是整個產品可靠性的良好指證。它是Weibull系列的另一個特例。指數模型是許多其他可靠性增長模型的基礎。指數模型可分為故障/失效計數模型（fault/failure count model）和失效間隔時間模型（time between failures model）。基本的指數模型的累積缺陷分布函數（CDF）為y=K*a*b^t，修正指數模型在基本指數模型曲線函數上加一個常數因子。

　　1）指數模型的函數形式

　　指數模型的累積缺陷分布函數（CDF）：F（t）=K*（1-exp（-λ*t））；

　　指數模型的缺陷概率密度函數（PDF）：f（t）=K*（λ*exp（-λ*t））。

　　其中，t是時間，K是總缺陷數，λ與K是需要估計的兩個參數。

　　2）指數模型對應的函數圖

圖3 指數模型的CDF圖

圖4 指數模型的PDF圖

2）指數模型的關鍵假設：測試工作量在測試階段中是均勻的。

　　3）使用：指數模型預測缺陷時是基于正式的測試階段的數據的，因此它主要適用于這些階段，最好在開發過程后期——例如最后的測試階段。但在交付用戶使用后，用戶發現的缺陷模型，與交付用戶之前的模型往往有很大差別，這是由于交付客戶后影響客戶的測試的不確定因素更多。

　　4）優勢：最簡單最有用的模型之一，易于使用和實現。

　　5）缺陷：假設測試的工作量在整個測試階段是均勻的。

　　3、NHPP模型（非齊次泊松過程模型）

　　NHPP模型是對在給定間隔內觀察到的故障數建模，它是指數模型的一個直接應用。

　　1）NHPP模型的函數形式：其中，參數的含義與指數模型相同

　　NHPP模型的累積缺陷分布函數（CDF）：F（t）=K*（1-exp（-λ*t））；

　　NHPP模型的缺陷概率密度函數（PDF）：f（t）=K*λ*c^（-λ*t）。

　　2）NHPP模型對應的函數圖：見指數模型

　　3）由于NHPP模型是指數模型的應用，所以NHPP 模型的特征與指數模型的特征相同。

　　4）缺陷：大多數NHPP模型都基于這樣的假設：每個缺陷的嚴重性和被監測到的可能性相同，在排除一個缺陷時不引入另一個新的缺陷，但實際情況并非如此。缺陷之間是存在著關聯關系的。

　　4、S型可靠性增長模型

　　S型增長模型是軟件領域應用較為廣泛的模型之一，下一篇，將會詳細進行介紹。

　　未完待續。。。

在上一篇里，已經介紹了如何選擇曲線模型，這一篇里，將會介紹怎樣預測出該模型下符合實際數據的曲線，選擇合適的模型。（模型的擬合算法將單獨介紹）

　　給定一組實際數據，要讓你預測出今后的一段時間，該數據的發展趨勢，很多情況下，你并不能一下子就找到符合這組數據發展趨勢的模型。而實際上，又有太多模型可以選擇，每一個模型都會得到一個不同的發展趨勢。好比買衣服，琳瑯滿目、各式各樣，可是，到底哪一件適合你要出席的場合呢？所以，到底是指數合適，還是Gompertz合適，又或者是Logistic合適呢？

　　這個時候，就迫切的需要一個評判的標準，這種標準稱為擬合度。擬合度的評價也有幾種方法，本文列出了幾種常用的擬合度判斷方法，并對這幾種方法進行總結、對比。

　　◆ 利用相關系數R2來進行擬合度判斷

　　相關系數R2是一種常見的擬合度的判斷方法，常用于判斷線性曲線的擬合度，然而在許多非線性曲線的擬合度判定過程中使用的依然是判斷R2的方法，這個判斷標準在實踐中也被證明是符合實際的。實際中，R2較大的曲線模型，往往也是擬合較好的模型。

　　● 計算殘差平方和Q=∑(y-y*)^2，其中，y代表的是實測值，y*代表的是預測值

　　● 計算相關系數R2=1-Q/∑(y-ya)^2，其中，y代表的是實測值，ya代表的是實測值的平均數

　　● 判斷方式：R2越大、越接近1，認為擬合度越好

　　◆ 利用變換的R2來進行擬合度判斷——以Gompertz曲線和Logistic曲線為例

　　Gompertz曲線和Logistic曲線的預測過程（無論是三點法還是三和法）首先都需將模型的函數進行變換（對Gompertz模型進行對數變換，對Logistic模型進行倒數變換），然后再運用三和法或者三點法的原理進行計算。所以這里提出一種運用變換的相關系數R2來進行擬合度判斷。

　　● Gompertz曲線

　　◇ 分別將實測值和預測值進行對數變換

　　◇ 將對數變換后的實測值記作y，將對數變換后的預測值記作y*

　　◇ 根據相關系數的計算方法，計算變換后的殘差平方和Q和相關系數R2

　　● Logistic曲線

　　◇ 分別將實測值和預測值進行求倒數變換

　　◇ 將求倒變換后的實測值記作y，將求倒變換后的預測值記作y*

　　◇ 根據相關系數的計算方法，計算變換后的殘差平方和Q和相關系數R2

　　◆ 利用實測數據與擬合數據來進行擬合度判斷

　　由于R2是用于判斷線性模型的擬合程度的，對于非線性曲線，似乎不具有什么理論上的支持，所以，出現了許多針對非線性曲線進行的擬合度判定。下面的方法是其中的一種。

　　● 同樣，計算殘差平方和Q=∑(y-y*)^2和∑y^2，其中，y代表的是實測值，y*代表的是預測值

　　● 計算新的擬合度指標RNew=1-(Q/∑y^2)^(1/2)

　　● 判斷方式：RNew越接近1，認為擬合度越好

　　◆ 利用余弦函數進行輔助判斷

　　從上一種方法中可以看出，在參數個數相同的前提下，擬合值越接近實測值，則認為擬合得越好。由此出現了根據幾何意義得到的方法：若把實測值和預測值視為N維空間中的向量，若它們之間的夾角Θ越小，則可以認為擬合得越好。這里，計算角余弦系數FR=cosΘ=∑(yy*)/((∑y^2)^(1/2)* (∑y*^2)^(1/2))。

　　經實驗證明，RNew的分辨率和靈敏度都較高，計算簡單。實際中，可先用FR初選，再用RNew精選，可能會得到較好的結果。

好像所有帶有‘管理’字樣的東西都變得不那么具體了。

　　一般這個東西就要對癥下藥了，所以首先得知道有什么樣的風險。在實際的工作中主要遇到過以下的風險類型：

　　1、需求變更，這個是最大的風險，因為最后期限是不變的，需求變了，就意味著更多的工作要在已計劃好的日程表中做完。風險可排老大

　　2、人員變動，在一個可以持續2，3個月的項目中，中途可能有人離職

　　3、需求理解問題，由于缺少行業知識，業務背景，有可能對需求的認識不夠透徹

　　4、復查工作沒做好

　　5、需求覆蓋率不高

　　6、測試用例執行沒有達到100%

　　7、測試環境和實際環境有偏差

　　8、測試缺陷很難重現，導致無法定位根源從而沒有修復

　　針對第一條：估計每個公司都在這上面吃過虧吧。所以才有那么多的軟件開發模型。我所經歷過的一些比較大的項目，采用的都是增量迭代的開發模式，所以在每一個小的階段，需求是相對穩定的。但是也有變更的時候，這種時候，我們一般是要求走需求變更流程，根據變更的大小來確定策略：如果變更造成的工作量小于3天/人，作為一個ADHOC項目，如果大于3天/人，就作為另一個新的項目。這個當然要和客戶達成一致。

　　針對第2條：最好是每個崗位培養備份的人員

　　3，4，5條其實可以歸結為一條，我們盡量在需求分析階段就把自己所有不明白，不清晰的問題提出來，整理成一個文檔，先內部回答，這個內部可以包含開發，然后發給需求方請求答案。測試用例評審會要組織好，在開始之前，要求每個人所設計的用例至少被2個不同級別的人員評審過，然后再評審會上確定最終的問題和解決方案，會后跟蹤這些評審會上出現問題的狀態。

　　第6條是完全可以避免的。如果時間確實很緊，按優先級別選擇最重要的CASE去跑。

　　第7條嘛，一般是在搭建測試環境之前，列出一些需要檢查的項，搭好后，讓人按這個檢查項一項一項的去檢驗。

　　第8條，還真沒什么好辦法，如果你有，麻煩告訴我下。我們一般遵循的是只要是出現過的，哪怕一次也是缺陷，都要記錄在案的。也可以在交付客戶時說明并一同交付。

　　說在最后的，做測試肯定要得到老大的支持和重視，否則風險控制都是空談啦。盡量每個階段都要文檔化，規范化。

　　做任何事情都有風險，風險管理無非就是消除，消除不了就減少，減少不了就降低。降低到一定程度就不再有威脅，或者短時間沒威脅，沒威脅就不是風險了。

　　針對測試的各種風險，還是建立一種“防患于未然”或“以預防為主”的管理意識比較靠譜。

　　此文為個人經驗，不對之處請指教。

題外話

　　最近有點心浮氣躁，在幾個群里發過牢騷，有過埋怨，有過稚嫩，有過沖動，也砸了一個鍵盤，一個人晚上散過心，呵呵倒是讓不少朋友見笑了，仔細想想也許是一種蛻變，覺得自己還是很幼稚，不夠成熟，總是想留住年輕，不想這么快老掉，所以無時無刻的都在表現自己，仿佛向所有人說，我還小一樣，呵呵。

　　難得靜下來，整理下思路寫下這篇博文實屬不易，困境從不缺少，能走出困境的人，必有其過人之處，如果能將困境變為利境的人，必有其獨特的見解，或者是人生觀，或者是生活觀，或者是價值觀，總有和人不一樣的觀念。

　　古人云：達者，一日三省吾身。我不是什么達者，但卻能做到三日一省吾身，三日不能醒悟，四日或許就能恍然大悟，四日不能，五日也許就醍醐灌頂了，呵呵。非常感謝侯老師的提醒，也很感謝很多群友，同行的開導，若非如此，也許我還在泥足深陷。

　　原本計劃寫兩篇博文，一為用專業的眼光看待自己的工作，一為我個人的困境，既然現在困境有轉變的趨勢，不如一起寫了下來，作為新人之路系列博文的第五篇博文吧，我相信我的生活和工作都很普通，自然我所遇見的事情，會有很多人也會遇見，這也算是我將自己的一些心得共享吧，別人的始終是別人的，不要試圖完全照搬我的心得，只有自己的才是最好的，吸取百家所長，總結出自己的經驗，寫出自己的心得，那時才是提高了，一味的模仿永遠不能超越。

　　正文

　　最近的工作其實挺忙的，工作確實是測試，但是卻沒有用到測試上的技術，不管是工具，還是用例都沒有用到，只是測試，很多人都是如此，測試，只是測試。

　　其實測試不只是測試。

　　大家都知道測試的兩個發展方向，一為管理，一為技術，如果你發現你所在的測試工作沒有技術的影子，那你是否嘗試過從管理的角度來理解呢？

　　昨日將手上的一個項目從頭到尾測了一遍，整整8個小時，沒有測完，但確實很累，不斷的針對同一個功能點的不同可能性，晚上到家心里疲憊不堪，一點點不順心就大發脾氣，把一個外接鍵盤砸得稀爛還不解氣，又做了幾個俯臥撐，力氣發泄出去了，頭腦慢慢冷靜了，決定出去散散心，專往人少的地方走，環境安靜下來了，心也靜了下來，開始試著分析自己這段時間的情況，那是相當糟糕。

　　問題一，為什么如此急躁，怎么能不急躁

　　太過急躁，因為一些事情，我對自己的要求很嚴格，對自己的職業規劃也很嚴格，有個很明確的目標，最多5年達到什么什么程度，最好3年達到什么程度，仔細想一想其實，真的太急躁了。

　　針對這個問題，我告訴自己，“現在要做的，只是學習和積累，學習什么，學習技術，理論上的知識只能通過自己體會，學是學不來的，并且相對于理論，我的技術已經跟不上理論的成長腳步了，為了讓技術和理論平衡，所以應該學習技術，積累工作的經驗，工作的每一分每一秒都是一種經驗，如何安排工作的空閑時間，如何安排工作，不至于工作量分布不均勻一會強度很大一會強度很小，在和開發人員對Bug進行定位時也可以吸收相關經驗，比如，在界面刪除一個數據，但是數據庫中這條數據還存在，這時就可以根據經驗來判斷有可能該功能是虛擬刪除不是物理刪除，可以說每一個BUG都是一份經驗，區別只是你看見沒有，想到沒有。”如此想來，其實我要學的要做得還有很多，遠遠不是自己所想的沒有可以學的了，自己很厲害了，呵呵現在覺得這種想法很幼稚，學無止境啊，何況自己還是個初出茅廬的菜鳥呢。

　　測試行業所需要學習的東西實在太多太多，如何選擇學什么，單從工作角度來講，目前我工作的內容是WEB測試，工作的內容是功能黑盒測試，并且，接觸不到數據庫，這時，很明確了，我在前面的一篇博文中提及過，要向自動化提高，加之對QTP有一定的了解，但是不夠，那么很自然的選擇了QTP，不怕大家笑話，我只會QTP，但不會用QTP測試，好了，這是我的一個學習方向了。

　　第一個問題解決了，心也靜下來了，對以后至少2，3個月的日子不會再這般迷茫了，為什么是2，3個月？呵呵因為我自信啊，我認為2，3個月我能夠學會用QTP測試，當然不是精通。。。。第二個問題來了。

　　第二個問題，工作這么段時間，自己有沒有得到提高

　　相信也是大家閑暇時常常想起的，測試到底有木有前途，看看人家開發的工作，都是技術上的，項目完了人家的代碼能力實實在在提高了，技術水平實實在在掌握了，再看看自己，這個項目完了，自己了解的業務就都沒用了，雖然不是什么都沒學到，但是和開發一筆卻覺得自己學的太少，因為測試的基礎是業務，是需求，一個項目完了也就意味著你了解的業務沒用了，你了解的需求沒用了，即使你說再做相同的業務能夠容易上手，但假若業務跨度很大呢，這個項目是做管理的，下個項目是做商務的，對比看看現下的招聘內容，熟悉各種自動化工具，熟悉各種數據庫，熟悉各種語言，各種各樣的優先考慮，再來看看自己花了很多時間很多心力做完了一個項目，即使做得很好，你也會覺得自己還是沒有多大的提高，還是不能去應聘薪資高點的工作，你們有這種感覺嗎？

你是否對它有一種責任感

　它，指開發人員對開發出的產品；它是測試人員所面對的測試產品。你是否對它有一種責任感，是指開發人員是否對它開發出來的產品有責任感，為它驕傲，為它而開心；你是否對它有一種責任感，是指測試人員是否對它測試人產品有責任感，是指測試人員更多的站在用戶角度考慮問題，盡量減少要發布產品中的缺陷，達到用戶滿意的程度。

　　如果你（開發或測試）對它有一種責任感，你就會發現，開發和測試之間，本質上是一個合作的過程，我們的目標是一致的，都是為了盡量減少發布產品中的錯誤，提高用戶滿意度。你對它有一種責任感 ，我們就無須進行太多太嚴格的版本控制要求，無須很多的中間環節，我們的產品研發過程將更快捷，質量更好。可是事實上并非如此，我們需要很多的管理環節來約束我 開發和測試過程，因為我們的團隊中并不是每個人都對它有一種責任感。并不是每個人對它的責任感目標是一致的。

　　就我們測試人員來講，作為一個測試人員，一般要經歷過一些成長階段才能做到一個真正對”它”有責任感。

　　一、學習需求＋驗證的過程

　　剛剛涉入測試，往往踏不下心來，感覺測試是件沒完沒了的事情，且簡單重復，枯燥乏味，沒有有激情，沒有成就感。這時候，所做的事，往往是學習所測產品的每個功能，弄清每個功能的最終結果是什么？然后嘗試驗證它，這種測試往往發現的是一些膚淺的表面的問題。

　　二、經歷測試和開發是對立的過程

　　到第二階段，漸漸認識到，測試就是找出產品的缺陷，是證明產品不可用的一種行為。這時候，感覺測試和開發的行為是對立而矛盾的，測試是為了證明產品是有問題的，開發是創造產品的。這實際上是一種誤區。這個時候，會發現一些較嚴重的缺陷。

　　三、學會與開發主動的配合

　　隨著經驗的積累和對工作的深入認識，會發現，開發和測試的目標是共同的，一致的。都是為了減少產品的錯誤，為用戶提供更加滿意的產品。所以，測試人員更多的站在用戶的立場（角度）發現問題，幫助開發析和解決問題。

　　四、責任感＋驗證

　　經過多個項目的需求、開發、測試、維護以及升級的循環過程，逐漸認識到測試介入越早，風險越小；測試投入的時間上更多的會在需求方面，而不僅僅是測試過程本身。通過和最終用戶的多交交流，對用戶體驗有了新的認識，會油然而生一種責任感（如：在公司五周年的活動中，看到我們的用戶對我們的尊敬、感激還有那份熱愛。會讓我們進一步體驗用戶在使用產品時的感受，同時，會對我們的提供產品產生一種成就感。對測試的理解也隨之成為一種對產品的質量意識、產品意識，有時候感覺自己精心”待弄”的是自己的孩子。

　　測試和開發工作實際上是一種榮譽與共的關系，取得的成績和造成的失誤，共榮譽和責任是平等的。與此同時，在遇到問題時，就會盡可能的幫助研發盡快定們bug原因，盡快把問題解決掉。

　　上面幾點是我就測試的一點認識，我想開發的應該也是一樣，也會經歷這樣一系列過程。

　　對它有一種責任感，讓我們的產品更加實用，易用。

　　對它有一種責任感，看大一點，就是要做一個有責任心的人，無論對誰（愛人，父母，孩子，朋友），對事，對物，對社會都有一份責任心。