本次版本内容涉及公司最重要的业务调整，其中逻辑、流程都发生了重大变化，页面进行重新设计开发，所以需要测试的内容比较多。包含 UI 测试、功能测试、流程测试、旧数据处理、邮件内容确认。
本次版本测试时间 2 个星期，测试人员 2 人（不包含写测试用例时间）。
测试用例准备：1人，1个星期。中间参杂其他任务测试。
测试的用户角色：学生（高中生、大学生）、导师。
角色区分国家线：北美、英澳
用户：测试用户、付费用户
导师：测试导师、付费导师
学生预约上课方式：管理员直接预约、管理员模拟学生预约、学生登录自己预约、再次预约、特殊服务预约。
可预约的项目：9个项目
部分功能由于旧数据、邮件格式、环境问题，于上线后进行测试。比如：邮件内容确认、旧数据处理后数据新确认、广播、上课评分问题。
上线后问题汇总：
时区问题。比如学生预约9点的课，显示预约的10点的课。
原因：北美实行夏令时，时间会提前一个小时。所以导致部分时区的学生预约时，上课时间会延后一小时。
谁发现的问题：在上线之前，与对应的业务人员进行培训，预约课程时发现的问题。庆幸是在上线前发现的，不然影响较大。
以后如何避免这个问题：在测试时，注意查看线上用户使用的时区，需要抽出几个时区进行验证，尽量将场景覆盖全面。在上预发环境之前，对导师的设置已进行旧数据处理，上线后未再次执行脚本。导致在上预发环境与上线上环境这段时间内新招的导师未进行数据处理，无法预约课程。
原因：上线前评估不到位，未想到这段时间新招的导师有影响。
谁发现的问题：上线后，业务人员过程中发现无法预约导师，爆出问题。因之前已准备好脚本，所以执行后问题即刻解决，影响不大。
以后如何避免这个问题：对于旧数据的处理，如果是在上预发环境时进行的处理，注意上线后是否还需要进行再次处理。线上邮件内容不对
原因：开发代码问题。因功能必须上线后验证，所以与测试无关。测试已在实际用户使用未发现问题之前发现问题，并督促开发进行了修复。因套餐不同，扣取的方式不同，导致部分用户无法预约课程。
原因：一类套餐上课课时 -1，一类套餐上课 -4。前端判断条件写反，导致课时 <4 时，应该可以预约课程的用户无法预约。当时测试时这里有出现其他问题，在开发修改问题之前，测试验证 <4 的情况正常，<1 的情况有问题。修复问题后，验证了 <1 的情况，未回归 <4 的情形。导致线上报错。
谁发现的问题：上线后用户反馈的问题。这个属于测试问题，测试未发现，影响较大。
以后如何避免这个问题：开发修复问题后，记得相应功能均进行回归，交叉所有场景。不要修复前校验一种场景，修复校验另一种场景。导致场景遗漏，线上出错。课程删除后，学生仍然可以预约此课程的课
原因：测试时只考虑了新增和历史数据情况，未考虑到删除后的情景。且当数据为空时，用户端显示数据不对。
谁发现的问题：上线后，业务人员暴露的问题。
以后如何避免这个问题：对于页面上显示的数据，测试需要了解清楚数据的获取逻辑，测试时需要考虑新增、删除、编辑、旧数据、为空、数据量大的情景，进行一一覆盖。用户点击链接，进入课堂上课失败。
原因：window.open兼容性问题，点击链接新打开一个网页进入上课。PC 端用户进入上课正常，安卓手机端正常，苹果手机端点击链接上课失败。影响较大，紧急修复为不新开网页打开链接上课。
谁发现的问题：上线后，业务人员暴露的问题。
以后如何避免这个问题：因大部分用户使用的是 PC 端，所以惯性忽略了手机端，未进行手机端回归测试。之后测试时一定要注意回归手机端功能。还有一些其他因网络不好，产生的问题。很难复现，发生概率较小。
此次发版产生问题多，影响较大。部分问题因测试回归不到位，导致影响线上用户的使用。虽然因为穿插其他紧急任务测试，导致测试时间不够充足，但是部分属于测试考虑不全面导致的问题。作为测试人员，我们应时刻保持头脑清醒，注意测试是否全面，尽量将功能覆盖全面。
测试是产品的质量把控者，应不断提升自己的测试思维，提升自己的专业能力，把控好产品的质量。每次发版都胆战心惊的，特别是大的业务版本，觉都睡不好，担心出问题。每次自己都调侃自己从事的是高危行业，同行的同志们，加油！
