IT界被忽视的小可爱们：致敬QA

一、了解软件测试

1.1、什么是软件测试

使用人工或者自动手段，来运行或者测试某个系统的过程。其目的在于检测它是否满足规定的需求或者弄清预期结果与实际结果之间的差别

1.2、软件测试现状

1.3、软件测试标准

国内通用的软件工程标准主要有ISO9000及CMM：
ISO9000系列标准是ISO国际标准化组织TC/176技术委员会制定的所有的国际标准，其核心标准是质量保证保准(ISO9001/2/3)和质量管理标准ISO9004

1.4、软件测试所需要的知识体系和素质

二、测试环境

首先alpha测试和beta都属于验收测试，这两种测试都需要用户参加，且都不能由程序员和测试员执行。广义上来讲， α测试是“内测”， β测试是“公测”，alpha测试是用户在开发环境或者是公司内部模拟实际操作环境的测试
α测试的特点是：
　　1、它是在开发环境下进行的（不对外发布）
　　2、它不需要测试用例评价软件使用质量
　　3、用户往往没有相关经验，可以是兼职人员，开发者或测试者坐用户旁边
　　4、目的主要评价软件产品的功能、局域化、可用性、可靠性、性能等
Beta测试是真实用户在实际操作环境下进行的测试。 而且顺序不能错，必须先进行Alpha测试再进行Beta测试；先α测试后β测试
Alpha测试的环境是受开发方控制的，用户的数量相对比较少，时间比较集中。
而beta测试的环境是不受开发方控制的，谁也不知道用户如何折磨软件，用户数量相对比较多，时间不集中。
对于软件产品来说，在系统测试后，才有α测试β测试，而且通用的软件产品需要较大规模的beta测试，测试周期比较长。如果产品通过了beta测试，那么就可以正式发行了。
　　如果还不能够理解明白，就类比《王者荣耀》，有体验服(内测玩家)、正式服(大众的普遍玩家)。

三、软件测试分类

3.1、黑盒测试和白盒测试

黑盒测试(Black Box -Test)指的是把被测试的软件看做一个黑盒子，我们不去关心盒子里边的结构是什么样子，只关心软件的输入数据和输出结果
白盒测试(White Box Testing),指的是把盒子盖打开，去研究里边源代码和程序结构

3.2、静态测试和动态测试

静态测试：是指不实际运行被测试软件，而只是静态的检查程序代码、界面或者文档中可能存在的错误的过程
动态测试：是指实际运行被测程序，输入相应的测试数据，检查实际输出结果和预期结果是否相符的过程

3.3、功能测试和性能测试

3.3.1、功能测试

是黑盒测试的一部分，它检查实际软件的功能是否符合用户的需求
功能测试可以细分逻辑功能测试，界面测试，易用性测试，安装测试和兼容性测试

3.3.1.1、逻辑功能测试

测试应用是否符合逻辑，比如应该先注册账号之后，才能进行登录，登录之后才能看我的购物车

3.3.1.2、界面测试

窗口大小，按钮大小，点击按钮弹出什么样的提示框，是否有滚动条，下拉菜单是否有展示内容…

3.3.1.3、易用性测试

从软件使用的合理性和方便性等角度对软件系统进行检查，比如：软件窗口长宽比例是否合适，颜色色彩是否赏心悦目，字体大小是否合适

3.3.1.4、安装测试

1、软件在不同操作系统下安装的过程
2、软件安装后的是否能够正常运行，安装后的文件夹及文件是否写到了指定的目录里。
3、软件安装各个选项的组合是否符合概要设计说明
4、软件安装向导的UI测试
5、软件安装过程是否可以取消，点击取消后，写入的文件是否如概要设计说明处理
6、软件安装过程中意外情况的处理是否符合需求（如死机，重启，断电）
7、安装过程是否是可以回溯的（即是否可以点上一步重新选择）、
8、软件安装过程中是否支持快捷键，快捷键的设置是否符合用户要求
9、对某些软件要考虑客户端的安装、服务器端的安装、数据库的安装及单机版和网络版的安装

3.3.1.5、兼容性测试

