目录
1.软件测试基础
1.1什么是软件测试
首先要明确测试的定义,所谓测试,就是以检验产品是否满足需求为目标。
软件测试:在规定的条件下对程序进行操作，以发现错误，对软件质量进行评估。
1.2软件测试目的
软件测试员的目标是尽可能早地找出软件缺陷，并确保其得以修复。
按照软件质量国家标准 GB-T8566–2001G，软件质量可以用下列特征来评价：
a.功能特征：与一组功能及其指定性质有关的一组属性，这里的功能是满足明确或隐含的需 求的那些功能。
b.可靠特征：在规定的一段时间和条件下，与软件维持其性能水平的能力有关的一组属性。
c.易用特征：由一组规定或潜在的用户为使用软件所需作的努力和所作的评价有关的一组属性。
d.效率特征：与在规定条件下软件的性能水平与所使用资源量之间关系有关的一组属性。
e.可维护特征：与进行指定的修改所需的努力有关的一组属性。
f.可移植特征：与软件从一个环境转移到另一个环境的能力有关的一组属性。
系统测试结束标准：
被测对象基本满足需求规格及范围
未发现严重级别的缺陷，且一般性缺陷数小于10个
已拒绝、已挂起的缺陷均已正确处理
系统测试报告已出
1.3软件测试流程
测试最规范的过程如下：需求测试->概要设计测试->详细设计测试->单元测试->集成测试->系统测试->验收测试（来自 W 模型）
详细的描述一个测试活动完整的过程
- 项目经理通过和客户的交流，完成需求文档，由开发人员和测试人员共同完成需求文档的评审，评审的内容包括：需求描述不清楚的地方和可能有明显冲突或者无法实现的功能的地方。项目经理通过综合开发人员，测试人员以及客户的意见，完成项目计划。
- 开发人员根据需求文档完成需求分析文档，测试人员进行评审，评审的主要内容包括是否有遗漏或双方理解不同的地方。测试人员完成测试计划文档，测试计划包括的内容上面有描述。
- 测试人员根据修改好的需求分析文档开始写测试用例，同时开发人员完成概要设计文档，详细设计文档。此两份文档成为测试人员撰写测试用例的补充材料。
- 测试用例完成后，测试和开发需要进行评审。
- 测试人员搭建环境
- 开发人员提交第一个版本，可能存在未完成功能，需要说明。测试人员进行测试，发现BUG后提交到bug管理系统。
- 开发提交第二个版本，包括Bug Fix以及增加了部分功能，测试人员进行测试。
- 重复上面的工作，一般是3-4个版本后BUG数量减少，达到出货的要求。
- 执行自动化测试，编写脚本，执行，分析，报告；进行性能测试，压力测试等其他测试，执行，分析，调优，报告。
- 编写测试报告
- 如果有客户反馈的问题，需要测试人员协助重现并重新测试
1.4测试用例怎么写
用例编号、用例类型、用例标题（名称）、前置条件、操作步骤、测试数据、预期结果、实际结果
1.5bug的严重程度和优先级
Bug 的 priority（）和 severity（）是两个重要属性，通常人员在提交bug 的时候，只定义severity，而将 priority 交给 leader 定义，通常 bug 管理中，severity 分为四个等级 blocker、critical、major、minor/trivial，而 priority 分为五个等级 immediate、urgent、high、normal、low。
Severity（严重程度）
1、blocker：即系统无法执行，崩溃，或严重资源不足，应用模块无法启动或异常退出，无法测试，造成系统不稳定。
- 严重花屏
- 内存泄漏
- 用户数据丢失或破坏
- 系统崩溃/死机/冻结
- 模块无法启动或异常退出
- 严重的数值计算错误
- 功能设计与需求严重不符
- 其它导致无法测试的错误, 如服务器500错误
2、critical：即映像系统功能或操作，主要功能存在严重缺陷，但不会映像到系统稳定性。
- 功能未实现
- 功能错误
- 系统刷新错误
- 数据通讯错误
- 轻微的数值计算错误
- 影响功能及界面的错误字或拼写错误
- 安全性问题
3、major：即界面、性能缺陷、兼容性
- 操作界面错误（包括数据窗口内列名定义、含义是否一致）
- 边界条件下错误
- 提示信息错误（包括未给出信息、信息提示错误等）
- 长时间操作无进度提示
- 系统未优化（性能问题）
- 光标跳转设置不好，鼠标（光标）定位错误
- 兼容性问题
4、minor/trivial：即易用性及建议性问题。
- 界面格式等不规范
- 辅助说明描述不清楚
- 操作时未给用户提示
- 可输入区域和只读区域没有明显的区分标志
- 个别不影响产品理解的错别字
- 文字排列不整齐等一些小问题
Priority（优先级）
- immediate：即马上解决，表示问题必须马上解决，否则系统根本无法达到预定的需求。
- urgent：急需解决，表示问题的修复很紧要，很急迫，关系到系统的主要功能模块能否正常。
- high：高度重视，有时间要马上解决，否则系统偏离需求较大或预定功能不能正常实现。
- Normal即“正常处理”，进入个人计划解决，表示问题不影响需求的实现，但是影响其他使用方面，比如页面调用出错，调用了错误的等。
- low：在系统发布前解决，或确认可以不用解决。
1.6敏捷测试
强调从使用系统的用户（客户）角度出发来测试系统。重点关注持续迭代地测试新开发的功能，而不再强调传统测试过程中严格的测试阶段。同时需要及早介入测试 ，不间断测试，具备条件即测试，持续进行回归测试保证之前测试过内容的正确性。
敏捷宣言：
个体与交互 重于 过程和工具
可用的软件 重于 完备的文档
客户协作 重于 合同谈判
响应变化 重于 遵循计划
在每对比较中，后者并非全无价值，但我们更看重前者
传统测试与敏捷测试对比：
敏捷测试就是符合敏捷宣言思想，遵守敏捷开发原则，在敏捷开发环境下能够很好地和其整体开发流程融合的一系列的测试实践，这些实践具有鲜明的敏捷开发的特征，如TDD、ATDD、结对编程、持续测试等。和传统测试的区分，可以概括如下：
1）传统测试更强调测试的独立性，将“开发人员”和“测试人员”角色分得比较清楚。而敏捷测试可以有专职的测试人员，也可以是全民测试，即在敏捷测试中，可以没有“测试人员”角色，强调整个团队对测试负责。
2）传统测试更具有阶段性，从需求评审、设计评审、单元测试到集成测试、系统测试等，从测试计划、测试设计再到测试执行、测试报告等，但敏捷测试更强调持续测试、持续的质量反馈，阶段性比较模糊。
3）传统测试强调测试的计划性，认为没有良好的测试计划和不按计划执行，测试就难以控制和管理，而敏捷测试更强调测试的速度和适应性，侧重计划的不断调整以适应需求的变化。
4）传统测试强调测试是由“验证”和“确认”两种活动构成的，而敏捷测试没有这种区分，始终以用户需求为中心，每时每刻不离用户需求，将验证和确认统一起来。
5）传统测试强调任何发现的缺陷要记录下来，以便进行缺陷根本原因分析，达到缺陷预防的目的，并强调缺陷跟踪和处理的流程，区分测试人员和开发人员的各自不同的责任。而敏捷测试强调面对面的沟通、协作，强调团队的责任，不太关注对缺陷的记录与跟踪。
6）传统测试更关注缺陷，围绕缺陷开展一系列的活动，如缺陷跟踪、缺陷度量、缺陷分析、缺陷报告质量检查等，而敏捷测试更关注产品本身，关注可以交付的客户价值。在快速交付的敏捷开发模式下，缺陷修复的成本很低。
7）传统测试鼓励自动化测试，但自动化测试的成功与否对测试没有致命的影响，但敏捷测试的基础就是自动化测试，敏捷测试是具有良好的自动化测试框架支撑的快速测试。
测试驱动开发（TDD）
测试驱动开发，英文全称是Test-Driven Development，简称为TDD，它是一种不同于传统软件开发流程的新型的开发方法。它要求在编写某个功能的代码之前先编写好测试代码，然后只编写使测试通过的功能代码，通过测试来推动整个开发的进行。这有助于编写简洁可用和高质量的代码，并加速开发过程。
简单来说，测试驱动开发是针对一些小功能点甚至小到一个方法的敏捷开发实践。传统的开发模式是开发人员编写完业务代码后再开始编写单元测试脚本来验证上一步的业务功能代码，而测试驱动开发的中心思想却是先根据需求文档来编写测试代码（即先编写单元测试脚本），并思考怎样对这些要实现的业务功能作验证，等编写了足够的单元测试脚本后，再继续编写业务功能代码，通过测试后，再继续迭代以上的过程一直到编写完成所有的业务需求功能模块。
测试驱动开发与传统开发的区别
传统开发模式下编写的单元测试脚本其实还是为了验证功能，仍属于测试的一种形式。而测试驱动开发已经不再是一种简单的测试行为了，准确地说，它是一种设计行为。测试驱动开发类似于是对一段代码的用法而编写的设计规格说明，可以从编写代码的内聚性、可测性、可复用性以及缺陷密度、接口的简易水平看出。在测试驱动开发中，以需求的剖析、用户业务功能的理解都是层层递进的，是可以逐步细化到代码级别的，而这样的过程也恰恰提高了测试的覆盖率，同时能从根本上解决一些因业务逻辑设计错误而导致的后期大量的缺陷修复工作。
测试驱动开发的优缺点
测试驱动开发最大的优点就是重构了，不断迭代，不断地对现有代码进行重构，不断优化代码的内部结构，最终实现对整体代码的改进。以此不断减少一些设计冗余、代码冗余、接口复杂度等等。
另外，对于一些前期需求不明确，甚至需求信息量特别少，且后期又会有大量业务功能修改时，传统的开发模式需要加班加点以此赶工开发，测试，缺陷修复，人工、时间成本且不说，最重要的产品质量也无法得到保证。当然 ，这种模式下也最适合采用原型法、敏捷开发模式了，毕竟拥抱变化是敏捷的宗旨 。而测试驱动开发也是敏捷开发模式的基础，这样无论是来自客户的紧急需求还是项目团队的一次技术改革，都可以通过重构设计、增加测试脚本来实现了。
2.测试方法
2.1单元测试、集成测试、系统测试、回归测试、验收测试
单元测试
一般由开发小组采用白盒方式来测试，主要测试单元是否符合“设计”。单元测试是对软件基本组成单元（软件设计的最小单位）进行正确性检验的测试工作，如函数、过程(function,procedure)或一个类的方法(method)。
集成测试
集成测试是在单元测试的基础上，将所有模块按照概要设计要求组装成为子系统或系统，验证组装后功能以及模块间接口是否正确的测试工作。集成测试也叫组装测试、联合测试、子系统测试或部件测试。应当避免一次性的集成（除非软件规模很小），而采用增量集成：
自顶向下集成
从主控制模块开始，沿着程序的控制层次向下移动，逐渐把各个模块结合起来，就是自顶向下的集成。在把附属于主控制模块的那些模块组装到程序结构中去时，可以使用深度优先的策略或者使用宽度优先的策略。所谓深度优先，就是先组装在软件结构的一条主控制通路上的所有模块；宽度优先就是沿软件结构水平地移动，把处于同一个控制层次上的所有模块组装起来。
自底向上集成
用下述步骤可以实现自底向上的结合策略：
- 把低层模块组合成实现某个特定的软件子功能的族；
- 写一个驱动程序(用于测试的控制程序)，协调测试数据的输入和输出；
- 对由模块组成的子功能族进行测试；
- 去掉驱动程序，沿软件结构自下向上移动，把子功能族组合起来形成更大的子功能族。
- 不断重复2~4步，直到构造起完整的软件结构为止。
系统测试
在集成测试完成之后，将已集成好的的软件系统，与计算机硬件环境、外部设置、输入数据、其他依赖软件、用户等结合在一起，进行的一系列测试活动。系统测试是针对整个产品系统进行的测试。
目的：
- 确保系统测试的活动是按计划进行的；
- 验证被测产品与用户需求是否相符，即是否符合需求规格说明书中的各项描述；
- 检查所有显性与隐性需求均被正确实现；
- 检查并确保最终系统可以交付验收测试。
测试依据：需求规格说明书(SRS)&其他用户文档资料
测试对象：整个被测系统或产品
集成测试与系统测试：
集成测试：完成单元测试后，各模块联调测试；集中在各模块的接口是否一致、各模块间的数据流和控制流是否按照设计实现其功能、以及结果的正确性验证等等；可以是整个产品的集成测试，也可以是大模块的集成测试；集成测试主要是针对程序内部结构进行测试，特别是对程序之间的接口进行测试。集成测试对测试人员的编写脚本能力要求比较高。测试方法一般选用黑盒测试和白盒测试相结合。
系统测试 ：针对整个产品的全面测试，既包含各模块的验证性测试（验证前两个阶段测试的正确性）和功能性（产品提交个用户的功能）测试，又包括对整个产品的健壮性、安全性、可维护性及各种性能参数的测试。系统测试测试软件《需求规格说明书》中提到的功能是否有遗漏， 是否正确的实现。做系统测试要严格按照《需求规格说明书》，以它为标准。测试方法一般都使 用黑盒测试法。
回归测试
回归测试是指在发生修改之后重新测试先前的测试用例以保证修改的正确性。理论上，软件产生新版本，都需要进行回归测试，验证以前发现和修复的错误是否在新软件版本上再次出现。根据修复好了的缺陷再重新进行测试。回归测试的目的在于验证以前出现过但已经修复好的缺陷不再重新出现。一般指对某已知修正的缺陷再次围绕它原来出现时的步骤重新测试。
按照常规的做法，当一个缺陷修复完毕后，通常会对修复后的代码进行两种形式的测试。首先是确认测试，以验证该修复程序实际上已经修复了缺陷，二是回归测试，以确保修复部分本身没有破坏已有的功能。需要注意的是，当新的功能添加到现有的应用程序时也适用这一相同的原理。
自动化回归测试：
在可能情况下，回归测试必须自动化。用相同的变量和条件一遍又一遍的运行相同的测试，不会产生任何新的缺陷。重复的工作会造成执行测试者的丧失兴趣和注意力不集中，可能在执行回归测试的过程中错失发现潜在缺陷的机会。此外自动化回归测试的另一个优点是，可以添加多个测试用例到该回归测试包而不对花费时间产生太大影响。自动回归测试包可以连夜执行或与手动测试并行运行，并能释放资源。
验收测试
验收测试是指系统开发生命周期方法论的一个阶段，这时相关的用户或独立测试人员根据测试计划和结果对系统进行测试和接收。它让系统用户决定是否接收系统。它是一 项确定产品是否能够满足合同或用户所规定需求的测试。验收测试包括 Alpha 测试和 Beta 测试。
Alpha 测试
是由用户在开发者的场所来进行的，在一个受控的环境中进行，也可以是公司内部的用户在模拟实际操作环境下进行的测试；
环境是受开发方控制的,用户的数量相对比较少,时间比较集中；
α测试先于β测试执行。
Beta 测试
由软件的最终用户在一个或多个用户场所来进行的，开发者通常不在现场，用户记录测试中遇到的问题并报告给开发者，开发者对系统进行最后的修改，并开始准备发布最终的软件；
环境是不受开发方控制的, 用户数量相对比较多,时间不集中。
冒烟测试
冒烟测试就是在每日build（构建版本）建立后，对系统的基本功能（主流程）进行简单的测试。这种测试强调程序的主要功能进行的验证，而不会对具体功能进行更深入的测试。
2.2黑盒测试、白盒测试、灰盒测试
黑盒测试
把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。因此黑盒测试又叫功能测试或数据驱动测试。
测试方法：
1.等价类划分 等价类划分是将系统的输入域划分为若干部分，然后从每个部分选取少量代表性数据进行测试。等价类可以划分为有效等价类和无效等价类，设计测试用例的时候要考虑这两种等价类。
2.边界值分析法 边界值分析法是对等价类划分的一种补充，因为大多数错误都在输入输出的边界上。边界值 分析就是假定大多数错误出现在输入条件的边界上，如果边界附件取值不会导致程序出错，那么 其他取值出错的可能性也就很小。
边界值分析法是通过优先选择不同等价类间的边界值覆盖有效等价类和无效等价类来更有 效的进行测试，因此该方法要和等价类划分法结合使用。
3.正交试验法 正交是从大量的试验点中挑选出适量的、有代表性的点。正交试验设计是研究多因素多水平的一种设计方法，他是一种基于正交表的高效率、快速、经济的试验设计方法。
4.状态迁移法状态迁移法是对一个状态在给定的条件内能够产生需要的状态变化，有没有出现不可达的状态和非法的状态，状态迁移法是设计足够的用例达到对系统状态的覆盖、状态、条件组合、状态迁移路径的覆盖。
5.流程分析法流程分析法主要针对测试场景类型属于流程测试场景的测试项下的测试子项进行设计，这是从白盒测试中路径覆盖分析法借鉴过来的一种很重要的方法。
6.输入域测试法输入域测试法是针对输入会有各种各样的输入值的一个测试，他主要考虑 极端测试、中间范围测试，特殊值测试 。
7.输出域分析法 输出域分析法是对输出域进行等价类和边界值分析，确定是要覆盖的输出域样点，反推得到应该输入的输入值，从而构造出测试用例，他的目的是为了达到输出域的等价类和边界值覆盖。
8.判定表分析法 判定表是分析和表达多种输入条件下系统执行不同动作的工具，他可以把复杂的逻辑关系和多种条件组合的情况表达的即具体又明确；
9.因果图法 因果图是用于描述系统输入输出之间的因果关系、约束关系。因果图的绘制过程是对被测系 统的外部特征的建模过程，根据输入输出间的因果图可以得到判定表，从而规划出测试用例。
10.错误猜测法 错误猜测法主要是针对系统对于错误操作时对于操作的处理法的猜测法，从而设计测试用例
11.异常分析法 异常分析法是针对系统有可能存在的异常操作，软硬件缺陷引起的故障进行分析，分析发生 错误时系统对于错误的处理能力和恢复能力依此设计测试用例。
白盒测试
可以访问程序员的代码，并通过检查代码的线索来协助测试——可以看到盒子里面。
- 保证一个模块中的所有独立路径至少被测试一次；
- 所有逻辑值均需要测试真（true）和假（false）；两种情况；
- 检查程序的内部数据结构，保 证其结构的有效性；
- 在上下边界及可操作范围内运行所有循环。
常用白盒测试方法有逻辑覆盖法，程序插桩技术，基本路径法，符号测试，错误驱动测试
静态白盒测试：不用运行程序的测试，包括代码检查、静态结构分析、代码质量度量、文档测试等等，它可以由人工进行，充分发挥人的逻辑思维优势，也可以借助软件工具（Fxcop）自动进 行。
动态白盒测试：需要执行代码，通过运行程序找到问题，包括功能确认与接口测试、覆盖率分析、 性能分析、内存分析等。
白盒测试中的逻辑覆盖包括语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖。六种覆盖标准发现错误的能力呈由弱到强的变化：
1.语句覆盖每条语句至少执行一次。
2.判定覆盖每个判定的每个分支至少执行一次。
3.条件覆盖每个判定的每个条件应取到各种可能的值。
4.判定/条件覆盖同时满足判定覆盖条件覆盖。
5.条件组合覆盖每个判定中各条件的每一种组合至少出现一次。
6.路径覆盖使程序中每一条可能的路径至少执行一次。
灰盒测试
介于白盒测试与黑盒测试之间的，可以这样理解，灰盒测试关注输出对于输入的正确性，同时也关注内部表现，但这种关注不象白盒那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运行状态，有时候输出是正确的，但内部其实已经错误了，这种情况非常多，如果每次都通过白盒测试来操作，效率会很低，因此需要采取这样的一种灰盒的方法。
2.3静态测试、动态测试
静态测试
静态测试是不运行程序本身而寻找程序代码中可能存在的错误或评估程序代码的过程。
动态测试
动态测试是实际运行被测程序，输入相应的测试实例，检查运行结果与预期结果的差异，判定执行结果是否符合要求，从而检验程序的正确性、可靠性和有效性，并分析系统运行效率和健壮性等性能。
2.4手工测试与自动化测试
| 优点 | 缺点 | |
| 手工测试 | 1、测试人员具有经验和对错误的猜测能力。 2、测试人员具有审美能力和心理体验。 3、测试人员具有是非判断和逻辑推理能力。 | 1、重复的手工回归测试，代价昂贵、容易出错。 2、依赖于软件测试人员的能力。 |
| 自动化测试 | 1、对程序的回归测试更方便。这可能是自动化测试最主要的任务，特别是在程序修改比较频繁时，效果是非常明显的。由于回归测试的动作和用例是完全设计好的，测试期望的结果 也是完全可以预料的，将回归测试自动运行，可以极大提高测试效率，缩短回归测试时间。 2、可以运行更多更繁琐的测试。自动化的一个明显的好处是可以在较少的时间内运行更多的测试。 3、可以执行一些手工测试困难或不可能进行的测试。比如，对于大量用户的测试，不可能同时让足够多的测试人员同时进行测试，但是却可以通过自动化测试模拟同时有许多用户，从而达到测试的目的。 4、更好地利用资源。将繁琐的任务自动化，可以提高准确性和测试人员的积极性，将测试技术人员解脱出来投入更多精力设计更好的测试用例。有些测试不适合于自动测试，仅适合于手工测试，将可自动测试的测试自动化后，可以让测试人员专注于手工测试部分，提高手工测试的效率。 5、测试具有一致性和可重复性。由于测试是自动执行的，每次测试的结果和执行的内容的一致性是可以得到保障的，从而达到测试的可重复的效果。 6、测试的复用性。由于自动测试通常采用脚本技术，这样就有可能只需要做少量的甚至不做修改，实现在不同的测试过程中使用相同的用例。 7、增加软件信任度。由于测试是自动执行的，所以不存在执行过程中的疏忽和错误， 完全取决于测试的设计质量。一旦软件通过了强有力的自动测试后，软件的信任度自然会增加。 | 1、不能取代手工测试 2、手工测试比自动测试发现的缺陷更多 3、对测试质量的依赖性极大 4、测试自动化不能提高有效性 5、测试自动化可能会制约软件开发。由于自动测试比手动测试更脆弱，所以维护会受 到限制，从而制约软件的开发。 6、工具本身并无想像 |
2.5功能测试和非功能测试
2.5.1功能测试
目的：检查产品的功能是否满足用户需求
工作内容
- 业务流是否正确实现
- 功能点是否正确实现
- 输入输出是否正确实现
测试工具：QTP（使用 B/S和C/S软件），LoadRunner（C/S软件），Selenium， IBM Rational Robot
工作原理：模拟用户操作
功能测试一般包含哪些测试类型：即黑盒测试方法。
常见的功能测试用例的设计方法：等价类划分法、边界值分析法、因果图法、正交实验法、判定表法、错误推测法
2.5.2非功能测试
性能测试
目的：验证产品是否满足用户指定性能需求
测试点：响应时间和资源性能(CPU,I/O,内存，信道，传输速度，响应时间)
备注：
-
内存和硬盘的区别
-
内存临时存储，电脑关机，信息就消失，内存容量小但速度快
-
硬盘是靠执行存储，断电后也可保存数据，硬盘存储量大但速度慢
-
-
信道与宽带有关，与访问人数有关
-
吞吐量，每个时间单元的处理数据
-
测试方法：压力测试、负载测试、容量测试等
-
高级录制可以获取到每个控件的name值，但普通录制只能定位鼠标移动到的位置
测试工具：LoadRunner，Webload ，Jmeter，Silk Performance
工作原理：（B或者C端通过传送协议与Server进行通信）录制时需要选择对应协议。
安全测试
目的：验证产品在系统的内部的安全保护机制和系统外对入侵的防护能力
测试点：
-
内部包括身份验证，权限，数据的完整一致，数据的保密性（DB中有些数据加密保存）
-
外部，病毒木马，未授权攻击，传输数据安全（传输过程中密码加密，通过HTTP协议传输）
测试工具：MBSA,IBM Rational Appscan,X-scan
工作原理：监控服务器或客户端哪些端口应该被禁止
功能性的安全问题主要有：
-
没有口令可成功登录到系统中？
-
各级用户权限划分是否合理
-
系统错误与文件访问是否被默认记录
-
系统配置数据默认保存是临时还是永久性
-
系统发生故障时是否可以正常恢复
兼容性测试
①web兼容性测试
主要考量：
- 浏览器的兼容性
- 操作系统的兼容性（核心：window,max,iphone）
测试方法：
- 人工测试：测试工程师测试主流浏览器和常用操作系统测试主流程和主界面，看看主流程和主页面是否有问题
- 第三方工具测试：部分情况下，部分浏览器可以依赖第三方工具辅助测试
②app兼容性测试
方向：
- 硬件设备兼容（手机）
- 手机操作系统版本兼容性
测试方法：
- 人工测试：测试工程师测试主流手机设备对主流程和主功能进行验证测试
- 第三方测试工具：三方主要以云平台为主
安装测试
目的：产品的安装过程和结果进行测试
工作内容：根据软件的测试特性列表，软件安装，配置文档，设计安装过程的测试用例
产品安装前的准备工作有：
- 检查所安装文档是否齐全
- 检查安装软件的程序文档是否齐全
- 检查被测软件的安装文件是否齐全
- 检查软件的文件格式与安装指导中要求的文件格式是否符合
安装过程中需要的检查工作
- 所有的预置数据是否齐全
- 软件环境配置是否合理
- 硬件环境配置是否合理
- 安装的过程测试
- 安装文档的测试
安装后要做的检查工作：
- 安装日志的检查
- 安装完成后，要进行程序的运行联接验证
- 软件的卸载测试
- 是否存在临时目录，垃圾文件，是否清除掉了冷补丁
- 安装软件中的升级测试
- 软件通过重新安装来升级，考虑到版本兼容性测试
- 软件在线升级
安装时异常终止包括：进程终止（操作系统未关闭）断电，断网
测试对象：安装文件、安装系统、安装文档、配置项
GUI测试
即用户界面测试，接口测试。GUI测试无法脱离功能测试而独立存在，否则只能测试外观，布局，而无法测试行为产生的结果
测试点：
-
对界面元素进行测试，检查产品界面是否与SRS设计一致（包括布局，外观，配色，元素行为，元素功能）
-
验证界面元素的交互是否正确。包括：整体界面，独立元素组合，独立元素
测试想法：先找整体界面，再测组合元素和独立元素（据对用户的影响严重程度来排列定义优先级）
工具：所有做功能测试的工具都可以做GUI测试
易用性测试
目的：检查产品是否符合实际应用情况，是否符合用户使用习惯及特殊要求，操作方式是否合理。同时交互信息是否通俗易懂，是否符合行业规则等等。
测试点：
-
过分复杂的功能或指令，提示信息出现错误码
-
安装过程复杂且耗时
-
系统错误信息过于简单
-
语法、语义、格式定义不一致
容错性测试（又称健壮性测试）
目的：检查系统容错能力，检查软件在异常条件下自身是否具有防护性措施，确保系统无论接收何种条件触发也不会发生意外事故 。
测试点：
-
输入错误或无效的数据类型
-
输入定义域外的数值
-
对关键进程或线程杀死，然后观察系统行为；
-
网络不稳定或DB异常情况下，检查系统响应
-
手动将系统的正常进程关闭或断开 ，检查系统响应
文档测试
并非单纯地指文档测试。需要对一组测试文档进行完整性、正确性、一致性的校验。
测试点：
-
仔细阅读每个步骤，检查每个图片，并重现每个文档中的示例。
-
检查文档的编写是否满足项目要求的文档目的。
-
检查文档内容是否完善、标记是否正确。
备份测试
目的：通过检查软件的备份策略来解决相应的数据丢失风险问题。
备份策略包括
-
本地备份
-
实时备份
-
本地异步备份
-
异地异步备份
-
恢复策略
配置测试
包括软件配置和硬件配置。
通过对被测系统软件与硬件环境的修改，分析每个环境组合对系统性能影响的程度，最后确定系统各项资源的最优分配原则。
配置测试属于性能测试的一个细分类。
多语种测试
又称本地化测试，是指为各个地方开发产品的测试，如英文版，中文版等等，包括程序是否能够正常运行，界面是否符合当地习俗，快捷键是否正常起作用等等，特别测试在A语言环境下运行B语言软件（比如在英文win98下试图运行中文版的程序），出现现象是否正常。
本地化测试还要考虑：
- 当语言从A翻译到B，字符长度变化是否影响页面效果。比如中文软件中有个按键叫“看广告”，翻译到英文版本中为 “View advertisement”可能影响页面的美观程度
- 要考虑同一单词在各个国家的不同意思，比如football在英文中为足球，而美国人使用中可能理解为美式橄榄球。
- 要考虑各个国家的民族习惯，比如龙个美国中被理解邪恶的象征，但翻译到中国，中国人认为为吉祥的象征
分辨率测试
测试在不同分辨率下，界面的美观程度,分为800*600，1024*768，1152*864，1280*768，1280*1024，1200*1600大小字体下测试。一个好的软件要有一个极佳的分辨率，而在其他分辨率下也都能可以运行。
发布测试
主要在产品发布前对一些附带产品，比如说明书，广告稿等进行测试
1.说明书测试
主要为语言检查，功能检查，图片检查
语言检查：检查说明书语言是否正确，用词是否易于理解；
功能检查：功能是否描述完全，或者描述了并没有的功能等；
图片检查:：检查图片是否正确
2.宣传材料测试
主要测试产品中的附带的宣传材料中的语言，描述功能，图片
3.帮助文件测试
帮助文件是否正确，易懂，是否人性化。最好能够提供检索功能
4.广告用语
产品出公司前的广告材料文字，功能，图片，人性化的检查
3.web测试
4.app测试
4.1app 性能测试的指标
（1）内存
内存消耗测试节点的设计目标是为了让应用不占用过多的系统资源，且及时释放内存，保障整个系统的稳定性。当然关于内存测试，在这里我们需要引入几个概念：空闲状态、 中等规格、满规格。
空闲状态指打开应用后，点击 home 键让应用后台运行，此时应用处于的状态叫做空闲；
中等规格和满规格指的是对应用的操作时间的间隔长短不一，中等规格时间较长，满规格时间较短。
内存测试中存在很多测试子项，清单如下：
●空闲状态下的应用内存消耗；
●中等规格状态下的应用内存消耗； ●满规格状态下的应用内存消耗；
●应用内存峰值；
●应用内存泄露；
●应用是否常驻内存；
●压力测试后的内存使用。
内存:使用adb shell脚本进行测试，查看Log数据。adb shell dump meminfo
（2）CPU
使用 Android 提供的 view plaincopy 在 CODE 上查看代码片派生到我的代码片 adbshell dumpsys CPUinfo |grep packagename >/address/CPU.txt 来获取； 使用 top 命令 view plaincopy 在 CODE 上查看代码片派生到我的代码片 adbshell top |grep packagename>/address/CPU.txt 来获取。
CPU：使用adb shell脚本进行测试，查看Log数据。adb shell top
注意：程序持续运行及操作过程中，内存不能一直增加，不然系统会自动kill掉该进程。
（3）流量
网络流量测试是针对大部分应用而言的，可能还有部分应用会关注网速、弱网之类的测试。
流量测试包括以下测试项：
应用首次启动流量提示；
应用后台连续运行2小时的流量值；
应用高负荷运行的流量峰值。
流量监控：可以借用网易的开源工具：Emmagee
（4）电量
- 测试手机安装目标 APK 前后待机功耗无明显差异
- 常见使用场景中能够正常进入待机，待机电流在正常范围内
- 长时间连续使用应用无异常耗电现象
电量监控：和竞品做对比测试，同一机型的测试机在不同时间，不同网络条件，不同功能使用的情况下分别测试电量使用情况。
（5）启动速度
第一类：首次启动 --应用首次启动所花费的时间；
第二类：非首次启动 --应用非首次启动所花费的时间；
第三类：应用界面切换–应用界面内切换所花费的时间。
（6）滑动速度、界面切换速度
（7）与服务器交互的网络速度
编写测试代码（Android Instrumentation），打桩到源码中，运行后通过log数据进行分析。
预期标准指定原则：
-
分析竞争对手的产品，所有指标要强于竞品
-
产品经理给出的预期性能指标数据
-
符合业内行业标准
站在管理员的角度考虑需要关注的性能点
(1)、 响应时间
(2)、 服务器资源使用情况是否合理
(3)、 应用服务器和数据库资源使用是否合理
(4)、 系统能否实现扩展
(5)、 系统最多支持多少用户访问、系统最大业务处理量是多少
(6)、 系统性能可能存在的瓶颈在哪里
(7)、 更换那些设备可以提高性能
(8)、 系统能否支持7×24小时的业务访问
站在测试工程师角度考虑
(1)、连接超时
这个是App关闭的首要问题，而在移动应用中网络错误数据比例报错中最高的就是连接超时错误。
(2)、崩溃
APP的崩溃，就是用户的崩溃。当用户使用你的App出现闪退或崩溃时，他们很有可能跑去App Store赠送你一个“一星”差评。
(3)、系统交互（电话短信干扰，低电量提醒，push提醒，usb数据线插拔提醒，充电提醒等）
在APP使用过程中，可能会遇到各种中断场景，那么一旦发生这些场景，APP就卡死或者闪退，想必也没有多少用户愿意持续使用你的APP。
(4)、弱网下的运行情况
电梯里、地铁上，网络信号差时，APP页面的菊花转不停，界面卡死，同时错误提示一堆，这样的情况怎能不让用户抓狂。
(5) 、CPU使用问题
CPU频率设置过高时会导致过热,过热导致耗电更严重, CPU频率设置过低导致手机滞后,应用处理缓慢同样会导致耗电。更多时候，用户解决CPU超载问题只能关闭甚至卸载App，App就被Kill了!
4.2测试工具
功能测试自动化
a) 轻量接口自动化测试：jmeter
b) APP UI 层面的自动化
android：UI Automator Viewer，Android Junit，Instrumentation，UIAutomator
iOS:基于 Instrument 的 iOS UI 自动化，
性能测试
a) Web 前端性能测试
网络抓包工具：Wireshark
网页文件大小
webpagetest
pagespeed insight
chrome adb
b) APP 端性能测试
Android 内存占用分析：MAT
iOS 内存问题分析：ARC 模式
Android WebView 性能分析：
iOS WebView 性能分析
c) 后台服务性能测试负载，压力，耐久性可拓展性，基准
工具：apacheAB，Jmeter，LoadRunner，
专项测试
a) 兼容性测试
手工测试：操作系统，分辨率，rom，网络类型
云平台：testin，脚本编写，Android。
b) 流量测试
Android 自带的流量管理，
iOS 自带的 Network
tcpdump 抓包
WiFi 代理抓包：Fiddler
流量节省方法：压缩数据，json 优于 xml；WebP 优于传统的 JPG，PNG；控制访问的频次； 只获取必要的数据；缓存；
c) 电量测试
基于测试设备的方法，购买电量表进行测试。
GSam Battery Monitoe Pro
iOS 基于 Instrument Energy 工具
d) 弱网络测试
手机自带的网络状况模拟工具
基于代理的弱网络的模拟:
工具：windows：Network Delay Simulator
Mac：Network Link Conditioner
web测试和app测试对比：
| 系统架构方面 | 性能方面 | 兼容方面 | |
| web测试 | 1.一般都是 b/s 架构，基于浏览器的 2.只要更新了服务器端，客户端就会同步会更新 | web 页面主要会关注响应时间和资源性能(CPU,I/O,内存，信道，传输速度) | 1.web 是基于浏览器的，所以更倾向于浏览器和电脑硬件，电脑系统的方向的兼容 2.web测试是基于浏览器的所以不必考虑安装卸载 |
| app测试 | 1.一般是 c/s 的，必须要有客户端，用户需要安装客户端 2.需要客户端和服务器都更新 | app 则还需要关心流量、电量、CPU、GPU、Memory 这些。 它们服务端的性能没区别，都是一台服务器。 | 1.app测试则要看屏幕尺寸，系统兼容、机型兼容、屏幕分辨率兼容、网络兼容、其它（如设备、存储、第三方应用等兼容） 2.app是客户端的，则必须测试安装、更新、卸载。除了常规的安装、更新、卸载还要考虑到异常场景。包括安装时的中断、弱网、安装后删除安装文件 3. APP还有一些专项测试：如网络、适配性 |
4.3 Android测试 与 iOS测试
Android手机如何截取崩溃log
1、下载ADB工具包
2、测试手机连接到电脑端（手机助手根据手机型号选择）
3、打开测试手机中的开发者模式
4、打开DOS窗口
5、进入到 adb所在目录
6、输入命令：adb logcat -v time > D:\\logcat.log（>后代表日志存放目录）
7、执行命令后开始操作应用
8、Ctrl在+C结束命令
9、进入日志存放目录中查看
IOS应用闪退时如何截取Log
1. 安装iTools
2. 测试手机连接到电脑端
3. 在iTools界面，点击进入崩溃日志模块
4. 导出崩溃日志
需要注意的是，Android端的Log可以通过设置Time来找到截取的对应日志内容，但IOS中日志信息较多的情况下，可以在崩溃日志模块中点击修改时间字段并记录好Crash的时间，二者结合很容易找出Crash的日志片断。
扫一扫
2751
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
