我一般都是從測試老大那裏拿到需求的，拿到需求後，他會把他理解的需求跟我講一下，接下來就靠自己去熟悉需求了，期間有什麽疑問的地方再問老大，如果老大也不知道的就記下來，把所有的疑問積累下來，再去問產品，這樣會解決很大一部分的疑問，也會讓產品去完善他的產品。

需求都了解之後就可以去編寫用例了，用例我一般都會分為兩部分去寫，一部分是功能，另一部分是業務，在編寫用例的過程中也肯定會碰到很多問題，功能上的，業務流程上的，測試前準備等，這個時候也是把問題記錄下來，找個時間問產品，測試用例的編寫要落實到具體的測試數據上面去，要在心裏過一遍這個要怎麽去測，這樣可以提高用例的可執行性，也是提前把測試需要的數據和工具都準備好，如果遇到阻礙也可以提前想辦法解決，用例編寫完後先給老大過一遍，沒有大的問題再跟產品、開發和測試組成員約個時間開個用例評審大會，用例評審的作用在於：第一，統一大家對需求的理解；第二，完善測試點；第三，幫助產品經理完善此次開發的產品，提示產品的開發效率和可執行性；第四，提前想辦法解決測試中可能會遇到的問題；第五，了解項目的進度安排。在評審的過程中遇到什麽問題，當場短時間內解決不了的，或者需求更改的地方要做會議記錄，等會議結束後再去修改自己的用例，一般再次修改的用例直接給自己的老大看就行了，不會再找產品和開發開會。

用例通過後，接下來就測試前的準備，等待開發提測就好了，測試工作開始後，每天都會寫測試日報，日報的內容包括測試的進度、執行用例的數量，發現的bug、阻礙測試的問題和風險。

測試環境一般都是從sit——uat——生產。

基本就這麽個情況吧。

需求出來後測試要做的事情