测试心得体会（一）

时隔一年多，最近才重新开始写写博客。在这一年的时间里，积累了一些收获，现在准备以博客的方式，呈现出来，以供大家参考！

功能测试方面

在一次次产品迭代中，我们都是以需求评审、迭代所需的周期、编写测试计划、编写冒烟用例和全用例、评审测试用例，之后再进行接口测试、全面测试，最后测试完成，进行上线。

可能每个公司不太一样，我目前的公司特性就是如此。

测试用例

首先，从编写用例开始。

测试用例分为：冒烟用例和全用例。

1、冒烟用例

冒烟用例就是针对研发人员，开发出来的产品，进行简单的主流程测试，不必在意具体的细节和异常的场景。

所以在编写冒烟用例的时候，我们应该关注的是产品的主体功能，和主线流程，不必在意具体的枝叶！所以，编写冒烟用例不必写太多条数，尽量做好精简。

2、全用例

全用例，个人认为全用例就是尽可能的覆盖产品测试的全部场景，以减少BUG的产生。当然有两种呈现方式：以数量见长、以最好的用例覆盖最全的情况(不可太过冗杂)！

接口测试

接口测试主要是对后端进行测试，在这里以测试工具进行介绍，以postman为例：

后端接口出来之后，首先我们需要对给出的接口，进行梳理。进行简单的接口用例整理。

根据接口用例，利用postman进行测试，首先添加一个集合，然后再分类多个folder,在发送接口

大致的流程就是：梳理接口业务逻辑、设计接口测试用例、利用工具或代码的方式，测试接口、得出测试结果并输出测试报告。

在接口测试中，比如像get请求，主要以查询为主，其中查询的数据，前端通过调用接口展出出来；其实想这一类问题，我们主要进行这几方面检查：

1、查询的数据要求是否与需求相符合；

2、前端调用接口是否每个字段正确调用；

3、还有一种通过get请求查询的数据，可能后面的接口会对其依赖。

而post请求，更多的是进行一些逻辑处理，主要以入参和相应数据为测试对象。入参在产品中，前端会从get请求中获取或者从用户操作事件中获取；响应数据，主要是从后端逻辑计算中得出，与前端关系不大。所以主要从以下几方面检查：

入参：

① 查询的数据是否可以正确拿到，并做为入参；

②用户的操作事件中是否可以正确拿到；

响应数据：

① 在入参正确情况下，响应数据是否可以正确得到；

② 通过一些异常场景的入参(有些接口入参字段，不一定都是必填)，响应数据是否做过处理；

先到这里，下一次分享具体的接口测试和通过抓包分析问题！