测试

3-2 软件测试类型-性能测试

2-2 软件测试手段

2-1软件测试阶段

需要学习jUnit测试可搜以下课程：

1-1软件测试概要

＊

敏捷测试

测试遵循原则

1. 二八原则 80%时间用在20%的重点模块上

1. 测试活动依赖于测试背景

1. 测试显示缺陷的存在，但不能证明系统不存在缺陷

1. 穷尽测试是不可能的，应该尽可能的设定及时终止的条件

1. 测试应尽早进行

1. 缺陷具备群集特性

1. 杀虫剂悖论 同样的用例和方法无法再发现新的问题 行不定期修改，评审

• 测试的二八原则

Script-based Testing

Script Testing（ST）

Linux 命令怎么使用 

定义：软件本身的兼容性（对历史版本的配置或数据兼容）

          不同平台下的兼容性（ubuntu centos redhat等）
           运行设备的兼容性（32位的 平板电脑 小型机等）

           软件的互操作性（与一些主流的应用是否兼容）

浏览器内核

浏览器兼容性测试工具

Browsershots browsersandbox Google浏览器兼容性测试插件（页面代码层面测试）

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

渗透测试：通过模拟对软件系统的恶意攻击行为来评估系统安全性的一种测试（取得了用户的授权）

安全测试vs安全测试

渗透测试：攻 、薄弱点

安全测试：防 、面、难度高

OWASP：Open Web Application Security Project（开放web应用安全项目）

前10名的漏洞问题：

注入：脚本或sql注入 页面输入构造

失效的身份漏洞或身份管理

跨站脚本：使用户浏览器能执行动态的内容

不安全的对象的直接引用：在url中修改参数

安全配置错误：如框架、服务有默认密码

敏感信息泄露：没对关键信息加密

功能级别的访问控制缺失：能够导航到用户没有权限的地方

跨站请求伪造：外部的一个恶意的网站获取到正常的数据

使用了已知的有漏洞的组件：没有及时打补丁

未被验证的重定向或转发：重定向没有没验证 可以被黑客转移到钓鱼网站

安全测试工具：

Appscan（Web 应用）

Webinspect

Nessus（服务器 主机类）

Nmap

MetaSploit（著名攻击软件）

WebScarab

Fortify（源代码静态分析）

W3AF（Web应用）

敏捷测试

Agile Testing

宣言：强调了个体的沟通重于过程，对于软件看重结果轻文档，客户视角与客户合作创造更多的价值，拥抱变化

特点：

强调从客户的角度测试

重点关注迭代测试新功能，不在强调测试阶段

尽早测试，不间断测试，具备条件即测试

强调持续反馈

预防缺陷重于发现缺陷（给整个研发提出建设性的意见，质量改进的建议，全方位的参与到软件研发的各个层面，提升整个团队的工作效率和保证产品质量）

与传统测试的区别：

传统测试是质量的最后保护者；开发和测试人员是紧密合作的，大家都有责任对软件负责

传统测试有严格的变更管理；变更是可接受的，拥抱变更

预先的计划和细节的准备（测试计划、测试方案、测试用例、规程文档）；敏捷计划随着进展时常调整；

重量级文档；只需要绝对必要的文档

各个阶段测试严格的入口与出口标准；各迭代之间已经没有明显的入口与出口标准

更多在回归测试时进行重量级的自动化测试；所有阶段都需要自动化测试，每个人都需要做

严格依赖流程执行；流程不再需要严格执行（注重测试结果，规则就是被打破的）

测试团队和开发团队是相互独立的；团队合作是无缝隙的合作（整个测试持续不断的质量反馈的过程，从研发生命周期的开始，就把测试过程中的问题持续不断的反馈给我们的开发人员、项目经理，及时知晓研发过程中的质量现状并且及时的进行改正）

基于脚本的测试-SBT

Scripted Testing(ST)

Exploratory Testing（探索式测试）：

完全抛开测试脚本的测试 探索被测系统，带着问题使用系统，在探索的过程中发现测试要点，找出被测系统的问题，在测试过程中测试设计和测试执行是并行的，更自由；

它是一种测试风格、思维而不是一种测试技术

局部探索式测试：

输入：接收输入 产生输出 存储数据 进行运算 输入顺序 输出内容 输出异常

状态：临时状态（运行时有效 阶段性有效） 永久状态（数据库保存 文件保存）

代码路径：对代码的覆盖率

用户数据：模拟真实用户数据

执行环境：软件运行的操作系统 网络拓扑 三方系统 系统的配置数据 硬件设备

全局探索式测试：

像游客游览一样测试系统

商业区：软件从启动到关闭用户可能使用到的一些功能

旅馆区：软件在没有运行时的功能如定时任务、一些后台进程

历史区：历史遗留的功能

旅游区：新用户使用或关注的功能（新手指引等）

娱乐区：辅助功能

破旧区：隐藏或遗弃的功能，用户看不到

执行探索式测试：

Konw You Mession：了解测试任务的重点 主要测试方向 系统的环境

Learnging Session：详细学习和探索被测系统 业务逻辑 系统功能

Coverage  Session：测试执行阶段 完成测试点的覆盖

Deep Session：更深入的发散式的测试

Close Session：总结 整理 复盘阶段

基于风险的测试-RBT

Risk-based Testing

风险：

质量风险（功能 易用性 性能 软件功能缺失 数据的转换）

管理风险（人员的技能不足 人力不足 测试环境不具备 被测系统的需求不够清晰 三方系统有问题等）

风险级别：风险的可能性*风险的严重度

识别风险：

可能性：复杂性（越复杂风险越大）时间压力 高变更率 技能水平 地理分散度（研发团队太分散 集成上有潜在的问题）

严重程度：使用频率 失效可视性 商业损失（支付功能 计费功能） 组织负面影响和损害 社会损失和法律责任

优点：优先测试的都是高风险的部分 对质量信心的提升非常明显

基于模型的测试-MBT

按软件测试模式来分类

1、瀑布模型

项目计划：制定研发计划，确定里程碑节点，输出项目计划书

需求分析：明确用户的需求定义，并对定义进行清晰的描述，充分理解客户需求明确产品功能，输出需求规格说明书

软件设计：根据需求确定产品实现的方案，概要设计、详细设计的多个文档

程序开发

软件测试：独立的测试的小组，评估产品是否满足需求，输出测试报告

集成维护：根据用户使用情况对产品进行修改

优点：强调需求、设计的作用；前一阶段完成后。只需关注后续阶段；为项目提供了按阶段划分的检查点，里程碑清晰；文档规范

缺点：难以适应需求的频繁变化；项目周期后段才能看到成果；强制里程碑、完成时间点；文档工作量大

没有体现出测试的地位和价值，测试阶段只是补救的阶段，缺陷发现太晚，修改成本高

2、V模型

使用最广泛的模型

明确表明了测试过程的不同阶段，描述了测试阶段与开发阶段的对应关系

单元测试、集成测试：检测程序是否满足设计上的要求

系统测试：软件在功能、性能上是否满足系统要求的指标

验收测试：是否满足用户的要求和合同的标准

在V模型里强调了软件开发的协作和速度，反应测试活动和分析设计的关系，并且将软件的实现和验证有机的结合起来。

局限性：仅仅把测试过程作为在编码后面的阶段，需求和系统设计的验证只能在验收测试中发现

3、W模型

V模型的改进模型

测试伴随整个开发周期，对需求和设计都全面测试，有利于尽早的发现问题

及时了解项目风险

局限性：开发与测试仍然是线性关系

4、X模型

5、H模型

将测试流程看成是一个独立的模型，与软件其他流程并发进行