# 写好测试，提升应用质量

> 软件测试的功能非常重要，现在结合过往经验谈谈如何做软件测试

- 每个类具有什么属性、具有什么方法都是确定的，所以拿 Objective-C 举例子，`.h` 中会有公有的属性以及方法，`.m` 中一般是私有属性和私有方法、公有方法。类的行为设计为方法，写代码之前我们一般需要做到心中有数，一个功能需要几个类、每个类的属性和方法分别是什么，需要暴露什么属性和接口。**UML图**  不是必须要画，但是需要胸有成竹。针对一个类在测试的时候 `.m` 文件中的私有方法没有办法在 Unit Test 类中访问，一般可以将需要测试的类增加分类。在分类的 `.h` 文件中将方法进行声明。在测试的 Uint Test 中引入分类头文件。下面举例子
  
```Objective-C
// Person.h

- (void)eat;

// Person.m

- (void)eat
{
    NSLog(@"eat");
}

- (vood)sleep
{
    NSLog(@"sleep");
}

// Person+UnitTestHelper.h

- (void)sleep;
```

另一种思路是没必要针对每个类的私有方法或者每个方法进行测试，因为等全部功能做完后针对每个类的接口测试，一般会覆盖据大多数的方法。等测试完看如果方法未被覆盖，则针对性的补充 Unit Test

目前，UI 测试（appium） 还是建议在核心逻辑且长时间没有改动的情况下去做，这样子每次发版本的时候可以当作核心逻辑回归了，目前来看价值是方便后续的迭代和维护上有一些便利性。其他的功能性测试还是走 BDD。

对于类、函数、方法的走 TDD，老老实实写 UT、走 UT 覆盖率的把控

> 目前，UITesting 还是建议在核心逻辑且长时间没有改动的情况下去做，这样子每次发版本的时候可以当作核心逻辑回归了，目前来看价值是方便后续的迭代和维护上有一些便利性。例如之前我们分享SDK升级微信和QQSDK，以便支持 universal link 功能，当时有了UITesing，基本上免去了测试人员介入。

> 如果是一些活动页和逻辑经常变动的，老老实实走测试黑盒...

> 我觉得一直有个误区，就是觉得自动测试是为了质量，其实质量都是附送的，测试先行是让开发更快更爽的

> appium 但是后来他自己也说 在iOS平台好像不是很好搞 能做的事情挺少的

> 投入产出比是不高 那你试试monkey test

> wwdc上这张图也很清楚，UI其实需要的占比很小的，还是要靠单测驱动

> 当时我找个UITest的bug都花了不少力气

> UTTest主要测逻辑的

> UITest可以测你页面渲染的对不对、按钮点击是否有问题

不过 macaca appium 都可以做到iOS自动化



12318 * 0.09 + 4091 * 0.04 + 3216 * 0.0316 + 5099 * 0.0164 +5351 * 0.0579 + 3196 * 0.0475 + 6092 * 0.0123 + 4382 * 0.0652 + 3238 * 0.0633 + 5617 * 0.0642 + 3211 * 0.0492 + 6296 * 0.0437 + 7089 * 0.0921 + 5274 * 0.025