Software Testing

<p><span><font face="SimSun">把程序看作一个黑盒子，在完全不考虑程序内部结构和内部特性的情况下检测每个功能是否正常使用。</font></span></p>

<p><span><font face="SimSun">又称结构测试、透明盒测试、逻辑驱动测试或基于代码的测试</font></span></p>

<p><span><font face="SimSun">不运行程序，只是对程序进行检查和审核</font></span></p>

<p><span><font face="SimSun">使用和运行程序进行检查</font></span></p>

<p><span><font face="SimSun">审查软济南，描绘状态，尝试各种合法可能性，确认状态及其转换正常</font></span></p>

<p align="justify"><span><font face="SimSun">为破坏软件而设计和执行的测试用例</font></span><span><o:p></o:p></span></p>

<p><span><font face="SimSun">依据需求对输入的范围进行细分，然后再分出的每一个区域内选取一个有代表性的测试数据开展测试。</font></span></p>

<p><span><font face="SimSun">被测系统对该等价类中的每个数据的处理方式相同（保证等价）</font></span></p>

<p><span><font face="SimSun">各等价类之间互不相交，即每个数据唯一隶属于一个等价类（保证不冗余）</font></span></p>

<p><span><font face="SimSun">所有等价类的并集是整个输入域（保证完备）</font></span></p>

<p><span><font face="SimSun">对于</font>SRS<font face="SimSun">而言，合理有意义的输入数据构成的集合</font></span></p>

<p align="justify"><span>.</span><!--[endif]--><span><font face="SimSun">对于</font>SRS<font face="SimSun">而言，不合理无意义的输入数据构成的集合</font></span><span><o:p></o:p></span></p>

<p><span><font face="SimSun">最终得到的测试用例完全覆盖所有输入条件的有效等价类的所有组合情况</font></span></p>

<p><span><font face="SimSun">测试用例仅需覆盖所有输入条件的有效等价类即可</font></span></p>

<p><span><font face="SimSun">避免测试工作量过大，并且测试不合理</font></span></p>

<p><span><font face="SimSun">依据需求对输入的范围进行细分，然后再分出的每一个区域内选取一个有代表性的测试数据开展测试</font></span></p>

目标是从理论上追求测试的完备性和无冗余性

在被测对象的边界及边界附近设计测试用例

大量缺陷发生在被测对象的输入域或输出域的边界上

多个输入条件共同构成的具有一定实际意义的输入域

输入条件分别构成的单个输入域的集合

对于每个输入条件的每个边界点(设为P点)，需在该点附近确定大小为1的邻域

测试用例覆盖所有输入条件的所有边界组合可测试到所有的边界组合，但不利于缺陷的隔离和定位

<div>基于单缺陷假设，仅覆盖输入条件的单个边界点即可</div>

强边界+弱边界

典型值法+弱边界法

1.输入域的确定2.边界点的确定3.确定邻域4.测试用例的设计

均衡分散整齐可比

正交试验法是指安排组织试验的一种科学方法。它利用一套规格化的表格，即正交表来设计试验方案和分析试验结果，能够在很多的试验条件中，选出少数几个代表性强的试验条件，并通过这几次试验的数据，找到较好的生产条件，即最优的或较优的方案

1.选择个体输入域，确定所有输入条件及其最大取值范围2.确定每个输入条件的取值个数3.选择合适的正交表4.建立正交表5.生成测试用例

<div>当输入条件较多，并且条件中参数值较多，若组合设计用例数量较大，则考虑使用正交实验法设计测试用例</div>

<div>是一个用表格形式来整理逻辑关系的工具，由横向的条件（因）和动作（果）和纵向的规则（测试用例）组合而成</div>

1.分析条件和动作2.生成决策表3.简化决策表4.转成测试用例

最少的场景数等于事件流的总数，基本流与备选流的总数2.有且唯一有一个场景仅包含基本流3.对应某个备选流，至少应有一个场景覆盖，且在场景中应该避免覆盖其他备选流

通过分析不同事件的触发顺序和处理结果；构建各个事件流，并基于这些事件的触发控制业务流程，形成多个不同的场景，最终基于场景设计测试用例

