软件功能测试

软件功能测试
一，软件测试概念和理论
1.1 测试的目的和原则
目的：
为了找到软件或者网站存在的问题（bug,用户体验不好，界面丑陋，功能是否全面）
提前找到存在的问题，降低商业风险
定义：
用人工或自动化对软件系统进行测试，通过找到预期和实际结果的差异
预期结果：测试前知道的结果、希望出现的结果
实际结果：测试后得到的实际结果
软件测试基本原则
1）所有软件只能证明存在问题，不能证明步存在
辩证/软件都有问题，
2）不能进行穷举测试，应进行分类测试
穷举：将所有可能测试一遍
分类测试：
可以被正常搜索的：也就是可以正常显示的，比如男装
不能正常搜索的：也就是哪些不应该被显示的对象，比如各种违禁品
特殊情况：带有特殊符号、空格、什么都不输入。
3）测试工作应尽早介入，降低修复成本
早发现早解决
4）缺陷聚集原则，二八原则
一个项目中80%缺陷会集中在20%的功能模块中
越有问题的地方，这里往往会有其他问题
出现这个现象的原因：此模块程 序员水平一般，模块功能复杂
5）测试依赖环境
程序架构：B/S C/S
B/S:Broswer/Server,浏览器访问服务，谷歌，火狐，IE
C/S:Client/Server,客户端程序访问服务,PC：win7、8、10，mac，linux ;手机：安卓、苹果、鸿蒙
6）杀虫剂现象
测试人员在经过一段时间后进入固有思维意识，难以测试出其他BUG,此时进行交叉测试，就是交互测试人员。
7)不存在缺陷谬论
同一条重复的

1.2软件开发模型
1.2.1简介
软件的生命周期：软件开发模型
软件测试与软件的开发模式有着紧密的联系，作为一名测试人员，应该充分理解软件的开发模式，以便找准自己在其中的位置，从而发挥自身的价值
在软件开发的几十年实践中，人们总结了很多软件开发模型用来描述和表示一个复杂的开发过程，软件开发有三种模式：
瀑布模型
快速原型模型
螺旋模型

阶段一：项目立项
1.调研：
首先对项目进行可行性研究，通过研究判断此项目是否盈利
调研后得出可行性报告
有项目负责人完成
2.需求分析：
调研得出项目无问题后进行需求分析
项目经理完成
最终得出具有需求大体说明的需求规格说明书
阶段二：项目开发阶段
1.概要设计：
将需求规格书内容落地
概要设计完成后得到概要设计文档
由经验丰富的前端和后端程序员负责
概要设计文档将整个项目分成若干功能模块，并明确说明各模块中的功能
2.详细设计：
明确指定模块具体实现的细节
由一线程序员完成
最终得到详细设计文档
3.编码：
程序员写代码 程序员完成 最终得到测试报告
阶段三：项目运维阶段
1.上线，用才能访问

瀑布模型的特点
以文档驱动，后面所有工作基于前面的文档内容
每个阶段执行一次，线性依次进行
瀑布模型是开发模式中非常重要的一种

优点：各阶段非常清晰，每人只关注自己的阶段
缺点：下面的阶段依赖上面的阶段一旦出错，下面都错
流程过分依赖需求分析结果，此模式不能适应变化频繁的项目
此模式适用传统项目和行业：银行，保险，建筑

快速原型模型
在很短时间内，项目有新版本上线，此版本功能不全有bug
后续版本修复BUG,并加以完善功能

特点：快速上线，支持用户参与
优点：克服了瀑布模型的缺点，减少中间环境，及早发现问题并进行修复
缺点：仅仅适合中小型项目，不适合大型项目

1.3 软件测试模型
测试模型：所谓的模型就是这个行业的人总结出来的测试经验。
第一种：V模型
这种模型其实就是在前面瀑布模型的基础上进行测试的
这种模型其实也是瀑布模型的变种
根据测试阶段不同，测试也同样分成四个不同的阶段

V型的流程
用户需求=> 需求分析 => 概要设计 => 详细设计 => 编码 => 单元测试 => 集成测试 => 系统测试 => 验收测试
优点：整个流程比较清晰，即包含了底层测试，也包含了对高层进行测试
缺点：这个本质上还是瀑布模型，因此具有瀑布模型的缺点

