软件是控制计算机硬件工作的工具
![](/i/l/?n=22&i=blog/1966851/202209/1966851-20220927234953716-564401668.png)
软件产生过程:
1.需求产生(需求方、产品经理)
2.需求文档(产品经理)
3.设计效果图(UI设计师)
4.产品开发(研发人员)
5.产品测试(测试人员)
6.部署上线
软件测试:使用技术手段验证是否满足使用需求
软件测试的目的:减少软件缺陷Bug,保障软件质量
测试主流技能:
- 功能测试(测试主要验证程序的功能是否满足需求)
- 自动化测试(使用代码或工具代替手工,对项目进行测试)
- 接口测试—工具、代码实现(使用代码或工具验证程序中的接口是否访问正常)
- 性能测试-工具、代码实现(模拟多人使用软件,查找服务器缺陷)
就业方向:
1.功能测试+接口测试
2.功能测试+性能测试
3.功能测试+web自动化
常见测试分类:
1、按测试阶段划分:
1.单元测试
(又称模块测试,针对软件设计中的最小单位-程序模块,进行正确性检查的测试结构出发设计测试用例 。多个模块可以平行地独立进行单元测试 针对程序源代码进行测试)
2.集成测试
(又称组装测试,通常在单元测试的基础上,将所有程序模块进行有序的、递增的测试。重点测试不同模块的接口部分; 针对模块之间访问地址进行测试)
3.系统测试(对整个系统进行测试包括功能、兼容、文档等测试)
4.验收测试
(验收软件是否符合用户需求的测试;主要分为内测、公测,使用不同人群来发掘项目缺陷)
α测试:
1、Alpha是内测版本
2、通常只在软件开发者内部交流
3、一般而言,该版本软件的bug较多,普通用户最好不要安装
β测试:
1、Beta是公测版本,是对所有用户开放的测试版本
2、这一版本通常由软件公司免费发布,用户可从相关的站点下载
3、通过一些专业爱好者的测试,将结果反馈给开发者,开发者们再进行有针对性的修改。
γ测试:
Gamma版本,指的是软件版本正式发行的候选版。该版本已经相当成熟了,与即将发行的正式版本。
2、按代码可见度划分:
1.黑盒测试:不关注源代码,针对程序UI功能进行测试(源代码不可见,UI功能可见)
2.灰盒测试:针对程序部分代码进行测试(接口)(部分源代码可见,功能不可见)
3.白盒测试:针对程序源代码进行测试(全部代码可见,UI功能不可见)
3、按是否运行分类:
1.静态测试
不运行软件,静态的观察软件是否符合预期
2.动态测试
运行软件,在运行过程中测试
4、按是否自动化:
1.手工测试
通过测试工程师手工对软件进行测试
2.自动化测试
通过编程写代码,通过程序自动化测试软件是否有bug
5、其他分类:
1.冒烟测试
对软件最基本的流程和工作做一个粗略的测试,看最基本的流程是否能跑通
测试拿到研发的第一个版本,一般先冒烟
2.回归测试
当修复一个BUG后,把之前的测试用例在新的代码下进行再次测试
3.随机测试
随机测试主要是对被测软件的一些重要功能进行复测,也包括测试那些当前的测试用例没有覆盖到的部分
4.探索性测试
一边了解和学习项目,一边测试项目
探索性测试意味着同时设计测试和执行测试。测试人员通过测试来不断学习被测系统
质量模型:(衡量一个优秀软件的维度)
1.功能性:适用性、准确性、互操作性、保密安全性、,功能数量、功能正确实现、错误处理情况
2.性能(效率):时间特性、资源利用性,服务器每秒处理请求数、服务器硬件配置是否满足
3.兼容性:
浏览器:谷歌、IE、火狐、欧朋、苹果
操作系统:
Win系统:wind7、wind8、wind10、其他
手机:分辨率、品牌、系统、网络、其他
4.易用性:易理解性、易学性、易操作性、吸引性,简洁、友好、流畅、美观
5.可靠性:成熟性、容错性、易恢复性,无响应(出现无响应)、卡顿(响应时间慢)、死机(系统崩溃)
6.安全:传输加密、存储加密
7.可移植性:网站数据迁移,适应性、易安装性、共存性、易替换性
8.可维护性:易分析性、易改变性、稳定性、易测试性
软件开发模型的介绍:
1、瀑布模型(重点):
1.需求分析(研发分析需求说明书,判断需求的可实现性)
2.概要设计(用到具体的技术点,大致模块划分)
3.详细设计(详细到可以为编码做支持,类和类关系,类的设计,函数设计,各个接口的细节,数据表的关系,字段关系)
4.编码(依托于详细设计进行编码操作)
5.软件测试
6.软件维护(上线后也是需要持续维护)
特点:
线性模型:每一步都是按顺序来执行
文档驱动:每一步都有文档产出
优点:
开发的各个阶段比较清晰
当前一阶段完成后,只需关注后续阶段
缺点:
依赖于早期的需求调查,不适应需求的变化。
风险往往延至后期才显露,失去及早纠正的机会
2、快速原型模型(了解):
一边确定需求,一边实现
优点:
避免瀑布模型的缺点,可以适应早期的需求变化
缺点:
适合小型项目
3、螺旋模型(了解):
特点:
引进了风险分析活动
优点:
螺旋模型很大程度上是一种风险驱动的方法体系
缺点:
采用螺旋模型需要具有相当丰富的风险评估经验和专门知识
测试模型:
1、V模型(重点):
从研发的瀑布模型来的
优点:
(1)测试V模型即包含了底层测试又包含了高层测试
(2)每个步骤都是文档驱动的
缺点:
(1)当需求变更时将会导致阶段反复,返工量非常大,模型灵活性比较低
(2)和研发瀑布模型一样,不能适应需求的改变,灵活性比较低
2、W模型(认识):
测试伴随整个软件开发周期,并且测试的对象不仅仅是程序,需求和设计同样要测试。
优点:
(1)强调测试伴随着整个软件开发周期,而且测试的对象不仅仅是程序,需求和概要设计同样要测试
(2)更早地介入测试,可以发现开发初期的缺陷,那么可以用更加低的成本进行缺陷修复
缺点:
(1)使用起来技术复杂度高,对于需求和设计的测试要求高,实践起来困难
测试流程:
1.需求评审(确保各部门需求理解一致)
2.计划编写(测什么、谁来测、怎么测)
3.用例设计(验证项目是否符合需求的操作文档)
4.用例执行(项目模块开发完成开始执行用例文档实施测试)
5.缺陷管理( 对缺陷进行管理的过程)
6.测试报告(实施测试结果文档 )
测试用例(Test Case):
定义:为特定的目的而设计的一组测试输入、执行条件和预期结果的文档
1.用例:用户使用的案例
2.测试用例:是为测试项目而设计的执行文档
3.测试用例的作用:防止漏测、实施测试的标准
4.用例设计编写格式:
用例编号:项目_模块_编号
用例标题:预期结果(测试点)
模块/项目:所属项目或模块
优先级:表示用例的重要程度或者影响力P0~P4(P0最高)
前置条件:要执行此条用例,有哪些前置操作
测试数据:操作的数据,没有的话可以为空
测试步骤:描述操作步骤
预期结果:期望达到的结果
例子:
标签:需求,模型,基础,用例,文档,测试,软件,软件测试 From: https://www.cnblogs.com/670ling/p/16736510.html