【测试】测试详解

1.答疑篇

什么是软件测试：找bug，发现缺陷，验证软件产品特性是否满足用户的需求

特点：只是一个样本测试，具有不可穷性

软件测试和开发的区别：

• 难易程度：开发广度小，专业度高；测试广度大，专业度低
• 工作环境：基本相似
• 薪资待遇：中小企业总体比研发低，自动化等专业测试领域和研发基本无差距；大厂研发测                      试基本无差别
• 发展前景：自动化测试、安全测试等领域发展前景和研发基本一致
• 繁忙程度：敏捷模式下差距不大，产品发布前压力比较大
• 技术要求：测试要求更广泛：业务能力，设计和架构分析能力，测试手段和工具使用，用户                      模型分析和理解，编程能力

软件测试与调试的区别：

• 目的不同：调试(Debug)：确保程序做了程序员想它做的事情
                    测试(Testing)：确保程序解决了它该解决的问题
• 参与角色不同：测试由测试人员和开发人员来执行，黑盒测试主要由测试人员完成、单元/集                             成测试主要是由开发人员执行
• 执行阶段不同：测试贯穿整个软件开发生命周期
                           调试一般在开发阶段

软件的生命周期：指从软件产品的设想开始到软件不再使用而结束的时间。

                             需求分析→测试计划→ 测试设计、测试开发→ 测试执行→ 测试评估

软件测试岗位：软件测试工程师、测试开发工程师、性能测试工程师、安全测试工程师……

软件测试在不同类型公司的定位：

• 无组织性
• 专职VS兼职
• 项目性VS职能性
• 综合性

优秀测试人员具备的素质：

• 综合能力：沟通能力、快速学习能力、开发能力、文字能力
• 掌握自动化测试技术
• 优秀的测试用例设计能力
• 探索性思维
• 兴趣，责任感……

2.概念篇

2.1需求

概念：满足用户期望或正式规定文档（合同、标准、规范）所具有的条件和权能，包含用户需求和软件需求。需求规格说明书（prd）

• 用户需求：可简单理解为甲方提出的需求，如果没有甲方，那就是终端用户使用产品时必须                      要完成的任务，该需求一般比较简略
• 软件需求：又称功能需求，该需求会详细描述开发人员必须实现的软件功能

需求是测试人员开展软件测试工作的依据。

2.2测试用例

定义：测试用例（Test Case）是为了实施测试而向被测试的系统提供的一组集合，这组集合包                 含：测试环境、操作步骤、测试数据、预期结果等要素。

测试用例解决了两大问题：测什么，怎么测。

为什么要有测试用例：

• 提高测试效率
• 简历自动化的基础

2.3软件错误

概念：当且仅当规格说明是存在的并且正确，程序与规格说明之间的不匹配才是错误。当需求规               格说明书没有提到的功能，判断标准以最终用户为准；当程序没有实现其最终用户合理预               期的功能要求时，就是软件错误。

2.4开发和测试模型

2.4.1瀑布模型

• 优点：强调开发的阶段性； –强调早期计划及需求调查； 强调产品测试。
• 缺点：依赖于早期进行的唯一一次需求调查，不能适应需求的变化； 由于是单一流程，开发               中的经验教训不能反馈应用于本产品的过程；风险往往迟至后期的测试阶段才显露，               因而失去及早纠正的机会。
• 适用：小型项目

2.4.2螺旋模型

• 优点：强调严格的全过程风险管理；强调各开发阶段的质量；提供机会检讨项目是否有价                  值继续下去。
• 缺点：引入非常严格的风险识别、风险分析和风险控制，这对风险管理的技能水平提出了很高
             的要求；需要人员、资金和时间的投入；一旦风险分析错误就会带来一定损失。
• 适用：大型项目

2.5增量、迭代

区别如下图：

2.6敏捷

敏捷宣言：

• 个体与交互重于过程和工具
• 可用的软件重于完备的文档
• 客户协作重于合同谈判
• 响应变化重于遵循计划
• 在每对比对中，后者并非全无价值，但我们更看重前者

--- scrum

角色组成：由product owner(产品经理)、scrum master(项目经理) 和 team(研发团队)组成。

• product owner：负责整理user story(用户故事)，定义其商业价值，对其进行排序，制定发布
                             计划，对产品负责；
