软件测试基础-概念篇

软件测试概要

软测定义:使用人工或自动的手段来运行或测量软件系统的过程，以检测软件系统是否满足规定的要求，并找出与预期定义之间的差异。

软测对象:

• 软件需求
• 概要设计
• 详细设计
• 源代码
• 可运行程序可运行环境

软测的五大要素及两大目标:

• 质量(最为核心)

• 人员(决定因素)

• 技术(实现手段)【测试技术，方法，测试工具】

• 资源【测试所需的硬件，网络环境，测试生命周期，测试时间】

• 流程(测试标准)【测试计划，测试执行，报告】

目标

• 提升测试覆盖率
• 测试效率

软测的遵循原则

1. 测试是为了发现错误而不是证明没错误
2. 穷尽测试是不可能的，应设定终止条件(无穷无尽的测试是不可能的，需很大代价;无论怎样测试，我们不可能发现软件的所有缺陷)
3. 测试尽早进行
4. 缺陷具有群集性(发现好多缺陷的模块，说明该模块存在没有被发现的缺陷)
5. 测试的杀虫剂悖论(应对测试用例，测试方法不定期的评审，添加新的测试用例或测试方法发现新的缺陷)
6. 测试的二八原则(80%的时间测试20%的重要模块)
7. 测试活动依赖于测试背景(如电信这块主要性能测试，银行啥的主要安全测试)

软件测试阶段

软件测试按测试阶段来分类：单元测试、集成测试、系统测试、验收测试。

单元测试:（认为规定的最小的测试模块，可以是c语言的一个函数，可以JAVA中的每个类，可以看做一个登陆功能）

单元测试是对代码进行测试

测试框架：junit针对JAVA nunit针对.net phpunit针对PHP CppUnit针对C++

集成测试:：偏于技术角度验证
是在单元测试的基础上，测试在将所有的软件单元按照概要设计规格说明的要求组装成模块，子系统或系统的过程中各部分工作是否达到或实现相应技术指标及要求的活动
尽可能保证各个测试用例是互相独立的，
主要实施方案：

• Big Bang。也叫一次性集成。就是把所有的东西组装好，然后再一起进行测试。
• 自顶向下。是一个递增的组装软件结构的方法。
• 自底向上
• 核心系统集成。
• 高频集成。高频次的不断地进行集成。

系统测试:（功能测试，性能测试，稳定性测试）
把整个系统组装以后置于真实的运行环境对这个系统进行全面的测试。主要做功能测试、性能测试、稳定性测试等多种测试。是将经过集成测试的软件，作为计算机系统的一个部分，与系统中其他部分结合起来，在实际运行环境下对计算机系统进行的一系列严格有效的测试，以发现软件潜在的问题，保证系统的正常运行。
系统测试和集成测试
1.测试对象不同：集成：由通过了单元测试的各个模块集成起来的构件；
系统：除了软件之外，还包括计算机硬件及相关的外围设备、数据采集和传输机构、支持软件、系统操作人员等整个系统。
2.测试时间：集成测试介于单元测试和系统测试之间；系统测试在集成测试之后
3.测试内容：集成：各个单元模块之间的接口；系统：整个系统完整的功能
4.测试角度：集成：偏于技术；系统：偏于业务

验收测试:（交付测试）
从用户的角度对系统软件的认可验收。也称交互测试。针对用户需求、业务流程的正式的测试，确定系统是否满足验收标准，由用户、客户或其他授权结构决定是否接受系统。

alpa测试，开发人员提供场景环境，用户测试

Beta测试，完全脱离开发人员，在用户提供的场所和环境下进行测试
系统测试阶段更多的使用黑盒测试
文档测试：针对软件产品的交付品，配套的文档类部件的测试。如用户手册，使用说明、用户帮助文档等。

---

按测试手段来分类

• 黑盒测试，白盒测试
• 静态测试，动态测试
• 手工测试，自动化测试

黑盒测试
黑盒主要测试

• 是否有不正确或遗漏的功能？

• 在接口上，输入是否能正确的接受？能否输出正确的结果？

• 是否有数据结构错误或外部信息访问错误？
• 性能上是否能够满足要求？

黑盒测试优点

• 容易实施，不需要关注内部的实现

• 更贴近用户的使用角度

  黑盒测试缺点

• 测试覆盖率较低，一般只能覆盖到代码量的不到40%

• 针对黑盒的自动化测试，复用率较低，维护成本较高。

白盒测试

测试主要的逻辑单位 语句 条件 条件组合 分支 路径
能够尽早的发现缺陷，有利于重构，简化集成，文档，用于设计，

不可能覆盖所有的执行路径，所以不可能保证捕捉到所有的错误，

