精准测试的个人理解和认识,谁是精准测试的前提和基础,精准测试的个人理解和认识,谁是精准测试的前提条件
敏捷开发下测试的情况从传统模式转变为敏捷开发，产品或项目的迭代增加。很可能每两周就会有一个版本。虽然没有达到每天部署3~4个版本的devops开发模式，但是此时测试的压力依然在陡然增加，没有足够的时间编写完美的用例，也无法对每个版本进行完整的回归测试。我以前的同事在敏捷开发环境下测试了一个电信运营商相关的财务app。她经常遇到，即使上线，缺陷也在不断涌现。测试中修复的一些问题在生产环境中重新出现；或者之前修复的问题，下次测试又会出现。在考试结束的时候，我们经常会忽略一件事和另一件事，我们会筋疲力尽。这个时候，如果测试只涉及到部署后的产品或项目，就会越来越累。测试需要肩负起软件质量控制的重任。
测试中遇到的问题：测试不参与产品或项目的需求评审，无法制定产品或项目的测试计划。即使参与需求评审，也没有快速构建控制需求的可测试版本，不了解产品或项目的内部流程，无法有针对性地编写更有效、更精简的测试用例。人力不足，版本迭代快，做不了全面的回归测试。关于理论测试左移和测试右移的概念，请参考项目实现DevOps时我们是如何做测试的。
劳伦特提出了测试左移和右移的概念：
将测试移到左边意味着在开发阶段之前定义测试。
测试右移是指在生产环境中直接监控，实时获取用户反馈。
实现从方法需求到任务再到用例的转化。用敏捷开发编写用例，拥抱变化。与传统模型相比，需求变化越来越多，因此用例需要及时更新。为了提高用例的编写效率，最好使用一个好的用例管理平台，而不是Excel等工具。无论是为了向上级展示工作成果，还是为了方便其他测试接手，甚至评估和分析测试用例的覆盖率都是有帮助的。
用例从概括到逐步细化，有需求但没有原型设计，或者需求不明确。通常不可能写出具体的用例。所以，这个时候你可以笼统的写，甚至可以把需求描述的功能点写成用例。当设计完成，需求明确后，用例就可以逐步细化了。就像画画一样，你先画个轮廓，然后逐渐画细节。
点线面书写用例采用点线面方法。以添加用户为例。添加用户这是一个功能点。点击添加用户按钮，输入用户信息，点击确定，提示添加成功。这个函数似乎已经完成了这个过程，但是它不能保证所有的数据都会被正确存储。此时，添加一个功能点来查询用户。查询这个用户，在查询结果中看不到新添加的用户。可能是添加用户的功能有问题。如果找到用户，将正确显示用户记录，但不能保证所有数据都正确入库。然后添加用户登录功能点。如果无法登录，或者登录后的用户数据显示与添加时不符，则可能是添加用户时出现了问题。所以功能点不是孤立的，要按业务串起来，这就是线。如果添加用户，请将该用户设置为用户A的朋友.然后，用户添加成功后，登录用户A，查看用户A的好友列表中是否有该用户。这是添加用户后的另一个分支，或者另一条线。每个业务逻辑会产生多条线，越来越多的线会形成一个平面。
使用代码提交工具构建受控版本，检查提交的代码内容，并确定测试的大致范围。每次构建或部署一个测试版本，只测试修改的部分，不做回归测试。可以查看开发提交记录，确定提交的代码是否都在ReleaseNote中有所体现，或者是否会“掺杂一些私人活动”，最后不进行测试。如果SCM是git或者SVN，可以使用代码源码树查看提交工具。掌握代码提交工具的使用，可以查看提交代码的内容。可以通过查看提交的描述来判断这次提交修改的是哪些功能。大部分后台服务都是用Java写的。而后台Java服务大多遵循MVC分层。所以可以通过代码文件名称的后缀来判断这次提交修改的是哪些函数。
**Util.java工具类**service.java是比较具体的业务逻辑服务层类**manager.java通用业务处理层类**controller.java控制器类，转发访问控制**DAO.java数据访问层类**Model.java模型类*。属性配置文件*。xml配置文件大多数服务也将遵循分层域模型。
**DO.java(数据对象):与数据库表结构一一对应，通过DAO层向上传输数据源对象。**DTO.java(数据传输对象):数据传输对象，以及服务和管理器传输的对象。**BO.java(业务对象):业务对象。封装业务逻辑的对象，可由服务层输出。**VO.java(View对象):显示层对象，通常是Web传输到模板渲染引擎层的对象。* *表示省略的特定类名。比如LoginController.java。可以知道这个控制器是用来处理登录业务的。
持续集成工具的使用和持续集成环境的构建可能不关我们的事，但是使用要懂。如果持续集成环境的构建不是不间断的，也就是说，服务在构建时可能在短时间内不可访问，这取决于测试环境架构或部署脚本的编写。比如突然无法访问测试环境，以为环境有问题。事实上，它可能只是开发和重建测试服务应用程序。知道了CI工具的使用，我们就可以尽快确定访问是因为构建还是真的出了问题而无法实现。建议测试人员负责在测试环境中点击构建。一方面，他们可以知道整个CI工具在构建过程中做了什么，构建过程中出现的问题也可以及时看到。另一方面，必要时可以控制受控版本的构造。比如确定开发提交了相关修改后，再做建筑。毕竟提交代码需要一段时间，一次搭建需要更多时间，尽量减少无意义的搭建。
质量管理的代码规范很多公司可能不太重视代码规范。但是代码规格说明与产品代码质量有直接关系。代码规范的一个重要点是它的可读性。代码的可读性提高了，我更容易理解，我的合作伙伴也更容易理解。这样的代码不太可能出错，因为它清晰易懂。一旦出了问题，就更容易发现问题。当一个很好理解的代码出错时，自己的或者同行更愿意去寻找问题所在，而不是对不容易理解的代码恋恋不舍。可读性高的代码开发也更愿意优化重构，形成良性循环。
audit TBD sonar cube和sonarlint TBD单元测试和BDD单元测试正在被越来越多的开发人员使用，但似乎将BDD(行为驱动开发)应用于单元测试仍然没有开放开发。然而“老树开新花”，却不知BDD是被自动化测试人员扶起来的。
说到BDD，就要说到TDD(测试驱动开发)。TDD先有测试用例，第一次所有测试用例运行下来，都失败了。之后，在用例中实现代码。当用例中的所有代码都实现了，所有用例都贯穿了，就可以“称之为一天”了。BDD也是如此，但是这一次，测试用例直接用结构化的自然语言描述，这样需求者也可以理解
自动化测试对于敏捷开发来说，自动化测试似乎是一种奇妙的存在。迭代添加，每次回归测试都会耗费大量时间，只测试添加或修改的功能部分，担心这种修改会不会影响原来的流程。而且在实际操作中，即使开发人员非常细心，也会遇到考虑不周的情况，对原代码的改动会导致原功能出现问题。如果可以实现自动化测试，不就解决了大问题了吗？
那么，问题来了，自动化测试应该做到什么程度。覆盖所有进程？这显然是不可能的。要知道自动化测试其实就是写代码，用一套代码验证另一套代码，谁来验证验证代码的代码呢？这是一个无限循环的问题。如果测试代码比较复杂，就会背负和业务代码一样的负担，开发时间和人力都会成为问题。打破这个循环，就是让验证码的代码足够简单，几乎不会有问题。既然测试代码简单到不会出错，就不能要求它能覆盖所有流程。你知道，有时候验证一个功能比开发一个功能要花更多的时间。比如验证发送短信验证码的过程，不仅要看发送验证码给出的提示，还要检查手机上是否收到了正确的短信验证码，这样就跨越了两台设备。如果这个过程要自动化，测试代码很可能比开发代码多，产出成本比太低。因此，尽可能地覆盖主要和重要的流程，将一些实现起来很复杂的用例放在后面。
这样只覆盖主要工序，工程量会减少最多。其实一个团队没有必要去做自动化，现实也是如此。很多时候只有大公司才有人力物力让一个团队去做。大多数公司没有也不愿意在测试上花费太多。这时候就要找准目标，做好减法。团队里可能有分工，有专门编写和执行测试用例的人，所以团队专注于做一个测试框架或者平台，方便这些人不用写代码就能编写自动化的测试用例。其实这就相当于一个开发团队开发一个自动化的软件，负责前端、后端、数据库等等。但如果只有一个人，那肯定不是想着做框架平台，简单的问题反而复杂了。我们的目标很明确，就是让自动化测试提高测试效率，让产品质量更可靠。因此，我们应该尽量利用现有的工具或框架来提高构建自动化环境的速度，而不是想着从头开始。
如果你不写自动化测试的代码，robotframework可能是个不错的选择。
如果你想写代码，那么一个合适的IDE就是一个好的前端和后端。可以用来写测试用例，测试代码，运行自动化测试，省了不少钱。IDE的选择可以基于个人偏好和所使用的编程语言。对于Java来说，IDEA，Eclipse，Netbeans可能都是不错的选择，python的Pycharm应该不错。这些常用的开发ide也是支持很多自动化的插件，从而提高了开发的效率。建议不要使用编辑器，因为很多自动化插件都不支持。当然，VSCode几乎不再是编辑器，内存占用和IDE一样。目前同时支持写用例和写代码的BDD相关插件应该是BDD相关插件(当然robotframework也可以)。使用Java cucumber和python使用behave都是不错的选择。有了中文的小黄瓜语法支持，写出来的用例更容易理解。
接下来是自动化框架。WebUI自动化，常用的是selenium。但是硒还是太低了。为了提高编码效率，我们有selene(Java)和selene(python)。这两样东西可以自动等待ajax，简化selenium的API，自动获取WebDriver和截图，可以大大减少与业务无关的wait和wait.until代码的使用，让代码更加简洁易读。
记录工具可以快速记录元素的位置，快速生成测试代码，无需自己寻找位置。有空的时候优化定位代码。Katalon Recorder和selenium IDE作为Chrome浏览器的扩展，都是比较好用的录音工具。
如果代码在本地调试，可以生成一个简单的测试报告。此时，您可以持续地覆盖用例，同时优化测试代码，并提取相同的用例进行重用。如果有其他测试人员，可以通过git快速分享代码。如果需要在CI或CD平台上集成，WebDriver可以使用无头浏览器，比如Chrome和FireFox。当然PhantomJS更直接，不需要在服务器上安装浏览器。哦，我忘了，selenium已经不支持幻像了。
郑重声明：本文由网友发布，不代表盛行IT的观点，版权归原作者所有，仅为传播更多信息之目的，如有侵权请联系，我们将第一时间修改或删除，多谢。