软件测试概念和基础

一、什么是需求

满足用户的期望  或  规定的文档(合同,标椎,规范)所需要的条件和权能,包含用户需求和软件需求

注册登录方式

1.第三方注册/登录(wechat qq  微博)

2.手机号注册/登录

3.账户、密码注册登录

二、什么是bug

(1)当且仅当规格说明(软件需求)存在,并且正确,如果程序和规格说明不相符,就是软件缺陷

(2)如果没有规格说明,当且仅当用户需求存在并合理,如果程序和用户需求不相符,就是软件缺陷

三、测试用例

就是向被测试系统发出的一系列的集合,包含测试数据,测试环境(软,硬),操作步骤,预期结果等

 

标题,测试模块,重要性,前提条件等

网易邮箱登录测试用例

标题:网易邮箱登录成功测试用例

测试模块:登录模块

前提条件:注册得到账户

重要性:重要性

 

测试数据:正确的用户名+密码

测试环境:Chrome

操作步骤:                                                                    预期结果

1.打开网易邮箱登录页面                                             出现登录页面

2.输入正确用户名+密码,点击登录按钮                        登录成功,进入邮箱主页面

三、软件开发模型

1.软件开发的生命周期:需求分析-->计划-->设计-->编码-->测试-->运行维护

2.瀑布模型:

优点:强调开发的阶段性早期计划和需求调查

缺点:风险至后期测试阶段显显示,失去及早纠正的机会

适合:项目小,前期需求明确,风险小的项目

3.螺旋模型

适合项目:项目庞大,前期需求不是很明确,风险比较大的项目

4.增量,迭代

系统A,B,C,D四个业务模块,2周时间

增量模型:第一周完成AB两个功能模块,第二周CD两个功能模块

迭代模型:第一周完成ABCD四个业务模块的基本框架和基本功能,第二周完成比较复杂的

敏捷(Scrum方法)角色:

PO:  客户的代表,负责把用户需求转换成user story

SM:  项目经理,负责管理流程,保障会议的召开

ST:  研发团队交付一个高质量可用的软件

Scrum流程:

    发布计划会议(PO)  ：PO整理user story，讲解user story

   迭代计划会议： ST对user story进行任务分解，每个开发人员领取任务

   每日站会(三件事),

   演示会议,：向客户展示开发的成果

   回顾会议：ST扬长避短（修正）

轻流程,轻文档,重目标,重产出

轻量级:迭代周期短,参与人员少

敏捷中的测试:测试用例的作用减弱,主要用思维导图整理测试思路,要运用探索性测试

                      测试人员和开发人员关系紧密,测试人员不仅要找BUG还要和开发人员一起找BUG产生的原因

四.软件测试模型

(1)v模型

优点:后期测试阶段和前期的阶段可以一一对应,清楚的标注每一个测试阶段的依据

缺点:不利于项目前期风险的及时发现

(2)w模式(双v模式)

特点:测试在项目前期介入,对需求,系统设计都会进行验证

优点:测试介入早,有利于全面的发现系统前期的风险

缺点:阶段性较强,强调一个阶段完成之后再进行下一个阶段,不可逆,无法适应敏捷开发

五.软件测试的生命周期(软件测试流程)

需求分析 , 测试计划 , 测试设计/测试开发 , 测试执行 , 测试评估

软件开发生命周期:需求分析 , 计划 , 设计 , 编码 , 测试 , 运维

六.如何描述一个BUG

目的:让开发人员更好的定位BUG

版本号

操作步骤

预期结果

实际结果

测试数据

其他:截图,修改意见,错误日志,出现问题的时间

七、BUG的级别(严重程度)

• 崩溃:系统无法正常运行.  例如运行系统死机;死循环;数据库死锁
• 严重:系统可以运行但不稳定, 例如,数据库数据插入错误, 密码明文显示,直播画面失真,数据泄露,日志中完整记录了客户的信用卡号.
• 一般:系统可以稳定运行,但功能未完全实现.  例如查询错误,微信朋友圈,图片显示不出来

        查询数据:30  3(每一页显示10条,翻页显示,数据在不同页面有重复---->数据没有排序)

          数据翻页实现:先把30条数据从大到小排序--->第一页取排序后前10条数据---->第二页取11~20条---->第三页取21~30

• 次要:建议类,界面文字显示,排版,图片模糊,文字说明不合理

八、BUG的生命周期

九、(了解)开始第一次测工作

确认具体工作内容

阅读相关文档,项目会议了解需求,和业务人员,工具,阅读旧的bug库,了解系统功能

计划--->内容(多长时间执行,)---->开发人员是谁,需求人员是谁---->是否需要特殊资源,资源是否满足需要

如何发现更多的bug

(1)某部分问题多,加强广度和深度

(2)有的开发人员bug较多,加强他开发模块的广度和深度

(3)多进行逆向和发散性思维

(4)不要局限于用例和需求文档

(5)尽早介入项目

十、因为一个bug和开发人员产生冲突

(1)先检查自身,是否bug描述的不够清楚

(2)在用户角度考虑问题,让开发人员了解bug对用户产生的困扰

(3)bug定级按照公司要求

(4)不只提出问题,最好有解决方案

(5)进行bug评审:产品经理,开发测试人员开会讨论