学习笔记

3月12 缺陷管理

一、缺陷属性定义：软件开发维护过程中的错误、问题、功能失效或违背

缺陷类型： 基础功能未实现 提交不完整 功能未实现 数据丢失或错误

操作界面：功能可以使用，但界面展示不友好或错误 接口问题：与其他组件、参数相互影响 版本和环境配置

文档问题：设计文档或用户说明书与需求文档不一致 致命错误：崩溃

性能问题：CPU温度过高 缺陷严重等级：

A：致命性的bug，由于应用本身问题，数据被破坏或丢失，应用无法安装 B：严重功能bug，严重影响用户使用，必现的崩溃 C：一般功能bug，偶现的崩溃 D：细小功能问题，界面UI问题 缺陷优先级：类似严重等级

低：暂时不影响继续测试；可以在方便时解决 中：部分功能无法继续测试；需要优先解决 高：测试暂停，无法进行；必须立即解决

缺陷状态（6种）：确保在各个阶段提交的每个缺陷能够尽快的解决，确保缺陷的修复率

新建：测试提交的缺陷

已修复：开发人员已经修复，等待测试验证

重开：缺陷修改未达到目标，重新指派给开发人员处理 关闭：bug终点，已修复并通过测试验证 拒绝：开发者认为缺陷不需要修复或不是缺陷

推迟：当前版本不能修复的缺陷，可追踪到下一个版本的bug

二、缺陷的生命周期

缺陷处理权限：

三、缺陷分析

在一定周期时间或者一定阶段内，缺陷按照一个或者多个维度的动态分布，周

期可以是天、周、月 缺陷趋势分析目的：

3月13 如何更快更好的了解一款应用的兼容性

安装卸载测试 运行稳定性测试 遍历测试 UI适配测试

自动化测试的概念

自动化测试时把以人为驱动的测试行为转化为机器执行的一种过程。 速度、效率、准确度和精确度、节省资源、仿真和模拟、坚持不懈 前提条件：

实施自动化测试之前需要对软件开发过程进行分析，以观察其是否适合使用自动化测试。通常需要同时满足以下条件。 1、 软件需求变动不频繁； 2、 项目周期足够长； 3、 自动化测试脚本可重复使用 自动化测试的过程：

自动化测试与软件开发过程从本质上讲是一样的 -测试需求的分析 -设计出自动化测试的用例

-搭建自动化测试的框架（Robotium） -设计与编写自动化脚本 -完成该套测试脚本

3月19 了解monkey

可以看做是自动化测试手段进行压力性测试 不熟 自动化测试 Bug分析 测试报告 基本了解 熟悉 基本掌握 编写测试用例 执行功能测试 定义bug级别 Bug管理、描述

手游功能测试及功能测试工具实例演练 游戏功能测试步骤： 1、 2、 3、 4、 5、 6、

明确游戏功能设计 画出流程图 编写测试用例 执行测试用例 将缺陷录入数据库 验证缺陷（回归测试）

编写测试计划、用编写需求文档 户手册 测试流程 Bug生命周期 什么是游戏的bug？ 没有实现设计需求 用户体验较差

没有达到第一方厂商的要求 违反当地的法律法规

程序：Crash/死机、hang/挂起、功能、兼容性、性能、网络连接（弱链接、中断）、服务器与数据库 美术：

图像、模型、动画 策划：

AI、UI、HUD（角色血条、弹药数量等）、游戏性、数值、摄像机、文本、剧情（过关情况）、技能/武器 产品：

送审（国外google）、法律问题（品牌商标）、产品意见或建议（颜色看起来不爽） 音效：

声音特效、背景音乐 中断类： 暂停游戏

存盘，返回菜单，然后再读取进度，S/L 杀掉游戏进程，再重启（查看游戏状态）

断网

弱连接（网络情况比较差，2g） 断电（一般都是测手机硬件）

3月27 移动应用测试

1、测试者的多角度

既要针对开发，也要针对产品、部门、用户，从多角度看待同一个问题； 例如： （四个角度） try{

System.out.println(“我不想上班”); }

Catch(Exception e){

System.out.println(“那就没钱花！”); }

开发角度：正常执行就OK

测试角度：两部分都要做全，正常和异常情况 产品设计角度：两部分都要做好设计

