软件测试理论

Vinkey_Z
301 阅读13分钟

提前声明，以下纯属个人实习过程中的个人经验，如有不同或觉得不合理的地方，请和平交流

qt4s接口自动化新手入门

QTA是一个兼测试框架和测试平台的工具；
QT4C：面对Windows
QT4A：面对安卓
QT4i：面对IOS
QT4W：面对WEB端
QT4S：面对后台

接口自动化主要是面对后台，所以主要使用QT4S。

测试阶段

软件测试总共要经历4个阶段：单元测试、集成测试、系统测试、验收测试

  1. 单元测试：单元测试是以最小单位的测试、也是最初期的测试阶段、一般是以一个函数方法窗口、一个功能模块、都可以看做是一个单元，主要依据的是详细设计文档。主要以白盒为主，一般有开发人员完成
  2. 集成测试：又称组装测试，在单元测试的基础上把软件逐渐组装起来一起继续测试的过程。包括单元之间接口的连接，以及子系统。逐渐组装的过程中会出现很多临时版本(迭代测试)。集成测试主要以黑盒为主(当然接口测试也在这阶段进行) 压力测试在这个阶段进行。
  3. 系统测试：整个功能全部完成后对集成了硬件和软件的完整系统进行模拟真实的环境模拟、测试重点主要在于 1)整个系统能否正常运行 2)整个系统的兼容性测试
  4. 验收测试：在用户的角度对产品进行验收 1)alpha阶段:在软件开发过程中由最终用户对软件进行检查 2)beta阶段:在最终用户的实际环境中由最终用户对软件进行检查 两者的区别：

1、测试时间不同： Beta测试是软件产品完成了功能测试和系统测试之后，在产品发布之前所进行的软件测试活动，它是技术测试的最后一个阶段。 alpha测试简称“α测试”，可以从软件产品编码结束之时开始，或在模块(子系统)测试完成之后开始，也可以在确认测试过程中产品达到一定的稳定和可靠程度之后再开始。 2、测试的目的不同： α测试的目的是评价软件产品的FLURPS（即功能、局域化、可用性、可靠性、性能和支持）。尤其注重产品的界面和特色。α测试即为非正式验收测试。 Beta测试是一种验收测试，通过了验收测试，产品就会进入发布阶段。 3、测试人员及场所不同： α测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试，α测试不能由程序员或测试员完成。α测试发现的错误，可以在测试现场立刻反馈给开发人员，由开发人员及时分析和处理。 Beta测试由软件的最终用户们在一个或多个客户场所进行。开发者通常不在Beta测试的现场，因Beta测试是软件在开发者不能控制的环境中的“真实”应用。

测试计划

  1. 测试的周期
  2. 测试的具体内容:功能、接口、UI等
  3. 测试的人员，工作安排

测试基类

在基类中封装一些通用的方法和操作，测试用例继承此基类，可以复用代码

bug等级

  1. 致命
  2. 严重
  3. 一般
  4. 界面问题
  5. 建议性问题

逻辑覆盖

属于白盒测试：白盒测试也称结构测试或逻辑驱动测试

以下内容覆盖率从弱到强

  1. 语句覆盖：程序里的每条可执行的语句都要至少执行一次；不涉及到语句里面的判定分支
if A and B == true then Action1
if C or D == true then Action2
testcase: A == true B == true C == true D == false便可以执行
  1. 判定覆盖：每个判断的真假分支至少执行一次，就是真要至少取一次，假要至少取一次
if A and B == true then Action1
if C or D == true then Action2
testcase1: A == true B == true C == true D == false(两个都执行)
testcase2: A == false B == true C == false D == false(两个都不执行)
  1. 条件覆盖：每个判定中的每个条件可能至少满足一次，也就是每个条件至少要取一次真的，再取一次假的。
if A and B == true then Action1
if C or D == true then Action2
就是ABCD都要有true和false的情况
testcase1: A == true B == true C == true D == true
testcase2: A == false B == false C == false D == false
  1. 判定-条件覆盖：包括条件覆盖、判定覆盖
  2. 条件组合覆盖：每个判定中的每个条件至少出现一次
  3. 路径覆盖：概念比较好理解，把所有可能路径至少都走一遍

