我們都知道，軟體測試是一門依賴性很強的綜合技術，軟體測試工程師在施行自己的工作時，總是要依賴其他團隊的產出。

　　比如，我們要依賴著需求團隊給出的需求分析說明書來確定測試的方向，又要依賴開發團隊產出的實際程式碼產品才能真正開展測試的執行。一個測試團隊，通常而言是不能獨立於其他團隊而存在的。

　　所以，軟體測試基礎理論中，我們提出了一個概念，叫做‘測試依據（test basis）’。從字面意義上理解，測試依據就是就是我們測試可以依據它來進行測試分析，以及用例編寫的文件或者資訊；他被用來指導我們的測試，我們可以從中提煉出‘測什麼’‘怎麼測’這樣測試根本性問題的答案。沒有了測試依據，測試工作就將無從下手。

　　說到測試依據，我們最直接會想到的就是需求文件了，根據專案特性的不同，他有可能呈現為不同的格式：比如需求規格說明書式，又比如原型圖式等等。而根據需求文件內容分解和描述形式的區別，他又有可能呈現為使用者故事型（User Story）或者產品需求文件型（PRD）。

　　說起這些需求文件，相信很多測試工程師都會叫苦不迭。由於國內IT行業內需求分析力量的普遍薄弱，又或者是甲方使用者時常胡攪蠻纏的態度，被我們測試工程師視為生命線和指南針的需求文件在交付到我們手裡的時候往往是不堪所用的狀況。不但功能描述不清，歧義性，二義性，含糊其詞，甚至有可能壓根兒就沒有某方面的需求。而在我們後期執行測試提出缺陷時，相關方又很喜歡用需求來搪塞測試提出的合理問題（“需求就是這麼定義的”，“這不是bug。。。”）。

　　基於這樣的現狀，各種測試的理論中總是不斷的強調需求對於我們測試工程的重要性。

　　然而理論很豐滿，現實很骨感，測試人員的吶喊，有時候未必能得到專案的重視。在需求文件始終得不到補完和修正的情況下，我們該做些什麼才能最大程度的彌補需求文件缺失所帶來的質量風險呢。

　　這裡就要回歸到文章開頭提到的‘測試依據’的概念了。

　　我們始終要明白一件重要的事情是，測試依據，其實指的並不僅僅只是需求文件。從本質上說，他應該包括所有可以指導我們測試的資訊。下面我們就來一一探討一下，都有哪些資訊我們可以拿來用作測試依據，以及怎麼來使用它們。

　　首先第一個是開發部門的設計文件，包括我們在軟體生命週期中提到的架構設計，詳細設計階段的產出。

　　開發部門在進行上述設計工作的時候，有可能會產出比需求階段更豐富的文件，比如架構設計圖，演算法設計圖，模組的詳細設計說明書，介面定義文件，資料庫設計說明書，介面設計線圖等等等等。

　　實際工作中，你會發現，開發部門產出的設計文件往往會包含對產品更詳盡，豐富的定義資訊。基於這些文件提供的資訊，我們就可以更進一步，深層次的確定我們測試所需要覆蓋的範圍和內容。

　　當然，理論上而言，這些設計文件只是開發部門為了實現需求而做出的分析性產出，他並不一定完全匹配最初的產品需求甚至使用者需求。我們使用這些設計文件的前提判斷是：開發部門與需求部門有足夠的溝通，他們的產品設計是符合需求的。為了確認這一事實，我們測試人員可能需要來回往返於開發團隊和需求團隊（或使用者）之間來尋求肯定的答覆（一個典型的狀況是，需求團隊對於使用者需求的解讀並不夠細緻詳盡，事實上他可能根本沒有思考到相應深刻的程度，而對於開發通過主觀判斷給出的設計，他也許並提不出什麼意見，只能表示認可）。

　　還有一種狀況是，對於某些細節性的處理，也許連設計文件都不曾包括，而是在開發團隊與需求人員（或直接客戶）的口頭，會議交流中確定了某些做法。這些約定，一旦沒有知會到我們測試團隊，那麼我們的測試就會走彎路甚至出錯誤。所以作為測試團隊，我們應該儘可能要求參加進專案調研分析階段的各項討論活動和會議，並且要把這些口頭約定的內容用文字記下來（比如用郵件，發給各與會方），從而形成我們的測試依據文件。相信我，在專案收尾階段，我們去交付自己的測試成果時，有這些記錄在案的約定處理會讓你更有底氣。

　　極端情況下，開發也有可能將需求中沒有涉及到，但是產品又不可能缺少的部分，直接按照自己的開發慣例實現了，連設計文件都沒有。比如，在使用者定製一個電子商務交易平臺時，他可能根本沒有去關注使用者模組；開發也就順勢用他所最熟知的使用者模組的開發形式，完成了該模組的創作。這種情況下，我們測試人員能依賴的依據就更不足了，通常我們只能預設開發人員的開發方式沒有問題，只能最大程度的去確保他按照自己想法開發出來的模組沒有明顯的問題和漏洞。

　　第二個是行業標準和慣例。

行業標準說起來是個很玄乎的話題，我們這個產品的行業裡到底有哪些標準啊？

　　這就要求我們對於對口行業有著深刻的理解了。說起來很難，但這其實是我們作為測試工程師所必須具備的能力之一。

　　在一個財會處理類系統中，我們去核算某隻債券的收益情況。按照行業標準和慣例，系統應當提供選擇，將該只債券最終的利息收入均攤到計息期間的每一天中，即所謂‘計提利息’-這樣才能達到財務核算平滑度的目的。這就是財會核算領域內的一個行業標準和慣例，如果我們的系統不設計這樣的功能，那麼即使需求沒有明確提出，我們也可以理所當然的將他做為問題甚至缺陷丟擲來。

