1、功能测试与数据库
1.1 项目与数据库的关系
1. 项目中的数据是存储在数据库中的
2. 对数据库修改(增删改查)会影响项目页面显示
实操练习：
1. 修改数据库中“小米手机5,十余项黑科技，很轻狠快”的商品名称，在前台页面看到变化
数据表 tpgoods 2、字段 goodsname 3、操作语句 update 表名 set 字段名 = 字段值 where 条件
修改前： select * from tp_goods where goods_name = \'小米手机5,十余项黑科技，很轻狠快\' -- 精确查询 select * from tp_goods where goods_name like \'小米手机5%\' -- 模糊查询 修改： update tp_goods set goods_name = \'小米手机55\' where goods_name = \'小米手机5,十余项黑科技，很轻狠快\' 修改后： select * from tp_goods where goods_name = \'小米手机5,十余项黑科技，很轻狠快\' -- 精确查询 select * from tp_goods where goods_name like \'小米手机5%\'
2. 修改数据库中\'力士精油香氛幽莲魅肤沐浴乳1000ml（新老包装随机发货）\'的商品价格，在前台页面看到变化
数据表 tpgoods 2、字段 shopprice 3、操作语句 update 表名 set 字段名 = 字段值 where 条件
修改前： -- 精确查询 select * from tpgoods where goodsname like \'力士精油香氛%\' -- 模糊查询 修改： update tpgoods set shopprice = 9.9 where goods_name like \'力士精油香氛%\' 修改后： select * from tpgoods where goodsname like \'力士精油香氛%\'
1.2 数据库典型应用场景（重点）
1. 验证数据的准确性与完整性
2. 借助数据库进行缺陷定位
3. 借助数据库构造测试场景（需要特定的测试数据）
4. 借助数据库数据备份更新
1. 验证数据的准确性与完整性
理解：比如说昨天会有打开选择商品的时候，到底是73条数据还是68条数据，我们可以找到对应的表，去进行一个查询。（会用另一个例子说明。）
针对一下这样统计数据，我们应该借助数据库来精确计算它对应的结果和页面上显示的数据，对还是不对。
2. 借助数据库进行缺陷定位
理解：当你发现了一个bug,你怎么判定它是属于前端的一个问题，还是后端的一个问题，有两拨开发工程师，怎么定位，那么在功能测试阶段，也可以借助数据库简单的模拟一下。
当然更深层次的问题，需要学习接口知识，了解什么是前端什么后端，怎么定位它们之间的谁是谁的一个问题。这里先简单的普及感受一下。
3. 借助数据库构造测试场景（需要特定的测试数据）
理解：这是我们最常用的一个场景，是我们要构造一些测试数据。比如说：你现在有一个测试场景，或者一个测试用例，要求是10000个用户登陆注册。
那10000个用户名，密码你怎么去准备，你是在这个用例测试数据里面，一条条写进去吗？那么我们正常像这种特殊的情况里面，我们会选择一条或者几条SQL语句快速帮你生成测试数据，不管是1万条数据，还是10万条数据，都可以快速去
帮你生成这样的数据，它的一个高效性就能得到充分体现，这是第3种场景。
4. 借助数据库数据备份更新
理解：当我们需要进行一些备份或者升级的时候，也就是我们的产品，1.0的时候有一些功能，2.0的时候升级了，有新的功能，在代码里面可能会去创建新的表，修改原来的表，那么这些创建表，修改表的SQL语句，你作为测试，需要在你
测试环境里面测试一下，SQL语句本身能不能成功，是需要去测试的，可以了才可以交给运维，在线上环境去运行。
1.2.1 验证数据的准确性与完整性
执行用例过程中，有时需要到数据库验证数据的准确性与完整性
用人话就是：你看到页面上的数据是对还是不对。
后台有一部分是数据的管理功能，一部分是统计功能。
例子：
登陆后台 localhost/Admin
商城——统计——会员统计 会员余额：100046628.97
怎么知道这个数据是对还是不对，可以到数据库进行一个查询计算。
会员统计信息是基于单个会员进行统计。会员信息在用户表tp_users
需求：确认会员余额总额是不是100046628.97这个数。
思路：找到单个会员，它有自己的余额。把所有的会员的余额进行显示。应该得到就是这个数，和页面上的数据看到的是不是一样。
用户余额：user_money
select sum(user_money) from tp_users;
查询的数据和页面的数据是一样的，说明页面关于这个统计数据是没有问题的，如果不一样，说明有问题。
1.2.2 借助数据库进行缺陷定位
进行BUG定位时，有时需要到数据库查看数据的详细信息
出Bug，看Bug的位置在哪？
一般前台这个页面的问题，会说是前端的问题。或者后面看不着的python代码，php代码，后面代码的问题，会说是后端的问题。
要想更清楚，需要学习接口知识。这里知识简单的了解一下。
这里举一个例子：tp_user表
sex 0 保密 1 男 2 女
后台修改性别信息以后，看到的结果和你想改完的结果是不一样的，这时出现一个bug，你要确认的是页面上的问题，还是代码上的问题。
先登陆
在个人信息里
这里有可能没有办法复现问题，有可能修改了代码。理解意思就行。
如果保存的是保密，显示保存完是男或者是女。我们要分析是什么原因导致的。需要判断是前端的问题还是代码的问题。
这里是根据手机号查询性别是女。
select sex from tp_user mobile=13488888888;
假设保存的是女，显示保存完是保密，数据库存女，说明是页面没有显示对，后端的代码没有问题。
假设保存的是保密，显示保存完是保密，数据库存的是女，那说明是后端代码的问题。
通过对比来校验，你不要被页面上的一些现象所迷惑，真正去检查结果的时候，需要去数据库里面进行结果的一个确认。
如果数据库和页面上是一样的，说明没有什么问题。如果有差异，有可能是前端或者后端出现了问题。
1.2.3 借助数据库构造测试场景（需要特定的测试数据）
构造某种测试场景时，可以在数据库里直接修改数据，要比使用界面更有效率
构造测试数据
前面提过UI界面设计，会检查UI界面的内容，文字信息，UI设计。
案例：
我的购物车显示你加入购物车的数量，这个数量是一个小圆标，你加入一个数据以后，这个小圆标会有数字，那有没有担心过，我加入的这个数量，太多了，这个小圆圈会压倒这个文字，或者说会把这个页面撑变形，我这个设计还在不在，
会不会影响这个美观，有没有这个顾虑，怎么去测？比如加了10000个，加了9万9千9百99个，它这个圆圈形状会不会影响购物车设计，会不会压到这个文字。
手机加了120个，这个圆圈会变成一个椭圆。刚才没有的时候，是个小圆圈，购物车就有设计上的改变了。
一会儿看在一些特殊的情况下面
比如说输入5位数，它这个圆圈会不会接着往这边扩，往这边走走，会不会把这个撑的更大，会不会把这个圆圈撑变形了。
那怎么让这个数据更大？
加入购物车最大显示的是多少？
是不是商品总类的限制？是不是商品数量的限制？这里多能加多少种类的商品？是20种。每一个商品，库存充足的情况下面，最多能加200个商品。
20*200=4000,通过页面这个规则，最多只能显示4000个，也就是4位数。
现在这个情况可能比较特殊，比较极端，看能不能显示加5位数，6位数，7位数等等这样的数据，它会不会影响你这个页面显示的效果。
我们没办法通过页面扩大到5位数进行测试，而且你在页面测试的时候，你是不是一个个去加这个商品，只能加到4000，我们要想测一万个，两万个，十万个怎么办？
从数据库找到对应的表来修改这条商品的数据，这个表叫购物车表，tp_cart。
字段是goods_num，购买数量。
我们可以查一下当前这个购物车购买数量是多少，可以加限制条件，因为这里只有一条购物数量的记录，就直接查了。你会发现购物数量是121，这个121就是页面的这个数字，因为没有别人，只有我一个人在用这个系统。我可以这么干，
没有加限制条件。
select goods_num from tp_cart;
我们可以像下面这样，通过一条update语句，把这个数字改了，这样就比页面加加更高效。查询goods_num是4000。
update tp_cart set goods_num=4000;
select goods_num from to_cart;
从页面上看，刷新是4000，圆圈变大了，同时我这个页面还是在这个框里面，并没有影响，有没有压到这个文字。
再测大一点，99999。查到的是65535。
update tp_cart set goods_num=99999; select goods_num from to_cart;
去页面上看，刷新也是65535。先不解释为什么设置的是99999，但显示和查到的都是65535。但是我们这里测试清楚了，我们测5位数，也没有影响我这个页面的显示。
这相当于我们的第3种场景，通过数据库来构造测试数据，高效的去辅助你进行测试。不用你去一个个加商品，换成登陆里面，你要有一万个登陆用户，或者一万个注册用户的话，你的注册信息你会填死。
可以通过sql语句来执行。
这里解释一下，为什么是65535。不是99999。
原因就是这个数据类型（smallint(5)unsigned）决定的，咱们这些整形数据，实际上是有边界的。它的最大值就是65535。这个整形数据，这个数据库里面定义的数据类型所决定的。
再延伸一下，我们的边界除了长度，还有一些类型它也是有边界的，比如说数字型。2位数，它的最大边界是99，5位数，整形数据它的边界就是65535。
另一个问题：不应该显示99+吗？
99+是我们的微信消息，比如说我有多少条消息，我可以显示的是99+,这也是一种显示方式。我们这里显示65535，也是一种实际的显示方式。
不管你是哪种显示模式，这要是取决于你的实际产品，比如微信，消息提示类，我可以固定是2位，超过2位，显示的就是99+，你点进去以后，可以看到全部，这也是一种，当然还有一种我们这个系统里，我可以把这个全部展示，但那时这
个形式，也是进过设计的，它不会影响到我这个页面的UI设计展示效果。
这些语句，select，insert，update，delete。叫做数据库操作语句。
数据库定义语句：create，drop，alter。（修改表结构）
1.2.4 借助数据库数据备份更新
软件升级过程中，有时会涉及到历史数据的处理，这种情况需要执行升级SQL，并验证结果
我们做大，做强了，当我们的产品更新以后，可能会执行sql语句，这个sql语句，只需要检查它对还是不对。不需要关注这个表，这个数据是怎么建的。
例子：
用户表 tp_users
比如想在当前用户绑定一个蚂蚁积分，原来的表肯定没有这个字段。新增一个蚂蚁积分字段，默认值是100。
alter table tp_users add myjf int(3) default 100;
影响到的是2000多行。看一下结果。
select * from tp_users;
可以看到最后添加了一个字段：myjf。默认值是100。
我们作为测试：
1.复制语句执行
2. 确认一下这个结果，测试通过。
如果报错了，把这个报错信息给开发。如果我能指明这个错的地方就说明我很nb。
这就是第4种场景，新增字段，给旧的数据加默认值。当然这个sql语句，不需要我们去写，交给我们测试的时候，把这个sql语句复制过来，在测试环境里面去执行一下就完事了，现在只是熟悉一下它，万一有什么错，看的懂得话可以告诉开
发。