2、原理的必要了解。這個還是要看情況，一般內部測試有必要去了解原理，方便實際搭建測試平台。也方便後面的進一步分析和優化。第三方測試或者收錢應付的就不要去深入了，但是一些基本的還是要去了解，特別是涉及到輸入輸出資料的。其實涉及到演算法測試，測試平台搭建和測試資料產生方法很關鍵，這些事必須對原理有一定了解的，當然越深入越好，甚至可以直接提出優化建議了。
3、巧妙地利用輸入資料變化和輸出變化趨勢來做判據。如何去判斷測試用例執行結果有時很難。在找不到參照標準的情況下，有些這種方法也許能夠啟發使用專案內部比對來判斷。例如：輸入資料新增一些小的限制，來觀察變化趨勢（例如：路徑起點終點相同，中間設定不同經過點）；把輸入資料顛倒來處理（比如：導航測試，終點和起點倒置，觀察路徑差異）
例如第4章導航評測中，路徑優化其實是沒有絕對好、壞用例的。引入計程車資料和競品資料來綜合評估，就可以有乙個相對合適的判據來初步確定資料了。
1、很重要的是，搭建測試平台。一般演算法測試，比較難的就是大量測試輸入資料如何產生；實際梳理或模擬執行如何加速執行；產生的大量輸出資料如何抓取、篩選和處理。選好工具，方便資料產生、抓取中間結果、方便分析就很重要，必要時要自己開發。
2、不要忽視從設計方法角度要求開發方講解和討論。實際情況是，新設計的演算法或者業界沒有先例的一些演算法，一般大家都是摸石頭過河，千萬別迷信設計者。大家交流討論一番是不會有損失的，可能他們沒有拿到實測資料時也是一臉懵的。但注意，這種討論一定要在搭建測試平台，實際有一些測試工作開展，並且發現一些小問題後開展比較好。讓他們講解時，可以發現一些假設和現在實際或者實測發現的不和諧的地方。
3、資料處理盡量自動化和視覺化。例如，語音轉換成文字；位置資訊轉變成經緯度，總之，要方便自動化處理。通常需要考慮用指令碼的方式，隨機產生大量資料；資料處理一般可以用python之類的指令碼語言編寫小工具，自動化地篩選、提取、儲存成方便處理的格式，然後按照需求自動處理成要求的報告。
但是，這種靠簡單分析就發現問題的機會是可遇不可求的。工程問題居多的，終究還是要靠正確方向下的多次試驗、驗證、調整來摸索找到合適的結果。這也是雖然我做了很多專案測試，知道各種問題拆解開來分析可以解決，但是拆解的機會不會給你啊。第三方測試就更加sb，你可以紙上談兵頭頭是道，但是沒有行業背景、缺少可支配的時間和資源，終歸就要認慫了。
ps：前面在做效能測試學習筆記，其中負載均衡演算法、集群排程演算法、快取機制演算法等，很適合用來做演算法測試的例子啊。2019/1/21。
Oracle認證的一點淺見
關於認證的看法 證書這真是個好東西啊！多少人為它花盡心思，花盡金錢的去得到它。它也正被人理解成。有了證書才能找到好的工作！沒錯，在以前的確是這樣。但現在已經發生了很多變化！以前考證書複習資料很少，要想考過試拿到證書，完全是通過努力得來的，而現在，考證書我大家都是在背題庫吧。考的人多了，當然就越來越不...
關於測試的一點思考
測試部門接手乙個專案 產品的流程及關注點 1 明確產品需求 i.顯式需求 功能 效能 ii.隱式需求 安全性 應用場景等 2 確定產品定位 在效率 安全性 效能 易用性等方面的定位 2.5 確定產品質量目標 專案規範 驗收標準 執行維護標準等 3 知道產品使用者 其教育背景 偏好等，便於提取場景，增...
一點一點進步
requestparam,是獲取前端傳遞給後端的引數，可以使get方式，也可以是post方式。若前端傳遞的引數和後端接收的引數名稱不一致，則必須要標註。pathvariable,是獲取get方式，url後面引數，進行引數繫結。1.裝箱就是講基本資料型別轉換為包裝類，拆箱就是自動將包裝類轉換為基本資料...