前些日子聽同事說，***部門做了個工具平台，可以度量每個開發人員所負責模組的ut情況，很感興趣這個平台是如何度量的，於是要了工具的**，準備上去一**竟。
登上平台胡亂看了兩眼，我已經對這個所謂的開發測試能力度量系統失去了信心：我所熟悉的乙個模組，由於系統比較特殊當前實際上並沒有在**提交環節做ut測試，然而，平台上顯示的ut測試充分度評估竟然是100%！這個平台並沒有起到應有的度量作用！
喊來之前的同事了解了下這個平台上顯示的資料背後的統計規則，真是讓我笑掉大牙：平台的統計思路是：要求開發人員自己反饋所負責模組的所有特性和需求內容，將這些資料放入後台作為功能的全集，而後，要求開發在ut用例中標識用例具體測試的是哪乙個特性或需求，然後將其對應起來，而這個所謂的充分度度量，實際上是用已經有用例對應的特性數作為分子，開發人員之前反饋的所有特性數作為分母，通過這個比值算出來的。
稍微想一下都會意識到：分母的資料是開發人員自己反饋的，分母中的用例對應關係也是開發人員自己標識的，既然都需要開發人員自己反饋，讓開發人員給個測試充分度的反饋值就可以了，何必還要計算呢？
所謂度量，最基本的就應該是可信，上文中說的這個平台，度量資料全部要求被度量者自行反饋，資料的可信程度完全取決於被度量者的誠實程度，而如果這個度量資料再和被度量者的利益有所關聯（比如測試充分度達到xx的獎金多發10%，或者充分度不達標影響晉公升、考核等），恐怕這個誠實程度就要打個問號了。看似度量了開發人員的能力，實際上度量的是道德。這裡要說明下，上文提到的我所熟悉的模組，我也私底下找對應的開發人員了解了下，之所以資料是100%，是因為開發人員根本就沒有反饋分母資料---這就更可笑了，平台的設計人員顯然是考慮到分母為0時的容錯的，但是卻沒有結合實際的業務情況作出應有的判斷，在我看來，給0%都比給100%更能說明問題
當然，光是吐槽改變不了任何事情的，鑑於上述問題，我認為要做到資料可信，其實並不難，只要做到資料的客觀反饋即可。最簡單的辦法可以通過轉移反饋人為利益無關者的方式收集資料：分母可以通過專案se反饋，分子資料可以通過測試人員評審後反饋，這樣反饋的資料才能更接近真實；當然，既然做的是度量平台，更多的應該考慮自動化手段，畢竟，所謂的利益無關者也不是總有時間去做反饋工作：分母可以通過構建特性基線資料庫或需求資料庫，從中獲取資料（事實上，公司其實是有這樣的平台並且運作成熟），分子資料可以通過構建ut用例基線庫進行實時統計。其實自動化僅僅是工具，還需要一些流程上的優化，使工具可以落實在日常工作中才行。
總之，無論是自動化度量還是非自動化度量，千萬不要讓能力度量變成道德度量。
中心趨勢度量和度量資料散布
一 中心趨勢度量 中心趨勢度量主要包括 均值，中位數，眾數，中列數 例 屬性salary 單位千美元 以遞增方式排列 30,31,47,50,52,52,56,60,63,70,70,110 1 均值 資料集中心最常用，最有效的數值度量是 算術 均值 對於上面的例子 均值為58 在上面這個例子中，所...
大資料常用度量單位
建立乙個自定義列表 如何建立乙個註腳 注釋也是必不可少的 katex數學公式 新的甘特圖功能，豐富你的文章 uml 圖表 flowchart流程圖 匯出與匯入 你好！這是你第一次使用markdown編輯器所展示的歡迎頁。如果你想學習如何使用markdown編輯器,可以仔細閱讀這篇文章，了解一下mar...
測試資料度量與控制 第一步 度量分析
前沿 這是09年提出過程改進和度量控制的第一步。該文件初步對當前測試專案中有關過程控制的部分與資料度量部分進行了分析。並提出該文件的目錄框架，本次更新第一部分，後續部分會在下週周五之前更新。涉及的相關文件，有興趣可提供模板進行交流。整體的資料收集 度量 彙總規劃，還在整理中，敬請期待.1.測試過程需...