身为一个软件工程师，我们不可避免的会遇到这样一些问题：不得不修改别人的代码，或者在别人的代码中添加新的功能。

有些人对这些问题有非常简单的回答。及时享乐型的程序员根本懒得去测试，快乐地活在当下。更严肃的程序员会告诉你软件测试是为了开发出高质量的产品。为了可以开发出高质量的产品，必须始终编写单元测试和集成测试，并做 QA 测试。

在学校里学了几年的编程，很少人有机会去写测试，对测试这门手艺活当然很陌生了。摆正思想，多练习，自然就熟练了。

要缩短发布周期、杜绝hotfix，需要从需求切分、迭代规划、技术架构、团队能力建设和测试策略调整等多方面进行优化，才能保证持续、快速的发布节奏，这是一个系统的问题。

作为一名QA，每次听到“重构”两个字，既想给追求卓越代码的开发人员点赞，同时又会感觉非常紧张，为什么又要重构？马上就要上线了，怎么还要改？是不是应该阻止开发人员做重构？

现在业界流行的测试金字塔和测试象限只是两种高度抽象和简化的测试策略模型，不具备实际可操作性，只具备高层次的指导性和参考性。直接根据这两个模型来工作是低效的，甚至可能带来负面效果。

我们先讨论一下在传统的瀑布模型下QA是如何工作的，其中最主要的问题是什么；然后作为对比，我们再来看看敏捷团队里的QA是如何工作的，工作重点又是什么；最后，我们详细看一看在新的职责下，QA应该如何做。

在工作中经常遇到当产品上线出了bug后，第一个受到指责的是测试人员，”测试为什么当初没有发现这个问题呢”，这种情况在现实工作中数不胜数，也许他们把测试人员当”超级魔法师”了，经过测试之手的东西就完美无瑕了，这就属于角色定位问题，当定位好自己的角色后，在协商角色内容时，就有了在可能出现的任何情况下现的问题时首先确立对自己预期的基础。

QA的职责 我们先讨论一下传统的瀑布模型下QA是如何工作的，其中最主要的问题是什么；然后作为对比，我们来看看在敏捷团队里QA又是如何工作的，工作重点又是什么；最后，我们详细看一看在新的职责下，QA应该如何做。

业务熟悉；逻辑思维好，气场也要好；掌控系统上线排期；熟悉测试技术；约束开发人员，保证开发质量；要懂的写代码进行接口自动化测试；

在本系列的上一篇文章中，我通过系统登录这一典型功能点，演示了编写自动化测试脚本的整个流程，并对测试脚本进行了初步优化。

在本文中，我将重点介绍如何对自动化测试脚本实现?工程化?的组织和管理。

项目从2009年开始启动，采用的是TDD开发方式。在这之后的过程中，团队做过各种尝试去调整自动化测试的策略去更好的适应不同阶段项目的特征，比如调整不同类型测试的比例，引入新的测试类型等。

我们都知道在测试移动app时最耗时的是在各种测试设备进行测试， 因为不论是安卓还是iOS都已经碎片化了。而云测试看似是解决这一问题的有效途径。因此选择哪种云测试平台来协助测试人员进行各种测试就成为首要问题。

在本文中，我将在M项目中挑选一个功能点，对其编写自动化测试脚本，演示编写自动化测试用例的整个流程。

在本文中，我们学习了对iOS UI控件进行交互操作的一般性方法，为编写自动化测试脚本打好了基础。

在本文中，我将在已准备就绪的iOS自动化测试环境的基础上，通过Appium调用模拟器运行iOS应用。

最近新加入 M 项目组，需要从零开始搭建功能自动化测试平台。简单说，M是一个典型的移动互联网产品，客户端包括 iOS 和 Android，并在 app 中通过 WebView 嵌入了 H5，后端基于 ROR 实现。

敏捷软件测试指的是在敏捷软件开发过程中跟质量相关的一系列活动，和传统意义上的软件测试有很多区别，因为敏捷软件测试的概念一直比较模糊，所以经?；嵊腥俗呷胛笄?，我曾经在瀑布型的软件开发模式下做过几年的测试人员，所以在刚刚接触敏捷项目的时候也曾有过一些误解，但是在敏捷软件开发团队工作将近5年后，对很多问题有了新的认识，以下针对几个常见的误区和大家分享一下我的理解。

什么是好的与坏的性能？为什么性能测试在软件开发生命周期中很重要？性能不佳的应用通常无法实现企业预期利益，花费了大量时间和金钱，而且也在用户中失去了信誉。

写一个测试程序，重现这个bug。即使你没有时间来立即修正这个bug或者这不是个致命的bug，你也应该有个能够让它重现的测试程序，当日后你回来解决这个问题时，你就能知道该做什么了。