支持
做完这些应为不太确定是不是完全正确,然后需要测试再全量回归一下,有时想想测试确实痛苦,这本来就是不存在的事情。及不重要又不紧急的事情,最后被推到了又紧张,又紧急的事情。关键是万一问题还要背锅,没出问题都是应该的。测试开发何苦折腾测试呢。 就这个事情,和代码重构真的不在一个维度上的,代码根本就没有重构, 重构什么了?那个 Bean 还是那个 Bean,只不过是编译的时候把 GET/SET 方法给自己生成了而已,对代码没有做任何形式的重构。
提高效率是好事,但是提高到代码重构工具,这肯定上不合适的,这肯定说不上重构,哪怕一点都说不上。
用@Data和用 IDE 直接生成 GET/SET 没大区别,就是看着烦了点,但是 Lombak 说不定还存在点坑,然后不只不觉的就引入了风险。
一切都是矛盾呀,一面说管控变更,一面一动手就用代码改代码了, 代码改代码风险并不会小。
业务体量还不够复杂,这个确实,不过呢也不算太简单,同时业务体量这个东西很有迷惑性,是指功能多?还是指用户量多。如果用户量多,其实呢不一定用例多。业务复杂,使用人少,也可能用例很多,所以这个光一句业务体量不够复杂本身就不够清晰.
公司内某业务回归几万条用例的问题,需要精准测试,但是呢,重复的多少?没人愿意去重新搞搞清楚的可能也是有的?
另外为什么要全量回归呢?不是拆分了微服务了吗,不是敏捷小步快走吗?那么如果还是动一下要几万个 Case,那么微服务的意义在哪里,敏捷的意义在哪里,是不是先反思一下领域拆分问题?
如果精准到几千条,那我想问下,如果直接通过优先级是 P1-P2 的过滤一下筛选,几万条能过滤到几千条吗?然后这个几万条用例,一条用例的定义是什么?是一个步骤还是一个场景?
个人觉得更全面的了解一下实际情况对我做决定很有帮助,所以多问几个问题。先谢过!
我觉得这些都没有问题,我只是考虑我自己实际的情况分析,同时想看看如果要做怎么做成本更低,
好多对上英文你就不惊讶了,比如造数工厂, data factory,就这么个事情。
何必搞这么复杂呢?这样不行吗? 数据驱动就在最外面驱动好了
import unittest
from ddt import ddt, data
type = [1,2]
@ddt
class MyTestCase(unittest.TestCase):
courseClassify_list = [] #最终为[('data3', 'data4'),('data3', 'data4')]的状态
@data(*type)
def test_A(self,data):
# 执行A测试用例并向courseClassify_list插入数据
self.courseClassify_list.append(('data3', 'data4')) #共2条用例,都会生成一份('data3', 'data4')
print(self.courseClassify_list) # 验证是否成功插入数据
for item in self.courseClassify_list:
print(item)
if __name__ == '__main__':
unittest.main()
我觉得权责要对等,谁背锅谁负责,我都是直接说,我背锅那以后都是我负责,你们都得配合我,看整不死你们。。。。。。。。。
不会出现响应时间和 TPS 同时变多的情况,因为这两个本身就有点互斥的意思。
这都需要有前提吧,如果是多节点,分布式呢?响应时间长一点,TPS 增加也做得到的吧,而且分布式,多节点的目的就是用网络传输上有额外小延时的损耗换取获取更大的 TPS. 所以响应时间和 TPS 是可以同时增长的,就是有前提。
会 Java 才算是会代码?这么说的人大部分我估计也不会代码,现在语言和语言直接的差别越来越小了,各种特性都在趋同,并且还有发展,这么语言和好的,可以加到另外的语言里面去的。 脚本语言 python,typescript 和 JAVA 区别越来越小了,会代码这个程度,最重要的我个人认为是熟练度。
这个做出来之后,其实数据检查上面其实不需要测试的。为什么:
那么为什么还需要测试呢?因为做这个工具平台也不太容易,另外呢,产品/开发一个个对字段其实也挺痛苦的,为什么不找另外一个人帮着对呢,反正不用自己出工资,有了这个平台还要自己输入,也没太多好处
回到具体问题,这种就看你主要目标: