软件测试回顾(2)

目录

软件测试回顾(2)

04自动化测试

什么是自动化测试？

这个没什么好讲的，就是使用工具代替人工

为什么要自动化测试？

优势：

  • 减少成本(时间成本+人工成本)
  • 先天具有可追溯性
  • 提高回归效率
  • 其他好处(定时执行、手工无法执行的用例，如稳定性)

劣势：

  • 不要奢望所有的测试都自动化，否则一定会得不偿失
    • 曾经维护过一个稳定性巨差的自动化，简直是要崩溃，影响用例结果的因素太多了,外部环境也会影响结果。很痛苦
  • “开发手一抖，自动化测试忙一宿” ，维护成本高
    • 要想做自动化，一定要和开发人员配合好，约定哪些东西能动，哪些不能动，特别是基于ui的web自动化测试。
  • 自动化测试用例的开发工作量远大于单次的手工测试，只有执行次数大于等于5次时，才能收回成本。
  • 自动化测试仅仅能发现回归测试范围的缺陷
    • 一般都会采用手工(新功能) + 自动化回归 做新版本，之后在将新的手工用例纳入到自动化用例集里
  • 不稳定的自动化测试用例实现比没有自动化更糟糕
  • 要想有完美的自动化用例，需要业务测试专家和自动化测试专家相互配合(或者你即懂业务，也懂自动化)
  • 自动化测试开发人员必须具备一定的编程能力

如何才能知道该用例是否可以被自动化呢？

当你发现自动化测试用例的维护成本高于其节省的测试成本时，自动化测试就失去了价值与意义，你也就需要在是否使用自动化测试上权衡取舍了。

哪些项目适合自动化？

可能刚工作，哪个项目要不要自动化，不是咱们说了算，但是我们也要有个全局的认知，站在更高角度看问题，不要局限在埋头工作，多抬头看看脚下的路。

  1. 稳定的需求，不会频繁变更需求
  2. 研发和维护周期长，需要频繁进行回归测试
    1. 对产品进行自动化，而非对项目
    2. 如果对项目继续自动化(需要频繁的进行回归测试)
      1. (对稳定的中长期的产品进行自动化，变动较大或者需求不明确的功能，20%的精力去覆盖80%的回归测试)
  3. 需要在多平台进行重复运行相同场景的测试
  4. 某些特殊的测试，手工无法完成。如性能和压力测试
  5. 规范的开发+可测试性的接口，否则后续的自动化很难开展
  6. 测试人员编程能力
    1. 测试工程师通常会非常热衷于学习使用自动化测试技术，以至于他们的工作重点会发生错误的偏移，把大量的精力放在自动化测试技术的学习与实践上，而忽略了测试用例的设计，这将直接降低软件整体的质量

个人感悟

以缺陷数量来衡量测试的绩效是不可取的，会激化测试和开发之间的矛盾，个人觉得缺陷数量应该来衡量开发的绩效，因为 开发需要对测试负责，测试需要对用户负责。

业务测试和测试开发一般公司都分离开，我做过2年的业务测试，1年的测试开发(完全不碰业务)。其实个人挺不太喜欢这种完全剥离的感觉，就会陷入一种误区，测开就在写内部公司代码，开发工具，并且由于测开完全不懂业务，就会需要一个更“高级”的工程师(也有可能是PM)来协调写出什么样的工具，最后的结果往往是需求不断更改，改了又改，业务测试人员还用的不爽。双方效率都很低下

最开心的就是我在做业务测试时候，自己写的测试工具，那是完完全全的“自我定制”，效率提升的很高，成就感也很足。

05章：软件开发各阶段的自动化技术

1.单元测试自动化

  1. 用例框架代码生成的自动化；
  2. 部分测试输入数据的自动化生成；
  3. 自动桩代码的生成；
  4. 被测代码的自动化静态分析；
  5. 测试覆盖率的自动统计与分析

2.WebServicec测试自动化

Web Service测试，主要是指SOAP API和REST API这两类API测试，最典型的是采用SoapUI或Postman等类似的工具。但这类测试工具基本都是界面操作手动发起Request并验证Response，所以难以和CI/CD集成，于是就出现了API自动化测试框架。

就是api自动化测试

基于代码的API测试用例

  1. 准备API调用时需要的测试数据；
  2. 准备API的调用参数并发起API的调用；
  3. 验证API调用的返回结果。

目前最流行的API自动测试框架是REST Assured，它可以方便地发起Restful API调用并验证返回结果

Web Service测试“自动化”

  1. 测试脚手架代码的自动化生成；
  2. 部分测试输入数据的自动生成；
  3. Response验证的自动化；
  4. 基于SoapUI或者Postman的自动化脚本生成

3.GUI测试自动化技术

  • 对于传统Web浏览器的GUI自动化测试，业内主流的开源方案采用Selenium，商业方案采用Micro Focus的UFT（前身是HP的QTP）；
  • 对于移动端原生应用，通常采用主流的Appium，它对iOS环境集成了XCUITest，对Android环境集成了UIAutomator和Espresso。

有留言分享 ： Rest-assured是一个非常适合，非常好用的API开源测试框架，我已经在我们项目里基于Spring-boot，Rest-Assured，Ccucumber开发了一个标准通用的微服务API自动化测试框架，我们项目里的所有微服务API都可以基于框架快速高效的在各个测试环境无缝切换进行自动化测试，并且完全集成到了公司的CICD Jenkins平台，以前从开发到单元测试，FVT测试，UAT测试，回归测试到MTP需要3天左右时间的Size的Story，现在相同工作量Size的Story只需不到一天时间就可以全部完成，期间除了产品代码开发和少部分特殊数据的准备，部分新增用例的开发外，全部都是在Jenkins上自动完成。

06章：测试覆盖率

测试覆盖率通常被用来衡量测试的充分性和完整性。

一类是面向项目的需求覆盖率，另一类是更偏向技术的代码覆盖率。

代码覆盖率

代码覆盖率是指，至少被执行了一次的条目数占整个条目数的百分比。

统计代码覆盖率的根本目的是找出潜在的遗漏测试用例，并有针对性的进行补充，同时还可以识别出代码中那些由于需求变更等原因造成的不可达的废弃代码。

高的代码覆盖率不一定能保证软件的质量，但是低的代码覆盖率一定不能能保证软件的质量。

代码覆盖率指标

  • 行覆盖率又称为语句覆盖率，指已经被执行到的语句占总可执行语句（不包含类似C++的头文件声明、代码注释、空行等等）的百分比。这是最常用也是要求最低的覆盖率指标。实际项目中通常会结合判定覆盖率或者条件覆盖率一起使用。
  • 判定覆盖又称分支覆盖，用以度量程序中每一个判定的分支是否都被测试到了，即代码中每个判断的取真分支和取假分支是否各被覆盖至少各一次。比如，对于if(a>0 && b>0)，就要求覆盖“a>0 && b>0”为TURE和FALSE各一次。
  • 条件覆盖是指，判定中的每个条件的可能取值至少满足一次，度量判定中的每个条件的结果TRUE和FALSE是否都被测试到了。比如，对于if(a>0 && b>0)，就要求“a>0”取TRUE和FALSE各一次，同时要求“b>0”取TRUE和FALSE各一次。

代码覆盖率工具

JaCoCo是一款Java代码的主流开源覆盖率工具。

posted @ 2020-12-28 23:10  火颜  阅读(139)  评论(0)    收藏  举报