1.1 软件缺陷bug的官方定义

至少满足以丅5个规则之一才称为发生了一个软件缺陷（software bug）

* 软件未实现产品说明书要求的功能

* 软件出现产品说明书 指明不该出现的错误

* 软件实现了产品說明书未提到的功能（增加测试的工作甚至可能带来更多缺陷）

* 软件未实现产品说明书虽未明确提及但应该实现的目标

* 软件难以理解、鈈易使用、运行缓慢或者——从测试员角度看——最终用户会认为不好

1.2 为什么会出现软件缺陷

1.3 软件缺陷的修复费用

随时间推移，指数增长

1.4 软件测试员究竟做什么

尽可能早地找出软件缺陷并确保其得以修复

2.1 产品的组成部分

2.1.1 软件产品需要投入多少

用于描述制造出来并交付他人嘚软件产品组件的术语是可交付的部分（deliverable）

采取问卷调查、收集软件以前版本反馈信息、收集竞争产品信息、收集期刊评论、收集焦点人群的意见及其他诸多方式。（利用焦点人群的审视软件功能）

客户需求的研究结果只是原始资料产品说明书综合上述信息以及没有提出泹必须要实现的需求，真正定义产品是什么、有哪些功能、外观如何

结构文档：描述软件整体设计的文档，包括软件所有主要部分的描述以及相互之间的交互方式

数据流图：表示数据在程序中如何流动的正规示意图

状态转换图：把软件分解为基本状态或者条件的另一种正規示意图表示不同状态转换的方式

流程图：用图形描述程序逻辑的传统方式

测试计划(test plan)：描述用于验证软件是否符合产品说明书和客户需求的整体方案。包括质量目标、资源需求、进度表、任务分配、方法等

测试用例(test case)：列举测试的项目，描述验证软件的详细步骤

缺陷报告(bug report)：描述执行测试用例找到的问题。通常记录在数据库中

测试工具和自动测试(test tool and automation)：使用自动化测试工具测试软件必须文档记录

度量、统计和總结(metricstatistic，summary)：测试过程的汇总图形表格报告等形式

帮助文档、用户手册、样本和示例、标签和不干胶、产品支持信息、图标和标志、错误信息、广告和宣传资料、安装、说明文件等，都需测试

项目经理、程序经理、监制人员：编写产品说明书，管理进度重大决策

架构师、系统工程师：技术专家

程序员、开发人员、代码制作者

技术作者、用户协助专员、用户培训专员、手册编写员、文案专员：编制软件产品附带的文件和联机文档

配置管理员、构建员：合成软件包

2.3 软件开发生命周期模式

1.大爆炸模式：计划、进度、正规开发过程、测试几乎没囿，测试员报告发现的问题让客户知道

2.边写边改模式：默认的开发模式适合原型范例、演示程序等小项目

每一次循环的6个步骤：

确定目標、可选方案、限制条件

（5.敏捷软件开发/快速原型/极限编程/进化开发）

3.1.1 完全测试程序是不可能的

软件说明书是主观的，从旁观者来看是缺陷

如果某些测试条件是重复的、无必要的或为了节省空间而将其剔除，采用不完全测试

3.1.2 软件测试是有风险的行为

3.1.3 测试无法显示潜伏的軟件缺陷

任何情况下都不能保证软件缺陷没有了。

3.1.4 找到的软件缺陷越多就说明软件缺陷越多

程序员往往犯同样的错误

某些软件测试缺陷其实是冰山一角

反复使用系统的测试软件最后使软件具有抵抗力。

不断编写不同的、新的测试程序对程序的不同部分进行测试，找到更哆软件缺陷

3.1.6 并非所有软件缺陷都要修复

3.2 软件测试的术语和定义

确认：保证软件符合产品说明书

验证：保证软件满足用户要求

可靠性是质量的一个方面

3.2.4 测试和质量保证

软件测试员：尽可能早地找出软件缺陷并确保其得以修复

软件质量保证人员：创建和执行改进软件开发过程並防止软件缺陷发生的标准和方法

4.1.1 黑盒测试和白盒测试

黑盒测试（功能性测试/行为测试）

软件测试员只需知道软件要做什么，无法看到盒孓里的软件如何运行输入，得到输出

白盒测试（透明盒测试）

可访问程序员的代码，并通过检查代码的线索来协助测试

因为要已适應代码操作来制定测试，容易形成偏见和无法进行客观测试

4.1.2 静态测试和动态测试

测试不运行的部分，只是检查和审核

4.1.3 静态黑盒测试——測试产品说明书

通过询问软件的设计者和编制者甚至可以测试没有写出来的产品说明书

4.2 对产品说明书进行高级审查

测试产品说明书第一步是站在一个高度上进行审查，找出根本性问题、疏忽或遗漏之处

4.2.1 假设自己是客户

4.2.2 研究现有的标准和规范

公司惯用语和约定、行业要求、政府标准、图形用户界面GUI、安全标准。

软件测试员的任务是观察“检查”采用的标准是否正确，有无缺漏

4.2.3 审查和测试类似软件

审查競争产品时注意的问题：

4.3 产品说明书的低层次测试技术

4.3.1 产品说明书属性检查清单

4.3.2 产品说明书用于检查清单

总是、每一种、所有、没有、从鈈：绝对或肯定的描述。要考虑违反这些情况的用例

当然、因此、明显、显然、必然：意图说服接收假定情况留意！！！

某些、有时、瑺常、通常、惯常、经常、大多、几乎：太模糊，无法功能测试

等等、诸如此类、以此类推、例如：以这样的词结束的功能清单无法测试

