1. 测试用例

1.1 测试用例前提

• 什么是测试用例？

一组由前提条件、测试输入、执行条件以及预期结果等组成，以完成对某个特定需求或者目标测试的数据，体现测试方案、方法、技术和策略的文档。

• 为什么编写测试用例

（1）深入了解需求的过程：一个项目立项开始，测试就开始介入，我们从产品的需求文档、原型图，效果图等相关文档去熟悉产品的各个模块，各个业务流程。或者在产品规划和设计阶段，测试开始熟悉产品。而编写用例的过程中，会充分的思考产品需求的细枝末节，需求的不合理、有矛盾、不明确的地方，还能对产品提出更好的建议，监督产品对需求做出更加详细的设计。整个过程是对需求深入了解的过程，产品的整个印象都在测试脑海里。 （2）测试执行的指导：用例编写是把产品需求转换为一种可操作步骤的行为，方便以后作为测试的标准，有步骤有计划的进行测试。如果没有这个标准，会使你的测试过程无计划，无目标，变成一个放任主流的状态，完全没有受控性。这样的产品质量保证显然是空谈。 （3）规划测试数据的准备：在我们的实践中测试数据是与测试用例分离的。按照测试用例配套准备一组或若干组测试原始数据，以及标准测试结果。尤其象测试报表之类数据集的正确性，按照测试用例规划准备测试数据是十分必须的。除正常数据之外，还必须根据测试用例设计大量边缘数据和错误数据。 （4）反应测试进度：测试人员开始按照测试用例的描述测试，每过完一个用例标记完成；这样测试也知道自己做过哪些操作，避免没有目的随机测试。并且通过测试用例的执行条数，大致了解该模块的测试进度。 （5）举一反三发现潜藏缺陷：测试人员开始按照测试用例的描述测试，每过完一个用例标记完成；这样测试也知道自己做过哪些操作，避免没有目的随机测试。并且通过测试用例的执行条数，大致了解该模块的测试进度。 （5）分析缺陷的标准*：通过收集缺陷，对比测试用例和缺陷数据库，分析确认是漏测还是缺陷复现。漏测反映了测试用例的不完善，应立即补充相应测试用例，最终达到逐步完善软件质量。而已有相应测试用例，则反映实施测试或变更处理存在问题。

1.2 测试用例定义

• IEEE 标准的定义:使用人工或自动的手段来运行或测定某个系统的过程，其目的在于检验;它是否满足规定的需求或是弄清预期结果与实际结果之间的差别。
• G.J.Myers给出的定义:“程序测试是为了发现错误而执行程序的过程”。这个定义被软件测试业界所认可，并经常被引用。

1.3 目的和意义

（1）测试是完善程序的过程，目的在于使系统更加符合用户的使用习惯，让系统在上线后带给客户极高的用户体验； （2）测试应致力于发现至今为止未发现的错误 （3）以最少的时间和人力，系统地找出软件中潜在的各种错误和缺陷； （4）证明软件的功能和性能与需求说明项符合； （5）通过测试的结果数据为软件的可靠性分析提供分析

1.4 测试分类

