2.9 KiB
写好测试，提升应用质量
软件测试的功能非常重要，现在结合过往经验谈谈如何做软件测试
- 每个类具有什么属性、具有什么方法都是确定的，所以拿 Objective-C 举例子，
.h中会有公有的属性以及方法，.m中一般是私有属性和私有方法、公有方法。类的行为设计为方法，写代码之前我们一般需要做到心中有数，一个功能需要几个类、每个类的属性和方法分别是什么，需要暴露什么属性和接口。UML图 不是必须要画，但是需要胸有成竹。针对一个类在测试的时候.m文件中的私有方法没有办法在 Unit Test 类中访问，一般可以将需要测试的类增加分类。在分类的.h文件中将方法进行声明。在测试的 Uint Test 中引入分类头文件。下面举例子
// 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