識別廬山真面目——分析需求
測試需求的獲取，是測試工作邁開的第一步，這在上節做了介紹，接下來是在有了需求後，如何理解它、分析透它，成了問題的關鍵。也只有解決了這個問題，才能提取出具體的可操作的測試物件出來。
1、快速理解需求的捷徑：需求宣講
軟體需求是軟體專案開發的依據，代表著使用者的需求，是軟體設計及軟體測試工作的入口，在整個軟體專案開發過程中起著舉足輕重的作用。對需求的理解是否到位，在很大程度上影響著開發過程的效率。曾經有個小專案（整個專案時間約兩個月），需求不多，在進行需求評審時，包括開發及測試人員都認為理解了需求，但在後來版本測試中才發現，有乙個重要需求點，開發人員與測試人員的理解完全不一樣，到底誰的理解才是對的呢？雙方找來需求討論，恰恰需求設計人員對這一塊的理解也講不太清楚，寫在文件中的描述就更不用說了。也就為此一點，開發整改設計及編碼，測試整改測試方案及用例，最後版本的發布推遲了兩周。俗話說「吃一塹，長一智」，通過這樣的專案事例，我們需反思整個開發過程做得不夠的環節，就「開發過程中如何更好地理解軟體需求」有以下幾方面的最佳實踐。
介紹需求的背景：需求編寫人宣講需求，介紹需求的使用者背景。這點很重要，讓開發及測試人員能清楚知道使用者的用途，實現後的軟體是用來做什麼的、能滿足使用者哪些要求、能給公司創造什麼樣的價值等，使開發及測試人員的工作目標很明確，處處從使用者立場考慮。
需求宣講內容：需求宣講是否需把所有內容都講一遍？回答是肯定的。正如前面所述，需求的至關重要性，如果需求內容多，可分開多次宣講。當然講解時，也要分開重難點，對於大家容易理解的需求（如之前專案做過或眾所周知的需求）可以幾句話帶過。
輔助答疑式宣講：在需求宣講時，對專案組成員收集到的問題，一一進行解釋，回答提問者疑問的同時，也分享給其他同事。
有乙個事實我們不得不承認，需求不可能詳細到面面俱到，總會存在著隱含需求，這種隱含需求的理解會體現出你對需求的掌握程度。對於這種情況怎麼辦呢？無論對於開發還是測試，如果自己意識到了，但不能確認，把問題記錄下來，與需求確認，並要求需求補充明確。
需求的設計也不可能是完美無缺的，在測試活動的整個過程中，特別是在設計用例的過程中，測試人員會發現不少有需求定義的bug，此時把它也錄入缺陷庫，作為乙個缺陷來跟蹤管理是乙個不錯的方法。俗語說「好記性不如爛筆頭」，事實證明，只在口頭上說的事，需求人員容易忘改需求，使得最後測試用例與需求對應不上，且給後續加入專案人員的工作增添麻煩。後面常會發生「這個地方的需求與實現不同，是以需求還是以實現為準」的局面。
2、需求定義也會錯並不是謊言
需求定義是否存在二義性，一直以來是衡量需求是否明確的乙個標準。儘管需求設計人員採用了圖、表等**並茂的方式來表達，但面對有著不同背景的讀者群，同樣一段話，理解的結果就是不一樣。特別是對於一些需要有一定背景知識的需求，不是理解不到位，就是理解錯誤，這也就有了顯式需求與隱式需求的叫法。顯式需求指有明確定義的一系列約束軟體實現的要求，可以是有給定具體值的資料字典，或有序的業務流程圖，或一段介紹業務功能的需求描述等。隱式需求並不是需求設計人員特意隱藏，更多的是由理解人員對某方面專業知識，或對產品的業務了解程度有限導致的。例如：某軟體需求中有一句這樣的定義「對使用者產生的資料，需每天定時備份（預設為每天晚上12：00，使用者可設定），並可按需生成書面報告，報告中的資料不存在法規風險」。那麼，此句話中的「法規風險」具體是指什麼呢？這正是需求背後的需求，也就是隱式需求。
隱式需求的識別要求較高，分析需求時，測試人員能否過濾到，直接影響著後續測試工作的有效性與全面性。另外，對顯式需求中存在的錯誤是否能及時發現或意識到也同樣重要。下面是乙個需求定義中存在缺陷未及時發現的案例。
案例】需求定義隱含缺陷
問題現象：軟體版本國際化後，輸入限制變小了？
問題背景：某軟體有可輸入使用者資訊功能，需求是這樣定義的：姓名可輸入16個中文，32個英文，也即最多輸入32位元組字元。於是軟體開發在實現此輸入功能時，「姓名」欄位的長度限制為32 bytes。但是有一天，軟體需進行國際化實現，以支援法語、俄語、西班牙語等。開發人員於是在字元的編碼格式上把原來的gbk換成了utf8。這樣一來，對於每個字元的編碼是不固定的（英文除外），測試人員發現原來中文可輸入16個漢字，現在只能輸入10個漢字了，於是提了乙個bug給開發。而開發人員認為是需求定義考慮不全面的問題，需求後來改為能輸入32個字元，這個字元無論是什麼符號（中、英、俄等語言）都一樣。
問題分析：初看「姓名可輸入16個中文，32個英文，也即最多輸入32位元組字元」這句需求，是明確的，不存在二義性。當軟體只支援中、英兩種語言時，它也是沒問題的。但是產品進入國際化市場是必然趨勢，需求設計人員當初定義此條需求時，是否考慮了這一點呢？如果考慮到這一點，是否又能意識到目前定義的侷限性？這讓筆者領悟到「需求設計人員要有軟體設計相關知識的重要性」。從開發人員角度分析，在編碼格式轉變後，表面上軟體是被國際化了，但是否對原有功能造成了影響，並未無及時提出。從測試角度分析，在分析需求，同時也在對需求進行測試時（在本書的第8章需求測試部分有單獨介紹），同樣並關注到。
思考：類似這種需求定義不合理問題，測試人員該如何在早期發現，這正是需我們解決的問題。可能有不少測試朋友會覺得詫異，筆者也曾多次聽一些開發或測試人員提到「怎麼需求也會錯？」需求定義錯誤的原因很多，如需求定義者並沒有真正理解使用者的需求，文字表達上引起的歧義，需求寫過頭了，如把對設計的要求寫進等。案例中需求定義「也即最多輸入32位元組字元」便是乙個例子，「32位元組字元」是一種開發語言，而不是使用者需求。另外，採用需求評審、需求宣講、需求測試的方式對挖掘隱含需求都是有幫助的。
具體到乙個專案中，當你接手乙個功能的時候，首先應該了解需求，這個過程中一定要求甚解，要把需求吃透，甚至要把乙個需求點周圍的東西都了解清楚。這是乙個痛苦的過程，工作量會很大，而且充滿挫敗感。但是這是乙個必須要過的坎，做到這一點，後面寫測試用例，執行測試，報bug，這些只會越來越輕鬆。
by me:
1、透徹理解需求很重要。這是乙個痛苦的過程，工作量會很大，而且充滿挫敗感。
2、站在使用者的角度理解他為什麼需要這個功能，站在設計者角度考慮他為什麼這樣設計，站在測試者角度分析容易出現的問題。
3、怎樣快速準確的理解需求？
需求宣講的組織：需求基線一旦形成後（即需求完成第一版後），啟動內審，通知專案組相關人員事先預審，給出問題反饋的截止時間與內審時間。
介紹需求的背景：需求編寫人宣講需求，介紹需求的使用者背景。這點很重要，讓開發及測試人員能清楚知道使用者的用途，實現後的軟體是用來做什麼的、能滿足使用者哪些要求、能給公司創造什麼樣的價值等，使開發及測試人員的工作目標很明確，處處從使用者立場考慮。
需求宣講內容：需求宣講是否需把所有內容都講一遍？回答是肯定的。正如前面所述，需求的至關重要性，如果需求內容多，可分開多次宣講。當然講解時，也要分開重難點，對於大家容易理解的需求（如之前專案做過或眾所周知的需求）可以幾句話帶過。
輔助答疑式宣講：在需求宣講時，對專案組成員收集到的問題，一一進行解釋，回答提問者疑問的同時，也分享給其他同事。
有乙個事實我們不得不承認，需求不可能詳細到面面俱到，總會存在著隱含需求，這種隱含需求的理解會體現出你對需求的掌握程度。對於這種情況怎麼辦呢？無論對於開發還是測試，如果自己意識到了，但不能確認，把問題記錄下來，與需求確認，並要求需求補充明確。
需求的設計也不可能是完美無缺的，在測試活動的整個過程中，特別是在設計用例的過程中，測試人員會發現不少有需求定義的bug，此時把它也錄入缺陷庫，作為乙個缺陷來跟蹤管理是乙個不錯的方法。俗語說「好記性不如爛筆頭」，事實證明，只在口頭上說的事，需求人員容易忘改需求，使得最後測試用例與需求對應不上，且給後續加入專案人員的工作增添麻煩。後面常會發生「這個地方的需求與實現不同，是以需求還是以實現為準」的局面。
流程改進：
po了解了需求後，作出乙個說明文件，會議開始前發給與會者；與會者仔細閱讀該文件並整理問題（包括理解困難的和認為有問題的）；po開會宣講，回答與會者的提問；會後整理會議記錄，並將會議中提出的問題或者建議整合到需求文件中；將補充過的文件發給專案組所有成員；其他有問題者繼續提問，問題解答後如有必要可以在補充到需求為文件中。
業務需求 使用者需求 功能需求怎麼理解
業務需求一般是我由我們軟體開發人員來蒐集的，是企業自身在顧問等引到下自己所作的工作。我們只是去從他們那裡直接的拿來就可以了。比如為了配合企業生產改造，為了加強庫存管理，為了建立企業電子化執行平台，這些都是業務需求。這些東西的建模還是留給諮詢顧問吧，我們沒有拿那份企業流程重組的錢，也就不用費這個力氣。...
快速排序理解
include include stdafx.h define n 7 void print2 int a printf n void sort int data,int left,int right int i left int j right int key data i while i j 左...
python快速理解
python是 種動態強型別語 python中的變數不需要宣告,直接定義即可.會在初始化的時候決定變數的 型別 python中也 持增量賦值 n n 10python中不 持 這樣的操作,只能寫成 n 1同 個名字變數,可以賦值成不同的型別的值 內建函式 type 可以檢視變數的型別 type a ...