软件测试工程师-开发与测试模型

开发与测试模型

1、开发模型——瀑布模型
优点：开发阶段，各个阶段比较清晰；强调早期计划及需求调查；适合稳定需求的产品开发。
改良：每个阶段都可以融入小的迭代工作。

2、开发模型——快速原型模型
实现一个基本原型，让用户对原型进行评价，逐步调整，使满足用户最终要求。
优点：适合不能确定需求的软件。
缺点：不适合开发大型系统。

3、测试模型——V模型
需求分析、概要设计、详细设计、编码、单元测试、集成测试、系统测试、验收测试
①单元测试：又称模块测试，针对单一的程序模块进行的测试。
②集成测试：又叫组装测试，在单元测试的基础上，对所有模块进行测试。
③系统测试：将整个软件看做一个整体来进行测试，包括功能、性能、兼容性。
④验收测试：
（1）内测版（alpha）：内部交流版本，可能存在很多bug，不建议用户安装。
（2）公测版（beta）：面向所有用户，通过用户的反馈再去修改细节。
（3）候选版（gamma）：与正式软件相差无几。

4、V模型优缺点
①优点：包含了底层测试（单元测试）和高层测试（系统测试）；清楚的标识了开发和测试的各个阶段；自上而下逐步求精，每个阶段分工明确，便于整个项目的把控。
②缺点：自上而下的顺序导致了，测试工作在编码之后，导致错误不能及时的进行修改；实际工作中，需求经常变化，导致V模型反复执行，返工量大，灵活度较低。
改良：每个步骤都可以进行小的迭代工作。

5、测试模型——w模型
定义：开发一个V，测试一个V组合起来的模型。（也叫双V模型）

优点：开发伴随着整个开发周期，需求和设计同样需要测试；更早的介入测试，可以发现初期的缺陷，修复成本低；分阶段工作，方便项目整体管理。
缺点：开发和测试依然是线性的关系，需求的变更和调整，依然不方便；如果没有文档，根本无法执行W模型；对于项目组成员的技术要求更高。
总结：V模型适用于中小企业，W模型适用于中大型企业（因为人员要求高），H模型人员要求非常高，很少有公司使用。

6、黑盒测试
又称数据驱动测试，完全不考虑从内部机构和特性，只注重软件的功能需求（不管代码）。

7、白盒测试
把盒子打开研究里面的程序和源代码

8、黑盒测试分类
①功能测试：
（1）逻辑功能测试
（2）界面测试
（3）易用性测试
（4）安装测试
（5）兼容性测试
②性能测试
（1）时间性能
（2）空间性能
（3）一般性能
（4）稳定性
（5）负载测试
（6）压力测试

9、随机测试
针对重要功能、新增加的功能、特殊情况、以前发生过重大bug的模块进行二次测试；也叫探索测试。

10、软件测试分类
（1）安装测试阶段划分：单元测试、集成测试、系统测试
（2）是否覆盖源代码：
①白盒测试
②黑盒测试
a、功能测试
b、性能测试
（3）是否运行：静态测试（不运行程序）、动态测试（运行程序）
（4）其他
①回归测试
②冒烟测试
③随机测试
④验收测试（内测、公测、候选版）
（5）是否自动化：
①人工测试
②自动测试

11、测试用例
测什么，怎么测

12、等价类划分法
属于黑盒测试，将不能穷举的测试过程进行分类，从而保证完整性和代表性。
思考步骤：
（1）确定有效等价类和无效等价类
（2）有效等价类划分（题目条件，还要注意边界值）
（3）无效等价类划分（跟有效等价类相反，其他特殊情况——中文、英文、特殊符号、空）
注意：两个框要一个正确，一个错误，这样才能准确判断；一定要根据需求来判断预期结果。

13、等价类细节总结
（1）考虑输入长度
（2）考虑输入类型
（3）组成规则
（4）是否为空
（5）是否区分大小写
（6）是否重复
（7）是否去除空格

14、边界值
在测试过程中，一定要小心边界值（极值），因为在程序中这些边界最容易出问题。
具体测试用例书写思路：找到边界值和它两端的值，分别进行测试。
总结：边界值思想应该是选到边界和刚超过的值来进行测试，也要根据实际情况来选择；边界值和等价类是相辅相成的关系，配合使用的。

15、因果图
因：输入条件
果：输出条件、输出结果
适用于输入条件之间有相互制约、相互依赖的情况。

16、因果图中的符号
（1）恒等——有因就有果，没有因就没有果
（2）非——有因没有果，没有因有果
（3）或——条件有一个是真，结果就是真
（4）且（与）——条件为真，结果才为真，一个条件为假，结果就为假。

