新手区 一些 API 测试、iOS 功能测试及团队问题，求各位指点，欢迎讨论。
主要负责移动端的 API 测试，保证 API 可以正常使用；同时参与到 iOS 的功能测试中。
每天在生产环境使用脚本测试 API 是否正常（测试环境也在用）。当然这不科学..基本属于监控的范畴了吧。
目前测试脚本的检查点就是 client 端使用的字段，判断这些字段是否是定义过的。
没有 API 文档，我负责编写移动端的 API 文档。开发从春节后才开始提供简单地 API 文档（之前是外包做的，我们自己的开发也是看代码去研究 API）。
iOS 的功能测试，简单地性能测试也都是我需要做的。
最后一点，也是最愁人，iOS 整体的代码质量很差，设计模式也很渣，但我不是很了解，对于开发也没有特别强的震慑力，只能通过 bug 来反映问题。设计模式上的问题清晰可见，但我没办法让开发去优化。
我的问题：
针对 iOS 这个很烂的代码，有什么好的办法改善吗？我们现在准备引入单元测试，最终的目标是 TDD。
针对 API 测试，以前基本没做过。API 的功能测试使用 postman 来执行，脚本使用 python 来编写。那么，脚本是否需要根据不同边界值等价类来设计呢。目前做的很初级，就是简单地 post/get 合法的请求，然后判断返回值的 xx 字段是否存在，是否是定义过的。
做的事情很多很广，每个方面都了解，也都能说出来点什么，但是都不是很深入。我既做测试也做 QA，还做一些项目管理和沟通协调，发展方向略显困惑。
关于单测
这个东西是见效慢的测试实践, 以你目前的实力不建议采用. 最好是先用其他的见效快的方法来保证质量. 比如接口测试, 覆盖率, 自动化, 专项测试, 业务分析, 监控等. 单测是我一直以来都讨厌的测试手段. 他更适合研发团队自己去推进. 而不是测试的人去推进.
关于 API 测试
用任何开发语言都可以. 尽可能的数据化. 或者采用关键词驱动的框架.
更高级一点, 可以做到从线上的数据录制反向生成测试用例.
能不能保证质量, 是要靠代码覆盖度的. 测试用例的多少不重要.
用例设计需要考虑好, 既要保证覆盖度, 又要保证业务贴合度.
发展方向
技术上, 我建议你先集中于一点. 这样可以作出有深度的事情来.
比如你可以先集中于接口测试 + 代码覆盖. 尽可能的往白盒测试方向发展.
技术实力说工作的基础. 能让你更好的理解产品和业务.
至于管理, 沟通这些都很有必要, 但是听到, 看到, 学到即可. 不要耗费太多的精力.
再过几年, 你会逐渐发现自己最适合做什么, 是技术, 管理,还是产品. 那个时候重新审视目前的一些, 你会领悟到新的理解. 太早的关注管理和产品, 反而会误入歧途.
年轻的时候看什么<人人都是产品经理>之类的这种书是没用的, 细节是魔鬼, 细节决定成败.细节是需要自己去踩雷才能深刻理解和体会的.
现在互联网的大佬, 比如张小龙, 雷军, 李彦宏 王小川和大淘宝的新任掌门人等, 都是技术和工程出生的. 以及国外的埃隆马斯克, google 的双侠, 乔布斯等. 他们才是一家公司的顶梁柱.
马云, 老罗, 陈年, 陈天桥这些人固然非常的辉煌, 但是成为他们是需要靠机遇的. 长远看, 具备更扎实技术和产品实力的人才更适应多变的环境, 他们才是未来的决定性力量.
.
API 测试基本没什么文档，或者文档维护工作不利。
如果代码很烂，就不要做单元测试了。
可以以集成测试，系统测试 + 验收测试为主。
时间有限的话，系统 + 验收测试吧。
API 的测试也要有等价类、边界值的思想在里面的。
如果是 SOA API 测试，建议先开始正向测试，优先保证传入正确的参数可以工作。
后续是负面测试，查看接口的容错性。
最后是异常测试。
未来可以发展成测试主管，测试经理。也可以发展成 PM/PMO，如果不想在技术上有所发展，也可以转产品。现在转产品的还是蛮多的。
总的一点，就是无论何种测试，测试用例的设计是很重要的，用例设计在任何阶段都一样，只是面对形式不一样，除了边界之类的，需要更多的关注业务，逻辑和场景的考虑，这样发现的问题才更深，而开发的很多 bug 就在这些地方。
关于边界之类的可以按照优先级看时间往后放放。
覆盖率本身是个有争议的东西，东西还是从用户角度出发，能用，好用，逻辑正确为基本总线，所以建议关注这些。
线上监控是必要的，但是测试阶段的 case 设计要涉及更广范围，既然都可以用 python 写脚本了，建议 postman 只做校对工具临时使用，还是尽量实现脚本自动化，让程序来校对正误。
移动端，实在不好意思，暂时提供不了好的建议，但是从用户角度考虑问题是个很重要的解决方式，可以暂时使用。
代码质量差，必须设计准入 case，让 RD 去过，测试的时候发现有没有过的打回重新开发
不然测试浪费时间太多