从系统的某个初始状态开始，经一系列状态变化后到达终止状态的过程中最主要的一个业务流程。

以基本流为基础，在经过基本流每个判定节点处满足不同的触发条件从而导致其他事件流

用图解的方法表示输入输出之间的各种组合关系，写出判定表，从而设计相应的测试用例

1.分析需求2.找出因果关系，原因与原因之间的关系，画出因果图3.将因果图转换成决策表4.根据（3）中的决策表，设计用例的输入数据和预期输出

<div>应用的输出结果依赖于各种输入条件的组合或各种输入条件之间有某种相互制约关系时</div>

从需求中找出因(输入条件)和果(输出或程序状态的改变)，通过因果图转化成判定表，通过判定表生成测试用例的方法。

是一种基于产品规格分析，对系统的每个状态及与状态相关的函数进行测试，通过不同的状态验证程序的逻辑流程

<div>1.根据需求，理解关键字段，获得主要的状态</div><div>2.绘制状态迁移图</div><div>3.画出状态迁移树</div><div>4.抽取测试用例规则（每个状态至少到达一次）</div>

针对性强、测试效率高、成本低

对函数代码和结构的测试

不需要实际运行被测软件，而是直接对软件源代码的形式和结构进行分析

代码检查、静态结构分析、代码质量度量

代码检查主要是通过同行评审(Peer Review)来发现缺陷

同行评审往往需要大量投入时间和人力资源

促使参与者在有监督压力下工作，提高责任心、有助于在开发早期发现需求和设计中的缺陷、有助于帮助程序员发现不足，提高工作质量

审查、团队评审、走查、结队编程、同行桌查、轮查、特别检查

优先测试根节点、然后叶子节点、然后接口数量多的节点

在远离代码的条件下对程序进行分析、需要通过源代码评审、后续的动态白盒测试来进一步对源代码进行测试覆盖，以期找到更多潜伏的软件缺陷

列出所有简单判定条件；<br>构建真值表；<br>对每个简单判定条件，找到能对整个判定结果产生独立影响的测试用例集合（简称独立影响对），即在真值表中依次固定其他简单判定条件，找到该条件的独立影响对；<br>抽取能体现所有简单判定条件独立影响性的最少独立影响对。

语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖、修正的判定/条件覆盖

尽量选择边界测试数据、应避免与或关系的屏蔽现象

设计测试用例，是被测程序中每一条路径至少执行一次（不一定能满足条件覆盖，一定满足判定覆盖）

压缩后的控制流图、特殊形式的有向图

程序结构复杂度的度量模型（不能超过10）

e图中的边数n图中节点个数

V(G)=P+1

通过对程序图中结构化设计节点不断进行压缩

在循环的边界和运行的界限内对循环体的执行过程进行测试

串联、嵌套、非结构化的循环

变量在使用之前未被定义、变量被定义但未被使用、变量在使用之前被多次定义

<font face="宋体">软件（</font>Software<font face="宋体">）</font><font face="Calibri">=&nbsp;</font><font face="宋体">程序（</font><font face="Calibri">P</font><font face="宋体">）</font><font face="Calibri">+</font><font face="宋体">数据（库）（</font><font face="Calibri">DB</font><font face="宋体">）</font><font face="Calibri">+</font><font face="宋体">文档</font><font face="Calibri">(D)+</font><font face="宋体">服务</font><font face="Calibri">(S)</font>

程序的定义

数据的定义

文档的定义

服务的定义

<font face="宋体">（</font><span>1</span><font face="宋体">）软件靠人的智力劳动创造出来，并且还有较大的随意性。</font>

<font face="宋体">（</font>2<font face="宋体">）软件必须依托于具体的硬件设备才能运行，硬件的改变很可能导致软件的不可用。</font>

<font face="宋体">（</font>3<font face="宋体">）软件不会磨损，但会经常维护和升级，测试升级后的软件注意对旧版本的兼容性</font>

<span>软件测试是使用人工和自动化手段来运行或测试某个系统的过程，其目的在于检验被测试软件系统是否满足规定的需要，或是弄清楚被测系统的预期结果与实际结果之间的差别。</span>

