试试 pm.environment.set("password",JSON.parse(pm.request.body.raw).password),
另外调试可以用 console.log(JSON.parse(pm.request.body.raw).password) 自己先看看能不能获取
包含以下几大块:
1.制度——好的制度能减少矛盾,大家有力一起使
2.资源——没钱没人=想 peach,另外合理的人员结构也比较重要
3.技术——工具上的、平台的、个人的。
我现在听到 “简单” 就头疼。。。简单意味着你的工作是理所当然的。别人的预期和你的预期相差甚远,做完之后可能存在较大的心理落差。而且测试从来都不会仅仅只考虑功能,从质量特性上看,功能、性能、易用性、可靠性、安全、可维护、兼容性等都要考虑。
【假设】微信支持余额支付时,不足的部分可以信用卡补充一起支付,但针对使用余额支付的部分给予 3% 的优惠(直接用于本次支付中)
单就这一句话的业务来分析,就有相当多的场景维度要考虑:
以上只是我想的一部分,实际上涉及支付的,业务安全和技术安全应该都是重点要考虑的,如果没有预设的背景,发散性的思考,上述维度多条件组合再加上边界值分析,产生的用例可真就多了去了。。。
如果不和年终考核挂钩,建议写成给自己看的总结。
如果要和考核挂钩,罗列数据,然后分析这些数据。
十年了。每天都在想如果发生了战争,我要怎么活下去。
这年头环游世界有风险呀
很有同感。测试做的越久,越无奈。
我司每当行业动荡或者结构调整,“开发优先” 是必然被提出来的。特别是疫情这两年,开发人数没怎么变,测试已经立省 50% 了
测试的价值在于被测对象的沉没成本。
测试的能力体现也是在被测对象的 NB 程度,甚至可以说是平台能力的体现。NB 的多是团队和平台。
当然,把别人吹的 NB 实现了,你就是有能力的人。
做这个的目的是啥?如果是你的 KPI,将就做呗,管他用不用的起来呢
工业 App 理论上应该更重视测试,只是管理人员不重视吧。。。
兄弟,每次你名字我都看成花泽香菜。。。
死道友不要死贫道,人之常情,特别是大龄团队,背锅=影响收入=可能失业=一家人没饭吃,非常焦虑。但是如果开发和产品的工作靠 bug 来导向,那肯定是团队出了问题,考核和指标的设置也可能已经变质,一个团队共同利益都没,就是外包的个体,确实谈不上共建,不内卷已经不错了。
长短连接只是三次握手的区别吧,排除网络因素,一般两个都行。
另外 conn reset 要保证客户端和服务端统一的连接配置(特别是 Nginx 这种默认客户端长链接,对服务器短连接的)。
门门通 + 一门精 + 适应变化。
开发:你行你上
测试:爬开老子来
这种程度就行。
质量是共建的,不是测出来的。出了线上问题,大概率团队本身也有或多或少的问题,盲目归结于某个人的原因,要么缺乏对质量的认识,要么就是管理水平低劣。对质量毫无作用,下次还会再犯。
当然,该反思还是要反思。
测试为什么没测到?——这是质量把关者应该考虑的问题,不逃避。
开发为什么犯这么低级的错?——这是生产者也要考虑的问题,不忽略。
只问测试不问开发,或者只问开发不问测试,都是有问题的。
当团队所有人都重视质量的时候,质量才会越来越好。(任何一个人不重视,他的质量就是团队质量的上限)
合理,可以根据这个设置准入标准。
max_area =a_area + b_area< (a_area + b_area) * 2 也相交?
另外都给了左下右上的坐标,还平行于坐标轴,直接判断两个左下和另外两个右上的关系不就行了。
没做过,不过再多的场景,等价类、分类树一分,就化无限为有限了。
PC 端如果没有针对性的需求,我一般不管分辨率。
如果经常出错,尽量还是花大力气整理一下规则。梳理好了进行自动化。
换个思路看,其实也算配置规则的测试没考虑完全。
这不是兼容性测试的一个环节吗?
java8 一行就行了
System.out.println(
LocalDate.now().equals(LocalDate.now().with(TemporalAdjusters.lastDayOfMonth()))
?"最后一天":"不是最后一天");