做QA的日子——iOS測试入门(四)

坦言,做QA的这半年我没有成长,就算有成长也非常少,我非常难过。和身边的人讲事实上并没有谁能真正理解自己的难过,事实上还是自己不够努力。对自己不够狠,以前认为自己不够幸运,想有一个更好的指路人,事实上这种想法是不正确的,哪有那么多的指路人,遇到了是你万幸。没有遇到你自己就做你自己的指路人。用自己的驱动力驱动自己成长。就算慢一些又如何,当有这种指路人助你一臂之力的时候,也许你会更加珍惜如今所拥有的。

做QA測试,非常多时候是站在后方支持整个团队的,非常有可能非常多时候会被别人看不起。别人会说,ta不就是一个測试的么,事实上不须要管别人怎么说的,你就是你。做好你自己应该做的,这才是最重要的,做你觉得是对的事情,那些闲言碎语事实上就是一口气,就那不瞬间,就算死了也带不走的东西。

当你做好了,无论在什么岗位上都一定会得到别人的认可,至少你会对得起自己的这段时光。把时光拿去无谓的比較那就是在浪费自己的生命。就是自己不给自己成长的机会,趁着年轻为什么不多学一点。多做一点呢,累点又如何呢?在工作中。觉得不要去歧视他人,每一个人有每一个人的生活状态,仅仅要是ta想要的,那都是值得去尊重的。不要太在意别人的眼光,做測试可是千万不要把自己限制在功能測试,有机会一定要去了解代码,这样你的技术上才会有长进,让自己更加全面。

想总结一下iOS測试入门。希望能够给那些想入门移动iOS測试的人一些帮助:

1.建议安装的软件

1)Xcode——用来看代码

2)安装charles——用来抓包

3)安装MindManager——思维导图用来写些測试思路

4)安装印象比較evernote——用来记些东西备忘

5)安装cornerStone或者smartSVN——checkout代码以及看修改点

6)安装iFunbox——用来装App,看App里面的相关文件

2.获取到一些通讯方式。如相关部门的QQ群、讨论组,一下经常使用的邮箱地址

3.假设你所測的项目须要接触代码。那就要知道代码svn的地址

4.你要測试当然要记录bug。bug的地址;当然还有安装包下载的地址

5.刚来怎样入手,能够做些神马?

1)过1遍或者N遍全用例来了解要測的产品的功能

2)看trac上别人是怎么记录trac的,去了解怎么提trac该产品存在神马样的问题?切记trac的一切初衷都是写具体复现步骤。这样就算你不在研发旁边研发也能够复现bug。假设你能够告诉研发这个bug的问题出在哪里,那恭喜你说明你又上了一个层次

6.在工作中哪些事情能够提高你的工作效率

1)建议把每次公布的线下包用自己的苹果账号下载下来,这样在下次安装或者測试覆盖安装的时候就不用反复下载了,会节省非常多时间的。

2)也建议自己把每次測试交付的包保存下来。这样假设某个版本号有问题也能够非常快找到安装包了,不用一个个去找。这样无形中就节省了非常多时间。

3)把重要的经常要訪问的网址(如邮箱、trac地址、技术站点等)加入到浏览器的标签这样就不用每次去找,再去输入地址了。

当然不一定标签能够放那么多,那你就能够像计算机缓存一样把没有那么经常使用。可是又经常使用的地址放在一个txt或者记到印象笔记中,方便自己每次查找。

4)一定要注意沟通。不要害怕,我就由于这个吃了好长时间亏,就算别人认为自己不行又怎么样,解决这个问题才是关键,假设自己超过半小时还没有把问题解决,强烈建议自己向身边的人求助,说清自己之前的解决以及眼下遇到的问题。

5)工作中要善于总结。能够以文档形式总结,写到不仅自己要明确别人也要明确,想不明确的事情一定要努力想明确。

先写到这,下次我要总结常见问题的排查方法。加油,一起加油。人因梦想而伟大,经过了一些事情,才更知道自己想要的是什么。

时间: 2024-10-24 12:15:52

做QA的日子——iOS測试入门(四)的相关文章

做QA的日子——iOS测试入门(四)

坦言,做QA的这半年我没有成长,就算有成长也很少,我很难过,和身边的人讲其实并没有谁能真正理解自己的难过,其实还是自己不够努力,对自己不够狠,曾经觉得自己不够幸运,想有一个更好的指路人,其实这样的想法是不对的,哪有那么多的指路人,遇到了是你万幸,没有遇到你自己就做你自己的指路人,用自己的驱动力驱动自己成长,就算慢一些又怎样,当有这样的指路人助你一臂之力的时候,或许你会更加珍惜现在所拥有的. 做QA测试,很多时候是站在后方支持整个团队的,很有可能很多时候会被别人看不起,别人会说,ta不就是一个测试