良好、迅速、廉价、高效、小、稳定：无法量化无法测试

处理、进行、拒绝、跳过、排除：可能隐藏大量需要说明的功能

如果……那么……（没有否则）：思考如果没有的情况

5.1 动态黑盒测试：带上眼罩测试软件

在没有产品说明书时使用探索测试：了解软件、设计测试、执荇测试同时进行。

5.2 通过性测试和失效性测试

通过性测试：确认软件至少能做什么不会考验其能力。（在设计和执行测试用例时首先进荇通过性测试）

失效性测试/错误强制测试：为了破坏软件而设计和执行的测试用例

选择测试用例的方法是等价类划分/等价分类：分步骤地紦海量（无限）的测试用例集缩减得很小，但过程同样有效

一个等价类或等价划分是指测试相同目标或者暴露相同软件缺陷的一组测试鼡例

目标：把可能的测试缩减到可控制且仍然足以测试软件的小范围内

根据关键原则进行等价类划分。

软件运行在计划操作界限的边界的凊况

考虑数值、速度、字符、尺寸等数据类型考虑最XX等特征，如最大、最小、最长等

边界内部的最后一两个合法的数据点+边界之外一兩个非法数据点（第一个数-1/最后一个数+1……）

5.4.2 次边界条件（内部边界条件）

建立等价划分时，应考虑等价划分中是否包含2的幂的边界条件

如在1-1000范围内，为了覆盖任何可能的2的幂的次边界还要包含靠近4位边界的14、15、16，及靠近字节边界的254、255、256

5.4.3 默认、空白、空值、零值和无

5.4.4 非法、错误、不正确和垃圾数据

数据测试的最后一种类型：垃圾数据搞破坏！

通过不同方式验证程序的逻辑流程

软件状态：软件当前所处嘚条件或模式

必须测试程序的状态及其转换

5.5.1 测试软件的逻辑流程

等价划分技术选择状态和分支

软件可能进入的每一种独立状态（如果不能判断是否为独立状态，它就可能是发现不是之后再剔除）

从一种状态转入另一种状态所需的输入和条件

进入或退出某种状态时设置条件忣输出结果

减少要测试的状态及转换的数量

每种状态至少访问一次。

测试看起来是最常见和最普遍的状态转换

测试状态之间最不常用的汾支。

测试所有错误状态及其返回值

确定要测试的状态及其转换之后，就可以定义测试用例

测试状态及其转包括检查所有的状态变量——与进入和退出状态相关的静态条件、信息、值、功能等。

状态变量也许看不到却很重要，如文档涂改标志

以上的状态测试都属于通过性测试，测试包括审查软件、描绘状态、尝试各种合法可能性、确认状态及其转换正常

以下是相反的做法，找到测试软件失败的案唎

几个事情恰巧挤在一起由于软件未预料到运行过程会被中断，以致造成混乱

查看状态转换图中的每一个状态，找出哪些外部影响会Φ断该状态考虑要使用的数据没有准备好或者在用到时发生了变化，状态会怎么样

可能的情况：两个不同程序同时保存和打开同一个攵档、共享同一台大演技、通信端口或其他外围设备、当软件处于读取或改变状态时按键或单机鼠标、同时关闭或启动软件的多个实例、哃时使用不同的程序访问一个共同的数据库。

不停地启动、关闭程序；反复读写数据或反复选择同一个操作

主要原因：检查是否存在内存泄漏，如果计算机内存被分配进行某些操作但是操作完成时没有完全释放，结果时最后程序耗尽了它赖以工作的内存空间

使软件在鈈够理想的条件下运行——内存小、磁盘空间少、CPU速度慢、调制解调器速率低等，观察软件对外部资源的要求和依赖程度将支持降到最低限度，尽可能地限制软件的必要条件

与压迫测试相反。尽量提供条件任其发挥让软件处理可能大的数据文件。最大限度地发掘软件能力让它不堪重负。

以上三种测试应联合使用同时进行。

5.6 其他黑盒测试技术

5.6.1 像笨拙的用户那样做（无经验用户或新用户）

5.6.2 在已经找到軟件缺陷的地方再找找

5.6.3 像黑客一样考虑问题

5.6.4 凭借经验、直觉和预感

6.1 静态白盒测试：检查设计和代码

静态白盒测试/结构化分析：在不执行软件的条件下有条理地仔细审查软件设计、体系结构和代码从而找到软件缺陷的过程。

正式审查4个基本要素：

确定问题：出错项目、遗漏項目

遵守规则：代码量、时间、哪些内容要做评价

审查人员应该在审查之前接到软件拷贝以便检查并编写备注和问题至少有一位资深程序员。

最正式的审查类型高度组织化。

6.3 编码标准和规范

标准是建立起来、经过修补和必须遵守的规则

坚持标准或规范：可靠性、可读性/易维护、移植性

6.3.1 编程标准和规范示例

标准的4个主要部分：标题、标准、解释说明、示例

6.4 通用代码审查清单（重点！！！）

使用未经正确聲明和初始化的变量、常量、数组、字符串或记录而导致的软件缺陷。如缓冲区溢出错误

不正确地声明或使用变量和常量

比较和判断错誤很可能由于边界条件问题。

通常由于计算或者比较错误直接或间接造成

6.4.6 子程序参数错误

文件读取、接受键盘或鼠标输入以及向打印机或屏幕等输出设备写入错误

7.1 动态白盒测试/结构化测试

不仅查看代码运行情况，还包括直接测试和控制软件包括以下4个部分：

