完善古诗模块相关接口文档,完善了应用的数据

作者: www.9159.com  发布:2019-11-07

我们MySQL线上环境大部分使用的是5.7.18的版本,这个版本已修复了很多bug,但针对主从复制的bug还是有很多的,尤其是一些组复制、并行复制的bug尤为突出,在5.7.19版本有做相应改善和修复。所以建议5.7.19之前的版本还是不要使用mgr和并发复制的功能,如使用建议升级至5.7.19(含)以后的版本。

这周完成的

  这周发布了教师端和学生端的2.1.4版本,在这个版本中实现了各个模块的分享功能,其中包括签到分享,配音报告分享,配音播放分享,作业报告分享和排行班分享等,修改了注册流程,完善了邀请码的提交机制,修复了应用在第一次使用是切换到后台并被系统杀死后数据异常的bug,完善了应用的数据缓存机制,修复教师端了并发条件下的发生的数据初始化bug,修复了日历控件的初始化的bug.

一、 测试周期

测试周期一般为2~3天,根据项目情况以及版本质量可适当缩短或延长测试时间。正式测试前先向主管或产品经理确认项目排期。

这周完成的

后台:

1 复现并解决线上数据接口在高并发的情况下锁竞争导致耗时异常的问题。

2 针对招生活动复杂版进行全面测试,配合web端与安卓端解决部分技术难点,完善招生活动创建后的数据推送机制。

4 对iOS教师端进行全面测试,完善并部署相关后台数据接口。

3 完善古诗模块相关接口文档,完善题库测试数据,配合web端梳理古诗模块功能流程,推进古诗模块的开发进度。

安卓端

1 对crab上的线上崩溃信息在worktile上进行梳理,对问题进行定位和复现,解决部分崩溃问题。

2 修复在iOS测试期间发现的bug,完善部分UI细节与功能细节

3 对iOS教师端招生活动模块进行全流程测试,对iOS线上教师端进行全面的页面适配测试,配合iOS端推进招生活动的开发进度。

web端

1 实现古诗模块的部分UI界面,推进古诗模块的开发进度

2 对招生活动编辑页面与预览页面进行测试,完善相关UI细节和功能细节。

iOS端

1 对教师端的页面适配进行测试,修复发现的所有页面适配问题并发布新的正式版本。

2 定位并修复学生端提交作业失败的问题并发布新的线上版本

3 对招生活动的整个功能流程进行测试并发布测试版。

我这里遇到的问题主要是莫名其妙的数据同步出现问题,无法执行stop slave,数据不一致等现象,经过查看发现是版本bug所致,所以对已上线的从库关闭并发复制,对未上线的系统实行版本升级。此风险非常非常高,各位务必重视。

接下来要做的

   在这周分享和邀请功能已经基本完成,但是仍然有很多细节需要处理,在进一步完善和优化之后需要发布更新各大应用商店的线上版本,在分享功能和邀请功能上线以后需要尽快推进作文模块的设计与实现,同时收集并修复crab上的bug,提升应用的稳定性.

二、 测试资源

测试任务开始前,检查各项测试资源。

  1. 产品功能需求文档、概要设计文档(包含非本期开发的产品功能部分)

  2. 产品原型图(包含非本期开发的产品功能部分)

  3. 产品效果图(包含非本期开发的产品功能部分)

  4. 测试用例(包含非本期开发的产品功能部分)

  5. 行为统计分析定义文档

  6. 测试设备(ios7-ios8;Android2.3-Android4.4, 也可兼容到5.0)

  7. 其他(例如有限时抢购类的项目,需要规划时间表;有优惠券使用的项目,需要申请添加优惠券数据;支付宝/银联支付功能的项目,需要提前申请支付宝/银联账户等等)

接下来要做的

后台

      接下来需要对招生活动复杂版的全部数据接口进行测试与更新部署,配合微信端整合活动创建后的数据推送流程,对招生活动的整个大闭环进行测试,做好招生活动功能模块发布上线的准备,同时对古诗打卡模块的全部数据接口进行梳理和测试,完善相关数据接口文档,配合web端推进古诗打卡模块的整体开发进度。

安卓端

  定位并解决线上发现的崩溃与ANR的严重bug,发布教师端与学生端的线上修复版本,对招生活动复杂版进行全流程复查,提升线上版本整体的稳定性,做好发布上线的准备,对整个安卓端的核心功能模块进行集中优化与完善。

