加精理由: 借着热度宣传下社区的微信号

猎头？薪资范围？

加精理由:实用，学习并分享是社区精神

加精理由:对 js 实现输入进行了原理解释，对移动 h5 的测试有参考价值

selenium 就是这么做的 可以参考他的代码 robotium 里面也有针对移动端 h5 自动化的实现

#85 楼 @fresh 随心就好.

#83 楼 @zailushang 谢谢. 我只是分享给社区的同学, 辩论交流下. 没必要跟社区外的人陷入什么口舌之争. 还是不要转了.

赶紧做那个没有 markdown 就不让发帖的功能吧.

#79 楼 @luxiaofeng 太虚的文章我不会写. 别人自称大神, 我也拦不住. 这个锅不要让我背啊.
在我没写文章之前, 懂 monkey adb appium, 会写 if else 的不少人都自称大神了.
如果早晚都要自称大神, 我宁愿那些人能按照我说的多学点. 知道的越多会越谦逊的.
我列举了这些工具其实也是增加了这群人装逼的成本. 其实也是好事吧.

工具和技术栈上就是解决问题理念的最成熟体现. 接触的工具越多, 越能深入理解解决问题的理念的. 量变会有质变.
本质上测试, 研发, 产品都是一定程度的技工. 既然同是技工, 为什么不选更好的工具那.
所以研发们从 eclipse 倒腾到 IDEA, 从 svn 折腾到 git. 看起来是工具升级成为高级技工了. 实际上是解决问题的理念更好了.
工具并不简单是一个物品和技术, 也深藏了很多解决问题的方法和模式.

#78 楼 @luxiaofeng 按照你的逻辑, 以后大家是不是提一个工具的时候都要先说几万字用的理由. 我只是罗列公司内经常用到的一些工具, 让大家看到现状. 过几年可能一些工具也会被行业淘汰了. 这个没包含什么价值观和人生观. 说实话用过相关的工具, 想不懂都难. 对于新人来说就已经可以为公司做服务了. 至于有没有深入的理解, 这决定一个人能走多高, 那就是个人的事情了. 但是如果没接触过相关的技术栈, 连面试都进不去的.

面试官大多都是实用主义, 他们需要 spring 的人, 你说没用过 java 只懂 asp, 他们不会问你为什么会选择 asp, 只是把简历扔进垃圾桶.
只要你的确用过相关的技术栈, 他们才会开始问你的解决问题的思路. 没有这个基础就没有公共语言了.

#70 楼 @wixed 别喊我大神, 我也是小弟. 你喊多了会导致我被人误解成沽名钓誉害我被喷的. 根据你的年龄, 喊我思寒, 思寒哥, 思寒叔都行.

#68 楼 @fresh 我很多年前也遇到过, 不走管理的原因有多个.

• 想多点时间去研究和做事. 做管理的变化是很多事情不能亲力亲为, 你的业绩取决于别人. 这样不仅会导致自己不能深入的做事打好基础, 还会导致陷入对外部不可控因素的依赖. 在早期我觉得自己上阵解决问题更快.
• 预料到测试行业会整体做技术专项. 在五年前测试行业最大的瓶颈不是缺管理角色, 而是缺好的技术型测试工程师和架构师, 这个时候选择了去做管理无疑是进入一个一潭死水竞争激烈的红海. 测试架构师这个词语这几年很火, 其实是我七八年前自己创造的一个词语. 也不排除更早是有前人提过
• 管理逐渐会扁平化, 做管理要晋升的话, 需要熬的. 如果我有车有房我会心平气和的等待机会. 但是没有的话 ,就得选择一条更快的路. 而且做管理不一定非要有管理的职位,在平常的角色上也能得到锻炼. title 随时都是可以改的. 但是能力一旦错过最佳的锻炼机会, 就再也难弥补了. 所以我宁可累点.
• 以前也是小黑客, 所以对技术更偏爱.
• 一度因为追求管理, 心态有个不好的变化. 所以我也尽量避而远之.

不做管理的缺点也很大.

