听了百人计划四组组长阿辉6.21的分享课程，记录并参考实际工作做对比总结。
一、测试流程
需求分析
把需求转化为功能点
功能测试之外
对项目的影响面进行分析
做好发布前的准备
做好线上测试
做好总结
努力拓展测试途径
二、需求分析
了解需求
场景分析
竞品分析
测试怎么去做需求分析？
提前阅读需求文档，对不理解或产生歧义的地方做出批注，特别是对功能需求不明确的，或者对需求挖掘不够的地方进行标注。
参加需求评审会的注意事项：
1、在评审时进一步了解需求，并对提前标注的内容有针对性的提问，在需求阶段把存在的风险避免掉
2、在评审阶段注意听并记好问题点，集中提问，避免打断产品经理的话，延长评审时间
3、站在用户角度考虑问题，需求要满足哪些人，用户在什么情况下使用该系统或功能
三、怎么把需求转化为功能测试点
1、把显示和数据进行分离
将UI和数据解耦
先关注数据的产生与业务处理的正确性，之后再关注UI对数据的显示的正确性，还有体验
先是数据的正确性，利用接口测试进行测试，然后才去看显示的正确性
当然数据分离不适合所有的
显示和数据分离的好处
通过接口测试来获取接口传递的内容是否正确，这样可以保证服务端业务处理是正确的，然后再去测试前端的展示，这样测更详细
2、给功能点划分优先级
1、数据的创建和更新优先于数据查询
2、数据查询优先于数据显示
3、业务逻辑判断也有一个优先级
黑盒测试法功能点
分析输入输出，根据输入的分类来划分功能点，可以是枚举
功能的输入类型
1、用户数据的输入，表单等
2、系统提供的数据，如股票实时交易过程中价格以及成交记录等
3、时间变量
4、某些功能可以运行的前提条件，有时候某个功能存在的意义，必须依赖于其它模块的输入，但是这个输入并不属于该功能的输入
3、自顶向下的拆解
由点到面，由全局到局部的分析方法，就是自顶向下的分析方法
用X-mind进行细分，当细分到一个功能点，他本身不再是一种功能的时候，或者是划分到某个业务不可再分的时候，那么我们就可以停下来，就停止细分了
4、手工的接口测试
从开发获取接口文档
5、兼容性测试和安装卸载测试
兼容性测试
首先保证功能正常，其次UI方面也有交互体验的测试，这个比较关键
兼容性测试：网页端，普通浏览器的兼容，一些分辨率的兼容
IE浏览器是个坑，从IE6-IE11都要兼容
客户端：IOS或者Android，不同的版本，不同的机型，都要做兼容性测试
C端，PC端，不同的版本不同的操作系统也是要做兼容性测试
不同的浏览器内核，IE\360\Chrome等
6、性能测试：并发、负载、稳定性、压力
7、系统的故障恢复测试
项目产生的影响，比如项目对系统的研发有影响，那我们就要利用自己对系统的了解程度，还有自己本身具备的系统知识，在需求分析的时候明确哪些是属于需要回归测试的。
圈定一个范围后，和开发沟通，可以了解哪些系统哪些模块可能受到影响
一般来讲受影响的功能都需要拉出通用的用例和个性化的用例进行重新测试
可能受到影响的需要拉出来一部分优先级为一的用例来进行回归
一定不会受到影响的，那就交给验收进行测试
四、强调做好发布前的准备
1、数据的初始化脚本是否OK
2、配置的脚本是否OK
3、发布的流程是否准备OK
4、发布人以及生产环境回归测试人员是否就位是否OK
5、应急预案：若发布失败，应急的预案是什么样子的？
五、发布完成后，做好线上的测试
发布后，测试人员做哪些事情？在有限的条件下
1、在线上回归所有测试环境发现过的bug
2、回归系统的主要业务流程
3、做好探索性测试
4、定期定时对线上的功能进行回测
六、做好总结
测试人员要维护bug库，系统分析产生bug的原因，并且把原因分门别类统一出来，形成文档， 把文档在测试人员和开发人员之间共享，督促开发人员不再犯同样的错
七、听完这次分享，你觉得有哪些可借鉴的，你之前哪些没做好？
我目前所负责的测试是电子产品的固件测试，所执行的步骤大体相同，但具体执行内容差别很大。
在评审时测试主要是明确项目包含的功能点，产品配置，各环节人员配置，时间节点等内容，提前做好准备，一些功能的探讨和确认是否能做到，由研发人员根据方案来确定。
功能测试、兼容性测试、性能测试一般会有通用的模板，必要时做一些调整。
初步接触互联网软件测试，很多都是看着新的，好好学习，每天进步一点点。
