JMeter 写好断言不就可以直接判断服务是否正常了么? 然后配合 Jenkins 在失败的时候发邮件不就可以了么？为什么要写 Shell

我觉得楼主说出了很多人的心声，我也很同意@yangchengtest的 “我们普通人离努力都不一定有结果的阶段，还差得太远” 这个观点。

其实努力也是要有方向的，我比较世俗哈，在我力所能及的范围之内没见过测试做到很高的职位，所谓的测试专家也没看见几个。相反，大部分的测试经理，研发经理，甚至总监都不是技术最强的。我觉得技术本身就是敲门砖，你做到 100 分可以成为专家，达不到 100 分，那就要高于 60 分。剩余的时间应该致力于提升软实力，情商，沟通。

我非常希望大家能多关注技术之外的事情，现在公司，社会更加需要综合实力强的人才。

在生活中，你欣赏什么人，羡慕什么人，那你就可以朝着这个方向努力。楼主如果觉得不是向往技术上发展，也就别听什么 “多看看书” 这样的建议，这在我看来和” 多喝水 “没啥区别

#1 楼 @350705144 app 查到原因了。 app 有内存问题

这是虚岁。。。

#8 楼 @purplerain 如果不是，你自己 + 上测试代码

#8 楼 @purplerain 通过位置进行滑动是一种方法。

我刚才观察了一下，发现你这个控件是不是初始化为当前时间？ 如果是的话可以使用 adb shell date -s “你要的时间” ， 然后打开 app

#2 楼 @purplerain 能通过点击选择时间么？ 如果可以就 OK 了， 通过 getChildAt 和 ChildCount 等组合，可以选中想要的时间。 如果需要滑动， 可能需要根据屏幕和这个控件所在的位置计算滑动相对的位置

能使用 UIAutomatorViewer 看下这个时间控件么？看下如何实现的

如果是自己的 app，写代码即可。 在生命周期中进行时间采集

公司的规模多大啊？项目经理能做到正规么

我的做法是模拟一个用户连进行远程连接的设置和操作，在每个步骤中进行用例的设计。在用例的设计中去考虑不同的方向，就像你说的兼容，安全，需求层面。 如果有时间可以使用探索测试的一些方法进行针对的测试用例构思。传统的测试用例方法也要熟悉，设计 case 中也会用到，这些方法帮助我们在设计中将有效 case 尽可能覆盖。
测试用例覆盖率我觉得真的是衡量不了的， 不同的经验不同的背景考虑的角度是不同的，比如 windows 的远程连接，很多人考虑的是功能， 有丰富网络经验的人可能会优先考虑网络质量对功能的影响等等， 所以我觉得一个复杂的功能，让其他的测试工程师进行用例评审是能够提高覆盖率的。一个功能，10 条 case 如果不漏 bug 就是高覆盖，100 条 case 如果漏 bug，就是覆盖不全，所以太难衡量。

用例设计其实更依赖于经验，对业务的理解，尽管方法可以传授，还是需要你自己多多积累。有一个非常重要的方法就是你一定要多了解多使用。上至编写代码，下至组装电脑，很多看似不相关的技术，都能帮助扩展思路，设计更多的有效 case。

@xdf 我觉得任何测试都是业务测试，因为都是面向用户面向需求的。 只是测试的手段不同，有的适合使用黑盒，有的适合自动化，但目的无非是一个"让用户用的爽"。 所以， 我也不觉得有 “技术情怀” 这么个概念。就好比需求是制造一个凳子，最重要的是凳子质量过关，坐的舒服，符合用户需求。 至于是手工打造好，还是通过制作生产线来提高生产效率好，完全看情况。
我觉得测试就应该懂技术，懂代码， 这不是情怀， 是基本功

赞一个, 打算好好学学

如果你想做好测试，你需要付出比别人更多的努力，因为你的专业确实是弱势，所以你在入这行之前要想清楚自己真的了解测试么？真的愿意付出这些努力吗？ 如果只是要一份糊口的工作，日后你可能面临着被淘汰的可能，所以想清楚是否应该做测试。