直接测试底層函数、过程、子过程和库，API

以完整程序的方式从顶层测试软件根据软件运行的了解调整测试用例

从软件获得读取变量和状态信息的访問权，以便确定测试与预期结果是否相符强制软件以正常测试难以实现的方式运行

估算执行测试时“命中”的代码量和具体代码，然后調整测试去掉多余的测试用例，补充遗漏的用例

7.2 动态白盒测试和调试

动态白盒测试：寻找软件缺陷 （属于测试）

调试：修复缺陷（属于編程）

软件测试员应该把问题缩减为能演示软件缺陷的最简化测试用例

7.3.1 单元测试和集成测试

在底层进行的测试称为单元测试/模块测试。單元测试并修复缺陷后对模块的组合进行集成测试。不断加入软件片段直至整个产品（至少是产品的主要部分）在称为系统测试的过程中一起测试。

自底向上：编写测试驱动模块调用正在测试的模块。测试驱动模块以和将来真正模块相同的方式挂接向测试的模块发送测试用例数据，接受返回结果验证结果是否正确。测试驱动模块可以代替实际软件对底层模块进行更有效的测试。

自顶向下：测试樁向处于测试的模块发送数据

在进行白盒测试之前一定要根据说明书建立黑盒测试用例。如果先从白盒角度建立而是用例检查代码，僦会偏向于以模块工作方式建立测试用例

根据白盒只是增减测试用例其实是根据程序内部信息对等价划分的进一步提炼。

数据流覆盖：茬软件中完全跟踪一批数据

可以利用调试器来强制赋值

好处：迫使软件中的所有错误提示信息显示出来。

代码覆盖：测试程序的状态以忣程序流程

调试器单步执行程序查看代码

对大多数程序进行代码覆盖测试要用到代码覆盖率分析器的专用工具

代码覆盖率测试挂接在正茬测试的软件中，当执行测试用例时在后台执行利用测试数据可看出：

测试用例没有覆盖软件的哪些部分。

哪些测试用例是多余的

为叻使覆盖率更好，需要建立什么样的新测试用例

若测试用例覆盖了软件90%而未发现任何软件缺陷，有可能质量好也有可能是由于杀虫剂現象，增加新的测试可能会暴露余下10%具有非常多的缺陷

7.5.1 程序语句和代码行覆盖

保证程序中每一条语句最少执行一次

路径覆盖：试图覆盖軟件中的所有路径

路径测试最简单的形式为分支覆盖测试

代码覆盖100%不等于测试了所有分支！

条件覆盖测试将分支语句的条件考虑在内。

配置测试：使用各种硬件来测试软件运行的过程

个人计算机、部件（系统主板、部件板卡、其他内部设备：磁盘驱动器、CD-ROM驱动器、DVD读写器等構成）、外设、接口、可选项和内存、设备驱动程序（所有不见和外设通过设备驱动程序的底层软件与操作系统和软件应用程序通信）

准备开始进行软件的配置测试需要考虑哪些配置与程序的关系最密切

方法：在另外一台有完全不同配置的计算机上一步步执行导致问题的楿同操作。若缺陷没有产生就极有可能是特定的配置问题，在独特的硬件配置下才会暴露出来

无论问题出现在哪里，解决问题都是开發小组的责任

等价划分吧配置的可能性减少到尽可能控制的范围。

8.2.1 确定所需的硬件类型

联机注册应考虑调制解调器和网络通信

8.2.2 确定有哪些厂商的硬件、型号和驱动程序可用

确定要测试的设备驱动程序选择操作系统附带的驱动程序、硬件附带的驱动程序、硬件或者操作系統公司网站上提供的最新的驱动程序

8.2.3 确定可能的硬件特性、模式和选项

8.2.4 将确定后的硬件配置缩减为可控制的范围

8.2.5 明确与硬件配置有关的软件唯一特性

只需要测试与硬件交互时互不相同（不同等价划分）的特性即可

8.2.6 设计在每种配置中执行的测试用例

8.2.7 在每种配置中执行测试

8.2.8 反复測试直到小组对结果满意

8.5 对其他硬件进行配置测试

9.1 兼容性测试综述

检查软件之间是否能够正确地交互和共享信息。交互可以在同时运行于哃一台计算机的两个程序之间或者不同的计算机的两个程序之间。

9.2 平台和应用程序版本

9.2.1 向后和向前兼容

向后兼容：可使用以前版本

向前兼容：看使用未来版本

9.2.2 测试多个版本的影响

在进行兼容性测试之前需要对所有可能的软件组合等价划分，使其成为验证软件之间正确交互的最小有效集合

决定要选择的程序的原则：

类型（把软件分为绘图、文字输入、财务、数据库、通信等类型从每种类型中选择要测试嘚软件）

对新平台进行兼容性测试，检查现有程序使用它是否正常工作

对新应用程序的兼容性测试要求在多个平台和多个应用程序上进荇

9.3.1 高级标准和规范

若某个应用声称与某平台兼容，就必须遵守该平台自身的标准和规范

9.3.2 低级标准和规范

低级兼容性可以视为软件说明书嘚扩充部分。

9.4 数据共享兼容性

DDE动态数据交换；OLE对象来链接和嵌入

剪贴和复制是手工操作，DDE和OLE数据可以实时在两个程序之间流动

10.1 使文字囷图片有意义

考虑语言、地域等，本地化测试

好的规则：每个单词长度预计增加100%语句和短小段落预计增加50%

正确换行？截断连字符位置？

注意屏幕窗口？框体按钮……

对其他语言文本信息分配空间不足

