往往在测试中，大家认为来了测试任务就测试，时间久了，反而忘记了还有什么规范？也就慢慢忽略了规范！

　　规范的软件测试流程有助于需求条理化，将测试工作模块化，一切跟着计划走比通过脑袋记忆要更加的有条理。有些时候，工作任务较为繁琐，脑袋记忆力有可能会出现乱成一锅粥的情况，特别这样一个时间段，软件测试计划就更重要。下面结合真实的情况对自己工作中测试流程进行简单的阐述。

　　测试策略就是怎么样做测试，运用何种手段来测试。当用户提出新的需求时，测试人员应该和开发人员一起做测试需求分析，一般我们都会通过会议的形式去进行讨论分析，这样测试人员会对测试需求要有个大概的了解，需要是干什么的，包括哪些功能等等，而不至于什么都不清楚不了解。

　　了解需求内容之后，就可以对整个测试进行预期估算，包括计划要测试哪些方面的功能，测试的策略，要计划分配哪些人员参与到测试中，哪些人负责哪个模块，以及按照交叉测试的方法，同时还要提前计划好测试的开始时间和结束时间，以及测试计入条件和测试退出条件，便于掌控整个测试进度。

　　测试计划规范之后，则是来测试用例的编写。测试用例的编写，主要围绕界面模块而展开，如界面包括哪些按钮，按钮操作是否可以正常进行，其次围绕功能来设计，然后根据不同的场景来设计。对于测试过程中，出现的缺陷问题，要在将缺陷问题记录到测试用例“测试结果”一列，便于查看测试项测试任务情况。测试用例需要组织研发人员、测试人员、需求人员一起进行评审，评审通过后作为正式测试用例供测试人员执行。

　　测试用例执行之后，对测试过程中发现的缺陷，要汇报自己的测试情况，并且将测试中的缺陷反馈到测试工具中，便于研发人员解决。对于安排的不同模块的负责人在测试自己对应模块的任务时，也要及时的汇报自己的测试工作进度，便于测试小组掌握测试的整个进度。

　　按照测试用例执行完所有的测试任务，且研发人员修复完了所有的bug问题(不包含一些难以修复但不紧急的问题，)，测试人需要编写针对本次项目的测试总结，要在总结中说明，测试计划是否按照如期进行。总测试缺陷数据多少，测试覆盖度等。

　　系统测试完成后，文档编写人需要针对本次项目开发新增加的功能进行项目“升级日志”和“用户手册”文档的编写。方便用户了解并能快速上手使用新增加的功能。

　　最后，测试通过的软件及文档需要CM发布文件包，以便对外正式使用。市场人能编写白皮书等文档对外进行宣传。