為什么寫這一篇文章否灾？可能大部分測試人員都沒有參與過數(shù)據(jù)庫的設計評審稍算，因為數(shù)據(jù)庫的設計是由開發(fā)人員自己設計的，評審也是開發(fā)人員自己評審糊探，而實際上钾埂，測試人員參與數(shù)據(jù)庫設計評審是很有必要的，但前提條件是要了解需求褥紫，如果測試人員對數(shù)據(jù)庫的設計了解的很清楚的話，那么有很多問題在這個階段就可以避免了（后面會舉例說明）髓考。

　　測試人員如何評審數(shù)據(jù)庫的設計呢？

　　首先绳军，我們可參考數(shù)據(jù)庫設計規(guī)范與原則印机，當然我們沒法關注所有的規(guī)范與原則门驾，但是表名的命名規(guī)范射赛、字段名的命名規(guī)范我們一定要注意奶是，另外就是索引、主鍵以及外鍵的設置也一定要考慮清楚聂沙。之前就經(jīng)常遇到多個開發(fā)人員設計的表和字段的名稱不一致秆麸，比如Ｂ開發(fā)設計的表中用到了Ａ設計的表USER的ID及汉，那么在Ｂ設計的表中他設計了一個user_id字段沮趣，而Ｃ開發(fā)設計的表中也用到了A設計的表user的ID,而在Ｃ設計的表中他設計了一個userId的字段坷随。像這種不一致的情況房铭，一定要開發(fā)修改成一致的温眉。另外考慮到表的查詢速度快慢的關系缸匪，一定要看開發(fā)在建表時使用的索引字段类溢，正常情況使用不能重復的字段建立索引凌蔬，當然也可以建立多個索引闯冷，最好不要超過5個砂心。以前項目中經(jīng)常遇到過索引少了導致查詢過慢的問題蛇耀，加上索引后查詢就正常了计贰。關于主鍵和外鍵不做過多解說了蒂窒，只要理清楚開發(fā)設計的表的關系躁倒，就能清楚表的主鍵和外鍵設計了洒琢。

　　另外秧秉，我們需要關注字段的類型以衰抑、字段的長度以及字段能否為空，這些需要考慮到可擴展性呛踊，但是有些開發(fā)人員在設計表時沒有考慮到這些砾淌，比如數(shù)據(jù)量大的ID設成整型（int）谭网，當然如果設置為長整型（long）是不是會更好一些呢汪厨，另外就比如字段的長度愉择，之前項目中就有開發(fā)人員把URL字段的長度設為100，后面測試時就會發(fā)現(xiàn)只要有URL的數(shù)據(jù)提交都會失敗锥涕，因為URL（購物鏈接）長度都超過了100衷戈。字段能否為空的問題也經(jīng)常遇到過层坠，本來可以為空的字段殖妇，開發(fā)設計時把字段設置成了不為空破花，測試時未填該字段谦趣，直接報錯了。這些都需要注意了旧乞。

? ? ? ?再一個就是跟安全有關的蔚润，在金融行業(yè)中對用戶的私人信息比較看重，所以像身份證號碼尺栖、手機號碼等敏感信息需要進行加密嫡纠。當然這一塊的設計是跟業(yè)務相關的，也需要產(chǎn)品經(jīng)理的確認延赌，之前就遇到一個坑除盏，因為做的也是金融項目，之前用戶的手機號碼都沒有做加密挫以，后面參考別人的系統(tǒng)才發(fā)現(xiàn)敏感信息沒有特殊處理者蠕，所以后面把手機號又全部進行了加密，如果這些問題在數(shù)據(jù)庫設計階段都想好了掐松，我想后面的這些問題就都不會出現(xiàn)踱侣。

　　最后粪小，需要說明的是，作為測試人員抡句，在參與數(shù)據(jù)庫設計的評審過程當中探膊，能把以上幾點弄清楚應該很不錯了，但實際上如果想要提升自己的話待榔，我們還需要根據(jù)需求多思考開發(fā)人員設計的表是否存在其他問題逞壁，比如字段是否冗余？是否需要分庫分表锐锣？表之間的關聯(lián)關系是否合理等等腌闯，總之數(shù)據(jù)庫作為應用軟件的基石，如果數(shù)據(jù)庫設計的好雕憔，那么有很多問題在這個階段就可以避免了。

說明：做了這么多年測試橘茉，我也是在最近這三年中工腋，每一次開發(fā)在評審數(shù)據(jù)庫表的設計時，我都會去參加畅卓，多多少少都會提些問題和建議擅腰，我相信對后面軟件的質(zhì)量是有提升的。