<span>软件测试的根本目的是确保软件满足用户需求。</span>

<span>软件测试的目的是要衡量软甲产品是否符合预期。</span>

<span>软件测试是一个持续进行的过程。</span>

<span>提高软件质量、确保软件满足需求。</span>

<span>软件测试不负责修复缺陷，并且受到时间、成本等方面的限制，不是所有发现的缺陷都能及时被修复</span>

<span><font face="SimSun">软件测试员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好、软件未达到需求规格说明书中指明的功能、软件出现了需求规格说明书中指明不该出现的错误、软件功能超出需求规格说明书中指明的范围、软件未达到需求规格说明书中虽未指出但应达到的目标。</font></span>

<p><span><font face="SimSun">一组测试输入执行条件和预期效果</font></span></p>

<p><span><font face="SimSun">通过测试工具、测试脚本等手段，按照测试工程师的预定计划对软件产品，进行自动化调试，从而验证软件是否满足用户的需求。</font></span></p>

<p><span><font face="SimSun">初始阶段、定义阶段、集成阶段、管理、测量和最佳化阶段</font></span></p>

国外现状

国内现状

人才需求大、职业稳定、无性别歧视、但仍需掌握一定的业务能力和技术能力

现场测试模式

内部测试模式

设立联合研究中心模式

<p align="justify"><span><font face="SimSun">软件测试工程师有扎实的理论基础、软件开发工程师帮助分析复杂需求，提高代码质量</font></span><span><o:p></o:p></span></p>

<p><span><font face="SimSun">软件开发的全部过程、活动、任务和管理的结构框架。</font></span></p>

<p><span><font face="SimSun">瀑布模型、边做边改模型、喷泉模型、快速原型模型、</font>RAD<font face="SimSun">模型、基于构件的开发模型</font></span></p>

优点：思路简单

缺点：<p><span><font face="SimSun">开发过程是非工程化的，随意性大，结果不可预知，除此之外开发任务完成之后，修复较困难</font></span></p>

<p><span><font face="SimSun">简单考虑到了软件的需求，产品周期短</font></span></p>

<p><span><font face="SimSun">没有计划和文档的编制</font>&nbsp;但<font face="SimSun">测试工作</font><font face="SimSun">由于新的版本不断产生，测试工作长期循环</font></span></p>

瀑布模型的使用步骤

<p><span><font face="SimSun">瀑布模型的优点：结构性强、将软件生存周期各个活动规定为依次线性顺序连接的若干阶段的模型、易理解，阶段明显，强调需求分析，明确测试阶段，提供了一套模板</font></span></p>

<p><span><font face="SimSun">瀑布模型的缺点：线性严格，成果晚出，风险大、阶段固定，反复迭代不合适，灵活性差、单次需求，需求变更多，适应性差、测试滞后，缺陷晚查，代价大</font></span></p>

<p><span><font face="SimSun">瀑布模型适合在功能、性能明确完整，需求固定，无重大变动的场景，如操作系统，数据库管理系统</font></span></p>

<p align="justify"><span><font face="SimSun">敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发，同时软件项目在构建初期被切分成多个子项目，各个子项目成果都经过测试，具备可视、可集成和可运行使用的特征</font></span><span><o:p></o:p></span></p>

<p><span><font face="SimSun">熟悉需求、拟定测试计划、设计测试用例</font>/<font face="SimSun">开发测试脚本、搭建测试环境、实施测试、测试评估、测试总结</font></span></p>

<p><span><font face="SimSun">阅读相关说明、阅读有关资料、提出疑问、站在用户角度进行需求评审</font></span></p>

<p><span><font face="SimSun">在软件测试工作正式实施之前明确测试的对象，并且通过对资源、时间、风险、测试范围和预算等方面的综合分析和规划，保证有效的实施软件测试。</font></span></p>

<p><span><font face="SimSun">为实施测试而向被测试系统提供的输入数据、操作或各种环境设置及期望结果等信息的一个特定集合</font></span></p>

<p><span><font face="SimSun">理解测试思路，避免遗漏</font></span></p>