qa如何高效參與設計評審
目標與方法：帶著如果按這個做出來後，真的能實現我們的需求與功能嗎？用各類使用者場景去構想他的設計與實現是否可行，是否存在遺漏。（即提前去把所需功能按設計的思路，我們在腦海裡來執行一下）對關鍵的設計決定進行驗證，並幫助關鍵專案從設計階段轉化為最後的實現
從下面幾個方面去評審這份文件：
第一：設計方案正確性、先進性、可行性；
第二：系統組成、系統要求及介面協調的合理性；
第三：軟體實現的功能是否覆蓋了產品需求文件中要求的功能；
第四：功能的實現中，是否考慮到了所有可能的分支情況，以及這些分支情況的處理是否合理，和pd要求是否一致；
第五：對於功能模組的輸入引數、輸出引數的定義是否明確；
第六：系統效能、可靠性、安全性要求是否合理；
第七：文件的描述是否清晰、明確。
從以下經驗點，類似問題去著手和參考：
大類
檢查點
資料庫設計相關問題
日期的考慮：預設有creat和modify時間，是否因業務需要增加：審核時間，生效時間，過期時間等
預設值的考慮：需結合業務某操作時該表新插入資料中，各個字段預設值的合理性：如：允許null是否對後繼業務有衝突？
關鍵的狀態標誌/型別標識中，各個值是否有缺失某種狀態/型別的可能，特別需考慮處理失敗和異常的標識；是否要增加某個欄位來標識中間的一些狀態變化的記錄？如取消，失敗？
需結合資料什麼時候插入，什麼時候被更新，什麼時候會刪除。刪除是表記錄刪除還是有狀態標識來考慮，表的設計值是否正確
增減字段：是否增加操作員/審核員字段？是否要有備註字段？或為便於業務未來的查詢，增加一些金額，pv值之類的字段？
是否增減表：是否需要操作日誌記錄表，是否主表與明細表分開？是否要有歷史表來分擔大資料？
有關聯的字段設計型別/長度確認： 如果表中的字段與現系統中其他表字段有關聯或存放內容一致。 需核對原有表字段型別與長度，確認無偏差
表名不可超過25個字元，表字段名稱命名是否合理
vachar型別的長度，是否不需要250長度
結合業務考慮合理性：若表中有多個欄位有各狀態位標識時，務必結合實際業務有哪些型別，這些型別，對應表中各狀態位是什麼來區別，一一分析，找出差錯，那些自我矛盾？是否可以對業務的需求進行支援（只有提前進行這類測試分析，才能確認表設計的合理）
如果設計中使用現有表，對現有表原有資料**必須了解清楚
流程邏輯圖
在有是否這類判斷後面，下一步處理正確嗎？
多個判斷條件，先後順序會有什麼影響？到底哪個應該在另乙個判斷條件的前面，為什麼？是業務需要還是技術實現需要？
是否漏了某個條件判斷嗎？如：是否需要在執行時刻要判斷物件的型別或條件？是否要判斷物件的資料存不存在資料庫中？
對異常或出錯，是否要增加乙個 啟動重新處理資料的指令碼或重試機制？
對併發的處理考慮？特別是介面的處理與資料庫狀態不一時，判斷的處理。
特別是活動等有時間段的業務，qa需結合，多個活動時間段，活動結束/中斷 與下一次活動開始的銜接邏輯。 是否與流程圖中的流轉有衝突？
新老客戶，新老流程，使用者對接，資料對接問題的考慮（老客戶老資料要統一遷移新系統嗎？或新系統對老客戶要有一定控制嗎？）
角色功能關係圖
某角色可以操作的內容，qa應拿著整個流程操作來看是不是各類操作全了？ 另外需以逆向（是否可取消，刪除，退回至上一步）邏輯狀態來考慮
訪問許可權是否合適？ 需進一步區分嗎？需多一些角色人員區分審核嗎？
實現細節與範圍考慮
與其他功能有關聯，其新增的一系列操作，需考慮通知或改變其他相關點
設計中有配置檔案
配置檔案中各值的作用與何時會被呼叫到，需要提前了解清楚
配置檔案中各值哪些是固定的，那些是可隨時在一定區間修改的，哪些配置項修改需要測試，必須確認。
互動和介面設計
互動中的**轉換機制的確認，二邊特殊字元處理清單確認
介面引數與結果中，是否缺少所需內容與資訊
介面通訊與返回異常處理機制確認 （要重發嗎？要預設返回乙個值嗎？）
資料生成有時間間隔時，間隔合理嗎？能連慣展現嗎？如：在介面獲取顯示也有時間段（定期自已重新整理或重取方式等），設計上會因這個時間差而取數不正確
正常業務與異常業務不在同介面或模組實現，對異常退款、刪除、終止等進行記錄時，可能有關鍵id欄位衝突，或異常業務取不到這個關鍵id欄位等
因表中資料**多處進行insert，但又要求某些關鍵字段內容唯一，當多處**併發時，可能會有重覆記錄出現，破壞唯一性要求。
互動時二邊資料唯一性，不應出現重覆記錄的考慮
sql條件審核
在金額統計上計算的正確性檢查
在比對的數字與字元型別不一而會有問題（30 >150是因為進行字元比對）
設計實現的合理性
qa結合對業務的熟悉，提出更好的設計實現方案
實現的可測試性的考慮
考慮實現是否有效能問題
如何高效地做設計評審
設計評審 design review 即在真正開始開發之前，組織一次或多次會議，先評審設計，以降低日後返工甚至專案失敗的風險。相信工作過一段時間，開始主導乙個功能模組甚至整個系統的同學，都對設計評審不會陌生。今天偶然看到了一篇亞馬遜vp及distinguished工程師brad porter的一篇部...
資訊系統設計評審的工作該如何開展
資訊系統設計評審的工作該如何開展 摘要 由乙方出具設計方案的大中型的資訊化系統，通常會組織較為正式的設計方案評審會，一方面意味著甲方基本認可乙方的方案，另一方面意味著乙方將對照專案目標勾畫出具體的框架，並從此開始圍繞這個框架而開展具體的開發建設工作。那麼，如何做乙個有意義的設計評審，將是本文關注的重...
如何設計高效合理的MySQL查詢語句
從大多數系統的應用例項來看，查詢操作在各種資料庫操作中所佔據的比重最大，而查詢操作所基於的select語句在sql語句中又是代價最大的語句。從大多數系統的應用例項來看，查詢操作在各種資料庫操作中所佔據的比重最大，而查詢操作所基於的select語句在sql語句中又是代價最大的語句。舉例來說，如果資料的...