木江现在每天9点左右从家里出发，9点半左右到公司，到公司之后木江首先用养生壶煮一壶好茶，工作忙碌时也要记得多喝水，然后一边听着煮茶声一边写着当天的工作计划，工作计划主要包括当天工作内容、学习计划和总结。
计划并不是每天都能完成，在工作结束之后根据实际完成内容标注和总结，同时写当天遇到的问题，方便第二天跟踪，写工作计划的好处就是可以随时查询每天都做了什么，这些是每天的固定的工作内容，软件测试人员每天的工作内容会根据项目的实际情况而有所不同。
木江今天就以测试阶段分析一下软件测试人员每天基本工作内容，总的分为以下几个阶段：
1.项目开始之初，也可以是一次迭代开始之初
这个时候每天基本都是以熟悉本次项目或本次迭代功能模块需求为主。
方式：一般就是看文档，有时就是看一天文档，或参加不同的评审会。
根据不同人理解需求方式的不同，木江喜欢用XMIND梳理测试点需求，木江不管做什么事都喜欢用笔去整理一番。
这阶段主要是理解需求，分析功能模块的业务流程，尽可能将测试点梳理得更细，在梳理过程中如果遇到不理解，或需要做的需求与以前的需求逻辑不符时，可以先找产品经理讨论，并确定，方式可以是当面讨论，也可以以邮件的方式确定，推荐以邮件的方式确定。
如果项目流程完善的团队，这时一般会由产品经理开始组织需求评审，用通俗的话讲就是过需求，以前公司是由SE组织需求评审，然后开发人员组织评审Story，目前是开发人员有时会组织，不同人组织评审内容有所不同，测试人员关注的重点也会随之变化。
2.项目中前期工作内容
这时阶段软件测试人员主是写文档。
因为前期已经将需求的范围和测试点整理OK 了,那这个时候基本就是输出这些东西为主，输出的文档测试人员称之为测试用例。
方式：一般是用excel写，有可能会写上几天的测试用例。
测试用例写完之后，测试人员会组织测试用例评审，可以用正式的会议形式组织，也可以以邮件的形式发给开发和产品评审，如果是以邮件的形式，那一定要跟踪，因为大部分开发人员都不喜欢看邮件，可以用即时通讯提醒开发人员和产品经理去评审测试用例。
这个阶段开发人员一般都在编码，也是非常忙的时候。
测试用例并不是一定要用excel写，像现在项目测试用例大部分都是用XMIND写，木江现在习惯了用这种方式写，用XMIND写更能发散测试人员的思维。
现在很多公司都不喜欢写测试用例，觉得太花费时间了，也可能是由于项目紧的原因，但木江觉得测试用例在执行测试之前一定去有这样一个过程，虽然花费时间，但是在执行测试时只需要根据前面梳理的测试点去执行就OK了，同时不容易造成漏测，就算公司不要求，木江在测试之前，一定会做这样的事，无论项目时间是否紧迫，这也算是成为一种习惯了。
3.项目中期工作内容
这个阶段是软件测试人员最辛苦的阶段—测试执行阶段。
方式：根据测试类型的不同，执行测试也有所不同
功能测试时，执行测试主要就是测试软件的功能，界面以及软件体验性等；做接口测试时，执行阶段就是通过工具调用各种接口，测试各类接口传值、取参、返回等测试点。
这个阶段不仅要测试，还有一件非常重要的事情就是提交BUG。
大概分为：在缺陷管理工具上编写BUG，和开发人员讨论BUG，复现BUG，跟踪BUG的处理流程。这个时期需要做的事情很多，不断地测试，不断地与开人员沟通，复现BUG。
在进行第二三轮测试时需要对前期提交的BUG，进行回归测试。
软件测试人员不仅要有发现BUG的能力，也需要有分析BUG，定位BUG的能力。定位BUG可以通过查询数据库、后台日志或者查看源代码等不同的方式去分析和定位。
4.项目后期工作内容
这个阶段测试人员主要做的事情有写测试报告和项目/迭代总结。
执行测试完成之后，测试人员需要对本次测试下一个结论，到底是测试通过还是不通过，这时软件测试人员需要给测试结论，但不能就简单的一句话给开发说本次项目测试通过了，可以上线，或者说本次项目测试不通过，BUG还有很多，软件质量有风险。
所有事情都讲究依据，那么软件测试也需要，测试人员需要给项目团队提供测试结果的依据。所以测试报告中一般包括测试用例的执行情况、从各种维度分析缺陷、遗留缺陷等方面分析测试情况。
项目测试完之后，软件测试人员可以利用项目间隔总结项目，一般是输出业务需求为主，方便其他测试人员查阅。
以上就是根据测试阶段分析了软件测试人员的主要工作内容。
最后：下方这份完整的软件测试视频学习教程已经整理上传完成，朋友们如果需要可以自行免费领取 【保证100%免费】
这一些资料，对做【软件测试】的朋友而言应该是较为完整了，这类学习资料也陪伴我走过了最艰难的路程，希望也可以帮助到你！万事要尽早，尤其是技术行业，一定要提升技术功底。