• scrum master：负责召开各种会议，协调项目，为研发团队服务；
• team：由不同技能的成员组成，通过紧密协同，完成每一次迭代的目标，交付产品。

基本流程：产品负责人制定product backlog——发布计划会议——迭代计划会议——每日例会                          ——演示会议——回顾会议

2.7软件模型

2.7.1v模型

• 优点：线性执行；明确标注测试过程中存在的不同类型的测试。
• 缺点：仅仅把测试作为在编码之后的一个阶段，测试人员介入需求较晚，发现问题时机较晚。

2.7.2w模型

• 优点：测试人员可更早介入需求，有利于尽早发现问题。
• 缺点：测试和开发保持一种线性的前后关系，上一阶段完全结束，才可正式开始下                             阶段工作；不能拥抱变化；无法支持敏捷开发模式。
• 特点：双v模型，测试与开发同步进行，第一个v是开发流程，第二个v是测试流程。

3.基础篇

测试报告：项目名称，项目代码地址，开发人员，测试人员，项目计划（测试计划、开发计                              划），测试用例，bug……

3.1bug

3.1.1bug的描述

一个合格的bug应该包括以下几个部分：

• 发现问题的版本
• 问题出现的环境：软件/硬件，Web项目/APP项目
• 错误重现的步骤：描述问题重现的最短步骤
• 预期行为的描述：让开发人员知道怎样是正确的，依据需求提出故障，写明需求来源最好
• 错误行为的描述：crash等可上传log，UI问题可截图
• 其他：故障分类，优先级分类……
• 不要把多个bug放在一起

3.1.2bug的级别

1> Blocker（崩溃）

阻碍开发或测试工作；造成系统崩溃、死机、死循环；导致数据库数据丢失，与数据库连接错误；主要功能丧失，基本模块缺失等问题。如：代码错误、死循环、数据库发生死锁、重要的一级菜单功能不能使用等。

2> Critical（严重）

系统主要功能部分丧失，数据库保存调用错误，用户数据丢失，一级功能菜单不能使用但是不影响其他功能的测试；功能设计与需求严重不符，模块无法启动或调用；程序重启、自动退出，关联程序间调用冲突；安全问题、稳定性等问题。如：软件中数据保存后数据库中显示错误，用户所要求的功能缺失，程序接口错误，数值计算统计错误等。

3> Major（一般）

功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。如：操作时间长、查询时间长、格式错误、边界条件错误，删除没有确认框、数据库表中字段过多等。

4> Minor（次要）

界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等问题。如：错别字、界面格式不规范，页面显示重叠、不该显示的要隐藏，描述不清楚，提示语丢失，文字排列不整齐，光标位置不正确，用户体验感受不好。

3.1.3bug的生命周期

注意：rejected、delay的bug一定要周知到项目相关人，团队领导

           无效的bug：open->closed、open->rejected->closed

tips：软件测试同样存在二八原则，80%的故障集中于20%的模块                                                             开发人员也存在二八原则，80%的故障集中于20%的开发人员

3.2解决争执

作为一名测试人员，一般会遇到以下几种情况与开发人员PK：

• 这不是bug
• 这个bug的级别太高了
• bug影响不大，暂不修改

此时需要发挥我们测试人员的专业素养，批判性思维解决争执。

1> 检查自身是否bug描述不清楚；                                                                                                    2> 站在用户角度考虑问题，让开发人员了解到bug对用户可能造成的困扰；                                    3> bug定级要有理有据；                                                                                                                    4> 提高自身的技术和业务水平，提出问题的同时最好也能提出解决方案；                                      5> 开发人员不接受时，不要争吵。

如果多轮沟通后开发人员仍拒不接受，可发起bug评审，包括两个层面：如何处理bug；分析缺陷产生的原因，找出预防的对策。

4.用例篇

4.1基本要素

概念：测试用例是为了实施测试而向被测试的系统提供的一组集合。                                                           这组集合包含：测试环境、操作步骤、测试数据、预期结果等要素。

好处：测试执行者的依据；使得工作可重复；自动化测试的基础；评估需求覆盖率；用例的复用；
           积累测试的方法思路以供后续借鉴。

测试用例覆盖率越高，测试质量越高。