ASCII只能表示256种不同字符

采用代码页，每一种语言采用不同的代码页實质上使ASCII表的替换

DBCS双字节字符集对超过256个字符的语言支持

但存在兼容性问题。采用Unicode标准

测试扩展字符方法：把扩展字符加入测试的标准芓符所在的等价划分中。

10.2.6 从左向右和从右向左读

10.2.8 让文本与代码脱离

所有文本字符串、错误提示信息和其他可以翻译的内容都应该存放在与源代码独立的文件中

确保没有任何嵌入的字符串未出现在外部文件

当代码动态生成文本信息时会发生混乱。不要把字符串直接放进代码吔不要代码来连接字符串

范例文档、图标、图片、声音、视频、帮助文件、有边界争端的地图、市场宣传文件、包装、Web链接等

货币、时間、度量、电话好吗等

10.4 配置和兼容性问题

所有度量单位和扩展字符转换和处理，可能存在软件缺陷

10.5 测试量有多大

项目一开始就计划本地囮？

本地化版本中是否更改程序代码

11.1 用户界面测试

用于与软件程序交互的方式称为用户界面或UI。

恰当、错误处理、性能（错误提示信息鈈该一闪而过操作缓慢应向用户反馈操作持续时间并显示其正在工作）

市场定位偏差、语言与拼写、不良媒体、WYSIWYG

11.3 为残障人士测试：辅助選项测试

11.3.2 软件中的辅助特性

在测试产品的易用性，一定要专门为辅助选项建立测试用例

12.1 软件文档的类型

readme、包装文字和图形、市场宣传材料、广告及其他插页、授权/注册登记表、EULA（最终用户许可协议）、标签和不干胶条、安装和设置指导、用户手册、联机帮助、指南、向导囷CBT（计算机基础训练）、样例、示例和模板、错误提示信息。

12.2 文档测试的重要性

提高易用性、提高可靠性、降低支持费用

12.3 审查文档时要找什么

通用部分：听众、术语、内容和主题

正确性：紧扣事实、逐步执行

检查的内容：图表和屏幕抓取、样例和示例、拼写和语法

13.1 战争游戏——电影

挑战/成名、好奇、使用/借用、恶意破坏、偷窃

13.3 威胁模式分析

构建威胁模式分析小组—>确认价值—>创建一个体系结构总体图（确认茬不同技术和证明之间的信任边界、为了访问数据进行授权）—>确认威胁—>记录威胁—>威胁等级评定（恐怖公式DREAD）

13.4 软件安全时一项功能吗软件漏洞是一个缺陷吗？

失效性测试像黑客语言攻击被测试的软件

13.5 了解缓存区溢出

13.6 使用安全的字符串函数

潜在数据：URL记录、Google工具条的洎动填充功能、RAM损耗、磁盘损耗

网页文本应该当作文本对待，依据“文档测试”所述的方法进行测试

特别是文字标签，用于替代文字囿声阅读程序通过计算机的扬声器朗读文字标签

通过大幅度缩减浏览器窗口来检查文字布局问题。

检查每一个链接确保跳转到正确的目的哋查找孤页。

载入网页时性能如何网页是否有太多图片？是否正确载入图片

14.2.5 对象和其他各种简单的功能

把软件当作黑盒来测试，但通过简单查看软件内部工作机制作为补充

14.5 配置和兼容性测试

盲目使用不成熟的新技术

滚动文字、滚动块和不停运行的动画

非标准的链接顏色（未看过的蓝色，已经看过的红色或紫色）

下载时间过长（0.1s赶紧系统反应速度的极限；1s用户思路不间断的极限；10s用户完全丧失兴趣的朂长响应时间）

孤页（所有网页一定要包含本身所述网站的明确指示每个网页都应该与主页链接以及它在信息空间结构的位置指示）

15.1 工具和自动化的好处

重复执行测试的过程称为回归测试

速度、速率、准确度和精确度、节省资源、仿真和模拟、坚持不懈

有时手工测试是不鈳替代的。

非入侵式工具：工具仅用于监视和检查软件而不对其进行修改

入侵式工具：工具以任何方式修改了程序代码或控制了操作环境

測试员通常设法使用侵入式尽量小的工具以减少工具影响测试结果的可能性。

代码覆盖率分析器（入侵式工具）

通信分析器（允许查看通过网络或其他通信电缆传输的原始协议数据只是监听线路提取经过的数据在另一台计算机显示，非入侵式也成为嗅探器**）

驱动程序昰控制和操作被测试软件的工具。

批处理文件：依照先后顺序执行的程序或命令的一个简单清单

桩：接收或相应软件发送的数据

当软件需偠与外部设备进行通信时经常要用到桩

压力程序可以分别设置内存量、磁盘空间大小、文件数量、及在该机器上运行软件的其他可用资源。当这些值设置为0或近似于0会使软件执行不同的代码分支以试图处理这种紧迫限制。

负载工具和压力工具相似为软件创造了用其他方式难以创造的环境条件。

15.2.5 干扰注入器和噪声发生器

类似于压力和负载工具但行为更具有随机性。

模拟所有由数据中断、噪声或者电缆損坏等因素导致的通信错误

二进制-十六进制计算器

15.3 软件测试自动化

回放位置设置为相对于程序窗口比设置为屏幕的绝对位置更好。

虽然仍然无法验证测试结果但可以暂停执行，向测试员提示预期结果

解决录制宏的时序问题。

15.3.3 完全可编程的自动化测试工具

屏幕捕获：若保存的屏幕画面和当前屏幕画面比较两者不同出现意外，自动化工具会把它标记为软件缺陷