web端

    对古诗模块的题库功能进行梳理与拆分,实现题库模块的核心功能流程与10种题型的UI界面,同时对招生活动相关页面进行复查做好发布上线准备,对接古诗模块数据接口,全力推进古诗模块的整体开发进度。

iOS端

    修复招生活动目前已知的问题,发布教师端招生活动复杂版的测试版本,对招生活动模块进行全面测试,提升正确性与稳定性,做好上线教师端招生模块的准备,同时对教师端与学生端的线上崩溃信息进行持续的分析与定位,及时修复发现的严重bug,确保线上正式版本的稳定性。

具体5.7.19修复的复制bug如下:

三、测试要点

  1. 接收版本

    1. 个人认为,我们目前的团队可以略过,但需要在svn上创建分支,称为“测试版本分支”,在发布后,代码进行封存。
    2. 在测试之前,需要向主管、产品经理确认当前测试版本的版本号与版本名
    3. 要区别对待本期开发的功能与已发布的功能
  2. UI测试

    1. 确保手头的原型图与效果图为当前最新版本。
    2. 确保产品UI符合产品经理制定的原型图与效果图。
    3. 一切界面问题以效果图为准,若有用户体验方面的建议,必须先以邮件或口头的形式询问产品经理。
    4. 由于测试环境中的数据为模拟数据,测试时必须预先考虑到正式环境中可能出现的数据类型。
  3. 功能测试

    1. 确保手头的功能需求文档为当前最新版本。
    2. 确保所有的软件功能都已实现且逻辑正常。
    3. 一切功能问题以需求文档为准,若有用户体验方面的建议,必须先以邮件或口头的形式询问产品经理。个人建议,用户体验方面的建议,优先级放在修复bug之后。
    4. 若有些功能在技术上难以实现或者由于排期的原因无法在短时间内实现,必须得到产品经理的确认,而不是单单只听开发人员的技术解释。此处确认最好以邮件形式存在。
    5. 所有的“外部原因”问题,都需要尽早地督促开发人员与客户服务端人员联系协调解决。并在之后的测试报告中予以体现。
    6. 所有的“设计如此”、“延期处理”问题,都需要和产品经理确认后再进行验证。并在之后的测试报告中予以体现。
    7. 测试下单时,注册的测试账号必须符合公司规范;收货地址必须包含“测试”关键字,最好每次下单的名称中含有日期,以便查询;在正式环境中下单后必须取消该订单等。
  4. 兼容测试/性能测试

    1. 确保软件在所有兼容机型上都能正常使用(ios一般需要兼容到6, ios5可以不用考虑,用户使用率已经低于5%以下)
    2. 性能测试方面必须满足硬件压力条件下的测试需要(例如多线程,用户常用的app都要后台运行的环境中测试。)
    3. 网络响应用户体验方面的性能测试,需要保证在wifi、3g、2g网络下的切换效果。比如wifi切换到2g,网络响应的速度以及切换界面。
  5. 后台订单统计测试

    1. 核对“客户端相关启动查询”项,此项数据就是经常说的“激活量”,非常重要。测试时必须保证该项中的各数据均正确,且每次启动软件都会有相应的统计记录。
    2. 核对“订单查询”项,测试时必须保证各数据均正确,且每次成功下单后都会有相应的统计记录。
    3. 需要注意的是,在成功下单之后,后台会做判断将该订单划到测试订单范围,测试人员必须到“订单查询(测试)”模块中核对订单统计记录信息。
  6. 用户行为统计测试(这个暂时略过不提)

    1. 确保手头的行为统计分析定义文档为最新版本,且与开发人员手中的文档一致。
    2. 确保产品经理在文档中所定义的页面在该产品中都是存在的。
    3. 尽可能真实地模拟用户行为。
    4. 核对统计日志,确保各项操作所对应的页面ID以及操作ID都是正确的。
  7. 回归测试

    1. 软件最终上线前,需对产品进行回归测试,测试内容包含之前所有的测试项目
    2. 回归测试不再对细节进行测试,而是类似于对产品进行验收,从客户正常使用的角度对产品进行再一轮的整体测试。
    3. 只有在回归测试通过之后,才对产品进行提交。

参考手册:

四、bug修复

  1. 测试人员提交测试日报,到主管、产品经理
  2. 主管与开发人员确认bug
  3. 主管与产品经理协调修复方案(有文档记录)
  4. 主管安排开发人员在测试版本分支上修复 bug (有文档记录)
  5. 开发人员修复完成后,通知测试人员已修复相关问题
