• 关于因果图法 at March 02, 2021

    测试用例只是把需求抄一遍的测试人员,是合格的测试吗?
    测试用例的本质是什么?设计测试用例的目的是什么?如果仅是简单扩充下需求,那为什么前期不把需求写完善, 测试直接对照着去做呢?
    这是个问题....

  • 一般在大版本更新时才会出具测试报告(比如从 V1.0 升级到 V2.0 这种必须要有对应的测试报告,从 V1.0.0 升级到 V1.1.0,这种最好也要提供测试报告,像 V1.0.0 升级到 V1.0.1 就没必要了)。
    测试报告应该是在发版前邮件发送项目经理,产品经理,开发经理及相关责任人,告知测试结果及已知风险,证明版本内容已经过测试验证,符合发布上线标准。说句难听点的,就是发布上线后出现问题,测试要担负一定责任。
    测试发版后有必要的话,需要做测试分析总结,针对当前版本的测试密度、缺陷密度做数据统计,查漏补缺,为后续测试工作做提升改善。

  • 我还想从无锡去南京...

  • 有效等价类、无效等价类,均选取一组对应数据不就可以了吗?
    每个等价类输入,只要一个输入测试正确,其他输入也一定会测试通过,这样是否存在冗余的测试用例呢?

  • 上联:“想要工资要的好,测试平台搞一搞”
    下联:“光有平台没业务,领导劝你找后路”

  • 自动化测试成神之路 at July 29, 2020

    测试思想是测试的竞争力,编程是辅助测试做的更深入。

  • 一篇文章中那么多群号加粗提示...

    建议放在文章末尾,没必要看技术文章插播广告🙏

  • 培训班既然存在就有其存在的价值,没必要讨论值不值。
    如果你觉得值,可以去报班学习;如果觉得费用贵,不值,可以选择不去报班学习。
    对于有能力,有想法,有自驱力的可以自学;对于基础弱的,没方向的,可以报班跟着节奏学,比自己盲目的学效率要高。
    所以说:值不值,主要看自己。

  • 他们不懂 “复古版” 是什么意思😂

  • 今年刚 30 整,也报了个技能提升班,如果通过这样的学习还是达不到技术上的提高,真的该考虑转行了...

  • 母亲节快乐 at May 09, 2020

    为人父母后才能真正懂父母,健在的时候就好好善待他们吧。

  • 1.第一个问题:如何写好测试用例?首先我觉得要理解透需求文档内容,知道被测产品大概是什么样子,看看是否有同类竞品参考;其次可以多和产品人员沟通,在需求理解过程有疑问的地方重点标识,明确被测点。写用例,依据需求文档,但不能纯粹的翻译需求文档,对被测点要能够举一反三,也就是正常、异常多种用例点,这样才能尽可能的覆盖需求;
    2.第二个问题:测试用例的目的是什么?在我看来主要有 3 个目的:一是自己梳理测试需求与被测点,执行过程能够循序渐进的开展工作,做到无遗漏;二是执行便捷,即使自己没时间执行,其他同事哪怕新来的同事,按照你的用例也能够按步骤、预期完成该项测试;三是留存测试依据,说句难听点的后期项目出现线上 bug 时追溯问题根源,对比用例设计情况是自己漏测,还是其他原因导致的一目了然;
    3.第三个问题:测试用例是什么?在我看来测试用例是测试过程的一个产出物,是指导测试执行的主要依据。测试用例设计质量高,能够尽可能的发现潜在问题,避免流向用户。
    以上纯属个人看法,欢迎补充。

  • 感觉这里堕落了 at April 02, 2020

    我也算老用户了,之前写过帖子,不过感觉没啥技术含量,再后来就潜水进来看看大佬们的精华帖,好久没更新输出了。

  • 2019,我 survive 的一年。 at January 10, 2020

    凤凰涅槃浴火重生,加油!

  • 两年都没有。。

  • 倒不是真站着开会,我们每天 5-10 钟的例会,主要围绕昨天已完成的任务、遇到哪些问题需要 PM 协助解决的,当天的主要工作计划。自己相关的介绍完,了解项目组内其他同事的任务进度,目的还是希望项目能够稳步推进,遇到问题及时沟通解决。

  • 浅谈游戏安全 (一) at January 09, 2020

    以前还会用用八门神器、烧饼修改器这些 “作弊器” 的,现在估计想用也用不起来了..

  • 相对而言比较权威、真实的数据了,支持!

  • 加油!总会好起来的!

  • 失业了,该做什么呢 at December 13, 2019

    年底了,机会不是很多,趁着失业期间恶补下,来年再战!

  • 现在还头疼如何给【后端开发】【Web 端开发】【App 端开发】编写自测标准与规范呢...
    今早被拉去开个会,让我牵头出三份文档,其实我觉得一份自测规范流程/标准就够了,但是觉得 “难产” ing...

  • 说说个人拙见:
    1.验收测试,肯定是由用户方来做验证。前期测试工作比较到位、测试场景覆盖全的话,一般不会担心用户验收会出现问题,因为能发现的问题在测试阶段都已经提交并得到修复了。如果验收测试过程,还发现明显的缺陷,那说明测试工作还是有疏漏(这也是难免的问题)。所以这时候可以要求产品/用户,提供 UAT 测试业务场景,在交付验收前,把他们比较关注的业务场景测一遍;
    2.测试对于项目上线有决策权,这个我理解测试对能否上线有一定的表决权,能否上线估计测试决定不了,至少在上线前我会把测试过程存在的潜在风险问题提出来,研发评估、产品是否接受,一致觉得没问题那就上线(最终决定是否上线还是老板,除非测试人员能力非常强,能够把控到位,不过身边没遇到过这样的 leader 或同事);
    3.关于测试报告问题,这个属于测试职责范围内的事情,测试相关的产出测试人员做好相应记录。

    能力强嘛就多做点,多承担点;能力有待提高,就多学点;技多不压身嘛。

  • 又一年过去了... 之前在公众号上已经填写提交了...

  • 算完这个你就不想加班了 at November 29, 2019

    面试时问加不加班?得到回复是,我们不强制加班,根据自己的任务完成度自行决定。入职工作一段时间发现,这任务量是逼着自己不得不加班,正常工作时间是铁定完不成的,恶性循环中。。。

  • 1.发布拜师公告处于 CD 中,发布公告后修改名字,待 CD 时间冷却后公告名字如何显示?
    2.解除师徒关系后是否存在 CD 时间?