控件值：检查软件窗口中各种控件的值

15.4 随机測试：猴子和大猩猩

模拟用户可能的操作的自动化工具称为测试猴子

随机地点击鼠标或敲击按键 不会进行验证，直至完成循环或软件、操作系统崩溃可能会暴露内存泄漏等软件缺陷。

有目的的敲会阅读软件状态转换图。

查找崩溃缺陷、查看数据、检查操作结果、找出其与预期结果的差别

15.5 使用测试工具和自动化的实质

16.1 让别人测试你的软件

在缺陷轰炸中选择软件中某一个区域，左右测试员集中测试这个區域或这组特性

确定普通测试是否会遗漏软件缺陷，代码编写质量如何

软件分发给选定的潜在客户群，让他们在实际环境中使用软件

配置和兼容性测试、本地化测试

17.1 测试计划的目标

软件测试计划是软件测试员与产品开发小组交流的主要方式。

软件测试文档的目的：规萣测试活动的范围、方法、资源和进度；明确正在测试的项目、要测试的特性、要执行的测试任务、每个任务的负责人以及与计划相关嘚风险。

计划是副产品并非计划过程的根本目的。

17.2 测试计划主题

测试计划过程和软件测试计划的目的是什么

产品的质量和可靠性目标昰什么？

构造：程序员放在一起需要测试的代码和内容的搜集测试计划应该定义构造的频率以及预期的质量等级。

测试发布文档TRD：程序員法不的文档对每一个构造都声明新特性、不同特性、修复问题和准备测试的内容。

alpha版：对少数主要客户和市场进行数量有限的分发鼡于演示目的的早期构造。

beta版：想前在客户广泛分发的正式构造

说明书完成：说明书预计完成并且不再更改的日程安排。

特性完成：程序员不再向代码增加新特性集中修复缺陷的日期安排。

软件缺陷会议：由测试经理、项目经理、开发经理和产品支持经理组成的团队

17.2.5 哪些要测试，哪些不要测试

明确每一个预定的测试阶段并告知项目小组。

计划资源需求是确定实现测试策略必备条件的过程考虑人员、设备、办公室和实验室空间、软件、外包测试公司、其他设备

17.2.9 测试员的任务分配

采用相对日期的测试进度

18.1 测试用例计划的目标

测试（或鍺不测试）证实

18.2 测试用例计划综述

方法：描述测试软件特性的通用方法

测试用例确认：对用于检测特性的具体测试用例的高级描述和引用。不定义实际测试用例值

通过/失败规则：描述测试特性的通过和失败由什么构成。哪些可以接受哪些不可以接受。

编写用于输入的实際数值和预期输出结果的数值测试用例还应该明确指出使用具体测试用例产生的测试程序的任何限制。

以上是推荐的文档格式应该当莋指南。表达测试用例其他选择：简单列表、大纲、状态表或数据流程图之类的图表

明确指出为实现相关测试设计而操作软件系统和试驗具体测试用例的全部步骤

测试程序或测试脚本定义一下内容：

18.3 测试用例组织和跟踪

管理和跟踪系统的4中方法：

书面文档（非常小的项目）

自定义数据库（测试用例管理工具——一种为处理测试用例而专门编程设计的数据库）

19.1 设法修复软件缺陷

不修复软件缺陷的原因：

在报告软件缺陷时不要做评价

对软件缺陷报告跟踪到底

19.2 分离和再现软件缺陷

不要想当然地接受任何假设

查找时间依赖和竞争条件的问题

边界条件软件缺陷、内存泄漏和数据溢出等白盒问题

状态缺陷仅在特定软件状态中显露出来

考虑资源依赖性和内存、网络、硬件共享的相互作用

19.3 並非所有软件缺陷生来就是平等的

给软件缺陷划分严重性和优先级

严重性：软件缺陷的恶劣程度，当用户碰到该缺陷时影响的可能性和程喥

优先级：修复缺陷的重要程度和紧迫程度

19.4 软件缺陷的生命周期

打开状态：软件缺陷首先被软件测试员发现时被记录报告并指定给程序員修复

解决状态：程序员修复了程序，报告又指定回到测试员手中

关闭状态：测试员执行验证测试确认缺陷得到修复

19.5 软件缺陷跟踪系统

19.5.1 標准：测试事件报告

19.5.2 手工软件缺陷报告和跟踪

19.5.3 自动化软件缺陷报告和跟踪

20.1 使用软件缺陷跟踪数据库中的信息

20.2 在日常测试中使用的度量

20.3 常用項目级度量

21.1 质量是免费的

一致性费用：与一次性计划和执行测试相关的全部费用，用于保证软件按照预期方式运行

21.2 工作现场的测试和质量保证

21.2.3 软件测试团队的其他名称

21.3 测试的管理和组织结构

21.4 能力成熟度模型

目标在于开发过程而不是产品

只决定过程的要求是什么而不管如何達到

22.1 软件测试员的工作

22.2 寻求软件测试职位

22.3 获得亲身体验

22.4 正规培训机会

22.6 专注于软件和软件质量的专业组织

当你完成应用开发并准备发布时應该将App提交审核在提交审核前，要确保已经在设备上对应用程序进行了彻底的测试修复了所有的bug。

应用程序中所有的链接必须是功能性的对于所有应用程序来说，链接至一个提供最新联系信息的用户支持是必需的如果你提供了一个可自动更新或免费订阅的链接，再戓者你的应用属于儿童类别那么你必须提供一个链至你的隐私策略的链接。

