测试思路整理【简略】

这条思路只是瀑布模型，如果是需求不确定的情况下不适用，应该采用类似于H模型的螺旋式，个人见解若存在问题，欢迎指正。

单元测试

对程序中的最小可测试单元进行检查和验证，一般是开发自测通过后，提测到测试部门。如同一个积木城堡，单元测试就是对每一块积木的检验，看看是不是有问题。

集成测试

模块间的集成，一般侧重接口功能及接口性能。就比如这是2块以上的积木拼接看看链接有没有问题。

确认测试

冒烟

对程序主功能或流程进行冒烟，不通过可打回开发时间。
一个简单的例子就是聊天窗口必需可以发送消息出去，发送消息‘A’，报后台错误则冒烟不通过；发送‘A’聊天窗出现的‘B’可以算通过，信息准确性可以在全量测试中检查。

全量

在测试时间内按照用例对系统需求进行全量确认。
按照测试用例执行全量测试，测试用例是以需求为基础的，根据输入，输出对比来确保程序功能点的正确性。值得一提的是测试并不是为了证明软件没有问题，而是为了证明它还存在问题，即使全量测试也不能穷尽所有的问题。

系统测试

考虑范围增加到实际场景：网络，硬件…等
看公司情况可能会涉及到安全，渗透，兼容，性能…

测试质量保证

一般来说测试部门不会是质量保证的最后一道防线，会有QA部门从需求设计到开发测试这整个过程做质量保证，部分没有QA部门就由产品，项目经理协同控制，只是效果会差一些。下图只是简略说明，仅作参考。