用户角度：不关心代码，能够正常使用，根据提示改正操作 2、不同系统对性能的要求 主要是要求速度快

（1）SNS这样的系统（新浪微博），主要是对feed（发微博）要求比较高，需要考虑大并发的情况，例如：一个姚晨发一条微博要通知多少用户啊？！

（2）舆情监控系统，主要关注于load大数据的处理，数据的处理和统计 要先学会先分析系统特点，在针对不同的特点设计性能测试方案，而这点很多人都会忽略。

3、测试中的分层思想（像洋葱，逐层分析，理清思路）

（Web测试）8层：客户端层（PC）、静态服务器层、动态服务器层、中间件层、DB前置层（缓存数据）、DB层（数据库）、代码层、运维部署层（部署架构） 所有的系统都是大同小异的，性能问题的解决都是去拆分 4、性能划分 （1）基于场景的测试 （2）基于接口的测试 （3）页面级性能测试

5、QTP自动化工具（QC测试管理工具、LoadRunner性能工具）【惠普三剑客】

自动化玩到一定程度是自动化测试设计思想的体现，不是你写代码的能力。 两个问题：对象识别不出来、自动化框架怎么做？ 6、移动应用测试 （1）产品

分类：工具类、社交类、娱乐消费类、游戏类；站在产品设计的角度看，每一类相通;

界面只显示主要内容 注意用户体验 （2）结构，3部分

前端app 后台server 网络信号 （3）方法

1) 手工测试，如：秒表记录第一次启动时间 2) 自动化工具 3) 利用第三方

（4）研发（扁平化，适应快速响应） 迭代快 不断试槽

求稳不求新（稳定技术） 创新

安卓：本质是java、Linux（少） 7、忠告

不要忽略业务特点

需要不断积累和总结，不要怕学得慢 需要更广的知识面，不见得要深 要脸皮厚

任何环节都要100%用心

不要光给出结果，而要试着给出解决方案，哪怕这个方案是错的

软件测试小技巧：

（1）边界测试，测试用户输入框中的数值的最大数和最小数，以及为空时的情况。

（2）非法测试，例如在输入数字的地方输入字母。

（3）跟踪测试，跟踪一条数据的流程，保证数据的正确性。

（4）在开始测试时应保证数据的正确性，然后在从系统中找出各种BUG。 （5）接口测试，程序往往在接口的地方很容易发生错误，要在此模块测试勿掉以轻心。

（6）代码重用测试，在开发过程中有些模块功能几乎相同，程序员在重用代码时可能忘记在原有代码上修改或修改不全面，而造成的错误。 （7）突发事件测试，服务器上可能发生意外情况的测试。

（8）外界环境测试，有些系统在开发时依赖于另外一个系统，当另外一个系统发生错误时， 这个系统所受到的影响的情况。

（9）在程序员刚修复Bug之后的地方，再找一找，往往程序员只修复报告出来的缺陷而不去考虑别的功能在修改时可能会重新造成错误。

（10）认真做好测试记录在做完一天的测试记录之后，第二天再根据第一天的测试记录重复测试你会发现有未修正的错误。

（11）文字测试，如果在系统中有用词不当的地方，我想这是不应该的。 （12）系统兼容测试，例如有些程序在IE6能运行正常，到IE5下不能运行。有些程序在WIN2000下能运行，而到WIN98却不能运行。像一些很特别的用户去使用系统，你很有可能发现BUG。

（13）用户的易用性测试，往往用户的需求是不断的变化的，而其中的一部份

变化的原因，是有用户操作上不方便引起的。

软件测试是软件开发中的重中之重，没有一点可以马虎的，在项目管理过程，我强调的是每个过程的每一个环节都要进行测试，保证系统在每个阶段可以控制。因为软件测试中考虑的问题基本上是项目管理中考虑的问题。

性能测试初探

Android性能测试，包括启动时间、内存、CPU、GPU、功耗、流量； 启动时间、内存、CPU一般采用第三方工具辅助测试，如GT、安测试等； 1、启动时间

1）首次启动---displaymanager 2）非首次启动 3）应用界面切换

3月30日 自动化测试与QTP （一）

什么是自动化测试？一般定义：各种测试活动的管理与实施，包括测试脚本的开发与执行，以便使用一种自动测试工具来验证测试需求。

