执行测试用例

测试执行

测试执行过程

项目提测 -> 冒烟测试（准入型测试，看是否符合项目测试的开始条件） -> 系统测试 -> 用例执行 -> 测试通过

测试执行阶段的主要任务

• 确定测试用例的优先级（一般在测试设计阶段完成，但是在测试执行阶段进一步明确）
• 开发测试规程并确定优先级，创建测试数据，同时也可以准备测试用具和设计自动化测试脚本
• 根据测试规程创建测试套件（相当于布置测试用例），以提高测试执行的效率
• 确认已经正确搭建了测试环境
• 根据计划的执行顺序，通过手工或使用测试工具来执行测试规程
• 记录测试执行的结果，以及被测软件、测试工具和测时间的标识和当前版本
• 将实际结果和预期结果进行比较
• 对实际结果和预期结果之间的查以，作为事件上报，并且进行分析以确定引起差异的原因
• 缺陷修正后，重新进行测试活动

测试准入准出标准

测试准入标准

什么时候能开始对项目进行测试

• 开发编码结束，并在开发环境已完成单元测试
• 需求上规定的功能均已实现；如没有完全实现，请提供测试范围，最好有书面的文档
• 已完成集成测试（开发之间的联调），测试员通过冒烟测试（被测系统的基本流程可以走通，界面上的功能均已实现），经过代码评审并符合软件编码规范（不同的公司可能会有不同的规范）
• 开发提交最新版本代码，以此为基线，提交并通知测试组进行测试
• 兼容性测试要求明确（要明确什么ios还是安卓系统能使用）
• 安全测试和性能测试范围和要求（确定要不要做安全测试和性能测试要不要做，如果要做要明确测试和方位）

总结：开发要自测（集成测试），通过冒烟测试，所有提测的内容、要求、范围非常明确。

测试暂停、停止

什么情况下会暂停、停止？

• 测试人员先进行冒烟测试，若发现重大缺陷或bug过多时、或者流程卡壳导致基本流程无法走通（认为当前版本不能进行测试，即不通过冒烟测试），测试无法正常进行，可以暂停测试并返回开发。
• 被测项目需调整而暂停的，测试也相应暂停（根据项目周期决定）
• 存在其他优先级更高的任务时，可以向领导申请暂停测试
• 被测系统经过系统测试，达到系统准出标准，可以停止测试（那么此时已经完成测试执行过程，就差系统测试总结和系统上线）

测试准出标准

缺陷管理

3-1 软件缺陷（bug）

• 缺陷是一种泛称，它可以指功能的错误，也可以指性能低下，易用性差等
• 并不是所有测试人员都能提交被开发认可的缺陷，也不是测试员在任何时候都能提交被开发认可的缺陷

缺陷的定义：

1. 软件未达到产品说明书表明的功能（需求上的遗漏）
2. 软件出现了产品说明书指明不会出现的错误
3. 软件功能超出产品说明书指明范围
4. 软件未达到产品说明书虽指出但应达到的目标
5. 软件测试员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好（由用户或产品方做的验收测试不通过）

测试人员最好能指出缺陷出现的原因

发现缺陷

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

3-2 缺陷报告

BUG重现

1. 不要想当然地接收任何假设，要将错误流程作好记录
2. 查找时间依赖和竞争条件的问题（注意缺陷对时间、环境前置条件（即前面执行了什么操作才会出现这样的问题）的问题）
3. 边界条件软件缺陷、内存泄露和数据溢出等白盒问题可能会随着时间慢慢自己显露出来
4. 状态缺陷仅在特定状态中显露出来，需要说明清楚
5. 考虑资源依赖性（内存、网络、硬件共享的相互作用）

无法重现的BUG，如何处理？

1. 首先，应当对这样的缺陷进行详细的记录，并尽快提交给开发人员
2. 其次，对于寻找难以再现的缺陷要合理地安排时间，要考虑到测试项目的整体进度，对一时难以再现的缺陷可以暂时搁置（如果经常出现bug则立即提交给开发），以保证项目的正常进度
3. 最后在测试过程中对为再现缺陷予以关注

缺陷报告

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

缺陷报告包含信息

