测试之家
  • 社区
  • 问答
  • 招聘
  • 社区学堂新
  • 开源项目
  • 活动
  • Wiki
  • 注册
  • 登录
高级会员
Ouroboros (Ouroboros)
第 48696 位会员 / 2019-11-21
11 篇帖子 • 1032 条回帖
26 关注者
1 正在关注
1 收藏
GitHub Public Repos
  • ED6-Steam-CN 156

    Steam 版空之轨迹 汉化+语音

  • Falcom 63

    「十三工房」

  • EDDecompiler 12

  • lldb 10

    Prebuilt binaries for Windows

  • theos_include 6

  • PyLibs 4

  • Ouroboros.github.io 4

    「十三工房」

  • Clutch 3

    ImageLoaderMachO::instantiateFromFile

  • theos 3

    theos For Windows 10

  • hackmap-rs 1

    Median XL 2.10

More on GitHub
  • 個人信息
  • 個人專欄
  • 帖子
  • 回帖
  • 收藏
  • 正在關注
  • 關注者
  • 接口的排列组合测试 at 2021年10月09日

    软件测试是咋有限资源约束下,如何去尽可能发现缺陷的技术和管理活动,理想的结果是实现测试代价和测试质量的最佳平衡。测个分数相加,竟然要进行穷举测试,我个人认为测试策略就是有问题的。

    这么搞的人,要么是外行的要求,要么就是闲的。

  • 想了解一下回归测试单里面的测试用例是怎么挑选的啊 at 2021年10月08日
    1. 自动化的全跑
    2. 没有自动化的,可以基于风险来做回归测试策略。根据业务的社会风险、商业风险、系统风险几个维度,分析风险发生可能性和损失高的用例(部分 SB 公司请根据自身风险承受度来做回归)。先做回归,再做自动化测试覆盖。
    3. 根据经验查漏补缺
  • 在需求混乱的产品团队中测试人员如何去做好测试需求分析,推进左移工作? at 2021年09月28日

    我已经成功打入产品团队,成为了他们的顾问。

  • 在 UI 界面上,当订单为某个状态时是不允许修改或删除的 (删除按钮变为禁用状态),但直接通过接口传参的话可以进行删除或修改,这种算是接口 bug 么 at 2021年09月28日

    安全漏洞:越权修改

  • 统一测试用例的写法,公司目前有两种意见,投票结果差不多,大家能补充下这两种的优缺点吗 at 2021年09月14日

    上世纪大厂是这么写的吧。。。这玩意儿我们这儿培养测试新员工才这么写。

  • 统一测试用例的写法,公司目前有两种意见,投票结果差不多,大家能补充下这两种的优缺点吗 at 2021年09月14日

    excel 不好维护。就 xmind 挺好。excel 可以移植过去的。

    “人员变动,不方便后续人员测试。”——这算哪门子缺点。非要为这个理由花一倍多的时间写一大堆废话吗?

  • 目前小公司 11K 测试负责人,跳槽至 14K 的的中型公司当螺丝钉,公司加到 13K 留我 at 2021年09月14日

    提了就走,别犹豫,犹豫你就会败北

  • 基于场景得接口自动化有意义吗? at 2021年09月13日

    自动化测试只是一个手段,要不要测由你自己决定。

  • 昨晚虾皮一面面试官出的一道题:利用随机生成(0,1)方法随机生成 0~1000 的数 at 2021年09月10日

    随机 9 位(512)+ 随机 8 位(256)+ 随机 7 位(128)+ 随机 6 位(64)+ 随机 5 位(32)+ 随机 3 位(8)=1000?
    不知道随机数加随机数算不算随机数

  • 公司的质量平台要取名啦,大家有没有好的建议 at 2021年09月10日

    断龙石

  • 昨晚虾皮一面面试官出的一道题:利用随机生成(0,1)方法随机生成 0~1000 的数 at 2021年09月10日

    Math.ceil(random.nextDouble()*1000) 就行了吧。。。
    取 0-1 之间的小数,乘 1000 后向上取整。

  • 貌似软件测试报告越来越不重要了? at 2021年09月08日

    对好的团队,在背锅方面,测试报告确实没那么重要了,因为所有的总结、数据都分解到了研发的各个环节,避免背锅也没必要非要用测试报告。

    但是作为普遍意义上的准出标准,测试报告还是很重要的,不过形式更灵活,轻便,重点突出,根据团队关注点写上对应内容,体现测试对质量评测的专业性。

    对一些互相甩锅的团队,有没有测试报告,其实没多大区别,欲加之罪,何患无辞?

  • 考证书太难了 at 2021年09月08日

    不撸靠刷题应该也行,反正翻过去翻过来就那些花样。。。考试大纲里计算机硬件、操作系统、数据库、中间件、计算机网络、编程啥的,应该是软件设计师考的差不多

  • 接口测试、自动化有必要去数据库捞数据校验么 at 2021年09月08日

    主要看测试需求和查询接口的逻辑。
    如果查询接口有特别的逻辑,调用查询接口满足不了测试需要,就得自己查。
    无脑把所有你要验证的数据查出来的查询接口,可以用来验证。

    自己去查的话应该是不信任查询结果或者担心查询接口业务逻辑变动影响自动化测试稳定性吧,当然也可能是顺手把存储一起测试了下。

  • 求数据结构 at 2021年09月07日

    理解不了题干。“5 个点”,“每个点有起点和终点”,是五个运动的元素,每个元素有一个起点和终点?

  • 考证书太难了 at 2021年09月07日

    新版教材还不错。我个人看下来,还是很有收获的,楼上说没有用的,一定是没看过。
    另外计算机基础的考试大纲基本没变,新版教材主要是针对测试类的题。

    当然收获最大的是系统学习的过程,而不是刷题考过。

  • 机器学习算法在常规测试中的实践 at 2021年09月07日

    可以详细介绍一下吗,比如什么是聚类算法,如何解决 200 多个类别分类,算法代码是怎么样的。
    你这篇文章总体下来我的感受就是一句话——我用了 Kmeans 做了个分类。

  • 自动化是否被过度神话了? at 2021年09月06日

    自动化测试本来就不是盲目的。。。一些项目本来就不适合自动化测试啊。不稳定的自动化测试用例实现比没有自动化更糟糕。

    另外自动化测试优缺点我按自己理解罗列了下,供参考。

    优点 缺点
    提高测试质量 产生开发成本
    提高测试效率,缩短测试工作时间 需要测试技术团队
    提高单位时间测试覆盖率 脚本维护成本高
    执行手工测试不易完成的测试任务(性能自动化测试) 无创造性
    更好的重现缺陷 引入更多的复杂性
    更好的利用资源 容易出现偏离原始的测试目标
    增进测试与开发合作伙伴关系 可能引入额外的错误
    更快的反馈软件质量 更依赖用例的质量
    提高测试系统稳定性和可靠性
  • 测试做算法题的意义是什么 at 2021年09月06日

    八股文啊。你可以不用,但是的你得会。

  • 软件测试怎么能提高研发的提测质量? at 2021年09月03日

    这是个长期的、持续的过程,很难立竿见影。
    观念不一致,没有质量共建的共识,绩效弄不好会起到反效果,搞得怨声载道,质量也没提高。

    根据我个人的经验,绩效这个东西,很多就是瞎拍脑袋弄的,如果不持续优化改进,短时间起反效果的居多,如果实在要搞,指标尽量是间接指标(比如恒捷提到的提测超时率、提测打回率、压缩时间占比、压缩后线上缺陷遗留增长情况等),同时尽量以激励为主,如果出现线上缺陷,开发测试共同担责(这一点是质量共建的基础)。不过还是那句话,大家认为质量不重要,随便怎么搞,都没多大效果的。

    另外,有时候确实是客观原因(实力不够、环境影响、没资源、人员流动)导致的,进度目标设置的时候,是不是合理呢?

  • 用 python 发送 requests 请求,带有证书 和密码的,但是响应报错 (Caused by SSLError(SSLError(398, '[SSL: CA_MD_TOO_WEAK] ca md too weak (_ssl.c:4024)') at 2021年09月02日

    没遇到过,
    可以参考下这个
    https://www.infopackets.com/news/10414/how-fix-openvpn-sslctxusecertificateca-md-too-weak

  • 福利来了,9 月 10 日前通过外推入口推荐简历到有赞测试开发岗,通过可拿 5500-12800 的推荐金。 at 2021年09月02日

    哈哈 给 tips 赞一个。

  • 软件测试怎么能提高研发的提测质量? at 2021年09月02日

    测试没话语权,不重视质量的团队就这样。解决这个需要从上到下的共识和制度的支持。

    以下做法供参考:

    1. 设置准入标准,未达标不进行测试。——这个常年因为产品进度压力妥协
    2. 尽早介入,每个环节介入——这个可能因为任务堆积被迫放弃,形成恶性循环
    3. 测试驱动开发,结对编程——没基础和一些基本条件不建议搞
    4. 要求开发自测——这个需要研发支持
    5. 尽可能小的分解任务,每个研发周期控制在 1-2 周。——这个还是可以做的,解决研发周期过长的问题

    至于压测试时间,一方面可以从自身效率解决问题(工具等,没资源不建议大规模做自动化测试),一方面可以把计划做好,提测结点约定好,压了多少时间,每次回顾会做到有据可查,时间成本很影响质量的。

  • 简历太糟糕找不到工作!!!!!! at 2021年09月02日

    可以照着用人单位的需求来写

  • 什么是站在技术角度保证产品的可测性?? at 2021年09月02日

    可以参考https://blog.csdn.net/vincetest/article/details/1466402?spm=1001.2014.3001.5501
    讲得很清楚了。

  • 上一页
  • 1
  • 2
  • 3
  • …
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • …
  • 39
  • 40
  • 41
  • 下一页
  • 关于 / 活跃用户 / 中国移动互联网测试技术大会 / 反馈 / Github / API / 帮助推广
    TesterHome社区,测试之家,由众多测试工程师组织和维护的技术社区,致力于帮助新人成长,提高测试地位,推进质量发展。Inspired by RubyChina
    友情链接 WeTest腾讯质量开放平台 / InfoQ / 掘金 / SegmentFault / 测试窝 / 百度测试吧 / IT大咖说
    简体中文 / 正體中文 / English

    ©testerhome.com 测试之家   渝ICP备2022001292号
      渝公网安备 50022202000435号    版权所有 © 重庆年云聚力信息技术有限公司