测试基础


优秀的测试人员的基本素质

1、参与需求讨论,制订测试计划,确保测试能顺利执行并完成。

2、负责项目的功能性测试、用户体验测试、兼容性测试以及性能测试。

3、负责测试用例的编写;编写测试报告和对测试结果分析。

4、与开发人员、产品经理沟通和协作,推动整个项目的顺利进行;

5、负责软件开发团队项目进度管理工作。

6、熟悉Linux常用命令,熟悉常用数据库(mysql),熟练使用基本的SQL语句;

7、熟练使用LoadrunnerJmeter等至少一种性能测试工具。

 

 

1、软件测试。

定义:贯穿整个软件开发生命周期、对软件产品(包括阶段性产品)进行验证和确认的活动过程,

目的:尽快尽早地发现在软件产品中所存在的各种问题与用户需求、预先定义的不一致性。

软件开发的生命周期

  1. 客户提出需求

  2. 根据需求写出《需求文档说明书》

  3. 前端同事根据《需求文档说明书》设计效果图(原型图); 后端开发人员根据《需求文档说明书》设计与编写代码实现功能 ;测试人员也会根据需求文档编写测试计划和测试用例。

  4. d. 在后台开发实现功能后根据测试用例测试人员进行测试。

  5. e. 开发完全结束后测试人员进行整体测试,全面测试。测试成功后进入上线。

  6. f. 软件上线后,根据用户体验和实际效果,进行小版本迭代

 

 

2、程序测试包含哪些内容。

程序测试包括程序逻辑功能,界面,性能,易用性,兼容性,安装等测试,当然文档测试也算,排版,字体大小,也算程序测试的内容

 

 

3、软件缺陷产生的原因。
  1. 需求变更次数频繁,理解误差。 ->产品或客户

  2. 开发和设计,代码问题开发人员。 ->开发人员

  3. 运维 资源使用率产生。 -> 公司问题

 

4、测试流程。

测试流程:

  1. 在立项会上根据客户需求编写需求文档/规格说明书,ui设计原型图后台编码,测试人员编写测试计划和测试用例

  2. 随着开发的代码实现测试进行测试评审

  3. 主要代码实现后测试人员先进行冒烟测试

  4. 代码实现后测试执行测试用例

  5. 根据执行的结果进行对应bug提交给相对应的开发人员让其修改代码

  6. 开发修改后测试人员进行回归测试

  7. 直至项目上线后 测试人员编写测试总结用于下一个版本的迭代

冒烟测试: 在这个软件中主要的功能实现后进行测试 回归测试: 在开发人员修改后进行的同一个问题的测试

随机测试: 指测试中所有的输入数据都是随机生成的,其目的是模拟用户的真实操作,并发现一些边缘性的错误。

需求评审测试计划制定测试计划执行发布与测试报告总结
1、从用户体验角度提供设计建议。2、从开发经验角度,分析设计是否存在风险,是否能够实现。3、联合其他模块分析,设计是否存在漏洞,逻辑功能存在缺陷 。 1、测试用例设计。2、测试用例评审,和测试时间估计。3、测试资源申请 1、用例执行。2、Bug修复验证和推动版本进度。3、性能监控,压力测试,兼容测试 1、版本发布和线上质量监控,用户反馈实时响应。2、测试用例更新整合,测试计划评估。3、提供版本最终测试报告,包括用例覆盖率,bug数据分析等。
全程跟进需求变更,与产品无缝沟通,在测试阶段有需求变更要第一时间了解改动范围,如果影响版本的质量要说明风险,评估需求是否必须更改以及是否影响版本发布上线的时间线 规划测试项目需要的功能开发和自动化开发人员比例,规划整个测试流程需要的时间,要预留处理紧急事件的缓冲 执行协调测试资源,部署测试环境,督促开发和产品提供一切需要的测试工具,测试数据等,推动版本进度,每日进行bug review(bug复盘),标识出bug解决的优先级和提交测试的时间点,每日提供当日产品质量报告 报告项目发布上线后,对整个版本的bug进行数据分析,总结出用例的覆盖率,对于没有覆盖到用例的bug,转化成用例,同时测试人员之间进行分享,针对新接触的测试方法测试工具和有价值的bug进行经验总结

测试用例的设计方法主要有黑盒测试法白盒测试法。(后有详解)

黑盒测试:也称功能测试,黑盒测试着眼于程序外部结构,不考虑内部逻辑结构,主要针对软件界面和软件功能进行测试。

白盒测试:又称结构测试、透明盒测试、逻辑驱动测试或基于代码的测试。白盒法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。

 

 

5、软件测试分类。

 

  1. 按阶段划分:

    1. 单元测试 :对一个模块测试 。

    2. 集成测试 :对多个模块测试(有一定的关联)。

    3. 系统测试 :在软件编译后执行的整体测试。

    4. 验收测试 :对软件执行后的用户体验的测试 。

    1. α 阿尔法测试 :有一定的开发测试人员的测试 =>内测

    2. β 贝塔测试 :只有用户参与的测试 => 公测

 

  1. 按是否运行程序划分。

    1. 静态测试 :UI设计图

    (不需要执行代码或是运行程序就可以进行测试,只是静态的检查程序代码、界面或者文档中可能存在的错误的过程。)

    1. 动态测试 :有执行代码过程中产生的问题

    (实际运行被测程序,输入相应的测试数据,检查实际输出结果和预期结果是否相符的过程。)

 

  1. 是否查看源代码方式划分。

    1. 黑盒测试 :不看源代码结构,只关心外观和能否输入输出以及响应时间。

    2. 白盒测试 :只看代码结构以及代码实现方式。

    3. 灰盒测试 :介于黑盒和白盒之间一种。

 

  1. 在还不运行的情况下(黑盒测试)划分。

  2. 功能测试 细分:逻辑功能测试,界面测试,易用性测试,安装测试,兼容性测试。

  3. 性能测试:压力测试负载测试一般性能稳定性测试

 