内点、上点、离点

  • 上点：边界上的点
  • 离点：离上点最近的点
    • 如果是闭区间，离点是区域范围外离上点最近的点
    • 如果是开区间，离点是区域范围内离上点最近的点
  • 内点：区域范围内的点

上点是有效数据时，离点是无效数据

上点是无效数据时，离点是有效数据

测试用例

  1. 用例名采用首字母大写命名法，必须以“Test”结尾，单词尽量少而意义明确，避免使用And、Of这样的连词。
  2. 用例每个步骤需要用start_step来描述

软件开发 生命周期

  1. SDLC ：需求阶段、设计阶段、建设/发展阶段、测试阶段、部署/交付阶段、维护阶段
  2. alpha测试和beta测试的区别
  • **Alpha测试：**Alpha测试（α测试）是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试，可以在测试现场立刻反馈给开发人员，由开发人员及时分析和处理。功能,局域化,可使用性,可靠性,性能和支持
  • **Beta测试：**是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。在Beta测试中，由用户记下遇到的所有问题，包括真实的以及主管认定的，定期向开发者报告，开发者在综合用户的报告后，做出修改，最后将软件产品交付给全体用户使用。β测试是在开发者无法控制的环境下进行的软件现场应用.
  • α、β、λ常用来表示软件测试过程中的三个阶段，α是第一阶段，一般只供内部测试使用；β是第二个阶段，已经消除了软件中大部分的不完善之处，但仍有可能还存在缺陷和漏洞，一般只提供给特定的用户群来测试使用；λ是第三个阶段，此时产品已经相当成熟，只需在个别地方再做进一步的优化处理即可上市发行。

软件测试 生命周期

  1. STLC: 需求分析：
  • 进入条件：提供应用程序体系结构文档和验收标准
  • 活动行为：列出要执行的所有类型（性能、功能、安全），环境详细、和测试用例的必要工具。
  • 交付成果：列出测试要求和测试环境详细信息的所有必要测试。
  1. 测试计划
  • 进入条件-需求文档活动行为-定义目标依、软件的范围。列出测试的方法
  • 测试环境的解决。准备测试计划和控制程序。角色和责任的确定。列出测试可交付成果，定义风险(如果有)。
  • 交付成果-测试策略文档
  1. 环境设置
  • 开发环境：由开发人员进行分支开发的环境，开发完成后合并代码
  • 测试环境：贴近于生产环境的环境，用于测试人员发现bug(多数功能型bug)在此发现
  • 预发布环境：如果是代码打包发布，不需要这一步，因为测试环境和现网环境的代码是一样的；如果是git分支代码发布，则需要这一步；

Dev：开发分支，开发人员开发和自测的代码分支

Test：测试分支，开发人员开发完转测功能合并代码的分支

release：预发布分支：测试环境测试通过后，开发人员将代码合并的分支，测试通过后，运营会将此分支代码发布到线上环境；

master：上线通过后，把这个迭代功能的代码合并的分支，新开发功能再从master分支上拉代码进行新的开发；

预发布环境作用： 预发布环境是正式发布前最后一次测试，所有的功能和配置，数据库都已经与线上环境高度相似，仅准入本次需要上线的功能代码，测试人员确认代码在测试环境经过测试用例测试没有问题后，提交预发布环境进行测试。因为在少数情况下即使预发布通过了，都不能保证正式生产环境可以100%不出问题； 预发布环境的配置，数据库等都是跟线上一样；有些公司的预发布环境数据库是连接线上环境的，危险。 预发布环境连接到数据库和现网环境高度相似。

  1. 测试用例
  2. 缺陷记录
  3. 测试周期

软件质量保证(也称为QA)

软件测试 黑盒测试

  1. 决策表技术：电子邮箱和密码登录。电子邮件和密码都是条件，预期结果是操作。在第一个条件下，如果电子邮件和密码都正确，则应将用户定向到帐户的主页。 在第二种情况下，如果电子邮件正确，但密码不正确，则该功能应显示“密码不正确”。在第三种情况下，如果电子邮件不正确，但密码正确，则应显示“电子邮件不正确”。
  2. 边界值分析：它用于测试边界值，因为边界附近的输入值具有较高的误差机会。
  3. 状态转化技术：三次试错机会，三次过了，（像账户被锁定，不能登录）
  4. 成对测试技术：

