测试执行过程（六）

测试执行过程

测试执行阶段的主要任务

• 确定测试用例的优先级
• 创建测试数据，准备测试工具和设计自动化测试脚本
• 根据测试计划创建测试套件（场景）
• 确定已经正确搭建测试环境
• 根据优先级，手工或使用测试工具来执行测试
• 记录测试执行的结果，以及被测软件、测试工具和测试件的标识与版本
• 测试完成，将实际结果与预期结果对比，若出现差异，分析引起差异的原因，确定是否作为缺陷上报
• 修正缺陷后，重新测试

测试的准入与准出

• 准入标准：
  （1）开发编码结束，并在开发环境已完成单元测试
  （2）阶段性需求规定的功能均已实现，若未完全实现，需提供测试范围
  （3）已完成集成测试（联调），系统基本流程可以走通，界面上功能均实现，通过代码评审，符合软件编码规范
  （4）开发组提交最新版本代码，并通知测试组进行测试
  （5）兼容性测试要求明确
  （6）安全测试和性能测试范围和要求（是否需要，不需要则给出原因）

测试暂停、停止

• 先进行冒烟测试，若基本流程无法走通或bug过多，无法进行正常测试时，可以暂停测试并返回开发。
• 被测项目需调整而暂停，测试也会暂停。
• 存在优先级更高的任务，可以申请暂停测试。
• 系统测试后，达到系统准出标准，可以停止测试。

测试准出标准

软件缺陷：（功能、性能、易用性、兼容性）

• 软件未达到产品说明书标明的功能
• 软件出现了在产品说明书指明不会出现的错误
• 软件功能超出产品说明书指明范围
• 软件未达到产品说明书没有指明但应达到的目标
• 从测试或最终用户的角度认为，易用性不高

产生缺陷的原因

• 需求不断变化
• 文档不完善
• 工期短，任务大
• 程序设计错误
• 软件的复杂度
• 软硬件支持不完善
• 沟通交流不够

发现缺陷

• 用户体验不好
• 界面有明显的错误信息
• 功能不完备，未按照需求说明编写代码
• 功能不完善，不能正常运行、程序崩溃、停止运行
• 逻辑不正确，与需求说明书、测试用例不符
• 模块之间的交互不好，与其他模块做集成测试时遇到倒问题

bug重现

• 做好记录，不接受任何假设
• 查找时间依赖和前置条件的问题
• 边界值缺陷、内存泄露和数据溢出等白盒问题会随着时间慢慢显露出来
• 状态缺陷仅在特定软件状态中显露出来
• 考虑资源依赖性和内存、网络、硬件共享的相互作用

无法重现的bug

• 进行详细记录，并尽早提交给开发人员
• 一时难以再现，暂时搁置，保证项目正常进度，但作为缺陷上报以作后续观察

缺陷报告：对缺陷进行记录、分类和跟踪的文档。

• 易于搜索软件测试报名的缺陷
• 缺陷信息具体、准确，需要必要的隔离
• 缺陷的本质特征和复现步骤（开发人员）
• 缺陷类型分布以及对市场和用户的影响程度（市场和技术支持部门）

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

• 准确-Correct：避免误会
• 清晰-Clear：易于理解
• 简洁-Concise：只包含必要信息
• 完整-Complete：复现完整步骤和本质信息
• 一致-Consistent：按照一致的书写格式，写全部缺陷报告

缺陷报告的组织架构

• 缺陷的标题（易搜索）
  尽量按因果方式书写：a→b，执行a后，发生b。
  避免模糊不清的描述，使用关键字：在…时，出现…
• 缺陷的基本信息（浏览器版本等）
• 测试的软硬件环境
• 测试的软件版本
• 缺陷的类型
• 缺陷的严重程度
• 缺陷的处理优先级
• 复现缺陷的操作步骤
  （1）提供测试的预备步骤和信息
  （2）简单一步步引导复现缺陷
  （3）每个步骤尽量只记录一个操作
  （4）每个步骤需要一个序号
  （5）尽量使用短语短句
  （6）要求完整、准确、简洁，没有遗漏任何步骤
  （7）将常见步骤合并
  （8）无需记录每个步骤执行结果
