上午 ci 又坏了，折腾了半天。

提供一下排查思路：
1.在 ide 上做设置，根据红色叹号做修改，然后 package，package 成功后保存工程配置文件。
2.check out 出来原来不能成功的工程配置文件，两边做比较。
3.在 ci build 前 sed 替换工程配置文件中的项。
4.目前大体看来就是 @sanlengjingvv 说的哪些项。

因为开发本地 build 和 ci 打包配置（主要是签名相关的）肯定不一样，肯定会冲掉你做的设置。所以 sed 动态修改是没有办法的办法。

感谢 @sanlengjingvv

#26 楼 @sanlengjingvv

我也是 sed 修改配置文件
ProvisioningStyle = Manual 暂时解决了问题

最近临时接手，对 ios 构建还是半生不熟。发现 xcode 每次升级都要折腾我们一番。
Xcode 的这一套签名方案真够绕的，最近打算把这破玩意儿好好刷一遍，争取弄通了写一篇文章。

#14 楼 @sanlengjingvv 这个变化十分恶心。

btw，如果@anonymous 的话，发帖匿名者本身的账号会收到系统通知么？

#43 楼 @anonymous 匿名的本意是：不对外人披露自己的名字。但是无法修改就是放弃帖子所有权。所以我理解上会产生困惑。

41 楼是我发的。匿名后无法修改自己匿名的帖子。这是 feature 还是 bug 呢？@lihuazhang

提供几个思路：
1.目前的工作最缺什么技能？最缺什么就学什么，有问题压着，效率会很高。
2.目前公司的技术栈是啥？可以选一个点，从开发的角度来学习，把自己搞成有 1 年~2 年开发的 level，比如 1~2 年的前端 ios/android 或者后端工程师。这个好处是，你可以在和开发沟通的时候掌握更多主动权，发现更多深层次问题，减少被忽悠的概率。
3.你最喜欢什么？
4.看到一大坨不会的，别恐慌，日拱一卒。有两年，你发现也就那点儿东西。
5.常规的测试开发思路有：自动化框架，质量平台，CI，测试数据，内部生产力工具，等等。
6.good luck

#44 楼 @silent_8 good luck

#42 楼 @silent_8 这个问题好大。。。首先说一句话 “质量不是测出来的。” 测试不是质量的守护神，测试只能搞定一部分事情。所以，单从测试环节和测试人员入手很难从根本解决问题。从你的描述来看目前开发从技术和项目管理上都有短板。不知道你对过程改进有没有了解，如果有，可以先推这一块儿，因为这一块儿见效最快。关于测试团队，把自己工作范围内的事儿做利索，这样对其他人指手画脚才会有比较好的效果，这就是一个大话题了，建议先从能够把测试团队的工作变得有条理开始，比如，能够合理的预估你的测试时间，并告知项目经理及其它干系人，每轮测试完成后有良好的信息（产品完成度如何，有何风险，bug list 等）清晰的汇报给干系人；保证你的测试是有效的，能够 cover 风险，如果时间和资源上搞不定，能够让所有人知道等。

推荐一本必读的书：
http://item.jd.com/10131514.html

#63 楼 @ycwdaaaa good luck 愿你招到合适的人选。

#60 楼 @wonew1228 竟然同时发了个贴。

浇几盆冷水：
1.如果事先明确定义了工作范围和技能要求的话，你面试通过的比率应该会高很多。不然是浪费彼此时间。

2.考察具体知识建议结合应聘人以前的工作背景，看他熟悉什么，你就问什么，并深入的问，这样可以考察应聘者研究问题解决问题的能力。不过，这就要求面试官的知识广度和深度了，而不是一味要求应聘者对你懂的那一亩三分地也很懂。例如，设计模式的问题，我觉得如果不是有过 10w 行以上代码积淀，或者整天战斗在一线的开发者，要求讲出细节，其实难度有点大。其实问深了你也不见得知道细节。比如，我问一个问题：请问，在 Scala 下的 singleton 可以如何实现，和 Java 的实现方式比较有什么有什么区别？有什么优劣？或者 awk 的时间复杂度是什么？我猜你八成答不上来。这并不代表你无法很好完成你分内的工作。

3.什么样的薪水可以招到什么样的人，的确目前一将难求，哪个行业哪个职位都是这样。你可以不满意应聘者，但把应聘者都贬损一遍，并用 “奇葩”，“傲娇” 这样的字眼的话，我觉得楼主也能配得上 “傲娇” 一词。

