点击『小生知道』关注我 ,这里有宝贝
上一篇
后端产品之路(四) - 降低耦合性、组件化
说完如何画原型,接下来其实是评审的事,不过评审也是为了调整业务、流程、原型,所以就不赘述了。
原型之后就是产品的开发工作了,开发工作开始了,测试工作其实也开始了。
要测试干嘛?
1、检验功能是否按需开发完成
2、功能是否存在使业务无法流转的bug
3、功能是否影响了其他业务
···
测试是个严谨而又措手不及的过程,你永远都不知道什么地方会出现bug,所以只能尽量将产品的边界想全一点,当然,虽然你永远都想不全。
开发测试:
为什么说开发工作开始了,测试工作也开始了?(我不是想说单元测试)
程序员是按需求开发的,但是在开发过程中,程序员会发现,这个需求无法实现,或者无法按需求完全实现,比如我今天遇到的一个问题:一个积分列表展示功能,由于早期的积分接口不提供某样数据,导致积分列表这个版本之前的数据是没有的,之后才会有。
这个就算没有按需实现,那怎么办呢?
『改需求啊。』
数据库还不知道有多少数据呢,不能把以前的数据都处理一遍的,所以只能以当前版本为界,之后的数据按产品设计的来,之前的就不处理。
新旧版本兼容是一个问题,实现难度也是一个问题。
除了需求实现的问题,开发自己也会跑单元测试,手工测试,这两个他们一般不会跟谁沟通,主要是保证交付给测试的功能是跑的通的,至于边界,就留给『测试员』去探索了。
测试员驾到:
大多数在互联网公司的,应该都知道测试用例吧。
测试用例是用来指导测试员测试用的,一般测试用例上写的都是正确的事。
测试会根据用例,先把正确的流程跑一边,然后把正确的事情拓展开再跑一遍。
比如:一个『输入框』,产品要求该『输入框』仅字母+数字输入,那么测试就会去尝试输入符号、汉字、表情等等规则之外的字符。另外像这种『输入框』还需要对输入『字符上限』做校验。
还有一些如:『文件大小限制』、『图片格式』、『是否必填』、『是否有预设』等等要求。
虽然测试用例是测试写的,但是产品在写文档的时候也要充分而详细把产品的边界给写出来,越清晰,测试员测试的也更详细和彻底,就能尽量多的避免上线后遇到bug。
产品验收、设计师也来吧:
一般测试跑完之后,还需要转交给产品、设计师进行验收测试。
产品测试:
我进行验收的时候,会先按正常的流程进行一次测试,然后试图做够多的边界测试。
明明测试员已经跑过了,为什么还需要产品测试一次?
一、防止产品甩锅,上线后出bug了,第一个就质问产品,如果产品没测试,那就是产品的锅;如果产品测试了,那还是产品的锅。除非是产品的性能bug或者开发bug。
二、虽然有测试用例,但是信息的传递一定是有损失的,功能到底要做成怎样,产品心里应该有点逼数,所以让他测一下还是很有必要的。
三、有的需求可能变更了,但是信息没同步,查遗捡漏。
设计师验收:
要说功能跟开发矛盾最大的是谁?首当其冲的是产品经理,其次就是设计师。
我自己有几个群,群里经常听到设计师吐槽开发说这个实现不了,那个实现不了。然后就来群里问别人,是不是开发忽悠他们。.- -(是)
一般设计师主要还是验收设计稿的还原度:字体对不对、间距够不够、图片比例错了咩、动效实现没、流程有咩有问题等等。
PS:互联网公司就没有统一战线的两个岗位吗?
总结
一般测试就是上述的流程,大一点的公司可能会还会有内测、公测、bate版本等等,不过,哪些问题都不大, 本质上跟正式发布差不多。
测试是个复杂繁琐的工作,我一度没有耐心做这个事,但是,测试多了之后慢慢开始,我写文档、画原型的时候,想的东西也越来越全面了。
所以后来我还是会尽量让自己参与到测试工作中去,而且,你自己的产品,哪里有问题,哪里是怎么操作的,你心里没点逼数怎么行。
另外,测试过程中,希望大家的目标都是为了『让需求更正确』。
领取专属 10元无门槛券
私享最新 技术干货