[开发测试]软件测试理论

软件测试：验证软件的功能是否满足用户的需求。

软件测试目的：

1. 为了发现程序中存在的代码或业务逻辑的错误
2. 为了检验产品是否满足用户需求
3. 为了提高用户的体验

软件测试分类

按测试阶段划分

单元测试：粒度最小，按照一个单元，一个模块，一个功能去测试，一般由开发小组采用白盒方式进行测试，主要测试单元是否符合“设计”；
集成测试：将多个模块合在一起测试，介于单元测试和系统测试之间，起到“桥梁作用”，一般由开发小组采用白盒加黑盒的方式进行测试，既要验证设计，又要验证需求（多个单元组成，单元与单元之间的调用与被调用，参数传递、值传递）；
系统测试：粒度最大，一般又独立测试小组采用黑盒方式进行测试，对整个系统的各个模块，流程，细节等进行完整的测试，主要测试系统是否符合“需求规格说明书”；
验收测试：与测试系统相似，主要区别是测试人员不同，验收测试由用户执行。

按技术进行划分（是否覆盖源代码）

白盒测试：针对代码测试，了解程序的设计原理，逻辑；
黑盒测试：针对功能，界面、易用性进行测试，不考虑其实现细节；
灰盒测试：既要测代码，还要测试界面和功能

是否运行

静态测试：根据需求文档，界面样式，有误错别字；不运行程序去测试；对程序和文档进行分析和检查；
动态测试：运行程序去测试，测试流程、逻辑等

其他

回归测试：程序原本有问题，提交开发更改，开发改完后，程序会更新，测试要检查这个改完的功能是不是正常的，并且有没有影响到其他的功能
冒烟测试：开发完成程序之后，要交给测试进行测试，冒烟测试进行基础功能测试，看主流程有没有问题，有没有严重问题，没有则进入正式测试，如果有则打会开发修改；不测试细节
随机测试：探索性测试，选取重要的功能模块进行随机测试
验收测试：α测试（Alpha是内测版本，公司内部自己在开发环境或者模拟实际操作环境下进行测试，是在受控制的环境下进行的测试），β测试（Beta测试是公测版本，交给客户在实际使用环境下进行测试，开发者不在测试现场，因而是在开发者无法控制的环境下进行的软件现场进行的），γ测试（Gamma版本，指的是软件版本正式发行的候选版，还没有发行，将要发行。没有大量推广，只给少部分用户使用）

是否自动化

人工测试：手动的测试，是专门的测试人员从用户角度来验证软件是否满足设计要求的行为，更适合用于深度的测试和强调主观判断的测试。
优点：易发现缺陷；容易实施；创造性、灵活性
缺点：覆盖量化难；重复测试效率低；不一致性，可靠性低；人力资源依赖
自动化测试：交给机器自动进行测试，利用测试工具软件来控制测试的自动化执行以及对预期和结果进行检查，一般来说，单元测试、接口测试和性能测试等就是利用自动化测试完成。
优点：高效率、速度快；高复用性；覆盖率容易度量；准确、可靠；不知疲劳
缺点：机械、发现缺陷率低；一次性投入较大；对人员要求高

测试方法

黑盒测试

概念

站在用户的角度测试软件，不关心软件内部，只关心输入输出，主要测试依据是需求文档。

测试规划

根据用户的规格说明，即对命令、信息、报表等用户界面及体现它们的输入数据与输出数据之间的对应关系，特别是针对功能进行测试。
用于用户场景的测试。

特点

优点：能站在用户的立场上进行测试。
缺点：不能测试程序内部特点不为，如果规格说明有误，则无法发现。

测试用例设计方法举例

基于图的测试、等价类划分、边界值分析、比较测试

白盒测试

概念

关心软件内部设计和程序实现，主要测试依据是设计文档。

测试规划

根据程序的内部结构，如语句的控制结构，模块间的控制结构以及内部数据结构等进行测试。

特点

优点：能够对程序内部的特定部位进行覆盖测试。
缺点：无法检验程序的外部特性；无法对尉氏县规格说明的程序内部欠缺部分进行测试。

测试用例设计方法举例

参考地址
语句覆盖：每条语句至少执行一次。
判断覆盖：每个判定的所有可能结果至少出现一次。（又乘分支覆盖）
条件覆盖：每个条件的所有可能结果至少执行一次
判断-条件覆盖：一个判断中的每个条件的所有可能结果至少执行一次，并且每个判断本身的所有可能结果至少执行一次。
基本路径覆盖：根据流图计算环复杂度，得到基本路径覆盖的用例数。
完全路径覆盖：每条路径至少执行一次。

覆盖程度：路径覆盖>多重条件覆盖> 判断/条件覆盖>条件覆盖>判断覆盖>语句覆盖

• 路径覆盖是覆盖率最高的，语句覆盖率最弱。
• 满足多重条件覆盖准则的测试用例集，同样满足判断覆盖准则、条件覆盖准则和判断/条件覆盖准则。

任何一种覆盖方法都无法实现完全的测试。所以，在实际的测试用例设计过程中，根据需要将不同的覆盖方法组合起来使用，以实现最佳的测试用例设计 。

灰盒测试

