项目流程
客户提出要求,需求人员把要求整理成需求文档,开发人员根据需求文档进行开发,测试人员根据分析需求编写测试用例,之后,测试人员进行测试工作。存在问题提交bug单,开发人员修改问题,测试人员进行复测,直到所有的需求都没有问题,项目提交给客户,项目结束。
软件测试流程
测试经理把需求分配给测试人员,测试人员接到需求后,会对该需求进行评审,评审需求规则是否存在问题,没有问题后测试人员先对最终确认下来的需求文档进行了解和分析,然后根据需求文档所有文档规则编写测试用例,并进行测试用例评审,评审通过后测试人员正式开始根据测试用例进行测试,存在问题的测试点提交缺陷单给开发,开发进行修复后测试人员进行复测,直到所有测试用例执行完毕,最终编写测试报告,该项目的测试工作结束。
评审的定义
在正式会议上将项目的成果,提交给用户以及客户或相关部门对软件产品进行评审和批准
需求评审
需求人员对需求文档进行讲解测试人员和开发人员对需求文档所有规则进行检查,存在问题和需求人员沟通的过程。
用例评审
一般分为两种,组内评审和租外评审
组内评审时测试人员把测试用例交给测试经理后,测试经理把测试用例分给组内的其他成员进行相互分析的过程。
组外评审,是由开发,产品,测试三方共同对测试用例进行的一个检查评审
Bug单的处理流程
测试人员提交缺陷到缺陷管理系统给对应开发人员,形成缺陷单,状态为<新建>状态;开发人员处理缺陷,并把缺陷单修改为<已修改>状态;测试人员进行复测如果有问题,则状态变更为<重新打开>,没有问题后把所有的缺陷单状态改为<关闭>状态。
第二章
软件测试的定义
测试即检测、试验、利用一切手段,检测被测对象特性表现与预期需求一致。对于软件而言,测试是通过人工或者自动化的检测方式,测试被测对象是否满足用户需求,或弄清预期效果与实践效果之间的差异的活动。
软件测试的目的
实施软件测试的目的通常有以下几个方面:
- 发现被测对象与用户需求之间的差异,即缺陷。通过测试活动发现并解决缺陷,增加人们对软件质量的信心。
- 通过测试活动了解被测对象的质量状况,为决策提供数据依据。
- 通过测试活动累积经验,预防缺陷出现,降低产品失败风险。
软件测试的原则
- 保证程序与相应的需求文档功能要求一致
- 不可能进行穷尽测试
- 测试应尽早启动、尽早介入
- 缺陷存在群集现象
- 杀虫剂缪论
- 不同的测试活动依赖不同的测试背景
- 不存在缺陷的缪论
软件测试检查的内容
- 保证程序与相应的需求文档功能一致
- 发现软件中的缺陷
- 确保软件做必要的事情
- 明确系统在失败前可以让系统正常运行到何种程度
- 明确发给用户的系统中有哪些风险
软件测试的对象
不同的研发阶段,软件测试的对象是不尽相同的。
在需求设计阶段,原始需求是测试工程师的测试对象,通过对需求的检查,发现需求的正确性、歧义性、完整性,一致性等方面的问题。
在产品开发阶段,测试工程师的主要进行的是单元、集成、系统方面的测试。
在系统的验收阶段,测试工程师主要是对系统测试中的主功能方面的测试。
软件测试的生命周期
- 制定测试计划2.设计测试用例3.事实软件测试4.提交缺陷单5.测试报告6.版本发布
测试计划;一般由测试经历编写,是规定一个项目或一个大的需求的测试的参与人员,各人员负责测试的模块,各人员负责模块对应需求的分析、测试用例的编写,以及各个模块测试执行制定严格的时间计划。
测试用例;把需求文档的每一项规则该怎么检查和测试编写一条记录,该记录即为测试用例
缺陷单:在测试检查中把出现的问题记录到一个bug管理系统并生成一个文件记录,该记录为缺陷单。
测试报告:测试完成后,测试人员需要吧测试遇到的所有问题,以及本次测试的内容、范围,本次版本中未解决的问题与本次测试相关内容有效记录下来形成一个文档,该文档即为测试报告
需求文档:产品人员/需求人员根据客户的有效需求,整理成对应的文档。
按阶段测试而言
- 单元测试2.联调测试3.接口测试4.系统测试(功能测试)5.验收测试
按测试种类而言
- 功能测试2.接口测试3.自动化测试4.性能测试5.安全测试
按功能测试执行或者接口测试执行过程而言
冒烟测试 系统测试
名词解释
黑盒测试:又叫功能测试,把被测程序看做一个黑盒子,不要考虑其他,只要知道这个软件程序(软件系统)的输入和输出关系即可
白盒测试:或基于程序本身的测试,把被测程序当作一个白盒子,需要把盒子打开,只需要关注程序内部的结构是否存在问题。比如单元测试,就是白盒测试。
灰盒测试:把被测程序堪称一个半透明的盒子,介于黑盒和白盒之间,既关注输入和输出关系,又关注代码运行逻辑。接口测试可以理解为简单的灰盒测试。
单元测试:对程序最小单元模块测试的过程,一般是对代码进行逐步检查和测试,难度较大,需要有一定语言基础。一般是由开发自己完成
集成测试:对关联借口之间、各个关联系统之间通过接口测试工具测试的过程。开发之间的测试叫联调测试,测试做的就叫接口测试。
功能测试:对可视化界面系统或软件(APP)进行手动操作,通过各种测试方法、测试思维进行逻辑操作,验证测试系统或软件(APP)是否存在有问题的过程。
自动化测试:通过编写一些自动化脚本Python,对系统已有功能(已经测试过的功能)进行回归性的测试(再次测试)。一般分为功能自动化和接口自动化。
回归测试:在系统测试结束后,对系统的老功能进行的再次测试
性能测试:主要是对系统性能方面进行的测试,通过使用一些性能测试工具,编写一些性能测试脚本进行的测试。
验收测试:一般由产品人员配合测试人员完成的验收测试,是产品人员用来检查软件产品是否符合设计需要所进行的一轮测试工作。
安全测试:在安全的角度上,检察系统的漏洞,评估系统当中可能会出现的风险。
线上测试:在产品上线之后,对产品本期新增的功能进行的一轮测试,防止产品在上线后出现新的问题。
环境:1.开发环境2.测试环境3.上线环境4.生产(线上或用户)环境软件版本流转过程
开发环境→测试环境(ST测试环境)→UAT测试环境→预上线测试环境→生产环境
CMMI模型
- 初始级2.可管理级3.已定义级4.量化管理级5.优化管理级
第三章
Bug产生的原因
- 人员与人员之间的沟通不够2.程序本身就存在问题3.软件的复杂性4.需求不断变化5.文档的不完善6.开发周期短7.开发水平参差不齐
缺陷的定义
在软件使用过程中所出现的任何问题,或者设计的软件不能符合用户需求文档要求而产生的问题称之为bug。
缺陷单(bug单或缺陷报告)内容:
- 软件名称2.测试人员3.指派处理人(开发人员)4.严重级别5.优先级6.缺陷概述7.详细描述(前置条件、操作步骤、预期效果、实际效果)8.版本号9.附件
缺陷的严重级别和优先级别
- 严重2.中等3.普通1.高2.中3.低
bug单状态和用途
- 新建2.已修改3.重新打开4.已关闭
- 记录缺陷2.缺陷分类和管理3.缺陷的跟踪
测试结束的标准
- 所有用例执行完毕
- 所有的bug修复并复测完毕
测试用例的目的
- 记录测试进度2.防范测试流程3.防止测试遗漏
代码/版本的发布
一般都是在每周或者每两周或每个月的周四或周五
版本/代码发布时间
一般是1个月左右发布一次新版本,一般是1个月两个版本,或者一个月更新4个版本
测试跟开发的人员配比
1:4的比例一个测试对应四个开发
测试和开发的耗时配比
1:1
如果产品已经上线,出现了bug怎么办?
- 详细的记录并提出缺陷
- 找到bug的复现路径
- 同开发一起,定位bug的问题,是前端还是后端问题
- 评估影响范围及修复难度
- 做好总结和反思
如果产品即将上线,发现bug怎么办
- 找开发协商,是否加班修复bug2.请示项目负责人是否延长上线3.请示是否可以以后版本解决,先不上次功能4.先进性上线,记录bug后继续进行补丁修改
如何应对不能重现缺陷的问题
对于无法重现的缺陷,应对这样的缺陷需要进行详细的记录,并提交给开发人员或项目负责人,同时合理的安排时间进行该问题的测试,不影响其它的测试工作。
对于不能重现的bug,一般测试到什么程度自动认为没有这样一个bug?
一般对于不能重现的bug,如果在后续两个版本内均无法复现该bug,此时自动认为该bug已经被修复;如果两个版本内可以复现该bug,找开发解决即可。
验收测试(α测试,β测试)
α测试:由开发人员或测试人员在场,可随时记录下错误和使用中出现的问题,一般由开发完成
β测试:开发人员和测试人员都不在场,一般由最终用户或其他人员完成
开发模型
敏捷迭代模型
这个模型相对比较灵活一些,可以一整个开发的系统分成若干个模块,每个模块独立进行开发,开发后即可使用。