首页
学习
活动
专区
圈层
工具
发布
社区首页 >问答首页 >敏捷手册测试:对于无法自动化的测试?

敏捷手册测试:对于无法自动化的测试?
EN

Stack Exchange QA用户
提问于 2015-07-13 16:13:33
回答 4查看 295关注 0票数 2

因此,似乎并非所有的测试都可以自动化,对于小型团队来说,创建或“自动化”手动测试的工作在某些情况下可能比它更值得。

然后呢?我试图脱离旧的“基于步骤:预期结果”的测试计划,这些测试计划是非常具体的,而且当需求change....so这样做的时候。因此,我研究了基于会话的/探索性测试。

这似乎是正确的方法吗?对于一个没有人力来自动化一切的小型团队来说,还有什么更适合敏捷的吗?

还是旧的方式更好?如果您试图寻找完整的测试范围,那么自动化测试与手动类型的探索性测试之间似乎存在差距(Which...maybe I错了,但感觉就像烟雾测试,但您并没有具体的测试“计划”)。

EN

回答 4

Stack Exchange QA用户

回答已采纳

发布于 2015-07-14 02:40:30

如果您试图寻找完整的测试范围,那么自动化测试与手动类型的探索性测试之间似乎存在差距(Which...maybe I错了,但感觉就像烟雾测试,但您并没有具体的测试“计划”)。

好的,从这个描述中,我认为问题可能是你把探索性测试的定义限制在完全自由的计划外探索。(我可能错了,这正是我在上面读到的)。

大多数坐下来参加SBTM会议的人都会计划他们的覆盖范围--不是在重量级的文档中,而是在试验宪章中。这可以让您更好地了解您所涵盖的内容,而且,由于在会话结束时您还添加了您已经意识到需要的新的章程,因此您可以灵活地结合新发现的或不断变化的需求。

下面是一个宪章的例子(来自这个博客严格的探索性测试):

“使用发布特性的各种方法来查找有效的发布请求未成功完成或用户没有收到任何有关发布功能代表他们采取的操作的反馈的实例。”

为了进一步阅读,我推荐伊丽莎白亨德里克森氏的好书,“探索它!”。对于敏捷团队来说,这是一个非常合适的选择(考虑到作者,这并不奇怪)。

如果时间是问题,那么我还建议,它可以帮助打破自动/手动区分,而不是考虑“我们想保持的测试”和“我们只需要运行一次的测试”。编写一次性脚本可以非常快,这些脚本可以自动完成您想要做的部分工作,但随后手动完成其余的工作--例如,捕获结果,您可以稍后评估自己,或者反复完成一组常见的步骤,直到您想要开始进行更改。(这听起来很明显,但很多团队没有想到这样做)。

票数 3
EN

Stack Exchange QA用户

发布于 2015-11-07 13:00:27

在敏捷QA中,我的重点是测试象限

我的重点是我的开发人员在Q1方面做得很好

我致力于为Q2用selenium和capybara编写良好的自动UI测试。

探索性测试是必不可少的,并在Q3中得到了体现。

Q4中的性能和负载

对于探索性测试(Q3),我将在这里讨论那些“很难涵盖”的内容。“不值得自动化”、“视觉”、“所涉及的判断”、“领域知识需要”的探索性测试形式。

象限帮助我跟踪测试中需要考虑的所有相关领域。

我还要请您参考https://en.wikipedia.org/wiki/Exploratory_测试,它包括

为了进一步解释,可以对自由式探索性测试与其对立面脚本测试进行比较。在后一种活动中,测试用例是预先设计的。这包括各个步骤和预期结果。这些测试稍后由测试人员执行,该测试人员将实际结果与预期结果进行比较。在执行探索性测试时,期望是开放的。有些结果是可以预测和预期的,而另一些则不然。测试人员配置、操作、观察和评估产品及其行为,批判性地调查结果,并报告可能是错误(这威胁到产品对某人的价值)或问题(威胁测试工作的质量)的信息。

票数 2
EN

Stack Exchange QA用户

发布于 2015-07-13 17:14:22

我建议可能分配一些“免费游戏”的时间,最少的参与者人数,特定级别的玩家或经验水平,以及一些目标和/或故事点,从核心功能和最近的几个冲刺试图在这段时间内实现。

随后可提供有条理的反馈,包括:

  • 核心要点能否在时限内实现?
  • 最近的故事能实现吗?
  • 接口可用性
  • 命名、提示等的准确性和适用性
  • 反应性

还有一些不那么有条理的:

  • 注意到的问题
  • 一般印象
  • 建议的改进
  • 评论

这之后可能会有一个“你能打破它”的会议,问题是你能-怎么做?

通常,你看起来至少有一个经验丰富的用户,一个缺乏经验但技术意识清楚的用户--可能是另一个团队的成员或一个十几岁的人,一个完全没有经验的用户,如果通常不提供培训的话--考虑一名文职或非技术管理人员的成员和一个典型的客户终端用户。

您可以考虑允许匿名反馈,但如果允许匿名反馈,则用户应该指出经验和背景的水平,这将使用户在短期内减少匿名,但允许对结果进行加权,并对可用性给予客户代表的反馈很高的权重。

版本控制您的结果/反馈与引用作为您的源代码版本信息。

此外,考虑使用屏幕记录器和可能的摄像机作为补充信息,第一种情况是,如果在12,42上单击像素会导致应用程序崩溃或做一些奇怪的事情,那么您就可以重现这个问题。第二种方法将让您看到用户在知道下一步该做什么时遇到了问题,即使他们说他们没有问题。

最重要的计划,结构,确保你可以复制苹果和苹果,而不是芒果。

票数 1
EN
页面原文内容由Stack Exchange QA提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://sqa.stackexchange.com/questions/13783

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档