浅谈测试
这篇文章的起源是昨天阿辉同学的分享，结合其分享写了这边文章，
这次的分享主题是“测试思路”一直是测试人员热衷的一个话题，经常会说，知道如此多的测试技巧却依旧无法合理的应用到实际场景中。
测试思路这事其实不仅仅需要一定的测试技巧，也需要一定的思维（我更倾向用“眼界”这个词），见得多了，疑问就多了，疑问多了就会深入的思考，思考后在总结，并将总结的方法和技巧应用于实际工作中形成自己的模式，无形中也就有了自己的测试思维，或者说自己的测试体系。
然现在很多人热衷于各种语言或者测试工具的学习，这些辅助测试的手段确实需要掌握，但是要注意一个词“辅助”，那就说明这不是测试的核心声明周期，但是仔细观察会发现整个圈子貌似都这种套路，认为会用一些前沿的工具或者语言就是新的测试人员了，诚然不是的，你会发现依旧说不清什么是因果图，什么是错误推测法，但你会反驳说能测出Bug就可以了，但是你也就是能测试Bug而已，试问你的真实目标是仅仅测出Bug么？
【题外话：中午和同事讨论小朋友上学的问题，为何那么多人喜欢去大城市上学、上班，又或者说那么多人喜欢北上广，我说抛开教育的质量，其实最根本的原因是眼界，因为学习这事只要你学，就不存在早与晚的问题，但是眼界这件事却会影响很大，这也就是人丑多读书来增加魅力的原因吧】
如下是正题：
问：
需求评审时要注意些什么？
答：
A、阅读需求文档，列出疑问点（带着疑问去参加评审，不是走过场）
B、评审过程中集中提问（避免打断产品的描述，影响其思路，同时也避免会议时间延长）
C、建议写会议纪要，把会议中的疑问点、已确认点、对应责任人备注好
总结：测试人员要对需求进行追根溯源，这是很多测试人员欠缺的事情，通常就是直接接受该需求，那么拿到需求首先要确定=》谁使用这个功能，何种场景下使用此功能，使用频率,此功能实现根本意义
测试如何提出更有建设性的建议：可以查看相应的竞品或者淘宝、京东等大厂商的对应的功能的设计（只有对同类产品的设计了解，才能更好的据理力争）
问：
如何将需求转换为功能点（也可以说如何提取测试点）？
答：
A、采用分层的原则，涉及到UI的展示、数据的正确性、业务处理的正确性（此种模式需要根据实际的项目情况进行选择，并不是所有项目都适合）
优点：因为大多数公司的组织结构是前后端分离的，这种组间合作的时候，通常都是通过接口文档作为沟通纽带，此时测试通过分层的原则，先测试后端服务（接口测试），当前端提测后，通过页面进行操作，从而保证业务逻辑的处理逻辑以及UI展示的正确性。
B、根据功能点划分原则，数据创建模块优先于数据查询模块优先于数据展示模块
优点：通过接口测试优先保证服务端的正确性，即数据的正确性，当后端服务正确性保证后，即是数据展示的测试（UI层测试也包含的业务测试）
Note：这里隐藏了一个数据正确性的测试，需要根据数据的时间的变更，确定数据的展示是否正确
C、根据业务逻辑进行功能点的划分
需求文档拿到后，输出流程图后（如何产品已经输出流程图直接使用接口），通过流程图划分核心逻辑，如A、B、C、D四个点 ，根据业务流的中功能点出现的次数来划分，例如三条业务流 出现A功能点3次，B功能点2次，C和D功能点1次，那么就可以将A理解为核心功能点（在流程图中该功能点被遍历的次数排序划分）
问：
如何设计测试用例？
答：
问：
何时回归Bug？
答：
一种是开发修复即验证Bug，另外一种是集中回归Bug
第一种的好处就是，能尽快发现开发是否因为修复Bug而引发新问题，第二种，不能快速发现是否引入新问题
实际工作中如何处理：
测试的第二天在回归前一天的Bug，不仅可以快速验证bug，还能做到版本的控制，进行测试版本控制是避免在测试过程中不同人员使用不同的版本测试（APP端很容易出现该情况），如果遇到阻塞性Bug可以更新测试版本，否则一天一个版本即可（仅仅是个人测试的习惯，仅供参考）
问：
日常上线测试要注意些什么？
答：
A、线上是否需要执行SQL语句
B、是否涉及后台配置内容（例如app端使用H5或者Native页面时，有些链接需要后台配置）
C、待上线分支确认以及合并的分支内容的确认（测试有gitlab权限时可以自行查看，否则找开发同学查看）
D、应急预案（如上线后发现短时间内无法解决的问题，能否快速回滚代码，此处建议开发在合并线上分支时，要打tag标签）
F、回归测试（主流程+测试环境bug）
问：
上线后要做些什么？
答：
A、线上问题收集
B、测试用例更新（有人会说我都上完线了，还更新用例做什么呢，用例会复用的）
B、总结（很多时候我们的习惯是上线了就上线了，没有总结，但是真正的成长恰恰是被我们忽略掉的点，有错不可怕，怕的是改了后不总结，依旧重复前路）