• 缺陷的实际结果描述
• 期望的正确结果描述
• 注释文件和截取的缺陷图像、视频

缺陷报告的十大原则：组织、重现、隔离、归纳、对比、总结、精简、消除歧义、中立、检查

缺陷跟踪
测试人员提交缺陷，然后指派缺陷（开发人员或自己）。如果是开发人员，开发人员确认缺陷存在，若否认存在，则再进行回归测试，测试缺陷不存在则封闭，存在则重新指派；若承认存在，测试人员判断是否需要推迟处理，否则需要开发人员处理缺陷，再回归测试；是则遗留缺陷，后续处理。

缺陷跟踪管理系统：JIRA、BUGZILLA、QC、禅道

禅道：基于Scrum（敏捷）思想，集产品管理、项目管理、测试管理于一体，包含事务管理、组织管理等功能的项目管理软件。

• 安装Windows一键安装包（开源版）
  https://www.zentao.net/download/80185.html
  

• 安装手册：https://www.zentao.net/book/zentaopmshelp/40.html

用户角色：系统管理员、项目经理、产品人员、开发人员、测试人员

项目基本流程

• 产品经理创建产品
• 产品经理创建需求
• 项目经理创建项目
• 项目经理确定需求
• 项目经理分解任务，指派人员
• 测试人员测试，提交bug

易用性测试

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

易用性测试方法

• 导航测试：功能模块直观好找
• 图形测试：图片用途明确，一般有链接。图片大小或质量，一般采用jpg和gif压缩。字体、前背景颜色是否合适。
• 内容测试：信息的正确性、准确性、相关性。
• 整体界面测试：页面结构设计的整体感，关于设计风格、重点信息位置等。

易用性测试点参考

• 控件测试
  
  

• 菜单测试
  

• 快捷键设置
  

兼容性测试（CTS）：是对程序与软硬件之间的兼容性的测试。

• 硬件平台：PC、Mobile
• 浏览器
• 操作系统平台
• 网络环境（弱网是否能展现报错信息）

兼容性测试分类

• web兼容性测试：浏览器兼容、屏幕尺寸和分辨率、操作系统
• app兼容性测试：设备型号

兼容性测试优点

• 提高产品质量和用户体验
• 尽可能达到平台无关性
• 保证软件存在价值，衡量软件质量的重要指标
• 使产品市场（潜在客户）更加广阔

web兼容性测试：IE、Chrome、FireFox、Safari、Opera等

• 内核分析：Trident、Gecko、Webkit、Blink
  （1）IE：Trident（兼容模式） → （win10）Edge：EdgeHTML（windows默认浏览器）
  （2）Safari：Webkit（macOS默认浏览器）
  （3）FireFox：Gecko
  （4）Chrome：Webkit（chromium） → Blink
  （5）Opera：Presto → Webkit → Blink

• 测试选型
  （1）IE：7-11
  （2）FireFox：最新版本
  （3）Chrome：Webkit内核1 & Blink内核1
  （4）Safari：mac版本单独测试
  （5）Edge：window10
  （6）360安全浏览器（双核版），搜狗等其他浏览器选其一
  （7）Linux系统下FireFox、ChromeOS下Chrome（如有需要）

web兼容性测试方法

• 人工测试
• 第三方测试工具
  IETESTER：进行IE5.5 - IE11的兼容性测试，但IE7+浏览器可以使用自带的调试工具，逐步变得鸡肋。
  BrowserShots：http://browsershots.org/
  通过在线截图，展示页面的兼容性。限制在于只可以通过网址查看，对未上线的网站难以使用。
  SuperPreview：集成以上两个工具的功能，目前尚未完善。

app兼容性测试：硬件设备兼容性、操作系统版本兼容性

• 设备选型（Top20）
  
  
• 补充说明
  Android使用真机或云服务测试，IOS使用模拟器。若获取不到，可选取同类机型代替，但不能超过4个代替。

app兼容性测试方法

• 人工测试
• 第三方测试工具（云平台）