测试人员的工作流程
(1) 需求评审：
不管是自研产品或其他产品，测试人员都要参加需求评审的会议。一方面，便于了解需求进而更好地开展之后的测试工作；另一方面，测试人员往往是从用户角度考虑居多，更加能够从用户的角度提出符合实际的建议。
(2) 制定测试计划：
待需求最终确定下来后，则可以开始制定测试计划，确定测试目标、测试范围、测试方法、测试策略、资源安排、风险评估等。
(3) 测试用例设计：
待测试计划拟定好后，可开始进行用例设计。一般先使用思维导图工具整理大概框架，再使用测试用例管理工具（如testlink）按功能模块、使用场景进行设计。
(4) 测试用例评审：
因为一个人的思想是有局限性的，待用例设计好后，最好项目组的所有人员（产品经理、研发人员、测试人员）都参与用例评审，以便查漏补缺，尽可能使用例覆盖更全面。
(5) 冒烟测试：
待研发人员提交版本后，测试人员便可以进行冒烟测试（当然，冒烟测试的用例要提前选好）。
(6) 一轮测试：
待冒烟测试通过，则可以开始执行第一轮的测试。发现的bug使用缺陷管理工具（如jira/redmine/禅道等）记录下来。
(7) N轮测试：
如果有必要，则进行第二轮、第三轮、第N轮的测试。
(8) 回归测试：
待研发人员把本次需修复的bug都修复完成后（并不一定是所有bug都需要修复，有些推迟的、有些被判定为不是bug的、有些影响不大的都可以暂时不修复），即可进行回归测试。主要是验证缺陷是否真的修复，是否会影响现有系统的使用。
冒烟测试
冒烟测试，是对软件基本的功能进行测试，测试的对象是每一个新编译的需要正式测试的软件版本，目的是确认软件基本的功能正常，保证软件系统能跑的起来，可以进行后续的正式测试工作。
举个简单的例子：新开发一个加法软件，答错后会显示正确答案。测试者故意输错答案后却没有显示正确答案，就直接退回给开发人，不必去考虑其他原因。这个就是冒烟测试。
意思就是正常的流程能够测试通过
冒烟测试在软件测试这块主要是指针对最基本的功能或最主要的业务流程进行测试。一般在开发提测，软件测试人员拿到提测版本并部署到测试环境后，首先就需要进行冒烟测试，这时候测试主要关注在检查服务器的网络连通、数据库连通性、最基本功能（登录）等等；待到临近发布的版本时，冒烟测试还需要关注软件的核心业务流程（以电商购物流程为例即【注册==》登录==》选商品==》购物车==》支付==》订单管理】）
回归测试
回归测试是指在发生修改之后重新测试先前的测试以保证修改的正确性。理论上，软件产生新版本，都需要进行回归测试，验证以前发现和修复的错误是否在新软件版本上再次出现。根据修复好了的缺陷再重新进行测试。回归测试的目的在于验证以前出现过但已经修复好的缺陷不再重新出现。一般指对某已知修正的缺陷再次围绕它原来出现时的步骤重新测试。通常确定所需的再测试的范围时是比较困难的，特别当临近产品发布日期时。因为为了修正某缺陷时必需更改源代码，因而就有可能影响这部分源代码所控制的功能。所以在验证修好的缺陷时不仅要服从缺陷原来出现时的步骤重新测试，而且还要测试有可能受影响的所有功能。因此应当鼓励对所有回归测试用例进行自动化测试。
参考：