很遗憾这节课没能在直播的时候听，收获很多，对于当前测试思路不明确的我很有帮助。
一、需求分析
现在的我：开会前拿到需求，大致看一下内容，了解下功能，常以没有时间为借口跳过这一段，对具体详细的内容缺乏整理，导致后期对需求不明确，会不断地进行确认，也导致了个人观点与开发观点产生歧义
需要改进：提前对需求进行分析，对不理解和有歧义的地方做批注，功能需求不明确或挖掘不够的地方要着重标注。在评审中集中提问之前存在的问题，说出自己的观点，通过会议保证和开发以及产品的观点达到一致，产品阐述观点中记录疑问，在产品结束阐述后进行集中的发问。多站在用户角度考虑问题，明确需求的指定满足那些人，用户在什么情况下使用系统，用户如何使用系统，用户的使用频率，以及功能为什么这么做，这么做的优势
二、怎么把需求转化为功能点
- 把显示与数据进行分离---UI与数据分离
优先关注数据的产生与业务处理的正确性，最后关注UI对数据显示的正确性以及体验，通过接口测试对服务端数据的正确性进行判断，保证服务端正确后验证前端UI数据的显示是否符合需求 - 给功能点划分优先级
目前的方式是保证功能跑通，之后再对各功能进行一些细节的测试，根据分享可以按以下优先级进行一个划分，根据优先级安排测试，能更好的保证主要功能
数据的创建更新>数据查询>数据显示
业务逻辑判断的优先级 - 黑盒法拆解功能点
用户数据的输入--表单等
系统提供的数据
时间变量
某些功能可以运行的前提条件---写用例时的前提条件
可以通过由点到面，由全局到局部的方式对功能进行细分，当细分到某个功能点或业务不能再分的时候就可以停下来，这样基本保证了覆盖度
三、手工的接口测试
有以下三种方式进行
- 从开发哪里获取接口文档
- 使用fiddler等抓包工具去抓接口
- cookie验证---牵扯到登陆相关的------这个工作中没有接触到
四、功能测试之外
兼容性测试
安装卸载测试
性能测试
故障恢复测试
五、项目的影响面分析
这个部分之前的操作基本上是验证bug，然后进行个冒烟测试，但每次测试完都会有些担心，总觉得测试的深度不够，根据分享感觉可以改进为与开发确认更改部分，受影响的部分着重测试+可能会受影响的优先级为A的功能进行回归测试，其他功能进行冒烟，这样既能快速的完成测试还能保证测试的深度。
网友评论