功能测试基本工作

@[T功能测试算是我们测试最基本的要进行测试的内容。

接到需求后，我们一般是会三步走，分别是：需求分析、测试用例设计、以及测试用例执行。理解需求并分析逻辑功能。

需求分析
　　拿到PRD需求之后，除了产品同学进行需求宣讲，我们也要做到多听多问，只有做了详细的需求分析，才能对需求有更深的一个了解、编写出正确的测试用例，这也是在测试过程中如果发现需求不明确时，需要和产品沟通说明。

需求测试的第一步，需要了解做这个需求是为了什么？以需求出发，以产品出发用户用你的这个功能是要做什么？其实了解需求本身的动机在于以下几点：

1、有些需求是用户必须要用的，比如：用户想要在你的产品上看到教育相关内容(你的产品是育儿类的)，那么必须要有文章或图片或视频来承载，吸引用户。

2、更好的理解需求本身，该需求是给什么角色的业务人员使用的，测试可以“站在对方的角度”考虑问题。

3、解惑，对于一个需求文档，很多时候测试做不到百分百的理解的，如果没有完全理解需求的话，在写测试用例的时候很有可能给出错误的测试用例，或者给出一个粗枝大叶的测试用例，这都不是我们想要的。

4、其实测试一两个版本之后，我们就知道了，有时候产品需求文档写的不明确，在开发或者测试过程中才发现，这个需求还有很多点需要考虑到，或者各种边缘情况没有考虑到。

测试用例
　　测试用例设计算是对功能的一个拆解和融汇贯通的过程。

1、业务逻辑测试：包括正常场景覆盖，异常场景覆盖，条件分支覆盖，业务边界值等。

2、构造数据测试：测试用例中一般描述某个场景时，需要加入特定的测试字段或测试点，构造不同的测试数据验证业务的点十分正常。

3、数据库：涉及到的数据表-数据字段，比如某些统计信息；

4、配置文件：测试熟悉掌握配置文件，一方面是能够方便自己排查问题，一方面是提醒开发无遗漏配置文件上线（因为环境问题出问题其实也不少）。

用例风暴是进行功能点补充，测试点补充的最好方式，所以如果时间允许，一定要进行用例风暴，让大家帮忙查漏补缺。

执行测试
　　按照编写的用例进行执行，所以用例要编写的比较细，分的越小越好。

一般公司都是提测到test环境，交给测试去执行用例。那么首先会来第一轮测试，验证主要的功能点是否冒烟通过，如果没有通过，可以打回让开发同学继续开发。

然后如果功能完全之后，就详细测试，过测试用例，提bug；然后再进行bug回归，如果开发质量不高，可以尽管提bug，后边会有老大们说明。

最后进行功能回归测试，测试一下新功能是否引起老功能产生问题。