（1）静态测试：通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性。对需求规格说明书、软件设计说明书、源程序做结构分析、流程图分析、符号执行来找错。可以借助代码扫描工具以及经验丰富的开发人员组织代码检查等。 （1.1）静态测试检查项：代码风格和规则审核；程序设计和结构的审核；业务逻辑的审核；走查、审查与技术复审手册。 （2）动态测试：指被测代码在相对真实环境下运行，从多角度观察程序运行时能体现的功能、逻辑、行为、结构等行为，以发现其中的错误现象。动态测试的主要测试方法以黑盒测试和白盒测试为主。 （3）手工测试：就是由人去一个一个的输入用例，然后观察结果，和机器测试相对应，属于比较原始但是必须的一个步骤。 优点：自动化无法替代探索性测试、发散思维类无既定结果的测试。 缺点：执行效率慢，量大易错。 （4）自动化测试：就是在预设条件下运行系统或应用程序，评估运行结果，预先条件应包括正常条件和异常条件。简单说自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。 自动化测试有功能测试自动化、接口自动化、性能测试自动化、安全测试自动化。 （5）白盒测试：白盒测试又称结构测试、透明盒测试、逻辑驱动测试或基于代码的测试。白盒指的打开盒子，去研究里面的源代码和程序结果 白盒测试也可以分为静态测试和动态测试。 （6）黑盒测试：黑盒测试也称功能测试，测试中把被测的软件当成一个黑盒子，不关心盒子的内部结构是什么，只关心软件的输入数据与输出数据。 （7）灰盒测试：是介于白盒测试与黑盒测试之间的一种测试，灰盒测试多用于集成测试阶段，不仅关注输出、输入的正确性，同时也关注程序内部的情况。 （8）冒烟测试：就是开发人员在个人版本的软件上执行目前的冒烟测试项目，确定新的程序代码不出故障。现基本执行对象为测试人员，在正规测试一个新版本之前，投入较少的人力和时间验证基本功能，通过则测试准入。 （9）随机测试：随机测试主要是根据测试者的经验对软件进行功能和性能抽查。随机测试主要是对被测软件的一些重要功能进行复测，也包括测试那些当前的测试用例(TestCase)没有覆盖到的部分。 （10）回归测试：回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。自动回归测试将大幅降低系统测试、维护升级等阶段的成本。 （11）安全测试：是在IT软件产品的生命周期中，特别是产品开发基本完成到发布阶段，对产品进行检验以验证产品符合安全需求定义和产品质量标准的过程 。 （12）α测试 ：α测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试。α测试的目的是评价软件产品的FLURPS(即功能、局域化、可使用性、可靠性、性能和支持)。 （13）β测试：Beta测试是一种验收测试。Beta测试由软件的最终用户们在一个或多个客房场所进行。

1.5 测试原则

• 所有软件测试都应追溯到用户需求。
• 应当把“尽早地和不断地进行软件测试”作为软件测试人员的座右铭。
• 完全测试是不可能的，测试需要终止，原因数据输入量太对、路径组合太多、输出结果太多。
• 程序员应避免检查自己的程序，测试无法显示软件潜在的缺陷，进行测试以查找缺陷，但不能保证所有的缺陷都被找到。
• 充分注意测试中的群集现象，在所测程序中，若发现错误数目多，则残存误数目也比较多，这种就是错误集群现象。
• 软件测试是有计划的，严格执行测试计划，排除测试的随意性。
• 应当对每一个测试结果做全面检查，妥善保存测试计划，测试用例，缺陷统计和最终测试分析报告，为维护提供方便。

1.6 测试策略

• 测试阶段：单元测试、集成测试、系统测试、回归测试
• 测试范围：单元测试中的测试模块实现基本的逻辑功能，没有重大逻辑错误；集成测试接口实现联调完成，接口数据流是通的；系统测试完成功能点的测试，功能是否满足需求；回归测试在漏洞修复完成是否产生其他新问题，功能需要重新覆盖完成。
• 测试方法：使用自动化测试还是手动测试，是否考虑性能或兼容性测试等
• 测试环境：环境解决方案、操作系统、软硬件
• 开始标准：开发自测完成
• 完成标准：需求文档上的功能是否完全实现，漏洞是否完全修复等
• 测试重点和优先级：按照系统中模块的重要性定优先级
• 网络环境：需要考虑弱网测试
• 风险管理：项目存在风险时，测试在控制质量和时间需要把控。

1.7 测试用例编写模板

2. 缺陷管理

2.1 缺陷的定义

（1）软件未达到产品说明书的功能要求 （2）软件出现了产品说明书指明不会出现的错误 （3）软件功能超出产品说明收范围 （4）软件未达到产品说明书虽未指出但应达到的目标 （5）软件被认为难以理解、不易操作、运行速度慢或最终用廖认为不好。

2.2 缺陷的状态