3.3.2、性能测试

时间性能：软件的一个具体事务的响应时间。比如点击一个登陆按钮，到登录成功(失败)的反应时间，浏览器非常常见，ANR（Application not responding 应用程序无响应）
空间性能：软件运行时所消耗的系统资源，比如对内存和cpu的消耗
一般性能测试：软件正常运行，不向其施加任何压力的测试
稳定性测试：也叫可靠性测试，是指连续运行被测系统，检查系统运行时的稳定程度
负载测试：让被测系统在其能够忍受的压力范围之内连续运行，来测试系统的稳定性
压力测试：持续不断的给被测试的系统增加压力，直到被测试的系统压垮为止，用来测试系统所承受的最大压力

3.4、单元测试、集成测试、系统测试和验收测试

3.4.1、单元测试

单元测试，又可以理解为单功能测试
是指对软件中最小可测试单元进行检查和验证
单元测试当一段代码完成之后，是由白盒测试工程师或者开发人员自行测试，比如java中执行单元测试叫做junit测试
目前大部分公司单元测试由开发人员简单编译和调试一下自己的程序，没有相应的单元测试计划
单元测试方式:先静态地观察代码是否符合规范，然后动态地运行一下代码，检查运行的结果

3.4.2、集成测试

集成测试是单元测试的下一个阶段，是指将通过测试单元模块组装成系统或者子系统，再进行测试，重点测试不同模块的接口部分

3.4.3、系统测试

集成测试完成之后，就是系统测试和验收测试
系统测试：指的是将整个软件系统看做一个1个整体进行测试，包括对功能、性能，以及软件所运行的软硬件环境进行测试。
系统测试由黑盒测试人员在整个系统集成完毕后进行测试，前期主要测试系统的功能是否满足需求，后期主要测试系统运行的性能是否满足需求，以及系统在不同的软硬件环境的兼容性等

3.4.4、验收测试

软件测试分为正式验收和非正式验收。正式验收测试是一项管理严格的过程，它通常是系统测试的延续。验收测试一般由用户派出代表和开发方的测试小组一起进行测试验收，但也可能有用户单独验收，总之方式不限，最终的目的还是用户满意并接收

非正式验收包括Alpha 测试、Beta 测试
Alpha 测试：一般是在开发者所提供的场所进行测试，由用户来执行、测试人员、开发人员共同参与的内部测试
Beta 测试：Beta 测试完全脱离开发者的环境，一般不由测试和开发人员进行测试、完全交给用户进行测试、一般是指的内测之后的公测

3.5、冒烟测试、回归测试和随机测试

3.5.1、冒烟测试

指对一个软件进行系统大规模的测试之前，先验证一下软件的基本功能是否实现，是否具备可测性
测试小组在正式测试一个新版本之前，先测试一下软件的主要功能，如果没有实现，则打回开发组重新开发，这样做可以节省大量的时间成本和人力成本

3.5.2、回归测试

回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。自动回归测试将大幅降低系统测试、维护升级等阶段的成本
回归测试作为软件生命周期的一个组成部分，在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。在渐进和快速迭代开发中，新版本的连续发布使回归测试进行的更加频繁，而在极端编程方法中，更是要求每天都进行若干次回归测试。因此，通过选择正确的回归测试策略来改进回归测试的效率和有效性是很有意义的

3.5.3、随机测试

软件测试中除了根据测试用例和测试说明书进行测试外，还需要进行随机测试主要是根据测试者的经验对软件进行功能和性能抽查

四、软件测试的原则

五、软件生命周期

软件生命周期 同任何事物一样，一个软件产品或软件系统也要经历孕育、诞生、成长、成熟、衰亡等阶段，一般称为软件生命周期；软件生命周期模型是指人们为开发更好的软件而归纳总结的软件生命周期的典型实践参考

六、软件测试模型

6.1、边做边改模型

