記錄用戶的測試點

1.身份證和活體的測試

a:若是身份證拍攝是斜的或者是反的，那麼進行活體檢測的時候，驗證是否能驗證成功

 

 

2.身份證的測試

a:時間的測試，當時間的格式爲長期的時候，驗證下是否正確

b:時間的測試，當時間身份證過時的時候，驗證是否正確

c:身份證的測試  X是大寫和小寫的區別

 

3.AB分流測試，若是比例50%後又有一個5%，則要考慮這個5%是否包含在了50%裏面

 

4.運營商：

a:假設進行運營商驗收時，提交時快速屢次提交，致使一次操做有多條數據，且數據結果不一致，那麼應該取最新的一條成功的數據，而不是最新的一條數據(有可能失敗的)

 

1.慢查詢 緣由：1.沒有索引或者沒有用到索引 2.I/O吞吐量小，造成了瓶頸效應 3.沒有建立計算列致使查詢不優化 4.內存不足 5.網絡速度慢 6.查詢出的數據量過大（能夠採起屢次查詢或者其餘方式下降數據量） 7.鎖或者死鎖，程序設計的缺陷，緣由是讀寫競爭資源 8.返回了沒必要要的行和列 9.查詢語句很差，沒有優化 優化查詢方式 1.把數據、日誌、索引放到不一樣的I/O設備，增長讀取速度，數據量越大，提升I/O越重要 2.縱向、橫向分割表，減小表的尺寸 3.升級硬件 4.根據查詢條件，創建索引，優化索引，優化查詢方式，索引應儘可能的小，使用字節小的列建索引好，不要對有限的幾個值的字段建單一索引 5.提升網速 6.增長服務器CPU的個數，例如單個查詢的排序、鏈接、掃描和group by字句同時執行，SQLserver根據系統的負載狀況決定最優的並行等級，複雜的消耗大量的CPU的查詢最適合並行處理 7.若是使用like進行查詢的話，簡單的使用index不行，全索引耗空間 8.編寫SQL時候須要注意與索引相關的規則，字段類型轉換致使不用索引，如字符串類型的不用引號，數字類型的用引號等，這有可能會用不到索引致使全表掃描失敗；不要使用select * 排序請儘可能使用升序；or的查詢儘可能用union代替，rder by / group by 字段包括在索引當中減小排序，效率會更高。儘可能規避大事物的SQL，大事物的SQL會影響數據庫的併發性能以及主從同步；分頁語句limit的問題，刪除表全部記錄用truncate不要用delete 2.mysql和redis的區別 接口冪等 https://blog.csdn.net/jks456/article/details/71453053 接口異常處理 卡夫卡 mq mysql與redis區別 mvc tomcat resin 如何給全部人賦可執行權限 chmod +x py切片 查詢進程的命令 nginx怎樣處理一個請求，越詳細越好 nginx限流指令 自動化case失敗的緣由 解決辦法 經過率 如何指定個性化測試報告 數據庫事務 數據庫group by和having的組合查詢 接口測試關注點 redis應用場景是什麼 mysql左右查詢的區別 壓測關注點，怎樣進行壓測的 CR的關注點（鏈接池、創建鏈接、關閉鏈接等、大併發數據的處理、異常邏輯處理、與數據庫redis等的交互以及形成的影響） redis 異步，redis 加鎖 算法： 1.矩陣長M，寬N，外層打印.內存打印*的算法，數組排序，數組 2.快速排序 3.冒泡排序 4.二分查找 5.[1,5,2,3,5,8,4]每兩個數求和大於6的兩個數字 6.怎樣用代碼實現tail –f的功能 7.字符串翻轉 linux裏的swift eval 索引的類型，爲何要創建索引 mysql如何刪除某一列 //ALTER TABLE version_info ADD COLUMN lishan varchar(64) //ALTER TABLE version_info DROP COLUMN lishan mysql事物 清理磁盤的shell腳本 https的ssl原理 es mq 卡夫卡

 5.查看日誌