4.2设计方法

分为功能测试需求和非功能测试需求：

• 功能性需求：各个功能界面的验证，功能的一致性、交互性，对错误、异常操作的测试，易                          用性，用户体验等。
• 非功能测试需求：主要涉及性能，安全性，可靠性，兼容性，易维护性和可移植性等。
   

4.2.1等价类

定义：依据需求将输入划分为若干个等价类，从每个等价类中选出一个测试用例，如果
           这个测试用例测试通过，则认为所代表的等价类测试通过。

• 有效等价类：对于程序的规格说明书是合理的、有意义的输入数据构成的集合；
• 无效等价类：根据需求说明书，不满足需求的集合。

组合规则：有效等价类组合时，一条测试用例尽可能多的覆盖有效等价类；                                                      无效等价类组合时，一条测试点只能覆盖一个无效等价类。

4.2.2边界值

定义：对输入或输出的边界值进行测试的一种黑盒测试方法，，通常边界值分析法是作为对等
           价类划分法的补充，这种情况下，其测试用例来自等价类的边界。

• 上点：边界上的点。
• 内点：边界内的点。
• 离点：边界左右的一个点。如果是闭区间，离点就是范围外的点；如果是开区间，离点就是               范围内的点。

上点：1,10； 内点：2~9； 离点：0,9

4.2.3其他方法

错误猜测法：对被测试软件设计的理解，过往经验以及个人直觉，推测出软件可能存在的缺陷，                          从而针对性地设计测试用例的方法。

场景设计法：是用业务流把各个孤立的功能点串起来，为测试人员建立整体业务感觉，从而避免                          陷入功能细节忽视业务流程要点的错误倾向。

因果图：借助图形来设计测试用例的一种系统方法，特别适用于被测试程序具有多种输入条件、                   程序的输出又依赖于输入条件的各种情况。 

正交排列：根据正交性，由试验因素的全部水平组合中挑选出部分有代表性的点进行试验，通过                      对这部分试验结果的分析了解全面试验的情况，找出最优的水平组合。

4.3测试用例的粒度和评价

粒度：测试用例编写的详细程度。

测试用例编写参考以下内容：

• 产品的质量要求
• 项目对用例的要求
• 测试时间和资源是否充分

注意：不管测试用例如何简化，都不应省略。

评价：分为正式和非正式评审：

• 同行评审
• 用户检查
• 项目组评审

5.进阶篇

5.1按照测试对象划分

5.1.1界面测试

界面测试（简称UI测试)，指按照界面的需求（一般是UI设计稿）和界面的设计规则，对我们软件界面所展示的全部内容进行测试和检查，一般包括如下内容：

• 界面内容显示的完整性，一致性，友好性；
• 界面布局和排版是否合理，不同板块字体的设计，图片的展示是否符号需求；
• 界面不同控件如对话框，文本框等是否符合要求；
• 界面的布局和色调是否符合当下事实的发展。

5.1.2可靠性测试

可靠性（Availability）即可用性，是指系统正常运行的能力或者程度，一般用正常向用户提供软件服务的时间占总时间的百分比表示。

可靠性 = 正常运行时间/（正常运行时间+非正常运行时间）*100%

5.1.3容错性测试

容错性测试是指系统能够处理异常，用户的错误操作而不至于系统崩溃，从而能够提高系统的可用性。包含以下方面：

• 输入异常数据或进行异常操作，以检验系统的保护性；
• 灾难恢复性测试。

5.1.4文档测试

分为三大类：开发文件，用户文件，管理文件。

在实际的测试中，最常见的是用户文件的测试，例如手册说明书等。也会有一些公司对需求文档进行测试，来保证需求文档的质量。

文档测试的关注点：

• 文档的术语
• 文档的正确性
• 文档的完整性
• 文档的一致性
• 文档的易用性

5.1.5兼容性测试

兼容性测试需求是指明确要测试的兼容环境，考虑软，硬件的兼容，对于软件兼容来说，主要考虑以下几个方面：

• 系统自身版本的兼容，用户已有数据的兼容，其中数据兼容是重中之重；
• 测试与应用环境的兼容，如操作系统，应用平台，浏览器的兼容；
• 测试与第三方系统以及第三方数据的兼容。

5.1.6易用性测试

