我一开始接触测试工作的时候，测试的产品是一个地图导航产品。当时主要是执行别人写的测试用例，我测试的主要是HMI，地图显示以及导航提醒这一块的功能，刚开始执行用例的时候只知道按照用例执行，大部分用例都可以直接执行，但是有些用例看起来我就不知道怎么去执行，比如规划一条带有环岛的路线，然后导航，听取进环岛以及出环岛的语音提醒。规划一条线路很简单，可以我在办公室，如果模拟导航呢？完全是一头雾水，当时询问我的导师，我的导师教我使用了一种工具运行一个脚本就可以执行该用例，当时还质疑这种测试方法真的靠谱吗？测试结果可靠吗？当然在后面的实习中，慢慢也了解了测试的产品，也了解了那个工具的原理后，我渐渐的也接受了这一种测试的方法。

      其实很多时候，特别是新入门的测试，经常会遇到一些现实中难以遇到的测试用例，比如什么弱网环境，连续运行10小时，游戏装备的掉落概率等等，起色很多难以测试的场景主要原因是以下几点：

1、现实环境问题，现实中极少或者很难遇到的场景

2、人力问题，测试场景或许涉及上万人的测试场景

3、时间问题，时间这东西人还是很难去把握的

      是不是遇到一些不容易测试的场景，那么就放弃这些场景的测试呢？当然不是，既然测试时考虑到了这些场景，那么这些就有必要进行测试。那么我们需要做的当然就是解决这些问题，通过一些现有的工具或者开发人员的协助，其实没有什么测试场景是无法测试的，现在我来说说我的一些思路吧。如果我遇到这些难以测试的场景我会如何做。

步骤1、明确我要测试的对象

步骤2、将测试对象进行拆分

步骤3、针对拆分后的点逐个测试

       举个例子，如果遇到一个弱网环境的测试用例，那么我们就可以先来分析我们的测试对象。既然要测试弱网环境，比如是需要测试一些网络相关的请求，不可能连网络请求都没有就要我测试弱网环境。既然有网络请求，就可以明确我们需要测试的网络请求的API有哪些。如个需要测试的是APP弱网环境启动的用例，那么启动时会有哪些网络请求，这个是测试人员比如需要知道的，比如请求用户登录信息，一些初始化的信息等，有的网络请求API可能是独立功能的，有些可能是相关联的，那么就需要所有启动时的API请求都列出来，这样我们就可以吧这条测试用例细化成，针对每一个API超时或者丢包的测试。这么一样通过我们平时使用的抓包工具就可以实现该场景的测试了。

       之前我们测试时遇到这么一个功能：城市新闻tab的获取。如果定位到一些制定的城市，服务器会返回给我们那个城市的Tab，比如莫斯科。当然我们不可能真的去莫斯科测试。于是我们也先明确我的测试点，需要测试的点是 1、手机APP将位置坐标传给服务器，服务器返回给我城市Tab的数据。2、服务器返回Tab数据后客户端能正常显示。第一个点需要测试的是服务器的功能，第二个点需要测试的是客户端的功能。拆分后我们就可以逐个的测试，先测试第一个点的办法，可以修改API上传时的坐标参数，让服务器强制返回我固定的城市数据，测试第二的点的时候既可以使用第一个测试点的办法，当然也可以直接修改API返回的结果。

是不是，很多时候吧测试的功能点拆分之后，会找到很多合适的办法去执行测试，而不会一头雾水。当然有的时候也会遇到一些拆分后也难以实现的测试。

       以前测试一个项目的时候，有这么一个功能，小汽车TCU电源电压监控的一个功能，当电压过高时会会给用户提示。当时也把功能拆分、1电压监视，实时监视电压，2电压到12v时会发送消息给控制台 ，3控制台转发消息给用户。其中2点和3点都很容易去测试，比较模拟系统直接发消息给控制台，测试过很多遍。但是电压监视时调整电压到12v这个操作很危险。比如当时测试的TCU就是一块集成的板子，不是量产的，设备极少，电压过高很容易烧电路，真的如果调到12v板子烧了就浪费一个测试设备。那么这个时候如何测试呢？当时我们一起讨论一个方案，就是调整阈值，文档规定12v属于高电压，我们觉得危险，我们是否可以将12v分别换成8v 9v 10v去测试。这样一来测试的场景更全面了，甚至可以保护当前的测试设备。比较我们只需要测试电源系统实时监听电压的功能，并且高压时会发送消息。针对高压的定义也是电源系统的一个功能，这样测试也必然将测试点覆盖全了。

        其实很多测试的时候，都会遇到很多问题，并且就算我们吧我们的测试对象拆分到我们觉得无法再拆的时候，但是和开发人员吧功能逻辑再多整理整理之后，还会发现功能都是可以拆成很多小的测试点的。当然我们不是做单元测试，做的是集成测试。但是我们测试时有时也需要利用到一些单元测试的方法去帮助我们执行一些难以执行的测试。