许多产品都是使用“边做边改”模型来开发的。在这种模型中，既没有规格说明，也没有经过设计，软件随着客户的需要一次又一次地不断被修改
在这个模型中，开发人员拿到项目立即根据需求编写程序，调试通过后生成软件的第一个版本。在提供给用户使用后，如果程序出现错误，或者用户提出新的要求，开发人员重新修改代码，直到用户满意为止。
这是一种类似作坊的开发方式，对编写几百行的小程序来说还不错，但这种方法对任何规模的开发来说都是不能令人满意的，其主要问题在于：
（1） 缺少规划和设计环节，软件的结构随着不断的修改越来越糟，导致无法继续修改；
（2） 忽略需求环节，给软件开发带来很大的风险；
（3） 没有考虑测试和程序的可维护性，也没有任何文档，软件的维护十分困难。

6.2、瀑布模型

瀑布模型是最早出现的软件开发模型，在软件工程中占有重要的地位，它提供了软件开发的基本框架。其过程是从上一项活动接收该项活动的工作对象作为输入，利用这一输入实施该项活动应完成的内容给出该项活动的工作成果，并作为输出传给下一项活动。同时评审该项活动的实施，若确认，则继续下一项活动；否则返回前面，甚至更前面的活动。对于经常变化的项目而言，瀑布模型毫无价值。

优点：

1. 为项目提供了按阶段划分的检查点
2. 当前一阶段完成后，只需要去关注后续阶段。
   缺点：
   1）各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。
   2）由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险。
   3）通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
   4）瀑布模型的突出缺点是不适应用户需求的变化。
   

6.3、V模型

V 模型的左边下降的是开发过程各阶段，与此相对应的是右边上升的部分，即各测试过程的各个阶段。
V 模型的优点在于它非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发各阶段的对应关系。
V模型的缺陷及解决思路
V模型仅仅把测试过程作为在需求分析、系统设计及编码之后的一个阶段，忽视了测试对需求分析,系统设计的验证，需求的满足情况一直到后期的验收测试才被验证。
解决的思路是，当一个软件开发的时候，研发人员和测试人员需要同时工作，测试在软件做需求分析的同时就会有测试用例的跟踪，这样，可以尽快找出程序错误和需求偏离，从而更高效的提高程序质量，最大可能的减少成本，同时满足用户的实际软件需求。

6.4、W模型

相对于V模型，W模型更科学。W模型是V模型的发展，强调的是测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、功能和设计同样要测试。测试与开发是同步进行的，从而有利于尽早地发现问题。

七、敏捷开发和敏捷测试

敏捷开发是针对传统的瀑布开发模式的弊端而产生的一种新的开发模式，目标是提高开发效率和响应能力。敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。
由于版本节奏比较快，开发与测试几乎并行，一个版本周期内会有两版在推动，也就是上图中提到的波次发布，波次发布用于尝试新加入的功能，做小范围快速的开发，验证和发布，为下个大版本的功能做实验和调研。快速发版的需求要求测试快速响应，敏捷测试模式适应项目需求。

模型特点：
工作任务划分清晰，工作效率较高
与开发和产品沟通紧密，团队协作性强
测试介入到整个项目的所有会议中，对整体版本信息情况把控全面
轻文档，重沟通。

7.1、敏捷的科学定义

敏捷测试既不是一种方法（如黑盒方法、白盒方法等），也不是一种方式（如探索式测试）
敏捷测试是一套解决方案、一类测试操作与管理的框架、一组实践或由一定顺序的测试活动构成的特定的测试流程
敏捷测试是顺应敏捷开发方法、力求达到质量和效率平衡的一系列的测试实践

7.2、敏捷测试的特点

多关注用户体验、系统使用场景，把单功能测试，交给开发自测
测试尽早介入，参与项目全流程
Code review（代码评审，代码复查）、单元测试、自动化测试，都非常重要
轻文档，重沟通。

7.3、用户故事

由于敏捷测试有一个特点叫轻文档，重沟通。有些时候，对于需求，没有特定的文档，可能就会用”用户故事”进行描述。
用户故事（user story）是从用户的角度来描述用户渴望得到的功能。一个好的用户故事包括三个要素：
　　1. 角色：谁要使用这个功能。
　　2. 活动：需要完成什么样的功能或目标。
　　3. 商业价值：为什么需要这个功能，这个功能带来什么样的价值。
英文：
　　As a , I want to , so that .
　　中文：
　　作为一个<角色>, 我想要<活动>, 以便于<商业价值>
比如:
作为一个“网站管理员”，我想要“统计每天有多少人访问了我的网站”，以便于“我的赞助商了解我的网站会给他们带来什么收益”。
作为用户，我想要查看我的订单列表，以便于了解我的购物信息。
作为用户，我想搜索我的足迹，以便了解我过去1年去过哪些城市。

八、软件测试组织架构

九、需求评审

9.1、什么是需求评审

需求评审通常是由产品经理主持，通过讲解产品需求文档，让相关人员了解具体需求，并提出疑问，进行沟通的过程。统一大家对产品需求的理解，为后续“如何做”打好基础。从整个产品的分析、设计和开发的流程来看，需求评审是一个非常重要的环节，它串起了前期的需求收集、需求分析和后期的需求实施和产品落地

9.2、为什么要进行需求评审

1、明确产品需求，达成统一认知。对于明确产品需求，主要面对的是需求提出方，即相关的业务人员或者用户代表。讲清楚自己对于用户需求的理解是什么，是否深入分析了用户需求。然后与需求方沟通，阐述自己的分析过程，确定自己的理解是否正确，并与其达成一致。接下来介绍相关的解决方案，也就是他们将得到什么样的按钮，进行如何的操作，会看到什么样的数据或分析等。
2、沟通需求细节，优化实现方式。对于需求细节的沟通，主要面对的是需求实现方，即相关的设计或开发人员。在这个环节主要是讲清楚“为什么做”和“做什么”，首先交代需求的相关背景和设计原因，让实现方从源头就清楚自己要做的功能为什么是这种形式，其次详细描述需求的实现方式的相关细节，让实现方知道自己接下来做的东西是什么，特性是什么，具有什么样的流程，如何操作等。最后针对相关细节进行沟通和讨论，实现方会站在他们的角度，对实现方式提出自己的疑问或建议，一般情况下，他们提出的相关问题，会弥补产品经理前期没有想到的地方，从而让实现方式更加合理。

9.3、如何进行需求评审

测试人员要想很好地推进需求评审，需要做到以下几个方面：
（1）关注公司，部门规划-------明确发展进度。对未来要做的需求达到心中有数，才能做到合理规划自己的工作，根据项目进度来安排需求评审，编写测试用例等等的工作。
（2）准确分辨需求类型，选择需要评审的需求。不能钻牛角尖，并不是所有项目都需要进行需求评审的，要根据业务发展，需求的类型等合理安排需求评审。
（3）关注产品规划，确定相关参与人员。在做需求的时候，一定要明确相关的参与人员，做到项目的每个阶段可以明确想着的负责人沟通存在的问题。
（4）积极配合产品进行项目推进，督促项目负责人或是产品进行需求评审。在项目的关键阶段，对应的交付物有没有交付，及时进行风险预警，推进项目的按期完成。
（5）提前阅读需求文档，做好充分准备。在需求评审前，一定要先阅读需求文档，带着问题去参加需求评审，以便能更好地理解需求，提出自己的不同意见。

9.4、需求评审检查列表示例

十、测试计划

十一、测试用例的概念和作用

11.1、测试用例的定义

测试用例 [Test Case]

测试用例就是在测试之前设计的一套详细的测试方案，包括测试环境、测试步骤、测试数据和预期结果。
测试用例=输入+输出+测试环境
其中，”输入” 包括测试数据和操作步骤
“输出” 指的是期望结果
“测试环境” 指的是系统环境设置

测试用例是为达到最佳的测试效果而设计的测试数据，包括测试输入、执行条件和预期的结果,测试用例是执行的最小实体

测试用例的特点：
（1）最有可能抓住错误的；
（2）不是重复的、多余的；
（3）一组相似测试用例中最有效的；
（4）既不是太简单，也不是太复杂。

11.2、编写测试用例的好处

在开始实施测试之前设计好测试用例，可以避免盲目测试并提高测试效率。