• 易于搜索软件测试报告的缺陷（缺陷关键词管理）
• 报告的软件缺陷进行了必要的隔离（即告知开发人员在哪一步发生错误，错误真正的点在哪？），报告的缺陷信息具体、准确。
• 软件开发人员希望获的缺陷的本质特征和复现步骤
• 市场和技术支持等部门希望获得缺陷类型分布以及对市场和用户的影响程度（市场会考虑此时项目是否可以上线，bug影响大不大）

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

• correct（准确）：每个组成部分的描述准确，不会引起误解
• clear（清晰）：每个组成部分清晰，易于理解
• concise（简洁）：只包含必不可少的信息，不包含任何多余的内容（沟通的时候可以说多一点，报告要简洁准确）
• complete（完整）：包含复现该缺陷的完整步骤和其他本质信息
• consistent（一致）：按照一致的格式书写全部缺陷报告，提高阅读效率

缺陷报告的组织架构

1. 缺陷的标题（尽量按缺陷发生的原因与结果的方式书写比如“执行完A后，发生B”或者“发生B，当A执行完后”，使用关键字）
2. 缺陷的基本信息
3. 测试的软件和硬件环境
4. 测试的软件版本
5. 缺陷的类型（操作流程、功能、易用性、页面等）
6. 缺陷的严重程度，即却西安优先级，如果缺陷卡住流程影响业务，则优先级很高，如果没有影响主业务，优先级可以没那么高
7. 缺陷的处理优先级
8. 复现缺陷的操作步骤，越详尽越好
9. 缺陷的实际结果描述
   10.期望的正确结果描述
   11.注释文字和截取的缺陷图像

复现步骤

• 复现步骤应该是完整的、准确的、简明的、可复现的
• 但是在实际软件测试过程中，总是存在一些不良的缺陷报告，主要的问题在于多余步骤、可读性差、难以理解、确实步骤等
• 提供测试的预备步骤和信息
• 简单地一步一步地引导复现该缺陷
• 每一个步骤尽量只记录一个操作
• 每一个步骤前使用数字对步骤编号
• 尽量使用短语和短句
• 复现的操作步骤要完整、准确、简短
• 没有缺漏任何操作步骤
• 每个步骤都是准确无误的
• 只记录各个操作步骤是什么，不需要包括每个步骤的执行结果
• 将常见步骤合并较为步骤（比如登录就直接登录就好了）

缺陷报告注意事项

• 缺陷报告已经向读者包含完整、准确、必要的信息了吗？
• 一个缺陷报告中是否只报告一种缺陷？
• 读者是否能容易的搜索该缺陷？
• 步骤是否可以完全复现而且表达清楚？
• 是否包含了复现该缺陷需要的环境变量或测试所用的测试文件？
• 缺陷的标题是按照原因与结果的方式书写的吗？
• 实际结果和期望结果是否描述不够清楚而容易引起歧义？

3-3 缺陷报告原则

• 组织Structure：测试人员应该采用深思熟虑的，小心谨慎的方法执行测试，并且做详尽的记录。这样可以促使他们对待测系统有很好的认识。当错误发生的时候，一个有组织的测试人员能够指导最早出现问题的地方
• 重现Reproduce；
• 隔离Isolate：在尝试编写缺陷报告之前，必须试着隔离错误。可以采用改变一些变量的方法，如系统的配置引起的，还是数据引起的。他可能可以改变错误的症状。这些信息可以为开发人员着手调试提供思路。
• 归纳Generalize：发现了一个已隔离的，可重现的问题后，应该对问题进行归纳。同一个问题是否出现在其他的模块或其他的地方？同一个故障是否有更加严重的问题？
• 对比Compare：如果测试人员以前曾经验验证过现在出错的测试用例，那么他就应该检查以前的测试结果以检查相同的条件以前的测试是否通过。如果是的话，那么这个问题就像是一个回归的错误。注意由于同一测试条件优可能出现在多个测试用例中，这个步骤就不仅仅只是检查一个测试用例在以前的多个结果。
• 总结Summarize：在缺陷报告的第一行写上错误的总结是非常关键的。测试人员要花些时间思考已发现的错误对客户有何影响。这不仅仅要求测试人员编写的报告要能够吸引读者，使和管理层的沟通清晰，还要能够帮助设置错误修复的优先级别。
• 精简Condense：在缺陷报告的初稿完成后，测试人员因该反复阅读，集中提出那些没有关系的步骤或词语。
• 消除歧义Disambiguate测试人员在精简话语后，要看看有没有表达不清的
• 中立Neutralize：作为坏消息的传递人，和善地提交消息是一个挑战，不要对恶意攻击开发人员，指责潜在的错误。
• 检查Review：一旦测试人员感觉缺陷报告实他能够编写的最好版本，他应该将报告再给一个或多个同行检查，在允许的时间里，测试小组应该尽可能提交最好的缺陷报告。