灰盒测试是介于白盒测试与黑盒测试之间的测试，它结合了白盒测试和黑盒测试的要素。
灰盒测试关注输出对于输入的正确性；同时也关注内部表现，但这种关注不像白盒测试那样详细、完整，只是通过一些表征的现象、事件、标志来判断内部的运行状态
其用于解决接口测试。

测试用例设计

定义

测试用例是为特定的目的而设计的一组测试输、执行条件和预期结果，以便测试是否满足某个特定需求。通过大量的测试用例检验软件的运行效果，是指导测试工作进行的依据。
就是一个文档，将测试操作步骤整理成文档，然后在测试的时候执行。

重要性

1. 编写测试用例时，需要思考产品需求的各个方面，这有助于梳理需求，及时发现需求的不合理之处，可以对序曲提出更好的建议，并且也会加深我们对需求的认识和印象
2. 编写测试用例时，可以方便以后有步骤有计划的进行测试，防止漏测
3. 通过测试用例，可以反应测试进度
4. 编写好的测试用例，可以方便在回归测试时，复查bug是否还会出现。

测试用例编写的8大要素

1. 用例编号（项目名称+编号）
2. 用例标题（简单明了的体现测试的内容，关注点）
3. 测试项目（要测试的是哪个功能哪个模块，eg：登录）
4. 用例级别（根据测试点判断测试是主流程，测试点是使用不频繁的低级别、还是使用频繁的高级别）
5. 预置条件（测试前需要准备的工作）
6. 测试输入（测试时要输入的数据）
7. 测试步骤（执行步骤）
8. 预期结果

测试用例设计方法

1.等价类划分法

等价类划分就是把被测对象的输入域划分为若干个集合，对于某个集合中的某个元素和该集合中的任一元素的表征一致，然后从每个划分得集合中取出少数的数据作为测试用例。

等价类的分类：*

• 有效等价类：对程序有意义的合理的数据
• 无效等价类：对程序无意义不合理的数据

等价类划分法案例

测试要求：测试QQ账号，账号的要求是6–10位正整数。
有效的等价类：

• 长度为6-10位之间的正整数

无效等价类：

• 长度小于6
• 长度大于10
• 负数
• 小数
• 英文字母
• 中文
• 空格
• 特殊字符

2.边界值分析法

边界值分析法是作为等价类划分法的补充，通常与等价类划分法一同使用。
边界值分析不是从等价类中随便挑一个作为代表，而是使这个等价类的每个边界都作为测试条件；
边界值分析不仅考虑输入条件，还要考虑输出空间产生的测试情况。

边界值分析法案例

测试要求：微信红包，金额在0.01-200，小数点后两位
等价类划分：
有效等价类：0.01-200的数字
边界值：0.01，0.02，199.99，200.00（选取具有代表性的边界数字）
无效等价类：

• 小于0.01 边界选取0
• 大于200 边界选取201
• 小数点后超过两位数 边界选取0.011
• 输入中文 边界选取二

3.场景法

场景法就是模拟用户操作软件时的场景，主要用于测试系统的业务流程。
当获取测试任务后先关注什么后关注什么？
当拿到一个测试任务后，先关注它的主要功能和业务流程是否正确实现，这就需要使用场景法来完成测试。当业务流程或者说该软件的主要功能没有问题时，我们再重点从边界值、等价类等方面对控件进行更加细致、完整的测试。
冒烟测试时主要采用场景法进行测试
按照流程测试，测试主流程。

场景法案例

测试ATM机：场景法
取钱的功能主流程：插入银行卡–输入密码–选择功能（取款功能）–选择金额–取款–退卡
考虑：插入的是什么卡，输入的密码是怎样的，选择其他功能

4.错误推测法

错误推测法是指利用直觉和经验猜测出出错的可能类型，有针对性列举出程序中所有可能的错误和容易发生的错误情况，它是测试经验丰富的测试人员喜欢使用的一种测试用例设计方法。
基本思想：列举出可能犯的错误或错误易发生的清单，然后根据清单编写测试用例；这种方法很大程度上是凭经验进行的，即凭人们对过往所做测试结果的分析，对所揭示缺陷的规律性作直觉的推测来发现缺陷。
不单独使用，可以作为其他方法的补充。

案例

登录测试:
登录失败了：列出可能导致出错的情况

• 用户名和密码错误
• 网络原因
• 账号被拉黑
• 服务器异常
• 单点登录

测试工作流程

1. 用户提出需求，做什么，需要完成什么功能
2. 公司产品经理，与用户对需求，并将最终需求整理成文档——需求分档
3. 需求会议（前端、后端开发、测试，需求相关人员）讨论需求问题：功能合理，如何设计等。如果需求不合理，会将需求打回，继续整理需求文档。
4. 需求合理，开发设计开发计划，分配人员，确定时间，用到什么知识点；同时，测试去做测试计划，分配人员，确定完成时间
5. 开发编码实现功能、测试设计测试用例（考虑程序上的问题，如何测试需求功能）
6. 设计完测试用例，进行测试用例评审会（与开发人员、测试人员、相关人员），讨论设计的测试用例；测试什么，流程什么，思维统一
7. 确定用例，等着开发，维护用例
8. 程序完成，测试开始测试程序，
9. 程序有问题，移交开发
10. 开发改好后，重新测试
11. 测试没有问题，发布到线上，再进行相关测试