本文部分內容借鑑於部落格需求評審的關注點
1、評審前期準備
評審是要在寫**前發現問題，不要吝嗇將時間花在前期上，因為這會大大減少我們中後期的意外，避免做很多的無用功。在評審之前，我們要仔細閱讀相關的評審資料，了解每個點是幹什麼的。
2、評審中需要關注的點
（1）文筆
描述是否存在錯別字，特別是介面上的文案。例如，登陸->登入（2）邏輯性描述是否清楚，是否存在歧義
沒有統一術語，多處地方用不同詞語來表示同一概念
是否雜亂無章，不便於閱讀和查詢資訊
流程的出入口：是否明確，是否過多（連使用者都會昏頭轉向）（3）實現條件與規則說明是否清晰明了
缺少說明資料的**、型別、精度、取值範圍、預設值、顯示格式、計算處理方式
是否考慮其它功能或需求的關聯影響
使用者體驗如何
人力、時間等資源是否存在困難3.其他實現難度較大
遺留的坑會導致出嚴重bug的概率大，風險高
效能不佳，會造成使用者體驗差
是否有比產品經理想到的更好的方案
能否復用已有的邏輯或使用業界更通用的有開源實現的做法
後續的迭代考慮，是否在設計上預留可擴充套件性
不重要的部分（例如後台系統）由開發自行決定介面和互動
在評審的過程中，我們要站在使用者的角度去思考，站在使用者的角度去提出問題
對於新需求來講，若出現開發和設計人員爭執的情況，這時試人員就需要作為第三方站在使用者的角度去剖析問題。否則，有些需求實現之後，在進行fut測試的時候，才發現不合適，那之前做的工作都白做了，這就是資源的一種浪費
乙個測試人員設計出的測試用例，可能會存在考慮不周的問題，如果沒有及時的發現這些問題，就可能會出現使用者發現問題導致對產品產生不好的影響。所以測試用例設計出來後，如何保證它的質量呢？這時我們將多位測試人員聚集在一起，集思廣益，就有了用例評審。用例評審又分為正式評審和非正式評審。
1、評審方式
測試用例的評審有很多種，但是最敏捷應當是臨時的同行評審。同行評審，尤其是臨時的同行評審，應當演變成類似結對程式設計的一種方式。從而體現出敏捷的「個體和互動比過程和工具更有價值。」要體現出測試用例設計者之間的思想碰撞，可以通過討論、協作完成測試用例的設計。原因很簡單，編寫的測試用例需要盡可能的覆蓋全部需求，而測試人員的思維總會存在缺陷，乙個人的思維總是存在侷限性，所以需要大家一起來設計。
結對程式設計：一種敏捷開發的方式，指兩個程式設計師在一台計算機上共同工作。乙個人輸入**，另乙個人審查他輸入的每一行**。輸入**的人叫做駕駛員，審查**的人叫做觀察員（或導航員），兩個程式設計師經常互換角色。
由測試負責人組織開展會議，用例編寫人對用例就行講解，參會人員有異議的當場提出。2、用例評審內容
在進行用例評審的時候，我們要準備的材料除了測試用例之外，還有測試方案。一般我們都用xmind工具來編寫測試方案，
3、歸檔用例
歸檔用例就是在用例評審結束之後，將評審中的意見建議修改之後的用例提交到對應的平台上，這就叫做用例的歸檔。最遲的用例歸檔時間是在專案版本整合之前。歸檔用例主要是給其他的測試人員看的。
軟體需求評審 過程階段評審
過程階段評審，無評審，不過關！還記得在我們還是學生的年代，每次考試交卷前都會檢查好幾遍，生怕錯漏了什麼，實際上就是開展了一次評審活動，評審的人是你，評審的物件是那份卷子，評審的目的是為了發現問題並修改。在軟體生產過程中，涉及到一道道環節，軟體生命週期從專案啟動到需求，緊跟著設計，然後開發，之後測試，...
用例評審交流
用例評審交流 用例的特徵 1 最有可能抓住錯誤的 2 不是重複的 多餘的 3 一組相似測試用例中最有效的 4 不要太簡單，也不要太複雜。用例評審交流 用例的意義 1 組織性 有利於測試的組織 2 功能覆蓋 確保功能不被遺漏 3 重複性 有利於測試的重複 4 跟蹤 有利於測試的跟蹤 5 測試確認 在少...
怎樣進行需求評審？
一 注意對需求規格說明的正確性進行評審 需求規格說明的正確性通常可以從如下方面得以體現 1 是否有需求與其他需求相互衝突或者重複？2 是否清晰 簡潔 無二義地表達了每個需求?清晰 是讓人能夠讀懂 簡潔 是讓人願意去讀 無二義 決定 讀 的效果,是讓大家對需求描述的理解能夠達成一致 3 是否每個需求都...