每一行代码，一般需要3·5行测试代码才能完成单元测试，所以存在投入和产出的一个平衡，

白盒测试的优点

• 迫使测试人员去仔细思考软件的实现，理解原理
• 揭示应藏在代码中的错误
• 对代码的测试比较彻底

白盒测试的缺点

• 昂贵
• 无法检测代码中遗漏的路径和数据敏感性错误
• 不能直接验证需求的正确性

白盒测试的主要测试方法：
代码检测法：多面检查、代码审查、走查等。主要检查代码和设计的一致性。
静态结构分析法：使用测试工具，内部结构分析进行设计测试用例
静态质量度量法：标准的度量模型（ISO标准等）
逻辑覆盖法：6种逻辑，语句 ，分支，条件，条件判定组合，路径，判定
基本路径测试法：通过分析复杂度，选出基本可执行路径的集合。程序控制流图，描述程序控制流

灰盒测试
介于黑、白盒测试之间的，关注输出对于输入的正确性，同时也关注内部表现

静态测试
定义：静态测试是指无须执行被测程序，而是通过评审软件文档或代码，度量程序静态复杂度，检查软件是否符合编程标准，借以发现编写的程序的不足之处，减少错误出现的概率；
方式：互审、走查、会议

动态测试
定义：动态测试是指通过运行被测程序，检查运行结果与预期结果的差异，并分析运行效率、正确性和健壮性等。

手工测试
由专门的测试人员从用户视角来验证软件是否满足设计要求的行为。更适用针对深度的测试和强调主观判断的测试。
众包测试，探索式测试

自动化测试
使用单独的测试工具软件控制测试的自动化执行以及对预期和结果进行自动检查。
单元测试、接口测试、性能测试等

手工测试VS自动化测试
手工测试：
优点：易发现缺陷，容易实施，创造性、灵活性；
缺点：覆盖量化难，重复测试效率低，不一致性、可靠性低，人力资源依赖
自动化测试：
优点：高效率、速度快，高复用性，覆盖率容易度量，准确、可靠，不知疲劳；
缺点：机械、发现缺陷率低，一次性投入较大

软件测试模式

按测试模式来分类：
瀑布模型、敏捷测试、基于脚本的测试、基于风险的测试、探索式测试等。
（传统的）瀑布模型：项目计划->需求分析->软件设计->程序开发->软件测试->集成维护
优点：强调需求，前一阶段完成后只需关注后续阶段，提供按阶段划分的检查点，文档规范
缺点：难以适应需求的频繁变化，项目周期后段才可看到成果，较关注时间节点，文档工作量较大，测试在项目的后期

V模型（最广泛）
需求分析->概要设计->详细设计->软件编码->单元测试->集成测试->系统测试->验收测试
缺点：也没能体现出测试需要尽早进行的原则

W模型（双V模型）
开发与测试并行，可以尽早发现问题
局限性：需求、设计、编码仍然是串行进行的，上一个阶段完成之后才能进行下一个阶段

X模型
解决交接和频繁集成周期的问题

H模型：把软件测试看成一个独立的流程，与其他流程并发进行，比如设计流程，并发流程，甚至是测试流程

软件测试模式-敏捷测试

敏捷测试：Agile Testing–遵循敏捷宣言的一种测试实践。
敏捷测试的特点：

• 强调从客户角度进行测试
• 重点关注迭代测试新功能，不在强调测试阶段
• 尽早测试，不间断测试，具备测试条件即测试
• 强调持续反馈
• 预防缺陷重于发现缺陷

敏捷宣言：

• 个体与交互 重于 过程和工具

• 可用的软件 重于 完备的文档

• 客户协作 重于 合同谈判

• 响应变化 重于 遵循计划

敏捷测试的特点：

• 强调从客户角度进行测试
• 重点关注迭代测试新测试，不在强调测试阶段
• 尽早测试，不间断测试，具备条件即测试
• 强调持续反馈
• 预防缺陷重于发现缺陷

敏捷测试VS传统测试
传统测试：

• 测试是质量的最后保护者；
• 严格的变更管理；
• 预先的计划和细节的准备；
• 重量级文档
• 各阶段测试严格的入口和出口标准；
• 更多在回归测试时进行重量级的自动化测试；
• 严格依赖流程执行；
• 测试团队和开发团队是相对独立的

敏捷测试：

• 开发和测试人员是紧密合作，大家都有责任对软件负责；
• 变更是可接受的，拥抱变更；
• 计划随着进展时常调整；
• 只需要绝对必要的文档；
• 各迭代之间已经没有明显的入口和出口标准；
• 所有阶段都需要自动测试，每个人都需要做，是项目集成的一部分；
• 流程不再需要严格执行；
• 团队合作是无缝隙合作；

