软件测试

软件测试所遵循的原则

1. 测试显示缺陷的存在，但不能证明系统不存在缺陷
2. 穷尽测试是不可能的，应设定即时终止的条件
3. 测试应该尽早进行
4. 缺陷具备群集特性
5. 测试的杀虫剂悖论
6. 测试的二八原则
7. 测试活动依赖于测试背景
8. 单元测试
9. 集成测试
10. 系统测试
11. 实验测试

软件测试的分类

按测试手段分类：

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

单元测试：对软件中最小可测试单元进行检查和验证。

原则：(1)尽可能保证各个测试用例是相互独立的

(2)一般由代码的开发人员来实施，用以检验所开发的代码功能符合自己的设计要求

益处：尽早发现缺陷，有利于重构，简化集成，文档，用于设计

限制：不可能覆盖到所有的执行路径，所以不可能保证捕捉到所有路径的错误。每一行代码，一般需要3-5行测试代码才能完成单元测试，所以存在投入和产出的一个平衡。

单元测试框架

集成测试：是在单元测试的基础上，测试再讲所有的软件单元按照概要设计规格说明的要求组装成模块，子系统或系统的过程中各部分工作是否达到或实现相应的技术指标及要求的活动。

主要实施方案：

Big Bang

自顶而下

自底而上

核心系统集成

高频集成

集成测试&单元测试

1. 测试的对象不同
2. 测试的依据不同
3. 测试使用的方法不同

系统测试：是将经过集成测试的软件，作为计算机系统的一部分，与系统中其他部分结合起来，在实际运行环境下对计算器系统进行的一系列严格有效的测试，以发现软件潜在的问题，保证系统的正常运行。

关注点：关注系统本身的使用，关注系统与其他相关系统间的连通，关注系统在不同使用压力下的表现，关注系统在真实使用环境下的表现

系统测试&集成测试

测试对象

集成测试：由通过了单元测试的各个模块所集成起来的构件

系统测试：除了软件之外，还包括计算机硬件及相关的外围设备、数据采集和传输机构、支持软件、系统操作人员等整个系统

测试时间

集成测试介于单元测试和系统测试之间测试

系统测试在继承测试之后

测试内容

集成测试：各个单元模块之间的接口

系统测试：整个系统的功能和性能

测试角度

集成测试：偏于技术角度的验证

系统测试：偏于业务角度的验证

验收测试：称交付测试，针对用户需求，业务流程的整事的测试，确定系统是否满足验收标准，有用户，客户或其他授权机构决定是否接受系统

细分：用户检验测试，运行验收测试，合同和规范验收测试，alpha测试，Beta测试

黑盒测试

优点：①容易实施，不需要关注内部的实现②更贴近用户的使用角度

缺点：①测试覆盖率较低，一只船只能覆盖到代码的不到40%②针对黑盒的自动化测试，复用率低，维护成本较高

黑盒测试主要测试

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

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

③是否有数据结构错误或外部信息（例如数据文件）访问错误？

④性能上是否能够满足要求？

黑盒测试的主要设计方法

等价类划分法，边界值分析法，错误推测法，因果图法，正交试验分析法，状态迁移图法，流程分析法

白盒测试优缺点

优点：①博士测试人员去仔细思考软件的实现，理解原理②可以监测代码中的每条分支和路径③揭示隐藏在代码中的错误④对待吗的测试比较彻底

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

白盒测试的主要测试方法

①代码检测法

②静态结构分析法

③静态质量度量法

④逻辑覆盖法

⑤基本路径测试法

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

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

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

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

自动化测试：使用单独的测试工具软件控制测试的自动化执行以及对预期和结果进行自动检查

单元测试，接口测试，性能测试（适用于自动化测试）

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

按测试模型来分类

①瀑布模型②敏捷测试③给予脚本的测试④基于风险的测试⑤探索式测试

瀑布模型：项目计划->需求分析->软件设计->程序开发->软件测试->集成维护

优点	缺点
强调需求，设计的作用	那以适应需求的频繁变化
前一阶段完成后，只需要关注后续阶段	项目周期后段才能看到
为项目提供了按阶段划分的检查点，里程碑清晰	强制的里程碑、完成时间点
文档规范	文档工作量大

 

 

