先講乙個故事，年輕的我在寫**時突然燈泡一亮，會覺得某段演算法好像不太好，就向當時的老大申請時間去創造乙個新的演算法。老大當時也沒責怪和限制我，就說：的確存在，但是創造新的演算法並不是件簡單的事，有機會可以去試試，畢竟前人的演算法是經過多次驗證，成熟的。如果花時間創造出來的，可能會引發連帶的問題。
我當時年輕，覺得自己數學功底十分紮實，雖然尊重老大，但內心認為演算法肯定是自己創造的1個更牛b。原則上服從了工作安排，但業餘時間還是花了很大精力搞了乙個演算法出來，隨後演算法做驗證後，還是發現其實和原來的是差不多的，只是把檢查的範圍變小了，自然效率高了。一旦檢查範圍變大，效果反而不如原來的。鬱悶，但一時間執作的脾氣又起來了，結果在回憶看來，完全是消耗了大量的時間做了很多毫無意義的事。
用這段時間我拿來去不同餐廳吃東西和切磋廚藝，將是多麼有意義的事。但是浪費了。這裡不是反對嘗試，嘗試是對的，關鍵字：有用功和無用功。
自我檢討包含幾個問題：
v舊時的我缺乏理論的驅動；
v過於依賴單一的只是工作需要的知識；
v技能運用的熟練度不高，無法舉一反三。
現在的我雖然知道問題在**了，應該是優化核心，周圍8個點傳入getf做處理，同時關注子節點的數量和盡量有效，區分設定點的型別和拐角的特殊處理，一些想法在紙上推算，可以減少直接上機的時間。
下面在轉換到乙個測試上的問題上去，關於效能的。
假定是客戶端cpu的問題，測試應該如何去採集檢視。是檢視整個機器n個進度下的cpu使用率還是目標程序的cpu使用率？如果目標程序的cpu35%，那麼35%算高嗎？多少才符合標準。是哪些因素導致的？測試人員可以排出乙個問題列表和解決問題的優先時間，如果可以評估開啟~至於解決結束時間做為給上面參考是最好了。畢竟測試的很多知識點是和很多職業有一定重合的，可以用溫和的方式去幫助他們，和專案組一起達成專案進度。
我下面套用1個簡單的使用者場景（頻寬和同配置情況下只看cpu）：
固定行為：無快取情況下，進入遊戲，載入完全主場景，進入一場戰鬥。揹包內物品入包和刪除等。根據業務來設計。測試是門嚴謹的學科，關乎效能部分還是要深入去做的。
執行後的一段時間內可以用vbs分段截圖快照，儲存在本地路徑下，也可以盯著電腦手動採集。
場景1：系統只開必要的程序，記錄cpu的使用率和截圖。嚴格執行這套固定行為，檢視一定時間段的cpu使用記錄。
理論和紮實的基礎可以指導你的實踐。結果應該是你需要記錄的cpu不會受到什麼影響。使用記錄的波段都是一致的才是對的。原理可以慢慢了解。
新的場景：如果環境執行是非ie類的產品巢狀的cpu使用率的檢視方式和上面的一樣嗎，需要關注什麼？取多個程序的平均程序？取哪2個呢。可以根據gdi物件來識別，到底是哪個呢？
我自己因為東西多而不嚴謹，在遇到過記錄了一段時間後，一看覺得不對啊，和預估相差太多，果然一看。取樣的地方錯了。
小結：關於效能總結出一句話：盡可能提公升單位時間的處理事物的能力，同時降低延遲，前句和後句都是對的，但放一起無疑是實踐上矛盾的。
當你乙個遊戲的玩起來比較卡。我們首先是不是應該先判斷是客戶端問題，還是服務上的延遲。可以一項項單執行緒去排除，列張黑板圖來看這些問題。
軟體測試考證指導
軟體測試證書 1.國家類 國家官方認可的考試和證書 1.1全國計算機技術與軟體專業技術資格 水平 考試 俗稱 軟考 全國計算機軟體資格考試是由國家人力資源和社會保障部 工業和資訊化部領導下的國家級考試。其目的是科學 公正地對全國計算機與軟體專業技術人員進行職業資格 專業技術資格認定和專業技術水平測試...
Linux上安裝使用boost入門指導
data mining 獲得boost boost分布 只需要標頭檔案的庫 使用boost建立乙個簡單的程式 準備使用boost二進位制檔案庫 把你的程式鏈結到boost庫 1.獲得boost 解壓2.boost分布 boost 1 46 1.boost根目錄 boost 所有boost標頭檔案 l...
Linux驅動 LED驅動測試
環境 主機 fedora12 目標板 mini6410 目標板linux核心版本 2.6.38 實現功能 驅動目標板4個led.說明 led與6410引腳對應連線 led1 gpk4 led2 gpk5 led3 gpk6 led4 gpk7 驅動源 led driver.c cpp view pl...