巩固基本功-测试思路
分享嘉宾阿辉简介：
6年测试，带领过测试团队，在测试整体体系、测试流程把控、项目质量把控方面非常有经验
第五期主题：测试思路
在进行需求评审之前，先要清楚有哪些需求
只有深刻理解了软件产品的需求，才能有效地完成需求的评审。
要把握好需求，需要从多个方面去思考和分析，包括用户、用户业务、和外部条件等，最终理解用例、产品功能性特性和非功能性等。
了解需求的过程.png
一张图胜过千万字，如下是课间分享的内容：
测试思路.png
课间案例分享
1、需求分析
需求分析一般可分为功能需求、非功能需求和领域需求
-
功能需求：
主要说明了系统实际应做到什么。这是用户最直观也是最主要的需求，如系统的输入输出、系统能完成的功能以及其它相关处理等 -
非功能需求：
也称“约束”，主要从各个角度对系统起约束和限制作用。如响应时间、存储效率、报表的规格和界面的样式等 -
领域需求：
来源不是用户，而是系统应用的领域，其主要反映了该领域的基本问题。
例如勤工俭学管理系统，其领域需求就涉及到应聘合同书、酬金发放及劳工考核等相关内容，如果这些需求得不到满足，系统就无法正常运行。
PS：领域需求可能是功能需求，也可能是非功能需求。
相信很多朋友都有这种体验：
1）早上来到公司，接到通知参与项目需求评审，需要测试介入
2）一个紧急项目，可能已经在开发阶段了，需要测试接入
3）一个紧急项目已经完成，需要测试
......
那么碰到这种情况要如何处理呢？
在需求评审前，一般产品经理会把需求发到与会者邮箱（邮件通知）或 将文档传到公司的共享目录下，群里通知各位参与会议
测试人员可以提前1天或1个时间段，把文档下载下来，进行综合分析，对不理解的或产生歧义的地方进行批注，尤其是对需求挖掘不够的地方，对功能需求不明确的地方
上述做法的好处：
1）需求评审（静态测试）前了解了需求，知道了大概功能，在评审时进一步了解，在会上可以对标注问题针对性提问，这样就可以在需求阶段把存在的风险避免掉了
2）在评审时集中式提问，而不是打断产品经理的思路，不然评审会议时间会比预期长
（会议期间带上纸笔，在产品经理讲述的时候记录想到的问题，等一个阶段阐述完后再进行提问）
3）站在用户的角度考虑问题
需求的制定满足哪些用户，用户什么情况下使用系统/功能，用户如何使用系统，使用频率（高/低），该系统的优势
2、把需求转化为功能点
UI与数据分离，是指把显示与数据进行分离：通过锁定需求文档，将UI与数据接偶，优先关注数据的产生与业务处理的正确性、UI对数据显示的正确性、用户体验
轮播条：前台通过ajax请求，在网页加载数据时加载轮播条数据，用JS生成轮播条，利用接口测试数据正确性，然后看显示的正确性（合不合适要看功能UI对数据的封装程度）
一般的轮播条，接口返回 json格式的数据，但UI将其分门别类去封装去展示，变成一个无序的滚动显示，与衍生的数据有很大差别，这种情况很适合前后端的数据分离。
名词解释：
原生数据：是指不依赖于现有数据而产生的数据，例如用户发表的评论数据、用户使用服务的日志数据等。
衍生数据：是指原生数据被记录、存储后，经过算法加工、计算、聚合而成的系统的、可读取、有使用价值的数据
3、黑盒测试法拆解
分析输入输出，根据输入的分类划分功能点，进行枚举，输出
功能输入：用户数据输入
- 表单
- 系统提供的数据（股票实时交易过程中价格、成交记录）
- 时间变量
- 某些功能可以运行的前提条件，即某个功能存在的意义必须依赖于其他的输入，但这输入并不属于该功能的输入（就是写case时的前置条件）
如客服系统：需要聊天，就必须先建立会话
4、自顶向下拆解功能
功能划分（用Xmind进行思维发散）：以系统提供的功能为中心来组织系统。
首先定义各种功能，然后把功能分解为子功能，同时定义功能之间的接口。
举例：客服系统--考虑系统可以干什么，有哪些输入哪些输出。
如智能回复、人工回复，根据智能回复再分有会话生命周期，如何使用......
客服系统.png
5、浏览器兼容性测试
测试一个web应用：用户登录，生成报表，发送报表，退出系统，管理功能（管理员登录后可查看哪些人做了哪些改动）
为了覆盖更多的浏览器，可以采用A浏览器来测试“登录”功能，在B浏览器中测试“发送报表”的功能，用C浏览器测试“生成报表”的功能......
上述看似是一个有效的方法，但还是存在一些问题的，比如说，如果“生成报表”这个功能在C浏览器中正常，而在B浏览器里是有问题，那么就会发现不了。
多浏览器的支持是我们心中永远的痛，特别是如今浏览器更新如此频繁的状况下，哎~
PS：有些浏览器有兼容模式，可以通过兼容模式来模拟老版本。像Chrome/IE，都提供了开发者工具可以帮着定位问题
Q&A环节
-
Q：一轮测试用例，在发现漏洞是要马上提交？研发声称已经解决并提交之后，测试是应该继续执行完一轮测试用例还是应该优先验证漏洞是否已经解决？
A：看对版本如何处理，一轮测试结束后新版本重新发布重新测试 -
Q：测试下来，太详细的测试用例，在实际测试过程中基本不会去使用，怎么改变这个现象，是只写测试点吗？
A：整理通用用例（库）和个性化用例（Xmind或某个项目），可以用 Xmind 列测试点 -
Q：兼容性，是主要功能走流程，还是每个功能点细测呢？
A：首先保证功能正常，其次是UI方面交互体验测试 -
Q：系统需要用哪些浏览器是否由需求决定？
A：若是内部系统，就简单很多，可以由项目经理决定，非内部使用的话还是看市场占有率吧 -
Q：两个浏览器的内核一样的吗，如果一个通过了，另一个我也可以默认是通过吗？
A：不一定
浏览器版本信息
浏览器打开开发者工具（F12），输入navigator.appCodeName，navigator.appVersion，可以查看内核与版本信息
以下是常见的浏览器信息
Trident内核的浏览器：IE、Maxthon、TT、The World
Webkit内核的浏览器：Safari、Chrome、360、Edge
双核/多核的浏览器：如搜狗浏览器，由Trident和Webkit 组成
Presto内核的浏览器：Opera7及以上版本
Netcape6及以上版本、FireFox、MozillaSuite/SeaMonkey
浏览器版本.png
这次分享都是满满的干货，收货很多，希望能用到工作中去。
比如说我们目前是没有维护bug库的，已经关闭的bug，存在被重新激活的情况
以后要系统的分析产生bug的原因，分门别类的统计成文档，测试与开发共享，督促开发不再犯同样的错误不再产生同样的bug。
