具体解释如下：
单元测试：这里的单元测试进行的是编写的代码功能检测，一般由研发员互相进行测试，测试员可参与的有代码审查，利用工具进行复杂度分析等，比如Logiscrope等，一般很少的中小型公司会进行代码走查，因为这个很费人力，特别是在人力资源紧张的时候（开发嵌入式软件除外）。
模块内功能测试：现在的软件研发都是分模块进行的，每人负责一些模块，只有某些比较核心的模块才由几个人共同完成，但是即使这样，一般也是将这些核心模块进行细分，也就是说每人完成模块内的某些功能，因此，完成可以从具体的功能入手，等每个功能一编译通过能正常运行就可以提交验证。此过程已经可以开始进行UI测试，为的是是界面模式统一。很多时候，我们都将UI测试忽略或者将之归类入到系统测试阶段进行。其实，像这么“鸡肋”的东西是越早进行规范越能节省时间，不单单是测试员的时间，也是研发员的。在这里的测试用例可以从UML中获取行为图，参考进行编写本模块的用例。
模块间功能测试：这个步骤对应于集成测试阶段，根据目前的测试经历推荐使用从底向上的模块集成，这个相对于从顶向下的方法便利于贴近项目的研发进度，节省人力，能更好的定位缺陷被暴露位置，此时的测试用例也不用写的太复杂，对测试员有个循序渐进的加深认识的过程。测试用例可以从UML中获取交互图，从中编写模块间的用例。
软件系统测试：此阶段的特征是--核心功能已完成，其余模块编码80%完成（用80%只是代表此时已经无其他技术障碍，可测的功能基本可以进行）。这时，可进行的测试有UI测试（最后一次的UI测试，以后无特殊需求可以少测）、安全测试（一般类应用软件不如特殊应用软件般对安全性有过高的要求，因此可以放在项目中后期进行）、性能测试等。另外，在此测试阶段中包含了Alpha版的发布与测试。可以利用正交法、场景法互相补充来扩充完善测试用例。本人认为，场景法的利用可以从业务流程中获取，这个比较主观，正交法就相对客观些，这两者的互补性将可以使测试用例更完善。
Beta测试：发布一个版本提交用户使用，直到验收开始的这一阶段所进行的用户使用测试。这时，可进行安全测试、性能测试等。
正式验收测试：依据之前各个阶段的测试安排的最为周密的一次系统测试，提交测试报告，签字确认通过，测试组正式退出该项目，以后用户的的新需求或者新版本发布所需的测试通过测试需求单进行提交于测试组进行安排测试。而在此项目实施了之后发现的Bug由维护小组（一般是技术支持人员）反馈给研发员进行软件的Bug修复。
以上的步骤糅合了基于W模型、H模型、UML用例模型还有些测试用例编写的一些具体应用，特别突出的是测试部的独立性。一般的，研发在概要编写与详细设计时已经开始某些模块的某些功能的编写，而这些，都会反应在UML图中，因此，可以从UML中获取静态图，从而进行单元测试的用例编写；另外，能够先完成的功能编写耦合性一般不高，而且很多只是与数据库进行交互即可的功能在完成时就可以验证其正确性，这些测试用例也可以从UML图中的行为图或使用了某些工具（PB、Erwin等）设计出来的数据库模型获取要测试的用例；其余的阶段类似。
假若要套用CMMI等级的话，这里要求企业内部至少满足CMMI-2级（管理级）。即使到今天，相信还有不少的企业还处于缺乏项目开发文档，测试介入于编码即将完成或者是已实施过程中的阶段。这就又要求测试员兼任起SQA的职责，除了建立一套比较完整的测试管理流程外还要改进研发的管理流程。
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/