关于测试思路阿辉的分享，还是有点收获，但是由于测试基础相对还薄弱的，所以此次重在记录以及思考，基本是记录下此次分享的内容，自己也可以再熟悉一下这个测试流程。
测试流程：用例评审----确认需求---需求分析---需求转化成功能点----写测试用例---执行测试用例----完成项目的测试。当然根据实际可能还有回归测试。
首先，正规流程一般项目经理或者产品经理会提前发需求评审通知及要点。我们要做的是提前查看分析、了解基本功能、记录标记需求不明确或功能挖掘不够等地方，等评审的时候集中提问，做到心中有数。
然后评审完确认需求之后，就开始做准备工作啦。分析需求：需要满足的是哪些用户、什么情况下使用、如何使用我们的产品的、使用频率怎样、为什么要这么做、有什么优势等等
考虑完了之后我们就开始把需求转化成为功能点，然后开始写测试用例。需求转化为功能点有常见的几种：
1、UI与数据分离。不管是web还是外部端都遵循数据与显示分离的原则。首先我们优先关注数据的产生与业务处理的正确性，再考虑UI对数据显示的正确性以及体验。
2、给功能划分优先级。第一，数据的创建更新优先于查询，而查询又优先于显示，第二，业务逻辑判断业务的优先级。
3、黑盒测试法拆解功能点。黑盒测试就是只看到输入输出不知道内部的运行原理。所以需要了解功能输入的几种模式：用户数据输入、系统提供的数据、时间管理、功能运行的前提条件。
4、自定向下拆解功能点。
自顶向下设计方法：指在软件模块划分时，不论软件多大，都采用自上而下、逐步分解的该当，完成若干部分并明确表达它们之间的关系，直到最低层达到要求的规模为止。
5、停止细分的条件（可用xmind细分）：本身已不是功能，某个业务已不可再划分。
6、强健壮性测试和弱强壮性测试。
7、手工接口测试
8、CCOKIE验证测试。
还有一些测试功能之外的：兼容性测试、安装卸载测试、安全性测试、性能测试、故障恢复测试等等。
阿辉讲的其实很好，可是我觉得我得自己先系统看下书，以后再来看下可能能学到的会多点，现在也最多只能了解一下，但是没接触到东西，有些还是不是很理解的。
趁这次也总结下自己现在公司的项目流程。
方案商或自主研发提供样机----业务拉单----客户下单----项目评审----工厂试产-----大货前试产-----大货
项目评审：主要是硬件、结构、物料、计划管理这些占主导，确定来料，安排试产，安排大货时间，软件只会确认一下大致信息是否过GMS、微软认证，软件版本即可，了解项目情况和硬件信息。
试产：主要是看工厂组装、硬件、结构、来料各方面有没有什么大问题，及时更改查找方案解决。然后拿机器做可靠性实验，再步验证机器是否可大货，是否有重大bug。 一般是几十台到一两百台。
软件就从评审开始穿插进去。主要是从客户提需求开始---研发和客户/业务核对需求----提交需求给方案商-----收到软件自测后-----发给测试中心测试------测试中心反馈问题-----研发核对后提给方案商解决-----测试回归测试。基本都是不断回归测试，中间加入可靠性实验的问题，工厂测试问题、客户测试问题，然后就是不断解bug，接着回归测试，直到最终确定大货软件。
安卓和Windows的系统bug是解不完的，但是基本稳定性还是可以，小bug解不完。可靠性实验和基本软件测试保证产品的质量，根据不同客户需求也能不断完善产品。
对于大多数的安卓或Windows平板的软件bug。一般必现问题，100%问题，一般处理比较快，能改就改，不能改提MTK或者微软找办法。概率问题，必现描述清楚，找到规律或者复现到现象，才能让方案商更快分析解决问题。所以描述问题一定要把问题出现时的操作，状态，以及问题概率描述清楚，如果一个bug测试工程师都不能复现，软件工程师你觉得他会花时间去找规律复现解决么。所以寻找软件bug出现规律、复现bug，以及一些简单的判断和分析,测试工程师也必须具备。
然后安卓软件工程师解决问题，一般是看到现象，分析定位问题，需要log捉log,需要看日志看日志，反正最终需要定位问题。其实一般问题软件工程师查找下公司记录有没有改过这种问题，或者安卓/微软技术支持网站查找有没有解决过相关问题，一般都能解决。不能解决的看log，看现象去分析判断定位问题，这个就需要一点经验和能力。其实一个厉害的测试工程师也是具备这种一般问题的判断和定位的能力。
其实想想虽说工作到第二年后有点迷茫，但是其实也有从中学到很多技术之外的东西，这些东西其实也很重要。想转测试之后，才发现测试也是有很多东西要学，测试也是门技术，才发现测试不仅仅是功能测试，还有自动化测试，还有集成测试等等，越了解越发现自己该学的东西太多，但是这些都不是问题，只要有方向有目的，在努力学习，剩下的就交给时间。
