测试执行过程
测试执行阶段的主要任务
- 确定测试用例的优先级
- 创建测试数据,准备测试工具和设计自动化测试脚本
- 根据测试计划创建测试套件(场景)
- 确定已经正确搭建测试环境
- 根据优先级,手工或使用测试工具来执行测试
- 记录测试执行的结果,以及被测软件、测试工具和测试件的标识与版本
- 测试完成,将实际结果与预期结果对比,若出现差异,分析引起差异的原因,确定是否作为缺陷上报
- 修正缺陷后,重新测试
测试的准入与准出
- 准入标准:
(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
用户角色:系统管理员、项目经理、产品人员、开发人员、测试人员
项目基本流程
- 产品经理创建产品
- 产品经理创建需求
- 项目经理创建项目
- 项目经理确定需求
- 项目经理分解任务,指派人员
- 测试人员测试,提交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兼容性测试方法
- 人工测试
- 第三方测试工具(云平台)