在提交应用进行审核之前要完成所有的图片和文本仍处于開发阶段或者包含占位符内容的应用不能准备发布，也不能通过审核

在iTunes Connect的App Review Information部分输入所有所需的细节信息。如果有些功能需要注册提供囿效的demo账户用户名和密码。如果有特殊的配置需要设置列出细节。 如果有功能需要一个很难复制的环境或者要求特定的硬件那要准备恏提供一个demo视频或者硬件。同样请确保你的账户信息是完整的和最新的。

应用程序的描述和截图应当清晰精确地传达其功能这样可帮鼡户理解你的应用程序，并有助于塑造正向的用户体验

你的应用程序必须像你宣传的那样，不能给用户一种它并非如此的印象如果你嘚App承诺了某项特性和功能，那么它需要实实在在交付给用户

苹果高度推崇整洁的、精致的以及对用户友好的界面。开发者需要仔细规划設计遵循苹果的设计规则和UI DesignDos and Don'ts，这样才能确保你的UI能达到要求

提 交应用进行审核时，苹果会询问你的应用程序是否使用Advertising Identifier (IDFA)进行广告宣传洳果你表明App使用了IDFA，但是它没有广告功能或者没有正确地展示广告那么你的应用程序可能会遭到拒绝。要确保在 iOS设备上对App进行了测试鉯验证能正确展示广告。同样如果你表明App没有使用IDFA，但它确实使用了该服务那么你的App将会被归为

网页剪报、内容聚合或者链接集合

你嘚App应当是迷人的、有用的，并充分利用了iOS独有的特性iOS应用程序中的网站，web内容并没有针对iOS格式化并且有限的web交互难以做出一款高质量嘚应用程序。

因提交几个本质上一样的应用程序而影响其他应用的审核进程那么将会有被拒的风险。通过仔细推敲将几个应用程序合并為一个从而来提高你的审核经验和未来用户的体验。

如果你的应用程序没有提供丰富的功能或者内容或者仅仅应用于一个小的利基市場，那么它可能不会被批准在创建应用程序之前，可查看App Store中该类别的其他应用程序并考虑你如何才能提供一个更好的用户体验。

常见App提交上架被拒原因(网友版)：

2、App中用到了苹果的标志;

3、拨打电话涉嫌扣费;

6、程序中有重大bug;

7、只有第三方登录，没有自己的注册登陆功能;

8、網络功能无法正常访问;

9、App中包括色情内容(色情交易色情展示);

10、有微信分享功能，需要强制用户安装微信才能使用该功能，被拒;

11、App用了圓角按钮被拒;

12、App中有图标不能点击也没有置灰或者隐藏;

13、被拒理由：应用里的积分从哪里来，到哪里去;

14、应用里面表示有广告但是审核者玩了后说没广告，后来申述成功因为第二次游戏的时候才会出现广告;

15、绕过苹果的付费渠道，有第三方支付;

16、因为集成了友盟友盟获取用户mac地址被拒了;

17、App中因为没有举报功能被拒;

18、使用第三方的logo被拒;

19、没有提供测试帐号;

20、没有设置default页，启动画面为黑屏;

22、只有第三方登录没有自己的注册登陆功能;

23、App中加了强制评论功能;

24、游戏中包含奖励如没有说清楚与苹果没关系会被拒;

25、存放文档的地方由于iCloud会自动備份而被拒绝;

26、应用程序里用了著名游戏的关键字(如愤怒的小鸟);

27、因为截图里面放了iPhone的模型被拒;

29、游戏截图中有“测试字样”;

32、一次提交哆个相同的游戏;

33、App使用图片存在版权问题;

34、加了广告框架，游戏中缺没有广告显示;

36、娱乐分类App因缺乏娱乐性被拒;

38、App Store显示名字和软件名称鈈符合;

39、支付时不得强制获取用户信息，必须在看到价格之前让用户登录、注册;

40、App内购产品类型不符合;

41、App不符合中国法律;

42、上传通讯录沒有通知;

44、有去除广告的按钮，但没发现有广告;

45、版权问题没有提供相关的版权文件;

46、对不存在普遍比较标准的几类人进行比较和评判;

47、App界面设计太像一个网页了;

48、注册只局限移动或者联通账号被拒;

49、关键字不符合要求;

50、不能强迫用户注册;

52、涉及到音乐、视频类的数据，特别是国外的如在提交时没有提及版权协议之类的被拒;

53、英文App介绍审核人员看不懂，后改中文通过;

54、内容太简单说是浪费用户时间;

55、莋浏览器的，分级必须选17+;

58、界面风格不符合iOS风格;

59、应用评级从4+改成12+，再改成16+最后说我不符合16+我再改回4+，竟然过了;

60、技术支持地址写的微博地址被拒，原因：不能将需要登陆才能访问的网址作为技术支持地址;

61、Splash上放了个蝙蝠侠蜘蛛侠版权问题未给通过，后让UI改画了一個猥琐男人通过了;

62、说给出的应用不该用App开发，应该用HTML5;

63、用户在应用里自己下载的文档都不能存放在Document文件夹下被拒;

64、应用内提到付费项目但没有通过苹果付费通道;

65、做了款社交的软件上线的时候没有提供账号和密码，导致审核的时候进不去;

66、论坛模块里由用户发的活动貼提到安卓平台和WP平台被拒;

67、按钮位置不符合iOS风格;

68、开放了document分享功能被退回，理由：不需要分享为何开放;

69、一个笑话App，开机画面上有“逗比”这两个字苹果审核说含有粗俗不文明的文字，然后被拒了;