• New：报告一个Bug。
• Open：验证后分配给相关的开发人员进行修改状态。
• Fixed：开发人员修复后的状态。
• Verified：等待测试人员验证的状态。
• Rejected：拒绝修改Bug。
• Reopen：如果没修改成功，则重新打开。
• Closed：如果修改成功，则关闭Bug。

2.3 缺陷的生命周期

2.4 缺陷的优先级

• 立即解决(Resolve immediately)：缺陷导致系统几乎不能使用或者测试不能继续。——P1
• 高优先级（high priority)：缺陷严重，影响测试，需要优先考虑；软件未达到产品说明书虽未指出但应达到的目标。——P2
• 正常排队(Normal Priority) ：缺陷需要正常排队等待修复。——P3
• 低优先级(Low priority) ：缺陷可以再开发人员有时间的时候被纠正。——P4

2.5 缺陷的严重程度

• 致命性（Fatal）：阻碍流程、系统崩溃导致重大任务不能正常进行的缺陷，比如数据库死锁、死机、非法退出、严重计算错误等
• 严重（Critical）：系统的主要功能部分丧失，数据不能保存，系统的次要功能完全丧失;如开发人员修复后的状态。系统响应时间过长、核心功能缺失等
• 一般(minor)：操作性错误、错误结果、遗漏功能等影响系统要求或基本功能的实现；比如界面错误、打印内容格式错误、数据输入没有边界值等。
• 轻微（Slight）：操作性错误、错误结果、遗漏功能等影响系统要求或基本功能的实现，界面设计存在缺陷、提示不正确、整体风格不一致
• 建议性：不影响使用的瑕疵或更好的实现等对软件各方面提出的更好的改进性的意见。

2.6 缺陷的类型

• 功能缺陷
• 性能缺陷
• 兼容性缺陷
• 安全性缺陷
• 易用性缺陷
• 用户界面缺陷
• 设计文档缺陷
• 安装/卸载缺陷等等

2.7 缺陷（bug）不修复的原因

• 时间：没有足够的时间. (Postpone)
• 需求：不是我们产品的问题 (External)
• 重复：已经有一个同样的Bug了(Duplicated)
• 风险：修复这个bug会带来更大的风险. (Won’t fix)
• 代价：不值得花费大量的时间去修复小bug (Won’t fix)
• 环境：在我环境上是好的，不能重现你的bug. (Not Repro)
• 设计：这不是一个bug, 这是一个设计. (Not Repro, By Design)

2.8 缺陷（bug）管理工具

• Bugzilla
• 禅道
• Jira

3. 测试流程

3.1 瀑布模型

（1）项目计划阶段：主要是制定项目总体研发计划，树立项目里程碑节点，输出项目计划书； （2）需求分析阶段：明确客户的需求定义，并对这个定义进行清晰的描述，是充分理解客户需求，描述产品功能的重要阶段，这个阶段会输出产品的需求规格说明书； （3）软件设计阶段：则会根据需求的定义，来确定产品实现的方案，包括定义软件硬件的结构，组建模块的实现方法，接口、界面、数据如何进行组织，这个阶段会输出包括概要设计，详细设计在内的多份说明书； （4）程序开发阶段：这个阶段是开发团队根据需求和设计具体实现我们的产品，来根据编程规范，构建我们的组件模块，最后输出我们的产品版本； （5）软件测试阶段：则是通过独立的测试小组或者QI团队评估我们的产品是否满足需求的定义，最后输出测试结果报告， （6）集成维护阶段：则是产品经过测试以后，交付给用户，根据用户的使用情况，再对产品进行维护，及必要的修改升级等操作。

优点：强调需求，设计的作用；前一阶段完成后只需关注后续阶段；为项目提供按阶段划分的检查点，里程碑清晰；文档规范 缺点：线性研发过程难以适应需求的频繁变化；周期后段才可看到成果，用户要到末期才能看到开发结果，增加了开发的风险；强制的里程碑，对于开发过程中出现的变化，适应能力较差；文档工作量较大，测试在项目的后期，文档的开发带来很大的工作量。

3.2 V 模型