缺陷跟踪（缺陷的一生）

• 指派：把缺陷分给哪一个人，指定给某一个开发。如果开发否认缺陷，测试再进行回归测试。如果是缺陷，那么看看法是不是推迟处理。
  
  

缺陷跟踪管理系统

在软件行业发展历程中，曾经或者正在被大量使用的缺陷管理系统包括JIRA、BUGZILLA、QC、禅道
禅道更多是一个项目管理系统，缺陷管理只是一部分功能。

禅道项目管理系统

5-1 禅道

一款基于Scrum（敏捷）思想并集产品管理、项目管理、测试管理于一体，同时还包含了事务管理、组织管理等诸多功能的项目管理软件。

用户角色

• 系统管理员
• 产品人员 product owner
• 项目经理：通过项目，协调产品人员，开发人员，测试人员完成产品
• 开发人员 developer
• 测试人员 QA

项目模式基本流程

1. 产品经理创建产品
2. 产品经理创建需求
3. 项目经理创建项目
4. 项目经理确定项目要做的需求
5. 项目经理分解任务，指派到人（指派开发，指派测试）
6. 测试人员测试，提交bug

易用性测试

测试人员代入用户体验的项目

行业不成文的规定
易用性测试是指用户使用软件时是否感觉方便，比如是否最多点击鼠标三次就可以达到用户的目的
(ps：易用性和可用性存在一定的区别，可用性是指是否可以使用，而易用性是指是否方便使用)

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

包括如下方面的测试：

1. 易理解性（文档、app活动的规则等）
2. 易学习性（学习使用app）
3. 易操作性
4. 吸引性
5. 依从性（在系统使用过程中，能不能顺着客户的操作，指引客户完成剩余操作）

易用性测试：导航测试、图片测试、内容测试、整体界面测试

易用性测试的测试点总结：

1. 控件类
2. 菜单测试
3. 快捷键设置

兼容性测试——提高产品质量和用户体验

定义：简称CTS，指对所设计程序与硬件、软件之间的兼容性的测试。
对于测试来说，具体是指被测软件在不同的硬件平台（PC MOBILE），不同浏览器，不同的操作平台、不同的网络环境中是否能够很友好的测试

兼容性测试的作用

1. 没有兼容性测试是不完整的项目测试，提高用户体验
2. 兼容性测试能使软件与尽可能多的其他软件“和平共处”，尽可能达到平台无关性
3. 兼容性测试能尽可能的保证软件存在的加支，他是衡量一个软件质量的重要指标
4. 兼容性测试能使软件产品的市场更广阔

7-2 WEB兼容性测试

主要考虑：浏览器、操作系统

测试方法

• 人工测试
• 第三方测试工具

浏览器测试选型

• Chrome：Webkit内核 & Blink内核
• FireFox：最新版本
• IE：7-11
• Safari：mac版本单独测试
• Edge：window10
• 360（双核版）
• 搜狗等其他浏览器任选其一即可，因为底层都是Webkit 或Blink

第三方工具——IETESTER

• 可以进行IE5.5-IE11的兼容性测试，能够满足一定程度测试需求
• 但随着IETESTER后期维护乏力，对浏览器的支持不足
• 一般可以用IE浏览器自带的调试工具来测试，ieteser用的人越来越少

第三方工具——BrowserShots

• www.browsershots.org 通过在线截图的方式展现页面的兼容性
• 限制在于只可以同构输入网址的方式查看，对于还未上线，测试中的网站比较难于使用

第三方工具 Super Preview

• Super Review是微软推出的独立安装包
• 他的目标是集成IETESTER和BrowserShots的功能，但是目前还没有完善

7-3 APP兼容性测试

考虑的方向：硬件设备兼容性，操作系统版本兼容性

测试方法

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

设备选型

• 使用TOP20的机型，指定系统版本即可
• 安卓机一律要求使用真鸡或者相应的云服务测试，IOS允许使用模拟器
• 如果上述的设备无法获取到的，允许选取同类（IOS/安卓）机型作为替代，但最多不超过4个替代机型