還是回歸到上一篇文章搜索字段對%的處理方式，可能測試數(shù)據(jù)比較規(guī)范，加上自己也沒有任意造數(shù)據(jù)，查詢報表的測試都沒問題，到了集成環(huán)境測試時異常數(shù)據(jù)比較多，列表頁的數(shù)據(jù)展示與預(yù)期不符，也沒有深入分析原因，直接給開發(fā)提了bug

請先看圖，如下文本框的搜索都為精確匹配

電話號碼搜索.png

查詢某個手機號，發(fā)現(xiàn)數(shù)據(jù)顯示不全，后來一個有一筆單據(jù)電話中含了空格，于是我以為找到原因了就提了bug---【文本框（SAP單號、客戶姓名、電話號碼 ）搜索優(yōu)化，根據(jù)輸入內(nèi)容去掉前后空格進行搜索】

開發(fā)看到這個后一查數(shù)據(jù)庫發(fā)現(xiàn)這個字段的數(shù)據(jù)比較混亂，有些還有文字，源頭上并沒有控制好，圖中客訴單創(chuàng)建時，雖然訂單信息是自動帶出的，但未作只讀限制，仍可以修改，所以存在各種各樣的異常數(shù)據(jù)。

TIM圖片20180124140451.png

（select * from table where length(fieldname)>11，根據(jù)電話號碼超過11位查詢）

電話號碼內(nèi)容.png

開發(fā)也沒經(jīng)需求確認直接改成了模糊搜索，跟我說bug處理好了，而我去跟需求確認的時候，還是維持原來的精確搜索，開發(fā)又得重新改回來，這么一來一回挺浪費時間的

總結(jié)：不要一碰到預(yù)期結(jié)果和實際結(jié)果不一樣的就覺得是bug，先冷靜思考下，分析下具體原因，追根朔源才能找到根本