一、软件测试概述
1、什么是软件测试？
一种观点：为发现错误而执行程序的过程
另一种观点：评价程序或系统属性为目的的活动，是对软件质量的度量。
什么是软件缺陷：
1）软件未实现规格说明书中的功能
2）功能出现了不应有的错误
3）软件功能超出规格说明书范围
4）软件未达到应达到的目标
5）软件难以理解，不易使用、运行速度缓慢
2、测试的对象：程序、文件、数据
3、测试的过程模型
V模型（较常用）：
单元测试：测试详细设计中的功能是否全部实现
集成测试：测试概要设计中的功能是否全部实现
系统测试：测试需求分析中的功能是否全部实现
验收测试：测试用户需求是否全部实现
其中，单元测试和集成测试一般公司不会采用。
该模型的缺陷：
1）周期较长：开发阶段和测试阶段是顺序进行的，没有进行并行工作，导致周期比较长；
2）问题发现较迟：比如在系统测试的时候发现有个需求是错误的，那么按V模型的话就要重新修订需求文档——概要设计——详细设计——编码——单元测试——集成测试——系统测试，这样一连串的工作下来可能时间就来不及了。
W模型（较常用）
黄色箭头表示开发，绿色箭头表示测试，两者并行进行。需求分析文档整理好后就进行系统测试用例设计，概要设计好后就进行集成测试用例设计，详细设计好后就进行单元测试用例设计，编码好后集成运用前面设计好的集成测试用例进行集成测试，然后编码实施时运用前面设计好的系统测试用例进行系统测试，最后验收交付。
该模型的优点：
1）将部分测试工作提前进行，缩短了整个项目的周期
2）一些问题在测试用例设计阶段可以提早发现，为解决问题争取更多的时间
X模型
H模型
4、测试的生命周期
测试计划：明确测试的范围（哪些功能需要测试，哪些功能不需要测试）、明确测试策略（采用哪些用例的测试方法进行测试、怎么算通过怎么算不通过）、明确人员进度安排
测试分析：了解需求文档、了解各个模块的功能，哪些功能需要哪些用例来测试，进行构思
测试设计（技术含量较高，工作量比较大）：采用用例设计技术进行用例设计（例如黑盒测试：等价类、边界值、因果图法、决策树等）
测试执行：执行测试用例，提交缺陷，反馈给开发进行修改
测试评估：对测试活动进行总结，对软件系统质量进行评估
注意：单元测试、集成测试、系统测试分别会产生相应的测试计划文档、测试用例文档、测试缺陷报告文档、测试报告文档
5、测试的方法
静态分析：不需要执行软件
动态测试：需要执行软件
黑盒测试（又名功能测试、数据驱动测试）：顾名思义，就像是用一个黑色的盒子将程序代码盖住，我们不关心程序内部结构，只需要知道输入什么样的值（IN）得到什么样的结果（OUT）
白盒测试（又名结构测试、逻辑驱动测试）：需要了解程序内部的逻辑机构
灰盒测试：黑盒测试和白盒测试的结合，即需要了解程序的内部逻辑结构，又需要输入输出值
单元测试：通常在代码完成之后进行，主要是测试函数的功能是否正确实现
集成测试：通常在单元测试之后，各个模块代码完成后集成在一起时进行，主要测试各个模块之间的调用、接口参数之间的传递是否正确
系统测试：集成测试之后进行，主要验证需求规格是否被正确实现
验收测试：用户能否接受软件系统
回归测试：开发人员将缺陷修改好提交后，需要测试该功能是否正确实现以及是否影响到其他功能引起新的缺陷
冒烟测试：程序开发完成后，如基本功能都不能实现（就像一通电电路板就冒烟了），那么我们就将测试申请驳回。因为基本功能都未实现的情况下，测试效率是很低下或无效的，浪费测试资源。
α测试（用户在开发环境下进行系统操作）：当测试人员测试好后，邀请一些用户在开发环境下进行系统操作，看是否有问题
β测试（用户在用户环境下进行系统操作）：软件测好后发布了一个β测试版本，用户在本地安装后进行操作，看是否有问题。一些大的软件公司会发布β版本，比如腾讯的QQ的β版本
6、测试的基本原则
尽早的和不断的进行软件测试（尽早的发现问题，以保证修改问题的代价是最小的，这就是V模型发展成W模型的原因）
应避免测试自己的程序
pareto原则（80/20原则）（80%的缺陷是在20%的模块中发现的，当测试时发现某个模块问题比较多的时候要增加人手进行充分测试以发现更多的缺陷）
测试用例由输入和预期的输出结果组成（要根据预期的输出结果来判断测试用例是否通过，所以输入和预期的输出结果必须成对存在）
程序修改后要回归测试
穷举测试是不可能的
二、黑盒测试技术
黑盒测试概述
什么是黑盒测试技术：不考虑程序的内部结构与特性，只根据程序功能或程序的外部特性设计测试用例。
测试步骤：同上面测试的生命周期
为什么要设计测试用例：
1）良好的测试用例可以缩短实施测试的时间（测试准备工作是跟开发并行的，只有测试执行的时间是单独进行的，从整体上缩短了项目周期）
2）确保测试的系统性、全面性
3）提高测试的可复用性（如有测试人员变动，交接人员会根据测试用例很快熟悉系统，减少对人员的依赖）
黑盒测试用例设计方法
1、等价类划分法：把程序所有可能输入的数据划分为若干子集，每一子集的代表性数据在测试中的作用等价于这一子集的其他值，每一个子集就是一个等价类。等价类需要考虑有效等价类和无效等价类
设计步骤：1）划分等价类 2）确定测试用例
2、边界值法：长期测试经验表明，大量错误发生在输入和输出范围的边界上，而不是发生在输入输出范围的内部。因此，对各种边界设计测试用例，能取得良好的效果。
将边界值测试用例补充到上面等价类划分法中：
3、判定表驱动法：是分析和表达较为复杂逻辑条件下软件状态和行为的有效工具。用它可以设计出完成的测试用例集合，将复杂问题的各种可能情况罗列出，是测试内容变得简单明了而避免遗漏。
判定表设计步骤：
1）确定规则的个数，条件数为n，规则个数=2n
2）列出所有的条件桩和动作桩
3）填入条件项
4）填入动作项
5）简化判定表，合并相似规则
列出所有的条件桩和动作桩：
进行简化合并后：
"—"处无论是Y或N对输出结果都没有影响。
4、因果图法
设计步骤：
1）从程序规格说明中找出因（条件项）和果（结果项），并分析因果关系，以及因因、果果之间的约束关系，绘制因果图
2）通过因果图转为判定表
3）将判定表中不符合约束条件的规则去除
4）然后将判定表简化，将每一规则简化为一个测试用例
该例的因果图：
注：该例中不存在条件约束，如果在实际工作中遇到有条件约束的，要用上面的条件约束的符号将其标出来。
将因果图转化为判定表：
5、正交实验法：从大量试验点中调出适量的、有代表性的点，利用正交表合理的安排试验的一种科学试验方法
正交法：
1）分析影响测试项的因素
2）分析每个因素的取值方式
3）设计或者选择一个合适的正交表
4）把正交表中的元素转换为因素的实际取值，每行转换为一个测试用例
常用的正交表：
正交表一般网上都有设计好的，不需要我们去设计，通常需要我们选择一个合适的正交表。比如我们的实际情况是有一个因素是3水平，有4个因素是2水平，上图中刚好没有完全符合的正交表，那么我们就选择最相近的一个，即混合水平中的第一个正交表最为相近：
，1个因素4水平的肯定包含了1一个因素3水平的。当然，如果我们的实际情况是有一个因素是4水平，有3个因素是2水平，那么我们也可以选择，因为4因素2水平肯定包含了3因素2水平。
总结：如果没有完全匹配的正交表，那么原则选择的正交表的因素数和水平数必须包含实际的因素数和水平数；如果有多个正交表满足要求，我们选择行数比较少的那个
正交表具体如下：
那么，我们如何将这个正交表修改为适合上例中使用的正交表呢？按如下步骤操作：
上例中，我们有2个因素2水平，2个因素3水平，1个因素6水平，那么需要将上述正交表中多余的两个3水平因素去掉：
上例中，因素1和因素2只有2个水平，因此，我们需要将上述正交表中因素1和因素2三水平的第三个取值替换为2水平的取值：
综上，我们改造后的正交表如下图：
最后，将正交表中的值替换为我们因素实际的取值即可：
将正交表因素1的取值0、1分别替换为A1、A2
将正交表因素2的取值0、1分别替换为B1、B2
将正交表因素3的取值0、1、2分别替换为C1、C2、C3
将正交表因素4的取值0、1、2分别替换为D1、D2、D3
将正交表因素7的取值0、1、2、3、4、5分别替换为E1、E2、E3、E4、E5、E6
全部替换后如下图：
通过该正交表我们需要进行13次测试，如果不用正交表，那么我们需要进行2*2*3*3*6=218次测试，因此正交表大大减少了我们的工作量。
6、场景法
1）事件触发时序不同形成不同场景
2）事件流分为基本流和备选流。基本流描述最正常的一种场景，备选流描述执行过程中的异常或偶尔发生的情况
3）场景法是通过用例场景描述业务操作流程，遍历业务流程上所有基本流和备选流
场景法设计步骤：
1）分析程序基本流、备选流
2）根据基本流、备选流生成场景
3）每一个场景对应一个测试用例
三、白盒测试技术
又称为逻辑驱动测试，测试用例是依据选用的覆盖标准来确定的。
白盒测试方法
1、逻辑覆盖法
设计步骤：
1）选择逻辑覆盖标准
2）按照覆盖标准列出所有情况
3）选择确定测试用例
逻辑覆盖法以程序内部逻辑结构为基础的测试技术，它考虑的是测试数据对逻辑的覆盖。
语句覆盖：设计若干个测试用例，使每个可执行语句至少执行一次
判定覆盖：设计若干个测试用例，使程序中的每一个真分支假分支至少执行一次。
条件覆盖：设计若干个测试用例，使每个逻辑条件的可能取值至少执行一次。
a、b、c三个参数的所有可能取值至少一次，a为T或F，b为T或F，c为T或F，从此例也可看出满足条件覆盖未必满足判定覆盖，同时满足判定覆盖未必满足条件覆盖，因此二者不存在谁比谁强的问题。
判定条件覆盖：设计若干个测试用例，使程序中的每一个真分支假分支至少执行一次，同时使每个逻辑条件的可能取值至少执行一次，即满足判定覆盖又满足条件覆盖。
条件组合覆盖：设计若干个测试用例，使每个判定的所有条件组合情况至少出现一次。
共有3个变量，每个变量有2个取值，那么所有的组合方式为23=8种情形，如上图。
2、基本路径测试法
它在程序控制流图的基础上，通过分析控制构造的环路复杂性，导出基本可执行路径的集合，从而设计测试用例的方法。设计出的测试用例要保证在测试中程序的每一条可执行语句至少执行一次。
1）导出程序的控制流图
2）计算程序的圈复杂度
3）确定线性独立路径集合
4）生成测试用例
四、自动化测试
自动化测试优点：
1）提高测试质量
2）提高测试效率
3）提高测试覆盖率
4）完成手工测试不能完成的任务（比如测试一个1000人并发登录）
5）测试可重复性
6）更好的利用资源
自动化测试局限：
1）不要希望所有的测试全部自动化，只有重复而繁琐的活动才可能需要自动化（自动化需要投入很多人力去开发脚本，如果一个测试只需要执行一次那就没必要自动化测试了）
2）如果软件不稳定时，必须先进行手工测试，手工测试可以处理更多的意外事件，而自动化测试未必能处理（比如网络连接中断）
3）自动测试不能发现大量的新缺陷，因此自动测试的重点在回归测试伤
什么情况下测试应该自动化？
接口、单元测试等易于实现自动化的测试
压力测试
自动化测试用例会被反复使用
项目周期较长，需求变动不频繁
什么情况下测试不应该自动化？
只运行一次的测试
周期短的项目
人体感官和易用性的测试
未经过详细准备的测试
不稳定的软件
涉及物理交互
自动化测试工具
五、软件测试经验谈
团队合作
不要人云亦云
学习/积累
细心、耐心