软件测试类型

软件测试类型-性能测试

负载测试：在测试过程中，逐步的增加负载，来观察系统的表现，最终确定出系统在正常的指标范围下的最大负载。

压力测试：测试系统在极限情况下的压力情况，最终系统字什么样的压力环境下会导致失效，不能正常运行，确定出我们这个系统所能承受的最大极限。

稳定性测试：一般是以稍大于正常业务量的负载进行持续的、长时间的测试，比如：24*5，连续5天的对这个系统进行24小时的施加压力，以确定系统在较长时间的运行情况下，我们这个系统地稳定性情况。

性能指标:

• 并发用户数VU，同时访问系统的用户数量；
• 每秒事务数TPS，每秒系统处理业务的数量；
• 系统响应时间；
• 设备性能，CPU等

性能测试工具：LoadRunner ,Silkperformer , Jmeter(java开源的有效的测试工具) ,WebLoad , Apache Bench, LoadUI(专门针对http接口的性能测试)

静态性能评估：开发Web应用时，基于一系列Web应用页面性能的最佳实践队Web应用的页面进行静态分析，并给出评估结果的性能分析方法。

评估的标准/工具（YSlow，PageSpeed）

应用性能管理(APM):

提供对系统的实时监控以实现性能管理、故障管理的解决方案。

下面博主演示了听云公司的官网上的产品——听云server的使用。
易用性测试主要针对用户的体验。人及交互界面是否友好？

软件测试类型-安全测试

安全测试：对软件产品进行测试以保证其符合产品安全需求和质量标准

安全测试工具各种针对的点：

• Appscan,Webinspect，W3AF：web应用
• Nessus：服务器，主机
• Nmap：端口开放
• MetaSploit：攻击软件，渗透测试
• WebScarab：代理劫持
• Fortify：针对白盒，源码中的安全问题
  OWASP：Open Web Application Security Project 开放网络应用安全项目

下面博主演示了访问OWASP官网

OWASP Top Ten Project 2013

1. Injection 注入脚本漏洞使用户访问到不该访问的数据的目的
2. Broken Authentication and Session Management 失效的身份认证和会话管理 会话劫持漏洞
3. Cross—Site Scripting（XSS）跨站脚本
4. Insecure Direct Object References 不安全的对象直接引用 参数的保护
5. Security Misconfiguration 安全配置类错误
6. Sensitive Data Exposure 敏感信息泄露 信息传递没有对关键信息进行加密
7. Missing Function Level Access Control 功能级别访问控制缺失
   比如访问网站可以访问到用户没有权限到达的地方
8. Cross-Site Function Level Access Control（CSRF） 跨站请求伪造
9. Using Components with Known Vulnerabilities 使用了已知有漏洞的组件

10. Unvalidated Redirects adn Forwards 未被验证的重定向和转发

    （钓鱼网站）

软件测试类型-兼容性测试

软件测试类型-文档测试

文档测试关注要点：完整性、正确性、一致性、易理解性、易浏览性

可靠性测试：软件的可靠性和硬件的可靠性

易用性测试：测试用户软件时是否感觉方便，是否能保证用户体验的测试类型

本地化测试：针对软件的本地化版本实施的针对性测试

本地化主要测试内容：

• 语言，书写习惯
• 时区。日期格式、货币
• 当地风俗、法律法规
• 政治敏感内容

部署测试：也称安装测试，主要验证系统部署过程，并确保软件经过安装测试后可以正常使用

部署测试的主要测试内容：

• 在不同环境下的部署验证
• 参照部署文档执行，过程的合理、正确性
• 基础数据

无障碍性测试：也称可访问性测试，指软件需要提供便于特殊人群使用的功能，包括视障、听障、老年人、身体残疾用户等，无障碍测试则是针对这部分功能的测试。
不同的浏览器内核会导致兼容性的差异，需重点测试。
（1）软件本身的兼容性：主要是软件的向后兼容，如软件升级，以前版本的功能也能使用

（2）不同平台下的兼容性：如在Linux系统下的ubuntu、openSUSE等，进行平台的兼容性测试

（3）对不同的设备的兼容性：如32位、64位、如小型机、PC等

（4）软件的互操作性：如和一些主流应用的兼容，也就是说和大众软件互通，比如和微信、微博、QQ能适用，有时是很多网站的登录。。。。
功能测试工具：

• QTP、selenium（开源）、Watir，是web应用类的自动化测试、
• winrunner
• Sikuli基于屏幕截图的，简单的功能验证

测试尽量在研发开始进行。到后期测试的成本很大