References: See also: Bug #84107.

Replication: In the case of delayed initialization of the Group Replication plugin, deployed in single-primary mode, secondaries were able to get writes through an asynchronous replication channel, which is not allowed in normal initialization of the Group Replication plugin. (Bug #26314756)

Replication: With GTIDs generated for incident log events, MySQL error code 1590 (ER_SLAVE_INCIDENT) could not be skipped using the --slave-skip-errors=1590 startup option on a replication slave. (Bug #26266758)

Replication: A USE statement that followed a SET GTID_NEXT statement sometimes had no effect. (Bug #26128931)

Replication: Groups can now contain members running different server versions to enable you to do online upgrades of a replication group. The rules for combining members in a group with different versions are:

    If you have a group with 8.0 members, you cannot add a 5.7 member

    If you have a group with 5.7 members you can add a 8.0 member, but it remains in read-only mode. Writing to this member is dangerous while the group contains multiple server versions and should be avoided.

In a single-primary group, if the current primary leaves the group and a new primary must be elected, the primary is first chosen from the lower version members. If no lower version member is found, the primary is chosen from newer version members. (Bug #25876807)

Replication: When binlog_checksum=NONE was set on a MySQL server after startup, and then Group Replication was started, if an error occurred, the server remained in RECOVERING state and could not be shut down. (Bug #25793366, Bug #85667)

Replication: In a Group Replication setup where circular asynchronous replication was implemented between members of different replication groups, view change log events were repeatedly replicated between the groups with new generated GTIDs each time. The fix ensures that view change log events are ignored outside the named replication group where they occur, and never generate new GTIDs. (Bug #25674926)

References: See also: Bug #26049695, Bug #25928854, Bug #25721175.

Replication: When first starting the MySQL server following an installation from RPM, passwword validation plugin is activated by default (true only for RPM installations). If binary logging was already enabled at this time, the activation was logged, even though plugin activations should not be recorded in the binary log. (Bug #25672750)

Replication: In a setup where single-primary Group Replication was combined with asynchronous replication, for example with S1 and S2 forming a group and with S2 and S3 functioning as master and slave, secondaries such as S2 were accepting transactions and these could then enter the group. The fix prevents secondaries creating an asynchronous replication channel when belonging to a single-primary group, and Group Replication cannot be started when asynchronous replication is running. (Bug #25574200, Bug #85047)

References: See also: Bug #86325, Bug #26078602.

Replication: In the event that a member failed to join a group the member was not stopping and continued to accept transactions. To avoid this set your members to have super_read_only=1 in the my.cfg file. Group Replication now checks for this setting upon successful start up and sets super_read_only=0. This ensures that members which do not successfully join a group cannot accept transactions. (Bug #25474736, Bug #84728)

Replication: If the binary log on a master server was rotated and a full disk condition occurred on the partition where the binary log file was being stored, the server could stop unexpectedly. The fix adds a check for the existence of the binary log when the dump thread switches to next binary log file. If the binary log is disabled, all binary logs up to the current active log are transmitted to slave and an error is returned to the receiver thread. (Bug #25076007)

Replication: Interleaved transactions could sometimes deadlock the slave applier when the transaction isolation level was set to REPEATABLE-READ. (Bug #25040331)

Replication: If a relay log index file named relay log files that did not exist, RESET SLAVE ALL sometimes did not fully clean up properly. (Bug #24901077)

Replication: The slave_skip_errors system variable did not permit error numbers larger than 3000. Thanks to Tsubasa Tanaka for the patch. (Bug #24748639, Bug #83184)

Replication: mysqlbinlog, if invoked with the --raw option, does not flush the output file until the process terminates. But if also invoked with the --stop-never option, the process never terminates, thus nothing is ever written to the output file. Now the output is flushed after each event. (Bug #24609402)

Replication: A memory leak in mysqlbinlog was fixed. The leak happened when processing fake rotate events, or when using --raw and the destination log file could not be created. The leak only occurred when processing events from a remote server. Thanks to Laurynas Biveinis for his contribution to fixing this bug. (Bug #24323288, Bug #82283)

Replication: A slave server could lose events not yet applied when MASTER_AUTO_POSITION=0, both replication threads were stopped, and the applier delay was changed using CHANGE MASTER TO MASTER_DELAY=N. (Bug #23203678, Bug #81232)

References: See also: Bug #25340185, Bug #84375.

Replication: Transmission of large GCS messages could take so long the sender appeared to have died. (Bug #22671846)

Replication: Multithreaded slaves could not be configured with small queue sizes using slave_pending_jobs_size_max if they ever needed to process transactions larger than that size. Any packet larger than slave_pending_jobs_size_max was rejected with the error ER_MTS_EVENT_BIGGER_PENDING_JOBS_SIZE_MAX, even if the packet was smaller than the limit set by slave_max_allowed_packet.

With this fix, slave_pending_jobs_size_max becomes a soft limit rather than a hard limit. If the size of a packet exceeds slave_pending_jobs_size_max but is less than slave_max_allowed_packet, the transaction is held until all the slave workers have empty queues, and then processed. All subsequent transactions are held until the large transaction has been completed. The queue size for slave workers can therefore be limited while still allowing occasional larger transactions. (Bug #21280753, Bug #77406)

Replication: An incident event that broke replication was not written to the binary log with a GTID, so that it was not possible to skip the event using SET gtid_next=value. Instead, it was necessary to set the relay log file and relay log positions directly; this meant that, when autopositioning was enabled, it was necessary first to disable it, then to set the relay log file and position, and finally to re-enable autopositioning.

Now in such cases MySQL writes the incident event into the statement cache, so that a GTID is generated and written for it prior to flushing, and that the slave applier works with the change. Then users can skip the event using the SQL statement SET gtid_next=value, followed by BEGIN and COMMIT. (Bug #19594845)

Replication: In certain cases, the master could write to the binary log a last_committed value which was smaller than it should have been. This could cause the slave to execute in parallel transactions which should not have been, leading to inconsistencies or other errors. (Bug #84471, Bug #25379659)

Replication: When using group_replication_ip_whitelist=AUTOMATIC, IPs in the private network are permitted automatically, but some class C IP addresses were not being permitted correctly. (Bug #84329, Bug #25503458)

Replication: When an existing GTID_NEXT transaction was assigned a conflicting GTID by the server, Group Replication generated an assert upon detecting two transactions with same GTID. This was because Group Replication generates the GTID after conflict detection, which is later than with master/slave replication. The fix relaxes some conditions to only be called when commit is done and a message has been added to alert you when a GTID has already been used. (Bug #84153, Bug #25232042)

Replication: The replication applier thread returns Error 3002 ER_INCONSISTENT_ERROR when there is a difference between an expected error number and the actual error number. It is now possible to ignore this error by using 3002 with slave_skip_errors. (Bug #83186, Bug #24753281)

Replication: MySQL lost its GTID position following a restart when a dump from mysqldump had been used to load data.

To keep this problem from occurring, the mysql.gtid_executed table is now excluded automatically from dumps made by mysqldump. (Bug #82848, Bug #24590891)

References: See also: Bug #87455, Bug #26643180.

Replication: Corruption of relay logs for one channel in multi-source replication caused good channels not to be initalized during a server restart. In addition, when run with --skip-slave-start=false, the server also failed to start slave threads for those channels which were in good condition, despite the fact that it should have started the slave threads for all good channels.

Now, regardless of any errors on other channels, the server attempts to create and initialize channels that are in good condition, and starts slave threads for the good channels if --skip-slave-start is disabled. As part of this fix, START SLAVE and STOP SLAVE, which are intended to operate on all channels, are also modified such that they continue executing on all good channels even if they find bad channels among them. (Bug #82209, Bug #24285104)

Replication: The SQL thread was unable to GTID skip a partial transaction. (Bug #81119, Bug #25800025)

Debian client packages were missing information about conflicts with akonadi-backend-mysql packages. (Bug #26002288)

五、 测试日报及产品上线报告

  1. 测试人员每天需对所测项目发送测试日报。

  2. 测试日报所包含的内容为:

    1. 对当前测试版本质量进行分级。
    2. 对较严重的问题进行例举,提示开发人员优先修改。
    3. 对版本的整体情况进行评估。
    4. 对版本测试过程中修改的内容进行记录。
  3. 产品上线前,测试人员发送产品上线报告(记录产品测试记录、修复情况、最终部分)

六、测试版本分支主线版本的合并

由于测试版本分支的上修改的某些代码只是为了暂时性的修复某些问题,随着我们代码量的增大,也许有时候不太会适合提交到主线版本。

  1. 开发人员、主管、产品经理集体确认需要把什么代码合并到开发主线

 

本文由9159.com发布于www.9159.com,转载请注明出处:完善古诗模块相关接口文档,完善了应用的数据

关键词: