软件测试理论

软件测试

根据需求（客户、行业规范、标准），运用技术手段，尽快、尽早、更多地发现软件的缺陷，保障软件问题得到妥善解决，目的提供软件开发质量和效率，提高客户满意度。

软件测试思维

逆向思考、发现尽可能多的缺陷，成功的测试在于发现迄今未发现的缺陷。测试绝不能证明软件100%正确；测试越早，发现问题后解决问题的成本越小。

软件测试原则

• 测试工作是有计划的，应尽早展开测试工作。

• 尽量避免测试自己开发的程序

• 测试只能证明缺陷存在，不能证明缺陷不存在

• 测试都应追溯到用户需求

• 测试设计和测试执行应该分离

• 测试缺陷具有免疫性，应该尽可能采用多种方法和数据对软件进行测试

• “彻底的测试”难以成为现实，要考虑时间、费用等限制，不允许无休止的测试

决定软件质量的关键因素

需求分析、设计和实现等，测试是贯穿于上述过程的一种检查手段

如何进行高效的测试

测试工程师可以尝试通过一些持续集成的手段，尽早地开展测试活动，还可以加入自动化技术，通过不断、反复地测试来发现更多的缺陷

软件缺陷无法完全消除

软件运行的环境多种多样、逻辑关系复杂、多种多样的数据结构都决定着软件测试活动不可能通过遍历所有的功能和使用场景来发现软件系统中所有的缺陷

软件开发的每个环节都可能够把软件缺陷引入系统中，通过测试只能发现部分缺陷，并不能检测到系统中的所有缺陷。

80-20原则

80%的缺陷聚集20%的模块中，经常出错的模块改错后还经常出错

软件测试流程：

测试启动准则

• 测试计划已经制定并且通过审批

• 测试用例已经制定并且通过审批

• 被测试对象已经开发完毕并等待测试

软件测试的对象

• 软件是由文档、数据以及程序组成的

• 测试应该是对文档、数据以及程序进行的测试

• 测试概念扩大化，提倡软件全生命周期测试的理念

软件测试阶段

单元测试（通常由开发人员完成）、集成测试、系统测试、验收测试

准入性测试（又称冒烟测试、确认测试）

冒烟测试就是在构建版本后，对软件的基本功能进行简单的测试。这种测试强调程序的主要功能进行的验证，而不会对具体功能进行更深入的测试。

Alpha和Beta测试

Alpha测试是用户在开发环节下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试，这是在受控制的环境下进行的测试

Alpha测试的目的是评价软件产品的FURPS(功能、可使用性、可靠性、性能和支持)

Alpha测试可以从软件产品编码结束之时开始，或在模块（子系统）测试完成之后开始，也可在确认测试过程中产品过程中产品达到一定的稳定和可靠程度之后再开始

Beta 测试是用户在实际使用环境下进行的测试，与α测试不同的是，β测试开发者同不在测试现场，开发者无法控制的环境下。

只有当α测试达到一定的可靠程度时，才能开始β测试，β测试处于整个测试的最后阶段，不能指望这时发现主要问题

软件测试方法

静态测试

静态测试指不运行程序，对程序和文档进行分析与检查包括软件中的需求规格说明书、设计文档、程序源码等进行审查

1.代码走查（走读）：开发人员间相互阅读代码，检查其编写是否正确

2.文档评估

需求文档的评审

设计文档的评审

测试文档的评审：测试计划、测试用例、

用户手册的评审

动态测试

动态测试是指通过人工或使用工具运行程序进行检查、分析程序的执行状态和程序的输出

白盒测试、黑盒测试、灰盒测试都属于动态测试

黑盒测试（功能测试）

通过软件的外部表现来发现其缺陷和错误；把测试对象看成一个黑盒子，完全不考虑程序内部结构和处理过程

黑盒测试是在程序界面进行测试，只是检查程序是否按照需求规格说明书的规定正确实现

如果软件需求本身有问题或规格说明有误，黑盒测试方法很难发现。

黑盒测试设计方法

等价类划分法、边界值分析法、错误推测法、因果图法、场景分析法

灰盒测试（接口测试）

关注输出对于输入的正确性，同时也关注内部表现，但不想白盒测试那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运行状态

单元测试应用白盒测试方法，集成测试应用灰盒测试方法，系统测试和确认测试应用黑盒测试方法

系统测试

产品已经可以使用，是针对整个产品系统进行的测试

功能测试

对产品的各种功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能，功能测试的依据是:《需求规格说明书》

基本方法：构造正常/异常输入检查输出是否与期望的相同。难点在于正确的理解用户需求和如何构造有效的测试数据。

功能测试的流程：需求评审分析-测试规划-测试执行(环境搭建)-问题分析报告-测试总结

性能测试

测试软件处理业务的速度；检验性能是否符合需求；得到某些性能数据以供参考

性能测试包括：容量评估（200TPS）、问题定位、压力测试（300TPS、400TPS、500TPS）、极限测试

健壮性测试（突发情况）

在异常情况下，软件还能正常运行的能力

健壮性有两层含义：容错能力（如输入错误的数据类型、超出定义域）、恢复能力（如能否重新运行、有无重要数据丢失）

安全性测试

防止系统被非法入侵的能力，既属于技术问题，又属于管理问题

