1樓：Ginny
定義變數var=東西（「東西」是世上任意的東西）if（var==「喝的東西」）
buy it
然後程式就去找東西，發現了一瓶烈酒，烈酒是喝的東西，則買它！沒毛病！
如果這是乙個問題，問題就是出在需求定義上，口渴的人喝的東西需要明確定義包含哪些東西不包含哪些東西。作為一名測試工程師，需要和產品確認具體的需求呢，不然我們也不能判定這個問題是個bug！
2樓：王曉軍
看到軟體測試，馬上不請自來
這是乙個典型的軟體需求模糊性的問題！我們來重新梳理一下這個題目
需求：有人口渴，要給他喝的
實現：這個好辦，哥這有烈酒
……
那麼是什麼原因造成在需求和實現之間產生了差異性？
我們一起來嘗試著分析一下這個問題中需求實現者的思維邏輯：
∵
口渴 = 需要喝水
水 = 液體
酒 ∈ 液體
∴
喝酒能解渴
你會發現，其實邏輯本身沒有問題。那麼錯在哪兒了？錯就錯在並不是所有液體都能解渴！
題主可能馬上會接著問，這個道理我懂，可是為什麼會出這樣的錯誤呢？難道實現需求的人不知道酒不能解渴嗎？
你說對了，他可能真的不知道！
在一般的軟體研發過程中，軟體產品在立項後，馬上要做的工作就是需求制定。為什麼先做需求？因為我們要知道，我們接下來要搞的這個東西（軟體產品）是人類自誕生於地球以來，所能折騰出來的最複雜的玩意兒之一。
它有以下特徵：
它是非物理的
它包含大量邏輯
它用的語言不同於人類自然語言
它的創造高度依賴於創造者的智力
可能參與創造它的人很多
創造它需要花些時間
用它的人大多數情況下不看操作手冊（幫助文件）
基於以上特點，怎麼能夠在最大程度上保證軟體研發團隊所研發的軟體產品是我們希望他們做的，並讓使用者用起來不罵娘？
依靠的就是——軟體需求。
在軟體工程中，軟體需求本身具備著不確定性、二義性、多樣性、易變性、反覆性、隱藏性和滯後性等特點，有很多時候，提出需求的人也未必知道他真正需要的是什麼，所以你更無法指望有個人（組織）一定可以完美的將所有需求都實現。
同時，解決需求的人所具備的問題分析能力與解決能力，也很有可能與我們希望的不一致。就如同題主你這個問題中所表述的，作為需求提出者，我們會普遍先入為主的認為，未來解決需求實現需求的人的智商情商各種商應該很不錯，最起碼不能比我差！可如果換個角度當我們成為需求實現者的時候，我們大部分情況下都搞不懂提這個需求有什麼意義，為什麼實現這個需求以及我覺得我已經完美的實現了需求（最後一條主要在說程式設計師的蜜汁自信）
所以我才會在上面說，實現需求的人真的有可能不知道他實現的方法是錯誤的，這也就是為什麼在軟體組織中，一定要有軟體測試工程師存在的主要原因！
另外，題主你還要知道軟體行業中還有一條普遍存在的規律，就是較高的需求永遠匹配的是較低的技術實現，需求與實現之間始終保持著不可彌合的差距。
所以在題主的問題中，還存在另一種可能性，就是給口渴的人找來的是烈酒，其實是已經能找到的唯一可以用來解渴的能喝的東西了，你說你喝不喝？
綜上所述，我想題主你的軟體測試課上老師提出的這個問題，無外乎就是想讓你搞懂兩個事情：
1、需求與實現之間存在了太多的不確定性，需要在研發的過程中被不斷的確認和驗證
2、完成這個不斷的確認和驗證軟體需求的人，叫軟體測試工程師
（圈下來，這是重點，要考的！！！）
3樓：測試牛
不管是從軟體工程或者產品工程的角度出發，我們做出來的產品就是要最大限度的滿足使用者的需求，那麼在做軟體產品之前我們就需要對使用者的需求進行分析，首先當然是需要了解和分析使用者的需求，這個並不簡單；
使用者的需求分為顯式需求和隱式需求，顯式需求是從使用者的需求表述中很容易提取到的需求點，隱式需求就需要從使用者的需求表述中進行深層次的挖掘，從而找出隱藏在使用者需求表述之下的需求點，只求充分挖掘出使用者的隱式需求才能保證我們所研發的軟體產品能夠真正滿足使用者的要求。
您題幹中所表述的，可能就是使用者提出來了乙個原始的需求：「我要買喝的」，這就是的原始的需求表述，但是我們可能往往忽略了基於使用者的原始需求去挖掘隱藏在這之下的使用者的真實需求，可能我們會想當然的認為這個使用者平時喜歡喝酒，現在他讓我去買喝的一定是想買酒了，其實我們再深入問一句「您為什麼要買喝的」，那麼使用者隱藏的真實需求就出來了。這樣我們買到的東西才能真正解決使用者的需要。
根據美國相關部門的調查，很多做失敗的軟體專案，其中80%是因為需求的問題導致，所以我們會看到需求分析是否正確往往是軟體專案能否做成功的主要因素，也是影響軟體質量的最重要的要素，所以我們在做軟體測試的時候需要重點關注做出來的產品是否真正滿足使用者的最本質的需求。
4樓：喵大人不吃葷
沒看到上下文的語境，我不知道你的老師們是怎麼聊到這個的。但是軟體工程模型告訴我們，軟體開發的全過程裡，最開始就是需求和立項。
這明顯就是對需求產生了誤解。就好像笑話裡說的，人家要挖一口井，你給人家搭了個煙囪。
這也就是為什麼軟體測試一直強調要盡早介入開發過程，專案管理一直強調要在每乙個階段都要關聯上當前階段所有利益相關的人。
產品、策劃在提出需求後，我們一定要組織展開需求評審。評審會一定要讓所有參與這個專案的實施方參加進來。一方面讓產品講述一下他的實際需求，另一方面從開發者的角度來判斷技術風險和實現難度。
如何從哲學出發，回歸家庭與生活？
維祺 哲學與生活並不衝突，也可以說哲學是生活的一部分，只是不能死扣概念，整天在腦袋裡想這些概念是毫無意義的，你要學會用哲學思想來處理問題，例如 敵進我退，敵駐我擾，敵疲我打。這都是方法，源於生活的哲學概念，馬克思主義哲學的廣泛應用都脫離不開哲學，例如 前進的道路是曲折的，前途是光明的。你也可以視為工...
從閘電路層級出發，計算機的可程式設計功能是如何逐步實現的？
比特曼 不同意那些說從電學開始的回答，我們也可以做出機械的數字計算機不是？那麼如果題主不關注閘電路的具體實現問題，只從理想的閘電路這層抽象開始構造計算機，以及不論及背後的數學原理 計算理論 的話，推薦閱讀 計算機系統要素 手把手教你搭起一台可以用的計算機 從NAND門到俄羅斯方塊。 咱把起點降低一點...
非計算機專業，計算機如何入門？
不懵傘 Fangxun 的推薦，親測有效。Crash Course.我是乙個不接觸計算機專業的人。現在，機械人都要發展起來了。我才不相信電子智慧型是什麼神奇魔法呢！所以，去看了Crash Course。它告訴我，是Computer Science.原來就是一堆電路。大道至簡。的確很神奇！ 高讚答案已...