软件测试 白盒测试

白盒测试又称玻璃盒测试、结构测试、开箱测试和透明盒测试。 透明框或白框或透明框名称表示能够透过软件的外壳进入其内工作。

单元覆盖率

  1. 新增代码被单元执行覆盖的行数 / 新增代码行数 = 代码覆盖率
  • 在函数A里面新增了一行代码，在代码执行过程中能执行到这一行新增的代码，可以理解为这一行代码被覆盖。
  • 空格、注释目前在计算范围内

TestBase

  1. assert_match和assert_equal的区别是，assert_match使用的是正则匹配而不是严格匹配，比如: self.assert_equal("严格匹配断言", "XXX", "X*") 以上的断言是不通过的，但是对于下面的正则断言是通过的: self.assert_match("正则匹配断言", "XXX", "X*") assert_match和assert_equal相比，还有一个区别就是，assert_match只支持字符串或字符串兼容的类型的值的检查；但是assert_equal可以支持大部分类型的值的检查。 注解：对于断言失败的执行逻辑处理，这个是QTA测试框架和其他一般测试框架比较大的差异点，设计测试用例是需要注意。
  2. QTA执行用例的接口是先执行run_test，然后执行post_test；而且即使测试用例执行run_test中发生异常，仍会执行post_test，这样就保证了测试环境的清理操作。
  • QTA会依照以下顺序执行测试用例的三个接口:
  • pre_test
  • run_test
  • post_test

且任意一个接口执行异常，QTA仍然会执行下一个接口。 注解 由于历史原因，QTA还提供另一套代码风格的接口preTest、runTest和postTest，建议测试用例编写时选择测试项目存量代码统一的代码风格，如果是新的测试项目还是建议使用lower_with_under的代码风格。 警告 在一个测试用例中仅支持一套代码风格的接口，QTA选择接口的代码风格是基于run_test/runTest选择的风格为主，也就是说如果用例定义了runTest，则只会执行preTest和postTest，但不会执行pre_test和post_test。当run_test和runTest两个接口都存在的时候，QTA优先选择run_test接口来执行。

k8s-pod概念介绍

  1. 基本框架
  2. 状态介绍
  • 节点状态：即k8s中的pod状态，共包含Pending、Running、Succeeded、Failed、Unknown五种状态

Pending: pod 已被 Kubernetes 系统接受，但有一个或者多个容器镜像尚未创建。等待时间包括调度 pod 的时间和通过网络下载镜像的时间。 Running 该 pod 已经绑定到了一个节点上，pod 中所有的容器都已被创建。至少有一个容器正在运行，或者正处于启动或重启状态 Succeeded pod 中的所有容器都被成功终止，并且不会再重启，结束状态 Failed pod 中的所有容器都已终止了，并且至少有一个容器是因为失败终止。也就是说，容器以非0状态退出或者被系统终止 Unknown 因为某些原因无法取得 pod 的状态，通常是因为与 pod 所在主机通信失败

  • 容器状态：即K8s中的container状态，共包含Waiting、Running、Terminated三种状态

Waiting 启动到运行中间的一个等待状态，如果长期处于该状态，则需要跟进原因

Running 运行状态

Terminated 终止状态,删除或者异常退出状态

  • 进程状态：容器内的process状态，共包含Active、Inactive、unknown三种状态，

Active 进程存在，依赖服务设置的进程监控，可能有进程监控间隔的间隔

Inactive

进程不存在，依赖服务设置的进程监控，可能有进程监控间隔的间隔

unknown 服务未下发进程监控任务<原因可能是扩容，发布时执行start/stop脚本返回非0>

  • 服务状态：最终的结果状态，也体现在service状态上，共包含healthy/unhealthy/unknown等状态，

依赖平台从北极星查到的service状态，如果服务service在北极星侧没有注册则为unknown; 123平台上的trpc服务默认全部开启healthy检测 123平台上的trpc服务默认三秒上报一次状态，三轮未上报则为unhealthy

界面详细状态展示

界面的详细状态展示会按照前面的图从左到右依次细致化，当底层出现问题时，优先展示底层状态：例如当pod创建成功，container正处于创建中，则整体状态展示为：Waiting。

avatar
文章
阅读
粉丝