我们公司的 app 之前也这样. 就是因为证书方面会有限制. 你可以用 burp suite 试试. burp 不会伪造证书, 他会重用老的证书的字段.

你们的客户端对证书有校验吧. 你看看他们的代码里面有没有校验证书的字段吧

加精理由: 普及了 docker 这个 devops 依赖的基础知识.

格式调整下. 翻译下细节. 给你加精.

直接 bash 就行了吧. python 是不是大材小用了.

如何录制这些流程貌似都没写. 与 anyproxy 如何结合的? 不少人估计没看懂

#14 楼 @aizaimenghuangu 如果出现之前的测试和研发模式未曾覆盖的点, 那么就不应该算是测试漏测, 也不需要质量背锅. 共同改进即可. 比如在人力资源紧张的情况下, 明确只测试主流的平台, 如果某个偏门的浏览器, 或者偏门的改造版 rom 或者浏览器爆出问题, 就针对性的解决即可. 不需要非要拉人背锅.

支持下 我当时就极力推荐说 627 可以胜任的. 现在终于找到自己的舞台了. 不错

没有具体的上下文, 别人也没法给你建议. 什么 app, 什么环境, 什么输入上下文.发生了什么现象. 你只列举了发生了什么现象.

请用 markdown

自己试下就知道了

虽然是冷门了, 但为你的分享点赞. 当年我做微软的外包, 也做过 windows 的自动化, 微软有自己的完整的自动化测试框架. 不知道有么有开源.

跟测试貌似没关系 决定屏蔽

其实 WDA 是工作的, 只是一开始 appium 发送了 session 的请求导致出错了. 执行其他的 source 命令, 还是可以正常工作的

不错. 比微信原来丑陋的菜单是个很大的进步了. 后面我们也规划下如何把 testerhome 做成微信号. 加我微信 seveniruby. 我邀请你加入 testerhome 的技术维护群.

现在主要是三大派系. jvm native 和 js 系
jvm 体系的语言是 java scala groovy jruby jython
native 的语言是 php python ruby c/c++ go oc swift
js 系是 nodejs typescript dart 之类的

考虑到移动测试行业本身大部分的 app 都是用 java 编写的, 所以 java 是基础必备技能.
在这个多变的行业, 如果想做的深入一些, 得深入一个引擎. 然后懂两门以上的语言才可以.
只做小白和业务测试, 那不会开发也能混, 只是路子相对较窄

哪家公司的

无图无真相啊

加精理由: 工作中实用技能. 方便产品流程中的多系统交互.

#4 楼 @aizaimenghuangu 对于让你伤心这个我表示歉意. 这个社区欢迎任何有真知灼见的同学来分享.
我屏蔽是怕这个帖子被人喷成筛子.

从这个帖子可以看出你从事管理的经验并不太深, 但是分享的精神可嘉.

分享的想法和实践希望是有真知灼见并有切身的经验的. 而不是被公司的主流思想所引导的.

关于 bug 数作为 kpi 的教训

那边把 bug 数作为 kpi 的那个帖子被我屏蔽了.

八年前我在阿里的时候所在的团队就推行过这个以 bug 数作为 kpi 的例子. 导致了如下结果

1. 如果是一个新手 碰到一个烂的开发, 一个项目就能成为 kpi 第一, 所以测试同学非常期待研发团队多招水平低的人.
2. 如果是个老手遇到一个好的项目, 就会倾向于把很多低级别的 bug 想办法夸大.

巧合的是研发那边是正好反着, 把 bug 数也作为 kpi. bug 越少 kpi 越高. 然后修 bug 已经不是主业了, 结果就是 bug 就跟黄金一样, 测试团队和开发团队天天在围绕着 bug 是否够量, 是否够纯等问题上来会拉扯. 推行一次后就再也不用了

纯从线上故障也不能完全反映 qa 团队的能力, 因为线上故障有的时候也是运气成本居多, 有的人运气好, 哪怕漏测很多也不出事, 有的人就算测试的很辛苦较全面, 也会倒霉的踩上地雷.
对于每个故障, 都要分析缘由不要贸然背锅和甩锅.

测试团队的考核维度

我理解的考核方式是先确定结果愿景, 再定义过程数据, 最后才是结果数据. 但是不要求数据严格化. 有些数据不能强制. 比如这个月员工工作了多少人日小时, 自动化测试用例多少个, 覆盖率多少. 在复杂的项目下, 这个数据统计方式和标准都不是精准的, 如果强制要求下面的人, 他们就会拿各种数据拼凑导致数据不精确. 不精确的数据就会导致错误的决策.

要求自动化测试用例数, 就跟研发要求代码行数, 飞机要求重量一样荒谬.

那什么是测试团队核心的评估维度那. 我认为一个好的维度是能即简单直观又能细分的指标. 因为这些指标是要能让老板和研发团队信服的. 我列举下我认可的能反应团队实力的几个维度.

质量维度: app 崩溃率, 线上 bug 数, 漏测率, 用户 bug 反馈数 测试用例的覆盖度, 测试行为的覆盖率...
效率维度: 测试成本, 测试周期 分层自动化 工具利用率, 自动化辅助, 创新与改进, 测试的提前度, 测试的并行度, 执行的效率...
团队维度: 流程管理, 文化建设, 沟通协作, 成员能力成长, 技能交流分享, 项目支持, 合作团队反馈...

以上只是列举的部分指标, 这些指标有的可以直接获取的, 就确定统计方式 不能有效获取的, 也不要求一线员工去补充.
很多问题其实都可以一叶知秋, 比如从线上漏测的 bug 就能知道从什么方向如何弥补质量,效率和团队三个主要资源的短板.
里面的每个指标都是和其他的指标关联的. 都不是孤立存在的.

质量管理的坑

很多管理者很迷信精确的数据, 的确数据量化是团队的终极目标. 但是不要在未成熟的阶段就刻舟求剑. 不正确的统计指标比如过于要求工作时间精确到小时, 测试覆盖率高到 90%, 自动化数量超过几百几千之类的, 既会让一线员工痛苦, 也会让以后的维护成本变的越来越大. 需要综合考量和参考.

管理方式和方法需要根据公司大环境, 行业环境和团队能力确定.
比如身处国企, 团队已经是一群不会编程的老员工组成, 你就得从测试用例的覆盖率和优化上去改进才能达到目标. 公司有钱有预算用来申请外部的咨询和培训辅助你的理念和目标落地.
如果团队里面新老参半, 你就得加强团队交流, 让新人快速的成长, 以免有人挟持业务自重尾大不掉, 这种时候把交流分享的 kpi 比重定的较高或者建立导师制度都有利于解决
如果你身处一家已经发展成型的大公司, 你就得规范流程, 明确责任, 重管理. 严格把关上线流程.
如果你身处一家茁壮发展的创业型公司, 你的首要任务就是招聘, 提升执行力和团队战斗力.
当然了, 还有更多的如何和复杂的环境需要处理.

如果用发展国企的风格来管理创业型公司 或者用创业型公司的方式来管理国企, 你都会死的很惨. 而且会拖死一家公司.
所以质量管理看似是小事情, 实则是一个难度极高的工种. 要对质量有深入的理解, 对自己的岗位要存敬畏之心.

作者只是更新了 changelog, 还没正式的发布.

#3 楼 @huangke 你少打了一个 s. version 修改为 versions

#8 楼 @huangke 恩, 碰巧有人也在反馈微信也有这 bug. 所以我看错了