测试用例的使用令软件测试的实施重点突出、目的明确。在软件版本更新后只需修正少部分的测试用例(可以把上一版完成的用例直接拿过来修改)便可展开测试工作，降低工作强度、缩短项目周期。

11.3、测试用例的特性

代表性
能够代表并覆盖各种合理的和不合理的、合法的和非法的、边界的和越界的以及极限的输入数据、操作和环境设置等。(一个测试用例应该覆盖合理和不合理的数据)

判断 5=<长度<=16

测试结果的可判定性
即测试执行结果的正确性是可判定的，每一个测试用例都应有相应的期望结果。
测试结果的可再现性
即对同样的测试用例，系统的执行结果应当是相同的。
针对性
对程序中的可能存在的错误有针对性地测试

11.5、设计测试用例

11.5.1、如何设计测试用例

根据产品规格书，测试基本功能；
考虑设计一般用户（非专业人员）的使用方案；
考虑设计稀有或特殊的使用方案；
与系统其他组成部分的配合（如FAX和上网可能要用到MODEM，测试中考虑对设备的共享）；
考虑特殊情况（如内存和硬件的冲突等）；
……其他软件的兼容情况
设计极端情况（如内存泄漏java、破坏性测试等）；
好的测试用例集能花费最小的代价（人力、物力、财力、时间）做最好的测试。

11.5.2、测试用例的组成元素

测试用例编号
测试用例名称(测试注册用例)
测试用例设计者
软件版本号
测试目的
参考信息
测试环境
测试步骤(打开网站,输入信息,点击搜索…等)
预期结果
测试结果
测试模块
前置条件
备注

十二、编写测试用例的基本思想

12.1、等价类划分法

12.1.1、概念

等价类划分是指分步骤地把海量（无限）的测试用例集减得很小，但过程同样有效。
等价类 ：何为等价类，某个输入域的集合，在这个集合中每个输入条件都是等效的。

12.1.2、示例

计算两个1～100之间整数的和。
输入框1 输入框2 求和

如果要进行完全测试，一共要设计多少个测试用例呢？
加数1有1～100共计100个取值，加数2也有1～100共计100个取值，所以他们之间的组合就有100*100=10000种组合可能，但这只是测试了正常范围内的取值。如果用户输入的数据不在1～100之间呢，穷举测试肯定不可能的。由此引入了等价类划分思想。

等价类划分为：
有效等价类：指符合《需求规格说明书》，输入合理的数据集合
1-100之间的整数
无效等价类：指不符合《需求规格说明书》，输入不合理的数据集合
<1的数字(整数 小数) >100的数字 其他字符(中文 英文 空格 空 符号)

我们将输入域分成了一个有效等价类（1～100）和两个无效等价类（<1,>100），并为每一个等价类进行编号，然后我们就可以从每一个等价类中选取一个代表性的数据来测试

12.2、边界值法

对数据进行软件测试，就是在检查用户输入的信息、返回的结果以及中间计算结果是否正确。即使最简单的程序要处理的数据量也可能极大，使这些数据得以测试的技巧是，根据一些关键的原则进行等价类的划分，以合理减少测试用例，这些关键的原则是：边界条件，次边界条件、空值和无效数据。

12.1.1、确定边界值的方法

确定边界情况（输入或输出等价类的边界）
选取正好等于、刚刚大于或刚刚小于边界值作为测试数据

输入要求是1 ～ 100之间的整数，因此自然产生了1和100两个边界，我们在设计测试用例的时，要重点考虑这两个边界问题。

注明:边界值不是从每个等价类中挑一个作为代表，而是把每个等价类的边界都进行测试。

12.1.2、边界值应用场景

1)比如，某商品页面展示一页最多能够展示10条 1-10
要一页能够展示10条以内，使能够查询出10条，11条，0条，9条信息。 <=
2)姓名要求1-20个字符，需要测试0,1,2个字符和19,20,21个字符。

12.3、因果图法

因果图法比较适合输入条件比较多的情况，测试所有的输入条件的排列组合。所谓的原因就是输入，所谓的结果就是输出。

12.3.1、因果图基本图形符号

