什么是软件测试
狭义的软件测试仅仅指的是动态测试，即测试是执行程序的过程，通过运行程序来发现程序代码或软件系统中的错误。广义的软件测试不仅是值运行程序或系统进行测试，还包括需求/设计/代码等评审活动。
软件测试的几个阶段
单元测试，集成测试，系统测试，验收测试
软件测试有7个基本阶段，即单元或模块测试、集成测试、外部功能测试、回归测试、系统测试、验收测试、安装测试。
软件测试过程模型
V模型，W模型，H模型，X模型
软件测试的原则
- 测试的本质是证明软件存在缺陷，而不是没有缺陷
- 不可能执行穷尽测试
- 测试应该尽早启动，尽早介入
- 缺陷存在集群现象（二八原则）
- 杀虫剂悖论
- 不同测试活动依赖不同的测试背景
- 不存在缺陷的谬论
黑盒测试
黑盒测试也称为功能测试，指测试人员不关心程序的内部结构和实现，只关心输入和输出的结果是否符合预期。程序功能是否按照需求规格说明书的规定正常使用。
一般又分为性能测试和功能测试
一、功能测试
逻辑功能测试 界面测试 易用性测试 安装测试
二、性能测试
软件测试的高级领域
时间性能 空间性能 一般性能测试 可靠性测试 负载测试 压力测试
白盒测试
又称结构测试，透明盒测试。是一种测试用例设计方法，盒子指的是被测试的软件。白盒法是穷举路径测试，测试人员必须了解程序的内部结构，从检查程序的逻辑出售，从而得出测试数据。
动态测试
不直接运行软件，静态的检查代码和界面或者文档
静态测试
运行软件进行测试，根据最后执行的结果判断
单元测试
又称模块测试，针对软件设计中的最小单位—程序模块
单元定义：c中一般指一个函数，java中指类，图形化测试指窗口。
一般由白盒测试员来做，不建议自己来做。
依据：源程序+设计文档
单元测试的通过标准：通过单元的测试用例，语句覆盖率要求，分支覆盖率要求，不同软件的标准不同
国内单元测试现状：简单+没有单元测试计划+没有单月测试用例和代码统计率的设计
如何运行单元测试：主要用于白盒测试，1.风格 2.实际代码 3.容错，临界点测试
集成测试
又称组装测试。将程序所有模块进行有序的，递增的测试。
什么时候进行？单元测试和集成测试理论上可以同步进行，但是一般先进行单元测试
由谁来做？白盒
依据：单元测试的模块，概要设计的文档
系统测试
把整个软件系统作为一个整体进行测试，包括功能、性能、软件的软硬件环境
由黑盒工程师在系统集成完毕后进行测试，前期主要是功能，后期主要是性能和兼容性测试
验收测试
以用户测试为主，包括质量保证人员共同测试，又分为α测试和β测试
α测试：指的是由用户、测试人员、开发人员共同参与的内部测试
β测试：指的是内测之后的公测，即完全交给用户进行最终测试
重要性：验收签字，收钱
α测试
指的是由用户、测试人员、开发人员共同参与的内部测试
β测试
指的是内测之后的公测，即完全交给用户进行最终测试
功能测试
逻辑功能测试 界面测试 易用性测试 安装测试
性能测试
软件测试的高级领域
时间性能 空间性能 一般性能测试 可靠性测试 负载测试 压力测试
回归测试
指软件被修改后重新进行的测试，保证软件的修改没有引入新的错误
随机测试
所有的数据都是随机生成的
冒烟测试
是指在对一个新版本进行系统的大规模测试之前，先验证一下软件的基本功能是否实现，是否具备可测试性
负载测试
负载测试指不限制软件的运行资源，测试软件的数据吞吐量上限，以发现设计上的错误或验证系统的负载能力。在这种测试中，将使测试对象承担不同的工作量，以评测和评估测试对象在不同工作量条件下的性能行为，以及持续正常运行的能力。
负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外，负载测试还要评估性能特征。例如，响应时间、事务处理速率和其他与时间相关的方面。
压力测试
对系统不断施加压力的测试，通过确定一个系统的瓶颈或者不能接收的性能点，获得系统能提供最大服务级别的测试。注重的是外界不断施压。
组合测试
组合测试也称集成测试或子系统测试，通常采用自顶向下测试和自底向上测试两种测试方法。组合测试的对象是指已经通过单元测试的模块，不是对零散模块进行单个测试，而是用系统化的方法装配和测试软件系统；是一个严格的过程，必须认真地进行计划，其计划的产生和单元模块测试的完成日期要协调起来。这种测试应在系统目标机上进行。造就系统应用的环境条件。除了开发部门项目负责人参加以外，还应该有相应系统的用户参加，给评审员进行演示。
开发者测试
在软件行业中，一个程序从开始开发到交付使用，中间涉及了包括单元测试、集成测试、接口测试、性能测试等许多测试环节。其中由开发者完成的代码级测试部分称为开发者测试。
什么是开发者测试
一、单元测试
开发者测试最重要的组成部分是单元测试。单元测试是在直接对代码的最基本逻辑进行的测试，一般而言，最基础的代码逻辑很难形成文档，只有开发者本人是最了解自己的代码逻辑，也只有开发者本人最适合写单元测试代码。之前比较流行的一些概念，比如测试驱动开发、结对编程等，与一般的开发者测试也是一样的思路，区别只在于是先写业务代码还是先写测试代码，是一个程序员写所有代码还是两个程序员互相写测试代码。
二、DevOps和测试前移
DevOps是比较流行的一种开发理念，这个单词是development和operation的组合，表示从开发到测试再到运维，一个项目团队要担起自己的项目生命周期内所有的事情。DevOps的概念流程中，没有单独的testing角色，但是测试还是要做，于是软件开发中有了测试前移的概念，既所有的测试都由开发人员来完成，这也给开发者测试添加了更加丰富的概念，除单元测试之外，代码级的各种黑白盒测试都可算入此类。
三、覆盖率
说到测试就不能不提覆盖率的概念。覆盖率表示测试活动中，执行到的业务代码占总业务代码量的比例，是代码测试充分程度的度量指标，与测试的另一个指标——测试用例通过率——一起衡量测试活动的达成情况。
要不要做开发者测试
针对不同的代码类别、不同的代码性能要求、不同的测试难度等，合适的开发者测试力度会有一定的区别。软件业界的主流观点是肯定开发者测试的意义的。当你访问一个开源的项目时，总能在他的文件列表中找到单元测试的代码。对开源项目开发者而言，充足的测试也是对自己代码性能的一种证明，让其他的开发人员更容易认可自己的项目。
web测试
Web测试的类型包括内容测试、界面测试、功能测试、性能测试、兼容性测试、安全性测试等。内容测试、界面测试和兼容性测试都比较简单，不再细谈。Web的功能测试与传统的软件测试区别不大，主要是在连接测试方面有点区别，数据的传递方面会稍微复杂点。由于Web软件都是采用B/S结构，客户端所需的服务都是由服务器提供的，所以主要是测试服务器上软件运行的性能。Web应用程序的测试包括客户端连接服务器速度方面的测试和压力测试这两方面。
功能测试
（1）链接测试。链接是Web应用系统的一个主要特征，它是在页面之间切换和指导用户去一些未知地址的页面的主要手段。链接测试可分为3个方面。首先，测试所有链接是否按指示的那样确实链接到了该链接的页面；其次，测试所链接的页面是否存在；最后，保证 Web应用系统上没有孤立的页面，所谓孤立页面是指没有链接指向该页面，只有知道正确的URL地址才能访问。链接测试可以自动进行，现在已经有许多工具可以采用。链接测试必须在集成测试阶段完成，亦即在整个Web应用系统的所有页面开发完成之后进行链接测试。
（2）表单测试。当用户通过表单提交信息的时候，都希望表单能正常工作。如果使用表单来进行在线注册，要确保提交按钮能正常工作，当注册完成后应返回注册成功的消息。如果使用表单收集配送信息，应确保程序能够正确处理这些数据，最后能让用户收到信息。要测试这些程序，需要验证服务器是否能正确保存这些数据，而且后台运行的程序能否正确解释和使用这些信息。当用户使用表单进行用户注册、登录、信息提交等操作时，必须测试提交操作的完整性，以校验提交给服务器的信息的正确性。如果使用默认值，还要检验默认值的正确性。如果表单只能接受指定的某些值，则也要进行测试。
（3）Cookie测试。Cookie通常用来存储用户信息和用户在某些应用系统的操作，当一个用户使用Cookie访问了某一个应用系统时，Web服务器将发送关于用户的信息，把该信息以Cookie的形式存储在用户端计算机上，这可用来创建动态和自定义页面或者存储登录等信息。如果Web应用系统使用了Cookie，就必须检查Cookie是否能正常工作。测试的内容可包括Cookie是否起作用、是否按预定的时间进行保存、刷新对Cookie有什么影响等。如果在Cookie中保存了注册信息，应确认该Cookie能够正常工作而且已对这些信息加密。如果使用Cookie来统计次数，需要验证次数累计是否正确。
（4）数据库测试。在Web应用技术中，数据库起着重要的作用，数据库为Web应用系统的管理、运行、查询和实现用户对数据存储的请求等提供空间。在Web应用中，最常用的数据库类型是关系型数据库，可以使用SQL对信息进行处理。在使用了数据库的Web应用系统中，一般情况下可能发生两种错误，分别是数据一致性错误和输出错误。数据一致性错误主要是由于用户提交的表单信息不正确而造成的，而输出错误主要是由于网络速度或程序设计问题等引起的，针对这两种情况，可分别进行测试。
性能测试
（1）连接速度测试。用户连接到Web应用系统的速度根据上网方式的变化而变化，或许是电话拨号，或许是宽带上网。当下载一个程序时，用户可以等较长的时间，但如果仅仅访问一个页面就不会这样。如果Web系统响应时间太长（例如超过5s），用户就会因没有耐心等待而离开。另外，有些页面有超时的限制，如果响应速度太慢，用户可能还来不及浏览内容，就需要重新登录了。而且，连接速度太慢，还可能引起数据丢失，使用户得不到真实的页面。
（2）负载测试。负载测试是为了测量Web系统在某一负载级别上的性能，以保证Web系统在需求范围内能正常工作。负载级别可以是某个时刻同时访问Web系统的用户数量，也可以是在线数据处理的数量。
负载测试应该安排在Web系统发布以后，在实际的网络环境中进行测试。因为对于一个企业，其内部员工数量总是有限的，而一个Web系统能同时处理的请求数量将远远超出这个限度，所以，只有放在Internet上，接受负载测试，其结果才是正确可信的。
（3）压力测试。压力测试的区域包括表单、登录和其他信息传输页面等。进行压力测试是指实际破坏一个Web应用系统，测试系统的反应。压力测试是测试系统的限制和故障恢复能力，也就是测试Web应用系统会不会崩溃，在什么情况下会崩溃。在Internet上黑客攻击常采用的方式是：提供错误的数据负载，直到Web应用系统崩溃，接着当系统重新启动时获得存取权。因此，对应用系统的压力测试很有必要。
嵌入式测试
简介
一般来说，软件测试有7个基本阶段，即单元或模块测试、集成测试、外部功能测试、回归测试、系统测试、验收测试、安装测试。嵌入式软件测试在4个阶段上进行，即模块测试、集成测试、系统测试、硬件/软件集成测试。前3个阶段适用于任何软件的测试，硬件/软件集成测试阶段是嵌入式软件所特有的，目的是验证嵌入式软件与其所控制的硬件设备能否正确地交互。
第三方测试
基本概念与测试过程
第三方测试是指介于软件开发方和用户方之间的测试组织的测试，第三方测试也称独立测试，他有独立的验证和确认活动。在模拟用户真实应用环境下，进行软件测试确认。测试方还要对错误进行归类和总结，通过分析错误产生的原因和错误的分布特性，帮助项目管理者发现当前采用的软件过程的缺陷，以便改进，更好的帮助用户
第三方测试的现状现状
第三方测试有别于开发人员或用户进行的测试，其目的是为了保证测试工作的客观性。从国外的经验来看，测试逐渐由专业的第三方承担。同时第三方测试还可适当兼顾初级监理的功能，其自身具有明显的工程特性，为发展软件工程监理制奠定坚实的基础。第三方测试工程主要包括需求分析审查、设计审查、代码审查、单元测试、功能测试、性能测试、可恢复性测试、资源消耗测试、并发测试、健壮性测试、安全测试、安装配置测试、可移植性测试、文档测试以及最终的验收测试等十余项。
软件缺陷的定义
软件缺陷管理的目标：确保每个被发现的缺陷都能被有效的解决（不是修复）
符合五条任意都是软件缺陷：
1.软件未达到软件说明书中标明的功能
2.出现了说明书标明不能出现的功能
3.软件功能超出了说明书中指明的范围。
4.软件未达到产品说明书中指明应达到的目标。
5.软件测试人员认为软件难以理解和使用，运行速度慢，或最终用户认为不好。
软件缺陷的严重程度
严重缺陷：导致程序或重要功能不能执行，或者危机人身安全，系统安全
较大缺陷：严重影响系统要求或者基本功能的实现，且没有办法更正（重新启动或重新安装该软件不属于更正方法）。
较小缺陷：影响系统要求或基本功能的实现，但有办法更正（重新启动或重新安装该软件不属于更正方法）。
轻微缺陷：使操作者不方便或遇到麻烦，但他不影响执行工作功能或重要功能。
其他缺陷：其他错误。
软件缺陷产生的原因
一、软件本身
1.需求不清晰，导致设计目标偏离客户的需求，从而引起功能或产品特征上的缺陷。
2.系统结构非常复杂，而又无法设计成一个很好的层次结构或组件结构，结果导致意想不到的问题或系统维护、扩充上的困难；即使设计成良好的面向对象的系统，由于对象、类太多，很难完成对各种对象、类相互作用的组合测试，而隐藏着一些参数传递、方法调用、对象状态变化等方面问题。
3.对程序逻辑路径或数据范围的边界考虑不够周全，漏掉某些边界条件，造成容量或边界错误。
4.对一些实时应用，要进行精心设计和技术处理，保证精确的时间同步，否则容易引起时间上不协调，不一致性带来的问题。
5.没有考虑系统崩溃后的自我恢复或数据的异地备份、灾难性恢复等问题，从而存在系统安全性、可靠性的隐患。
6.系统运行环境的复杂，不仅用户使用的计算机环境千变万化，包括用户的各种操作方式或各种不同的输入数据，容易引起一些特定用户环境下的问题；在系统实际应用中，数据量很大。从而会引起强度或负载问题。
7.由于通信端口多、存取和加密手段的矛盾性等，会造成系统的安全性或适用性等问题。
8.新技术的采用，可能涉及技术或系统兼容的问题，事先没有考虑到。
二、团队问题
1.系统需求分析时对客户的需求理解不清楚，或者和用户的沟通存在一些困难。
2.不同阶段的开发人员相互理解不一致。例如，软件设计人员对需求分析的理解有偏差，编程人员对系统设计规格说明书某些内容重视不够，或存在误解。
3.对于设计或编程上的一些假定或依赖性，相关人员没有充分沟通。
4.项目组成员技术水平参差不齐，新员工较多，或培训不够等原因也容易引起问题。
三、技术问题
1.算法错误：在给定条件下没能给出正确或准确的结果。
2.语法错误：对于编译性语言程序，编译器可以发现这类问题；但对于解释性语言程序，只能在测试运行时发现。
3.计算和精度问题：计算的结果没有满足所需要的精度。
4.系统结构不合理、算法选择不科学，造成系统性能低下。
5.接口参数传递不匹配，导致模块集成出现问题。
四、项目管理的问题
1.缺乏质量文化，不重视质量计划，对质量、资源、任务、成本等的平衡性把握不好，容易挤掉需求分析、评审、测试、等时间，遗留的缺陷会比较多。
2.系统分析时对客户的需求不是十分清楚，或者和用户的沟通存在一些困难。
3.开发周期短，需求分析、设计、编程、测试等各项工作不能完全按照定义好的流程来进行，工作不够充分，结果也就不完整、不准确，错误较多；周期短，还给各类开发人员造成太大的压力，引起一些人为的错误。
4.开发流程不够完善，存在太多的随机性和缺乏严谨的内审或评审机制，容易产生问题。
5.文档不完善，风险估计不足等。
软件缺陷优先级
- 立即解决：严重阻碍测试进行，且没有办法绕过去。
- 高优先级：严重影响测试进行，但有可选方案绕过该内容进行其他内容的测试
- 正常排队：缺陷需要正常排队等待修复或列入软件发布清单
- 低优先级：缺陷可以再方便时纠正
软件缺陷类别
- 界面：界面错误，如界面显示不符合需求、提示信息不符合规范等
- 功能：系统功能无效、不相应、不符合需求
- 性能：系统响应过慢、无法承受预期负荷等
- 安全性：存在安全隐患的缺陷
- 数据：数据导入或设置不正确
软件缺陷状态
- 提交：已提交缺陷
- 打开：确认待处理缺陷
- 已拒绝：被拒绝处理的缺陷
- 已解：已修复的缺陷
- 已关闭：确认解决的缺陷
- 重新打，修复验证不通过，被重新打开的缺陷
软件缺陷的生存周期
.JPG)
软件测试充分性
软件测试充分性的度量
https://wenku.baidu.com/view/99f291a081eb6294dd88d0d233d4b14e84243e05.html
ppt中有
软件测试终止准则
软件质量特性（静态特性，动态特性）
静态质量特性
包括结构化的、可维护的、可测试的代码，以及正确和完整的文档
动态质量特性
正确性、可靠性、完整性、一致性、易用性、性能等。
软件正确性：如果软件针对其输入域中的每个元素都能得到正确的结果。
软件质量的可靠性：软件在给定的时间间隔中和给定条件下无故障运行的概率。
易用性：软件使用的难易程度。
完整性：得到说明书中的所有功能。
一致性：对常规惯例和假设的遵循程度
性能：软件完成规定任务完成的时间
软件测试特性（复杂性，经济性）
复杂性
黑盒测试：
需要的输入量太大，测试的输出结果太多，软件实现途径太多，软件规格说明没有一个客观标准。
白盒测试：
穷举路径测试不现实。
经济性：
软件测试只能证明有错。
测试用例的设计步骤
一、测试需求分析
二、业务流程分析
三、测试用例设计
四、测试用例评审
五、测试用例更新完善
测试用例的设计方法（p98）
控制流图
环形复杂度
独立路径
测试覆盖率
语句覆盖率
- 概述：根据每个可执行语句是否被执行，即每行代码是否都被执行了并且被测试了
- 含义：选择足够多的测试数据使被测程序中每条语句至少执行一次
- 要求：达到100%声明覆盖面，每一条语句都要被测试覆盖
- 优点：可以直接应用于目标代码，并且不需要处理源代码
- 缺陷：对一些控制结构是不敏感的，对程序执行逻辑的覆盖很低，往往发现不了判断逻辑中逻辑运算符出现的错误
语句覆盖是最基本的覆盖
判定覆盖率
- 概述：又称分支覆盖，报告在控制结构中是否测试了布尔表达式取值分别为真和假的情况。分支覆盖保证只要程序能跳转，就能跳转到所有可能的目标语句
- 含义：设计足够的测试用例，使每个判定至少都获得一次“真”和“假”，或使得每一个取“真”分支和取“假”分支至少经历一次。
商用软件分支覆盖要求95%
- 优点：具有语句覆盖的简单性且没有语句覆盖所存在的问题
- 缺陷：忽略了在布尔表达式内的分支，当程序中分支的判定由几个条件组合构成时，未必能发现每个条件的错误
分支覆盖不够全面，因此引入条件覆盖
条件覆盖率
- 概述：报告每个布尔型子表达式的结果是真是假，是否都被执行和测试。子表达式是用逻辑与运算符和逻辑或运算符分离开的。条件覆盖检查每个判定点是否被执行和测试
- 含义：构建一组测试用例，使得每一个判断语句中每个子逻辑条件的可能值至少满足一次
条件覆盖100%，分支覆盖不一定100%，反之也是。即二者没有包含关系
条件组合覆盖率
- 概述：条件覆盖和分支覆盖的一个混合
- 归纳：有两者的简单性但是没有两者的缺点。分支/条件覆盖的含义是设计足够的测试用例，使得判定中每个布尔型子表达式的所有可能至少出现一次，并且每个判定本身的判定结果也至少出现一次
分支覆盖率
同判定覆盖率循环覆盖率
路径覆盖率
- 概述：路径覆盖报告是否每个函数的每一条可能的路径都被走过。它检查代码中给定部分每条可能的路径是否都被执行了并且被测试了。一条路径是函数的入口到出口分支里的一个唯一序列
- 优点：进行非常彻底的测试，比判定覆盖强
- 缺陷：路径是以分支的数增加而指数级增加，许多路径由于数据相关不可能被执行
黑盒测试用例设计
等价类设计方法（p45）
等价类划分法是一种典型的、重要的黑盒测试方法，它将说有可能的输入数据（有效的和无效的）划分成若干个等价类。然后从每个部分中选取具有代表性的数据作为测试用例进行合理的分类。测试用例由有效等价类和无效等价类的代表组成，从而保证测试用例具有完整性和代表性。
等价类划分
有两种不同的情况：
- 有效等价类：指对于程序的规格说明而言，是合理的且有意义的输入数据构成的集合。
- 无效等价类：是指对于程序的规格说明来说，是不合理的，无意义的输入数据构成的集合。
等价类的划分方法
具体内容在书上边界值设计方法
程序的很多错误发生在输入或输出范围的边界上，因此针对各种边界情况设置测试用例，可以发现不少程序缺陷。设计的方法
- 边界值分析不是从某等价类中随便挑一个作为代表，而是这个等价类的每个边界都要作为测试条件
- 边界值分析不仅考虑输入条件，还要考虑输出空间产生的测试情况
常见的边界值
- 文本框接受字符个数，比如用户名长度，密码长度等
- 报表的第一行和最后一行
- 数组元素的第一个和最后一个
- 循环的第1次、第2次和倒数第2次，最后一次
因果图设计方法
错误推测方法：利用直觉和经验进行推测发现缺陷
因果法：输入条件比较多 原因就是输入，结果就是输出
导出步骤：
- 分析程度规格说明书的描述中，哪些是原因，哪些是结果
- 分析程度规格说明书的描述中语义内容，并将其表示成连接各个原因与各个结果的“因果图”
- 标明约束条件
- 把因果图转换为判定表
- 为判定表中的每一列表示的情况设计测试用例
基本图形符号：恒等、非（~）、或（∨）、与（∧）
- 恒等，原因是什么，结果就是什么
- 非，与原因情况相反
- 或，几个原因有一个出现，结果出现，只有原因全不出现，结果才不出现
- 与，只有几个原因同时出现，结果才出现，否则，不出现
约束符号：
- E（互斥），两个原因不会同时成立，最多有一个可能成立
- I（包含），三个原因至少有一个必须成立
- 0（唯一），两个原因必须有一个，且仅有一个成立
- R（要求），两个原因，a出现，b也必须出现
- M（屏蔽），两个结果，a为1，b必须为0，但是a为0，b的值是不确定的
![]()
注意，以上几个约束符号只有屏蔽是针对结果的，其余都是对原因的因果图优缺点
- 优点：逻辑清晰
- 缺点：测试用例数量庞大，有些因果关系是不明确的，规模庞大，代价较大
正交试验设计方法
正交试验设计法：是一种成对测试交互的系统的统计方法。它提供了一种能对所有变量对的组合进行典型覆盖（均匀分布）的方法。可以从大量的试验点中挑出适量的、有代表性的点，利用“正交表”，合力的安排试验的一种科学的试验设计方法。
正交表的构成
- 行数：正交表中行的个数，即试验的次数，也是通过正交试验法设计的测试用例的个数
- 因素数：正交表中列的个数，即要测试的功能点
- 水平数：任何单个因素能够取得的值的最大个数，即要测试功能点的取值个数
- 正交表的形式：L行数（水平数因素数）如：L8(27)
设计步骤：
- 确定有哪些因素（功能点）
- 每个因素有哪几个水平（功能点的取值）
- 选择一个合适的正交表
- 把变量的值映射到表中
- 把每一行的各因素水平的组合作为一个测试用例
- 加上你认为可疑且没有在表中出现的组合
如何选择正交表：
正交试验法最大优点：减少测试用例规模和范围
场景图设计：用例场景是用来描述流经用例路径的过程，这个过程从开始到结束遍历用例中所有的基本流和备选流。
这里就要确定哪些是基本流，哪些是备选流
流程图法
算法流程图是针对程序的内部结构的，而黑盒测试的流程图是针对整个系统业务功能流程的
流程图法的步骤：
- 详细了解需求
- 根据需求说明或界面原型，找出业务流程的各个页面以及各页面之间的流转关系
- 画出业务流程
- 写用例，覆盖所有的路径分支
注意点
测试用例的设计方法不是单独存在的
每种类型的软件有各自的特点
每种测试用例设计方法也有各自的特点
针对不同软件利用各种技术
自动化测试（p142）
自动化测试是通过测试工具或其他手段，按照测试工程师预定的计划对软件产品进行自动化的测试，通俗地说就是程序测试程序，用脚本的运行代替手工测试。自动化测试是软件测试的一个重要组成部分，他能够完成部分手工测试无法完成或难以实现的测试工作。
自动化测试流程图
