项目发布验收不严格带来思考

前言

经常会遇到小公司的很多项目在测试环境针对测试数据库 草率的测试完之后就进行上线,然后生产环境暴露出大量问题,而且每个似乎都很严重需要马上纠正的问题。

经过一系列的关键词阐述,发现这个问题其实在整个开发过程中就已经很明显的暴露出了,如果不对这个开发流程进行必要的规范,那么就会导致整个开发团队疲于应付,永远无法进入正轨的开发流程。

测试数据

测试数据意味着很多非真实数据,那么针对测试数据,一般制定的是比较符合需求和代码要求的数据,所以对异常数据的处理或者很多非代码逻辑内的数据会有很多考虑不到的情况。

测试数据也意味着与真实用户库,真实用户的差距性,真实数据具有更完整、更严谨的逻辑、更复杂的情况,针对测试数据适用的代码对真实数据未必可行。

还有一个情况是很多时候程序员会忽略的,就是当进行一个业务整理或者代码迁移、数据迁移的时候,没有考虑到历史数据的各种情况,线上脏数据的可能情况,这种在很多时候在发布后暴露出来。

用户与机型

  • 用户主要代表的是两种影响:
    1 用户权限的特殊性,还有就是用户的操作与测试操作过程的差别性,很多时候是用户的操作不规范或者用户的疏忽导致某些逻辑无法进行
    2 用户数据的特殊性,当用户的数据量足够大时,数据具有多样性
  • 机型
    用户的机型包括分辨率、网络、设备系统与性能对整个产品的影响是很大,而我们测试时一般是公司现有机型的一些测试,对用户特有的机型没有针对测试,这部分问题一旦暴露,开发会因为没有对应的机型而导致没有马上的应对办法,而这部分问题又是加急的

测试流程本身规范性

测试从最开始的环节就不是特别严谨,会导致后续各种问题。
一个很严谨的测试需要定测试计划,测试任务分配,针对代码写单元测试,测试用例。单元测试之后有功能测试,性能测试,ui测试,容错测试等环节。整个测试过程中都需要写规范的测试报告,测试报告书等。进行完整的测试通过之后,需要针对测试环境各个问题的暴露和解决情况,问题是否修复和优化给出详尽的分析。
而其中测试用例的严谨和全面性是最大程度决定上线质量的,如果用户的某种行为或者某种情况是列在我们的测试用例中,那么我们肯定会在测试阶段解决对应的问题。所以测试用例要保证质量。

完整的测试用例包括的前提:
测试用户,具有的权限,具有的数据,测试的功能,某个功能的前置要求,功能的每个步骤的操作是如何的,中间的交互期望是什么,操作结果是什么。(另外也会包括客观环境,包括网络,机器性能,是否中间地址打开等)

预发布环境的验证

正是因为测试环境的不真实性,我们需要预发布环境来做更真实的抽样检测,甚至是预发布环境的全量验收。
有的人认为预发布环境没有必要做验证,或者与真实数据库有什么差别。但这种观点很错误。
首先,在线上的用户或者数据部分,我们没有办法进行功能验证,所以无法完全保证功能的正确性,但在预发布环境这些操作都是允许的。可以更加稳妥的确认功能的正确性。

与灰度发布的关系,其实预发布环境也可以当做灰度发布的一种,很多大型的产品,都会正式公布前,对一部分用户做发布新版本,也称为内测,与测试本身相比,有了更多的测试用户和测试过程,会对程序的功能性做更全面的检测。

发布评审 && 代码评审 && 关联活动

测试整个过程完成之后确定发布没有问题的时候,保险起见,建议进行一次发布评审,需要知会项目经理、技术架构负责人,相关后续运营的产品和运营,分析这个发布带来的影响,以及如何配合之后的工作。而技术架构师则要在这次迭代中开发完成以及测试完成之后对代码的整体的质量以及可维护性给出一些关键的点评,以及后续功能的设计可能,是否需要架构调整等。

线上问题的反馈纠正机制

如果大错已经铸成,我们上线的项目就是有很多问题的,那么针对功能性的很严重影响整个流程的。可以分严重程度进行分别的处理。简单的分类可以如下:
1 功能整个流程漏洞很大的,可以下线或者关掉这个功能的入口。把功能的开发进行重构开发,放到之后的迭代中。
2 功能基本可以,但是某个节点有问题的,而且功能很重要的,需要做紧急修复,调用最优势的开发资源进行纠正,这类问题不要无限制的延期。
3 优化:包括体验优化,性能优化,间隔性的功能bug。这一类要分门别类的,系统性的归类,安插到正常的迭代优化需求中。

而针对我们在做的工作中,优先级一般是:
线上bug>>功能开发 >>优化需求 >>重构>>规范

最后

以上很多环节的具体把握权限都在项目经理的权责范围内,希望相关项目经理或者说产品经理、技术经理把好项目质量关。不要让开发团队疲于奔命,一直在没有原则、没有意义的反复加班。

发布者

Robinson Zhang

热爱前端,热爱分享,坚持高频写作,从小白到大师只是时间问题。