当然这些前提是公司已经有自己的UE规范,前端代码规范,数据规范,交互规范。
每个项目初期都会进行评审,且在此之前都会跟参会人员发送一个 市场需求文档(以下简称 MRD),前端开发(以下简称 FE)在拿到该文档后要对该文档里的内容进行审查,并把有疑惑的地方标记下来,以方便开发的时候询问并确认。
一般评审会是由 PM 发起,由 FE、UE、RD 参与,一般这个时候已经有UE的初稿,并会附加到 MRD 里以方便 FE 查看,FE 在评审会上一般需要确认以下:
这些部分应该是 UE 考虑的范畴,但如果真到 FE 这边了,自己必须得处理这些,不然线上的 bug 机率要高很多~
如果会上没有搞清楚的事情一定记下来,待会后单独找 PM 确认,一定保证在开发之前把所有的逻辑明确,这样才能提高效率。
一般情况下我习惯在开发之前把我所有明确的逻辑以图文的形式发给 PM 查看,比如有页面各个状态的描述、出现条件、UE 展现,以色块来区分的点击区域等。且这个邮件以后还有大用。
明确了需求,知道了逻辑,有了数据格式,开发就略爽了,只需要按照FE的规范,把功能写出来就 OK 了
但要注意的是,一定要考虑到之前的各个状态,比如截断,判断等
当自己的代码写完后首先要保证兼容性,这个就不多说了,其他就是逻辑测试,这里要说明的一点就是:RD给的测试数据格式大多都是一种,比如给的 5 条,但逻辑上又是超出 5 条才分页,如果按测试数据那么一辈子也测不到分页,乍办呢?
答:自己模拟数据~
我通常是为了测试不同的展现策略,自己要去模拟可展现这些页面状态的数据,我一般是在 url 中加 GET 参数完成,比如:
以上只是一些展现的模拟,不能说明什么~
注意的是,这里的模拟数据一定要加注释,且在上线前一定删除,并且这些测试代码通常放在逻辑处理前的某一块,要做到删除这一块对整体代码无影响、不被其他正式代码所依赖
当然可能还会涉及到一些别的测试,比如速度测试,压力测试,规范测试等,这些跟据所要求的流程走即可。
当这些自测都通过后,接下来的任务就比较轻松了,这时候不妨冲杯咖啡,然后静静的坐会,不要问我谁是静静~
这样的测试应该是QA来做,但问题是就我目前的接触QA是不管代码的,数据满足不了这些条件是不展现状态的,当然这跟所在公司有关吧。
代码方面的可以写单元测试完成,但这些展现类状态就目前我的认知范围还得靠这种方式解决,如果你能更好的解决这一环节,一定要与我联系,我请你吃饭~
上面曾说过我会在逻辑确认后发一个逻辑确认的邮件,这时候邮件的作用就来了。因为每一个逻辑条件可能就是一种UE展现,这时候我会对那封邮件进行编辑,所把我自测里的测试 url 附加上,这时候这个编辑后的邮件就成了展现确认,里面包括了:逻辑的描述和展现条件、最新确认后的UE界面截图、该逻辑完成后的 url,当然如果是手机端项目,我通常会再加上一个二维码(可以直接扫打开目标页面)。当然里面也会有一些没有图的逻辑。
把展现确认的邮件发给 PM、UE,我会跟进他们的反馈,是否有逻辑 bug,是否有不是UE期望的效果。收到反馈后,评测这个反馈的问题,如果可以 fix,直接 fix 并标记,如果为新需求,则评估排期并加以说明。整体解决完反馈后回复邮件,重复整个过程直到 PM,UE 都说 OK 为止。
通常只要 评审会 考虑的 周全,这一步是相当快的。
整理一下 PM&UE 在展现确认里的反馈,现结合展现确认的邮件,发送给 QA 妹妹(通常是妹妹吧),并附带上 PM 的 MRD,这里就满足 QA 需要的:
当然QA测试的可能就多了,什么多平台,多浏览器,夜间模式,各种网络适配,各种链接测试,展现日志测试,点击日志测试,报错日志,noscript,nocookie 等
其实我只是想 静静 的让 QA 妹子测试。
这里 FE 做的其实只是 fix bug了,直到 QA 说 OK 为止。
上线就走上线流程即可,完成后一定要在线上回归一下自己的页面。
这时候再静静吧,因为新的一轮战斗即将发起~ 兄弟们,冲啊~
其实还是要多跟工作中的前辈沟通,多跟项目组的同学沟通,这里也说下,我们的 PM 真的很棒~
由于涉及到了内部数据,我就不插图了,当然如果你在流程上有什么问题,或者有什么见解,我想说:大神,请联系我~

