這些奇怪bug你見過嗎？分享下我在測試中遇到的經典或非經典場景

測試過程中，無論案例怎麼設計、怎麼執行，都需要測試人員有一定的敏感度去發現問題，測試人員的經驗積累無論對於案例的設計、測試執行還是缺陷的發現都有很重要的意義，所以接下來我想給大家分享一些我自己在測試中遇到的經典或非經典場景。

1、需求瞭解不到位

有些問題其實並不算很難或很複雜，只是需要測試人員在測試前仔細閱讀需求，明確需求要求實現的功能、需求給定的請求和應答報文欄位、需求闡明的業務規則，所有需求裡明確寫了的內容在測試中應當務必保證覆蓋。我在測試中遇到的問題有返回報文欄位和需求不一致，業務規則要求取值範圍大於等於固定值，在實現中變成了大於固定值等等情況。相關場景多是疏忽沒有仔細閱讀需求所致，有時候是由於任務多次分解，最後一個接收到程式碼任務的人沒有接觸到需求直接完成了程式碼工作，這種場景就需要測試人員足夠細緻耐心，如果測試環節無法發現，很有可能相關問題就會逃逸到生產上，再次修復成本更高，甚至可能已經產生了負面影響。加我VX：atstudy-js 回覆“測試”，同時領取限量軟體測試學習資料哦~~

2、查詢條件是否包含等於

涉及到查詢交易中查詢條件如何設定需要認真按需求完成，例如上一個問題中提到過的內容。但是也有其他場景，這次遇到的並不是開發程式碼問題，而是我在測試中對程式碼邏輯沒有充分了解所以將正常邏輯誤判為缺陷，開發同事在拒絕缺陷後又解釋了相關場景和邏輯，我認為還是很有意義的一種場景，可以寫下來給測試小夥伴們參考。在某交易明細查詢中，查詢條件有一個是20位時間戳，格式例如：20210101102533760702，在查詢過程中，當上送時間戳欄位的時候，返回的是時間戳大於該值的結果，不包括等於該值的場景，原因是該交易一般取上一次返回的時間戳為查詢條件進行續查，如包含等於的場景會導致資料出現重複。由此可見，是否需要包含等於需要視應用場景而定，避免按自己的理解想當然，同時，相關場景如果不確定或未事先溝通的話，最好充分了解後再確定處理方案。加我VX：atstudy-js 回覆“測試”，同時領取限量軟體測試學習資料哦~~

3、空格在交易中的影響

空格分全形空格和半形空格，我測試中遇到過兩種情況。一種是一致性校驗的過程中，一方資料混入了空格，需要額外進行處理;另外是在查詢過程中，查詢條件輸入的值包含空格，需要考慮是否進行處理。以上兩種情形，對空格的處置需要考慮多種情況，全形空格、半形空格、空格在數值前(例： 20210101)、空格在數值中(例：2020 0101)、空格在數值末尾(例：20210101 )，其中，空格在數值末尾和半形空格的場景相對比較常見和易於處理，另外幾種場景則需要根據需求及應用場景充分考慮、適當處置，避免影響交易執行或交易成功率。

4、資料校驗的適當性

在使用者註冊交易中，個人使用者常常需要使用身份證號進行註冊，通常大家預設身份證號為18位數字，第7位到第14位為8位年月日，但是實際中，有可能出現15位身份證號碼，如果按18位且7-14位為日期進行校驗，有可能攔住部分使用者註冊，導致使用者註冊失敗。因此，在類似的資料校驗中，校驗規則應當鬆緊適宜，如果輸入要素規則明確，可以適當細化校驗規則，在輸入的要素規則不明確的前提下，校驗規則不應過於具體，以保證資料校驗的適當性，避免出現上述問題。

以上是我在近期的功能測試工作中遇到的我認為值得分享的事例。測試工作需要我們常常保持警惕，細緻耐心完成工作任務，同時，在未完全明確的場景中，充分溝通也是非常重要的，提高事前溝通成本總好過大量精力花在時候修改上，溝通成本並不會減少，還要承擔重複勞動修改程式碼的成本。