恒等：若原因出现，则结果出现；若原因不出现，则结果不出现。【有因才有果，卡中有钱才能取钱】
非（～）：若原因出现，则结果不出现；若原因不出现，则结果出现。【联系人搜索时，如果有这个人，提示不存在的弹框（结果）就不会出现，如果没有这个人，那么这个框框就会出现】
或（∨）：若几个原因中有一个出现，则结果出现；若几个原因都不出现，则结果不出现。
与（∧）：若几个原因都出现，结果才出现；若其中有一个原因不出现，则结果不出现。

12.3.2、因果图的约束符号

E（互斥）：表示两个原因不会同时成立，两个中最多有一个可能成立（男女单选）
I（包含）：表示三个原因中至少有一个必须成立 （文字样式的选择）
O（惟一）：表示两个原因中必须有一个，且仅有一个成立 （下拉框中城市选择）
R（要求）：表示两个原因，a出现时，b也必须出现，a出现时，b不可能不出现 （银行取钱）
M（屏蔽）：两个结果，a为1时，b必须是0，当a为0时，b值不定 （是元旦就不上班，不是元旦不一定上班）

12.3.3、因果图测试用例

例如：有一个处理单价为2.5元的盒装饮料的自动售货机软件。若投入2.5元硬币，按“可乐”、“啤酒”、或“奶茶”按钮，相应的饮料就送出来。若投入的是3元硬币，在送出饮料的同时退还5角硬币。

分析这一段说明，我们可列出原因和结果
原因(输入)：
投入2.5元硬币；
投入3元；
按“可乐”按钮；
按“啤酒”按钮；
按“奶茶”按钮。
中间状态： ① 已投币；②已按钮
结果(输出)：
退还5角硬币；
送出“可乐”饮料；
送出“啤酒”饮料；
送出“奶茶”饮料；

12.4、判定表法

12.5、场景法

现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。这种在软件设计方面的思想也可以引入到软件测试中，可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，同时使测试用例更容易理解和执行。
用例场景是通过描述流经用例的路径来确定的过程，
这个流经过程要从用例开始到结束遍历其中所有基本流和备选流。
基本流和备选流
如图所示，图中经过用例的每条路径都用基本流和备选流来表示，直黑线表示基本流，是经过用例的最简单的路径。备选流用不同的色彩表示，一个备选流可能从基本流开始，在某个特定条件下执行，然后重新加入基本流中（如备选流1和3）；也可能起源于另一个备选流（如备选流2），或者终止用例而不再重新加入到某个流（如备选流2和4）。

遵循上图中每个经过用例的可能路径，可以确定不同的用例场景。从基本流开始，再将基本流和备选流结合起来，可以确定以下用例场景：
场景 1 基本流
场景 2 基本流 备选流 1
场景 3 基本流 备选流 1 备选流 2
场景 4 基本流 备选流 3
场景 5 基本流 备选流 3 备选流 1
场景 6 基本流 备选流 3 备选流 1 备选流 2
场景 7 基本流 备选流 4
场景 8 基本流 备选流 3 备选流 4
注：为方便起见，场景 5、6 和 8 只描述了备选流 3 指示的循环执行一次的情况。

12.6、错误推断法

主观+经验

错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 总之，就是进行根据经验分析错误的课程性，根据这些可能性设计用例操作。

比如:
1）新开发的功能，与其相关的业务，或者数据，容易出现问题 。
2）分页功能，页码搜索 。
3）新功能的，异常场景 。
4）列表功能，为空时，是否报错 ？
5）文本框，“空格 / 特殊字符”的处理 。

12.7、正交表

正交排列法能够使用最小的测试过程集合获得最大的测试覆盖率,当可能的输入数据或者输入数据的组合数量很大时,由于不可能为每个输入组合 都创建测试用例,可以采用这种方法.
案例:字符属性设置程序
窗体中有多个控件(字体,字符样式,颜色,字号),每个控件有多个取值
字体：仿宋、楷体，华文彩云
字符样式:粗体、斜体，下划线
颜色:红色，绿色、蓝色
字号: 20号, 30号,40号
有多少个排列组合呢？ 333*3 = 81
图：

