测试执行的艺术

测试执行

测试执行过程

主要任务

1. 确定测试用例的优先级
2. 开发测试规程并确定优先级，创建测试数据，同时也可以准备测试用例和设计自动化测试脚本
3. 根据测试规程创建测试套件，以提高测试执行的效率
4. 确认已经正确搭建的测试环境
5. 根据计划的执行顺序，通过手工或者使用测试工具来执行测试规程
6. 记录测试执行结果，以及被测软件，测试工具和测试件的标识和版本
7. 将实际结果和预期结果进行比较
8. 对实际结果和预期结果之间的差异，作为事件上报，并且进行分析与确定引起差异的原因
9. 缺陷修正后，重新进行测试活动

测试准入准出

准入标准：

1. 开发编码结束，并在开发环境已完成单元测试
2. 需求上规定的功能均已实现，如果没有完全实现，需要提供测试范围
3. 已完成集成测试，被测系统的基本流程可以走通，界面上的功能均已实现，经过代码评审并符合软件编码规范
4. 开发提交最新版本代码，以此为基线，提交并通知测试组进行测试
5. 兼容性测试要求明确
6. 安全测试和性能测试范围和要求

测试暂停、停止：

1. 测试人员先进行冒烟测试，若发现重大缺陷或者 bug 过多时，或者流程卡壳导致基本流程无法走通，测试无法正常进行，可以停止测试并返回开发
2. 被测项目需要调整而导致暂停的，测试也相应暂停
3. 存在其他优先级更高的任务时，可以向领导申请暂停测试
4. 测试系统经过系统测试，达到系统准出标准，可以停止测试

准出标准（不同公司会有不同的标准）：

1. 被测项目是否满足原型的要求
2. 所有测试用例都已经通过评审？
3. 所有测试用例都已成功执行？
4. 测试覆盖率是否达到100%
5. 所有发现的缺陷都记录在缺陷管理系统？
6. 一二级错误修复率达到100%？
7. 三四级错误修复率达到95%？
8. 所有遗留问题都已有解决方案？
9. 性能指标是否到达要求？
10. 兼容性测试是否满足？
11. 安全性测试是否达到要求？
12. 产出系统测试总结报告？

缺陷管理

软件缺陷：包括功能的错误，性能低下，易用性差，兼容性差等；

1. 软件未达到说明书表明的功能
2. 软件出现了产品说明书指明不会出现的错误
3. 软件功能超出产品说明书指明范围
4. 软件未达到产品说明书虽未指出，但应达到的要求
5. 软件测试人员认为软件难以理解，不易使用，运行速度缓慢，或者最终用户认为不好用

• 并不是所有的测试人员都能提交被开发认可的缺陷
• 也不是测试人员在任何时候都能提交被开发认可的缺陷

缺陷产生原因：

1. 沟通交流不够（出现频率高）
2. 需求不断变化
3. 软件的复杂性
4. 程序设计错误（最容易解决）
5. 文档不完善
6. 软硬件支持不完善
7. 工期短，任务大

发现缺陷的方法：

1. 用户体验不好
2. 界面上有明显的错误信息
3. 功能不完备，没有按照需求说明编写代码，致使某些功能缺失
4. 功能不完善，不能正常运行或者运行的过程中出现程序崩溃，停止运行的情况
5. 逻辑不正确，与需求说明书、测试用例不符
6. 模块间的交互性不好，与其他的模块做集成测试时遇到问题
7. 程序的性能不够好，不能承载压力考验

缺陷报告

bug 重现：

1. 不要想当然地接受任何假设，要做好记录
2. 查找时间依赖和竞争条件的问题
3. 边界条件软件缺陷，内存泄露和数据溢出等白盒问题可能会慢慢自己显露出来
4. 状态缺陷仅在特定软件状态中显露出来
5. 考虑资源依赖性和内存、网络、硬件共享的相互作用

无法重现的bug 处理：

1. 对缺陷进行详细的记录，并尽快提交给开发人员
2. 对于寻找难以再现的缺陷，要合理安排时间，要考虑到测试项目的整体进度，对一时难以重现的缺陷可以暂时搁置，以保证项目的正常进度
3. 在测试过程中，对未再现缺陷予以关注

缺陷报告：

• 对缺陷进行记录，分类与跟踪的文档
• 软件测试人员的任务之一就是书写良好的软件缺陷报告
• 提供准确、完整、简洁、一致的缺陷报告是体现软件测试的专业性，高质量的主要评价指标
• 直接读者是软件开发人员和质量管理人员，除此之外，来自市场和技术支持等部门的人都可能需要查看缺陷情况

包含信息的要求：

1. 易于搜索软件测试报告的缺陷：关键词管理；
2. 报告的软件缺陷进行了必要的隔离，报告的缺陷信息具体、准确：具体到哪个步骤有错
3. 软件开发人员希望获得缺陷的本质特征和复现步骤
4. 市场和技术支持等部门希望获得缺陷类型分布以及对市场和用户的影响程度

