U站软件测试团队回顾总结
● 项目情况和测试难点：
依赖环境多，系统复杂度高，沟通协调成本大。
● 测试做的不错的地方：
1、对于项目测试管理的控制把握，问题的及时跟踪很清晰。
- 每日测试晨会，汇报测试进度和风险。
- 项目测试进度及时更新给项目组。
2、对于质量的保证：
- 测试执行期间共发现444个有效bug， 其中321第二次迭代发现，共10个工作日，平均每天32个有效bug.
- 保证较高的测试覆盖率62.5%。
- 对于bug的坚持：n 云木同学对于bug的坚持和解决问题的建议，追踪
3、系统相关功能的测试覆盖度和深度。
- 接口测试脚本，直接调用系统的接口，覆盖了28个，覆盖率93%。
- PHP，覆盖183个，覆盖率45%。
4、并行多条的快速反应和协调。
- 后期并行的各种系统的环境协调，并保证项目按时上线发布。
- 协调性能，安全测试团队并行评估风险，及时制定方案及措施，保证功能的同时，安全和性能也没问题。
● 测试需要提高的地方：
1、工作量评估不足：
- 对于系统的复杂度和各个系统的环境稳定性估计不足，结果第二次迭代时间非常紧张，未来需要借助评估模型提高测试工作量评估的准确性。
- 测试过程中，发现很多设计的时候无法考虑到得功能点，测试需要及时跟进TC改动并且录入系统，避免越忙越乱。
2、需要解决测试账号可重复使用问题：
- 现在测试账号用了不能重复使用，尤其线上账号资源非常紧张，语瑶Drive解决测试账号可以重复使用的问题。
3、工作的分配，需要做好备份机制：
- 例如：云木主要负责TAE的工作，但是后期并没有其他人可以比云木更加熟悉TAE，难以在工作紧张的时候帮助。
4、严格控制提测版本的质量：
- 对于主流程没有走通的产品版本，必须及时打回，不能因为测试时间紧张而勉强接受，造成后期测试时间和压力加大。
5、提高自动化脚本在测试流程中的作用：
- 一期很多自动化脚本的变化较大，在测试中发挥的作用并不很好，未来，需要补齐稳定回归，同时降低维护成本。
- 需要做起来U站项目的自动回归，用于开发自测。
6、提高对于后端代码的熟悉度：
- 发生过太多次开发的一个小改动造成了其他地方的bug，这种概率非常高。未来测试需要熟悉后端开发代码，要比开发更加清楚一个代码改动可能会带来多少问题。
7、做起code review机制：
- 测试Review开发的改动代码，降低回归不足的风险。
8、提高ISV相关的测试力度：
- 一期中，依赖的系统的可使用性，并未正式纳入测试范围，但ISV使用过程中遇到很多问题，未来需要考虑如何提高这部分的功能稳定性。
9、脏数据清理工作：
- 本项目的安全扫描比较特别，有线上安全扫描的部分，造成了线上安全测试的脏数据，未来需要制定清除机制。
● 对于PD同学的要求：
1、分工明确：
- 项目的PD比较多，需要非常明确的分工，避免一个问题两个人跟进，造成了前后不一致的事情发生
2、建议虚拟团队：
- 整个项目中的沟通协调实在是痛苦的问题，是协调各个团队的工作，自下而上推得累。烟霞已经在drive了。
3、需求全部走workflow track.
- 所有变动必须走workflow，提前通知测试同学，否则不予测试。
4、控制发布频度：
- 除非P1，P2 bug，其他走日常，避免频繁发布造成的人力消耗。
5、加强视觉稿和交互稿评审：
- 视觉稿的异常流很少，前端自己YY，效果和PD不一致，造成不断返工。
- 前端只看视觉稿做事，但是项目中对于视觉稿的评审力度远不如PRD，未来加强视觉稿和交互稿评审，同时前端也要多考虑PRD的设计，避免遗漏。
6、提高项目前期review效率：
- 前期review PRD需求等花费了大量时间，后期的开发测试周期压力相对变大。
- 各种review meeting的效率极其低下，请大家必须线下review，会上只处理收集到得意见，不能在会议上临时进行review. 这同时要求PD/视觉/交互需要提前几天发出文档。
7、资源提早安排：
- 例如，前端资源。
8、信息及时沟通：
- 保证信息周知到团队成员。
● 对于开发同学的要求：
1、环境稳定性问题：
- 严格遵守日常环境，预发环境的重启时间约定，避免测试环境不稳定造成的测试时间浪费。
2、代码变化需要同步项目组同学：
- 任何对于代码的优化，改动，无论多小，必须通知测试和PD同学，走流程，避免混乱。
- 更加不可以私自发布上线。
3、提高单元测试和自测力度：
- 鼓励开发同学内部进行单元测试的分享。
- 前后端联调的部分需要做充分自测后再提给测试同学测试，后期测试主导做好监督机制，相关smoke test没通过，不接受测试。
4、发布权限和能力：
- 每个开发同学都要有线上发布的能力，但是发布权限需要PM的严格控制。
5、开发内部互相code review：
- 严谨的对待自己的每次改动，无论多么小，大部分开发同学都曾经顺手做过一件小事，结果证明只要细心点，都不会错。
- 开发内部互相review代码，加强这个部分，同时提高开发代码质量。
- 这个部分测试同学也需要通过代码review来协助提高。
6、不要改动初期约定好的接口定义：
- 在开发中后期，除非不得已，不能改动接口定义，否则会造成测试同学接口测试的浪费和返工。
7、开发分工更加均匀：
- 核心模块不能仅有一个开发负责
- 测试也有这个问题，后期可以考虑把每次迭代的工作内容更加细化，并且分给不同的同学负责。同时可以做好备份机制。
8、和合作方保持及时沟通：
- 电话，旺旺，Email， 避免消息没有及时通知合作方，而导致的环境不稳定，造成时间浪费。
● 对于项目的建议：
1、代码使用SVN管理。
2、推拽版增加用户可编辑的模块，后续可以推出模块市场，增加推拽办的丰富性。
3、编码办提供模块代码，降低开发成本。
● 技术支持建议和考虑：
1、自动化掉ISV的反馈机制，接入kelude平台，减少技术支持的人肉投入，云木已经开始推动。
2、开始ISV公共组件的建设和使用。
3、帮助ISV提高站点的功能和性能：
a）前段页面的性能检查，可以尝试使用开源的测试工具：dynatrace，yslow.
b）死链接的自动检查等。
4、考虑如何保证升级兼容：避免每次升级的时候，ISV不得不悲催的改动自己的代码以适应升级。