V模型是瀑布模型的变化，也是使用最广泛的模型。V模型中的过程从左到右，描述了基本的开发过程和测试行为。V模型的价值在于它非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系。 （1）单元测试：是基于代码的测试，最初由开发人员执行，以验证其可执行程序代码的各个部分是否已达到了预期的功能要求； （2）集成测试：验证了2个或多个单元之间的集成是否正确，并有针对性地对详细设计中所定义的各单元之间的接口进行检查；
（3）系统测试：所有单元测试和集成测试完成后，系统测试开始以客户环境模拟系统的运行，以验证系统是否达到了在概要设计中所定义的功能和性能；
（4）验收测试：当技术部门完成了所有测试工作后，由业务专家或用户进行验收测试，以确保产品能真正符合用户业务上的需要。

优点：在V模型里，强调软件开发的协作和速度，反应测试活动和分析测试的关系，并且将软件的实现和验证有机的结合了起来，V模型，明确的界定测试过程是存在不同阶段的。 缺点：但是V模型也有一定的局限性,它仅仅把测试过程放在需求分析、系统设计、编码之后的一个阶段，忽视了测试对于需求的分析和验证。我们对需求的验证，对系统设计的验证，到后期的验收测试才有可能被发现，对于我们测试当中的测试需要尽早进行的原则在V模型中没有体现，这是V模型的局限。

3.3 W 模型

相对于V模型，W模型增加了软件开发各阶段中同步进行的验证和确认活动。由两个V字型模型组成，分别代表测试与开发过程，图中明确表示出了测试与开发的并行关系。 优点：开发与测试并行，有利于尽早发现问题，有利于及时的了解项目的测试风险，来及早的执行相应的应对方案，加快项目的进度。 局限性：需求、设计、编码仍然是串行进行的，测试和开发保持线性的关系，上一个阶段完成之后才能进行下一个阶段，不能够很好的支持迭代的开发模型。如果没有文档，根本无法执行w模型；对于项目组成员的技术要求更高！

3.4 H 模型

把软件测试看成一个完全独立的流程，与其他流程并发进行，比如设计流程，编码流程，甚至是测试流程。 优点： （1）开发的H模型揭示了软件测试除测试执行外，还有很多工作； （2）软件测试完全独立，贯穿整个生命周期，且与其他流程并发进行； （3）软件测试活动可以尽早准备、尽早执行，具有很强的灵活性； （4）软件测试可以根据被测物的不同而分层次、分阶段、分次序的执行，同时也是可以被迭代的。 缺点： （1）管理型要求高：由于模型很灵活，必须要定义清晰的规则和管理制度，否则测试过程将非常难以管理和控制； （2）技能要求高：H模型要求能够很好的定义每个迭代的规模，不能太大也不能太小； （3）测试就绪点分析困难：测试很多时候，你并不知道测试准备到什么时候是合适的，就绪点在哪里，就绪点的标准是什么，这就对后续的测试执行的启动带来很大困难； （4）对于整个项目组的人员要求非常高：在很好的规范制度下，大家都能高效的工作，否则容易混乱。例如：你分了一个小的迭代，但是因为人员技能不足，使得无法有效完成，那么整个项目就会受到很大的干扰。

3.5 敏捷开发模型

（1）定义：敏捷测试即是不断修正质量指标，正确建立测试策略，确认客户的有效需求能得以圆满实现和确保整个生产的过程安全的、及时的发布最终产品。 （2）实质：敏捷测试既不是一种方法（如黑盒方法、白盒方法等），也不是一种方式（如探索式测试）。因为在敏捷测试中可以采用已有的各种方法，包括白盒方法、黑盒方法。敏捷测试应该是一套解决方案、一类测试操作与管理的框架、一组实践或由一定顺序的测试活动构成的特定的测试流程。 （3）目的：敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。 （4）体系特征： 经常交付、密切交流和反思改进，这三大特征在任何项目中都必须采用。 （5）敏捷测试与开发的关系： 在敏捷软件开发过程中开展的测试就可以被称作是敏捷软件测试。因此，敏捷软件测试并不是一个与敏捷软件开发同一层次的划分，而是敏捷软件开发中的一部分，与传统的测试不同，敏捷软件测试并不是一个独立的过程，相反，它与整个敏捷开发中的其他活动交织在一起，处处都能看到它的影子。

