【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）
比如：下架操作，每次发版本后，进行下架操作，都无法弹出确认提示框；清理缓存能解决问题（后面开发跟进，找到了原因：
一般刷新一下就就好了）
比如：Iphone X 在输入文字时的用户体验
比如：我的订单，非正常流程中，先下单（待支付，有效期30分钟），从APP端再购买或导入学生，原待支付订单仍存在
-
对同步程序的异常测试
容错能力：APP服务挂起后，WEB端下单，能正常使用（APP服务起来后，订单的修复机制）
WEB服务挂起后，APP端下单，能正常使用
同步程序的压力测试在之前版本已经弄过了
-
关注迭代的SQL脚本
比如：新增字段的初始化值是否正确。
- 关注对页面性能的影响
订单实现web与APP端互通后，在课程详情页查询购买状态时，增加查询对方系统是否购买的步骤，在webapp端需要验证性能是否满足。