测试理论之测试流程

咳咳，元宵节再写一篇出来吧，因为项目近期不忙，这一篇要说的是测试流程的知识，基本面试必问的了，回答也会回答得出，区别只是在于描述得详细与否了。

下面会有两个部分，一个是基本的核心，另一个是改进版本。

核心版本(喂，这是个真正工作过的测试应该都知道吧)：

需求评审--开发--编写用例--开始测试--回归BUG--发布

改进版本(各个公司的改进版本，更适合某一项目，而不是通用)：

市场调研--需求评审--开发预研--代码实现--转体验--转测试--回归完成--代码合流--系统测试--发布

咳咳，是不是加了很多东西呢，下面来慢慢解释

• 市场调研，好吧，这个可有可无，其实这是运营做的，分析竞品的功能，投放宣传方式啊等等内容，测试能干啥呢？有的，提供技术支持，比如市面上同类产品的一些性能情况，测试可以给出分析报告，那么根据这个报告，可以拟定出自己的产品的质量指标，比如我要做网盘，那么我就去分析市面流行的网盘工具，百度/微云/360等等，看他们的上传下载情况，然后制定出一套对于自己产品的质量标准，供参考。
•需求评审，有请产品上台表演，与会人有对应模块的开发，对应模块的测试和组长(可选)，或者全体人员(大需求)，对于开发来说，你不能产品说什么我就开发什么是不，开发就是去否定掉现有技术不能实现的需求点的，测试干啥，打个酱油就好了，开玩笑的。测试的参加是为了规避缺陷，很多人都这么说，但是具体要干什么就不知道了，其实测试就是在评审会上针对某个地方容易出现的BUG的地方记录下来，必要的时候可以当场提出，另外，需求没考虑到的点也可以拖出来说的，比如需求要添加一个播放器，一个需求说明了播放器样式，功能，而如果你是测试，你需要提出：播放源失效做的处理，网络连接不上的处理，和其他播放器同时播放的优先级等等，也就是你要以测试的思路去评审这个需求。
• 开发预研，针对需求的技术方案研究，这里测试可以要求开发把研究的结论发邮件出来，恩，这个要开评审会吗？答案是，如果影响全局体验的，要，小的模块，没必要了。
•编写用例，测试不就是干这个的吗，但是啊，忙的时候谁还和你慢慢敲用例啊，都是测试点列出来，发散性测试，好听点叫探索性测试，简单地说就是列出小点，步骤自己临时发挥，这个是比较好的，但是我觉得不适用与全面功能测试，因为不能保证大家的状态都很好是不，至于怎么写用例，度娘会告诉你，我只关心用例覆盖全面，怎么写就是个人的事了。
• 转体验，很多公司功能开发完成都是直接给测试测，然后测试完成产品看到说：吖，我不是要这个效果哒，好了，重新来吧，所以开发好的模块，必须由产品说可以测试了才能测试，这是要保证的，不然吃亏的是测试。
• 回归完成，也就是回归BUG咯，这个也没什么说的吧
• 代码合流，我想现在产品迭代都是分支开发的吧，模块测试完毕，回归完成下一步当然是河流，阿不，合流，分支代码提交主干，然后这个模块就算正式完成了
• 系统测试，发布前N天要系统测试，因为分支开发的，代码提交主干后为了避免函数相互调用产生bug，额，说简单的就是关联的模块发生变化，怕影响其他模块，于是在需要进行系统测试，系统测试怎么测呢，这就要求我们平常写用例的时候抽取出主要功能用例，称之为P0，搜集而成就变为系统测试用例，这个用例不要求很细，但要把最重要的点过一遍，这个也是需要常常维护的。
• 发布，发布前，除了完成回归测试外，不要忘记新安装/覆盖安装测试，这样一个周期的迭代流程就走完了。