关于IOS测试

时间 2019-12-06

标签关于 ios 测试栏目 iOS 繁體版

原文原文链接

前言：

最近跟不少同行讨论过，如今也想和你们聊聊，我这里还有一些APP测试的具体指标,但愿经过本身颇有限的经验帮助你们。内容中部分是能够百度到，部分是我本身的一些见解，欢迎你们补充。
2016/1/27ios

虽然近几年有大量的测试人员加入到测试这个行业，社会中的各类培训机构、学习网站、交流社区也愈来愈多，可是能真正认真作测试的公司仍然很少，这里说的“认真”并非一次精准细致的测试或者说短期内的测试，而是指对一款APP的生长过程当中的无数次测试，随着环境的改变而作出不一样的测试。
咱们都知道任何App要想在苹果的AppStore上架，都须要通过苹果的审核员的审核，无论你是世界五百强的大公司，仍是小做坊，都会一视同仁，绝无例外。若是你的App没有通过良好的测试，被审核员发现有闪退、崩溃或者其余严重质量问题，他们会绝不犹豫地拒绝你的App。而你则须要修改App，从新提交，这每每就意味着再等7~8天的排队才有机会被审核。若是你的运气好，Bug没有被审核员发现，或者说，在审核员审核的环境下，你的App表现良好，你的App就成功上架了。可是若是它在用户的iPhone/iPad上面发生闪退、崩溃，等等，其实你会更倒霉。由于愤怒的用户会迅速让你收获大量的1星，即便你好不容易作了一年的好评度，也会一会儿跌落谷底。若是你熟悉AppStore的话，就知道这每每意味着你的下载量将一落千丈，你的App也有可能今后无人问津。因此，对iOS开发者强调测试的重要性，我以为说100遍、1万遍都不嫌多，都有其现实意义。可是为何还有那么多团队和我的开发者没有进行完善的测试呢？懒、侥幸心理、怕麻烦必定是少不了的。还有，我以为就是通常的入门书、教程，甚至包括苹果的官方文档，讲到的测试部分都太简单，缺少可操做性。我给你们推荐一本专一于iOS测试领域的书，书名为《iOS 测试指南》，做者是芈峮。书中的内容很具体，也很实用，从基本的讲到iOS环境再讲到iOS的持续集成，使我受益不浅。web

指标：

A.测试周期xcode

测试周期通常为两周，根据项目状况以及版本质量可适当缩短或延长测试时间。正式测试前先向主管或产品经理确认项目排期。安全

B.测试资源网络

测试任务开始前，检查各项测试资源。
产品功能需求文档
产品原型图
产品效果图
行为统计分析定义文档
测试设备（ios3.1.3-ios5.0.1）
其余（例若有秒杀专题的项目，须要规划秒杀时间表；有优惠券使用的项目，须要申请添加优惠券数据；支付宝/银联支付功能的项目，须要提早申请支付宝/银联帐户等等）多线程

C.测试要点app

接收版本
本人以为，这个过程能够直接略过。非专业测试者，不喜勿拍。工具

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提供有价值的信息。而找到那些关键问题的最好方法就是：提问！