一般他们会问我,我说投入多少就是多少,产出比?我不算他们就不会算
mark,学习下
安全保证在任何时候都是需要的,只是成本和技术能否支撑的问题,无关场景
保证质量、降低成本还不够吗,不要盲目的为了回答就忘记了实际要付出的,有些东西接过来就不是那么简单做和扔的。
多谢大佬
转岗吧
是的,主要是遇到个 jd 是做数据库内核测试,公司也有一款自研数据库,就想来找大佬们了解下内核测试的方法
多谢大佬
也在尽可能的由测试往外辐射,但是毕竟第一份文档,还是想先把一些说的清楚明白的写进入,然后慢慢更新辐射更多。后续的目标就是由测试流程带动整体软件周期流程,把软件生命周期每个节点都制定出具体规范
好的,大佬的建议很清晰,会认真参照,多谢
可能我背景解释说的不清晰。整理的一个目的不是为了开发自测,而是项目人员进行测试阶段的设计和执行工作。我也清楚开发做测试时的实际情况,但是为了降低项目对测试的依赖,只能用测试基础知识普及的方式来提高开发人员的测试意识,对文档的实际作用也有一定的向下预期。
文档更大的目标还是在测试流程的规范说明,为公司测试人员 (为 kpi) 提供一个具体依据,也是对自己的一次锻炼
应付类会议主要是给上面看的,陪听的不放飞也没啥事。评审类的如果还放飞的话,大多是内容与自己无关
多谢大佬
约束主要就想到了需求分析和开发转测时的标准要求,但是因公司研发环境问题又难以实际落地,后面考虑还是加入具体的节点流程要求。
大佬还有没有其他节点的约束分享
多谢大佬,也有考虑过分开,可是发现分开后流程可写,规范却难以脱离流程分开说明,所以现在基本是按照流程阶段划分节点,在流程说明的基础上添加各节点规范,在讲解流程内容的同时给予标准
主要做数据服务的,关注点在交付环节,所以不关注线上场景,此处也不做过多扩展。公司是类敏捷开发,半吊子的那种,考虑现实情况也不选择对其作出建议,只做测试范围及对接前后环节的分享
当外行掌握了你的岗位生死,你该如何抉择
测试目标是数据库本身或者说是数据库内核测试,不是做数据库校验测试
有测试的发下吧
看大佬说的就晕了,没接触过,溜了溜了
这个 bug 留给产品宣讲吧
还是等 m3 吧
不懂就问:分布式部署时脚本设置线程组或者说压力是预设值 * 压测机个数吗?
钱再多些好了
加油,今年确实太难了,这个期望也可以看看周边城市的 JD
打卡 28
你是不是使用方式上有差错啊,将多个查询接口都进行异步调用的话不就实现并发了吗,你没达到并发的场景是怎样的