4. 测试方法

4.1 黑盒测试

定义：将被测软件看作一个打不开的黑盒，主要根据功能需求设计测试用例，进行测试。 主要用于发现以下情况： （1）是否有不正确或遗漏了的功能 （2）在接口上，能否正确地接受输入数据，能否产生正确地输出信息 （3）访问外部信息是否有错 （4）性能上是否满足要求 （5）界面是否错误，是否不美观 （6）初始化或终止错误

4.1.1等价类划分

定义：在分析需求说明书的基础上把输入域划分为若干部分，然后在每部分中选取代表数据形成测试用例。 有效等价类：

• 是指对于程序的规格说明来说是合理的，有意义的输入数据构成的集合
• 利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能

无效等价类：

• 与有效等价类的定义恰巧相反
• 设计测试用例时，要同时考虑这两种等价类。因为，软件不仅要能接收合理的数据，也要能经受意外的考验。这样的测试才能确保软件具有更高的可靠性

例：输入值是学生成绩，范围是0～100。

等价类可作如下划分

• 有效等价类：0≤成绩≤100
• 无效等价类：成绩<0；成绩>100

4.1.2 边界值分析法

定义：对输入或输出的边界值进行测试 例：重量在10公斤至50公斤范围内的邮件 （1）选择正好等于边界的值：10及50 （2）选好刚好大于或者刚刚小于边界的值：10.01,49.99,9.99及50.01等。

4.1.3 因果图法

定义：利用图解法分析输入的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件的各种组合情况。 例：有一个处理单价为1元5角的盒装饮料的自动售货机软件。若投入1元5角硬币，按下“可乐”，“雪碧”或“红茶”按钮，相应的饮料就送出来。若投入的是两元硬币，在送出饮料的同时退还5角硬币。

4.1.4 决策表法

定义：是把作为条件的所有输入的各种组合值以及对应输出值都罗列出而形成的表格。 例：参考

4.1.3因果图例

4.1.5 错误推测法

（1）定义：基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性的设计测试用例的方法。 （2）基本思想：列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据它们选择测试用例。例如：

• 在单元测试时曾列出的许多在模块中常见的错误、以前产品测试中曾经发现的错误等，这些就是经验的总结。
• 输入数据和输出数据为0的情况、输入表格为空格或输入表格只有一行等。这些都是容易发生错误的情况，可选择这些情况下的例子作为测试用例。

4.2 白盒测试法

定义：白盒测试也称结构测试或逻辑驱动测试，是一种测试用例设计方法，它从程序的控制结构导出测试用例。

目的：

• 保证一个模块中的所有独立路径至少被执行一次；
• 对所有的逻辑值均需要测试真、假两个分支；
• 在上下边界及可操作范围内运行所有循环；
• 检查内部数据结构以确保其有效性。

覆盖标准：白盒法考虑的是测试用例对程序内部逻辑的覆盖程度。最彻底的白盒法是覆盖程序中的每一条路径，但是由于程序中一般含有循环，所以路径的数目极大，要执行每一条路径是不可能的，只能希望覆盖的程度尽可能高些。

4.2.1 白盒测试各方法

在逻辑覆盖测试中，按照覆盖策略由弱到强的严格程度： （1）语句覆盖：每个语句至少执行一次。 （2）判定覆盖：在语句覆盖的基础上，每个判定的每个分支至少执行一次。 （3）条件覆盖：在语句覆盖的基础上，使每个判定表达式的每个条件都取到各种可能的结果。 （4）判定/条件覆盖：即判定覆盖和条件覆盖的交集。 （5）条件组合覆盖：每个判定表达式中条件的各种可能组合都至少出现一次。 （6）路径覆盖：每条可能的路径都至少执行一次，若图中有环，则每个环至少经过一次

最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取