线上BUG溢出所思

本文涉及的项目是为展示车辆活跃状况，车辆实时分布状态做的场景化展示，为用户提供看板，辅助领导决策；
项目测完半个多月后，猛的收到产品走查的问题邮件，扫了一眼，问题好多，大大小小十几条，身为测试人员保证产品质量的责任感告诉我要立马验证下BUG，定位下原因，是不是测漏了，此处有一个测试小菜鸟的恐慌。
简单介绍下该项目：

1. 项目整体架构：
   

2. 项目指标：
   今日活跃车辆
   今日新增用户
   累计GKUI用户数
   累计车辆销量
   累计行程公里数
   主界面为活跃车辆热力图。

BUG分类

1. 数据源问题；
   ① 累计行驶里程数减少；
   ② 车辆轨迹数据失真；
   ③ 车辆位置数据不合逻辑；
   ④ 今日活跃车辆总数与按条件查询结果不一致—数据不完整；
   ⑤ “今日新增用户”数据指标为空

2. 数据统计问题：
   ①新增用户数比累计新增用户数更小；
   ②车辆品牌下拉项统计不正确；
   ③热力图聚合策略问题：全国展示与放大展示热力不一致；

3. 服务端&前端问题；
   ①年龄筛选不正确
   ②缺少关键指标展示

4. 需求未明确规定，用户体验问题；
   ①响应加载慢；
   ②道路信息隔两分钟消失；

问题溯源

1. 对于数据源错误，数据统计问题可以归纳为大数据问题。
   ① 为什么会溢出这类BUG—没有覆盖到；
   在测这个项目之前，测过的仅仅是基于功能测试的web项目，不涉及数据，没有数据意识。因此在测这个项目时，大部分的关注点均放在页面功能，后台接口上，未对数据来源进行探究，因此以上产品走查提出的数据问题没有在我这次测试的范围内。
   为什么没有数据测试的意识？我想了下，思维中有惰性意识在，求简单方便，探究意识薄弱。对测试中可能存在的测试类型，测试的方面了解不够。
   另外这个项目的用例，也只是我一个人在写，然后执行，没有另外的人来和我一起讨论用例的不足之处，进行用例评审，再深究可能涉及到公司的测试流程层面哈哈哈。
   ② 我可以做些什么？----补救和预防
   既然BUG溢出是测试没有覆盖的领域，属于测试失职，对于超出我当时所认知的测试领域，虽然当时是一头雾水，但在导师的指点下，积极去了解相关领域的知识，从数据的产生，到数据接收，提取，处理，统计，整个过程数据的流转，找到测试的切入口，模拟数据源检查数据的处理规则，统计规则，定位原因，解决BUG；
   对于这次大数据的测试，虽然解决了一定的BUG，但是我的测试方法可能不够成熟，测试不够充分，便去学习了一下大数据领域的相关知识，组件，以及大数据测试方法，多多探究，做了些总结，便于在以后的项目中进行实战。另外，适时了解不同领域的测试，不同的层面的测试方法，也会对避免类似情况出现有益。

   在需求了解，编写用例过程中，防止测试程度不够深，一定要多问几个为什么，怎么来的。

   另外，一个人写用例可能会有覆盖盲区，我相信这就是用例评审这个流程的意义所在，拉上开发，产品，一起讨论用例，直面盲区，用例没有最好，只有更好，被开发，产品，测试共同认可的用例才是好用例。理想与现实总是有差距的，在敏捷开发流程下，项目迭代快，周期短，可能没有充足的时间进行用例评审，修改，再评审，在不影响项目进度的情况下，写好用例之后，可以给同组了解相关项目的同事，甚至领导（如果领导有时间的话），产品，看一下用例，保证没有大的遗漏点，从个人可以做的层面用另一种方式进行用例评审。
   无论如何，保证产品质量，用例评审的流程是必不可少的环节。

2. 服务端&前端问题可以归纳为业务问题
   ① 为什么会溢出这类BUG—忽略或未回归；
   本项目溢出的此类问题，在用例中都有覆盖到，但在测试中未执行，或未回归，仍然溢出BUG，无疑是我的失职。
   为什么会出现这种失职，①没有严格按照用例执行；②性格的弱点，会忽视细节；③没有做到脚踏实地。
   ② 我可以做些什么？—预防&端正态度
   我的测试用例中有覆盖到这些溢出的BUG，但是在测试过程中未执行，我想了想问了问自己，为什么没有执行这条用例，和我的测试习惯有关。我在测试过程中，不喜欢按照用例一条条执行，习惯按照自己作为用户的感觉，来对这个产品进行测试，显而易见的会漏掉一些用例。
   首先，我按照自己感觉来完整的测这个产品有没有问题？是不是一定要严格按照用例一条条执行。我想了一会，答案是，先按照自己感觉测试一下这个产品没有问题，但同时，每一条用例都要过。按照个人习惯进行测试，有可能会发现不一样的用例或用例组合，发现用例之外的BUG，所以我认为，可以先按照自己感觉进行产品测试。而同时，为保证产品质量，用例的遍历必不可少。
   根据这次经验，综合个人习惯和产品质量，设计了一种适合自己的测试方法：

   1. 先按照个人习惯分模块自由测试；
   2. 定时记录执行的用例情况（可以按模块，也可以按天），在该模块按习惯测试完后，对照用例执行没有执行过的用例；
   3. BUG修改后的回归验证：确定相关联会影响的用例，执行相关用例。
   4. 在全部BUG修改完成后，进入下一环境全部按照用例回归一遍；

   测试过程中，无论何时都要端正态度，不断对自己进行心理暗示，脚踏实地，不要投机取巧。

我可以做些什么

对这些溢出的BUG综合来看，可以做的事情有很多：

1. 平时：多了解不同领域的测试，不同的层面，不同类型的测试，不断进行实战，扩展自己的知识领域。
2. 需求了解：一定要多问几个为什么，怎么来的，可以画思路图，流程图帮助自己理清楚需求及底层实现；
3. 用例评审：可以用不同方式进行；
4. 测试：
   ① 先按照个人习惯分模块自由测试；
   ② 定时记录执行的用例情况（可以按模块，也可以按天），在该模块按习惯测试完后，对照用例执行没有执行过的用例；
   ③ BUG修改后的回归验证：确定相关联会影响的用例，执行相关用例。
   ④ 在全部BUG修改完成后，进入下一环境全部按照用例回归一遍；
5. 测试复盘
   ① 有没有溢出BUG？是否是没有覆盖到？为什么没有覆盖到？身为测试人员可以为产品质量做些什么？
   ② 整个项目有没有涉及到新的领域？有没有用到不同的技术方法？有没有深入到产品底层？对自己的测试技术有没有提升；
   ③ 有没有好的工具，方法在保证产品质量的同时可以提升测试效率？
   ④ 目前的测试方法是不是存在问题？有没有好的测试方法？