【201903】测试版本回顾

　　

【2019-3月】在这个月我们迭代了2个版本

（web系统1个：TB 190315-v1.2.9版本 修复遗留问题

   APP与web交互版本 1个：APP 190328-v2.0.0版本 租户开通APP门户、及web与APP订单双通、APP看直播课体验升级）

说明： 租户开通APP门户、及web与APP订单双通的业务再后期已被取消，现在是开通租户会自动创建租户，目前支持1个学校对应多租户。

 

----------------昨天03-28， APP 版本上线完已经是凌晨2点了，这样的‘’战绩'估计会越来越少了(＾－＾)V-------------------------------

在测试过程中，发现问题需要得到解决，因此写这篇文章记录，有不对的地方望大家多多指教。

项目中的流程

目前是规范的，需求评审--》详细设计评审--》用例评审，冒烟测试-->模块测试--》集成测试--》系统测试

测试过程的困惑

• ①没有理清测试用例的优先级，发现问题滞后（我们是2个tester、1个leader）

 

• ②模块测试时，按用例过了一遍了，再到集成测试时，再看用例测试时，测试状态不佳，看到的就是一堆文字，不愿意细读用例（改进：可以结合xmind梳理的思路测试，如果集成测试时不想看用例文档，如何？待实践验证得知。）

（今天是0409在梳理新迭代版本用例，这次先用xmind梳理了要测试内容（该功能涉及哪些页面、对其他功能是否有影响、需求描述是否清楚或不明确--尽早弄清需求等），及测试方向（功能、兼容性、是否会影响到页面性能等））

（这样再写用例时，思路更清晰、编写时思考哪些是必须作为冒烟用例，哪些用例优先级调低一些（让测试效果更多，发现问题更快））

• ③当模块测试时问题较多，是否继续测试该模块，若停下等开发给你新版本，测试进度又耽搁了，这时应该怎样安排测试任务。

　　　（我们有冒烟测试，在冒烟通过后，再进行细测，如果同一业务相关场景有bug ，其他场景可以暂停，等bug修复后，进行全面测试。）

• ④有时候，在验证数据的正确性时，你会关注验证途径或参照数据的正确性，在找这个参照对象时，你会耗费不少精力，这种？

　　　（需要提高自身数据库查询能力、或提前向开发确认查看数据所在对应的表、及字段，参照数据层来判断）

• ⑤同一原因有多个bug：课程表模块存在1个bug，导致与之相关场景用例均失败

　　　（那多个人测试时，就会提出不同场景的多个bug单，这种，也属于正常现象）

• ⑥对于多人开展测试的分工：愿意测试关键模块（核心功能）、边缘功能测试不够，以及对测试过程的把控（是否按测试计划进行、各模块是否测试齐全）
• ⑦再说到对bug的敏锐度：有待提高

　　　　比如：在测试安卓、IOS APP过程中，关注业务功能、流程实现多一些，在UI和用户体验上，关注不够，需要加强意识

　　　　比如：实际场景中，各平台学年数据基本一致，学年未区分平台，影响不大（但数校平台 已有2017课程数据，那其他平台APP端始终会显示2017）

　　　　比如：下架操作，每次发版本后，进行下架操作，都无法弹出确认提示框；清理缓存能解决问题（后面开发跟进，找到了原因：

 　　　　　　不是缓存的问题  jquery被重复引用了
　　　　　　一般刷新一下就就好了）

 

　　比如：Iphone X 在输入文字时的用户体验

　　比如：我的订单，非正常流程中，先下单（待支付，有效期30分钟），从APP端再购买或导入学生，原待支付订单仍存在

 

• 对同步程序的异常测试

容错能力：APP服务挂起后，WEB端下单，能正常使用（APP服务起来后，订单的修复机制）

  　　　　WEB服务挂起后，APP端下单，能正常使用

同步程序的压力测试在之前版本已经弄过了

• 关注迭代的SQL脚本

比如：新增字段的初始化值是否正确。

• 关注对页面性能的影响

订单实现web与APP端互通后，在课程详情页查询购买状态时，增加查询对方系统是否购买的步骤，在web\app端需要验证性能是否满足。