这 bug 明显是因为用户名两行没做处理导致的...成都的小伙伴没有这么长的昵称....

想读原因:
想要了解更多 iOS 平台的测试方法和工具,拓展测试思路,实践自动化测试.

学习计划:
本书分三个部分,十个章节.都会通读一遍.
对第一,第六,第七,第九,第十章会重点阅读.

读书笔记:
平时就有写笔记的习惯,只是更随意一些.
这次会整理好并发出来的.

志愿者的名额是不是已经满员了?

客户端还是服务器?
效果不错,指的就是速度和质量都有提升啊

Android 客户端的覆盖率我们用了两年了,最近对服务器加了覆盖率的使用,效果不错,对测试质量和速度都有提升.

求手册

#10 楼 @crisschan 华为网盘关闭了~~~求个下载地址~

#2 楼 @neatdagon 你可以问问研发~他们肯定是清楚的.

我司也是做日历,碰见同业了.棒棒哒~多交流啊~~~

好多种办法,你看你开心用啥了.

比如,如果 monthView 上有日期,get 日期可以判断那个是当前展示 view
比如,如果 monthView 不是整体,可以通过子 view 的个数来判断一下
比如,你家研发好沟通,让他帮忙改改属性

可以肯定的是,源码里应该有方法会知道当前显示的 monthView 是那个,
robotium 的方便之处就是可以用源码的方法,多开心

就算不是日历,其他页面的形式,也可以用类似的方法进行判断的.

#23 楼 @xdf android 真机没有问题,但是 iOS 一直提示 waiting device start. macaca doctor 检查都是没有问题的

#9 楼 @xdf 我是真机,iOS 手机是 6s

#21 楼 @defias test 是 QA 流程中的一部分工作,如果为了提高质量,我觉得 QA 更适合一些

#20 楼 @defias 客气啦~我们所有的流程有包含产品和研发,还有一些细节会包含设计~还有输入,输出标准

#17 楼 @defias 管理方面我也是在不断摸索,可能我个人比较传统,更看重这些基础.
我司的流程都包括产品和开发.给你看个例子,其实我们也是根据自身情况制定的,做的也不是很好.
我最近也打算好好再优化一下我们的流程,这次参加大会之后,也觉得有些地方可以再优化一下.
等我忙完这个项目,复盘之后,整理一下,大家一起看看,多多讨论.

#10 楼 @defias 我觉得他给定的大目标什么的,这个都没问题.但你肯定要跟他对一下其中的细节和完成的时间点.他不明白,你得让他最起码得理解.一步步的来.
大目标总要拆分成小目标,给出明确的时间节点和衡量标准才是真的准备实现的目标.要不就都是空谈了.
我觉得他给半年的时间,你将目标细分一下,分成几个阶段,每个阶段的目标什么,如何执行,效果会是什么样的.这个目标的执行细节是由你来掌握,有没有风险,能不能达到预期,都可以说明一下.

比如规范流程什么的,制定需要的时间很短,一周都用不了,主要是花时间在执行和不断的优化上.
但这些主要费时间都是每天常规工作上,制定了之后,优化和改进就是常规任务了,有没有什么高大上的目标这个也是需要执行的.
之后就可以为了自动化,接口,持续集成做准备啊.自动化没问题啊,先准备测试用例,准备的过程根据产品特性选择一下工具.
如果你们组的目标订了,也得传递给组里每一个人,让他们一起为了这个目标努力,不用自己一肩抗.以后每个月都核对一下进度,多沟通,有问题及时修正.