传统测试	敏捷测试
测试是质量的最后保护者	开发和测试人员是紧密合作的，大家都有责任对软件负责
严格的变更管理	变更是可接受的，拥抱变更
预先的计划和细节的准备	计划随着进展时长调整
重量级文档	只需要绝对必要的文档
各阶段测试严格的入口和出口	个迭代之间已经没有明显的入口和出口标准
更多在回归测试时进行重量级的自动化测试	所有阶段都需要自动测试，每个人都需要做，使项目集成的一部分
严格依赖流程执行	流程不再需要严格执行
测试团队和开发团队是相对独立的	团队合作是无缝隙合作

基于脚本的测试-SBT

Script-based Testing

Scripted Texting(ST)

Exploratory Texting(ET)

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

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

探索式测试：

Know You Mession

Learnin Session

Coverage session

Deep Session

Close Session

基于风险的测试-RBT

Risk-based Testing

一种基于对软件失效的风险评估并以此指导测试计划，设计，执行，结果评价的软件测试类型

识别风险：

可能性	严重程度
复杂性	使用频率
时间压力	失效可视性
高变更率	商业损失
技能水平	组织负面影响和损害
地理分散度	社会损失和法律责任

基于模型的测试-MBT

Model-based testing is software testing in which test cases are derived in whole or in part from a model that describes some (usually functional) aspects of the system under test (SUT).

(https://blogs.msdn.microsoft.com/sechina/1009/11/18/123/)

主要的MBT工具

Spec Explorer(Microsoft)

GraphWalker(OpenSource)

https//graphwalker.github.io/

Tcases(OpenSource)

https//github.com/Cornutum/tcases

Modeljunit(OpenSource)

https//www.cs/walkato.ac.nz/~marku/mbt/modeljunit/

按测试类型来分类

功能测试	性能测试	兼容性测试
可靠性测试	部署测试	易用性测试
	文档测试	本地化测试
	安全测试	无障碍测试

功能测试：根据产品特性、操作描述和用户反感、测试一个测聘的特性和可操作行为以确保它们满足设计需求

针对的问题：功能错误或遗漏，界面问题，性能错误，数据及访问错误，初始化及终止错误

功能测试工具：QTP winrunner、silk Test、Rational robot，selenium、Watir、Sikuli

性能测试：负载测试、压力测试、稳定性测试

性能指标：并发用户数VU、每秒事务数TPS、系统响应时间、设别性能

性能测试工具：LoadRunner、Silkperformer、Jmeter、WebLoad、Apache Bench、LoadUI

静态性能评估：开发Web应用是，基于一系列Web停用页面性能优化的最佳实

应用性能管理（APM）：Application performance Management，提供对系统的实时监控以实现性能管理，故障管理的解决方案

安全测试工具：Appscan、Webinspect、Nessus、Nmap、MetaSploit、WebScarab、Fortify、W3AF

兼容性测试：软件本身的兼容性、不同平台的兼容性、软件对运行设备的兼容性、软件互操作性

浏览器内核：

Trident4-6	Gecko	WebKit	Presto
IE6-8,、9、10	FireFox	Safari、Chrome	opera

浏览器兼容性测试工具：BrowserShots、Browser Sandbox、Google 浏览器兼容性插件（http://www.w3help.org/）

文档测试：针对软件产品的交付品，配套的文档类部件的测试。如用户手册、使用说明、用户帮助文档。文档测试关注的点：完整性、正确性、一致性、易理解性、易浏览性

可靠性测试：软件可靠性、硬件可靠性

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

本地化测试：针对软件的本地化版本实施的针对性测试。主要测试内容：语言、书写习惯，时间、如期个事、货币，当地风俗、法律法规，政治敏感内容。

部署测试：也称为安装测试，主要验证系统部署过程，并确保入软件经过安装测试后可以正常使用。主要测试内容：在不同环境下的部署验证，参照部署文档执行，过程的合理，正确性，基础数据。

无障碍测试：Accessibility Test.也称可访问性测试。是指软件需要提供便于特殊人群使用的功能，包括视障，听障，老年人，身体残疾用户等，无障碍测试则是针对部分功能的测试。

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

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

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

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

“每日构建”中用冒烟测试来确认合入的代码没有影响主要功能的正常

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

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

AB测试实施要点：①多个方案并行②每次测试仅改动一个变量③按照某种规则进行优胜略汰

AB测试工具：Google Analytics Content Experiments，Visual Website Optimizer