Android軟件測試的需求評審是什么

這篇文章主要講解了“Android軟件測試的需求評審是什么”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“Android軟件測試的需求評審是什么”吧！

需求評審

1．需求階段評審的角色和職責

一句話，根據具體情況選擇相關人員，充當相關角色，履行相關職責，大家也別吐槽我，現實就是這樣，別去記憶這些死規則了

2．好的需求應具備的特點

完整性：每一項需求都必須將所有要實現的功能描述清楚，以使開發人員獲得設計和實現這些功能所需的所有必要信息。

正確性：每一項需求都必須準確的陳述其要開發的功能。

一致性：指與其它軟件需求或高層需求不相矛盾

可行性：每一項需求都必須是已系統和環境的權能和限制范圍可以實施的。

無二義性：對所有需求說明的讀者都只能有一個明確統一的解釋，由于自然語言極易導致二義性，所以盡量把每項需求簡明的用戶性的語言表達出來。

健壯性：需求的說明中是否對可能出現的異常進行了分析，并且對這些異常進行了容錯處理。

必要性：可理解為每項需求都是用來授權你編寫文檔的“根源”，要使每項需求都能回溯至某項客戶的輸入。

可測試性：每項需求都能通過設計測試用例或其它的驗證方法來進行測試。

可修改性：每項需求只應在SRS中出現一次。這樣更改時容易保持一致性。另外，使用目錄列表、索引和相互參照列表方法使軟件需求規格說明書更容易修改。

可跟蹤性：應能在每項軟件需求與它的根源和設計元素、源代碼、測試用例之間建立起鏈接鏈，這種可跟蹤性要求每項需求以一種結構化的，粒度好(f i n e - g r a i n e d )的方式編寫并單獨標明，而不是大段大段的敘述。

分配優先級：應當對所有的需求分配優先級。如果把所有的需求都看作同樣的重要，那么項目管理者在開發或節省預算或調度中就喪失控制自由度

以上特點也是需求評審的要點，評審前可以根據實際情況指定需求評審檢查表來幫助評審。

可以根據以上特點對需求進行評審

3．軟件需求評審輸出

還是一句話，根據具體情況適當的做好評審記錄，形式不限，輸出文檔名稱也不限，隨便你取，^^內容才是重點

4．組織需求評審原則

還是一句話，組織自己定吧，適合就好，效率優先 ^^，別吐槽，沒騙你的，不信你百度去，可以百度出不同答案

5.需求評審形式

總 體來說可以分為正式評審與非正式評審。正式評審是指通過開評審會的形式，組織多個專家，將需求涉及到的人員集合在一起，并定義好參與評審人員的角色和職 責，對需求進行正規的會議評審。而非正式的評審并沒有這種嚴格的組織形式，一般也不需要將人員集合在一起評審，而是通過電子郵件、文件匯簽甚至是網絡聊天 等多種形式對需求進行評審。2種形式各有利弊，在評審時，靈活地利用這2種方式。

仔細來說，可以分為如下：

(1)相互評審、交叉評審( Pear-to-pear Review )，甲和乙在一個項目組，處在一個領域，但工作內容不同，甲的工作成果交給乙審查，乙的工作成果交給甲審查，相互評審是最不正式的一種評審形式，但應用方便、有效，被普遍使用

(2)輪查( Pass-round )，又稱分配審查方法，是一種異步評審方式。作者將需要評審的內容發送給各位評審員，并收集他們的反饋意見。是一種一種非正式的同行評審。

(3)走查(Walkthrough )，產品的作者將產品在現場向一組同事介紹，描述產品要有怎樣的功能、結構，從頭到尾走一遍，以收集大家的意見。希望參與評審的其他同事可以發現產品中的錯誤，并能進行現場討論這種形式介于正式和非正式之間，其應用普遍。是一種一種非正式的同行評審

(4)小組評審(Group Review)，通過正式的小組會議完成評審工作，是有計劃的和結構化的評審形式。評審定義了評審會議中的各種角色和相應的責任，所有參與者在評審會議的前幾天就拿到了評審材料，并對該材料進行了獨立研究。

(5)審查(Inspection )。審查和小組評審很相似，但更為嚴格，是最系統化、最嚴密的評審形式，包含了制定計劃、準備和組織會議、跟蹤和分析審查結果等。

6.需求評審的策略

(1)分層次評審

一般，可以分成如下的層次：

*目標性需求指整個系統需要達到的業務目標，是最高層次的、基本的需求，是企業的高層管理人員所關注的。如果讓具體的操作人員去評審目標性需求，容易導致“撿了芝麻，丟了西瓜”的現象。

*功能性需求指整個系統需要實現的功能和任務，是目標之下的第二層需求，是企業的中層管理人員所關注的。

*操作性需求指完成每個任務具體的人機交互〔UI)需求，是企業的具體操作人員所關注的。

(2)分階段評審

應該在需求形成的過程中進行分階段的多次評審，而不是在需求最終形成后才進行僅有的一次評審分階段評審可以將原本需要進行的大規模評審拆分成各個小規模的評審，這樣就降低了需求分析返工的風險，提高了評審的質量。

這點對于敏捷開發模式特別有效。需求按版本為單位劃分，根據版本進行需求評審（確定做啥，是不是那樣做），通過后開發針對該版本需求進行開發，測試根據需求進行用例編寫和維護，然后按這種模式進行迭代。

7.注意事項

精心挑選評審人員->定制規范化評審流程->準備好評審材料->做好結果跟蹤工作等

關于需求評審

1、 傳統的軟件開發模式中，太過依賴文檔，有各種各樣的文檔，需求說明書，比如市場需求說明書，業務需求說明書， 軟件概要說明書，軟件詳細設計文檔等等，這些文檔在追求速度的時代卻似乎效用不大，很多時候反而成了負擔。怎么解決這個問題？

去掉無用的功能定義文檔、需求文檔可行方法：

想法快速制作成靜態的原型->>根據“市場效果反饋”修改原型設計->>用真實數據建立一個動態原型->去除累贅

這樣，以實際的界面或原型來說明你要構建一個真正的產品，是很好的方法。

從這個點出發，我們可以把重心從“需求文檔評審”轉移到“原型(Demo)評審”,以原型評審為中心，輔以必要的文檔說明，作為原型的補充。

2、 三方協作

也就是說，每項功能需求的討論都要開發人員，測試人員，產品人員的參與，有參與才有認同，開發前必須達成一致

3、各種評審會上，一定要有個能做決定的人，因為評審的時候各方不可避免地會對需求有不同理解，從而出現爭論，公說公有理，婆說婆有理，誰也說服不了誰。

感謝各位的閱讀，以上就是“Android軟件測試的需求評審是什么”的內容了，經過本文的學習后，相信大家對Android軟件測試的需求評審是什么這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！