缺陷报告的写作准则（5C）：

1. 准确：每个组成部分的描述准确，不会引起误解
2. 清晰：每个组成部分的描述清晰，易于理解
3. 简洁：只包含必不可少的信息，不包括任何多余的内容
4. 完整：包含复现该缺陷的完整步骤和其他本质信息
5. 一致性：按照一致的格式书写全部缺陷报告

缺陷写作格式：

1. 缺陷的标题

   1. 尽量按缺陷发生的原因与结果的方式书写：例如，执行完a后，发生b
   2. 避免使用模糊不清的词语：例如“功能中断”，应使用具体文字说明功能如何中断，如何不正确，或如何不起作用
   3. 为了方便搜索和查询，请使用关键字
   4. 为了便于他人理解，避免使用术语，俚语等
2. 缺陷的基本信息
3. 测试的软件和硬件环境
4. 测试的软件版本
5. 缺陷的类型
6. 缺陷的严重程度
7. 缺陷处理优先级
8. 复现缺陷的操作步骤
9. 缺陷的实际结果描述
10. 期望正确结果描述
11. 注释文字和截取的缺陷图像

复现步骤：

• 包含如何使别人能够很容易地复现该缺陷的完整步骤。
• 为了达到这个要求，复现步骤的信息必须完整，准确，简明，可复现

• 要求

  1. 提供测试的预备步骤和信息
  2. 简单地一步一步地引导复现该缺陷
  3. 每一个步骤尽量只记录一个操作
  4. 每一个步骤前使用数字对步骤编号
  5. 尽量使用短语和短句，避免复杂句型和句式
  6. 复现的操作步骤要完整，准确，简短
  7. 没有缺漏任何操作步骤
  8. 每个步骤都是准确无误的
  9. 没有任何多余的步骤
  10. 将常见的步骤合并为较少的步骤
  11. 只记录各个操作步骤是什么，不需要包括每个步骤的执行结果

缺陷报告注意事项：

1. 缺陷报告是否已经向读者说明清楚完整、准确、必要的信息
2. 一个缺陷报告是否只说明了一种缺陷
3. 读者是否能够容易地搜索该缺陷
4. 步骤是否可以完全复现而且表达清楚
5. 是否包含了复现该缺陷需要的环境变量或测试所用的数据文件
6. 缺陷的标题是否按照原因和结果的方式书写
7. 实际结果和期望结果是否容易引起歧义

书写原则：

1. 组织
2. 重现
3. 隔离
4. 归纳
5. 对比
6. 总结
7. 精简
8. 消除歧义
9. 中立
10. 检查

缺陷跟踪

缺陷跟踪管理系统

• JIRA
• BUGZILLA
• QC
• 禅道

易用性测试

定义：指的是，用户使用软件时，是否感到方便

内容包括针对应用程序的测试，同时包括对用户手册系统文档的测试。通常采用质量外部模型来评价易用性

• 易理解性
• 易学习性
• 易操作性
• 吸引性
• 依从性

测试点：

1. 控件类

1. 菜单测试

1. 快捷键设置

兼容性测试

定义：简称CTS，指对所设计程序与硬件、软件之间的兼容性的测试

被测试软件在不同的硬件平台，不同的软件--浏览器，不同操作系统平台，不同的网络环境中是否足够友好运行的测试

分类：

• web 兼容性测试

  • 浏览器兼容
  • 屏幕尺寸、分辨率等
  • 操作系统

• APP 兼容性测试

  • 设备型号兼容测试

作用：

1. 能够进一步提高产品的质量，提高用户体验
2. 能使软件与尽可能多的其他软件“和平共处”， 尽可能达到与平台无关性
3. 能尽可能地保证软件存在的价值，它是衡量一个软件质量的重要指标
4. 能使软件产品的市场更广阔

Web兼容性的测试方向：

• 浏览器兼容性

  • 人工测试

  • 第三方测试工具

    • IETESTER：用的人越来越少
    • BrowserShots：在线测试；局限性：只可以通过输入网址的方式查看，对于未上线的项目，测试中的网站比较难以使用
    • SuperPreview：目前未完善

  • 内核分析，测试选型

    • Chrome：Webkit内核 & Blink内核
    • Firefox：最新版本
    • IE：7-11
    • Safari：Mac 版本单独测试
    • Edge：window10
    • 360安全浏览器（双核版）
    • 搜狗等其他浏览器任选其一
    • 如有需要 Linux 系统下 Firefox、ChromeOS 下 Chrome
• 操作系统的兼容性

APP兼容性测试：

• 硬件设备兼容性
• 操作系统版本兼容性

测试方法：

• 人工测试
• 第三方测试工具：以云平台为主