推荐这篇日记的豆列
······
&(59人关注)
&(181人关注)
&(85人关注)【岗位职责】
负责乐信集团部分产品业务测试，参与项目全流程，把控产品整体质量；
参与项目的需求分析，关注项目需求的可测性，并能预先评估项目的风险；
负责项目的测试分析、测试用例设计、测试执行、测试质量评估和报告；
对软件问题进行跟踪分析和报告，推动测试中发现问题及时合理地解决；
负责业务自动化测试建设工作，能够针对日常测试提出自动化思路并实施建设；
负责业务专项点测试，能够挖掘业务痛点，深入研究针对性测试推动产品质量；
【岗位要求】
计算机或者相关专业，本科及以上学历；
2年以上测试经验，对软件测试流程和方法有良好的理解和积累，熟知常用质量控制手段；
熟练运用测试理论方法及了解其原理；
熟练使用LINUX/UNIX操作系统；
掌握至少一门开发语言(如C、C++、java)，熟悉python，shell等脚本语言;
有相关自动化测试经验者优先，熟悉自动化思路，参与过相关框架和工具开发；
了解服务框架，有互联网金融测试经验，后台相关测试经验者优先；
热爱测试工作并具有高度的工作热情和敬业精神，具有良好的沟通交流、团队合作、抗压能力。
有意向可将简历发送到：
非猎头，求贤若渴，亲自上阵来挖，欢迎交流。
薪资区间为15k - 30K， 看具体能力和级别。
乐信集团，旗下分别有分期乐、桔子理财、提钱乐和鼎盛资产，公司发展迅猛，从创业思维蜕变和转型，现对研发质量非常重视，技术和业务提升空间大。
「保留所有权利，禁止转载」
头像，排版，薪资范围均没，何来的诚意啊？
必须是本科，大专行不行？
一年半可以不，现在也是做的互联网金融测试
屏蔽了该贴
请增加头像和薪资范围，文章请用MarkDown格式排版
已按要求修改， 请审核，谢谢。
能力ok， 绝对可以。
也欢迎来交流
公司地址能发下，网上查出来多个地址？
； 查多个是不是公司内产品站点， 例如分期乐
乐信集团网址： ，
大家可以初步了解。
开发转测试可以不？
欢迎~， 可以测开岗位
非常感谢小伙伴们儿，已收到了一些简历，今天我会尽快处理，可能不会一一回复，大家谅解哈
谢谢，简历已经发送！！！
后方可回复, 如果你还没有账号请点击这里 。
yijunli (yijun)
第 13044 位会员 /
共收到 18 条回复测试工程师和开发工程师怎样才能最好的合作？_软件测试工程师入门_领测软件测试网
测试工程师和开发工程师怎样才能最好的合作？
发表于：来源：Csdn作者：测试仔刘毅点击数：
测试工程师和开发工程师怎样才能最好的合作？础信息表pol_main，大约有500万条记录，算是一张中等数量级的表，它关系着大量的保险业务操作和相关查询功能。这张表的pol_sts(保单状态)字段的cardinality(基数)是26
　　从一张表的索引想到的
　　我们有一张保单基础信息表pol_main，大约有500万条记录，算是一张中等数量级的表，它关系着大量的保险业务操作和相关查询功能。这张表的pol_sts(保单状态)字段的cardinality(基数)是26，这个字段上有个独立的索引;另外一个常用的查询字段plan_code(险种代码)的cardinality在1000以上，并且在逐年随着新业务模式的出现而增长，该字段无索引。参照这两个字段，数据都是非正态的不均匀分布，而且这两个字段都是非常频繁的被查询语句用到。无论是从selectivity还是cardinality的角度考虑，在plan_code上建索引都要比pol_sts好，但是为什么没有这样做呢?我曾就这点疑问咨询过资深的和架构师，他们的观点是一致的：pol_sts字段上有索引是因为最初在做表结构设计的时候就做了，而当时没有考虑plan_code这个字段，估计当时在售险种只有几个吧;而现在不在plan_code上建立索引，主要是因为这个表、这个字段被引用得太多，没人能够评估得清楚这样做的风险有多大。
　　要么删除pol_sts字段上的索引，要么建立plan_code字段的索引，最不济就是建立这俩字段的组合索引，看起来很简单的事情，实际操作起来却有着这么多的顾虑，为什么?因为没人愿意去挑战系统运营的稳定性，拿这个做赌注付出的代价的确是很大的。对于他们的担忧，其实我解读出来的信息就是：
　　1、 对软件的质量保证作用信心不足，不论是开发自己做还是部门去做;
　　2、 测试的成本太高，为了一个的优化，要牵动十几个人去测试，换来的质量提升很有限，换句话说，可能是测试的手段不够经济、不够高明导致了整个行为的ROI不高;
　　3、 总之，没有好的质量守护，没有好的，开发不敢轻易修改他们认为软件中敏感的地方。
　　既然coder对自己开发质量的衡量如此依赖testing(注意：不是tester)，那么他们是否为testing创建了足够好的环境呢?未必!再举个例子，我们公司的应用绝大多数是script/html++oracle这么三层。大部分人都知道SP代码易发布但是相对于代码来说，测试更麻烦一些;反之代码的发布都要走中间件的部署，需要起、停应用服务，看起来会让系统服务不连续，但是测试更加简单。而我们因为有固定的版本发布计划，所以SP代码在发布上的优势其实已经不明显了，但是大家还是热衷于写一些逻辑复杂的、相互调用繁多的SP代码来实现我们的业务，这是为什么呢?
　　刚毕业那会，很幸运在神码融信的东亚银行核心项目做QTP的测试试点和推广工作，真可谓是不舍昼夜的忙碌。早在那个时候，我就梦想着开发如果能够就一定可以建立标准的UI组件库，实现标准的拖拽式开发，不会随意命名一些组件;这样脚本开发和维护就非常方便，很容易追得上甚至超过编码的进度。可惜这对我来说只是一个梦想，从未被实现，现如今在带领大家一起做/ Driver和WatiJ等工具的脚本开发同样面临这种问题。很多页面组件没有id、name，coder们在修改的时候变动随意性也很大，实现方式五花八门，这样测试脚本的维护工作量也是非常大的，经常因为人力和工作量的比例不协调导致测试脚本维护不及时，运行稳定性不好。这样就意味着测试的投入需要增加而质量却不高，自动化的ROI呈指数曲线下降。有同事说：&测试自动化没有开发的帮忙就等于是测试自己在YY&。虽然有点夸张，但是意思很简单：如果coder如果故意不配合的话，的确会因为可测性遭遇很多测试脚本开发技术实现上的问题，所以说低质量的应用代码能锻炼出自动化测试开发高手来，但是伴随着这种锻炼方法的是可耻的资源浪费。高智商的coder们想不清这么简单的问题么?当然不是，那他们为什么没有提供更具可测性的代码给tester呢?
　　反过来tester对coder处境的考虑也是一样不够的，例如，很多tester不考虑coder的工作量，死硬地按照流程规范要求coder首次必须移交所有的SRS，拒绝增量迭代开发和移交;这样其实也是在逼迫coder们权衡之后移交一堆不可测的代码过来。再例如，tester只顾埋头想自己的测试设计和执行，不愿意主动帮助coder想设计和实现的方法，认为这不是自己的本职工作或者认为自己不具备这个&资格&去对coder的工作指指点点。高智商的tester们难道不知道自己这些不合理、不积极的做法最终会给自己带来更大的麻烦、更大的工作量么?他们应该知道，但是他们为什么没有采取更好的办法呢?
　　Coder和Tester的渊源
　　接上文，我能想到的原因很简单：因为负责coding的和负责testing的不是同一群人，所以往往由于他们专心于&本职工作&而忽视了对对方工作进行深入的思考，他们忽视的是对自己造成什么样的间接影响，最终忽视的是自己交付给客户的代码的质量，也是自己的口碑。即便他们中有些人偶尔能想到这些，替对方多考虑一些，他们也无法打败流程的约束和更简单实用的诱惑，换句话说：选择短视，选择当下可见的便利;选择无条件服务流程规范，选择拒绝持续改进。
　　把一个人的&本职工作&变成了多个人的&本职工作&，用流程来约束势必造成这些现象的出现，但既然coding和testing不由同一拨人负责已成既定事实，那么很明显，coding和testing的合作变成了coder和tester的合作了。我把二者的合作关系和渊源分成5个层次，仅供参考：
　　1、 原始模式&&没有专职，没什么可以讨论的;
　　2、 相互指责&&我能想到的关键字是权力制衡与推诿或过分干涉，常看到这种现象，抱怨的帖子满天飞;那些自以为善于&权术&的管理者也很喜欢利用coder和tester的冲突和相互推诿去做所谓的&制衡&，相信这种管理者会渐渐退出IT的舞台，不过这种相互指责的现象貌似短时间内还不会那么快消失。
　　3、 相安无事&&我能想到的关键字是既定流程下责任共担与成果共享，我个人感觉这是我们公司现有的一种常态，彼此照章办事，无过多思考和改进意识;即便彼此心里对对方有更多期待也不便明说，总觉得干涉对方的工作很不礼貌。在我看来，这是虚假的尊重，却是真正的安于现状和不思上进的代名词。
　　4、 相互倚重&&我能想到的关键字是质量守护和可测性保证，表现在积极的互动和沟通：乐于相互尊重但决不因为害怕冲突而不提出自己的意见;懂得换位思考但决不迁就对方短视或者不经济、不科学的行为。coder要实现一个重构或者系统改造，他们可以依赖测试的质量保证和守护作用;tester要更快更简单的测试也可以要求coder使用更合理易测的实现方式，在哲学上叫相互独立而相辅相成。
原文转自：
评论列表（网友评论仅供网友表达个人看法，并不表明本站同意其观点或证实其描述）}