1、公司都沒產品經理，開發人員的意識不足，收到的客戶需求，直接開幹（寫需求文件 ？不可能的） 。
2、專案進度緊張，需求變動大，一直在變，產品偷懶，沒更新原始需求文件 。
3、專案是從原有老專案上進行迭代開發，開發人員認為不需要需求文件 。
對於，如上情況，理論上的做法，如下 ：
1、測試負責人，應該要堅持自己的原則：沒需求文件，一律不接受測試
2、需求文件要進行評審，評審做會議記錄，並有專門人員對需求文件進行修改、更新、確認；
但是，實際情況是 。
很多時候，如上理論，無法落地（當然，能落地更好，而且，也應該落地；此文，主要針對那些，無法落地需求文件持續更新的情況下的可行性建議） 。
1、測試團隊，在公司，完全無話語權，想推動產品寫需求，難 。
2、而且，很多時候，整個技術團隊，都是服務於業務，時間緊、任務重，需要每個人多主動點 。所以，如上的理論情況，實際落地，難。
沒有需求文件，對於編寫測試用例來說，太難（保障最終上線質量，就更難了） 。
作為測試人員，在沒有測試需求文件情況下，別傻乎乎的等著，應該主動點，盡可能去多了解專案的一些情況，多知道一點，對測試用例就能多寫點。
如下，是ido老徐 ，根據自己的經驗，給的可行性做法，供參考 ：
1、盡量去找找其他相關文件，如原始碎片需求會議討論紀要、策劃書、開發文件、市場調研書、可行性分析報告 等
2、盡可能多的參加內部討論會議（需求、設計、計畫 ），參加討論過程，進一步理解需求
3、諮詢相關人員：專案、市場、業務、研發、客戶
4、如果是基於舊版本開發的，多去使用舊版本，自己摸索需求（也可以看看歷史bug庫、用例庫）
5、參考同行或競爭對手的類似產品（其實，產品經理，規劃原始需求，也是類似方式參考的）6、最後，根據如上了解到的，梳理出你理解後的需求點，召集相關人員，碰一下（專案、開發、產品、市場、業務 等），查漏補缺，以及更正你的某些錯誤的需求理解 。
7、接下來的事，測試同學，都應該知道了：根據自己整理的，已確定的需求，去整理出乙份評審過的測試需求點，最後進行測試用例設計。
總之，乙個原則：沒有需求文件的情況下，自己多主動，去了解，去梳理，去反向推動 。1、開發自測
2、產品提測後的需求還原度，讓產品經理，加入，一起確認，一起驗收 。
3、產品提測後的設計還原度，讓設計師，加入，一起確認，一起驗收 。
原創不易，所有持續分享、持續輸出價值的，都值得敬佩 。
end ，
ido老徐 2019/08/22
測試 發布 質量保障 使用者體驗
自學閱讀完構建之法後，我提出了五個現在還無法解決的問題如下 1 現實的開發過程中往往會比理論中多出很多問題，比如需要如何能夠將需求細化到任務，然後在細化到設計，最終使得能夠在規定的時間內有條不紊的完成目標？2 如果最後做效能分析的時候發現效能問題造成的原因是前期乙個隱藏在很深地方的不妥當架構造成的，...
軟體測試 產品需求文件測試
產品測試間歇期，打算坐下產品測試覆盤，又把產品測試方案拿過來看下，發現產品需求描述出現問題，反思了下發現是從開始到現在，由於新產品是在老產品的基礎上做了優化，所以未進行需求評審，且我自己介入產品的時間比較晚，已經到產品測試階段才介入產品，但是還是想寫下自己對於需求文件測試需要注意的問題。產品需求文件...
測試驅動需求分析 需求文件評審例項
需求文件評審例項 軟體的開發文件質量一般只能通過評審來進行保證，如何有效發現文件中的問題，是乙個令許多人頭疼的問題。先看一段關於日誌檔案的需求描述如下 軟體要將所有的訪問者都要記錄下來，對每次訪問要記錄訪問開始時間 訪問結束時間 訪問者的 ip位址這三個資訊作為一條日誌記錄。要求以天為單位每天生成乙...