day1 执行用例

故事1

今天的工作,是执行已写好的"回馈"模块用例

每个子模块的用例都有优先级之分

肯定要先进行通过性测试,验证正常流

因此,我优先执行各个子模块优先级最高的那条用例,进行通过性测试

然而,通过性测试,失败概率80%

我请教同事该怎么办

他的意思是,这样很正常,遇到阻碍,先测其他模块,正常流测试完,改完一轮bug,再进行测试

我认为开发的质量太差了,因为在测试正常流时,若遇到了很大的阻碍,那么后续很多用例都无法执行

故事2

策划、开发、测试都在一个群里

我今天测试过程中,遇到好几处和原型不一致的地方,这个需要和策划确认

策划也是没多说什么,只是让把设计相关的bug指派给他,功能相关的bug指给开发

那么我就照做了

后续原因等策划在bug系统中的回复

因为是小程序的开发,肯定是手机来使用

就列表的加载,开发质疑策划设计的合理性

进入列表页,默认加载20条数据,上拉加载更多,每次加载10条

开发说,因为标题图在200~500k,那么20条得加载4~10M

首次加载20条按照500k的网速,得8~20秒

所以,设计的不合理

多么精彩的反驳,有理有据

最终,策划的方案改成

默认加载10条,上拉加载更多,每次加载10条

于是我感受到了策划的不切合实际

他可能凭感觉设计的,而开发的考虑却出于实用性和用户体验

故事3

因为今天执行用例很不顺,通过性都受阻

我带着满腹牢骚的心情,恰巧看到了老徐发的一条分享

当你接到一个[质量非常烂、UI效果非常LOW]的提测版本时,

不太建议疯狂提bug

先测主流程,及明显的bug,然后让开发修复后,再测第二轮

bug提得多,并不代表你的能力,多数是提测质量太烂

线上无漏测,才是能力的体现

共勉