关于避免加班这个事情,很多人讲的都是如何安排好自己的工作,觉得只要自己合理安排了就不用加班了,加班的都是效率不高的。
其实很多时候不是这样的,上级给你分配任务的时候,通常都是按照 1.2 倍,或者 1.5 倍正常工作量来安排的。
也就是说一周的任务,其实是安排的 7 天的任务,而不是 5 天的任务。
这个就只能希望自己去一个不加班的公司了,难啊。
京东加班不?华为加班不?小公司加班不?
感觉再加班,头发都要掉光了。。。
看到有 44 岁的前辈,我等刚 40 的就放心了
回来给我们讲讲课吧
这个问题老实说我回答不来。
不过我可以回答另一个问题:我确实认识到了另外一名测试的很多地方都比我更优秀。
我都拿小本记着的。
我们也是遇到类似的困难,自带一个密码控件,无法输入。所以做不了自动化。
这种自己的 APP 怎么办呢?有没有什么办法?
优点是有测试责任感
缺点是不擅长人际交往
请帮我保留前排座位,谢谢。
我一个同事先离职,但是手续没办完。就委托我去问一下后续怎么办。
我刚好过去总部,就去问了一下离职手续怎么办。当时也答复了我。
回来研究所这边,我们这边的人事找我谈话,说我:在公司问离职手续怎么办,影响公司的声誉(说是刚好那天有新员工什么的入职)。巴拉巴拉。。。
我当时年轻气盛,一拍桌子,说:不干了! // 绝对没有说老子不干了
然后就辞职了,找了 4 个多月的工作,才找到新工作。
这个很多时候测试人员会受限于自己的工作环境。
比如我们的接口返回的消息都是 json,所以我们现在都是直接用 rest assured 的 jsonPath 来获取的。如果是只返回一个值的,直接放在 return 里。如果要获取多个值,则写到一个字典里。
如果要我考虑其他各种可能,我也很难回答出来。
关于第一个问题,接口测试要做到什么程度,也是我一直以来的困惑。
如果简单的说凭经验肯定是不行的,或者说根据实际情况我是不行的。
问题在于,在一般的情况下,接口自动化测试用例,要做到什么程度?
或者说:从多细的地方开始划断,该手工测试的归手工测试,该自动化的归自动化?
期待有大牛来根据实际的案例讲解一下自己的经验。
从公司或者项目来讲,目前项目处在频繁变更阶段,根本不应该做 UI 的自动化。不要为了自动化而自动化,任何事情都要讲投入产出比的。
从个人学习发展来讲,不要放弃学习自动化测试。
另外,楼主也说了自己的目的,要减少自己的手工测试量。这个不一定要去做什么完整的自动化的,你现在做的这个东西,真的减少了你的手工测试吗?
也许一个简单的脚本,一个简单的辅助工具,反而效果会更好。先仔细想想什么地方天天重复的做,可以改进嘛。
老实说只会基本的 linux 操作,简历上也只能写会常用的 linux 命令。
那么我这种人,平时使用什么命令来帮助自己的测试工作呢,也算自己总结一下吧:
1、tail -f、grep、vi 等命令查看日志;
2、scp、ssh、telnet、ftp 等命令远程拷贝文件、登录系统;
3、用 linux 的命令,启动、停止 linux 上的各种软件,比如数据库、容器;
4、编写一些简单的 shell 脚本,用来配合 jenkins 来做持续集成;
5、使用 top 命令查看内存使用、CPU 占用;
6、使用 tcpdump 进行抓包;
7、使用 svn 命令和 crontab 进行版本管理和备份;
支持第三方应用安装,本质上不是 app 本身代码的测试吧?
这个是否需要验证运营人员是否正确的去更新第三方应用(比如应用宝上的最新程序)?
我们就出现过,pp 助手自己不知道从哪里获取了我们公司的软件,并放在上面,导致用 UC 安全下载的版本都有问题。
资源编号这个我有点理解了,可能我们公司的 apk 没那么复杂。所以还不存在这种根据资源编号更新部分资源的情况。
我们只是一个普通的 apk,没什么状态的。
多谢讲解,很多思路以后都可以参考啊。
看不懂 jiazurongyu 老大写的内容啊,这个对小白来说不明白是怎么回事,比如:
支持第三方应用
本地校对 Version_id,平台校对 Version_code
业务面覆盖后,根据 checklist 高版本不会影响低版本
求指导一下,多谢
作为一个工作了超过 15 年的传统测试,我也来说几句话吧。
首先我没有走上领导岗位,在一家大公司待了很多年,和很多一起进公司的同事一样,一直在底层。
然后也没有成为测试大牛。楼主问的这些问题,大多数都说不清楚。
关于公司为什么这样设计流程,可能也只能说一下流程不好的地方。关于产品的内部分层(现在的产品我还真知道,但是我以前测试的产品,公司根本不让测试接触到很多东西,也反感测试去接触)。
才开始做测试的时候和现在有很多不同,公司做性能测试,板卡拔插,选了两个最壮的小伙子,2 个小时轮换一次,去手工拔插。测试电话,每个人控制八部电话,同时拨打。
最开始,一直认真的工作着,认真完成自己的工作,加班加点毫无怨言,老大的评价是细心,很适合做测试工作。
当时的很多测试,大部分工作是手工测试,也就是现在说的业务测试。
在一家大公司里,产品经常变化,流程高高在上。大部分的时间都花在熟悉产品上了。悲哀的是,并没有成为产品的大牛。亲眼目睹了各个项目从产生到消亡,自己所学习的东西,包括记了好多笔记的 “经验” 最终都毫无价值。
后来也觉得这样不行,然后要求去做测试工具开发。那个时候还没有所谓的测试开发的说法。也就是去写写挡板什么的,后来也做 QTP 的自动化,用用 LoadRunner8.1。不过都不精通。因为只有项目需要的时候才会用一下。也许一年就用那么一周。
现在很多测试开发,其实很早开始就走对了路,对于开发能力,各种新技术都很厉害。
而没有及时走对路的人,或者要换方向的人,或者没有得到一个很好的平台的人,其实路是相当艰难的。
他们必须要从头学起,试图去和那些已经在正确路上走了 3 年、5 年的人竞争。
有人问:你有 15 年经验,应该比 10 年的更懂架构,更有思想。但是很多时候,工作 5 年的人会明显比工作 2 年的人强,但是工作 15 年的人很难说就比工作 12 年的人强。
我从 StuQ 下载了一个 “测试技能图谱”,知道最悲伤的事情是什么吗?
这里技能图谱上,没有任何一项 “测试技能”。只有各种各样的新技术。没有一条技能是如何更好的发现 bug,如何更好的去设计测试用例。
测试工程师多年以来,所做的事情不就是发现 bug 吗?争取用最少的时间去发现最多的 bug。但是现在这些都落伍了。
新世纪的测试开发同学,是在一个完全不一样的维度上和传统测试人员竞争的。
楼主说的大多数东西,我都赞同,警钟也敲得很好。不管过去如何,现在大家都在同一个行业里,年龄大不是你不懂的理由。有小孩?可以半夜起来看书。什么都不懂,可以向年轻人学习。老年人需要付出更多来拉平差距。我也在学 jmeter,在学 java,在学 appium,在学 rest assured,在学移动客户端性能测试。。。
我唯一不赞同是,迟暮、未老这种事情,暂时还不到楼主说的时候,请让我们老年人先来说,谢谢。
奔五的末路不知道往哪里奔
啊!明白了。我回去督促开发修改的,修改为兼容大小写。
我这边检测到的是一个 timestamp 字段,会在使用了 Fiddler 后,变成 Timestamp
你说得太对了。在版本质量很差,开发也不配合的公司做测试,很快人就会毁了的。
因为你提了反正也没人改,开发还觉得你多事。你的测试技能、水平都会急速下降。
多学习,争取早日跳槽吧。
这种情况,可以找更高层的老大反馈。
由于服务器问题,导致无法区别缺陷和正常的 “缓慢” 响应甚至超时。
这样就没办法确定是否有缺陷率,很容易遗漏测试故障,造成版本质量问题。。。等等等等。
如果老大坚持说没有钱更新机器或者没法解决,你也只能认了。
究竟测试只是公司研发体系中的一份子,假如工地上都是用独轮车搬砖,你也得适应。
徐老师好,请教一下这个函数的用法啊,多谢多谢。
List getList(String path, Class genericType)
就是官网的那个例子:
{
"store": {
"book": [
{
"category": "reference",
"author": "Nigel Rees",
"title": "Sayings of the Century",
"price": 8.95
},
{
"category": "fiction",
"author": "Evelyn Waugh",
"title": "Sword of Honour",
"price": 12.99
},
{
"category": "fiction",
"author": "Herman Melville",
"title": "Moby Dick",
"isbn": "0-553-21311-3",
"price": 8.99
},
{
"category": "fiction",
"author": "J. R. R. Tolkien",
"title": "The Lord of the Rings",
"isbn": "0-395-19395-8",
"price": 22.99
}
],
"bicycle": {
"color": "red",
"price": 19.95
}
},
"expensive": 10
}
能否使用 getList 方法,获取到一个 List呀?
这样会报错:
List bookList = JsonPath.from(jsonString).getList("store.book", Book.class);
Cannot convert class java.util.HashMap to class Book.