已有 1266 人访问
非辑 ID.12747
阅读(4)
博客(0)
非辑的阅读

[译文]软件可测试性的启发(下)
(接上文)可测试性分析导语认知可测试性·质量的先验知识。如果我们已经相当了解一个产品了,我们不需要太多测试。·容忍失败。所需的质量要求越低,或产品可以承担的风险越大,就越不需要测试。项目相关的可测性·变更控制。频繁和破坏性的变化导致重新测试,并且使我们现有的产品知识失效。谨慎的变更控制有助于产品在测试阶段的发展。·信息的可用性。我们得到所有所
331°/ 2015-12-28/3316 人阅读 / 1 人点赞 / 0 条评论

[译文]软件可测试性的启发(上)
产品的实际可测试性是指一个专门的测试员在给定的环境†中通过特定测试流程进行测试的容易程度。实际的可测试性取决于其他五个“可测试性”:项目相关可测试性、价值相关可测试性、主观可测试性、固有的可测试性以及认知可测试性(俗称“缺口风险”)。正如通常而言的质量一样,可测试性是一个可塑的、多维的宏观概念,并不能用任何具体的单位表达。但总体而言,我们能够通过定义与其相关的问题以及启发来提升产品可测试性。趣味可
335°/ 2015-12-10/3353 人阅读 / 1 人点赞 / 0 条评论

[译文]Motley声称:“自动化测试多多益善”(2)
Maven:这是团队太注重自动化的一个普遍问题。Motley:什么意思?自动化测试是一件好事。它让我们在没有定期人工干预的情况下重新运行测试。如果没有自动化测试,每次在做出改变的时候我们就破坏产品的其他方面的风险。Maven:别误会我,自动化可以很棒。单元测试是自动化测试和我们一直在讨论的每个软件开发人员必须做的事情的形式。你改变,你运行你的测试,也许为确保你没有破坏任何功能而让其他的团队测试。越
288°/ 2015-11-10/2880 人阅读 / 2 人点赞 / 0 条评论

[译文]Motley声称:"自动化测试多多益善"(1)
摘要:Motley:测试人员的工作是寻找缺陷,那么发现的缺陷数量就是其价值所在.所以测试的自动化总是多多益善的.Maven:别用测试人员报告的缺陷数量衡量他们的价值,应该更多的考虑测试团队质量保证的作用,而不仅是质量控制.由于测试基础建设薄弱,太多的时间用作故障排查测试,测试中的非最佳测试投入以及缺少从用户的角度出发看问题,过多的自动化测试可能成为问题.——————————————[背景:Motl
306°/ 2015-11-03/3061 人阅读 / 9 人点赞 / 0 条评论