【测试】互联网测试流程其相关测试概念

背景

在写这篇文章之前我需要先问自己为什么要写？每个人未来的职业发展方向都是不一样的，但是一定都是了解更多的知识，所以是为了未来做铺垫用的，至于有什么用处那就用时间来说明一切吧。另外一个问题就是一直认为测试是整个交付过程中非常重要的一环，所以学习了解就是必然。

一、敏捷测试流程

敏捷开发测试是现在互联网公司使用最多的，其大概解释为小步快跑，就是将一个项目或软件的开发分为多个模块迭代完成，再针对每个模块都能够独立的进行需求分析，开发和测试，能够将每个迭代交付给客户的软件是可以使用的。

其优势如下：

1. 项目及产品可以在短时间迭代上线（一般为一周、快的几天、小改动一天），通过不断迭代尝试完善产品本身功能。

2. 避免过长时间的需求分析及调研，可通过线上数据来看实际需求效果。

3. 产品上线后根据客户时时反馈来跟踪使用等问题。

这里要说明的几点：

1. 分支开发指的是新功能或者模块的开发（会存在多个分支）。

2. RD开发和QA用例设计并行，有的公司甚至能做到新需求的单元测试或自动化代码开发。

3. 用例评审需要PM、RD共同参与。

基本上我们每天的工作也都是围绕这个流程来的，当然再好的流程也会存在问题，如遇到最多的几个常见问题：

1. 迭代太快了，经常有一句话需求

2. RD提测了，和需求实现不一致。

3. 紧急项目如何处理。

针对第一种常见问题、如果遇到复杂的需求，RD、QA一定要在需求阶段沟通解决，及时提出让PM整理好需求，重新发起需求评审，要坚决杜绝这种现象发生。（如需求不复杂，比如屏蔽、去掉某某功能，添加个文案这种的，改动极小的可以简单描述，但必须要有效果图，符合设计）

这里还要说明一种特殊情况，需求不一定必须是文档，可通过口头或简单纸搞的形式完成，前提是对应的RD和QA都理解清楚。

第二种问题，RD提测前的测试用例评审环节必须邀请到PM和RD共同参加，如PM、QA发现RD设计有问题要当面提出，并且如果提测后，最好再和RD对下相关实现逻辑，这样QA能更好的了解RD设计，以便深入测试。

第三种对于紧急项目一般要简化流程，如果优先级最高的比如处理线上问题的话，基本上RD修改后QA根据修改点和RD给出的风险点，代码reivew（这两点非常重要）、测试列出测试点，然后立刻进行测试（功能、和单元、自动化测试相结合），测试没问题，RD直接快速上线了，QA再在线上灰度测试，确认没问题后就是全量上线。

二、相关概念

白盒测试：是通过程序的源代码进行测试而不使用用户界面。这种类型的测试需要从代码句法发现内部代码在算法，溢出，路径，条件等等中的缺点或者错误，进而加以修正。（这种我的理解就是直接给测试提供接口去测试，根本没有用户界面，可以查看后台日志，数据库情况，现在的测试人员都是要求能够查看日志，简单的数据库操作，害怕不害怕？）

黑盒测试：又被称为功能测试、数据驱动测试或基于规格说明的测试，是通过使用整个软件或某种软件功能来严格地测试, 而并没有通过检查程序的源代码或者很清楚地了解该软件的源代码程序具体是怎样设计的。（我的理解就是通过界面去操作，达到你设计时想要的功能，如果出现不符合要求的就找对应的开发人员排查问题）

冒烟测试：是在软件开发过程中的一种针对软件版本包的快速基本功能验证策略，是对软件基本功能进行确认验证的手段，并非对软件版本包的深入测试。冒烟测试也是针对软件版本包进行详细测试之前的预测试，执行冒烟测试的主要目的是快速验证软件基本功能是否有缺陷。如果冒烟测试的测试例不能通过，则不必做进一步的测试。进行冒烟测试之前需要确定冒烟测试的用例集，对用例集要求覆盖软件的基本功能。这种版本包出包之后的验证方法通常称为软件版本包的门槛用例验证。

自动化测试：是把以人为驱动的测试行为转化为机器执行的一种过程。通常，在设计了测试用例并通过评审之后，由测试人员根据测试用例中描述的规程一步步执行测试，得到实际结果与期望结果的比较。在此过程中，为了节省人力、时间或硬件资源，提高测试效率，便引入了自动化测试的概念。主要是通过一些必要的自动化测试软件来提高效率。

 

参考：https://www.jianshu.com/p/6f019c310ba3