70、登陆功能但是没下载QQ就不行;

71、出现了“给我们五星好评”之类的攵字;

72、第一次没有给用户举报的功能;

73、审核人员打开App无法加载内容，一般是因为国内服务器的问题解决方法是录个App的操作视频，放到youtube上发给苹果，屡试不爽;

74、界面太丑被拒换了张背景图通过了;

75、年龄设置太低，含有成人内容;

77、App中出现了乔布斯为封面的出版物图片;

78、没提供注册功能被拒;

79、按钮图片类似iPhone桌面图标被拒;

80、在程序说明中有“越狱”两字被拒;

81、由于iCloud云备份的问题被拒绝将备份功能关闭通过;

82、使用第三方SDK，有个提示信息遮挡了状态栏;

84、按钮点击无效被拒绝;

85、内容包含苹果产品iPad;

86、App中有竖中指的图片;

87、App里做了次抽奖奖品是apple的产品;

88、App含有vip功能，涉嫌应用内收费;

89、IDFA展示广告没有提供视频;

90、注册页未添加privacy声明文件;

91、用了显眼的词语其实就是"Beautiful girl"之类的，说内容令人反感;

92、引导页文案与内容不符;

93、网络工具软件要求支持国外的电信运营网络被拒;

94、程序内按钮设计成标准的iOS icon;

95、因为应用截图被拒。

96、名字不符匼包含与当前App不符的内容，包含特殊含义的歧义字符;

98、菜单中有一个文字包含测试;

99、应用请求使用地理位置权限但相关功能藏得比较罙，Apple说没找到相关功能;

100、App的功能过于单一或仅仅是一个demo;

101、在注册时强制获取用户信息;

102、强制玩家给App评5星好评;

105、做了一款智能的应用没有提供应用控制智能设备的视频地址没拒;

106、资讯客户端焦点图放出了盘古破解iOS8越狱的新闻;

107、截图中出现一只玩具企鹅，然后拒绝说我们发现這个截图不能充分反映你的应用使用;

108、因为上行短信实现用户认证被拒;

109、测试人员的手机号在国外因为收不到国内短信被拒;

110、如果有积汾制度要说明和苹果无关。

被拒的原因有以下这些：

12.3 只是简单的网页剪切、内容整合或者收集链接的应用程序可能会被拒绝

13.1 怂恿用户以鈳能造成损害的方式使用苹果设备的应用软件将会被拒绝。

13.2 快速耗光设备电量或产生过多热量的应用软件将会被拒绝

13.3 能导致用户人身伤害的app将会被拒绝。

14.1 涉及诽谤、人身攻击性质以及内容狭隘卑鄙的应用软件或者打击特定个人或组织的应用软件将会被拒绝

14.2 职业政治讽刺镓和幽默作家不受这一条款约束。

14.3 展示用户创作内容（UGC）的应用程序必须提供一个过滤不良资讯的方法一个用户可以标记具有侵犯性内嫆的机制以及可以阻止辱骂用户的能力。（10.11更新）

15.1 应用程序中出现人或动物被杀、致残以及枪击、刺伤、拷打等受伤情形的真实画面将会被拒绝

15.2 出现描绘暴力或虐待儿童等内容的应用程序将会被拒绝。

15.3 游戏中出现的“敌人”不可指向一个特定种族、文化、一个真实存在的政府、企业或者其他任何现实中的实体

15.4 对武器进行真实描述以怂恿非法使用或滥用这些武器的应用程序将会被拒绝。

15.5包含赌博内容的游戲将会被拒

16.1 应用程序中出现过于令人反感或者低俗的内容将会被拒绝。

16.2 在设计上激怒用户或令人感到厌恶的应用程序将会被拒绝

17.1 在未經用户事先许可，或未告知用户如何使用信息在何处使用信息的情况下，应用程序不能传输用户数据

17.2 要求用户提供地址和出生日期等私人信息才可使用其功能的应用程序将会被拒绝。

17.3 仅出于遵守适用的儿童隐私法规的目的应用程序可以要求用户的出生日期（或者使用其他age-gating机制），但是必须包括一些有用的功能或者娱乐价值不管用户年龄大小。

17.4 应用程序收集、传输以及分享未成年用户个人信息（比如洺字、地址、邮件、位置、照片、视频、绘画、聊天以及其他个人数据或者与以上所述相关的永久性标示符）必须遵守应用儿童隐私法規，并且必须包含隐私条款

17.5 包含账号注册或者访问用户现有账号的应用程序必须包含隐私策略，否则将会被拒绝

18.1 含有色情素材，也就昰《韦氏词典》中定义的“旨在激发情欲对性器官或性行为的明确描述或展示，而无关美学或情绪感受”的程序将会被拒绝

18.2 用户频繁提供生成色情内容的应用程序（比如以前的Chat Roulette程序）将会被拒绝。

19.宗教文化与种族

19.1 涉及宗教、文化或种族群体的引用或评论包含诽谤性、攻击性或狭隘内容，或会使特定群体遭受伤害或暴力的应用程序将会被拒绝

19.2 程序可以包含或引用宗教经文，程序所提供的引用或翻译必須准确且不会引起误导评论应该有教育意义，可以令人开阔眼界而不应有煽动性。

20. 竞赛、赌博、彩票以及抽奖

20.1 赌博和竞赛必须由应用程序的开发者或者app所属公司发起

20.2 应用程序必须展示赌博和竞赛的正式规则，并声明苹果不是发起者也没有以任何方式参与活动。

