【对每一个重要的缺陷修复都要新增一个测试用例与之对应】
这个比较好，需要反复的验证，到上线前还是需要验证，但容易忘记，
这时跑一下新增的这些用例，可以避免漏测。
【重要的功能都要经过集成测试，每一个特性至少有一个与之对应的集成测试用例】
在写用例时，针对特性会有详细的功能测试用例，同时也建议出集成测试用例：罗列表格的方式 或流程图 或思维导图（为了把相关因素、关联的流程一起测试到位）
【有冒烟用例，在每次代码转测之前都要求通过冒烟测试】
【TE需要考虑以下问题】
当前软件的薄弱点在哪里
有没有安全、隐私、性能、可靠性、可用性、兼容性、全球化和其他方面的问题
主要用户场景是否功能正常
当发生问题时，是否容易诊断问题所在
等等。。
找到薄弱点，通过测试使软件出错，然后与开发、产品一起推动解决这些bug。
TE并不需要自己去解决所有这些问题，但必须保证这些问题被解决掉。
保护用户和 业务的利益，使之不受到糟糕的设计、令人困惑的用户体验、功能bug、安全和隐私等问题的困扰。
一个TE同时参与几个项目也很常见，尤其是那些具备安全、隐私或全球化等专门技能的TE。
【具备专门技能的TE，是以后的目标】
TE对技术能力、领导力、深刻理解产品的能力等多方面的要求，有很强的人格魅力和优秀的沟通技巧。
【在Google，TE的工作描述为：“从中间开始”，必须保持足够的灵活，能迅速融入一个产品团队的文化和现状】
【罗列产品的特质，几分钟的事情，看对它的熟悉程度】
1、支持大班直播教学
2、支持小班直播教学
3、支持看点播
4、课前预习、课后练习，及智能推题
5、支持SAAS服务，可以为学校开通直播、点播服务，建立自己的数字学校
6、看课数据的推送和展示
7、支持微信支付、分享页购买、分享页看课等等
8、价格体系
软件测试的风险分析，可参考的因素：
1、哪些事件需要担心
2、这些事件发生的可能性有多大
3、一旦发生，对公司产生多大影响
4、一旦发生，对客户产生多大影响
5、产品具备什么缓解措施
6、恢复过程有多困难
7、事件是一次性问题，还是会再次发生？
编写测试计划，去掉冗余，只留下精髓，列必要的东西，把细节留给测试执行者，而不是测试计划者。
大家十分清楚在测试过程中不大可能完成所有测试点，既然如此，为什么要求在测试计划中面面俱到呢，在测试真正开始以后，项目日程、需求、架构等都可能发生变化，既然如此不必执着于计划的精准。
【学习风险管理方法】
【除了提升技能，还要积累人脉、开拓眼界】
马斯洛之所以把“自我实现”放在需求的最上层，也就意味着，自我实现这件事情，是需要建立在一系列的保障和基础之上才可以完成的。