一个测试的几点感悟

    在新公司上班了两个多月，有几点感悟须要记录一下。虽然书本上常常说这些原则，可是本身实际经历过，踩过坑，感觉是彻底不同的。

    需求文档越明确越好。关于需求文档这一块，感受永远是开发和测试的痛。通常需求都是只记录整个程序最基本的功能，而那些辅助功能，异常情景处理，要么是一笔带过，要么就是彻底被忽视了。这几个项目的测试，发现一点，就是需求文档里面明确有的，开发基本上都会作出来，错误也比较少，而需求上没有提过的，基本上都会错漏。这体现了开发们的想法，我只是个写代码的，不要让我去想业务逻辑，异常处理，文案提示啥的好很差，你都列出来，我就只管写代码好很差？并且，项目时间都是特别赶的，能把这些主要的功能逻辑实现已经着实不易了，哪还有时间去考虑什么异常状况了。甚至就算是很常识的问题，需求文档没说起，没经验的开发也可能会没考虑到。我以前就遇到过，购物车上调整商品数量，能够一直减减到负数的。因此说，需求越明确，开发出来的程序就越完善，bug也会越少，反而会更节省时间。有时候到了测试时期，才发现需求有些逻辑是自相矛盾的，就要从新定义逻辑，形成开发返工，致使功能都要重测，连锁反应，延期在所不免。因而可知，开发和测试早早就要参与需求评审，若是开发前就能找出需求自己的bug，那该节省多少时间成本呀！顺便说一下，我遇到的好多产品都没有项目管理，项目流程之类的意识的，并且都以为写代码很容易，吃饭前提的需求，设计图都还没出，就说下班前就要上线了。一环扣一环，每每测试时间是最被压缩的。说了那么多，单纯想说，好的产品经理是项目成功的一半。

     产品是否上线该由产品经理决定。有时候测试时间过短，产品测试不完，或者遗留有bug开发没时间改，而上线时间就定死在那。是否要上线不该该由测试决定的，而测试主要是要反馈产品的测试状况，罗列出未解决的bug，能够提出建议，最好不上线，能够上线之类的。可是最后拍板应该由产品经理来。产品经理可以更好的评估风险。还有就是避免背锅。

      编写测试用例不该该照搬需求文档的描述，要有本身的测试思路。其一，需求文档自己是有漏洞的，若是彻底照搬需求文档，只是把里面罗列的功能点转化成测试用例表述语言，就很难发现需求文档自己的漏洞，会被带跑偏了。通常来讲，测试不能只关注程序自己，对于需求文档，接口文档要有一种质疑精神，都应该把这些产出物看成测试对象。其二，需求文档的模块划分，功能排序等是按产品经理本身思考的逻辑的，有时候一直补需求补需求，整个文档的功能顺序是可能有点混乱的，若是测试用例的结构和需求文档的结构同样，是极可能不方便阅读和理解，也不利于对照着执行测试的。

     接口测试时，必定要注意接口之间的依赖关系。虽然接口测试时没有前端界面，但也要根据设计图好好想一想接口是用于哪一个界面哪一个功能的。并且要注意验证接口所产生的实际结果，不能被表象骗了，好比，一个帖子点赞接口，不能接口返回了点同意功就认为这个接口是经过的，而是要调用帖子列表接口，查看点赞数是否正确。测试接口的时候，真的是要假想是有前端界面的，想象接口返回的数据可以匹配界面上展现的元素吗？返回结果的排序正确吗？结果是否有重复，列表翻页是否正常？结果为空，入参不正确等等状况。

      测试时最好要用有意义的测试数据，这样后面看到才不会莫名其妙，有时候对提高测试效率也是颇有帮助的。测试时也要有一种思惟导图的那种思惟，大模块，大功能，小功能，注意细节，特殊状况。最好可以作到一看到界面，脑海就能造成一份测试用例。对了，测试时，界面的一些小元素常常会被忽略，好比头像旁的昵称，评论的发布时间，右上角的更多按钮等等，还有界面标题很容易被遗忘。

      此次先说那么多，一个月后再来吐吐槽吧。