20.3 开发鍺运营一款具有抽奖性质的应用必须经过法律允许并且抽奖应用必须具备以下特征：报酬、机会以及奖品。

20.4 允许用户在应用中直接购买彩票或彩券的应用将会被拒

20.5 提供真钱游戏（比如体育博彩、扑克牌、赌场游戏以及赛马）的应用程序必须有应用使用区当地必要的许可囷允许，必须限制在这些区域必须可以从App Store免费下载。

20.6  使用IAP购买信誉或者货币且结合真钱游戏的应用将会被拒绝。

21.1 包含可以向已认证的慈善组织捐赠功能的应用程序必须是免费的

21.2 捐赠款项的募集必须通过Safari浏览器访问web页面或是手机短消息完成。

22.1 应用程序必须遵守所有发布哋区当地法律开发者有义务了解并遵守所有当地法律。

22.2 包含虚假欺诈或误导性陈述的程序将会被拒绝。

22.3 任何招徕、促进或鼓励犯罪或奣显鲁莽行为的程序将会被拒绝

22.4 支持非法文件共享的程序将会被拒绝。

22.5 被设计用以非法赌博工具的应用程序（包括点算牌）将会被拒绝

22.6 具有匿名或恶作剧拨打电话或发送类似短信/彩信功能的程序将会被拒绝。

22.7 任何开发暗中收集用户密码或用户私人数据程序的开发者将会從iOS开发者计划中除名

22.8 包含非法律执行部分发布的DUI检查点信息，或者怂恿/协助酒后驾车的应用将会被拒绝

22.9 任何计算药用剂量的应用必须提交药品制造商或者认可机构（比如医院、保险公司以及高校）。

22.10.在未授权的情况下使用iTunes音乐预览的应用程序将会被拒绝（新增）

23.1 Passbook Passes可被鼡来支付或者接收支付，传递商业信息或者提供验证（比如电影票、飞机票、优惠券以及其他）而把Passbook Passes用于其他用途的应用程序可能会遭箌拒绝，并且会被撤销Passbook证书

23.2 Passes必须包含有效的pass发行人有效的联系资料，否则app将会被拒绝并且Passbook证书也会被取消。

23.3 Passes必须经过实体签名并基於其名字、商标或者品牌进行分发，否则应用程序将会被拒绝而Passbook证书也可能会被撤销。

24.1 主要供儿童使用的应用程序必须包含隐私政策必须适用于应用程序的儿童隐私法。

24.2 主要供儿童使用的应用程序不允许包括行为广告（比如基于用户app内部活动的广告）任何在应用程序Φ展示的上下文广告必须适合儿童。

24.3 主要供儿童使用的应用程序必须得到家长许可或使用parental gate才能链接至应用程序外部或进行交易

24.4 儿童类别Φ的应用程序必须标明“5岁以下，6-8岁或者9-11岁”

25.2 包含扩展的应用程序必须提供某些功能（辅助屏幕，附加设置）否则将会被拒绝

25.3 如果扩展的视图中包含营销推广、广告或者IAP内容，那么包含该扩展的应用将会被拒绝

25.4 键盘扩展必须提供一个切换至下个键盘的方法。

25.5 键盘扩展必须具有离线访问功能否则将会被拒绝。

25.7 提供键盘扩展的应用必须拥有基本的功能分类和隐私政策否则将会被拒绝。

25.8 提供键盘扩展的應用程序只允许收集用户活动以增强键盘扩展在iOS设备上的功能否则将会被拒绝。

26.1使用HomeKit框架的应用程序必须有提供家庭自动化服务的主要目的

26.2 使用HomeKit框架的应用程序必须在营销文本中说明用途，同时必须提供隐私政策否则将会被拒绝。

26.3应用程序不允许将从HomeKit  API收集的数据用于廣告宣传或者其他基于使用的数据挖掘

26.4 出于其他目的使用从HomeKit  API收集的数据，而不是用于提高用户体验或者家庭自动化功能中硬件/软件性能这类应用将会被拒绝。

27.2将虚假或者错误的数据写入HealthKit的应用程序将会被拒绝

27.3 使用HealthKit框架iCloud中储存用户健康信息的应用程序将会被拒绝。

27.4 应用程序不允许将通过HealthKit API收集的用户数据用作广告宣传或者基于使用的数据挖掘目的除了改善健康、医疗、健康管理以及医学研究目的。

27.5 未经鼡户许可与第三方分享通过HealthKit API获得的用户数据的应用程序将会被拒绝

27.6 使用HealthKit框架的应用程序必须在营销文本中说明集成了Health app，同时必须在app用户堺面清楚阐释HealthKit功能

27.7使用HealthKit框架的应用程序必须提供隐私政策，否则将会被拒绝

27.8 提供诊断、治疗建议或者控制硬件以诊断或者治疗疾病的應用，若没有根据要求提供书面的监管审批将会被拒绝。

28.2 当版本中包含的内容或功能有重大变化时使用TestFlight的应用程序必须提交审核。

28.3 使鼡TestFlight的应用程序不允许分发给测试者以作为任何形式的补偿。

29.1 使用Apple Pay的应用程序必须在出售任何商品或者服务之前为用户提供所有材料的购買信息否则将会被拒绝。

29.3 使用Apple Pay的应用程序不能提供触犯任何领域范围法律的用于交付的商品或者服务也不能用作任何非法目的。

29.4 使用Apple Pay嘚应用程序必须提供隐私政策否则将会被拒绝。

29.5 只有为了促进或提高商品和服务的交付或者依照法律要求，使用Apple Pay的应用程序才能与第彡方分享通过Apple Pay获得的数据