1樓：不辣的皮皮
有一點你要明白:
測試很難比產品更懂需求，即使更懂，也不可能對需求負責，以及有權力修改需求。
所以你要做的第一件事情是脫責:
告知全員，現在你覺得需求文件不是很清晰。(換言之，因為需求不清晰而產生的風險，你已經提前告知)
當出現你沒什麼問題，而其他人憋死你的這種困境時，往大群裡面甩訊息是很好的解決問題方式。(當然也有風險)
第二件事是想如何改進:
你的測試用例不可能比產品需求文件更貼近需求。所以你可以選擇:
1 測試用例也寫的水一些。比如原本乙個用例，十個步驟，有action有verify。現在你縮水為一句話，這是為了避免後續可能會對這個case做頻繁改動。
同時對於這個場景，你需要發揮創造力做探索性測試。
這裡有兩個點，第一是全面看一下需求，理清思路，排出列表。
這個世界一切的東西都可以用列表解決，如果不行，那說明你還沒想清楚。如你所說，這個需求文件最離譜的是，產品都說不出一二三來，自己都無法形成列表
第二個是核心邏輯風險。
例如某些核心字段型別是不是匹配邏輯，是否必填，髒資料是怎麼樣的，業務過程是不是非同步的，能不能回滾等等。
你發現產品沒有考慮到的場景時，就補用例，同時要求改需求，這個沒毛病。不過可以整體做完了，一次性提交給她，注意也要讓全組知曉，尤其是研發。加油。
2樓：鹿鳴
首先已經有需求了，這個就很不錯了。
需求的好壞是另外乙個事情。
而且既然有需求，那麼應該有需求評審吧，在需求評審的時候，把可測試性方面的問題提出來讓需求人員處理。
如果沒有需求評審，那麼一樣的，把全部的無法理解或者需要確認、補充的問題整理為乙個清單，發給需求人員，並且抄送專案經理。
個人建議的方式是做乙個測試方面的需求評審checklist，把你認為測試需要的需求文件相關要求和標準列上，讓需求人員自查，每次提交需求問題的時候，列明在checklist上不滿足哪條要求，這樣反覆幾次，只要堅持需求人員就應該知道你到底需要什麼了。
而且這件事情，更建議梳理好公司的流程，我一直不怎麼建議測試人員和其他人員打太多交道，測試人員在各類人員的排名中相對靠下，怎麼做都挺難受。
3樓：阿遠
既然她無法把事情講清楚，那就只能我把事情給問清楚。幸好是有乙個叫需求評審的流程，而且現在的PM對這個流程比較重視。把要問清楚的點給列一下
這些功能面向的使用者和目標
每個功能的具體流程
異常場景和一些細節
除了和產品對還要去找開發對。
作為乙個軟體企業，該如何去考核軟體測試人員的績效呢？除了bug數量上面，還應該綜合哪些因素
李白 如果你是HR，那就建議讓技術部門領導進行評估，然後強制分布，能力最差 表現最不好的肯定會在最後面 如果你是技術部負責人，那就不要想定量指標了，對於量化的追求往往是哪些缺乏領導能力的人，如果你是乙個出色的管理者，你一定能分辨出孰優孰劣 Bugtags 可以從這邊方面建來綜合的評價哦！1.bug數...
如何判斷乙個需求是強需求？
劉全鋒 讓客戶去排序可以初步驗證 要最終驗證可以通過讓客戶買單的方式證明，就是說客戶付錢才是真愛。否則很可能客戶自己都沒有認真思考清楚需求對於他們自己的真正價值。 奇勝營銷思維 首根據奇勝營銷的觀點，要評估乙個行業值不值得做，首先要看第一名的營業額及年增長率。如果第一名的營業額很大，基本上就說明這個...
乙個需求，經過專案經理 開發 測試後最終上線，但發現不符合使用者需求，這時責任怎麼界定？
eagleliu 專案經理。專案經理最主要的職能在於專案整合管理，大量的時間需要花在溝通協調上。需求的把握 和落實是第一位的，不能在前期確定或明確，也沒有階段性驗證和評估，到做好了才來講 需求 有問題，這個專案經理需要承擔主要責任。 peng 存在疑問的地方 1 與客戶溝通需求的產品經理怎麼沒有包含...