我司迭代也非常的频繁,以前两周一版,一周一版的时候都有.Android 和 iOS 都要发,还牵扯服务器和前端的修改.
之前全公司都觉得所有的时间都浪费在测试上了,为什么测试这么花时间,和开发周期用相同的时间,有时候还要超过开发周期.
我把整个测试流程做了非常明确的流程图,告知所有人.还有每个版本的测试计划,用例有多少,执行时间需要多少,free test 需要多久,回归,验收要多久,全都列出来了.
提测开始之后每天都输出一下测试进度,比如什么地方出现了严重问题,需要研发赶紧解决,测试时间是否需要调整之类的.
迭代结束再做一下复盘,到底每个版本用了多长的时间,过程中出现了什么问题,和产品,研发一起开会说明一下.
效果还是不错的,大家都知道时间浪费在什么地方,研发也开始注重质量.整体还是在往好的方向发展.

被边缘化这事,我是通过更积极主动参与项目中,更多的和研发,产品沟通,来慢慢解决的.
之前 QA 在技术边被缘化有一部分真的是我自己造成的,本来 CTO 就不太了解测试,也不知道该怎么管理.我呢,又不是什么积极主动跟领导沟通的人,说一次费劲,说两次费劲,以后就懒得说了.有些误会慢慢的就越来越深了.
为了改变这个问题,我先把以前测试的流程整理出来,发全员邮件,让大家看看有没有什么意见,真是给了不少建议,也促进我们优化了不少.流程确定之后,给了相应的规范和准入,准出的标准,过程也挺费劲的,但都是值得的.
形成习惯之后就好了,现在我要是没复盘,研发产品都会催.

我司之前跟你说的情况类似,咱们可以一起探讨一下~我还是支持 CTO 领导 QA 的,毕竟 QA 还是一份需要有技术的工作.
我觉得多沟通,双方都抛开成见,你也别嫌弃他不懂测试,说明白当前的困难,你需要的帮助,正常点的 CTO 还是很好沟通的.
不管研发,产品做的怎么样,先把自己该做的做好,有自己的历史数据的积累.对新的技术,小范围实验,及时总结,阐明利弊,用数据话说.
该坚持的坚持,该尝试的尝试.自动化,性能测试,持续集成,真的没那么高大上.都是工具而已,主要看你怎么用了.

我到公司的时候就两个测试,但是 QA 组内所有的工作流程,规范,标准什么的,我全给定了.虽然公司的工作流程一直在变,每次我都会根据变化及时变更,然后出一个文档,发给所有人.这部分,我觉得还是靠 leader 自己推动,靠 CTO 就有点不靠谱了.
QA 的技术方向还是得靠 leader 自己找,不太可能靠 CTO 给吧?我司 CTO 是服务器出身,基本上我都是有几个方案,他给排优先级.每次都能收获不少,他总说"这块我不是特别了解"但是每次都能根据他的经验,给出很多意 (抬) 见 (杠).我还是相信一通百通的,作为技术他思 (抬) 考 (杠) 的角度,还是很有帮助的.
由 CTO 直接领导,更容易提升 QA 的技术,提升研发对质量意识.

之前,QA 组名义上是技术部,但感觉非常边缘.技术培训没你什么事情,前期需求讲解,只叫研发,没你什么事.CTO 也是技术大拿,对测试有一点了解,反正不是很看得上,觉得没技术含量,人员素质差.对 QA 组完全放羊,除了问问测试时间,基本没什么交流.对 QA 的发展,除了提高效率,提高质量,没给过什么实质性指导.和你的情况相反,我们老大觉得如果技术不成熟,人员能力跟不上,搞那些虚头巴脑的东西,不能提高效率和质量,还浪费时间和成本.

在这种情况下,我觉得非常痛苦,没归属感什么的就不说了,工作都不好开展.随着项目越来越紧张,版本质量开始下滑,估计 CTO 也感觉到不管管 QA 不行了.
有一次 CTO 突然跟我说,让我给他找点测试相关的资料看看,我趁着机会反正 QA,测试相关的概念性的东西,都给他了.虽然还是得解释一些概念,但是沟通能在一个频道上了.开始对研发提质量要求的,推动产品,研发自测等等.目前算是良性发展了.

#5 楼 @gaopeng1106 改了~

#1 楼 @pacerron 谢谢~~ 有 bug 就提别客气~~~