物联网测试地图（译）
本文首发于「BY林子」，转载请参考版权声明。 物联网的出现，给测试带来了很多有意思的挑战，使得众多QA开始重新思考传统的测试过程。 例如，我最近测试了一个产品，在这个产品中的移动APP会跟连接的机器产生会话。这两个设备各种各样的状态给测试场景的设计带来了特别大的挑战。下面给大家介绍一个很有用的物联网产品测试框架——物联网测试地图，它可以帮助我们管理物联网设备多种排列的复杂状态。 01 物联网测试因素当我们测试简单的web应用时，通常要考虑的状态有： 服务器宕机 HTTP请求超时 网速慢 授权和认证错误 测试任何互联网应用的时候，需要警惕这四种状态。对于移动应用，操作的是移动环境，需要关注额外的几种情况： 离线模式 在线模式 杀掉Activity 后台行为 语言 地理位置 我们再看“连接的机器”所带来的状态多样性，通常还有： 机器WiFi断开 机器WiFi连接 机器繁忙 机器休眠 这意味着即使只有上述给定的状态集，整个系统在任何时间点上可能会有96（4x6x4）种状态。 由于系统中状态转换会引入附加的约束，这些状态都不能当做独立的实体。例如，状态从“离线”变成“在线”...
系统级集成测试的断舍离
本文首发于「BY林子」，转载请参考版权声明。 01 食之无味，弃之可惜在企业级应用的季度或月度发布被认为是领域最佳实践的时候，应用部署到生产环境之前维护一个完整的环境进行集成测试是非常必要的。但是，集成测试环境和集成测试本身有着如下的问题： 环境本身脆弱，而且通常存在手动配置部分，环境维护成本很高； 环境因素导致集成测试不稳定、不可靠、反馈慢，测试失败不易定位问题，同时还会重复测试隔离组件已经测过的功能。 集成测试成为了持续交付的瓶颈，犹如鸡肋。因此，最新一期（2017年第16期）ThoughtWorks技术雷达建议企业暂缓搭建企业级集成测试环境，而是采用增量的方式发布关键组件到生产环境。增量发布涉及到一些重要的技术包括契约测试、将发布与部署解耦、专注于平均恢复时间和生产环境下的QA 。 02 断舍离之技术可行性下面分别介绍技术雷达建议的这四项技术，以及在没有集成测试的情况下如何保证应用的质量、如何帮助企业做到独立增量发布。 1. 消费端驱动的契约测试消费端驱动的契约测试是微服务测试的重要组成部分，主要用来覆盖两两服务之间的契约关系，下面举个例子来说明什么是契约测试以及契...
为什么不能每周发布一次？
本文首发于「BY林子」，转载请参考版权声明。 “看，车来了！不过这趟车貌似咱赶不上了吧？！” “啊！那快点跑，错过这趟就得再等半个小时！” …… 好无奈，可是真的赶不上也没有办法，这个场景很多人都经历过。 “这个release又是一定包就开始上hotfix，四天跟了四个，我根本没时间做回归测试！” QA小静同学抱怨道。 “每次都是定包后就开始无休止的上hotfix，咱们还不如改成每周发布一次！”Dev大鹏同学也被hotfix折磨苦了。 这是发生在蓝鲸项目的一次真实而平常的对话，跟前面赶公交车的场景有什么关系呢？ 01 发车间隔与发布周期1. 发车间隔的不同带给乘客的感受会完全不同有些公交车很少，每半个小时一趟，有时候眼看着一辆车来了又走了，没赶上的心情无比懊恼，下一趟还得等上半个小时啊！实在着急的可能考虑叫一辆快车赶紧走… 而有些公交车发车间隔非常短，几分钟一趟，就算错过一趟也无需等待太久，只要不是着急去救火的乘客一般都不会太在乎。 2. 项目的不同发布周期带给客户的感受也是类似的蓝鲸项目的发布周期跟第一种公交车发车间隔非常类似，是四周发布一次，如果这次没能上线的功...
大规模团队的QA如何高效合作
本文首发于「BY林子」，转载请参考版权声明。 “你们团队QA和DEV的人员比例是多少？” “我们团队一般有1个QA和3~4对DEV pair.” 经常会被问到这样的问题，一般的小团队都是这样的人员比例，QA也不会觉得压力有多大。当多个特性团队工作在同一个代码库、分别在开发同一个系统的不同功能的时候，虽然每个特性团队也保持前面所述的比例，对于QA的挑战却要大得多，那是因为： QA不仅要了解自己特性团队的需求，还需要了解其他团队的需求，因为这些功能都在同一个系统上，联系必然是很紧密的； 某个团队发现的软件缺陷的根源、错误日志信息，在其他团队也可能发生，这些信息需要共享； 某个特性团队有任何基础设施、测试环境配置文件的变化都得让所有团队知晓，而QA是其中沟通这个内容最恰当的角色； …… 由此可见，大规模团队的QA不像小团队那么简单，沟通的成本要高很多。如果没有及时沟通，将会造成信息不对称，要补救所花费的额外精力是比较大的。当然，大规模团队不仅QA的沟通成本增加，其他角色也一样，只是因为我是QA嘛，就跟大家聊聊我们QA是如何应对这种大规模团队的挑战的。 01 集体参加story...
神圣的QA——写给应届毕业生
本文首发于「BY林子」，转载请参考版权声明。 你有没有过下面的经历： 在谷歌浏览器输入一个网址，出来一个错误提示：“不支持当前浏览器，请用IE访问”… 换成IE，重新打开该网站，输入用户信息注册一个新用户，随后收到一封注册成功邮件，里边直接包含刚刚注册的密码… 用注册的用户名密码登录进去，又不知道所需要的功能入口在哪里… 翻遍了一层又一层的菜单，终于找到了入口，进去打开的是一个列表，足足等了2分钟才加载完成… 从列表中找到自己需要的那个信息，点击“查看详情”，却显示一堆乱码… 一次性碰到上面的各种当然属于极端现象，但我敢说，你一定碰到过其中的问题不止一次，而且碰到了一定很郁闷。这些都是软件缺陷，分别是兼容性、安全性、易用性、性能和功能方面的缺陷，一旦出现将会给企业和用户带来不同严重程度的影响。 这种糟糕的体验有没有使你产生想去优化的冲动？你是否想知道如何帮助软件开发团队开发出缺陷更少的软件产品？如果你的回答是肯定的，那么请跟我一起来做QA吧：） 01 QA是什么？狭义的理解就是软件测试，软件测试工程师常被称为QA；广义上，QA就是在软件开发过程中做好软件质量分析和保证的人...
敏捷实践Showcase的七宗罪
本文首发于「BY林子」，转载请参考版权声明。 01 Showcase介绍Showcase就是开发团队把开发好的功能给客户的Product Owner（以下简称PO）等业务相关人员演示，以获取他们对所开发系统的反馈，是敏捷开发流程中的一个实践，一般频率是一个迭代一次，也可以根据项目具体情况做调整。Showcase是做功能演示，同时也是展示开发团队面貌的时刻，其重要性不言而喻，但据我经历的项目，总能看到一些不是很理想的地方。 02 Showcase之七宗罪 1. 准备工作没做好所有人就位，准备开始showcase的时候，突然发现环境没有ready，连不上了！ 好不容易把环境弄好了，开始showcase，可是数据又没有ready，还要临时创建，花了大半天时间（创建、准备数据）才终于show到了真正要演示的功能…… 主讲人手忙脚乱，而其他人都要在这种忙乱中等待，浪费了很多宝贵的时间，尤其是对于PO那些重要人物来说。 正确做法：充分做好准备工作 确定要做showcase的功能后，需要提前把以下事情提前做好： 从业务的角度把整个要演示的功能尽可能的串起来，准备好showcase演示的步...
测试右移——生产环境下的QA
本文首发于「BY林子」，转载请参考版权声明。 2015年11月ThoughtWorks发布的技术雷达提到一个新的主题——生产环境下的QA（QA in Production），2016年4月再次提到。这个主题第一次出现在技术雷达，就深深的吸引了我，当时我就给测试团队成员转发了这个内容，但同时脑子里却产生这样一系列的疑问： 生产环境下的QA可以做什么呢？有什么挑战，又有哪些好处？ 它跟预生产环境的QA有何区别，是否就是预生产环境QA方法的延伸？ 生产环境有运维支持团队（Ops），生产环境下的QA跟Ops所做的事情又有什么区别与联系？ 带着这些疑问，结合项目上的一系列实践，于是有了本文。 01 一个生产环境Bug的解决办法先来跟大家分享一个生产环境下的Bug： 一个在线订购葡萄酒的系统，订购流程相对复杂，下单过程中后台会有随机的失败，系统采取的措施是重试，就是说顾客下单后，后台如果有错误就会不停的重试，直到成功，这个过程对顾客是不可见的。这听起来没什么问题，用户体验似乎也不错。 后来有个新版本上线了，顾客下单后还是会有随机失败，系统依然不停的重试，但这次不一样的是有的随机失败，...
从《技术雷达》看软件测试新趋势
本文首发于「BY林子」，转载请参考版权声明。 2015年11月，ThoughtWorks发布了新一期的技术雷达。技术雷达是以独特的形式记录ThoughtWorks技术顾问委员会对行业产生重大影响的技术趋势 讨论的结果，为从CIO到开发人员在内的各方利益相关者提供价值。这期雷达的技术趋势主要体现在：受到热捧的微服务相关技术，逐步成熟的以Docker为典型的容器化生态系统，备受企业和用户关注的信息安全问题。本文就从这几个新趋势来分析一下给软件测试带来了哪些影响。 01 自动化测试是王道在这个快速变化发展的时代，任何一款产品想要在市场具备竞争力，必须能够快速适应和应对变化，要求产品开发过程具备快速持续的高质量交付能力。而要做到快速持续的高质量交付，自动化测试将必不可少。同时，自动化测试也不是用代码或者工具替代手工测试那么简单，有了新的特点和趋势：针对不同的产品开发技术框架有着不同的自动化技术支持，针对不同的业务模式需要不同的自动化测试方案，从而使得自动化测试有着更好的可读性、更低的实现成本、更高的运行效率和更有效的覆盖率。来自技术雷达的下列主题分别体现了自动化测试的这些特点： 针对...
软件缺陷的有效管理
本文首发于「BY林子」，转载请参考版权声明。 “这次发布之前怎么这么多的缺陷，是不是需要分析一下啊？” 答案是肯定的，可是这个时候才想起要分析已经有点晚了，有可能这些缺陷很难分析了。这是发生过的一个真实场景，所记录的缺陷包含信息很有限，很难有效的做好分析！ 本文就来聊聊如何有效的管理和分析缺陷。 缺陷是一项非常有价值的资产，软件缺陷的管理分为两个部分：缺陷信息收集和缺陷分析。 01 恰到好处的缺陷信息收集1. 无效的缺陷记录 信息繁冗 有的项目团队要求详细记录缺陷的多个维度信息，而且大部分都是必填字段，比如详细的重现步骤，对于有些特别简单的缺陷来讲是没必要的，关键是信息能够说明缺陷即可，过分详细的要求会带来更大的浪费。 曾经有个项目是在QC(Quality Center)里记录缺陷，需要填写很多必填属性字段，没有办法灵活根据具体缺陷调整，加上QC服务器在国外，访问速度非常的慢，每次记录缺陷成为了大家极其痛苦的一件事情。 信息缺失 也有的项目对缺陷的格式和属性没有严格要求，记录的时候很简单也很自由，这样记录的缺陷由于很多必要信息的缺失，对后续的跟踪和分析也是极为不利。 ...
说起BDD，你会想到什么？
本文首发于「BY林子」，转载请参考版权声明。 在刚接触BDD（Behavior Driven Development，行为驱动开发）的时候，我以为就是用Cucumber这样的工具来编写场景用例，从而实现自动化测试，甚至很长时间分不清BDD和ATDD(Acceptance test driven development)到底有什么区别。 那么，BDD真的就是用来做自动化测试的吗？本文就来跟大家分享一下我理解的BDD。 01 为什么要BDD？“开发软件系统最困难的部分就是准确说明开发什么” (“The hardest single part of building a software system is deciding precisely what to build” — No Silver Bullet, Fred Brooks) 。 场景一：业务分析人员觉得自己分析的需求BDD已经写的很清晰了，并且跟技术人员进行了足够的沟通，可是开发完做Desk check的时候，发现所开发的功能还是跟期望有差距。 场景二：开发团队辛辛苦苦开发完一个功能，满怀信心的去给产品经理/...
