wilcoxons配对测试_战争游戏，配对测试和其他有趣的Bug发现方式-CSDN博客

wilcoxons配对测试

我已经研究了良好的测试对于项目，产品和组织的健康状况有多么重要。好的测试要比在持续集成中运行自动化测试套件并强迫某人浏览功能测试脚本和检查清单要好得多。优秀的测试人员将花费时间探索该应用程序，以确保他们真正理解该应用程序，并确保该应用程序确实有意义，找到缺陷并戳戳它们以发现没人期望的问题，从而为团队提供有价值的信息和反馈。有什么比一个好的测试员更好？两个优秀的测试人员一起工作…

配对测试–两个头脑比一个头脑好

配对测试是一种探索性测试方法，其中，两个测试人员共同处理各种场景，结合他们对应用程序的了解以及他们独特的技能和经验，以复制难以发现的错误或对系统的某些部分进行特别的深度测试。像成对编程一样，一个人开车，定义测试会话的目标，时间限制和启动方案，并在键盘上提供帮助。另一个人导航，观察，做笔记，建议，提出问题，仔细检查，挑战并造成麻烦。作为一对，他们可以通过误解和障碍互相帮助，在彼此的思想基础上提出新的变化和更多的方法来攻击应用程序，互相推动以发现更多问题，并且他们在一起时更有可能注意到一些小问题。对方可能认为不重要的不一致和错误。

如果将开发人员和测试人员组合在一起，则配对测试会特别有效–优秀的测试人员知道在哪里寻找问题以及如何破坏软件；优秀的开发人员可以利用他们对代码和设计的理解来建议替代方案和变体，并且他们可以共同帮助彼此识别不一致之处并识别出意外的行为。这不仅是查找bug的好方法，还是人们相互学习应用程序和测试的好方法。在我们的团队中，开发人员和测试人员会定期结对在一起，共同审查和测试难题，例如验证对复杂业务规则的更改或对分布式故障转移和恢复方案进行操作测试。

配对测试，尤其是将开发人员和测试人员配对在一起，是一种成熟的团队实践。您需要测试人员和开发人员，他们有信心和自在地一起工作，彼此信任和互相尊重，了解探索性测试的价值和目的，并且都愿意花时间做好工作。

战争游戏和团队测试

如果两个脑袋比一个脑袋好，那么四个脑袋，八个脑袋，十个脑袋呢？通过运行《战争游戏》，您可以得到更多的观点并创造更多的学习机会：团队测试会议将一群人聚集在一起，并尝试尽可能地接近现实生活条件。在团队测试中，一个人定义了目标，角色，时间限制和主要方案。多重人最终驱动，各扮演不同的角色或承担不同的角色，一些人试图疯狂的狗屎看看会发生什么，其他人被更有纪律，同时通过日志和代码别人的肩膀次区域资源中心或长相，因为人们发现问题。更多的人意味着更多的变化和更多的机会来创建意外的情况，更多的眼睛来寻找不一致和完成细节（“系统在执行此操作时是否应该这样做？”），以及更多的手可以尝试相同的步骤。同时测试并发问题。在最坏的情况下，您会遇到一群猴子在键盘上猛扑甚至发现一些错误。但是，一个运行良好的团队测试会议是一件很美好的事情，人们可以互相借鉴彼此的发现和想法，并以一种松散的结构即兴演奏的方式即兴演奏，就像爵士乐团一样。

对于在线游戏，社交网络，在线商店或在线交易等交互式系统而言，这种方式的测试非常有意义：这些应用程序支持具有不同配置和导航选项的不同类型用户，他们扮演着不同的角色，从而可能导致通过应用程序和许多不同的体验。

有这么多人在做很多事情，重要的是每个人（或至少一个人）要有纪律来跟踪自己在做什么，并在发现问题时做笔记。但是，即使人们保持了体面的笔记，有时您真正知道的只是有人发现了问题，但没有人知道他们当时到底在做什么，还是要重现该问题的步骤。就像在生产中发现问题一样，因此您需要使用类似的故障排除技术，更多地依赖日志和错误文件来帮助追溯步骤。

团队测试可以成组进行，有时甚至可以作为验收测试或与客户进行现场测试的一部分。但是回报却在不断减少：随着越来越多的人参与进来，很难使每个人都充满动力和专注，也很难理解和处理结果。我们曾经邀请整个团队参加团队测试会议，以尽可能多地关注问题，并为每个人提供一个机会来查看系统的整体运行情况（这在您仍在构建系统时非常重要，并且每个人都有专注于他们的作品）。

但是现在我们发现，只有四到六个人组成的团队真正了解该系统通常就足够了，胜过两个人，效率要比十个或一百个团队高得多。您需要足够的人员来创建和探索足够的选择，但需要的团队又很小，每个人仍然可以紧密合作并保持参与。

团队测试是另一种成熟的团队实践：您需要彼此信任，乐于合作，纪律严明，了解探索性测试并且喜欢发现错误的人。

来玩个游戏

在我们建立良好的自动化测试覆盖范围之前，我们在最初构建系统时就非常依赖War Games。这是一种效率低下但有效的方法，可以提高代码覆盖率，并在我们的客户发现之前发现良好的错误。

今天，我们仍然依靠战争游戏，但现在它的目的是寻找现实中的错误：在边缘进行测试，测试怪异的组合和工作流链问题，仔细寻找可用性和完成问题，强迫错误，查找设置和配置错误以及寻找计时错误和比赛以及锁定问题。

团队测试是发现细微（而不是细微）的错误并建立对我们的软件开发和测试实践的信心的最有用的方法之一。即使以其他方式进行测试和审查后，每个人都对通过这种方式发现的各种问题感到惊讶，有时甚至感到失望。这种测试不仅是要发现需要修复的错误，它还指出了我们需要改进的地方，并在发现太多（或任何可怕的）问题时发出警报。

这是因为战争游戏只有在开发的后期阶段才有意义，一旦您有足够的工作系统一起进行真实的系统测试，并且已经进行了基本的功能测试和回归。将多个人聚集在一起，为一组人设置测试系统，定义角色和场景，然后运行测试会话并查看结果是很昂贵的–您不想浪费每个人的时间去寻找基本的功能性错误或回归，应该早已发现。因此，无论您发现什么，都应该是（不太好）惊喜。

战争游戏也可能会筋疲力尽–如此好的探索性测试只有在每个人都参与其中，需要精力和决心的情况下才有效。这不是我们每周甚至每次迭代都要做的事情。当有人（开发人员，测试人员或经理）意识到我们已经更改了工作流程，体系结构或业务规则中的重要内容时，我们便会这样做。或决定是时候了，因为我们进行了足够的细微更改并通过足够的迭代进行了修复，或者由于我们最近在生产中看到了一些有趣的错误，因此有时间将关键场景作为一个小组一起运行，看看我们能找到什么。

战争游戏之所以能发挥作用，是因为它们是游戏：当您让聪明的人一起解决问题和发挥感觉时，激烈程度和竞争就会自然而然地形成。