4.一个很棒的测试开发真的很难招到。因为既要懂测试又要懂开发，充其量又和开发拿的钱差不多，上升路径还不如开发。所以。。。碰上一个聪明伶俐有潜力的同学就应该谢天谢地了。

建议：
放低预期，把问题放在应聘者是否真正能够吻合你工作要求上边来。如果要求过多的技能，对你和应聘者都是浪费。本着合适就好的原则面试会有更好的效果。当然你如果是土豪公司，或者带着光环的公司，要求个个是精英可以忽略我这句话。

#22 楼 @cy_suncheng sorry，暂时满员了。多谢兄弟关注。
我会修改原帖。

手动点赞。前途不可限量。q 博加油。

#5 楼 @oscarxie 求贴。

#9 楼 @lihuazhang 推特上推荐我几个人吧：）

说说我的习惯：
1.多和同行交流，聊天的时候同行会说一些信息。我会根据这些信息去 google（绝不是百度）然后找到技术解决方案的网站。
2.多参加一些会议，关注测试 session。国内好的会议目前我觉得 infoq 的测试专场会不错，TID 其实也值得参加，国外的我会关注每年的 star east 和 star west 还有 google 的自动化测试大会。这样就能跟踪一些真的比较好的成果。结合你实际的问题有选择的研究。如果你比较关注前沿的学术研究，其实有很多学术会议，会有很多 paper 散出来，我曾经特别喜欢啃过一些，但现在看的少多了，因为大多数不能直接应用，而手头问题又太多只能放弃。
3.问题驱动：有什么问题就死命找解决方案，搜索引擎，同行。想法获取跟你面对同样或者类似挑战的先行者，学习他们，追上他们，然后跟他们一起磕。
4.关注一些国内测试专家的微博（为了避嫌不写名字了，你可以顺藤摸瓜）他们会时不时发一些他们关注的新技术，新方法。
5.买市面上大部分风评还不错的测试书（每年算上国外的也不过七八本）并翻阅。
6.关注国外一些专家的 blog，我常看这几个：

http://kaner.com/
http://www.satisfice.com/blog/
http://lisacrispin.com/
http://www.developsense.com/

7.把视野放到整个 it，不光光是测试，很多东西和问题都跟测试相关，我会获得很多 idea 和线索。然后有选择的 google，深入了解。

8.testerhome，国内目前很好的测试专业论坛，有很多热爱测试技术的人在这里。多泡泡能学很多东西，我经常潜水。
9.学技术习惯用百度=慢性自杀。三年后你会比习惯用 google 的人差一大截子，当然工资也会差一大截子。

#29 楼 @seveniruby 嗯。好趋势分析。其实所有工种都得进化。
但是我对 QA 整体进化速度不乐观。对传统 QA 的淘汰现状也不会太悲观。因为技术的门槛没有那么高。认识 N 个姐姐已经成功跳槽互联网了，慢慢补一些技术（只要肯学，根本没多难），现在也发展很好。

你分析的质量会变成多层次承载的这种趋势其实真的挺明显。
灰度，云测，众测，生产系统质量监控、反馈、数据分析，这些都有大片工作去做。也改变了很多现有测试的工作模式。
其实本质是传统的测试方法论搞不定现在的系统了，需要不断的进化

#27 楼 @oscarxie 业务测试（手工测试）的很大价值真的在集成测试这一块儿，参与过大型系统构建的人会深有体会。
很惨的一个现实是：测试的价值扔然被低估。尤其是手工测试的价值。我不认为我们国内一些厂商的实践方式是好的，有些实践长了必然深受其害。冷暖自知吧。

再重复一遍说过 n 遍的观点：我们只看到了国际一线大厂（GOOG FB AMAZON，不是国内大厂）越来越少的测试。没有看到国际一线大厂平均快 20w 美刀的年薪，n 轮面试，每个工程师都是精英中的精英，有能力和有意愿做好绝大部分事情；没有看到大厂各种科学的管理方法、工程方法；没有看到大厂对基础设施的巨大投入（各种定制的工具，自动化流水线，工程方法）；没有看到大厂对每个工程师代码近乎变态的苛求（有认识 GOOG 的人去问问他们的代码规范，评审过程）；没有看到大厂有效的知识传递体系；没有看到大厂质量共担的文化。
举个例子：一个 MIT 毕业的博士可以在 google 开心的写七八年 JS，所以能够研究到很深，出来的代码质量自然没的说。到了国内肯定就是 CTO 整天开会了。
说白了，没有那么多牛人，很多你看着很美的工程实践永远无法落地。 牛人的比例基本是是固定的，所以。。。大部分公司还会该怎样怎样，慢慢的爬升。摧枯拉朽的变化在行业里是不会出现的。

