我一般都是从测试老大那里拿到需求的，拿到需求后，他会把他理解的需求跟我讲一下，接下来就靠自己去熟悉需求了，期间有什么疑问的地方再问老大，如果老大也不知道的就记下来，把所有的疑问积累下来，再去问产品，这样会解决很大一部分的疑问，也会让产品去完善他的产品。
需求都了解之后就可以去编写用例了，用例我一般都会分为两部分去写，一部分是功能，另一部分是业务，在编写用例的过程中也肯定会碰到很多问题，功能上的，业务流程上的，测试前准备等，这个时候也是把问题记录下来，找个时间问产品，测试用例的编写要落实到具体的测试数据上面去，要在心里过一遍这个要怎么去测，这样可以提高用例的可执行性，也是提前把测试需要的数据和工具都准备好，如果遇到阻碍也可以提前想办法解决，用例编写完后先给老大过一遍，没有大的问题再跟产品、开发和测试组成员约个时间开个用例评审大会，用例评审的作用在于：第一，统一大家对需求的理解；第二，完善测试点；第三，帮助产品经理完善此次开发的产品，提示产品的开发效率和可执行性；第四，提前想办法解决测试中可能会遇到的问题；第五，了解项目的进度安排。在评审的过程中遇到什么问题，当场短时间内解决不了的，或者需求更改的地方要做会议记录，等会议结束后再去修改自己的用例，一般再次修改的用例直接给自己的老大看就行了，不会再找产品和开发开会。
用例通过后，接下来就测试前的准备，等待开发提测就好了，测试工作开始后，每天都会写测试日报，日报的内容包括测试的进度、执行用例的数量，发现的bug、阻碍测试的问题和风险。
测试环境一般都是从sit——uat——生产。
基本就这么个情况吧。
