在Scrum中GUI或API级别的自动化

Question

我是自动化工程师。我使用QTP实现自动化。我想知道几件事。

1. 在有2周工作的scrum项目中，如何在该时间框架内完成自动化(只讨论GUI级别)？
2. 类似地，如何完成自动化测试的API级别，特别是在单个sprint中？API级别测试究竟是什么？
3. 如何从API测试开始？我想QTP肯定不是这里的工具。

Answer 1

你不想“完成自动化”。相反，你和其他人一样有故事。您可能有严格的自动化故事，或者更好的是，自动化是用户故事的接受标准的一部分。

您是(或者应该是)团队的一部分，自动化是交付的一部分。你的工作不能脱离你的团队。你应该一起决定作为一个团队你能做些什么。

两周的sprint不应该意味着“我们可以在两周内编写代码”，而是“我们可以在两周内编写代码并进行测试”。如果你不能在两周内做到这一点，要么你需要更简单的故事，更好的团队成员，或者更长的冲刺。

至于API测试，选择合适的语言并开始编写调用API的代码。

Answer 2

1. 通过分解自动化任务，使它们能够在单个sprint中完成。
2. 见1。
3. 请定义API测试。如果您指的是多个代码单元(内部和/或外部)之间的测试交互，那么您可能会看到集成测试。

Answer 3

谷歌快速搜索显示，QTP是一个GUI机器人。这些工具是黑匣子测试工具，测试应用程序的编译后的二进制文件，模拟用户按下按钮，在某些字段中输入值，检查其他字段显示的结果等等。通常，您不需要知道原始程序是用哪种编程语言编写的。创建这样的测试通常只有在GUI部件达到一定程度的稳定性之后才有意义。

当谈到API级测试(而不是GUI机器人测试)时，我们讨论的是GUI逻辑的白盒测试，不是通过GUI元素本身，而是通过应用程序的一个API层，该层非常“在GUI下面”。这样的API层最容易通过应用“模型-视图-演示者”模式来创建。这种模式允许在推荐人-第一方法中进行测试，这使得很早地创建自动(单元)测试成为可能--当执行TDD时，比GUI逻辑本身的代码更早。这些测试通常是由编写演示程序的开发人员用与测试应用程序本身相同的语言编写的，您通常只需要一些类似于免费的xUnit测试工具，而不需要更多的测试工具。

根据我的经验，两种测试方法都可以测试不同的东西。但是，这两种方法也可以用来测试许多重叠的需求，以防我显然更喜欢API级别的测试(让我们说，我以前使用GUI机器人的经历有点令人失望，付出的努力太大，收益太少)。但你的里程会不一样。

关于Scrum:我从来没有这样做过，但我怀疑使用GUI机器人工具的测试最好是在每次sprint之后编写，而API级别的测试应该是sprint开发过程中的一部分。