测试的第一步，就是判断需求的正确性，总纠结看到需求存在的合理性，因为怕这个需求是错的，而在这个错的需求上做的越多，就错的更多。

　　在工作中，不管是否理解需求，测试都是要做的，为了减少需求理解不对带来的Bug，在多次尝试后，找到了独属于自己的功能测试方法:

　　为看到的需求设想使用场景，比如：在一个订购的场景中必须要有的元素 用户、产品、价格、产品付费类型（一次、永久、包时段），其他属性优惠/减免，去和需求对应，去和产品经理做确认。

　　这种方式尝试的次数越多，构思场景的速度越来越快，常常还没到测试执行阶段就能发现问题，我想这也是一种测试方式。

　　到正式拿到可测项目时，心里对需求已有底。

　　那么如何快速地进行功能测试呢？

　　1）找到项目的主流程场景和常用场景。

　　2）拿以上场景中的字段属性和需求去做对比，对有出入进行修正。

　　3）边测试边完善场景，写简要的测试用例和步骤（补充异常case）

　　4）走完第一轮测试，回顾所有场景。

　　因都是自己大脑思考，回忆一遍很快，也因都在脑海，只要负责过的项目，有什么功能、功能在什么地方，有什么字段属性都是一清二楚的，再也不用翻看厚厚的需求文档。

　　5）场景测试完成后，对所有功能做个扫测。

　　确保所有功能无明显异常（页面报错、功能不可用）

　　如查看功能，点进去看一眼即可（因知道所有属性，也知道属性显示成什么样是对的，一般一眼就能判断出）

　　6）保持一个习惯，看研发提交日志和代码。

　　这是一个提升测试正确率的大杀器，可以少走很多弯路，减少大部分工作量。

　　前提：要有阅读代码的能力。

　　此方式在代码框架设计的合理情况下都是可靠的，倘若框架设计的烂，如两个毫不相干的模块却共用一个方法、属性，那就死的不能再死啦，因为你根本就是想象不到的，也无法预防的。

　　每次测试前 我都会仔细阅读研发的提交日志和代码变更，会根据这些去判断哪些需要重点测试，哪些只要看是否有影响即可。

　　如果发现代码变更和需求变更无法对应上时 会立马找研发当场确认，为什么改动这块代码。

　　这个时候往往发现有个更大的坑在，如果不看代码变更，那么只有做全部的回归测试才能发现问题啦。

　有人曾说我只有测试经验没有行业经验，我认同。因为我单看需求文档，只认识文字，组合在一起就是想象不出到底表达了几个意思。为什么读不懂需求，我一开始认为是没有听产品经理讲解，于是在后来的项目中，产品经理讲解需求时我特意跑去参加，发现听到都清晰，但就是无法将它们转成我能理解的需求（判断标准是能不能写出测试用例）

　　我没有行业知识去判断产品经理写的这个需求是不是正确的，然而我又无法自动认为已看到的就是正确的。

  以上，关于软件测试的全部内容讲解完毕啦，欢迎大家继续关注!更多关于软件测试的干货请关注职坐标软件测试频道!希望这篇软件测试文章可以帮助到你。总之，同学们，你想要的职坐标软件测试频道都能找到!

  本文由职坐标整理并发布，希望对同学们学习软件测试的知识有所帮助。了解更多详情请关注职坐标软件测试频道!