“自动化”指的是策略、工具和工件的使用，它增加或减少了手工或人为参与或干预非技巧性、重复或冗长工作的需要。（不是指工具本身，只要能解放双手，降低劳动强度的统称为自动化测试工具）

首先做好手工测试，必须对被测应用非常的熟悉，才能选择合适的应用做自动化测试。自动化是为测试服务的，最主要的是测试！

初始层—自动化测试本身：引入工具，解决手工效率、覆盖率的问题 二层--搭建自动化测试框架：测试步骤与业务相分离，在业务层写测试工具 三层--自动化测试过程：搭建环境，部署软件、编译、基础的功能测试、自动发现缺陷、自动提交报告、自动分发、自动修改、自动提交、自动编译、自动回归---整体的自动化测试过程

自动化功能测试主要围绕Windows、Unix和Linux图形界面、字符终端和browser界面进行测试。客户端可以是C/C++、VC、VB、JAVA、C#等编制的软件、各种字符终端软件或者运行浏览器IE和Netscape，通过自动录制形成测试脚本实现自动化功能/回归测试。

做自动化测试过程实际上就是一个软件开发的过程，开发实现软件功能，自动化测试工程师实现软件的自动化操作。 GUI自动化测试工具特点： 1、支持脚本语言

支持多种常用的变量和数据类型、数组、列表、结构、各种条件逻辑、循环、函数的创建和调用

2、对程序界面中对象的识别能力

鼠标位置识别、对象识别、位图对象识别（图像比较） 3、支持函数的可重用

脚本比较容易实现对函数的调用，脚本与被调用函数之间的参数传递 4、支持外部函数库

如Windows中DLL访问，如采用外部函数进行数据库操作正确性检查等 5、支持抽象层

可以将程序界面中存在的所有对象实体一一映射成逻辑对象，通过简单修改抽象层，帮助减少测试维护工作量 6、分布式测试支持

分布式测试可以实现定制任务执行的时间表，安排多人同时进行测试 7、支持数据驱动测试 8、支持错误处理 9、支持源代码管理

10、支持脚本的命令方式执行

GUI自动化测试实现方式 1、GUI录制回放方式 在测试者运行应用程序

3月31日 Ranorex

Ranorex是Windows上运行的GUI自动测试框架，它支持多种不同的应用，包括web 2.0, Win32, MFC, WPF, Flash/Flex, .Net和Java(SWT)。Ranorex没有自己的脚本语言，用户可以使用业界流行的编程语言C#, VB.NET编写它的测试用例。

Ranorex的特性包括，使用RanoreXPath对待测应用的GUI对象进行识别，这种方式可以识别绝大部分控件对象。

除此之外Ranorex拥有几乎所有自动测试工具都有的录制回放功能，这是通过它的Ranorex编辑器实现的，它被称为Renorex Recorder。该工具可以通过使用动作表格编辑器很方便地维护录制的代码，并且集成了Ranorex对象库，可以自动产生C#和VB.NET的代码。

与此同时Ranorex还提供了GUI对象映射功能，这就是前面提到的Ranorex对象库，该库对各种类型的GUI对象进行统一管理。

Ranorex还提供了专门支持.NET环境的自动测试库。用户使用Ranorex Studio可以非常轻松地进行自动测试开发，该集成环境提供了代码自动完成和强大的调试功能。

Ranorex曾经因为其对.NET和Flash/Flex绝佳支持获得第二届和第三季ATI自动测试最佳商业功能测试工具奖。

自学软件测试攻略：

首先是学习软件测试基本理论、打好基础、了解流程，然后针对被测软件的测试计划> 针对被测对象的测试用例 > 利用正确的功能测试方法进行软件测试活动。随后，当你工作1-2年后，能胜任一切基本的工作后，想发展得更好，就要深入的开展软测工作了，这个时候你就要深入的学习一些自动化测试工具的使用，一般是性能测试工具（loadrunner),功能测试工具(QTP) 和 测试管理工具(TD). 同时要学习数据库和软件的源代码相关知识，以备以后可以有能力做数据库测试，软件源代码的白盒测试等等，这些是工作3-4年后可以精通的。

测试用例的切面设计

