2.过程质量(管理者)
1. (能力成熟度模型)CMM质量管理体系(主要做过程,看重过程和文档)(行业标准):
标识:软件 开发管理水平
强调软件 过程改进
体现承接项目的能力
核心:把开发视为一个过程,对每个阶段进行把控,
目标是:让每个阶段:更科学化,更合理,有一个标准进行监控,更标准,最终实现 商业目标,让整个软件开发风险降得更低
CMM质量管理体系等级:
初始级
重复级:借鉴有的东西,拿来照猫画虎
定义级:定义、实施这个过程
管理级:在3这个过程上,度量标准,根据标准管理
优化级:优化,不断完善改进过程
题:
1.质量模型解决的是什么问题?并说出你所知道的质量模型?
解决产品质量问题,我们来验证。。。。。(其他要自我扩展)
2.质量管理体系解决的是什么问题?并说出你所知道的质量管理体系?
解决:1.给没有规则体系以及质量不稳定的组织一个向上的标准体系,是在质量方面指挥和控制组织的协调活动的优化,从而让公众相信企业具有一定的产品质量保证能力和质量管理水平
2.ISO9000一族(是一类标准的统称):ISO9001、ISO9002、ISO9003、ISO19011
3.SQA和QC的区别和联系?***
4.测试是为开发服务的吗?(或者问叫你必须选一个证实或证伪)(开放性)***
相辅相成,终是为公司盈利,开发为正方面(证实)保障,测试为反方向(证伪)保障,都是保障产品质量
不行,一定要两个都要
5.各个质量属性,分别与哪些测试类型对应?
软件质量的总结
2.敏捷(不看重过程和文档)
项目管理:
进度(按时)(一定不能延期,成本最高)
铁三角
成本 质量
质量度量(量化):
没有描述就没有度量
没有度量就没有产品
seven:
软件定义:
程序+数据(内部数据和外部数据)+文档
程序:源程序(满足用户需要的功能的源程序)
数据:
1.外部数据
输入、输出
2.内部数据
文档:软件开发过程中一系列的文档。比如使用说明书(面向用户、面向开发者的)
被测对象:软件
可用、能用(大多数用户认为是有效的)、好用
软件测试7大原则
1、测试尽早介入
2、穷尽的测试是不可能的
3、测试显示软件存在的缺陷
4、缺陷集群性
5、杀虫剂悖论
6、测试活动依赖于测试内容
7、无错就是最好的谬误
软件测试潜规则
1、 可以规划缺陷的数量
2、 测试在前期工作只能是学习
3、 姜是老的辣,用例是陈的香
4、 任何一个项目都是可以复制的
5、 超出设计规格的缺陷不是都是缺陷
6、 规格是测试出来的,不是设计出来的
软件正确理解:
1.运行时,提供要求的功能和性能的计算机程序集合
2.程序能正确处理信息的数据和数据结构
3.提供给人们可读的、可理解的技术数据和图文资料
测试对象:程序(开发+脚本)、数据、文档 (需求说明书、用户手册)(详细设计、概要设计、需求分析、用户需求)
测试级别(测试阶段):单元测试(UT)、集成测试(IT)、系统测试(ST)、(用户)验收测试(UAT)
测试方法:*************************
1. UT、IT、ST、UAT(按阶段、级别分类):*******************************
UT(最小力度的测试(函数、程序代码等),通过详细设计说明书来检验,功能性)
IT(把已经通过单元测试的模块集合起来,检验是否符合概要说明书,通过 接口来看功能(接口、架构、ui))
ST(检验是否符合需求规格说明书)(有前中后3轮,UAT可以提前到2轮(1.预测试、ui。2.回归、功能。3.回归、功能、性能))(一定要在用户环境下测试,一致)
UAT(用户(外部用户、内部用户)验证软件产品与用户需求的符合程度)
Alpha测试:受控测试,用户不一定参加
Beta测试:不受控测试,一定有用户代表参加的,研发人员有可能会在有可能不在(更严)
2. 黑白灰
黑盒(IPO):只关注输入和输出结果,不关注内部结构(依据文字类用例),主要站在用户的角度进行,(基于需求规格说明书)
白盒:关注程序内部结构(依据代码用例),开发角度
3. 自动化、人工
4. 动、静(3类静态:走查、检视、评审(严))(静态被测对象:代码、文档、ui原型)(从运行起来的角度)(基于逻辑结构,设计说明书)
5. 开发、用户、第三方
冒烟测试:来源硬件
题:
1.黑、白测试和UT、IT、ST的联系?
ut有黑白,以白为主 黑辅(因为对单元的认识不同),测试主体:开发人员
it黑白间
st以黑为主,白辅,测试主体:测试人员
很多企业:
第一种:(很多企业跳过it,ut下阶段集成和系统组合直接sit)
第二种:持续集成
2.黑、白测试和静态、动态的联系?
黑:静:评审(规格文档)。动:程序运行起来
白:静 动:
3.黑盒和白盒测试的定义和区别?
4.alpha、beta测试的区别?*************
5.有it为什么还要有st?
ut、it都是测功能性,质量不仅测功能还有性能,功能基础,终质量
测试策略:
(st)系统测试类型:
1.功能测试
1、业务测试:与单个模块没有太大的关系。应该对不同的模块组合起来实现不同的业务,来进行测试。功能+业务流程(各个功能组合起来实现的业务流程)。
2、通过测试(正向):测试时,所有的输入、预期等都是正确的。
3、失败测试(反向):测试时,所有的输入、预期等都是错误的。
验证系统提供的功能是否符合用户需求
功能测试的主要测试内容:
1.验证这个功能有没有
2.验证这个功能是否正确
3.验证这个功能是否冗余
需求来源不明确或没有需求就对一个系统的功能进行测试,应该如何进行:增、删、改、查。
增、删、改、查指的是在测试功能点的时候,尽可能的往这四个方向去测试。
2.专项测试:
性能测试(属于质量的一个环节) (检测系统是否满足用户要求的性能指标)
负载测试:施加负载量的过程,直到测试到极限
压力(强度)测试:当确定最大负载量时,直接给一个重的压垮,看系统的恢复力和响应力
可靠测试:两次故障时间间隔越短,越可靠
稳定测试:越可靠越稳定
配置测试(更多是在硬件。目的:验证软件在不同硬件的配置下软件的运行能力)
并发测试
容量测试
基准测试
兼容性测试(特定的硬件平台之下,不同软件间、操作系统、网络环境、数据库等下的运行能力)(更多是在软件)((wps、office叫数据兼容)、向前向后兼容、版本兼容、标准和规范(少))
确定系统兼容在哪个浏览器运行?
1.调研客户的浏览器使用习惯
2.看是什么客户
3.厂商
4.浏览器收费否、年限
安全性测试(安全、防护提高让攻击者所付出的代价不成正比)(目的:验证系统的安全机制具 合法 方式访问,同时防范 非法 的侵入)(包含 数据备份和恢复测试(少单独列出))
测合法访问一般是功能测试,方式有:1.用户权限设置。2.密码复杂度设置。3.安全日志(和 4.数据权限(数据库)绑在一起)(涉及隐私要加密)
测非法方法:1.安全扫描(app scan)。2.攻击手段(跨站点脚本攻击)
回归测试
易用测试(文字、图片、导航(菜单测试)、链接(死链)、文档)
文档测试(操作手册提供方式在线(快捷键f1)还是离线。1.目标群体:用户群体是谁。根据面向的群体内容不同。2.检查,操作手册提到的功能一定要是实现的。3.使用手册注意事项是否和软件吻合)
本地化测试
国际化测试
安装测试(安装、升级、卸载(反安装)。1.是否提供安装手册。2.是否有程序的依赖包。 校验安装成功:1.界面反馈是否有响应反映。2.运行一下是否成功。3.写入文件位置是否存在。(安装程序路径尽量不超过三层))
**********************************************************************************************************************题
题:
1.没有需求,需求不明确,让你展开测试,怎么测功能?
对增删改查展开测
2.专测和用户来测得区别?
查看数据库,比对。通过用例的预期结果看出
业务功能模块(功能+业务流程)(业务测试、正反测试)
过程:用户需求 -》需求分析(需求分析工程师) -》 概设 -》 详设
(概详是核心)
一般企业:
1-2过程:需求-细化-需求文档-评审
2.(需求规格说明书 也叫 基线)
(2个必要)
功能模块难度:核心 基本 辅助(支持)
写需求时注意:1.每个模块简述功能是做什么的
2.最好开始有背景,概论,摘要
3.某些地方有些用例
写前可以有一个总体要求,包括系统架构,什么语言,等等
评审:1.有歧义
2.结果不唯一
3.前后不一致
******************************************************************************************测试执行流程
测试的执行流程:1.需求评审
2.预测试
3.回归测试
4.交叉测试
评审属于哪里?(各有各的分发)
1.软件研发角度:需求分析
2.测试角度并分流程阶段的角度:执行阶段
3.很多企业把流程12放一起
需求测试是一种黑盒测试流程策略。通过分析检查系统的需求定义,尽早地修正和验证需求,然后使用各种黑盒测试设计方法来设计:最小数量的测试用例,满足最大的需求功能覆盖
需求变更
*************************************************************************************************************SRS作用
SRS的作用:1.用户:与用户达成一致,是一个需求沟通的结果 (外部作用)
2.开发:进度、计划、设计、实施提供基础 (内部作用)
3.测试:STP、用户手册、提供基础 (内部作用)
*************************************************************************************************************需求测试检查点
需求测试检查点:1.完整性:包含所有的需求;输入处理;确定与待确定的都要标识
2.正确性:正确描述软件需要实现的功能
3.二义性:需求传递失真
4.一致性:各子系统间不矛盾、不冲突
5.可验证性:可验证,可实现
6.统一性:ui界面风格,操作的提示
7.易理解性:需求中是否有需求的原因背景、用户使用场景,采用 用户能理解的语言表达等。多问why,是核心功能?支持功能?等。
*************************************************************************************************************测试计划
什么是测试计划?
明确测试的对象,并且通过对资源、时间、风险、测试范围的预算、人力、测试通过失败标准等方面的综合分析和规划,保证软件测试工作有效的实施
资源(人、系统、硬件、软件、网络)
时间(什么时间做什么事、什么时候完成)
风险(做事情都有风险,对高风险模块重点测试)
测试范围(哪些测,哪些不测)
预算(经济成本)(文档一般不体现)
测试计划要写的内容:
项目说明 ===== 项目是干什么的
测试范围 ===== 明确 测试对象 *
测试手段和策略 ===== 用黑、白,哪些测试技术 *
通过和失败标准 ===== 测试可交付性,达到什么程度,测试可以交付用户 *
暂停和重启测试的标准
测试的可交付性
测试任务分配 ===== 测试人员、任务量分配、级别 *
测试用例规范(基本):
1.编号(从001开始)
命名规则:1 产品名称—st—系统测试项(大的模块)—测试子项—001
2 产品名称—st—测试类型(FUNC)—系统测试项—001
作用:用例编号和相应文档的对应关系:1 需求覆盖
2 测试报告
3 缺陷报告
2.项目名称(可以加测试子项)
模块覆盖率
子模块(测试子项)
和用例编号中的:测试项—测试子项对应起来·
*3.标题
要求:简明扼要,重点描述(不超20字,不要重复),通过标题反映测试的是什么
4.前置条件(没前置条件操作步骤繁琐,作用:总结语言)
在什么样的状态下,去做下面的事(规定测试用例执行的前置条件)
可以包括测试环境
*5.操作步骤(怎么做,做什么)
完整性、清晰性、可操作性
可以把动作和输入数据放在一起
6.用例级别(优先级,根据功能模块来分)
划分目的(重要紧急程度(先测))
划分依据(按照功能的重要程度)
如何确定用例的优先级(分级目的:重要的先执行,重要的先测,不重要的后测或者不测)
正向(基本流)
逆向(备选流)
1非常高:核心+基本
2高:核心+备选,基本+正向
3中:基本+备选,
4低:基本+备选
题:
可不可以带风险发布版本?
可带风险发布(根据功能模块(核心、基本、辅助)分大小—用户的影响程度)
*7.预期结果
根据SRS,用例执行后,期望得到的结果
输出结果要求
8.执行结果(用例执行结果)
通过,(实际与预期相符)
失败,(实际与预期不相符)
阻塞
题:(面试)
1. 你们项目组要不要写测试用例?
2. 你们公司的用例规范怎么制定的?为什么?
刚开始怎么组成的---》后来发现问题---》怎么改进的
3.用例最难的?
一个用例几个人执行,结果不唯一
4.没有用例怎么办?进度紧张怎么测试?(面)
熟悉团队–》为什么会没有
基于个人经验写出简易化的用例(chicklist),当做测试标题,测试点,围绕这个走(缺点:依赖于设计的人、执行的人)
5.用例的价值有哪些?
6.测试用例有哪些作用?
用例管理
1. 用例工具的选择
2. 用例结构与元素的设计
3. 用例维护
黑盒测试用例设计方法:
1.基于用例:
1.基于输入、输出:等价类
边界值
2.基于条件组合:因果图
正交试验
判定表
3.基于状态转换:状态转换
4.基于流程分析:场景分析(重点是测流程,流程涉及的功能他是不关心的)(功能流程不会分开,都测)
2.基于缺陷
5.基于个人经验:错误推测
1. 等价类
什么是等价:任意挑选的一个数据去发现错误 与验证软件能成功运行还是缺陷是等价的
有效
无效
使用步骤:
1. 根据输入项划分有效和无效有哪些(例:输入项:皮肤颜色。有效:黄。无效:黑、白)
2. 为每个等价类编号
3. 设计用例尽可能多的来覆盖有效和无效,直到完成
一条尽可能多的覆盖有效。1-n
一条覆盖一条无效。1-1
2. 边界值:(例:1-30)
上点:边界上的(1, 30)
离店:离边界近的点(0-31)
内点:边界内的(1-30)
一般测:有效:1,30。 无效:0, 31
有时间的话:测极值
(问:功能测试验证哪些)
3. 错误推测
新增功能测试:
正向(正面、通过):
验证:正确输入各个字段值,看系统是否提交成功
预期结果:
1.界面(提示操作成功的提示信息)
2.功能(相关模块是否正确添加了数据)
3.DB(数据库中是否添加了相关数据)
反向(负面,失败)
验证:错误输入页面当中,某个字段,是否会提示操作失败
预期结果:
1.界面(提示操作失败的提示信息)
2.功能(没有产生相关数据)
3.DB(没有相关数据记录)
验证:界面中各个字段名称以及控件类型,是否和需求保持一致
不急于开展测试 (软件的实现与需求的一致)
核对需求
校验:各个字段相应生成规则
长度、类型、格式 (等价类、边界值、对每个字段一一覆盖)
验证:页面中必填项字段
界面:是否有标志、背景颜色 (UI、功能)
功能:实现是否正确
必填项不填时,是否有提示信息
验证:页面字段唯一性
用户名 (1:界面:给提示 2:功能正确)
邮箱
已注册过的,是否再次注册
验证:各个按钮功能
如:确定、清除、取消 (控件)
相应的按钮功能是否实现正确
验证:权限限制
时效性:在一定的时间范围内,你有此权限
过了时效后,限制了此功能
权限划分
验证:初始值
是否有初始值
初始值是否正确
验证:特殊字符
输入/出数据为0 (边界值)
输入数据位:空格
输入超长数据、极值数据
特殊字符
验证:自动加载的数据
如:高级选项,自动弹出的内容
删除功能的测试 ===常见测试点
邮件删除,文件删除,记录删除,邮箱当中的删除
通过测试:能成功删除; 失败测试:记录不被删除
选择一条记录的时候,进行删除,系统是否提示操作成功,相关模块和数据库中是否删除数据;显示删除成功,数据库中未删除
取消删除,来验证相关模块和数据库中,没有删除数据
删除操作(不可恢复的操作),弹出确认删除的提示窗口,应该支持确定和取消相应的操作;高危行为,防止进行误删除
验证删除:单条,多条,全部记录的情况,是否提示都正确,是否相应模块和数据库中显示都正确(无效:空)
删除操作,是软删除还是彻底删除,软删除(没哟真正删除,只是在前台无法看到,任然存在于后台,或者其他位置,需要验证:软删除后,数据是否可以恢复)
多记录分页显示的时候,验证删除功能是否正确,最后一页当中是否只有一条记录,删除是否会报错,页码是否会减1,并定位于前一页
删除权限的验证,有权限的才可以;普通用户新增的帖子,只有本人或者管理员才可以删除
易用性角度:批量删除是否支持(手机、邮箱)
多条删除、全部删除、取消全选功能是否实现
空数据的时候,选择删除
修改与查询?
修改:满足新增的需求规格 === 关注数据库
修改:关注可修改项 与 不可修改项 ==== 不可修改项,一条用例覆盖
查询结果:精确、模糊(单字符匹配、全模糊匹配)
查询方式:但条件查询/ 多条件查询
查询结果:对于查询条件的清空(常见:清空查询条件,不清空查询结果)
查询结果:关注翻页:关注数据列表的正确 ===== 数据库sql语句
测试执行阶段的策略(常常用的测试):
1.冒烟测试(预测试)-》
2.按用例执行-》(执行3轮,1.发现问题。2.改问题,没发现有bug加bug。3.改了再全面测一下)
3.发散测试-》(快捷键、符合用户习惯,密码不允许复制粘贴,什么时候自动清空)
4.交叉测试-》
5.回归测试
4.状态转换
有效类:有限。 无效类:无限
输入:事件。 输出:状态
状态:饿-》饱-》撑
事件:吃、等等等
5.条件组合
例题:
1.全单值(所有都可以组合,但是只组合一次)简单、不完善
做法:
2.简单组合(基本组合)(做加法)(相同+相同+不同,相同+不同+相同,不同+相同+相同) (全组合:做乘法(等价于判定表))
3.全对偶
4.判定表
条件桩(输入项) 条件项(每个项的取值、数据)
定义:实质:把输入中所有可能的情况进行组合,并汇总所对应的操作结果。各种组合类型的全值组合
步骤:1.列出:所有的条件桩和动作桩(条件项、动作项)(根据需求分析输入输出)
(一般输0, 1, 或 Y, N)(条件桩、项之间与顺序无关)
2.计算规则的个数(用例条数)
3.填充条件项和动作项到判定表(实际就是在完善(用例)操作步骤、输入数据、预期结果)
4.合并/化简规则(业务处理来的)
合并规则:两条或两条以上规则有相同的操作,且条件项之间存在较为类似的关系,需要进行规则的合并,用—代替(合并后不同的条件随意选)
不推荐合并:在业务逻辑上是可以的,在业务逻辑上不确定
优点:1.充分考虑输入条件间的组合,对组合情况。覆盖充分
2.把复杂的问题按各种可能的情况一一列举出来,进行全部罗列,简明易于理解
3.每个用例覆盖多种输入情况,有利于提高测试效率
4.对输入条件间的约束关系做了考虑,避免了无效用例
缺点:1.输入较多时,判定表规模非常大
2.合并有可能存在着测漏的风险
3.是一个全值组合,会产生冗余用例
4.不能表达重复执行的动作
适用范围:输入输出比较多,输入之间和输出之间相互制约的条件比较多的情况
5. 因果图(和判定表没有本质区别,因果图可以说是判定表,反之)
问:他们两有没有附属关系?
没有本质区别,和附属没有关系,一眼看不出输入和结果就可以画因果图
6. 正交试验(每一行一个用例)
4:因子(输入条件)
3:水平(每个条件下3个元素)
正交表设计步骤:需求分析,提取各分类 及分类下的元素
选择合适的正交表,进行套用
填入相应的数据,生成用例
定义: 使用已经创建好的表格(正交表(有很多个)),来安排试验并进行数据分析的一种科学试验设计方法
特点: 1.用例代表性强,用例数量又不大
2.借助正交表,可以从大量的试验数据中,筛选出合适的、有代表性的值,从而合理展开测试。即简化了用例,又尽量充分覆盖测试(取值均匀)
缺点:分析出来的需求和已有的正交表不对应时,就不能用,有局限性
7.两两组合
测查询:花瓣查找(常规)(确定一个,先加再减)不同人思路不同,覆盖率不同
测试执行(规范)(星号是必须测得):
1. 冒烟测试(预测试):
1测试员做预测试(测试环境(尽可能与用户环境一致))
转测试前开发做,转测试后我们验证
2在进行正式或全面测试之前进行最基本的测试(初验)(只测1级)
3目的:暴露软件基本概念失效等严重问题
核心+正向测试:1级(占所有比例:10%-20%)
核心+逆向测试:2级
基本+正向测试:2级
*2.全面测试(用例测试)
完了之后做发散
3.交叉测试
4.发散测试
围绕这个点发散,防止随意性
*5.回归测试(1、2、3)
*1针对发现的错误,对开发修改后进行再一次的验证,
2验证修改后相关的模块是否有影响(交互)
3对没有错误的也再进行测试,在迭代增量后,验证是否对老功能有影响(增加有风险)
前提条件:
1开发修改错之后
2这一轮回归上一轮(版本)(一版本最少修复78%再进入下一版本)
目的:
1变更点(缺陷)本身实现的正确性
2是否影响到原有功能的正确使用(交互模块、老模块)
软件变更:
新增需求、变更需求
缺陷修复
代码优化,代码移植
策略:
1基于用例:
2基于bug:
缺陷
题:
1. Bug单填写还有哪些需要完善的?
1 . bug定义模块
2 . bug解决说明模块
3. bug回归记录模块
2. 实际工作中,对于bug的管理会出现哪些现象?
1提交
2录入
3重现、主动、协助解决
4用例更新
5评审
6回归
7版本发布
8线上问题
9偶发bug(不一定会重现)
10特定的数据发现特定的bug(边界)
3. 实际工作中,bug库有哪些应用?
1.对内
2.对外
4. 如何提高bug敏感度?(照bug思维的培养)
5. 如何确定两个bug还相同的bug?
常见缺陷单:
项目信息、版本信息、发现时间 ====== 系统自动填上
【概述】 ===== 字数不超太多
【详述】
【环境信息】
【操作步骤】
【预期结果】
【实际结果】
【备注】
【附件】:截图、录屏
【缺陷严重程度】 ========== 缺陷对用户的影响程度
【致命、严重、一般、提示】
【优先级】 ======= 开发针对某一个缺陷,先修改,还是后修改的,修改优先级
【备注】严重度与优先级没有必然联系,企业常见参考:根据严重度的级别不同,进行先后修改
【下一步处理人】 ===== 缺陷单交给谁来处理,可根据 不同的处理流程(简单 和标准),分别交给不同的人
【实际工作会遇到的问题】:测试与开发人员的沟通交流:
1:开发重现缺陷单的时候,需要:按操作步骤去重现;
2:开发团队不认可测试提交的缺陷严重度;
3:测试提交的缺陷,开发不认可,不修改;
4:常见的下一步处理人:由系统管理员或CMO(配置管理员)根据不同的管理系统或工具配置,你们中需要选择相对应人员的账号即可
缺陷单格式:
缺陷管理流程:
缺陷管理工具:bugfree、jira
项目管理工具:禅道(cd的前生是bf)
测试轮数:
测试3轮(一般),敏捷(4轮,还有验收)
可以有4轮,给自己一个预防有问题的、缓冲的时间
St-》3轮(1:全面。2:回归。3:全面)-》验收测试3轮(有用户)
Story(2轮)—》迭代测试(2轮)--》sit(3轮)
1000行代码---20-15条用例
一般一天一个模块-----执行50—100个用例
xmind思维导图
IE lester 可以模拟ie6-10,测兼容