有如下步骤：1、为非法入侵设立目标，如“盗窃某个文件或”更改数据库记录“ 2、邀请（或悬赏）一些人扮演黑客，让他们想尽办法入侵系统，实现”目标’ 3、如果有人成功，请她详述入侵过程

可靠性测试

在一定环境下，在给定的时间内、系统不发生问题的概率

软件缺陷

软件缺陷的定义

• ​ 未实现产品说明书要求的功能
• ​ 出现产品说明书要求不能出现的错误
• ​ 实现了产品说明书未提到的功能
• ​ 未实现产品说明书虽未明确提及但应该实现的目标
• ​ 软件难以理解、不易使用、运行速度慢，或测试人员认为最终用户会认为不好

如何发现软件缺陷

查找时间依赖（例如文件的有效期）和竞争条件的问题

查找边界条件软件缺陷、内存泄漏和数据溢出缺陷

查找状态转换时出现的缺陷

查找资源依赖性：内存、网络、硬件等方面的缺陷

查找和硬件相关方面的缺陷，比如硬件兼容性方面的缺陷

报告软件缺陷的原则

尽快报告软件缺陷

有效描述软件缺陷

对软件缺陷报告跟踪到底

每个报告只针对一个软件缺陷

软件缺陷描述

缺陷ID：唯一的，可以根据该ID追踪缺陷

缺陷状态：新建、待解决、已解决、已验证

缺陷标题：描述缺陷的标题

缺陷的详细描述：缺陷如何复现的步骤

缺陷的严重程度：致命、严重、一般、细微

缺陷的紧急程度：从1—4,1是优先级最高的等级，4优先级最低

缺陷提交人

缺陷提交时间

缺陷所属项目/模块：缺陷所属的项目和模块，最后能精确的定位至模块

缺陷指定解决人：缺陷指定的解决人，在缺陷“新建”状态为空，在缺陷“待解决”状态下由项目经理指定相关开发人员修改

缺陷指定解决时间：项目经理指定的开发人员修改此缺陷的deadline

缺陷解决人：最终解决缺陷的人

缺陷处理结果描述：对处理结果的描述，如果对代码进行了修改，要求在此体现出修改

缺陷复核人：对被处理缺陷复核的验证人

缺陷复核结果描述：对复核结果的描述（通过、不通过）

测试环境说明

必要的附件

软件缺陷生命周期

• 识别缺陷
• 提交缺陷
• 分析和定位缺陷
• 修改相应的程序
• 验证修改
• 关闭缺陷
• 通过分析缺陷的共性，防止缺陷再次发生

缺陷处理流程

1.用户或测试人员报告bug,安排开发人员寻找并解决问题，验证bug是否j解决，bug得到解决，关闭bug;

2.用户或测试人员报告bug,安排开发人员寻找并解决问题，验证bug是否解决，未解决则再次安排开发人员寻找并解决问题，再次验证bug是否解决，

回归测试

在软件错误修正、设计修改以及软件升级后，主要针对软件修改、影响部分进行有效性测试和系统测试

测试何时结束

需求覆盖度评估

需求覆盖度评估：需求覆盖度是“已经测试验证的产品需求数”和“产品需求规格总数”的比值。
需求覆盖度的目标必须是100%，即测试保证对产品承诺要实现的需求都进行了验证，并要对产品是否满足需求给出评估。

代码覆盖度评估

代码覆盖度评估：代码覆盖度是“已经测试到的代码数量”和“程序中可执行语句的总数量”的比值。此覆盖度可通过工具进行统计；
代码覆盖度分为：全量覆盖率和差异覆盖率，根据项目的不同，设置不同的测试通过条件。比如：新项目，全量覆盖率要在90%，并说明未覆盖到的原因；迭代项目，差异覆盖率要达到80%，并说明未覆盖到的原因。

测试用例分析

测试用例分析：通过测试用例执行率、测试用例执行通过率、测试用例和非测试用例发现缺陷比，进行测试用例分析；
进入到测试阶段后，每天应该有测试过程的评估产出，对于测试阻塞（指测试用例因为产品开发「一般指缺陷」、测试「如测试环境不具备」等原因，无法被执行的测试用例）这种情况，测试需要提前识别这些问题，进行风险识别和控制。

测试方法分析

测试方法分析：在测试之前，测试就需要根据产品的质量要求，根据测试目标、测试的深度和广度来确定测试方法；在测试用例评审时，保证各个特性使用的测试方法和测试策略相符，可以通过测试执行时的日报、周报，测试用例执行情况等方式去跟踪和分析。

缺陷密度分析

缺陷密度分析缺陷密度是指每千行代码发现的缺陷数。确定了缺陷密度后，还可以顺带得到缺陷总数。通过缺陷密度，可以帮助我们评估当前已经发现的缺陷总数是否足够多。如果缺陷密度和预期偏差较大，原则上不应该退出测试，发布产品。

缺陷修复情况分析

缺陷修复情况分析：缺陷修复率是指产品“已经修复解决的缺陷总数”和“已经发现缺陷总数”的比值。缺陷修复率能够帮助我们确定当前产品发现的缺陷是否被有效修复，为当前的产品质量是否达到测试质量目标提供最直接的判断依据。在测试开始时应该就确定缺陷修复率目标，如果最终缺陷修复率不能达到预期，原则上不应该退出测试，发布产品。