物联网的出现给测试带来了很多有趣的挑战，让很多QA开始重新思考传统的测试流程。例如，我最近测试了一款产品，其中移动应用程序将与连接的机器进行会话。这两种设备的各种状态给测试场景的设计带来了极大的挑战。给大家介绍一个好用的物联网产品测试框架——物联网测试图，可以帮助我们管理物联网设备多种排列的复杂状态。物联网测试因素当我们测试一个简单的Web应用时，通常考虑的状态有：服务器宕机HTTP请求超时慢网速授权和鉴权错误在测试任何互联网应用时，都需要警惕这四种状态.对于移动应用来说，在移动环境下运行，需要额外注意几种情况：离线模式在线模式killactivity后台行为语言和地理位置我们来看“连接机器”带来的状态多样性，通常有：WiFiDisconnectedMachineWiFiConnectedMachineBusyMachineSleeping这意味着即使只有上面给定的一组状态，整个系统在任何时间点也可能有96(4x6x4)个状态。由于系统中的状态转换引入了额外的约束，因此不能将这些状态视为独立的实体。例如，状态从“离线”变为“在线”可能会触发一系列事件。这些因素只是冰山一角。随着对规范的更深入理解，将不同状态与逻辑场景结合起来将变得更加复杂。对于静态系统的可变数据集，可以利用现有的Web测试技术提取测试场景，如全对（一种开源的配对测试工具）、等价类划分、边界值分析等，这些技术通过对测试数据集进行优化消除逻辑。例如，全对技术将消除重复的数据对组合。然而，这些技术在为系统的可变状态设计测试场景时是不可靠的，陈旧的系统状态会使系统通信不畅。当然，这些技术仍然适用于物联网系统中的各个单元。因此，创建物联网测试地图是非常有必要的。你们都在地理课上看过地图。但是我这里说的地图是针对测试场景的，它列出了所有潜在的系统因素，在测试某个特性时可以从中提取必要的测试场景。乘积各系统的n个状态列在同一个可旋转环中，逻辑上相邻的状态在环中相邻。在测试复杂的集成时，非功能性需求(NFR)很容易被忽略，因此将它们单独列在一个环中。下图就是我所说的物联网测试地图：下面举例介绍地图的使用场景。本例只涉及移动设备和机器的交互，需要关注的环是设备、机器和网络。将移动设备和机器固定在WiFi连接状态，打开网环，可以得到以下场景：触发相应的业务错误信息——“程序错误，请稍后再试”响应超时可能有两种情况：重新发送相同的请求并显示“正在加载”图标，或者显示与上述类似的错误信息。非法请求会触发消息“请更新您的应用程序”保持移动设备的WiFi连接并使机器响铃：当机器处于离线模式时，应用程序应显示“请检查机器的网络连接”当机器处于离线状态时忙，弹出警告“机器正忙，无法完成请求”当机器处于睡眠状态或在另一个网络上时，它应该显示一条消息，如“找不到机器”然后，当机器调到正确的网络时，移动设备与机器之间的连接应恢复对于WiFi连接，转动移动设备响铃：当移动设备处于离线状态时，应弹出相应的消息或禁用操作按钮。当移动设备返回在线模式时，App应发送相应的请求以连接到机器。当移动设备的网络从WiFi切换到3G时，应该有什么样的行为？当用户试图连接到物联网设备时，他突然接到一个电话并将应用程序置于后台。这个时候他是不是还能收到完整的请求，还是需要从头开始发送请求？Android设备kill一个已经在后台运行了一段时间的应用，是否还会保存用户的活动屏幕状态？有本地化需求的应用程序必须在每个场景级别进行验证。这样就可以展开地图的多次旋转，生成多个Scenes。虽然有些场景可能不适合现在的特性，有些甚至和业务需求不相关，但是这张测试图还是很详细的。在实践层面，对于一个有多个QA测试同一个物联网产品的团队，该图可以作为手册供大家参考。该图以通俗易懂的方式呈现了工具、设备、场景和协议的排列，涵盖了测试场景设计的独特需求，是一种非常高效的合作方式。【本文为专栏作者“ThoughtWorks”原创稿件，微信公众号：Thinkworker，转载请联系原作者】点此查看该作者更多好文
