测试思维

          测试思维是体现在测试用例上的。我们在编写测试用例的时候千万不要撒网式搬需求，写的全部是需求本身，特别是使用脑图形式这样写，一眼望去全是网，条理混乱没有任何测试思维其中。我们用例模块层级尽量不要超过三层，测试点尽量一句话简洁描述，条理清晰具有测试思维在里面。虽然用例最终是测试人员执行的，但一个好的测试用例是可以帮助开发梳理需求、提前避免一些异常情况出现，甚至可以让开发直接拿来开始写业务代码，也好规避一些异常问题，同时也帮助产品发现一些未明确的问题。

          测试从需求开始。我们可以在需求出来后就开始测试，从需求开始到提测阶段，虽然该阶段没有成形的产品出来，但我们可以通过需求发现一些未知的风险，该阶段大多是需求未明确点、需求之间冲突的点；需求完后就是服务端接口。我们可以跟随服务端同学写的接口文档，了解业务在接口层面的一些逻辑、帮助后期测试定位问题来源，该阶段大多是接口与需求冲突、接口中泄漏用户隐私、接口中有一些不安全字段暴露； 然后就是UI设计稿。可以走查UI设计稿当中的一些问题，提前排查服务端返回来的字段值在UI展示上限制，大多情况UI会落下部分页面的空页面UI以及断网情况。

           bug从哪来。保证产品质量单靠测试人员根本不可能完成。要靠该项目组的每一个人共同把控质量。测试过程中出现的bug的来源有这些情况：产品需求未覆盖到、产品需求之间冲突、开发理解需求有偏差、开发未详细看需求、客户端未详细看UI设计稿、服务端由测试环境部署到正式环境异常、产品前端服务端测试获取信息不一致、前后端联调时接口对接问题、接第三方sdk时未知坑问题、开发包打好了忘进代码、代码混淆导致的问题、开发遗漏部分异常情况的处理、接口字段值格式变动导致客户端不识别（特别是时间）、代码本身的问题。还有一些问题是测试构造测试数据导致的问题，我们应当避免此类情况发生。

          偶现的bug。严格意义上说根本不存在偶现的bug，只是没有找到必要环境下的必现路径。对于偶现的bug我们测试是很头疼的，开发也头疼，无从下手。对于在测试前期偶现一两次的bug，发现后根本无法复现的话，后期观察处理；对于偶现概率比较高就尽最大努力复现，如果完全相同操作这个bug时而出现时而不出现的话，那这个bug 90%是跟响应时间上有关系，可以在一些页面切换临界点上操作去复现；如果高概率偶现的bug没有注意到必现路径，不知道怎么出现的，就用排除法，每一个操作路径去遍历找复现路径，或者下载一个录屏工具，集中操作一会儿回看操作步骤复现；还可以用跳跃思维，就是不要按部就班正常操作复现，跳出当前思维寻找其他操作情况。当然我们发现偶现的bug先提交给开发，有时候偶现的bug开发会找到根本问题的，后面测试有时间再复现。偶现的bug出现后影响用户正常使用或影响关键数据（如金额），这类bug一定要改，如果偶现的bug出现后不影响用户正常使用，根据情况可暂且观察。

          多从实际用户角度出发测试。之前就出现过问题，在app内视频在移动网络下各个功能均正常，测试没问题，但是发版后，发现大部分用户进入app无法观看视频，这个是我们在测移动网络时，是在无线网下启动app，然后切换成移动网络漏测的。实际用户本身就是移动网络下启动app的；还有一次是移动网络下给用户提示耗费流量，因为在办公室，将手机声音调的特别小，在移动网络下测的时候是给用户提示的，但是发版后发现，用户在移动网络下看视频有这个提示，但提示过程中，视频的声音还在继续进行着。所以我们要在测试过程中保证是实际环境。

            测试方法。具体测试方式是围绕着需求展开的。测试的时候是遵循一个大树逻辑，由树干到树枝再到树叶走向，先把最重要的部分测试也就我们常说的冒烟测试，然后再各个模块功能走通，其次是各个功能当中的业务细节。注意以上说的只是我们正向测试也就是满足需求部分测试，这些走通后就是逆向测试，也就是各种异常交互情况，如断网、弱网、非正常操作，有时候开发在写代码时处理异常情况要比需求还写的多，所以异常情况同样重要，但是他的测试时间优先级比正向测试稍低一些。

           确保不要漏测，绝对的测试完整是不可能的，但首先我们要保证需求部分功能一定完成明确，其次是用户常用的操作流程、然后是异常情况。在测试中带着傻瓜式为什么的思维去测试，因为一个产品成形也是从一张白纸开始的，是开发一行一行代码让这个傻瓜具有一些思维的，但难免会落下什么。

           举个例子，如自动售货机，先大概理一下，输入钱，选择货物，出货并有可能找零钱。一步一步走，记得自动售货机是个傻瓜，首先投入钱。

