目录

测试相关概念输入

[TOC]

CI/CD

参考:https://www.zhihu.com/question/23444990

最近看了一篇文章 The Product Managers' Guide to Continuous Delivery and DevOps 文中对「持续集成(Continuous Integration)」、「持续交付(Continuous Delivery)」和「持续部署(Continuous Deployment)」这三个概念有很详细的解释。这里借用文中的插图,说一下我对这三个概念的理解。

持续集成

http://img.cana.space/picStore/20211006104905.png

持续集成强调开发人员提交了新代码之后,立刻进行构建、(单元)测试。根据测试结果,我们可以确定新代码和原有代码能否正确地集成在一起。

持续部署

持续部署在持续集成的基础上,将集成后的代码部署到更贴近真实运行环境的「类生产环境」(production-like environments)中。比如,我们完成单元测试后,可以把代码部署到连接数据库的 Staging 环境中更多的测试。如果代码没有问题,可以继续手动部署到生产环境中。

持续交付

http://img.cana.space/picStore/20211006105011.png

持续交付则是在持续部署的基础上,把发布到生产环境的过程自动化。

我个人觉得持续集成、持续部署,持续交付非常值得推广。开发过程中最怕集成时遇到问题导致返工,而持续集成、持续交付、持续部署恰恰可以早发现早解决,从而可以避免这个问题。


作者:赵劼 链接:https://www.zhihu.com/question/23444990/answer/26995938 著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

集成是指软件个人研发的部分向软件整体部分交付,以便尽早发现个人开发部分的问题; 部署是代码尽快向可运行的开发/测试节交付,以便尽早测试; 交付是指研发尽快向客户交付,以便尽早发现生产环境中存在的问题。 如果说等到所有东西都完成了才向下个环节交付,导致所有的问题只能再最后才爆发出来,解决成本巨大甚至无法解决。 而所谓的持续,就是说每完成一个完整的部分,就向下个环节交付,发现问题可以马上调整。是的问题不会放大到其他部分和后面的环节。

这种做法的核心思想在于:既然事实上难以做到事先完全了解完整的、正确的需求,那么就干脆一小块一小块的做,并且加快交付的速度和频率,使得交付物尽早在下个环节得到验证。早发现问题早返工。

举个例子,你家装修厨房,其中一项是铺地砖,边角地砖要切割大小。如果一次全切割完再铺上去,发现尺寸有误的话浪费和返工时间就大了,不如切一块铺一块。这就是持续集成。 装修厨房有很多部分,每个部分都有检测手段,如地砖铺完了要测试漏水与否,线路铺完了要通电测试电路通顺,水管装好了也要测试冷水热水。如果全部装完了再测,出现问题可能会互相影响,比如电路不行可能要把地砖给挖开……。那么每完成一部分就测试,这是持续部署。 全部装修完了,你去验收,发现地砖颜色不合意,水池太小,灶台位置不对,返工吗?所以不如没完成一部分,你就去用一下试用验收,这就是持续交付。 -——————- 补充:从敏捷思想中提出的这三个观点,还强调一件事:通过技术手段自动化这三个工作。加快交付速度。

接口测试/单元测试/功能测试

接口测试是一个比较宽泛的概念, 近几年在国内受到很多企业和测试从业者的追捧, 尤其是上层的UI在取悦用户的过程中迭代更新加快, UI自动化维护成本急剧上升的时代, 大家便转向了绕过前端的接口层面进行测试. 但是很多人, 对接口测试的理解并不完整, 事实上, 我们无论通过何种方式运行一段程序, 都必须调用该程序的接口才能实现.

比如, 我们通过登录页面输入账号和密码, 点击 登陆按钮, 最终该操作会被封装成一个HTTP请求, 发送给后台服务器, 后台服务器会直播调用登录接口, 来运行登陆的实际代码.

在这个过程, 点击"登录"按钮是一个前端界面, 如果通过该方法来观察其运行状态, 那么我们就称之为界面级的黑盒测试, 俗称"点点点". 我们也可以利用各种工具, 比如Fiddler, Postman, SoupUI, 甚至使用代码发送数据给后台服务器, 进而观察其运行结果的, 这些, 我们称之为协议级的接口测试. 这部分是大家经常提级的接口测试, 我就不再继续赘述了.

当然, 我们还可以从代码层面来直播调用该登录接口, 那么 此时就称之为代码级的接口测试.

我们大概率是拿不到源代码的, 但是可以拿设计文档, 这几个方法所需要的参数, 以及类型都是可以拿到

由于我们只是调用接口, 只是接口的层次已经更接近底层代码了, 但是依然看不到代码, 所以, 我们依然需要使用用例的设计方法去设计我们的传入参数, 对div这个方法进行演示:

  • 整数相除
  • 小数相除
  • 除数为0
  • 输入字符串
  • 输入特殊字符
  • 超长的数字
  • 被除数为空
  • 除数为空
  • ………

以上, 有没有发现, 像极了使用等价类对页面的输入框进入用例设计. 是的, 没错.

因此, 我们就可以直接调用这些方法, 使用设计好的数据对它进行测试

最后, 我们还可以深入到代码实现层, 对代码的实现逻辑进行详细的测试, 常用的方法有

  1. 语句覆盖
  2. 判定覆盖
  3. 条件覆盖

我们又称之为白盒测试单元测试

看到了吧, 这三种测试方法:

  1. 黑盒测试(从UI去)
  2. 协议级的接口测试(发送HTTP请求)
  3. 代码级的接口测试

以上方法的测试, 整个过程唯一的区别公在于我们调用该计算器的方式不一样, 最终真正工作的, 都是同样的一段代码, 这个本质是绝对不会因为被调用的方式不同而发生一丁点儿的变化. 所以, 任何一种调用的方式, 都在驱动程序运行而已, 本质上来说, 他们所做的事情没有任何区别.

因此, 正是因为接口测试的所谓接口, 是一个不太容易下定义的概念, 所以我们千万不能盲目地认为, 只有协议级的测试才是接口测试, 或者代码级的测试才是接口测试, 这些理解都太过绝对. 事实上, 通过页面上的操作, UI-User Interface, 用户界面, 直译用户接口, 这些页面的操作入口, 也是一个一个的接口啊. 所以, 请大家不要纠结于概念本身, 本文不是要去教大家如何*抬杠*, 而是明白, 我们的测试确实可以多样化, 可以更多地专注于从不同角度来完成对一个功能的测试, 进而达到更全面的测试覆盖, 尽早地找出Bug才是王道.

预祝各位测试人员产品上线都都能睡个好觉~

自动化测试

从测试的行为本质上去分析,功能测试和自动化测试没有区别。唯一的却别,一个是人工操作,一个是由代码工具执行。

许多朋友会认为有了自动化,你可以坐等测试报告,但是没有这样的事情。因为可以做自动化项目,必须经过多次测试,而且框架和功能相对稳定,可以编写自动化测试代码;不能说,如果你掌握了自动化,你就能达到人生的巅峰。主要还是看自动化框架在公司是否实用,对于公司项目而言,如果产品三天一小改,半月一大改,那自动化也就只能说说而言,可能你自动化脚本才刚开始起步,然而产品就已经有所改动了。所以自动化测试也是一种辅助的方式,最重要的是一切要以做好功能测试为前提。