mirror of
https://github.com/NohamR/knowledge-kit.git
synced 2026-05-25 12:27:15 +00:00
54 lines
2.7 KiB
Markdown
54 lines
2.7 KiB
Markdown
# 如何写好测试
|
||
|
||
> 软件测试的功能非常重要，现在结合过往经验谈谈如何做软件测试
|
||
|
||
- 每个类具有什么属性、具有什么方法都是确定的，所以拿 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自动化 |