关于IOS测试
前言：
最近跟很多同行讨论过，现在也想和大家聊聊，我这里还有一些APP测试的具体指标,希望通过自己很有限的经验帮助大家。内容中部分是可以百度到，部分是我自己的一些看法，欢迎大家补充。
2016/1/27
虽然近几年有大量的测试人员加入到测试这个行业，社会中的各种培训机构、学习网站、交流社区也越来越多，但是能真正认真做测试的公司仍然不多，这里说的“认真”并不是一次精准细致的测试或者说短时间内的测试，而是指对一款APP的生长过程中的无数次测试，随着环境的改变而做出不同的测试。
我们都知道任何App要想在苹果的AppStore上架，都需要经过苹果的审核员的审核，不管你是世界五百强的大公司，还是小作坊，都会一视同仁，绝无例外。如果你的App没有经过良好的测试，被审核员发现有闪退、崩溃或者其他严重质量问题，他们会毫不犹豫地拒绝你的App。而你则需要修改App，重新提交，这往往就意味着再等7~8天的排队才有机会被审核。如果你的运气好，Bug没有被审核员发现，或者说，在审核员审核的环境下，你的App表现良好，你的App就成功上架了。但是如果它在用户的iPhone/iPad上面发生闪退、崩溃，等等，其实你会更倒霉。因为愤怒的用户会迅速让你收获大量的1星，即使你好不容易做了一年的好评度，也会一下子跌落谷底。如果你熟悉AppStore的话，就知道这往往意味着你的下载量将一落千丈，你的App也有可能从此无人问津。所以，对iOS开发者强调测试的重要性，我觉得说100遍、1万遍都不嫌多，都有其现实意义。但是为什么还有那么多团队和个人开发者没有进行完善的测试呢？懒、侥幸心理、怕麻烦一定是少不了的。还有，我觉得就是一般的入门书、教程，甚至包括苹果的官方文档，讲到的测试部分都太简单，缺乏可操作性。 我给大家推荐一本专注于iOS测试领域的书，书名为《iOS 测试指南》，作者是芈峮。书中的内容很具体，也很实用，从基本的讲到iOS环境再讲到iOS的持续集成，使我受益匪浅。
指标：
A.测试周期
测试周期一般为两周，根据项目情况以及版本质量可适当缩短或延长测试时间。正式测试前先向主管或产品经理确认项目排期。
B.测试资源
测试任务开始前，检查各项测试资源。
产品功能需求文档
产品原型图
产品效果图
行为统计分析定义文档
测试设备（ios3.1.3-ios5.0.1）
其他（例如有秒杀专题的项目，需要规划秒杀时间表；有优惠券使用的项目，需要申请添加优惠券数据；支付宝/银联支付功能的项目，需要提前申请支付宝/银联账户等等）
C.测试要点
接收版本
本人觉得，这个过程可以直接略过。非专业测试者，不喜勿拍。
UI测试
确保手头的原型图与效果图为当前最新版本。
确保产品UI符合产品经理制定的原型图与效果图。
一切界面问题以效果图为准，若有用户体验方面的建议，必须先以邮件或口头的形式询问产品经理。
由于测试环境中的数据为模拟数据，测试时必须预先考虑到正式环境中可能出现的数据类型。
功能测试
确保手头的功能需求文档为当前最新版本。
确保所有的软件功能都已实现且逻辑正常。
一切功能问题以需求文档为准，若有用户体验方面的建议，必须先以邮件或口头的形式询问产品经理。个人建议，用户体验方面的建议，优先级放在修复bug之后。
若有些功能在技术上难以实现或者由于排期的原因无法在短时间内实现，必须得到产品经理的确认，而不是单单只听开发人员的技术解释。此处确认最好以邮件形式存在。
所有的“外部原因”问题，都需要尽早地督促开发人员与客户服务端人员联系协调解决。并在之后的测试报告中予以体现。
所有的“设计如此”、“延期处理”问题，都需要和产品经理确认后再进行验证。并在之后的测试报告中予以体现。
测试下单时，注册的测试账号必须符合公司规范；收货地址必须包含“测试”关键字，最好每次下单的名称中含有日期，以便查询；在正式环境中下单后必须取消该订单等。
兼容测试/性能测试
确保软件在所有兼容机型上都能正常使用（ios一般需要兼容7或者6, ios5可以不用考虑，用户使用率已经低于5%以下）
对于低端性能兼容机上独有的问题（例如ios5以下），若在技术上难以修改或者由于排期的原因无法在短时间内改进，必须在测试日报中注明，并得到技术平台主管、产品经理以及运营人员的确认，最好以邮件的形式得到确认。
性能测试方面必须满足硬件压力条件下的测试需要（例如多线程，用户常用的app都要后台运行的环境中测试。）
网络响应用户体验方面的性能测试，需要保证在wifi、3g、2g网络下的切换效果。比如wifi切换到2g，网络响应的速度以及切换界面。
后台订单统计测试
核对“客户端相关启动查询”项，此项数据就是经常说的“激活量”，非常重要。测试时必须保证该项中的各数据均正确，且每次启动软件都会有相应的统计记录。
核对“订单查询”项，测试时必须保证各数据均正确，且每次成功下单后都会有相应的统计记录。
需要注意的是，在成功下单之后，后台会做判断将该订单划到测试订单范围，测试人员必须到“订单查询（测试）”模块中核对订单统计记录信息。
用户行为统计测试
确保手头的行为统计分析定义文档为最新版本，且与开发人员手中的文档一致。
确保产品经理在文档中所定义的页面在该产品中都是存在的。
尽可能真实地模拟用户行为。
核对统计日志，确保各项操作所对应的页面ID以及操作ID都是正确的。
回归测试
软件最终上线前，需对产品进行回归测试，测试内容包含之前所有的测试项目
回归测试不再对细节进行测试，而是类似于对产品进行验收，从客户正常使用的角度对产品进行再一轮的整体测试。
只有在回归测试通过之后，才对产品进行提交。
D.测试日报及产品上线报告
测试人员每天需对所测项目发送测试日报。
测试日报所包含的内容为：
对当前测试版本质量进行分级。
对较严重的问题进行例举，提示开发人员优先修改。
对版本的整体情况进行评估。
(产品上线前，测试人员发送产品上线报告)
测试问题归纳：
在不应该返回的时候返回了
不耐心而且多次敲按键；
输入错误的数据；
不理解该怎么做；
可能没有按要求进行设置；
可能会自以为是地认为自己知道该怎做什么（比如通常不阅读说明）。
测试人员遇到这些问题时，也常常发现意料之外的Bug。有时候，这些Bug微不足道，但是更深入的调查就会发现更严重的问题。
很多问题是可以被预先确定和测试的。测试移动端App时，以下的问题并不都有关，但是也可以尝试问问：
是否按照所说的来做呢？
是按设计完成任务的吗？
不是按设计完成任务的吗？
如果处于一直被使用或者负荷情况下，状况会怎么样？会反应迟钝吗？会崩溃吗？会更新吗？有反馈吗？
崩溃报告会反馈到App吗？
用户可能有哪些创造性的、逻辑性的或是消极的导航方式？用户相信你的品牌吗？
用户的数据安全如何？
有可能被中断或是被破解吗？
运行到极限时会发生什么状况？
会要求打开相关服务吗(如GPS、Wi-Fi)？如果用户打开会怎样？没打开又会怎样？
将用户重新引向哪儿？去网页？还是从网页到App？这会导致问题出现吗？
沟通过程和市场反馈是否符合该App的功能、设计和内容？
登录流程是怎样的？能在App上直接登录还是要去网页端？
登录是否整合了其他服务，比如用Facebook和Twitter帐号登录？
可能的是用户或者是软件开发人员在信息流中确实太容易迷惑了，因为可能会出现很多错误，所以基于数据和云的服务更为重要。
也许你可以尝试在以下场景中检查出问题：
移动设备数据已满；
测试人员移除了所有的数据；
测试人员删除了App，那数据怎么办？
测试人员删除并重装了App，数据怎么办？
过多或者过少的内容导致设计和布局的改变；
在不同的时间段和时区使用；
数据不同步；
同步被中断；
数据更新影响其他的服务（比如网页和云端服务）；
快速处理数据或是处理大量的数据；
使用无效的数据
这只是无数测试过程中需要测试者需要去解决的很小一部分，大家心里也都知道很多，篇幅有限就不过多的说了。
测试工具归纳：
UIAutomation是苹果xcode自带的工具，肯定比较好用。连上手机（签名的app或者越狱debug包）就可以进行自动化测试了。
appium，它原理就是通过selenium的webdriver移植过来的，现在也可以驱动UIAutomation进行自动化测试，优点是可以用任何语言开发，但是工具本身bug多，容易假死。
所以最好这两个工具都会用。
另外如果你是开发者，没有完成专业测试的条件，因为这需要极大的硬件与人力成本。在共享经济与协作开放的时代，开发者可以尝试从第三方来进行应用测试，继而发现应用的不足之处，及时完善产品质量，加速上线审核。让专业的人做专业的事，别让莫名其妙的bug拖延你宝贵的上线时间。这方面的话做的人很多，我不过多介绍了，只给大家推荐一个Testbird云测在测试领域是做得很好的一家。
Testbird云测 （致力于APP移动应用测试的专家）
最后：
之前看过一篇讲测试的文章，其中有一段我认为讲的非常好，这里引用一下
测试不是对错判断
我们讨论了移动测试的一些方面，但这些前提是：带着问题，才能发现问题。
通常，测试被认为是完全合乎逻辑的、可计划的和可预测的，过程包括：测试脚本和测试计划、通过和失败、正确和错误的反馈。走完这些测试流程就离真相不远了。
当然，如果必要，我们可以用上述方法进行测试，但这并不是测试的目的。我们不仅是为了创建测试用例、发现Bug，更重要的是找到关键的问题，为项目组决定什么时候发布App提供有价值的信息。而找到那些关键问题的最好方法就是：提问！