应用人体工程学的研究成果，使产品在使用起来更加灵活舒适。

易用性七要素：符合标准和规范，直观性，一致性，灵活性，舒适性，正确性和实用性。

5.1.7安装卸载测试

应用的安装和卸载在任何一款APP中都属于最基本的功能，一旦出错，就属于优先级为紧要Critical的缺陷。主要需要考虑以下方面：

• 软件不同的安装和卸载方式
• 应用是否可以在不同的环境、版本下安装（安装兼容性）
• 安装或卸载过程中是否可以手动暂停或取消
• 安装空间不足时系统是否有提示
• 是否可以正常卸载，以及应用软件的各种卸载方式
• 卸载和安装过程中出现环境问题，软件是否可以正常且合理应对，如死机、断电、断网等

5.1.8安全测试

安全性是指信息安全，指计算机系统或网络保护用户数据隐私，完整，保护数据正常传输和抵御黑客，病毒攻击的能力。常见安全漏洞和威胁如下：

• 输入域，如输入恶性或带有病毒的脚本或长字符串
• 代码中的安全性问题，如SQL/XML注入
• 不安全的数据存储或者传送
• 数据文件，邮件文件，系统配置文件等里面有危害系统的星系或数据
• 有问题的访问控制，权限分配等
• 假冒ID进行身份欺骗
• 篡改，对数据的恶意修改，破坏数据的完整性

安全性测试法方法：代码评审、渗透测试、安全运维。

5.1.9性能测试

对产品的性能需求进行分析，然后基于系统的性能需求和系统架构，完成性能测试的设计和执行，最后要进行持续的性能调优。常见性能问题如下：

• 资源泄露
• 资源瓶颈
• 线程死锁，线程阻塞
• 查询速度慢或效率低
• 受外部系统影响越来越大

衡量性能好坏的指标：用户响应时间，事务平均响应时间，吞吐率，每秒点击次数，内存和CPU                                        使用率。

5.1.10内存泄漏测试

常见内存泄漏原因：

• 分配完内存后忘了回收；
• 程序写法有问题，造成无法回收；
• 某些API函数使用不正确，造成内存泄漏。

内存泄漏检测方法：

• 人工静态法：代码走读，人工查找未被回收的内存；
• 自动工具法：借助相应测试内存泄漏的工具，如VIsual Leak Detector，记录每次内存分配，                          清楚告知用户内存是如何泄漏的。

5.2按照是否查看代码划分

5.2.1黑盒测试

定义：在完全不考虑程序逻辑和内部结构的情况下，检查系统功能是否按照需求规格说明书的规               定正常使用、是否能适当的接收输入数据而输出正确的结果，满足规范需求。

所以，黑盒测试又称为数据驱动测试，只注重软件的功能。

优点：

• 不需要了解程序内部的代码以及实现
• 从用户角度出发设计测试用例，易知道用户需求
• 测试用例基于软件需求开发文档，不容易遗漏需要测试的功能

缺点：不能覆盖所有代码。

测试方法：等价类、边界值、因果图、场景法、错误猜测法。

5.2.2白盒测试

定义：通过检查软件内部的逻辑结构，对软件中的逻辑路径进行覆盖测试；在程序不同地方设立               检查点，检查程序的状态，以确定实际运行状态与预期状态是否一致。

测试方法：语句覆盖、判定覆盖、条件覆盖、判定条件覆盖、条件组合覆盖、路径覆盖。。

5.2.3灰盒测试

定义：介于白盒测试与黑盒测试之间的一种测试，灰盒测试多用于集成测试阶段，不仅关注输                   出输入的正确性，同时也关注程序内部的情况。

5.3按照开发阶段划分

5.3.1单元测试

定义：对软件组成单元进行测试，又称为模块测试。

• 测试目的：检验软件基本组成单位的正确性
• 测试阶段：编码后或编码前
• 测试对象：最小模块
• 测试人员：白盒测试工程师或开发工程师
• 测试依据：代码+注释+详细设计文档
• 测试方法：白盒测试
• 测试内容：模块接口测试，局部数据结构测试，路径测试，错误处理测试，边界测试

5.3.2集成测试

定义：将程序模块采用适当的集成策略组装起来，对系统的接口及集成后的功能进行正确性检                   测，又称为联合测试（联调）。

