1樓：七星小蟲
我的做法是
需求文件出來的時候就仔細檢視需求，如果發現有問題，及時和產品溝通，如果有修改一定要求他們修改文件，通知開發，編寫用例時同樣
測試過程中發現問題，要和產品溝通，並與開發溝通，如果與需求文件不符，同時還是要產品要修改需求文件
後期如果有人員更換或者需求確認，需求文件是最重要和直接的工具
2樓：Julian
理論上說如果已經在執行測試過程中才發現需求文件不完備，是有人失職了。但是實際情況還是很常見的，比如新產品開發，原型開發模式等等。
你需要做的事情包括如下：
1. 根據新增的需求，重新設計相關的測試用例。
2. 重新review新增用例。確保各方認同測試方案。
3. 執行
4. 最痛苦的就是你可能會發現需求還會變化。尤其是那種管理不夠嚴謹的公司，產品經理或者銷售團隊不能與客戶很好的溝通，導致需求變化太頻繁。
3樓：lynx
不知道是否有寫測試用例。很多問題會在寫測試用例的時候發現。
如果是測到一半有些漏掉的需求，或者異常性的需求。那就跟產品溝通，補上需求。小的補充需求就直接給開發加上就好。
如果比較大的需求會影響到其他模組的邏輯的話，那需要再次評審，作為補充需求。也有可能會放到下個版本。首先跟產品溝通，這些讓產品做決定是否要加需求。
4樓：
這邊有乙個流程供您參考。
產品經理產生idea-》產品團隊內部通過-》提出需求-》需求評審通過-》技術評審通過-》用例評審通過-》排期會-》開始研發-》研發完成-》一輪測試通過-》二輪測試通過-》三輪測試通過-》上線
可以看到在提出需求時候QA和RD就需要看到需求文件，最晚在需求評審時候也需要過需求文件，如果不完善就應該打回給產品團隊，重新出，不會進入到測試階段。如果在測試階段發現問題，說明整體流程是有問題的。
如果說 Rust WASM 會逐漸蠶食 JavaScript 生態，那將以怎樣的路徑進行？
JiuniangYZ 一部分絕大部分開發者無法觸及的基礎設施用wasm來替換是完全可能的 但是你說讓大多數開發者放棄js生態直接換語言那就想太多了 在絕大多數場景下，效能瓶頸並不出在js這門語言上 南京朝月小妹 go wasm 路過.實際上很多程式都有wasm 實現.js 本質也是wasm的上層指令...
如果說過錯可以改，那麼錯過呢？
亦鑫宇 錯過有時算是天意吧逆天而行也未必有好結果反正已經錯過了想開點吧 過錯只因為你的原因，而錯過不只是你的問題，這是雙方面的。人是要向前看的，過去的那已是過去的風景。不要因為這一次的錯過就否定了自己。 夕落 過錯未必都能改，錯過也未必永遠無法挽回。不能改的過錯，都寫在刑法裡，挺詳盡的，望題主知曉。...
如果說哈扎拉人是蒙古後裔，那？
Eric 遇到的哈扎拉人，都說自己是蒙古人的後裔。不過的確是和中中國人像，他TM像了，把我和乙個哈扎拉人拉一起，不說話，你肯定會覺得那個哈扎拉人才是中中國人。 波美拉尼亞公爵 我的理解，哈扎拉人在蒙古入侵前就到了阿富汗，但不一定是突厥人。哈扎拉人的波斯語裡混合了大量來自蒙古語族 注意是蒙古語族不是蒙...