17、判定表
根据因果图来制定判定表（因果图可以不画）
组成部分：
（1）条件桩：所有条件
（2）动作桩：所有结果
（3）条件项：针对条件桩的取值
（4）动作项：针对动作桩的取值
书写步骤：
（1）列出所有条件和动作桩
（2）填写条件和动作桩中的项目
（3）简化判定表
注意：如果出现“-”代表此选项不影响最终结果。

18、场景法
主要用来测试业务流程：分为基本流（正确流程）和备选流（错误流程）
注意：还要补充一些异常情况。
在冒烟测试中主要采用场景法来测试。

19、流程分析法
适用于有先后顺序的测试；常用于业务流程、安装流程等等。每个流程就是一条测试用例，它只是在测试整体流程是否正确，细节还需要使用等价类、边界值等方法进行完善。

20、错误推断法
凭直觉和经验来设计测试用例，它是根据之前项目相关的bug数据总结来的。

21、正交表
从全面试验中挑选出有代表性的点进行测试（均匀分散，整齐可比）；高效率、快速、经济的方法。

22、正交表使用方法
（1）根据控件和取值数选择一个合适的正交表
（2）列举取值并编号，生成取值表
（3）把取值表与选择的正交表进行映射

23、混合正交表工具
在实际工作中，很多情况都是因素（控件个数）和水平（每个控件的可选个数）不同，我们在现成的正交表中找不到对应的表格，此时我们就需要使用混合正交表工具来生成混合正交表。
步骤：
（1）制作取值表（不需要编号，列出数据即可）
（2）复制表格中的数据放在一个新建的txt文档中，保存到allpairs文件夹中（例如：test.txt）
（3）win+r再输入cmd进入控制台界面
（4）使用控制台代码进入allpairs文件夹中（例如：e：回车 cd 复制文件夹路径 回车）
（5）再次输入allpairs.exe test.txt>chenggong.txt （test.txt是我们刚刚新建的文件，chenggong.txt是我们最终生成的正交表文件）

24、测试用例方法的选择
（1）测试功能和流程，要使用场景法。
（2）需要输入数据的地方，我们要使用等价类划分法，要注意配合边界值法来做详细测试。
（3）如果有条件组合的情况，我们要使用因果图制作出判定表。
（4）配置类软件，组合比较多的，我们要使用正交表来科学的选择测试用例。
（5）如果没有得到覆盖标准，就要增加一些测试用例。
（6）依靠经验追加一些测试用例（错误推断法）。

25、软件缺陷
缺陷就是软件的问题，最终表现为没有满足用户的需求。

26、属于软件缺陷
（1）软件未达到规格说明书表明的功能
（2）软件出现了规格说明书中指明不会出现的错误
（3）软件功能超出了规格说明书指明的范围
（4）软件未达到规格说明书未指明但应该达到的目标
（5）软件测试人员或用户觉得不好

27、缺陷的表现形式
（1）功能、性能没有实现或者部分实现
（2）设计不合理、功能不明确、逻辑不清楚或者存在矛盾
（3）实际结果和预期结果不同
（4）没有达到规格说明书要求的性能指标
（5）运行出错、崩溃、中断、界面混乱
（6）数据不正确、精度不够、不完整或者格式不统一
（7）用户不能接受的其他问题，如存取时间过长、界面不美观
（8）硬件或者软件存在其他问题

28、软件缺陷的状态
（1）提交——测试人员提交了一个缺陷给程序员
（2）打开——待处理
（3）拒绝——程序员认为不是缺陷或者重复，就可以修改状态为拒绝
（4）修复——程序员修复缺陷后提交的一个状态
（5）关闭——测试人员经过回归测试后，认为此缺陷已经解决，将其关闭
（6）推迟——可以放在后续版本解决的问题，但是要详细写出修复的日期或版本

29、软件缺陷的严重程度划分
（1）low——表面性错误，如错别字
（2）medium——影响一个相对独立的功能、仅仅发生在特定条件上、与需求定义不一致、断断续续出问题
（3）high——功能点没有实现、不符合用户需求、导致数据丢失
（4）veryhigh——频繁死机、大部分功能不能使用
（5）critical——系统瘫痪、异常退出、死循环、严重的计算错误

30、软件测试的优先级
（1）low——时间和资源允许的情况下修复
（2）medium——不会延迟发布，会在以后修复
（3）high——会制约开发和测试的进行，需要在发布之前修复
（4）veryhigh——影响系统，产生严重影响
（5）critical——导致系统几乎不可用

31、软件缺陷分类
（1）系统缺陷
（2）数据缺陷
（3）数据库缺陷
（4）接口缺陷
（5）功能缺陷
（6）安全性缺陷
（7）兼容性缺陷
（8）性能缺陷
（9）界面缺陷
（10）建议