Tips

  1. 压力和负载测试

 

  1. 性能测试表

 

 


 

面试题: 对任意物品的测试

回答思路:

  1. 功能上 体积 形状 用途 材质

  2. 界面上 颜色 图案

  3. 性能上

  4. 易用性

  5. 安全性


 

 

6、软件生命周期模型。

 

  1. v摸型

     

    V 模型的左边下降的是开发过程各阶段,与此相对应的是右边上升的部分,即各测试过程的各个阶段。

    V 模型的优点在于它非常明确地标明了测试过程中存在的不同级别,并且清楚地描述了这些测试阶段和开发各阶段的对应关系。

    V模型的缺陷及解决思路

    V模型仅仅把测试过程作为在需求分析、系统设计及编码之后的一个阶段,忽视了测试对需求分析,系统设计的验证,需求的满足情况一直到后期的验收测试才被验证。

    解决的思路是,当一个软件开发的时候,研发人员和测试人员需要同时工作,测试在软件做需求分析的同时就会有测试用例的跟踪,这样,可以尽快找出程序错误和需求偏离,从而更高效的提高程序质量,最大可能的减少成本,同时满足用户的实际软件需求。

  2. w模型

     

    相对于V模型,W模型更科学。W模型是V模型的发展,强调的是测试伴随着整个软件开发周期,而且测试的对象不仅仅是程序,需求、功能和设计同样要测试。测试与开发是同步进行的,从而有利于尽早地发现问题。

  3. 螺旋模型

     

    图中的螺旋线代表随着时间推进的工作进展;开发过程具有周期性重复的螺旋线形状。4个象限分别标志每个周期所划分的4 个阶段:制定计划、风险分析、实施工程和客户评估。螺旋模型要点:统一了瀑布模型与原型模型,与增量模型相似,更强调风险分析。

    1.软件分多个版本开发,每个版本就是一次螺旋。

    2.每个版本按照这样的顺序进行:

    1)确定软件目标,选取定实施方案,弄清项目开发的限制条件;(图中左上象限)

    2)分析所选取方案,考虑如何识别和消除风险;(图中右上象限)

    3)实施软件开发;(图中右下象限)

    4)评价开发工作,提出修正建议,调整计划。(图中右下象限、左下象限)

    3.需求不是一次获取和实现的,通过多个螺旋来完善。

    4.计划也不是一次成型的,每次螺旋都需要调整。

     

    优点

    1)设计上很灵活,可以在项目的各个阶段进行变更;

    2)以小的分段来构建大型系统,使成本计算变得简单容易;(国企项目)

    3)客户始终参与每个阶段的开发,保证了项目不偏离正确方向以及项目的可控性;

    4)随着项目推进,客户始终掌握项目的最新信息 , 从而能够和管理层有效地交互;

    5)客户认可这种公司内部的开发方式带来的良好的沟通和高质量的产品。

     

    缺点

    螺旋模型强调风险分析,但要求许多客户接受和相信这种分析,并做出相关反应是不容易的。

    因此,这种模型往往适应于内部的大规模软件开发。该模型建设周期长,而软件技术发展比较快,所以经常出现软件开发完毕后,和当前的技术水平有了较大的差距,无法满足当前用户需求。

     

7、敏捷开发和测试。

 

敏捷开发是针对传统的瀑布开发模式的弊端而产生的一种新的开发模式,目标是提高开发效率和响应能力。敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。

 

由于版本节奏比较快,开发与测试几乎并行,一个版本周期内会有两版在推动,也就是上图中提到的波次发布,波次发布用于尝试新加入的功能,做小范围快速的开发,验证和发布,为下个大版本的功能做实验和调研。快速发版的需求要求测试快速响应,敏捷测试模式适应项目需求。

 

模型优势*:

工作任务划分清晰,工作效率较高

与开发和产品沟通紧密,团队协作性强

测试介入到整个项目的所有会议中,对整体版本信息情况把控全面

迅速占有市场,添加新的功能,吸引更多用户使用,提升用户体验度

 

模型的缺陷

模块提交较快,测试时较有压迫感

项目规划要合理,不然测试时会出现复测的现象,加大工作量

 

 

8、测试部门的组织结构。
     一般在公司内部有的部门:  人事  财务  开发(前端 后台  移动端 测试)  市场(产品)  运维(产品维护的服务)
  开发,测试 1个测试对应5个开发 1个前端 3个后台 1个移动端
  ceo 首席执行官
  CTO 首席技术执行官
  CFO 首席财务执行官
  COO 首席运营执行官
 
  UI
  ANDROID
  IOS
  QA
  TS
  DBA
  UE
  RD
 
  总监
  项目经理:pm
  组长:
  组员:
  产品经理:
9、测试工具。
  1. World文档 测试计划 测试用例 缺陷报告

  2. 接口工具 charles Fiddler postman

  3. 性能工具 Jmeter Loadrunner

  4. bug管理工具 禅道 QTP

  5. 自动化管理工具 selenium appnium untest pytest

  6. 云测工具 Testing

没有结果就是最好的结果。 -Linux哲学
原文地址:https://www.cnblogs.com/Stubbornlyn/p/13158336.html