第二种：W(双V)模型
这种模式主要是为了解决V型模型存在的问题，解决思路就是测试前移

W型比V型多的部分
集成：每个程序员将自己负责的功能模块合并到一起
实施：将 开发好的软件安装到客户的服务器上
交付：教给用户如何使用软件

静态和动态测试
W模型中，对各种的文档进行测试，都是静态测试
对程序进行测试，就是动态测试

总结：W模型中的流程
开发V：用户需求=>需求分析=>概要设计=>详细设计=>编码=>集成=>实施=>交付
测试V：验收测试设计=>系统测试设计=>集成测试设计=>单元测试设计=>单元测试=>集成测试=>
系统测试=>验收测试

优点：测试工作前移，可以今早发现存在的问题
缺点：对技术和管理能力要求较高

1.4 软件质量模型
质量体系：ISO 9126
六大特性
功能性
可靠性
易用性
效率
维护性
可移植性

1.5 软件测试分类
第一种分类方法：按照阶段分类

单元测试
模块：程序的最小单位就是模块，比如用户登录模块、购物车模块
单元测试：就是检测这个模块是否满足测试用例的要求，仅仅是测试一个单独的模块是否能正常运行

集成测试
集成测试又称为 组装测试
在单元测试完成以后，就是表示每个单独的模块已经正常
集成测试，就是将多个模块组合起来进行测试

系统测试
在集成测试完成以后，才能进行系统测试
系统测试，将软件作为一个整体来测试，测试的依据是软件需求说明书【就是检查软件是否
达到了当初想要的样子】

验收测试
主要是检查软件是否满足客户的要求，对软件做最后的测试验收测试分为几个小类
α测试【Alpha】：阿尔法测试的软件版本内存版本，软件bug较多，一般不让用户直接使用，而是公司内部交流使用。
β测试【Beta】：贝塔测试就是软件的公测版本，目的就是让更多的用户通过使用软件来发现更多的问题。
γ测试【Gamma】：伽马测试就是软件的正式候选版，这个版本和用户最后使用的正式版几乎完全一致。

第二种分类方法：按是否查看源码分

白盒测试
不去执行程序，而是去直接读取程序的代码

黑盒测试：
又称之为数据驱动测试
这种测试就是直接使用软件，完全不考虑程序内部结构和代码
例如：输入账号、密码，一点就能登录成功，就表示测试通过

灰盒测试
即要去读程序的代码
也要去执行程序
既要做黑盒的工作，也要做白盒的工作

第三种分类方法：按照是否运行程序划分
静态测试
动态测试

第四种分类方法：是否自动运行
人工测试：所有的测试工作，由测试人员手动点击完成
自动化测试：通过python开发自动化工具，用工具完成测试工作

第五种分类方法；其他分类
冒烟测试
测试软件基础功能是否正常
回归测试
在测试工作种，一旦发现了bug，需要将这个bug提交给开发，开发修复完成后，需要重新进
行测试
测试人员必须对哪些曾经发生过的bug再次进行测试
随机测试
虽然叫做随机测试，但是不是真的随机
这里的随机其实是重复测试，包括测试之前的测试用例种没有涵盖的部分
探索测试
这个测试不是必要

1.6 软件缺陷
缺陷不等于bug
bug仅仅是缺陷中的很小的一个部分而已
什么是缺陷：只要让测试人员感觉不爽，那么这个就是缺陷

软件缺陷判定标准

1. 软件未能达到需求规格书中的要求
2. 软件的功能超出规格书中的要求
3. 软件出现了规格书中明确指定不能出错的地方
4. 软件出现了规格书中未明确指定，但是不应该出现的错误

软件缺陷产生的原因【缺陷只能减少、不能完全避免】

1. 对于需求文档等文等文件解释、理解错误【需求说明会】
2. 设计文档本身有错误
3. 程序代码错误
4. 硬件和软件系统有错

软件缺陷的类型

1. 功能错误：软件没有达到需求文档的功能要求，或者功能异常
2. 界面错误：软件功能正常，但是界面不好看或者未达到规格说明中的要求
3. 兼容性错误：软件和系统中的其他的程序冲突，导致软件无法运行
4. 易用性错误：软件用起来不好用
5. 改进建议：改了更好，不改也没事