管项目,管人,管进度
楼主自己的记录吗,没有学习点
既然是需要向上反馈,那么就是说明你看出了团队中的问题:
1、需要站在客观的角度,讲述一个事实,同时说清楚事实依据;
2、既然发现问题,那么就需要给出你认为可行的解决方案,供上面参考;
3、叙述事实,可以减少出现对应的人员名字(领导能通过你的事实,推断问题出在谁身上,不需要你指明)
首先要处理研发的开发分支管理。再就是结合公司测试的情况,决定的使用哪种方式。
题外话,站在公司的角度,为了省钱,会选择只有一个测试环境的方式。
羡慕
检查下你代码里面生成报告的路径,是不是你 Jenkins 对应的路径
数据接入的不同,可以去了解每种网络协议的内容。
m
null 的情况,主要是代码没判断对象是否为空,考验研发代码习惯和对象处理的严谨程度,如果是接口测试,可以针对入参必填和非必填进行测试,能覆盖一部分情况
之前有了解,这里需要拥有小程序开发者权限才可以写脚本之类
工作地没说啊
蹲着,抽空深入学习下
感谢分享
mark,接口测试 + 数据驱动,在加好的模式
研发评估工期,主要考虑功能难易程度和每个人研发人员的个人能力,测试其实也可以相似,从功能的复杂度、测试方法、个人能力等方面评估
如果真的难以接受,还是跑吧,不要委屈自己
大佬,學習了
大牛就是大牛,看一遍还消化不了
竟然中奖了,感谢;同时感谢十年的付出,期待下一个十年
可惜已不是新人
已读,虽然无法报名,但希望活动顺利,期待大会视频、ppt 资源
具体要看你们提测的方式:如果是全部完成提测,那就按提测标准,符合就正常测试,不符合就打回继续开发;如果是边开发边提测,那只能根据每个研发的能力,分开评估每个人开发功能需要测试和修改 bug 的时间;
这个测试时间不管怎么评估,在领导面前都是很难满意的。你只能给出一个比较合理,领导相对能接受的时间范围;
占楼,学习
大佬这是准备出书啊
想看看大家是怎么做的