想想自己的优势在哪里，喜欢什么工作，适合什么工作，再做决定。虽然你年轻，但最好还是能一次选择一个相对正确的行业。

#3 楼 @m13890 多接触人，多看书

#24 楼 @brucezhang0 回复完之后我又仔细想了想你的评论，我觉得是很有道理的。

1. 也许因为我站的不够高，所以我觉得自己看到的风景就是全部，其实只是冰山一角。
2. 我也不应该为了自己那点小小的面子而不去天天问 PM。我要做到是天天和 PM 沟通，直到不需要主动问也能得到 PM 的告知为止。
3. 信息不对称其实是两个方面的原因，首先可能是 QA 并没有给人重要地位的感觉，针对这点我会持续的学习并进步。其次，可能是 PM 等意识不到质量的重要性，这个应该是通过积极的沟通来帮助别人意识到。

若有激烈的言辞冒犯了，望见谅

#24 楼 @brucezhang0 首先说信息不对称，如果你很忙你真的会不知道一些事情，比如商务合作直接找 PM，运营需求直接找 PM，很多小的功能或者这次的预装版本就直接找开发做了，不会通知测试的。另外，不知道谁会天天抓着 PM 问，有啥要测试的？我觉得做工作吧的确是有方法的，但也是有个人自尊的，我可以主动去做一些事情弥补别人的不足，但绝对是有度的，不知道你能否理解我这句话的意思。

见招拆招的意思是，如果明天发版今晚就加班测。有需求就改，改完就测。不考虑测试的时间，不考虑开发的时间，不考虑流程，一句话，解决问题就好。这是我理解的见招拆招，我不想做一个执行者，既然在创业公司，我就有改进流程推进产品的义务，很明显不是经验的问题，而是大家的理念不同。

再说需求变化，我是认同你的观点的，就是开发的水平也要提高，也要有产品的意识。

每个人看问题的角度不同，所以得出的结论不同。老板关心的是产品的用户，产品的方向，其实他不 care 你测试干的如何，如何来完成，更不 care 你用了什么工具什么方法，所以你觉得老板是对的。如果你站在测试的角度来看，你就会觉得难处和槽点比较多，不是仅仅提升自己独善其身就 OK 的。 这位同仁，虽然可以站在公司战略的角度看问题，但别站着说话腰不疼

#9 楼 @t880216t 建议大公司和小公司有条件的话都体验下，然后找个适合自己的

#18 楼 @wudamyw 我觉得自动化是保证敏捷的必要条件之一，不然敏捷很容易流于形式，测试人员淹没在铺天盖地的测试中

#16 楼 @zd987 比较尴尬的是快速的迭代自动化跟不上，就变成了伪敏捷

#8 楼 @windanchaos 其实我也希望开开心心的学新技术，有版本了测试下然后交付。但在这种流程下，想让自己和测试同仁轻松点，也只能努力去改进了。而且我始终坚信，承担更多的责任，会有更多的回报。只是，我现在不知道是否有更好的方法去改进了

#6 楼 @shadow000902 感觉应该联合内部有识之士一起联名上书，哈哈

#7 楼 @monkey 恩， 这是我的第四家公司了，如果不是有质的提升，其他的公司很难对我有吸引力。的确最近的半年多，自己的进步速度慢了很多，一方面是工作中大量的时间用在了撕逼及改进，一方面也是任务也能胜任了，学习动力减弱了。 之后的日子，我会多接触新的技术，同时也尽量推进流程吧。。。

#2 楼 @oscarxie 我们的老大来自 google, 比较崇尚自由，不喜欢流程这种规范的东西来束缚工程师。这里先不讨论这种观点的正确性，最起码有一点，我们的 code 质量远远没法和 google 的相提并论，这样又没有流程的保证，测试工作起来就很尴尬。

我知道想说服一个人要有理有据，但是吧我现在没法去量化这个使用流程的好处，难以匹敌老大的口若悬河。

#3 楼 @testor 感觉大部分公司都差不多

—— 来自 TesterHome 官方 安卓客户端