　　再比如在一個Web專案當中，我們可以對站內所有的連結地址進行篩查，防止出現‘孤島鏈接’的存在（即這個連結在站內沒有任何其他頁面可以導向他）。同樣這也是現今網頁專案的一個行業標準。

　　其實行業慣例的體現還可以類似“在這個行業內，一般都是這樣做的--如果我們的產品沒有足夠的理由不這樣做，就要遵循慣例“。這次舉個非常簡單的栗子，在系統中，我們設計瞭如下對話方塊：

　　這個對話方塊符合行業的慣例嗎？其實他是有問題的，因為在介面設計慣例中，出於人體工程學考慮，確認按鈕一般都放在對話方塊的右下角，這樣才方便使用者操作（除非你的使用者全都是左撇子並且左手持滑鼠）。像這樣的對話方塊按鈕設計，完全可以報出一個易用性類別的缺陷，其依據就是”行業慣例“（當然如果你夠自信，也可以援引人體工程學的理論作為你的論據）。

　　當然在我們引用行業標準和慣例的時候，是需要我們測試人員有足夠的經驗的。如果你對行業標準和慣例沒有足夠的瞭解，就要多關注這方面的知識，多思考，多積累。相信我們對於行業和市場的學習，不但會幫助到我們的日常測試工作，甚至有可能讓我們成為對手行業的專家呢。

　　從另一個角度而言，一個經驗足夠豐富的測試工程師，很多時候是可以反過來指導需求和開發工作的開展的。

　　第三個是政策法規和政治要素。

　　是不是聽起來更玄乎了，怎麼我們測試人員不但要懂測試，還要懂行業，現在又要懂法律法規了！？

　　事實上不必驚訝，一個資深的測試人員確實從知識面的廣度上而言是要超出其他崗位的，這是由我們的工作性質和狀態決定。質量是我們測試人員的生命線，從某種意義上來說，沒有人比我們更關心一個產品的質量和水準，所以我們天然的會對這個產品能涉及到的方方面面性狀去進行了解和學習。

　　我們還是用栗子來說話。例如，我們現在要開發一個藥品零售網站，為消費者提供線上購買醫藥用品的服務。那麼結合著國內的法律法規，我們可以知道，藥品的銷售可否是受到法規限制的，那麼我們的系統就要有違禁藥物篩選功能；再比如，處方藥是需要得到醫生處方才可以被銷售的，那麼就意味著我們的系統可能要有處方上傳功能。

　　如果這個系統在需求和設計開發階段，沒有從其他方面限制藥品的錄入，又沒有實現我們上面提到的違禁藥篩選和處方上傳功能，我們就可以認為這是一個系統風險。在一些情況下，我們完全可以將這樣問題作為缺陷上報。

　　那政治要素又怎麼說？

　　同樣我們舉個栗子：在前些年，大名鼎鼎的PC遊戲《足球經理(Football Manager)》某一版本釋出時，就在政治上犯了錯誤。他在制定足球運動員的國籍一項屬性中，將‘加泰羅尼亞’作為一個國籍赫然列在選項當中，這就引起了大量西班牙使用者的不滿，以致遭到了抵制甚至政府出面的封殺（加泰羅尼亞和西班牙的問題自行百度哦）。事實上，如果測試人員在這款產品製作的過程中意識到這個問題，完全是有可能預防這樣嚴重的後果的。

　　除了我們以上說的這些，能作為我們測試依據的我們還能找出一些來。比如使用者手冊--手冊裡闡述的內容當然應該與產品的功能保持一致；又甚至是”自然規律“--比如一個手機APP，即使需求和設計裡不做任何規定，我們也知道他應該適配現在市場上的所有主流手機型號（這個栗子也許也能用行業標準來判斷）；等等等等。

　　在許多軟體測試的理論中，也有另外一個名詞被經常提到，那就是”隱性需求“。這個概念跟本文所提到的這些額外的我們可用的測試依據既有相互重疊的部分，也有相互補充的部分，我們在採集測試依據的時候，可以把這兩方面都包含進來，從而形成一個更加完備的測試覆蓋面積。

　　結語：測海無涯苦作舟。我們當然希望我們的需求是完美的，我們的開發是成熟幹練和藹可親的，然而理想和現實卻往往是有差距的。但是換一個角度思考，問題越存在，在解決問題後，才越能彰顯我們自身的實力。作為一個測試人員，如何在需求不完備的情況下，利用自己的知識，技能，儲備和經驗，應用各方面的條件來實現更完備的測試，無疑是我們的挑戰，但同樣也是證明我們自己的機遇。

　　我們可能還會疑慮，如果我基於這些沒有得到需求文件支撐的依據報了bug，開發和管理人員會承認嗎？筆者認為，你大可不必擔心，我們這樣報出的缺陷是肯定沒有問題，而且是對團隊有益的。你完全可以去據理力爭，相信經過你們團隊的磨合，隨著各利益相關方對我們測試水平的逐漸認可，這些問題遲早會得到專案的重視。而你作為一個測試人員的口碑也一定會得到提升。

　　以後再遇到需求不足，不明確的情況下，除了苦苦追著需求人員要答覆，試著應用這些依據來開展你的測試吧。

　　原創文章，轉載請註明來源！

• 軟體測試交流群：603317397 加群時請備註：部落格園-Vincent

• 個人工作qq：2049427226