• 会错过获得最大回报的好机遇. 如果我 5 年前不离开阿里, 待遇和职位都会很不错.
• 做技术岗位的薪资始终是低于管理岗位的. 大公司相对有成熟的技术和管理体, 不会有这个问题.
• 如你所说如果遇到领导发出错误的决策的确会很痛苦, 不过我很幸运我的领导都很不错. 而且一些决策我也能跟他们协商

对于你的问题 ,我建议是沟通解决, 如果沟通不了. 你可以记录下自己的意见和看法, 让团队和领导知晓你的担心, 然后再跟团队和领导非常快速的"错"下去.

跟着团队一起错, 也是一种值得尊敬的心态. 况且对错不一定是绝对的. 有可能你的想法也是错的.
这种叫试错. 试错不仅是表明你愿意跟领导和团队一起成长, 也能尽快的验证可行性, 从而更早的止错.
我以前也知道一些事情做错了最后还拿奖的团队, 以及个人做错了领导也要强行颁奖挽回面子的事情.
试错也是一种有担当的行为, 这也是不错的经历, 走过的弯路也是一种人生财富.

#66 楼 @wixed 这也是典型的两大管理问题. 体力劳动为主的业务测试部门, 会倾向于多招人抬高和巩固自己的地位. 脑力劳动为主的部门, 会愿意多构造技术工具和平台创建自己的技术门槛和核心业务以树立起部门墙. 不能说一定是对还是错, 要看产出是不是足够有效, 足够大. 结果导向.

企业也不傻, 一般都是先找齐人手用低级的生产力快糙猛的拿到业务搭起来架子,然后再逐渐在"飞行中换引擎", 不断改进. 如果是纯做手工测试, 一般会出现平时很忙, 天天加班加点. 但是到了不忙的时候, 一半人就被裁撤了. 结果还是要忙起来. 业务是贪婪的, 他会不断的甩掉赘肉. 除非你运气好跳到什么垄断企业, 产品再差再慢也无人替代, 人再多再傻也有铁饭碗. 当然这就不是互联网行业了. 超出我的理解范围了.

#55 楼 @safe @hu_qingen 目前测试行业的现状不是我们自己造成, 相对于研发行业不断追求技术和架构的改进, 咱们测试行业对测试技术和测试架构的思考太少了. 目前受的累不过是前人不思进取埋的坑. 再不改进一旦业务发展平稳, 测试的地位和饭碗都不容易保住的.

在业务高速发展的时候, 企业会雇佣较多的人手做手工测试, 较少的人数做测试技术和架构改进, 一旦业务发展平稳, 首先被裁撤的是无法有自己业务和技术门槛的人. 手工测试的工程师群体首当其冲. 会裁撤大部分, 仍旧会保留少数的业务精英.

最近大佬们不是都在提互联网的下半场吗, 一般游戏结束大浪褪去, 就知道是谁在裸泳了.

#56 楼 @Lihuazhang 我把技术单独拆分出来吧。以免讨论太多歪楼

#58 楼 @luxiaofeng 有道理，这点我也愿意深入交流。猜到会有这种观点出现了。我的理解是这样的，黑猫和白猫能抓到老鼠的都是好猫，但是你如何解释同样都能做测试的人，为什么大部分企业会更希望要学历阅历和技术较好的人？算盘和计算器都能算账为什么现在所有的小餐馆都用计算器或者电脑自动结算？用 asp 也能开发网站为什么却找不到工作？

当你选择了一个落后的工作方式，工具或者技术栈的时候，不仅公司会被拖累，连自己的发展都会被波及。如果不能持续的改进自己，就会被行业淘汰。

我列举的技术，每超过一层对公司的收益都会越大，也能提升工作效率。每深入一层对质量的理解也会深入，还能看到更大的发展空间。当技术做不到做不到就降纬用低级生产力解决问题，当有更好的方案就要及时升纬提升效率。

