看着图慢慢吃补品。谢谢 kasi
1.编程一点儿也不难,写出一个简单 app 花的时间比大学英语过四级掌握的知识要少好多。
2.女孩子编程也不难,我们 team 最近有个女孩子刚转了 iOS 开发,做得非常好。她原来的专业还不是计算机。
3.开发肯定会比测试平均薪水高。
4.做测试也得会开发,不然走不远。
5.综合 1、2、3、4 能留下来做测试的是真爱,或者是真对开发没兴趣。
6.各位女神节日快乐。
#27 楼 @seveniruby 竟然还当过包身工。
#37 楼 @linkenzhou 论坛留贴吧,咱们慢慢熟悉:)
#35 楼 @a754354300 “作为一个测试菜鸟,一直只停留在系统测试,每天工作都有危机感,一年下来感觉啥都没做,没有给公司创造任何价值,只是开发的附属品”---
系统测试也是大有可为的啊。问一个问题:单从系统测试层面,你觉得你们你们能够有效发现潜在的问题么?自评能打多少分:)
觉得你身边缺一个好老师带你,刚入行其实有人带很重要的,我入行的时候基本上没人带,其实走了两三年弯路。
现在挺好的一件事儿是,网络资源丰富,好老师不见得非在身边。
good luck 兄弟。
#34 楼 @sunflower 1.你能发现问题,其实就是非常好的事情。2.从你的角度上来看,测试无法力挽狂澜,改变各种不合理。这很正常,很多是我我也有很多看着觉得不好的地方无力改变,但总还有能做的事儿。3.不爽就是机会,怎么抓住它不是一句两句能讲清楚,因为 team 形态差距很大的,但一定有办法。4.你们有负责流程改进的同学么?可以多找他聊聊,看看他的想法是如何的,另外,有不少相关的书和文章可以看看的,会有帮助。你理解一个问题越深,越有可能为解决它出更多的力。5.team 中如果有一部分不合理的流程和工作方式,但是产出进度、质量还可以。那就说明主要矛盾不是太深,大伙儿已经磨合到一个相互适应的状态了,再想动其实不容易,如果没有太扯淡的地方,也许你可以先睁一只眼闭一只眼,把自己手头的工作做得更好。6.你觉得 team 太 low 了,你有 idea,就只说出来吧。7.你觉得 team 太 low 了,无法忍受,又改不了,这样是对自己的消磨,问问自己内心,看看能做啥吧。 good luck
@Test
public void testGetUser() {
try {
HashMap map = new HashMap();
List> list = new ArrayList>();
map.put("a", "test");
list.add(map);
StringBuffer body = new StringBuffer();
body.append("{\njava.util.HashMap map = new java.util.HashMap();\njava.util.List list = new java.util.ArrayList();\nmap.put(\"a\", \"test\");\nlist.add(map);\nreturn list;\n}");
QMock.setMethod("com.qmock.demo.UserDAOImpl", "getList", body.toString());
userDAO = new UserDAOImpl();
System.out.println(userDAO.getList());
System.out.println(userDAO.getList().get(0));
System.out.println(userDAO.getList().get(0).get("a"));
assertEquals(list, userDAO.getList());
} catch (Exception e) {
e.printStackTrace();
}
}
这个用例不是要测试这个方法?
public User getUser(Integer id) {
return this.user;
}
还是单纯的展示 mock 的实现?
其实我想说的是:Spring 框架下有不错的框架。如果你想展示 mock 的原理的话,那其实咱俩就说差啦 :)
Spring 有自己的 testFramework,最近用这个,所以学了一下,单元测试和集成测试都很便利。
http://docs.spring.io/spring/docs/current/spring-framework-reference/html/testing-introduction.html
另外,如果要 UserServImplTest 中的 getUser,其实应该 mock 的依赖是 UserDAO(因为依赖的外部数据库,违背了单测原则)
UserDao 算是个 bean,所有 bean 在声明变量的时候都该用@Autowired 在 Context 里管理起来(也许你用配置文件实现了,但代码里没有体现),这样,用 Spring Testframework 就能很方便的 mock 被管理起来的 beans。这玩意儿配合其它 mock 框架很好用。mock 框架都差不多。 我选用的是 mockito。
#30 楼 @liuxiaosea 开发,运维,产品,或者所有干活的人可能都是这么想的。。。也许我说这句话的时候是 这山看着那山高。
学习了! 感谢分享。
挺好的讨论,不过火药味有点儿浓啊,这大过年的:)
每个人成功和不成功路径都不大一样,是自己性格,能力,外部环境,时运综合了的结果。
至于那种路线对,其实也没有绝对的正确和错误。不同组织测试参与的工作范围还有工作方式差别其实特别大,要求的各个维度的能力其实大有不同。
结合个人发展,其实也会大有不同。
比如说,你想在这个企业一直混。其实首先的就是要适应这个企业先活下去,有情怀想改变这个企业甚至行业也得先站稳脚跟再说。那这个时候,沟通,人脉,企业的业务领域知识可能会很重要,IT 能力同样很重要,但如果不是科技派的公司,就不见得是最重要的了。
如果说,你不知道的未来在哪里,但想变得在市场上非常有竞争力,哪里都愿意要。这时候技术就很重要,因为市场的风向标目前是越来越倾向于技术的。
如果说,你特别迷茫,那就先从解决手头问题做起。需要技术就死搞技术,需要沟通就死搞沟通,需要啥就死搞啥。解决问题的能力才是根本的能力。这么说还是有点儿抽象。举个例子:你发现开发提交上来的代码特别烂,一测试就跟筛子一样净是窟窿。你如果能够推动流程上改变,比如说搞定开发自测,测试有准入,没准就能解决一部分问题,这该属于流程、沟通范畴;如果你发现开发自测了,只好了一点儿,代码根本上还是不行,你觉得需要推动评审和单元测试,能推动,还是流程、沟通范畴;你发现无法推动,那就想为啥无法推动,这时候发现主要有 3 个原因,1.进度太紧张;2.开发人员不会单元测试;3.开发人员不会评审,也不愿意评审;面对第 2 个问题,开发人员不会单元测试你就要解决:1.为什么不会?培训不到位么?2.学习需要多久?3.开发人员有热情么?4.如何推动这件事儿发展。。。。。最后你会发现,这是一颗问题树。很多树的最末端有技术领域的,有业务领域的,有过程领域的,有企业文化领域的,有。。。。 其中很多跟传统的测试职责不沾边。要做多少呢?能做多少呢?做了有什么用呢?回报是什么呢? 不同企业有大不相同。 你可能转型为项目经理,你可能转型为架构师,你可能测试做得很棒变为测试部门的头,你甚至可以变成 CTO(有挺少的例子,比如段念),你也可能做了也不落好还落一身骚,你也可能混不下去了。 一切的一切全在你自己。 学会从多个维度的看问题,聪明的解决问题才是关键。所谓的坚持什么什么路线,什么什么对,全是有前提和原因的,不要盲目的跟从和相信。新同学多看,多问自己的内心,多埋头做事儿,时间长了自己就有杆秤了。不然看再多也没毛用,因为纸上得来终觉浅。 这是我的理解。
#27 楼 @hua666777
别脱离了实际需求做我觉得会不错。
#5 楼 @lihuazhang 钱少,擦屎,心烦。
要人家爆公司的还匿名也不厚道。楼主不想爆就别爆。毕竟圈子很小,如果是大公司有可能被算计影响后续找工作。多留意一下招聘吧,现在机会也很多的,愿你找到好工作。别干删代码的傻事,有可能惹上官司。这样不被善待,随便交接一下得了,留下精力好好找工作。
#7 楼 @monkey 延胜说的应该是正确的。代理 https 的原理是,代理服务器代替客户端和服务器建立 SSL 连接。这个代理服务器也不错,里边有一篇文章介绍了原理。 http://docs.mitmproxy.org/en/stable/howmitmproxy.html#explicit-https
何必自寻烦恼呢:)
#8 楼 @su_qianai 外边很多机会的,不用太忐忑,慢慢增强自己的实力,一两年以后就会非常抢手啦。