开发模型--瀑布模型
优点：开发阶段，各个阶段比较清晰；强调早早期计划及需求调查；适合稳定需求的产品开发
改良：每个阶段都可以融入小的迭代工作！
开发快速原型模型：适合做小型产品
实现一个基本原型，让用户对原型进行评价，逐步调整，使其满足用户最终需求
优点：适合不能确定需求的软件
缺点：不适合开发大型系统
螺旋模型
软件测试模型：v模型 w模型 h模型
v模型：需求分析、概要设计、详细设计、编码、单元测试、集成测试、系统测试、验收测试
1、单元测试：又称模块测试，针对单一的程序模块进行的测试
2、集成测试：又叫组装测试，在单元测试的基础上，对所有模块进行测试
3、系统测试：将整个软件看做一个整体来进行测试，包括功能、性能、兼容性
4、验收测试：
（1）内测版(alpha)内部交流版本，可能存在很多bug，不建议用户安装
（2）公测版(beta)面向所有用户，通过用户的反馈再去修改细节
（3）候选版(gamma)与正式软件相差无几
v模型优缺点
1、优点：包含了底层测试（单元测试）和高层测试（系统测试）；清楚的标识了开发和测试的各个阶段；自上而下逐步求精，每个阶段分工明确，便于整体项目的把控
2、缺点：自上而下的顺序导致了测试工作在编码工作之后，就导致错误不能及时的进行修改；实际工作中，需求经常变化，导致v模型步骤，反复执行，返工量很大，灵活度较低。
改良：每个步骤都可以进行小的迭代工作。
w模型
开发流程：需求分析、概要设计、详细设计、编码、集成、实施、交付
测试流程：验收/系统测试设计、集成测试设计、单元测试设计、单元测试、集成测试、系统测试、验收测试
优点：伴随着整个开发周期，需求和设计同样要测试；更早的介入测试，可以发现初期的缺陷，修复成本低；分阶段工作，方便项目整体管理
缺点：开发和测试依然是线性的关系，需求的变更和调整依然不方便；如果没有文档，根本无法执行w模型；对于项目组成员的技术要求更高
定义：开发一个v ，测试一个v组合起来的模型；w模型也叫双v模型
总结：v模型适用于中小企业，w模型适用于中大型企业（因为人员要求高），h模型人员要求非常高，很少有公司使用。
H模型
软件测试分类
一、按是否查看源代码：黑盒测试 白盒测试 灰盒测试
黑盒测试：又称数据驱动测试，完全不考虑从内部结构和特性，只注重软件的功能需求（不管代码）
白盒测试：把盒子打开研究里面的程序结构和源代码
黑盒测试分类
️功能测试：逻辑功能测试、界面测试、易用性测试、安装测试、兼容性测试
️性能测试：时间性能、空间性能、一般性能、稳定性、负载测试、压力测试
灰盒测试
二、按是否运行分类：静态测试、动态测试
三、其它测试：回归测试、冒烟测试、随机测试、验收测试
随机测试：针对重要功能、新增加的功能、特殊情况、以前发现过重大bug的模块进行二次测试；也叫探索测试，可以结合回归测试进行。
四、是否自动化：人工测试、自动测试
五、按测试阶段划分：单元测试、集成测试、系统测试
测试用例
测什么 怎么测
等价类划分法
属于黑盒测试，它将不能穷举的测试过程进行分配，从而保证完整性和代表性；
思考步骤：
1、确定有效等价类和无效等价类
2、有效等价类划分（题目条件，还要注意边界值/极值，中间再随意找个值）
3、无效等价类划分（跟有效等价类相反，其它特殊情况（中文、英文、特殊符号、空格、空））
注意：两个框要一个正确，一个错误，这样才能准确的判断；一定要根据需求来判断预期结果
等价类细节：1、考虑输入长度 2、考虑输入类型 3、组成规则 4、是否为空 5、是否区分大小写 6、是否重复 7、是否去除空格
边界值
我们在测试过程中，一定要小心边界值（极值）。因为在程序中这些边界嘴容易出问题；
具体测试用例书写思路，找到边界值和它两端的值，分别进行测试
总结：边界值思想应该是选到边界和刚超过的值，来进行测试，也要根据实际情况来选择；边界值和等级类是相辅相成的关系，是配合使用的。
案例：1-100整数加法、qq账号、电话号码、登陆界面
因果图法：
因：输入条件
果：输出条件、出结果
适用于输入条件之间有相互制约 相互依赖的情况；
因果图基本符号：1 恒等-有因就有果，没有因就没有果；2 非-有因没有果，没有因有果；3 或-条件有一个是真，结果就是真，条件都是假结果才是假；4 且（与）-条件都为真结果才是真，一个条件为假，结果就是假
因果图中的约束条件：互斥 包含 屏蔽 唯一 要求
因果图案例：交通一卡通充值
判定表法：因果图只是一种辅助工具，通过分析得到判定表。根据因果图来制作判定表（因果图可以不画）
1、条件桩：所有条件
2、动作桩：所有结果
3、条件项：针对条件桩的取值
4、动作项：针对动作桩的取值
书写步骤：
1、列出所有条件和动作桩
2、填写条件和动作桩之昂的项目
3、简化判定表
判定表法案例：好学生判断
注意：如果出现"-"代表此选项不影响最终结果
场景法：
主要用来测试业务流程：分为基本流（正确流程）备选流（错误流程）
注意：还要补充一些异常情况
在冒烟测试主要采取场景法来测试
案例：QQ登陆，根据业务流程写用例（产品经理会提供出来）
流程分析法：
适用于有先后顺序的测试；常用于业务流程、安装流程等等。每一个流程就是一条测试用例，它只是在测试整体流程是否正确，细节还需要使用等价类、边界值等方法进行完善。
案例：使用ATM机取款，根据业务流程写用例（产品经理会提供出来）
错误推测法：
凭着直觉和经验来设计测试用例，它是根据之前项目相关的bug数据总结来的
正交排列表：
从全面试验中挑选出油代表性的点进行测试（均匀分散，争气可比）；高效率、快速、经济。
案例：字符属性设置程序、114查询系统、
正交表使用方法：
1、根据控件和取值数选择一个合适的正交表
2、列举取值并编号，生成取值表
3、把取值表与选择的正交表进行映射
混合正交表工具：allpairs
在实际工作中，很多情况都是因素和水平不同，我们在现成的正交表中找不到对应的表格，此时我们就需要使用混合正交表工具来生成混合正交表
使用步骤：
1、制作取值表（不需要编号，列出数据即可）
2、复制表格中的数据放在一个新建的txt文本文档中，保存到allpairs文件夹中（例如：test2.txt）
3、win+r再输入cmd进入控制台界面
4、使用控制台代码进入allpairs文件夹中（例如： e: 回车 cd 复制文件夹路径 回车）
5、再输入allpairs.exe test2.txt>chenggong.txt (test2.txt是我们刚新建的文件，chenggong.txt是我们最终生成出来的正交表文件)
测试用例方法总结
1、如果测试功能和流程，要使用场景法；
2、如果需要输入数据的地方，我们要使用等价类划分法，要注意边界值法来做详细测试，（包括输入条件和输出条件的等价划分，将无限测试变为有限测试）
3、如果有条件组合的情况，我们要使用因果图制作出判定表；
4、配置类软件，组合比较多的，我们要使用正交表来科学的选择测试用例；
5、如果没有达到覆盖标准，就要增加一些测试用例；
6、依靠经验追加一些测试用例（错误推断法）
测试用例的力度
软件缺陷
定义：缺陷就是软件的问题，最终表现为没有满足用户的需求
哪些属于软件缺陷
1、软件未达到规格说明书表名的功能
2、软件出现了规格说明说指明不会出现的错误
3、软件功能超出了规格说明书指明的范围
4、软件未达到规格说明说虽未指明但应该达到的目标
5、软件测试人员或用户觉得不好
软件缺陷的表现形式：
1、功能、特性没有实现或部分实现
2、设计不合理、功能不明确、逻辑不清楚或存在矛盾
3、实际结果和期望结果不同
4、没有达到规格说明书要求的性能指标
5、运行出错、崩溃、中断、界面混乱
6、数据不正确、精度不够、不完整或格式不统一
7、用户不能接受的其它问题，如存取时间、界面不美观
8、硬件或软件存在其它问题
缺陷的根源、费用
缺陷产生的原因：需求解释或者记录错误、用户需求定义错误、设计说明存在错误、编码说明 程序代码错误、硬件或软件系统上存在错误、其他 文档 或代码拼写错误
软件缺陷根源：交流不充分、软件的复杂性、开发人员的错误、需求的改变、进度压力
软件缺陷修复的费用：缺陷发现越早费用越少
软件缺陷的信息：
软件缺陷分类——缺陷状态：提交（submited）测试人员提交了一个缺陷给程序员；打开（open）待处理；拒绝（rejected）程序员认为不是缺陷或重复 就可以修改状态为拒绝；修复（resolved）程序员修复缺陷后提交的一个状态；关闭（closed）测试人员经过回归测试后 认为此缺陷已经解决 将其关闭；推迟（later）可以放在后续版本解决的问题，但是要详细写出修复的日期或版本
软件缺陷的信息：
软件缺陷严重程度的划分：5-critical系统瘫痪、异常退出、死循环、严重的计算错误 4-veryhigh频繁死机 大部分功能不使用 3-high功能点未实现 不符合用户需求 导致数据丢失 2-medium影响一个相对独立功能、仅仅发生在特定条件上、与需求定义不一致、断断续续出问题 1-low 表面性错误，如错别字
软件缺陷的优先级（优先修复顺序）：5–导致系统几乎不可用 4–影响系统，产生严重影响 3–会制约开发和测试的进行 需要在发布之前修改 2–不会延迟开发 会在以后修复 1–时间和资源允许情况下修复
软件缺陷的分类——bug分类：系统缺陷；数据缺陷；数据库缺陷；接口缺陷；功能缺陷；安全性缺陷；兼容性缺陷；性能错误；界面缺陷；建议
网友评论