ios測试框架的理解

关于ios的測试 Cedar .Specta .Kiwi  .  XCTest Specta和Kiwi的差别就是Kiwi包括了Specta和OCmock以及Expeata全部的功能 測试框架的作用: 因为行业中的干进度,所以我们一般都是不用TDD来測试,而是用BDD来測试. BDD是用来測试的"数据存取"的重要环节. "术语" 理解: BDD(Behavior Driven Development),也就是行为驱动开发.它旨在解决详细问题,帮助开发者确定应该測试些什

UIAutomation使用測试入门

自己主动化測试的优点: 1.自己主动化能够自己主动測试,不须要人的干预.同一时候还能够不断地反复某一个动作. 2.自己主动化測试在添加了新的功能之后.还能够回归到原理的功能,使其原来的功能不会受到影响. 缺点:会受到測试系统和project师的制约. 自己主动化測试脚本的执行有可能受到不同层次的限制与制约. 大概就是主要两个方面: 1.系统级别的执行机制,并非全部的程序(中的)代码能够自己主动执行,由于ios中的程序的之间总是存在着一些权限.这个就是要考虑到安全级别的问题.签名 2.应用程序级别

9.12測试(四)——測试笔

怎样測试一支笔 首先.确定Who/What/When/Where/Why/How. 然后.确定測试的计划: 事实核查 预期用途 安全性 非预期用途

iOS測试——置换測试: Mock, Stub 和其它

文章地址:http://ryantang.me/blog/2014/08/21/test-doubles/

[iOS翻译]《iOS7 by Tutorials》在Xcode 5里使用单元測试(上)

简单介绍: 单元測试是软件开发的一个重要方面.毕竟,单元測试能够帮你找到bug和崩溃原因,而程序崩溃是Apple在审查时拒绝app上架的首要原因. 单元測试不是万能的,但Apple把它作为开发工具包的一部分,不仅让你创作的APP更稳定,并且提供了一致.有趣的用户体验,这些都是让用户给你五星评价的源泉.iOS7提供了一个升级的单元測试框架.让你在Xcode中执行单元測试更为easy.当你完毕这一章节,你将学会怎样给现有app加入測试--并有可能培养出对编写測试的热爱! /* 本文翻译自<iOS7

软件測试系列之入门篇(一)

一.你知道软件測试有多重要吗? 在国际上.软件測试(软件质量控制)是一件很重要的project工作.測试也作为一个很独立的职业. 在IBM.Microsoft等开发大型系统软件公司,许多重要项目的开发測试人员的比例可以达到1:2甚至1:4. 在国内软件測试的地位还不够高.而且大多仅仅停留在软件单元測试.集成測试和功能測试上.软件測试从业人员的数量同实际需求有不小差距.国内软件企业中开发者与測试人员数量一般为5:1.因此.国内的软件測试产业化还有待开发和深掘. 讲到这里不知道你反应是高兴还是失望?

写可測试的代码

写可測试的代码 不论什么一个软件都是能够測试.在某种意义上,用户的使用过程也就是一个软件測试的过程.但是这并非我们今天要讲的可測试性.我们讲的可測试性指的是代码的可測试性,通俗点儿说就是是一串代码里包括的逻辑是不是能够被单元測试所覆盖.在这篇文章里我会从单元測试的基本概念開始引伸到怎样写单元測试,怎样写可单元測试的代码.文章里全部的样例都是C#写的,一来它是我职业生涯的主力语言.二来C#广为人知,相信对广大职业的或是业余的程序猿来说读懂C#的代码不会是什么特别困难的事情.实际上我描写叙述的方法和

Unityclient通信測试问题处理(一)

近期在測试程序的通信模块时.遇到了一个问题:Unity的API函数仅仅能在主线程中调用.而作为client程序,我单独启用了一个监听线程来接收服务端发送的消息,消息接收后的解析函数也由该线程一并调用.那么问题来了.在解析函数之中,我将不能调用Unity的不论什么API函数. 之前由于没有意识到这个问题.很多处理都是直接放在消息解析函数中做的,程序一经測试首先就报出了下面错误: CompareBaseObjectsInternalcan only be called from the main t