在测试时，要考虑这些控件的组合情况，组合量非常大（3^4 = 81种组合情况）
由于组合量太大，不可能为每一种组合都创建测试用例。如何采用最少的测试用例集合获得最大的测试覆盖率-------采用正交排列法

正交表生成工具allpairs
很多情况下无法找到合适的正交表,就要使用正交表生成工具。
使用步骤:
制作取值表 【只列出数据即可，不用编号】

2、复制取值表的数据,放到文本文档中保存(注意不要更改任何格式,例如文件叫asd.txt)
3、把文本文档放在pairs文件夹中
4、win + r后输入cmd进入控制台
5、进入pairs文件来
6、在控制台中输入allpairs.exe asd.txt >qq.txt(qq自己起的名字,用来存放生成的组合用例,可以自动生成,不必提前建好)

注意：波浪线后内容随意，男女都可。最后一列多于数据可以删除的。

小结：
将81条测试用例降到了9条(理论值)，这是进行测试的最少组合量，但是，在测试中有72种（81-9=72）组合没有测试到。当然如果时间允许，应该再补充一些测试用例。因为测试用例的组合越多，存在缺陷的可能性就越大。还是竟可能多的去测试。但是九条是我们得到科学的测试方法

12.8、测试方法抉择

十三、测试用例的评审和变更

13.1、用例评审

按正式程度来说：
会议评审
一种正式评审，需要以会议室且投屏的形式，进行评审活动
非会议评审
不需要开会，可以是项目组的成员对测试用例的书面检查
按参与角色来说：
测试组评审
测试组内部成员参与的评审。当一份测试用例初稿完成后，一般先进行测试组内部评审。评审内容侧重在测试思维完整系统性、确保对需求是可追溯且高覆盖的。尤其是当测试团队有测试新人时，测试思维完整性不够，测试组内部评审必不可少。
项目组评审
即整个项目团队人员参与的评审。一般在测试组评审之后进行。包括项目经理、开发人员、架构设计人员、测试人员、产品需求人员，另外像配置管理人员、运营人员具备评审能力都应积极参与。开发人员会注重用例对程序逻辑的覆盖，产品需求人员会注重业务覆盖，另外可确保测试、开发、产品对于需求理解的一致性。

13.2、测试用例评审流程

测试组内部评审，一般评审彼此的用例，以文档检查的形式居多。若需求业务逻辑复杂，视情况开展会议评审。项目组评审主要是会议评审。
会议评审，一般测试负责人(参与测试的测试团队负责人，可能是测试主管、也可能是临时小组长)为会议主持人，会议评审开始时，一般先会大致介绍用例编写的思路，可以按照核心业务流程展开评审，再到各个不同的模块的用例设计，重点包括测试验证点、测试数据、预期输出。同时针对被指出的用例问题组织讨论并做好用例标记记录。会后，整理问题清单，并明确问题责任人。

13.3、评审检查项

十四、缺陷

14.1、缺陷产生的原因

14.2、缺陷分类

bug 臭虫:
按照严重程度分:
一般分为5个等级:
系统崩溃，严重，一般，次要，建议

14.3、缺陷优先级

1. Immediate 即“马上解决”，表示问题必须马上解决，否则系统根本无法达到预定的需求。
   2.Urgent即“急需解决”，表示问题的修复很紧要，很急迫，关系到系统的主要功能模块能否正常。
2. High即“高度重视”，表示有时间就要马上解决，否则系统偏离需求较大或预定功能不能正常实现。
   4.Normal即“正常处理”，进入个人计划解决，表示问题不影响需求的实现，但是影响其他使用方面，比如页面调用出错，调用了错误的等。
3. Low即“低优先级”，即问题在系统发布以前必须确认解决或确认可以不予解决。
   

14.4、bug解决方案的描述

14.5、“完美”的缺陷

14.6、bug的生命周期

14.7、bug的沟通

9.4、

9.4、

9.4、

9.4、

9.4、

9.4、

9.4、

9.4、

9.4、

9.4、

9.4、

9.4、

9.4、

9.4、

9.4、

9.4、

五级标题

六级标题