說道測試流程，很多人都知道需要評審，然後根據需求設計用例，然後測試。那麼評審測試究竟在幹嘛呢？我概述一下我以前剛工作問周邊同事的理解，他們是這麼樣說的：
作為乙個測試的角度評價這個需求，看需求完不完善，**有補充的地方，**有改進的地方。然後我抱著這樣個心態做了兩年測試，然後發現，每次評審其實測試都屬於最打醬油的型別，評審玩之後除了了解需求提提小改進的地方外其實並沒有什麼實質的對測試有幫助的作用，不信可以試試不去評審和去評審，一輪測試下來其實效果相差不大。
所以進入今天的重點了，評審的實際意義其實是去發現產品的價值的，你要做的是找出這個需求的重點，吸引點，並合理初步規劃出適合這個需求的測試方案。
我們除了關注於這個產品需求的測試細節，更重要的是從整體把控這個需求的意義，我很喜歡我上個公司老闆的一句話(當然目前已經加入其他公司了)，當時公司產品使用者量持續下降，研發人員也是嚴重流失，產品也提出了很多功能，結果放到老闆那裡去，老闆說這些功能都不做，我們不做沒有意義的功能，一點價值都沒有功能加上去，完全是浪費時間，結果那些寫了好多天的需求全部砍掉了。
所以，作為乙個測試，也應該是要有產品價值觀的分析能力的，在看到需求的第一眼，不是應該怎麼去測，而是應該先思考這個需求的重點在**，價值在**，然後第二步才去設計測試點。然後我以產品為導向的分析，是這樣的：
那麼抱著這三個目的，我會這麼樣分析：
在不同網路下切換的邏輯
不同機型的相容，是否相容
是否支援來回拖動，拖動後不費流量
… …
那麼綜合使用者價值和測試角度，我會這樣測試：
輸出效能對比報告
加入網路流量和記憶體的專項效能測試
覆蓋相容性要重點覆蓋
&& 常規的測試
以使用者價值角度設計測試點，是在基礎測試的基礎上，從另乙個更高的角度去發現問題，去保障質量，我想這才是乙個正真的測試工程師吧！
ok，今天就聊這麼多吧，有兩周時間沒寫東西了，都把事件花在找工作上了，不過還好進入了一間不錯的公司
從設計角度分析MVC
ps 原來寫文章是從來也不寫提綱的，現在通過不斷的設計訓練和 注釋的影響，沒提綱就寫不下去了 言歸正傳，mvc作為一種軟體設計模式，它用一種業務邏輯 資料和介面顯示互相分離的方法組織 將業務邏輯單獨封裝，使得在介面及與使用者互動的形式改變時不影響到邏輯。1 模式簡介 mvc是一種建立web應用程式的...
Java記憶體模型之從JMM角度分析DCL
dcl，即double check lock，中衛雙重檢查鎖定。其實dcl很多人在單例模式中用過，lz面試人的時候也要他們寫過，但是有很多人都會寫錯。他們為什麼會寫錯呢？其錯誤根源在 有什麼解決方案？下面就隨lz一起來分析 我們先看單例模式裡面的懶漢式 public class singleton ...
從使用者角度看BI系統中資料分析模型的層次
經營層次的分析模型是按照業務環節 業務環節是業務流程中的業務事件 交易事務等業務操作單元 組織的多維分析資料模型，一般情況下每個業務環節包含一到兩個分析模型，該層次的分析模型一般儲存細節粒度的事實資料，以便滿足該環節的未知分析需求對維度組合及資料聚合等方面的靈活要求，同時也能夠避免當業務流程發生改變...