测试入门秘籍<<独孤九剑>>之破枪式-测试执行管理
测试入门秘籍<<独孤九剑>>之破枪式-测试执行管理
破解诸般长枪，大戟、蛇矛、齐眉棍、狼牙棒、白蜡杆、禅杖、方便铲 种种长兵刃之法。
测试执行过程
过程示意图
graph LR
A[项目提测] --> B(冒烟测试)
B --> C{是否通过}
C -->|通过| D[系统测试]
C -->|未通过| A
D-->F[用例执行]
F-->G{是否通过}
G-->|通过|H(测试通过)
G-->|失败|M(提出缺陷)
M-->K(研发修改)
K-->F
测试执行阶段的主要任务
- 确定测试用例的优先级
- 开发测试规程并确定优先级，创建测试数据，同时也可以准备测试 用具和设计自动化测试脚本
- 确认已经正确搭建了测试环境
- 根据计划的执行顺序，通过手工或使用测试工具来执行测试规程
- 记录测试执行的结果，以及呗测软件、测试工具和测试件的标识和版本
- 将实际结果和预期结果进行比较
- 对实际结果和预期结果之间的差异，作为事件上报，并且进行分析以确定引起差异的原因
- 缺陷修正后，重现进行测试活动
测试准入准出
测试准入标准
- 开发编码结束，并在开发环境已完成单元测试
- 需求上规定的功能均已实线；如果没有完全实现，请提供测试范围
- 已完成集成测试，被测系统的基本流程可以走通，界面上的功能均以实线，经过代码评审并符合软件编码规范
- 开发提交最新版本代码，以此为基线，提交并通知测试组进行测试
- 兼容性测试要求明确
- 安全测试和性能测试范围和要求
- 开发要自测
- 通过冒烟测试
- 所有提测内容，测试范围都已明确
测试暂停、停止
- 测试人员先进行冒烟测试，若发现重大缺陷或bug过多时、或者流程卡壳导致基本流程无法走通， 测试无法正常进行，可以暂停测试并返回开发
- 被测项目需要调整而暂停的，测试也相应暂停
- 存在其他优先级更高的任务时，可以向领导申请暂停测试
- 被测系统经过系统测试，达到系统准出标准，可以停止测试
测试准出标准
| 序号 | 准出标准 | 是 | 否 | 日期 |
|---|---|---|---|---|
| 1 | 被测项目满足需求原型的要求？ | |||
| 2 | 所有测试用例都已通过评审？ | |||
| 3 | 所有测试用例都已成功执行？ | |||
| 4 | 所有发现的缺陷都记录在缺陷管理系统？ | |||
| 5 | 一二级错误修复率达到100% ？ | |||
| 6 | 三四级错误修复率达到了95% ？ | |||
| 7 | 所有遗留问题都已有解决方案？ | |||
| 8 | 性能指标是否达到要求？ | |||
| 9 | 兼容性测试（IE8，Changerome,火狐）是否满足？ | |||
| 10 | 性能指标是否达到要求？ | |||
| 11 | 安全性能测试是否达到要求？ | |||
| 12 | 产出系统测试报告总结？ |
软件缺陷概述
软件缺陷
- 缺陷是一种泛称，它可以指功能的错误，也可以指性能低下，易用性差等
- 并不是所有测试人员都能提交被开发认可的缺陷，也不是测试人员在任何时候都能提交被开发认可的缺陷
什么是软件缺陷
- 软件未达到产品说明书表明的功能
- 软件出现了产品说明书指明不会出现的错误
- 软件功能超出产品说明书指明范围
- 软件未达到产品说明书虽未指出但应达到的目标
- 软件测试人员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好
缺陷产生的原因
- 工期短，任务大
- 程序设计错误
- 文档不完善
- 沟通交流不够
- 软硬件支持不完善
- 软件的复杂性
- 需求不断变化
发现缺陷
- 用户体验不够好
- 界面上有明显的错误信息
- 功能不完备，没有按照需求说明编写代码，致使某些功能缺失
- 功能不完善，不能正常运行或者运行的过程中出现程序崩溃、停止运行的情况
- 逻辑不正确，与需求说明书、测试用例不符
- 模块之间的交互性不好，与其他的模块做集成测试时遇到问题
- 程序的性能不够好，不能承载压力考验
缺陷报告
Bug重现
- 不要想当然地接受任何假设，要做好记录
- 查找时间依赖和竞争条件的问题
- 边界条件软件缺陷、内存泄漏和数据溢出等白盒问题可能会慢慢自己显露出来
- 状态缺陷仅在特定软件状态中显露出来
- 考虑资源依赖性和内存、网络、硬件共享的相互作用
无法重现的BUG
- 首先，应当对这样的缺陷进行详细的记录，并尽快提交给开发人员
- 其次，对于寻找难以再现的缺陷要合理安排时间，要考虑到测试项目的整体进度，对一时难以再现的缺陷可以暂时搁置，以保证项目的正常进度
- 最后在测试过程中对未再现缺陷予以关注
缺陷报告
- 缺陷报告是对缺陷进行记录、分类和跟踪的文档
- 软件测试人员的任务之一就是书写良好的软件缺陷报告
- 提供准确、完整、简洁、一致的缺陷报告是体现软件测试的专业性、高质量的主要评价指标
- 通常，缺陷报告的直接读者是软件开发人员和质量管理人员，除此之外，来自市场和技术支持等部门的人也可能需要查看缺陷情况
缺陷报告包含的信息
- 易于搜索软件测试报告的缺陷
- 报告的软件缺陷进行了必要的隔离，报告的缺陷信息具体，准确。
- 软件开发人员希望获得缺陷的本质特征和复现步骤
- 市场和技术支持等部门希望获得缺陷类型分布以及对市场和用户的影响程度
缺陷报告的写作准则（5C）
- Correct（准确）：每个组成部分的描述准确，不会引起误解
- Clear（清晰）：每个组成部分的描述清晰，易于理解
- Concise（简洁）：只包含必不可少的信息，不包括任何多余的内容
- Complete(完整)：包含复现该缺陷的完整步骤和其他本质信息
- Consistent(一致)：按照一致的格式书写全部缺陷报告
缺陷报告的组织架构
- 缺陷的标题
- 缺陷的基本信息
- 测试的软件和硬件环境
- 测试软件的版本
- 缺陷的类型
- 缺陷的严重程度
- 缺陷处理的优先级
- 复现缺陷的操作步骤
- 缺陷的实际结果描述
- 期望的正确结果描述
- 注释蚊子和截取的缺陷图像
缺陷标题
- 尽量按缺陷发生的原因和结果的方式书写（“执行完A后，发生B”或“发生B，当A执行完后”）
- 避免使用模糊不清的词语，例如“功能中断”，“功能不正确”，“行为不起作用”等，应该使用具体文字说明功能如何中断，如何不正确，或如何不起作用
- 为了方便搜索和查询，请使用关键字
- 为了便于他人理解，避免使用术语、俚语或过分具体的测试细节
缺陷标题案例
| 原始描述 | 错误原因 | 改进的标题 |
|---|---|---|
| 英文单词的连字符不管用 | 描述太笼统，什么时候不起作用？ | 在行末尾换行时，不能根据英文单词长度设值连字符。 |
| 段落调整出现错误状态 | 描述太笼统，不正确的行为是什么？ | 选定两个单词，启动单词“字间距”自动调整后间隔排版错误 |
| 警告：该命令产生了错误的结果 | 没有包含原因与结果信息。描述内容太长。 | 更新头像图像保存到服务器时，警告：“错误” |
| 在鼠标点集执行每一个拷贝或复制的编辑功能之后，响应时间很长。 | 没有指明原因与结果，包含了过分详细的细节信息。 | 拷贝和复制工能执行效率低下 |
| 插入的引号成为特殊符号 | 信息没有充分隔离。所有的引号都如此吗？什么类型的引号？ | 在文档中插入一个智能引号成为不可识别的字符串 |
复现步骤
- 复现步骤包含如何使别人能够很容易的复现该缺陷的完整步骤。为了达到这个要求，复现步骤的信息必须是完整的、准确的、简明的、可复现的
- 但是实际软件测试过程中，总是存在一些不良的缺陷报告，主要的问题在于多余步骤、可读性差、难以理解、缺失步骤等
- 提供测试的预备步骤和信息
- 简单地一步一步引导复现该缺陷
- 每一个步骤尽量只记录一个操作
- 每一个步骤前使用数字对步骤编号
- 尽量使用短语和短句，避免复杂句型和句式
- 复现的操作步骤要完整，准确，简短
- 没有缺漏任何操作步骤
- 每个步骤都是准确无误的
- 没有任何多余的步骤
- 将常见步骤合并为较少步骤
- 只记录各个操作步骤是什么，不需要包括每个步骤的执行结果
缺陷报告注意事项
- 缺陷报告已经向读者包含完整、准确、必要的信息了吗？
- 一个缺陷报告中是否只报告了一种缺陷？
- 读者是否能容易的搜索该缺陷？
- 步骤是否可以完全复现而且表达清楚吗？
- 是否包好了复现该缺陷需要的环境变量或测试所用的测试文件？
- 缺陷的标题是按照原因与结果的方式书写吗？
- 实际结果和期望结果是否描述不够清楚而容易引起歧义吗？
缺陷报告的原则
- 组织Structure:测试人员应该采用深思熟虑的，小心谨慎的方法执行测试，并且做详尽的记录。这样可以促使他们对待测试系统有很好的认识。党错误发生的时候，一个有组织的测试人员能够知道最早出现问题的地方
- 重现Reproduce:测试人员在编写缺陷报告之前必须在检查问题是否可重现，如果错误不可再重现，仍然应该写下来，但是必须说明问题的偶然性。一个好的处理原则就是再编写缺陷报告之前反复尝试3次
- 隔离lsolate:在尝试编写缺陷报告之前，必须试着隔离错误。可以采用改变一些变量的方法，如系统配置，它可能可以改变错误的症状。这些信息可以为开发人员着手调试提供思路
- 归纳Generalize:发现一个已隔离的，可重现的问题后，应该对问题进行归纳。同一个问题是否出现在其他的模块或其他的地方？同一个故障是否有更加严重的问题？
- 对比Compare:如果cesium人员以前曾经验证过现在出错的测试用例，那么他就应该检查以前的测试结果以检查相同的条件以前的测试是否通过，如果是的化，那么这个问题就像是一个回归的错误。注意由于统一测试条件有可能出现在多个测试用例中，这个步骤不仅仅检查一个测试用例在以前的多个结果
- 总结Summarize:在缺陷报告的第一行写上错误的总结是非常关键的，测试人员要花些时间思考已发现的错误对客户有何影响。着不仅仅要求测试人员编写的报告要能吸引读者，使和管理层的沟通清晰，还要能够帮助设置错误修复的优先级别
- 精简Condense:在缺陷报告的初稿完成后，测试人员应该反复阅读他，集中剔除哪些没有关系的步骤或词语。隐含的或模糊的说明和那些由于对没有任何关系的细节或者那些在重现错误过程中不需要的步骤而消磨报告欢迎程度的无穷唠叨都不是缺陷报告的目标
- 消除歧义Disambiguate:测试人员在精简空话的同时或其之后随即应该再仔细检查报告是否有会产生误解的地方。测试人员应该尽量避免使用模糊的，会产生歧义的和主管的词语。目标是使用能够表述事实，清楚的，不会产生争执的词语。
- 中立Neutralize:作为坏消息传递人，和善地提交消息是一个挑战。如同所有的错误总结一样，独立的缺陷报告再措辞方面应该保持公正。公鸡开发人员，指责潜在的错误，企图诙谐或使用挖苦将引起开发人员的憎恶，并且使注意力从“提高产品质量”这个大的目标上转移开了。
- 检查Review:一旦测试人员感觉缺陷报告是他能够编写的最好版本，他应该将报告再给一个或多个同行进行检查。在允许的时间离，测试小组应该尽可能提交最好的缺陷报告。
缺陷跟踪
graph LR
A[提交缺陷] -->B(指派缺陷)
B --> C{确认缺陷}
C -->|是|D{推迟处理}
C -->|否| E{回归缺陷}
E -->|未通过| G[重新打开]
E-->|通过|F[关闭缺陷]
D-->|是|H[缺陷遗留]
D-->| 否|L[处理缺陷]
L-->E
H-->|后续版本处理|L
G-->C
缺陷跟踪管理系统
- 早期的缺陷跟踪大都是以缺陷记录单的形式完成，现在还有很多项目还用此方法，但是随着用户对软件功能需求的不断增加，软件算法和复杂度都发生了很多变化，随之而来的是软件缺陷的增长，这给缺陷跟踪带来很大的挑战
- 于是，缺陷管理系统应运而生
- 在软件行业发展历程中，曾经或者正在被大量使用的缺陷管理系统包括JIRA、BUGZILLA、QC、 禅道等。
- 而目前，除了部分大型IT公司拥有自研的缺陷跟踪管理系统外， 很多公司应用禅道来进行缺陷跟踪甚至是项目管理。
禅道项目管理以及实战
- 禅道是一款基于Scrum思想并集产品管理、项目管理、测试管理于一体，同时还包含了事务管理、组织管理等诸多功能的项目管理软件
用户角色
- 系统管理员（Admin）:系统管理员主要负责添加用户，分配权限
- 产品人员（product owner）:产品人员主要负责产品管理
- 项目经理（Project Manager）: 通过项目，协调产品人员，开发人员，测试人员完成产品
- 开发人员（developer）:开发人员负责产品的研发
- 测试人员（QA）：测试人员保证产品的质量
最简使用
- 只使用禅道来进行产品管理
- 使用禅道来进行项目任务管理
- 只使用禅道来做BUG管理
- 个人使用禅道来做事务跟踪管理
项目模式的基本流程
- 产品经理创建产品
- 产品经理创建需求
- 项目经理创建项目
- 项目经理确定项目要做的需求
- 项目经理分解任务，指派到人
- 测试人员测试，提交BUG
易用性测试
- 易用性测试是指用户使用软件时是否感觉方便，比如是否最多点击鼠标三次就可以达到用户的目的
- 易用性和可用性存在一定的区别，可用性是指是否可以用使用，而易用性是指是否方便使用
- 易用性测试包括针对应用程序的测试，同时还包括对用户手册系统文档的测试。通常采用质量外部模型来评价易用性
易用性测试内容
- 易理解性
- 易学习性
- 易操作性
- 吸引性
- 依从性
易用性测试方法-导航测试
- 通过考虑下列问题，可以决定一个应用系统是否易于导航：导航是否直观？系统的主要部分是否可通过主页存取？系统是否需要站点地图、搜索引擎或其他的导航帮助？
易用性测试方法-图形测试
- 在系统中，适当的图片和动画既能起到广告宣传作用，又能起到美化页面的功能。
- 一个应用系统的图形可以包括图片、动画、边框、颜色、字体、背景、按钮等。
- 要确保图形有明确的用途、图片或动画不要胡乱地堆在一起，以免浪费传输时间
- 应用系统的图片尺寸要尽量地小，并且要能清楚地说明某件事情，一般都链接到某个具体页面
- 验证所有页面字体的风格是否一致
- 背景颜色应该与字体颜色和前景颜色相搭配
- 图片的大小和质量也是一个很重要的因素，一般采用jpg或gif压缩、
易用性测试方法-内容测试
内容测试用来检验应用系统提供信息的正确性、准确性和相关性
易用性测试方法-整体界面测试
- 整体界面是指整个应用系统的页面结构设计，是给用户的一个整体感。
- 例如：党用户浏览应用系统时是否感到舒适，是否凭直觉就知道要找的信息在什么地方？整个应用系统的设计风格是否一致？
测试点总结
- 控件类
| 编号 | 测试内容 | 是否通过 |
|---|---|---|
| 1 | 按钮名称易懂，与同一界面上的其他按钮易于区分 | |
| 2 | 常用按钮支持快捷方式 | |
| 3 | 相同或相近的功能的按钮用Frame框起来，并有功能说明标题 | |
| 4 | 完成同一功能或任务的元素集中放置 | |
| 5 | 应首先输入数据和重要信息的控件在Tab顺序中靠前，并放在窗口上较醒目的位置 | |
| 6 | 选项卡控件（Tab）支持在页面间的快捷切换，常用快捷键Ctrl+Tab | |
| 7 | 默认按钮要支持“回车”即选操作 | |
| 8 | 选择常用功能或数值作为默认值 | |
| 9 | 复选框、单选框、列表框、下拉列表框的内容或条目多的时候按选择概率的高低或字母顺序排序 | |
| 10 | 复选框或单选框有默认选项 | |
| 11 | 节目空间较小时使用下拉列表而不用单选框 | |
| 12 | 选项条目较少时使用单选框，相反使用下拉框列表 | |
| 13 | 专业性强的软件要使用相关的专业术语，通用性界面则提倡使用通用性术语 | |
| 14 | 不同界面的通用按钮位置保持一致 | |
| 15 | 常用按钮的等价按键保持一致 | |
| 16 | 对可能给用户带来损失的操作最好支持可逆性处理 | |
| 17 | 对可能造成等待时间较长的操作应该提供取消功能，并显示操作状态 | |
| 18 | 根据需要，程序自动过滤输入的空格 |
- 菜单测试
| 编号 | 测试内容 | 是否通过 |
|---|---|---|
| 1 | 常用菜单项要有快捷键 | |
| 2 | 菜单项前的图标能直观的代表要完成的操作 | |
| 3 | 一组菜单的使用有先后要求或有向导作用时，按先后次序排列 | |
| 4 | 没有顺序要求的菜单按使用频率和重要性排列，常用的和重要的放前面 | |
| 5 | 主菜单的宽度要接近，字数不多于四个，每个菜单项的字数最好能相同 | |
| 6 | 工具栏可以根据用户的需求进行定制 | |
| 7 | 相同或相近功能的工具栏放在一起 | |
| 8 | 工具栏的图标能直观的代表要完成的操作 | |
| 9 | 状态条能显示用户切实需要的信息。如果某一操作需要的时间较长，还应该显示进度条和进程提示 | |
| 10 | 滚动条的长度根据显示信息的长度或宽度及时变换 | |
| 11 | 菜单和工具栏有清楚的界限 | |
| 12 | 菜单和状态条通常使用5号字体 |
- 快捷键测试
| 编号 | 测试内容 | 是否通过 |
|---|---|---|
| 1 | 编辑：Ctrl+A;Ctrl+C拷贝；Ctrl+V粘贴等 | |
| 2 | 文件操作：Ctrl+P 大于；Ctrl+W关闭等 | |
| 3 | 主菜单：Alt+F文件；Alt+E编辑 等 | |
| 4 | Windows 保留键；Ctrl+Esc任务列表等 | |
| 5 | 其他组合：Alt+N否；Alt+D删除等 |
兼容性测试
- 兼容性测试简称CTS，指对所设计程序与硬件、软件之间的兼容性测试
- 一般来说，兼容性指能同时容纳多个方面，在计算机术语上兼容时指几个硬件之间，几个软件之间或是软硬件之间的相互配合程序
- 对于我们测试来说，通俗一点的理解可以认为时被测软件在不同的硬件平台（PC||Mobile）,不同的软件（浏览器），不同的操作系统平台、不同的网络环境中是否能够很友好运行的测试
兼容性测试-分类
兼容性测试
- Web兼容测试
- 浏览器兼容
- 屏幕尺寸、分辨率
- 操作系统
- App兼容性测试
- 设备型号兼容测试
兼容性测试-作用
- 兼容性测试时软件测试过程必不可少的一个过程，没有兼容测试的测试是不完整的测试，兼容性测试的存在是有一定作用的
- 兼容性测试能够进一步提高产品的质量，提高用户体验
- 兼容性测试能使软件与尽可能多的其他软件“和平共处”，尽可能达到平台无关性
- 兼容性测试能尽可能的保证软件存在的价值，他是衡量一个软件质量的重要指标
- 兼容性测试能使软件产品的市场更广阔
web兼容性测试
- 浏览器兼容性
- 操作系统兼容性
测试方法
- 人工测试：测试工程师测试主流浏览器和常用操作系统测试主流程和主界面，看看主流程和主界面是否有问题
- 第三方测试工具：部分情况下，部分浏览器可以依赖第三方工具辅助测试
内核分析
- 浏览器
- IE
- Chrome
- FireFox
- 其他
测试选型
- Chrome:webkit内核1&Blink内核1
- FireFox:最新版本
- IE：7-11
- Safari:mac版本单独测试
- Edge:window10
- 360安全浏览器（双核版）
- 搜狗等其他浏览器任选其一
- 如有需要Linux系统下FireFox、ChromeOS下chrome
第三方工具--IETESTER
- 可以进行IE5.5-IE11的兼容性测试，能够满足一定程度的测试需求
- 但随着IETESTER后期维护乏力，对浏览器的支持不足
- 同时母亲对于IE兼容性来说，更多支持 IE7+,我们可以使用IE浏览器自带的调试工具来测试，故IETESTER逐步从重要变为鸡肋
三方工具--BrowserShots
- www.browsershots.org 通过在线解图的方式展现页面的兼容性
- 限制在于只可以通过输入网址的方式查看，对于还未上线，测试中的网站比较难于使用
三方工具--Super Preview
- SuperPreview是微软退出的Expression Web3一部分，同时，微软也提供了SuperPreview的独立安装包
- 他的目标是集成IETESTER和BrowserShots的功能，但是母亲还没有完善
APP兼容性测试测试方向
- 硬件设备兼容性
- 操作系统版本兼容性
测试方法
- 人工测试：测试工程师测试主流手机设备对主流程和主共鞥你进行验证测试
- 第三方测试工具：三方主要以云平台为主
设备选型TOP20
- 使用TOP20的机型，指定系统版本
- 安卓机一律要求使用真机或者相应的云服务测试，IOS允许使用模拟器
- 如果上述的设备无法获取到，允许选取同类型机型作为替代，但最多不超过4个替代机型
