是否遇到看了几天的需求文档 没有理清楚需求从哪里开始，到哪里结束，需求边界在哪里。
是否曾花了很多时间编写出的用例，到项目中却无法开展测试。
是否刚做完测试，又有新版本过来，来不及看需求，来不及写用例，项目经理就来问测试结果。
每天忙的像个陀螺，节奏越快越没底，对新项目（需求）渐渐有了恐惧，完全不知道从哪里开始。
以上这些，是我的测试路程，我不聪明，也不愿意什么事都请教别人（怪我咯），分配到自己身上的事情再难也会抗，跳过很多坑，背过很多锅。
有人曾说我只有测试经验没有行业经验，我认同。
因为我单看需求文档，只认识文字，组合在一起就是想象不出到底表达了几个意思。
为什么读不懂需求，我一开始认为是没有听产品经理讲解，于是在后来的项目中，产品经理讲解需求时我特意跑去参加，发现听到都清晰，但就是无法将它们转成我能理解的需求（判断标准是能不能写出测试用例）
我没有行业知识去判断产品经理写的这个需求是不是正确的，然而我又无法自动认为已看到的就是正确的。
而测试的第一步，就是判断需求的正确性，我总纠结我看到需求存在的合理性，因我怕这个需求是错的，而我在这个错的需求上做的越多，就错的更多。
我对我听到/看到的需求无法做出它是不是正确需求的判断，我一直思考的是需求本身的正确性，因为无法确定，所以我一直无法写出用例。
在工作中，不管是否理解需求，测试都是要做的，为了减少需求理解不对带来的Bug，在多次尝试后，我找到了自己的笨方法。
为看到的需求设想使用场景，比如：在一个订购的场景中必须要有的元素 用户、产品、价格、产品付费类型（一次、永久、包时段），其他属性优惠/减免，去和需求对应，去和产品经理做确认。
这种方式尝试的次数越多，构思场景的速度越来越快，常常还没到测试执行阶段就能发现问题，我想这也是一种测试方式。
到正式拿到可测项目时，心里对需求已有底。
那么如何快速地进行功能测试呢？
1）找到项目的主流程场景和常用场景。
2）拿以上场景中的字段属性和需求去做对比，对有出入进行修正。
3）边测试边完善场景，写简要的测试用例和步骤（补充异常case）
4）走完第一轮测试，回顾所有场景。
因都是自己大脑思考，回忆一遍很快，也因都在脑海，只要负责过的项目，有什么功能、功能在什么地方，有什么字段属性都是一清二楚的，再也不用翻看厚厚的需求文档。
5）场景测试完成后，对所有功能做个扫测。
确保所有功能无明显异常（页面报错、功能不可用）
如查看功能，点进去看一眼即可（因知道所有属性，也知道属性显示成什么样是对的，一般一眼就能判断出）
6）保持一个习惯，看研发提交日志和代码。
这是一个提升测试正确率的大杀器，可以少走很多弯路，减少大部分工作量。
前提：要有阅读代码的能力。
此方式在代码框架设计的合理情况下都是可靠的，倘若框架设计的烂，如两个毫不相干的模块却共用一个方法、属性，那就死的不能再死啦，因为你根本就是想象不到的，也无法预防的。
每次测试前 我都会仔细阅读研发的提交日志和代码变更，会根据这些去判断哪些需要重点测试，哪些只要看是否有影响即可。
如果发现代码变更和需求变更无法对应上时 会立马找研发当场确认，为什么改动这块代码。
这个时候往往发现有个更大的坑在，如果不看代码变更，那么只有做全部的回归测试才能发现问题啦。
以上6点，就是我快速进行测试的秘诀，分享给大家，望对大家有所帮助，也期望和大家讨论，得到更有效的测试路径。