渗透测试：通过模拟对软件系统的恶意攻击行为来评估系统安全性的一种测试

文档测试的重点：完整性、正确性、一致性、易浏览性、易理解性。
基于模型的测试-MBT
它的测试用例是从一个模型中导出所得，这个模型描述了被测系统的某些方面，通常是功能部分。
模型：对需求功能点建模

https://blogs.msdn.microsoft.com/sechina/2009/11/18/123/

主要的MBT工具
Spec Explorer( Microsoft )

GraphWalker( OpenSource )
http://graphwalker.github.io/

Tcases( OpenSource )
https://github.com/Cornutum/tcases

modeljunit( OpenSource )
http://www.cs.waikato.ac.nz/~marku/mbt/modeljunit/
基于风险测试——（RBT risk-based testing）
定义：一种基于对软件失效的风险评估并以此指导测试计划、设计、执行、结果评价的软件测试类型

风险：
质量风险（软件功能，易用性，性能，软件代码缺失）；
管理风险（人员能力不足，环境风险，被测系统的需求不清晰，被测系统关联的第三方系统不能联调）
风险级别=风险可能性*风险严重度

识别风险：
可能性：
复杂性；时间压力；高变更率；技能水平；地理分散度

严重程度：
使用频率；失效可视性；商业损失；组织负面影响和损害；社会损失和法律责任

局部探索式测试：输入；状态；代码路径；用户数据；执行环境

全局探索式测试：漫游测试法。
让测试人员像游客游览一样来测试，而且软件按照不同属性划分为各个区域。
商业区是指软件启动到关闭之间用户会使用的功能。
旅馆区是指软件休息没有实际运行时候的功能，例如后台进程和定时任务。
历史区是指版本遗留代码或者说以前版本经常出现bug的功能模块。
旅游区是指新手引导之类的功能。
娱乐区是指主要功能之外的一些辅助特性。
破旧区是指废弃或者已经隐藏的功能。

探索式测试测试流程（基于session）
konw you mession 了解测试重点，系统环境，有一个测试的总体思路
learning session 详细的学习探索被测系统了解系统的业务逻辑，具体功能，深入学习被测系统
coverage session 探索式测试的实施阶段，完成主要功能点的测试验收，完成测试点的覆盖
deep session 在上一个功能点的基础上，更深入的发散式的测试，挖掘深层次的问题，深入测试
close session 总结测试，整理测试信息，根据整理数据，分析有没有测试的遗漏
缺陷大扫除。
基于脚本的测试-SBT 强调先做出测试设计，然后再测试
Script-based Testing
Scripted Testing(ST)

探索式测试ET：
Exploratory Testing(ET)
完全抛开测试脚本的测试；
它是一种测试风格，思维不单单是一种测试技术

按照ST和ET的互补程度，有各种不同的测试种类

ST：系统性强；容易管理，控制；设计在先，执行在后；主要是验证自己的思路；可预见性
ET：自由灵活；与ST是互补的，执行和设计并行；不断和系统交互，带着问题测试；学习的过程（重在测试人员）

探索式测试的优点：

• 更能激发测试人员的创造性和工作乐趣；
• 增加了发现新的或较深入的bug的可能性；
• 在较短时间内找到更多的bug以及对SUT（software under test 被测程序）作一个快速的评估；
• 有利于更加有效的实施自动化；
• 更加适用于敏捷项目；
• 减少了在简单，繁复上用例的无谓编写时间

缺点：

• 测试管理上有局限性，较难协调和控制；
• 对于bug的重复利用和重现上作用有限；
• 对测试人员的测试技能和业务知识深度要求高；
• 只有在SUT一完全可用的前提下才更有作用；
• ET的生产率很难定义；
• ET本身较难进行自动化

其他的一些测试类型概念**：回归测试、冒烟测试、Monkey测试、AB测试

回归测试：软件功能修改后，对软件进行重新测试已确认修改没有引入新的错误或导致其他部分产生错误。

回归测试的中心在关键模块和重点功能组件。

软件研发周期中会进行多次回归测试，且尽量实现自动化。

Monkey测试：也称搞怪测试。就是用一些随机、稀奇古怪的方式来操作软件，以测试系统的健壮性和稳定性。

冒烟测试：来自于硬件板卡验证术语。软件上则用于确认代码中的更改会按预期运行，且不会破坏整个版本的稳定性。

A/B测试：多用于互联网行业，通过为页面提供2个版本给用户使用并记录相关的用户行为数据，来确定更优化设计的一种测试方案。

A/B测试实施要点：

• 多个方案并行
• 每次测试仅改动一个变量
• 按照某种规律进行优胜劣汰