对于一个测试人员来说，只会手工测试，而对你需要测试的东西的实现技术没有一点认识肯定是做不好工作的，这点毋庸置疑。
测试人员要掌握的很多，结构应该是一颗均衡的技能树。 所以传统测试人员肯定要保持不断的学习，包括必要的 it 知识的学习，其实并不是很难。

测试的本质还是发现问题，一味的追求技术，最多也不过是被称为 “测试开发” 而已，还是一个开发人员，一样有苦恼，一样有天花板，测试开发的职业空间还不如开发，既然那么喜欢技术还不如直接转行了，跳出去会有更好的天空，因为你去做了喜欢的工作。

真爱可以只 follow 自己的 heart 就行。

#17 楼 @lihuazhang 不叫自私的。就个人来说，肯定是个人发展最重要啊，这没什么可说的。其实大部分的时候个人发展和公司发展能结合到一块儿。如果发现真的被消费了。两个选择，选取 smart 的方式规避；走人。

#10 楼 @cathy 从流程上做优化是可以从很大程度上做到减少返工的。测试不是被动的按照需求设计用例，发现需求和设计中的问题也是测试的一项重要工作。建议了解一下敏捷和精益，还有软件开发过程相关的一些知识。
参考书：
实例化需求
http://item.jd.com/11073791.html
用户故事与敏捷方法：
http://item.jd.com/1695419808.html
scrum 敏捷软件开发
http://item.jd.com/10400883.html
看板方法
http://item.jd.com/1702705156.html
软件需求最佳实践
http://item.jd.com/11224645.html

很赞的话题，谈谈我的理解：
1.有一些行业是业务密集型行业如银行，民航，医疗，证券等，需要很长时间去学习业务知识，不光是测试人员，开发人员也得掌握很多业务知识才能把活儿做下去。作为测试，想做好对应的测试工作，得舍得花时间去学习。而你业务比较精深以后，其实话语权和职业发展还是不错的。但是，业务的确有局限，如果你换了行，这部分优势就没有了。这就是俗话说的换行穷三年，不过行业足够大的话，可以换公司不换行。
2.这里所说的业务测试其实是偏功能的系统测试，约等于手工黑盒测试。很多小伙伴的印象就是：黑盒测试很 low，就是点点点，谁来都行。这其实是个错觉。测试是一项极为复杂思维过程，是非常有创造性的活动，是一个在有限时间和资源下选择最有效验证方式的艺术。高超的黑盒测试能力也需要经过大量的训练来习得（有人有这方面的天才，非常快就能很牛逼，但是不是天才的人也能够习得）。习得的路线其实是可以复制的，但是目前并没有特别详细的教程，不过已经有了很不错的骨架。推荐三份资料：《探索吧》，《The little black book on test design》还有 James Bach 的《启发式测试策略模型》，这三份都是值得读好多遍，并不断根据它思考演练的材料。最后的测试能力一定是脑袋里的一份地图或者思维导图，每个人不见得一样。 根据我的大量观察，有这份图的人测试非常有效率，有针对性，远离盲目，有的时候让你忍不住竖起拇指大赞天才。目前我身边就有两个找 bug 特别猛的小伙伴，他们的灵光一闪总是让我钦佩，他们有一点天生，不过也是经过 n 年刻意训练的出来的。
3.有一个词叫做 “领域知识”。其实抽象一点儿，所谓的业务和技术都是领域知识。如果你在做 “云平台” 的测试项目，你的领域知识可能就偏技术一点，如果你做 “第三方系统 “你的领域知识就需要偏业务点（当然也需要有很多技术相关的知识需要掌握）。以前看的一本测试书有一句话至今影响我：“能否做好测试，最重要不是看你有多大能力，而是看你对被测系统有多深的理解。” 这句话不断的被验证着它的正确性。死磕你眼前的东西，从业务和技术上都真正搞定它，最后一定会不错。至于优先级，我觉得哪项知识能够帮助你更好的工作就先搞它。把学习和工作结合起来是一种效率极高的方法，学了就是用的，用了才能看到更多的问题更好的学。
4.当你把一个稍微复杂的项目，乃至一个系统的测试问题全能很好的搞定的时候，你就可以说自己是一个测试架构师了。有时候需要好几年，但事情发生在不经意间。

#3 楼 @lihuazhang 那是能做好一切事情的能力。。。

#43 楼 @kasi 其实我只会写鸡汤。。。