还有一点是这些年大家老是对立技术和业务，其实在一定的层次上业务和技术是有个非常有价值的结合点的，在这个结合点上能够非常完善的区分出代码的变更对业务变更的影响范围，能通过技术的方法判定基础功能的正确性。这一层在覆盖率的下一层。做到这点我们就能对业务建模，积累业务数据形成 QA 稳固的业务。这样才能让最后的手工测试压力降下来。

类似的技术和思维方式还包括全链路的压测，流量对比等专项手段，也能在很短的时间保证系统的质量，这样产出的产品质量会好很多，留给 qa 最后的质量保证压力就会小很多。

最后公司赋予你的使命你忽略了一点，除了让质量更好也要让质量保证的效率足够快。

#48 楼 @r455678 多谢提建议, 这块可以交流下. 我举个例子, 如果你的后台服务器有一百台, 你是没法去 top 或者用 nmon 的.
ganglia 之类的系统是监控大量服务器的, 他的指标和绘图一般会延迟一分钟, 这在性能测试上是足够用的. 使用监控系统最大的好处是可以把 qps 和 cpu mem 的指标关联起来进行更好的对应分析. 比如 gatling 和 jmeter 都支持同步把结果发送给监控系统. 就是为了能更好的分析.

至于那几个层次, 你可以看下我一开始的注明.

我简单分了下层次. 层次没有高低 只是在满足第一层后人们会逐渐的开始探索更高的层次.

这是一个工程师成长的若干阶段, 不存在替代关系. 分别对应的是工具, 平台, 应用问题定位和平台问题定位几个方向.
多一层少一层, 甚至跨层成长的也很多.

#46 楼 @safe 这个事情有点像设计模式和架构要解决的问题。变化是主旋律，架构，设计模式，版本管理做了这么多的改进其实就是为了分离变化和固定的东西，让变化更快更容易维护，让不变的东西更稳固可复用。这个问题不仅是 app 端存在，接口存在，甚至单元测试也存在。这种对变化的抱怨很多年前在代码层面就有人吐槽了，也有了很完善的解决方案。以你们的接口为例，你们需要分离做可测性提升，构建两层接口体系，对基础接口做自动化回归，对不断变化的新接口做人工测试，或者借助类似自动生成用例的工具做快速的接口测试用例编写。这样才能构建基础稳定的质量防护网。底层稳定了变化就可控，业务压力就会下来。现在测试的一个痛点就是没有积累性，对产品反复测试很多次就因为一行代码变更还得大部分回归，这是不合理的，也跟不上业务发展的需求，ui 自动化也是错的。没有可测性提升和分层的自动化保证，这种痛苦就无法终结。

#20 楼 @dongdong 还是加精吧. 思路不错. 我一开始也发现没源代码. 只看到几个 cshtml 文件.

#72 楼 @guaixiaomei 配置文件不兼容. 有些配置项名字修改了

#75 楼 @guaixiaomei 他貌似没没找到你的 backButton 配置, 或者 backButtton 里面的返回按钮都没找到. 才会报错. 你确定@name是对的吗, 会不会是 label 什么的.

加精理由: 思路不错,值得借鉴.

本来要加精的. 不过看了你的源代码. exe 和 dll 都进去了. 你把源代码和发布的东西区分下吧. git 里面放源代码. exe 和 dll 放到单独的下载包里吧. 好像 vs 没有像 maven 这种构建工具. 发布的确不容易

#34 楼 @ycwdaaaa @safe 跟业务形态和技术架构有关. 如果产品能做好分层. 比如包括 app 自身都能清晰的分出 mvc 结构. 那自动化是可以的. 再一个是以各种电商活动为主的 app, 活动几乎一周一变, 也的确做不起来. 但是回归测试自动化是肯定能做起来的. 需要推动研发提升可测性, 推动分层自动化. 和一些专项测试的自动化.

大部分人容易在错误的基础上做自动化, 古人也说过"勿在浮沙筑高台", 架构的可测性和技术选型很关键. 不然就会失败.

#25 楼 @safe 打字打的快, 错别字太多了, 思维也秀逗了.