調測中的反思

2022-02-24 06:36:15 字數 2580 閱讀 4682

在正常的cmm專案中,測試包括了ut/it/st/bbit/sdv/sit/svt/beta等,目前專案運作仍然處於st前的單模組調測階段.

由於本次負責的模組進行全新的重開發,因此該階段的除錯任務顯得尤其繁重.

在調測之前,調測任務已經進行有效的分解,基本的原則是由簡入繁,由淺入深,穩紮穩打,步步為營.

100%

版本編譯:                       50 %

問題定位:                       20

%問題修改驗證:                10 %

版本演進引入問題分析:       10

%其他:                            10

%從上面的資料分析中,在調測活動中,實際上有效的時間僅僅佔了總時間的3成,也就是說剩下的約7成的時間在從事著非實際有效的調測活動.以目前15工作日計算, 有效調測時間僅僅約4.5天.

也許你並不贊同我上面資料的分析,

版本編譯/版本演進中引入問題分析和定位以及其他有些活動並非與調測活動無關聯,相反,這些都是在調測中不得不需要完成的活動.我承認如此.因此我把調測活動本身稱為實際有效調測活動,而將與調測活動關聯的一些其他必要或者非必要的活動統一稱為非實際有效調測活動.

下面,我們將分別針對該兩類活動來**如何更加有效的提高我們的調測效率.

實際有效的調測活動主要包括了問題定位和問題修改驗證.從表面看似乎遇到問題,定位和驗證是無法避免的.因此該活動時間似乎也沒有可以節減的空間.但是深入分析問題的根源,

就可以很容易找到提高調測效率的有效方法.

以目前我所從事的調測活動中,所以遇到的問題主要分布如下:

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

所有問題:                      

100%

copy引入問題:                60 %

筆誤:                            35

%功能性問題:                    5  

%-------------------------------

低階錯誤:                       95 %

在調測前,一般需要進行ut和review.對於低階錯誤,一般充分的ut和review活動可以完全發現.而在所有的調測問題中,低階錯誤佔了95%,

從調測過程來看,也說明了該問題:

越是充分ut和review的**,調測過程所遇到的阻力越小.以曾經的乙個低階錯誤為例:如果review,可能花費的時間代價約30分鐘,但是調測中為了解決該問題,則花去了約一天的時間.從發現問題的效率比較來看,可以作如下的排序:

調測<< ut < review(他人) <

review(本人)

因此在調測前安排充分的ut和review是必不可少的,也是提高最終調測效率的很好手段。

非實際有效的調測活動主要包括了版本編譯/版本演進引入問題的分析和定位/其他一些活動。

版本編譯和調測實際上是並行的活動,我想地球人都知道。但是在實際的調測中:你的**如何做到讓版本編譯和調測過程足夠並行呢?這卻決於良好的軟體架構設計。如果你在架構設計中,做到了子模組間功能的獨立和低依賴性,也就是常說的高內聚,低耦合,同時在設計之初,能考慮更多的容錯性設計(比如一些錯誤情況的替代模組,通過替代模組,可以對一些出錯模組進行規避性替代,從而不影響到對其他子模組的功能調測)。好的設計,可以充分保證在改錯後的版本編譯與實際有效的調測活動可以並行開展。

版本編譯還有乙個最直接和最有效的手段就是採用功能更加強大的電腦和編譯工具。目前公司內部大力推廣的分布式編譯就是屬於後者。

版本演進中引入問題的分析定位時間的節儉主要依賴於嚴格的版本發布機制。一般乙個新的版本的發布經歷如下的階段:

**問題修改->問題驗證->合入->主線驗證->其他基本功能驗證->發布

嚴格執行上述的流程將可以將調測中版本演進引入的時間耗費完全杜絕。版本演進過程最好盡量平滑,嚴格控制每次版本合入問題的解決數是乙個很好的手段。

最後乙個其他活動主要看個人的時間管理習慣而言。但在調測階段,盡量採用優先與調測活動強相關活動的時間管理策略。

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

總結:在上面的分析中,我們其實都忽略了乙個基本的東西:專案管理的理性和合理性。

專案管理的理性是指:充分認識到專案管理中對流程的嚴格執行的重要性。一些冒進的做法,看似在與進度搶時間,殊不知其實已經對進度拖了後腿。以本次專案中之前的調測過程為例:未經過ut和review的**,直接進行調測,最終獲得的是慘痛的教訓。

專案管理的合理性則是指:在理性的制定專案計畫中,提供可行的專案計畫方案。

同樣本次專案中最初計畫存在不合理性也在於(就本模組而言):15k的**量(完全新寫),

初始計畫:15工作日,

整個專案週期中,工作量為170行/日

修正計畫:40工作日,整個專案週期中,工作量為100行/日

儘管修正計畫的工作量仍然大大高於了公司的基線值(30行/日),

但至少相比於第乙個計畫,還稍具可行性.

如果按照理想的情況下:根據上述總總的調測效率提公升手段後,目前15天的調測時間將縮減為15*6.5% =

1天.ps:今天情人節,定了99多玫瑰確是送給朋友的老婆...無奈..........

移動端調測方法

引入對應的vconsole.js,移動端開啟即可 全域性安裝weinre npm g install weinre建立資料夾,例如 e program mobile weinree program mobile weinre 資料夾下安裝 區域性安裝 npm install weinre 執行wei...

Android真機調測Profiler

u3d中的profile也是可以直接在鏈結安卓裝置執行遊戲下檢視的,匯出真機鏈結u3d的profile看資料,這樣能更好的測試具體原因。大概看了下官方的做法,看了幾張帖子順帶把做法記錄下來。參考 用安卓真機調測profile的資料,其實就兩種方法,wifi和adb的方式。其實一般用的都是adb方式,...

mysql 效能壓測後調優 MySQL效能測試調優

mysql效能測試調優 作業系統 基本操作 檢視磁碟分割槽mount選項 mount 永久修改分割槽mount選項 系統重啟後生效 修改檔案 etc fstab 中對應分割槽的mount options列的值 sudo t ext4 o remount,noatime,errors remount ...