转：https://www.jianshu.com/p/f82f23099b03

一、需求分析

现在的我：开会前拿到需求，大致看一下内容，了解下功能，常以没有时间为借口跳过这一段，对具体详细的内容缺乏整理，导致后期对需求不明确，会不断地进行确认，也导致了个人观点与开发观点产生歧义

需要改进：提前对需求进行分析，对不理解和有歧义的地方做批注，功能需求不明确或挖掘不够的地方要着重标注。在评审中集中提问之前存在的问题，说出自己的观点，通过会议保证和开发以及产品的观点达到一致，产品阐述观点中记录疑问，在产品结束阐述后进行集中的发问。多站在用户角度考虑问题，明确需求的指定满足那些人，用户在什么情况下使用系统，用户如何使用系统，用户的使用频率，以及功能为什么这么做，这么做的优势

二、怎么把需求转化为功能点

1. 把显示与数据进行分离---UI与数据分离
   优先关注数据的产生与业务处理的正确性，最后关注UI对数据显示的正确性以及体验，通过接口测试对服务端数据的正确性进行判断，保证服务端正确后验证前端UI数据的显示是否符合需求
2. 给功能点划分优先级
   目前的方式是保证功能跑通，之后再对各功能进行一些细节的测试，根据分享可以按以下优先级进行一个划分，根据优先级安排测试，能更好的保证主要功能
   数据的创建更新>数据查询>数据显示
   业务逻辑判断的优先级
3. 黑盒法拆解功能点
   用户数据的输入--表单等
   系统提供的数据
   时间变量
   某些功能可以运行的前提条件---写用例时的前提条件
   可以通过由点到面，由全局到局部的方式对功能进行细分，当细分到某个功能点或业务不能再分的时候就可以停下来，这样基本保证了覆盖度

三、手工的接口测试

有以下三种方式进行

1. 从开发哪里获取接口文档
2. 使用fiddler等抓包工具去抓接口
3. cookie验证---牵扯到登陆相关的------这个工作中没有接触到

四、功能测试之外

兼容性测试

安装卸载测试

性能测试

故障恢复测试

五、项目的影响面分析

这个部分之前的操作基本上是验证bug，然后进行个冒烟测试，但每次测试完都会有些担心，总觉得测试的深度不够，根据分享感觉可以改进为与开发确认更改部分，受影响的部分着重测试+可能会受影响的优先级为A的功能进行回归测试，其他功能进行冒烟，这样既能快速的完成测试还能保证测试的深度。

作者：单单丹丹 链接：https://www.jianshu.com/p/f82f23099b03 來源：简书 著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。