快速掌握测试业务，提高测试效率

 

       互联网软件近几年是大热门的行业，由于移动设备的物美价廉和迅速普及，人人手中都是智能机，目前手机两大主流的操作系统的各色应用就如雨后春笋般冒出千千万，大家都想在app中捞一桶金，有个idea就能开发出一个app，前景好拿着财务报表往天使投资人那里一摔，几百万几千万甚至上亿的投资基金瞬间到手，然后老板就开始带着一帮产品，开发，测试：撸起袖子加油干呐。

       快速迭代的产品就需要员工快速的适应，在先机中占据先机。

       初入软件测试的同学在入职新公司后，最需要做的就是迅速上手自己所负责的业务模块；那么如何在一个庞大的业务系统中进行有条理的理解掌握，这个时候就必须做到思路清晰找到业务系统的规律，这样才能在工作中迅速脱颖而出站稳脚跟。

       1、玩转后台管理系统。一般app的版本迭代更新以及内容的管理，后台都有一个后台运营管理系统；针对app面向用户的所有页面的内容管理；一个成熟的app，那么对其质量的考验也是看后台运营的系统运行的是否稳定进而让其配置的内容更吸引用户停留在app端内花费更多的流量；所以软件测试的工作也是针对app端和后台系统的测试分别展开的。

 

       2、掌握产品的核心业务。APP端测试，首先要确定产品的核心业务是什么以及核心业务的主流程操作：例如淘宝的核心业务就是购买商品：用户选中商品，下单支付成功后，商品的物流派送一直到物品的签收形成整个订单的闭环；如果拆包之后对商品不满意，那么可能就要进入到退货退款或者换货的流程中去；在整个订单流转的过程中，后台的数据库都会对订单进行相应流程的状态记录，从而让运营或者管理员等同学进行对订单数据的监控。所以测试同学在入司之后对公司的核心业务流程有一个初步的了解和掌握。

        3、整理库内所有的表格。比如淘宝下单，下单之后肯定是在order相关的表中有记录的，通过数据库可视化工具，通过模糊查询应该就可以获取订单相关的所有的表，开发同学在建立一个表时，表名肯定是以相关业务的英文单词加底横线作为规律进行组合的，获取到这一组表之后，可以通过查看表结构中各种字段梳理订单的类型，性质，以及状态的流转；

       能猜到的单词还好说，但是大部分的表的查询还真不好靠猜单词来查找，这个时候你就可以去后台相关页面去查看一些线索，淘宝为例，以活动相关为例，后台管理系统中可能会有关于活动管理的运营页面，找到某个活动，会有活动id，活动名称等等列表，点击编辑活动，进入到编辑页面时，看浏览器的链接，链接的拼接问号后面就带了这个活动的各种参数，至少包括了这个活动的id，那么这个时候你按照这个活动的参数名，再去数据库进行模糊查找的话，一定会有所斩获的，一般像这么大的数据量，表也应该会分的细一些，肯定还有一些保存商品其他信息的表中存有商品表中的主键作为外键；按照这个规律，后台系统的很多页面就可以在不依赖其他人的前提下，基本上可以做一个大轮廓的梳理，这对后面需求测试的时候，无论是页面功能的迭代或者新增页面，都能达到快速上手的效果。当然了阿里家大业大，可能有商家运营系统，后台管理员系统等等不止一个系统，不过千变万幻，表结构和页面的关系都可以遵循以上的关系去查找。

       如何了解产品中的业务有多么庞大呢，那么就需要去了解我们的后台运营系统，在测试环境中，测试同学一般拥有的都是超管的权限，所以是可以查看所有的业务页面的（如果有专门设计到权限的测试的话，那么再根据自己测试用例的测试点将测试账号划分到不同部门或者组进行测试），基本上后台系统大部分的页面配置之后的数据都会按照不同逻辑的形式展示在app上；

       在捋页面的时候呢，最好是结合端内一起查看，这样既能加深对业务的了解程度，也能知道端内读取后台数据的逻辑，例如配置一个活动，活动内增加一些商品；或者通过后台给不同的用户发送push或者通知；或者通过一个活动让用户领取不同面值的优惠券等等；这些数据基本上都是通过后台系统配置之后存到数据库相关表中，app再按照活动的类型、开始结束时间、用户的类型等等获取到这些数据的。

那么怎样做才能提高测试效率呢？

       1、强化对业务的熟悉程度。平时需要做好对测试工作的积累和沉淀，一个项目的测试工作完成之后，最具有价值和意义的是将整套项目的业务流程按照自己的理解画出流程图，这样就可以在不同的节点构造不同需求的数据，从而避免每次构造数据都要从头操作一遍，大大节省了测试时间。

       2、深化对接口的掌握。大部分的数据是通过接口的请求落地到数据的表中，那么如果在测试想要构造某个场景的数据时，获取到这个接口，通过接口的工具（例如postman、yapi等）填写相关的参数进行调用，就会比通过页面构造的数据节约更多的时间，测试工作也会更有效率；

       3、规范测试用例的编写和用例评审严格流程化。测试用例编写的过程也是整理对业务的测试的思路，没有百分百覆盖率的测试用例，只有不断完善和补充的测试用例。之前看的一篇文章有句话特别赞同：测试用例的数量只能在需求频繁更新和产品不断上线中寻求最大的权衡。所以只有测试用例尽可能的编写全面，然后在用例评审中，开发和产品能够在不同的角度进行补充，这样在代码上线后才能最大限度的减少bug的产生，从而在另一角度减少了不必要的重复测试和回归，侧面提高测试效率。

希望上面的工作经验能够给新人同学带来些许的帮助。

以上。