售货机：‘什么是钱’，此时我们就可以围绕什么是钱展开。--------测试点：一分、五角、一元硬币、一毛、五毛、一块、五块、十块、五十块、一百块人民币分别投入是否生效

售货机：‘我怎么知道你投钱了’。---------测试点：验钞机测试

售货机：‘只要检测到钱就算投币成功了吗’。--------测试点：投纸币一半再抽出来

售货机：‘我怎么知道哪些纸币是有效的’。--------测试点：残缺纸币、直接一张白纸、纸币折叠不整齐等

售货机：‘是个圆片都认硬币吗’。--------测试点：游戏币、塑料圈、啤酒瓶盖

售货机：‘这么多钱我怎么计算’。--------测试点：计算准确性测试点，

售货机：‘一块纸币+一块纸币=两元，一元硬币+一元硬币=两元，一块纸币+一元硬币=啥’，---------测试点，不同金额形式组合测试

售货机：‘我怎么知道你要买什么’。--------测试点：单选货物，多选货物

售货机：‘我怎么知道你投的钱就值买的货’。--------测试点：金钱大于买的货物时找零，金钱小于买的货物时不能选货物，金钱等于买的货物时，不找零

售货机：‘我拿什么给你找零’。--------测试点：上述条件下，存储的零钱大于等于找零钱时找零，小于时无法购买成功或者提前给用户提示

售货机：‘我怎么知道我有货物’。--------测试点：没有对应货物时不能选择该货物，有对应该货物时可选择

等等等。。。。售货机偏向流程功能，所以应当按照事务处理，只要这个流程中一个环节出问题该流程就失败，其实有发现我们在能不能找零的那个测试点上发现了一个需求问题，当没有找零存储钱的情况下此时怎么处理？以上只是一小部分的测试点，还有一异常情况，使用过程中断电了，投入的是美元、售货机出问题了不出货（其实这个问题抛出了一个产品运营问题，要在售货机上贴上服务热线电话，以便处理实际的异常情况）。

          售货机就像我们的前端，那有前段起码就有服务端，也就是数据回传（货物与零钱）以及统计打点，千千万万个售货机怎么管理统计，此时就引出了打点测试。打点测试其实很重要，要不然售货机都报废了都不知道什么情况，如果当中出货或者投钱统计错误，有时候会给管理人误判，以为今天赚百万，实际售货机都让人给搬走了。引出了打点、数据监控以及售货机本身运作状态监控的测试点。产品可以根据打点情况来调整接下来的产品需求改善情况，有些是靠广告来增加收入的，所以打点测试非常重要。

          除过打点重要外，对于app测试当中还有一个很重要但大家很容易忽视的，就是升级安装测试，如果发版之后发现app升级有问题无法升级，那将有一大批老用户会丢失掉的，还要产品下架重新换新版，所以每一个版本都要进行升级安装测试。