所谓测试切面设计，其实就是测试用例大项的划分。测试用例划分的经典方法是瀑布模型，也就是从上到下，逐渐细分，大模块包括小模块，小模块包括更小的模块。但仅仅如此是不够的，我们还要从更多的角度切入系统，从不同的角度把系统切分成一块一块的，来进行测试，从而确保测试大项的完整性。 1、功能点切面

这是最常见的切面，通常我们认为页面上的一个按钮就是一个功能点。然后我们可以根据功能的复杂程度，按每个功能;或一个功能点分多页;或多个功能点合成一页来进行用例的撰写。 2、特定切面

除此以外，还有一种特定切面的划分方法，也是用例撰写时经常会用到的。所谓的特定切面，就是忽略掉表面上的功能点，而关注测试对象的某一个面。比如我们的内部管理系统提供了销售录入导入、注册录入导入等功能，从菜单划分上对应了七八个功能点。但这些功能处理后台有个共同的处理项就是授权记录的生成，这时我们就可以把“授权记录生成”单独拿出来做一个测试项，而在其它测试项中涉及这一部分的用例就不必再一一撰写。此外象一些界面共通的操作用例单独写成一页，也是一种特定切面。所以如果说将用例按功能点划分是一种纵向划分法，那么特定切面就是从横向的角度分析所得到的切面。在普通功能点划分上再根据实际情况设计特定切面，可以使我们的用例阅读性、理解性、操作性更强。 3、隐含切面

这类用例是最容易被忽略的。它往往不是明显的某个功能项，可能是功能项后台的隐含处理，也可能是多个功能项之间的关联处理，甚至可能是在某种特定情形下的处理。这都需要测试人员通过对软件的学习了解，来进行挖掘。 (1)、后台功能

常见的如一些定时自动启动的服务;以及某种特定情况下自动执行的操作等。它们在界面上往往是不体现的，但许多在需求设计中还是会提到，也有一些比较细小的功能可能会被忽略，就需要测试人员根据对项目的了解程度来进行挖掘。所以说一个熟悉项目的和一个不熟悉的测试人员，写出来的用例就完全是两个层次的。

(2)、完整业务流程的测试

我们都知道测试用例的设计是从点、线、面三个层次去考虑的。完整的一个功能项是线，其中的某个按钮是点，多个相关功能结合成完整业务流就是面。从实际来看这类用例往往被我们忽略。

事实上目前公司的软件本来都是业务型应用软件，将各种功能从业务流中切割出来单独写用例，肯定也会有涉及到整体流程的情况。若不加以区分，将细节与全局搅在一起，不仅思路混乱，也容易考虑不周。因此在系统测试阶段，建议用例

设计要有分有合，针对具体功能的就只围着这个功能转：而在业务流程测试项中，再完全从整体的业务流角度出发去考虑用例，这样不仅不容易产生疏漏，用例阅读与执行也更清楚。

(3)、某种特定情况下的系统运行

这类用例的设计往往与系统实际业务情况密不可分。比如财务软件，通常需要在月尾一天、月头一天、年尾一天、年头一天，对所有相关功能中的日期处理进行测试;又比如WIN 2000环境开发测试的系统，要测试在98、XP、2003等操作系统下是否能运行自如;再有如存在大量动态图片视频等的网页，在普通网速下的展现速度等等。总之就是要尽可能从实际应用的角度出发考虑，来进行测试补充。

(4)、其它相关系统

即指在当前项目中直接使用的其它成果，包括公司自有的系统模块、组件、函数;以及购买或免费得到的一些功能组件。对这些内容需要预先与开发组长等讨论清楚，是否需要测试。若时间紧张或其它原因决定不测的，应在测试计划中说明。若需要测试的，则具体可根据实际情况来设计，可以是通过系统某个功能的测试来涉及，此时就不需要单独划分测试项;若相对比较独立的，也可以通过单独的测试项来对其专门进行测试。 (5)、除功能测试外的其它测试类型

包括可靠性、安全性、恢复性、配置安装测试等等，这些测试类型都是一个单独的测试项。

所谓好的开始是成功的一半，保证测试项划分的完整、合理、正确，会直接影响到本次测试的成效。通常建议该阶段工作要花1-2天的时间来考虑，并要在测试过程中随着对软件的深入了解，不断进行调整补充。可千万不要认为把分析设计中的功能模型图搬搬过来

本文来源：https://www.bwwdw.com/article/m5cr.html