• 测试目的：检查软件单位之间的接口是否正确
• 测试阶段：单元测试之后进行
• 测试对象：模块间的接口
• 测试依据：单元测试的模块+概要设计文档
• 测试方法：黑盒测试+白盒测试
• 测试内容：模块之间数据传输、模块之间功能冲突、模块组装功能正确性、全局数据结构、                      单模块缺陷对系统的影响

5.3.3系统测试

定义：将软件系统看成一个系统的测试，包括对功能、性能以及软件所运行的软硬件环境进行测试

• 测试阶段：集成测试通过之后
• 测试对象：整个系统（软、硬件）
• 测试人员：黑盒测试工程师
• 测试方法：黑盒测试
• 测试内容：功能、界面、可靠性、易用性、性能、兼容性、安全性等

5.3.4回归测试

定义：指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。

回归测试在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会多次进行回归测试。随着系统的增大，回归测试的成本越来越大，通过选择正确的回归测试策略来改进回归测试的效率和有效性是很有意义的。

5.3.5冒烟测试

• 测试目的：确认软件主要功能和核心流程正常
• 测试阶段：正式进行系统测试前
• 测试对象：每一个新编译的需要正式测试的软件版本

如果冒烟测试通过，则测试人员开始进行正式的系统测试，如果不通过，测试人员可以让开发人员重新修复代码直到冒烟测试通过，再开始进行系统测试。

5.3.6验收测试

定义：部署软件之前的最后一个测试操作，是技术测试的最后一个阶段，也称为交付测试。

• 测试目的：确保软件准备就绪，各方面都满足需求
• 测试阶段：系统测试通过之后
• 测试对象：整个系统（包括软硬件）
• 测试人员：最终用户或需求方
• 测试依据：用户需求、验收标准
• 测试方法：黑盒测试
• 测试内容：同系统测试

5.4按照实施组织划分

5.4.1α&β测试

α测试：由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进               行的测试。目的是评价软件产品的FLURPS（即功能、局域化、可使用性、可靠性、性能                 和支持）。

β测试：一种验收测试，由软件的最终用户们在一个或多个场所进行。

区别：

• 测试场所：α测试是把用户请到开发方的场所来测试；β测试是在一个或多个用户的场所进行                      的测试。
• 测试人员：α测试的环境受开发方控制，用户的数量相对比较少，时间比较集中；β测试的                          环境不受开发方控制，用户数量相对比较多，时间不集中。
• 测试时间：α测试先于β测试执行；通用软件产品需要较大规模的β测试，测试周期较长。

5.4.2第三方测试

定义：介于开发方和用户方之间组织的测试。

5.5按照是否运行代码划分

5.5.1静态测试

定义：不实际运行被测软件，只是静态地检查程序代码、界面或文档中可能存在的错误。不测试               数据，而是对测试对象的分析过程，仅通过分析或检查源程序的设计、内部结构、逻辑、               代码风格和规格等来检查程序的正确性。

5.5.2动态测试

定义：实际运行被测程序，输入相应的测试数据，检查实际输出结果和预期结果是否相符，所以               判断一个测试属于动态测试还是静态的，唯一的标准就是看是否运行程序。

注意：大多数软件测试工作都属于动态测试。

5.6按照是否手工划分

5.6.1手工测试

定义：人为去一个一个的输入用例，然后观察结果，和机器测试对应，是比较原始但是必须的一               个步骤。

• 优点：自动化无法替代探索性测试、发散思维结果的测试。
• 缺点：执行效率慢，量大易错。

5.6.2自动化测试

定义：在预设条件下运行系统或应用程序，评估运行结果，预设条件应包括正常条件和异常条                   件。即把以人为驱动的测试行为转化为机器执行。

分类：功能测试自动化、性能测试自动化、安全测试自动化；                                                                   （按测试对象分）接口测试、UI测试等，接口测试的ROI（产出投入比）比UI测试高。

5.7按照地域划分

5.7.1国际化测试

软件本地化和国际化测试是一个综合翻译行业和软件测试行业的测试类型。它要求测试人员具备一定的翻译能力、语言文化，同时具备测试人员的基本技能。

其定义顾名思义，这里就不赘述了…………

5.7.2本地化测试

见上