从传统模式到敏捷开发，产品或项目的迭代增多，很有可能达到每两周就会有一个版本。虽然没有达到每天部署3~4个版本的devops开发模式，但这个时候测试的压力依然陡然增大，既没有那么多的时间写完善的用例，更做不到每个版本都进行完整的回归测试。以前的同事便是在敏捷开发环境下测试某电信运营商相关的金融类app。她经常会遇到即使上线，缺陷也不断的涌现。有些在测试时已经修复的问题，在生产环境又再次出现；或者之前修复的问题，下次测试又再次出现。测试到最后经常顾此失彼，疲于奔命。这时候，测试如果仅仅只是在部署后才参与到产品或项目中，就会越来越累。测试需要肩负起软件质量控制的重任。
测试遇到的问题 测试不参与产品或项目的需求评审，无法对产品或项目做测试计划即使参与到需求评审，但是没有把控需求的可测试性版本构建快，无法把控版本构建测试不了解产品或项目内部流程，无法针对性的编写更有效、更精简的用例测试人力不足，版本迭代快速，无法进行全面的回归测试 理论测试左移、测试右移的概念可以参见项目实施DevOps时，我们是如何做测试的
Laurent提出一个测试左移和右移的概念:
测试左移，就是指在开发阶段之前定义测试。
测试右移，就是直接在生产环境中监控，并且实时获取用户反馈。
实现方法 需求到任务到用例的转化 用例的编写敏捷开发，拥抱变化。需求的变化相较于传统模式越来越多，所以用例也需要跟着及时更新。为了提高编写用例的效率，使用一个好的用例管理平台比用Excel等工具要好。不管是给上级看到工作成果也好，还是方便其他测试接手也好，甚至评价分析测试用例覆盖率都是很有帮助的。
用例从概括到逐步细化刚有需求但没有原型设计，或者需求不明确，用例往往是没法写具体的。所以这时候可以先概括的写，甚至就是把需求描述的功能点写到用例。当设计出来，需求不断明确后，用例就可以逐步细化。就像画画，先勾勒一个轮廓，然后逐渐画细节。
点-》线-》面写用例采用一种点-》线-》面的方式。以添加用户为例。添加用户这是一个功能点。点击添加用户按钮，输入用户信息，点击确定，提示添加成功。这个功能看似流程走完了，其实不能保证所有数据入库正确。这时加入一个功能点，查询用户。查询该用户，在查询结果看不到刚添加的用户，可能是添加用户功能出现了问题。如果查询到用户，用户记录也显示正确了，但同样不能保证所有数据入库正确了。这时再加入用户登录功能点。如果登录不了，或者登录后用户数据显示与添加时不符，还有可能是添加用户时出现的问题。所以功能点不是孤立的，应该用业务串起来，这就是线。如果在添加用户时，设置该用户是用户A的好友。则添加用户成功后，还要登录用户A，查看用户A的好友列表是否有该用户。这就是在添加用户后的另一条分支，也可以说是另一条线。每个业务逻辑会产生多条线，线越来越多，就形成了面。
把控版本构建 会用代码提交工具，查看提交代码内容，确定测试大致范围每次构建或者部署一个测试版本，仅针对修改的部分做测试而不是做回归测试。可以通过查看开发提交记录确定提交的代码是不是都在ReleaseNote上体现了，还是会“夹杂一些私活"，最后没有测试到。对于SCM是git或者SVN的，可以使用sourcetree这个代码查看提交工具。掌握了代码提交工具的使用，可以查看提交代码的内容。可以通过查看提交的描述判断这次提交修改的部分是那些功能。大部分后台服务都是用Java编写的。而后台Java服务大都遵循MVC分层。所以代码文件的名字的后缀来判断这次提交修改的部分是那些功能。
**Util.java 工具类 **service.java 相对具体的业务逻辑服务层类 **manager.java 通用业务处理层类 **controller.java 控制器类，对访问控制进行转发**DAO.java 数据访问层类**Model.java model类 *.properties 配置文件*.xml 配置文件大部分服务也会遵循分层领域模型。
**DO.java（Data Object）：与数据库表结构一一对应，通过DAO层向上传输数据源对象。**DTO.java（Data Transfer Object）：数据传输对象，Service和Manager向外传输的对象。**BO.java（Business Object）：业务对象。可以由Service层输出的封装业务逻辑的对象。**VO.java（View Object）：显示层对象，通常是Web向模板渲染引擎层传输的对象。**表示省略的具体的类名。比如LoginController.java。可以知道这个控制器是用来负责处理登录业务。
持续集成工具的使用持续集成环境的搭建可能我们不关心，但是使用应该是要了解一下的。如果持续集成环境的构建不是无中断的，就是说，构建时服务可能会有短暂时间的不可访问，这取决于测试环境架构或部署脚本的编写。比如突然访问不了测试环境，以为环境出了问题，其实也许只是开发在重新构建测试服务应用。了解了CI工具的使用，可以尽快确定是构建导致的访问不了还是真的出了问题。建议在测试环境由测试人员负责点击构建的工作，一方面可以了解构建时整个CI工具做了那些工作，构建时出了问题也可以及时看到。另一方面可以把控版本的构建，在必要的时候进行控制。比如在确定开发确实提交了相关修改时，再做构建，毕竟提交代码也是会花费一定时间的，而构建一次会花更多的时间，所以尽量减少无意义的构建。
代码质量管理 代码规范很多公司可能不太注意代码规范。但是代码规范与产品代码质量有着直接的关系。代码规范很重要的一点是代码的可读性。提高了代码的可读性，自己更容易理解，结对开发的同伴也更容易理解。这样的代码由于清晰易理解，所以更不容易出错。一旦出错后也更容易找到问题所在。好理解的代码在出错后自己或者同伴更愿意去找问题，而不是对不容易理解的代码面露难色。可读性高的代码开发也更愿意去优化重构，形成良性循环。
代码审核 TBD sonarqube与sonarlint TBD unit test 与 BDD单元测试倒是越来越多的开发人员开始使用，不过把BDD（行为驱动开发）运用到单元测试似乎仍然不受开发待见。不过“老树开新花”，孰不知BDD被自动化测试人员扶了起来。
说到BDD就要谈到TDD（测试驱动开发）。TDD是先有测试用例，第一次所有用例跑下来都是失败的。之后实现用例里的代码，当所有用例下的代码都实现，所有用例都跑通了，那就可以“收工了”。BDD同样是这样，不过这次直接将测试用例变成结构化自然语言去描述，这样需求人员也可以看懂测试用例了，岂不美哉。
自动化测试对于敏捷开发而言，看似是一个很美好的存在。迭代增加，每一次做回归测试会花费大量的时间，仅仅对增加或者修改的功能部分做测试，又担心这一次修改是否会影响到原有的流程。而且在实践中，开发人员即使很仔细，也会遇到考虑不周，改动到原有的代码导致原有的功能出现问题。如果自动化测试可以实施，岂不是解决了大问题？
那么，问题来了，自动化测试应该做到什么程度。覆盖所有流程？这显然是不可能的。要知道自动化测试其实就是写代码，用一套代码验证另一套代码，那验证代码的代码又是谁来验证？这是一个无限循环的问题，测试代码如果很复杂，就会背上业务代码一样的包袱，开发时间、人力都会成为问题。打破这个循环就是让验证代码的代码足够简单，简单到几乎不会出问题。既然测试代码简单到不会出问题，那么就没法要求他可以覆盖所有流程。要知道，有时候验证一个功能比开发一个功能更花费时间。比如要验证发送短信验证码的流程，不仅要看发送验证码给出的提示，还要在手机上查看是否收到正确的短信验证码，这样就跨了两个设备。如果要做这个流程的自动化，测试代码很可能比开发代码还要多，产出与成本的比实在是太低。所以，尽可能的覆盖主要和重要流程，把一些实现起来很复杂的用例放到后面。
这样的话，只实现覆盖主要流程，工程量就减少了大部分了。其实做自动化并不一定要一个团队去实现，况且现实也是如此，很多时候也只有大公司才有那样的人力物力，可以让一个团队去做，大部分公司都没有也不愿意花太多在测试上面。这时就要找准目标，做好减法。团队可能会有分工，有专门编写执行测试用例的人员，那么团队侧重点是做一个测试框架或者是平台，方便这些人员在不编写代码的情况下编写自动化测试用例。这其实就相当于一个开发团队开发一款自动化软件，有负责前端、后端、数据库等等。但是如果只有一个人的话，则肯定是不要想着做框架平台，简单的问题反而复杂化了。我们的目标很明确，就是要让自动化测试提升测试的效率，让产品质量更加的可靠。所以我们要尽可能的使用已有的工具或者框架来提升搭建自动化环境的速度，而不是想着从头做起。
如果不写代码进行自动化测试，robotframework也许是一个不错的选择。
如果要写代码，那么一个合适的IDE就是一个好的前端和后端。既可以用来写用例，又可以写测试代码，还可以跑自动化测试，这又省了一大笔开销。IDE选什么可以根据个人喜好和使用的编程语言，对于Java，IDEA、Eclipse、Netbeans也许都是不错的选择，python的话Pycharm应该不错，这些常用的开发IDE也是支持很多自动化的插件，提升开发的效率。编辑器建议还是不要用了，因为很多自动化的插件并不支持。当然VSCode几乎已经不是一个编辑器了，内存占用也和IDE有的一拼。。。自动化的插件目前来看，既支持写用例又支持写代码的应该就是BDD相关的插件了吧（当然robotframework也是可以的）。Java使用cucumber，python使用behave都是不错的选择。加上Gherkin语法对中文的支持，写出来的用例更加容易理解。
再下来就是自动化框架了。webUI自动化，常用的是selenium。但是selenium还是太过底层，我们为了提高编码的效率，于是有了selenide（Java）和selene（python）。这两个东东可以自动做ajax的等待，简化了selenium的API，获取WebDriver和截图也是自动完成的，可以大量减少wait和wait.until的这些跟业务无关的代码的使用，让代码更加精简易读。
录制工具可以快速记录元素定位，不用自己再查找定位，快速生成测试代码。有空闲的时间时再去优化定位的代码。Katalon Recorder和selenium IDE作为Chrome浏览器的扩展，都是比较好用的录制工具。
代码在本地调试通过了，也就可以生成简易的测试报告了。这个时候就可以不断覆盖用例，同时优化测试代码，抽出相同的进行复用。如果有其他测试人员，可以将代码通过git快速共享。如果需要在CI或者CD平台集成，WebDriver可以使用支持headless的浏览器，比如Chrome和FireFox。当然用PhantomJS更加直接，不用在服务器上安装浏览器了。哦，我忘了，selenium已经不支持PhantomJS了。。。