关于功能测试的个人总结

一个比较完整的测试流程如下：

一.需求澄清

1）原始需求是从业务方获取，或者从产品经理/BA

2）潜在需求：有些需求是在开发测试过程中发现的，这类是潜在需求。

3）可以给到测试的文档：demo（从设计师获取），软件产品需求规格说明书（项目产品经理/BA），有的比较粗糙的项目，是没有文档的，这种就难受了！

二.测试分析

1.测试分析的重要性

1）测试分析是测试人员对待测试功能或待测系统在分析其产品需求后，思考如何去测试这个功能或系统，然后转化为测试点的过程

2）测试分析体现了测试人员的测试思维。通过测试分析的产出物（测试分析文档）可使项目组其他成员清楚了解待测功能或系统是如何被测试，可以组织项目组对测试分析文档进行评审，指出遗漏项，使整个过程更透明化。

3）测试分析包含两个过程：一是对待测试功能或系统的需求了解；二是思考如何去测试这个功能或系统，这两点可以综合的说测试分析可以帮助测试人员梳理测试功能，使测试更加充分和全面

4）测试分析为测试用例的编写提供了依据。避免了用例编写的随意性，可以提高用例的编写效率

5）在开发人员进行代码开发之前，查看并和测试人员探讨测试分析产出物，可以帮助开发人员自查开发逻辑是否有遗漏。

2.测试分析方法

偏功能：理清主流程-->拆分功能点（页面模块/业务逻辑）-->罗列每个功能点的测试点

偏流程: 画业务流程图（状态转换图）-->设计流程场景

1）分析方法主要分两大类，偏功能和偏流程。

偏功能是指业务流程少，一般不超过三个；界面上的操作元素较多或者功能较复杂。

偏流程是指业务分支叫多，但页面上的操作元素较少且功能简单

2）当测试需求偏功能时

第一步：理清业务流程

第二步：从页面/模块/业务逻辑三个方面进行功能点的拆分

第三步：罗列每个功能点的测试点

第四步：对功能点的测试顺序进行不同顺序的组合。

3）当测试需求偏流程时

借助工具画业务流程图，通过业务流程图找出所有的业务分支，设计测试场景，每一个测试场景代表一个业务分支，保障所有的业务分支都被设计到。PS：要考虑逆向的业务场景用例

4）当测试需求较复杂时，即包含了较多的业务场景和较复杂的功能时，可以综合运用以上两种的分析方法。一般，我们可以通过画流程图找出所有的业务分支，然后再对每一个业务分支进行功能拆分，罗列测试点，然后针对每个测试点设计测试用例，类似敏捷开发的story。

5）测试分析完后，产出测试分析文档，测试分析文档一般由图例和测试点组成

PS：无论是偏功能还是偏流程，测试过程都应该保证所有的业务流程被测试通过。

三.输出测试用例

1.根据测试分析文档输出测试用例，用例设计大多使用黑盒测试方法。

2.测试用例的评审也是一个比较重要的流程，如果前面测试分析文档没有进行评审的话，那么用例评审就必须要邀请项目组其他成员参加。还有一个就是，最好邀请多一位测试同事帮忙评审，毕竟思维是有差异的！

四。进行测试

1）.测试发现的问题记录到bug管理工具上，跟踪闭环bug单。

2）.测试过程中，测试建议最好每天发个测试报告。内容涵盖且不限于：

　　~测试进展，测试了多少

　　~bug单情况汇报，当日新增bug数，当日处理bug数，严重级别bug数量，当日关闭bug数。最好可以使用趋势图展示

　　~测试的风险预警：时间点上看当前测试进展是否能上线前完成所有测试即闭环所有bug；是否存在影响测试进展的问题；其他问题告知等

3）.测试后期最好找测试同事进行项目间的交叉测试，因为测试久了会形成单向的逻辑思维，有一些bug我们会不小心忽略掉，且每个人的测试经验不一样，交叉测试对质量保证是个好办法。

五、测试报告

测试完成输出测试报告，简单点来说涵盖需求清单和BUG清单。 

六。线上bug原因分析及文档沉淀

1.上线发布后，对应线上bug进行原因分析，总结经验教训。

2.将所有文档进行沉淀归档。

以上有部分知识点是学习别人的，欢迎大家点评下不足的地方。