架构-软件工程5-测试
概述
系统测试是为了发现错误而执行程序的过程，成功的测试是发现了至今尚未发现的错误的测试
测试原则：
- 应尽早并不断的进行测试；
- 测试工作应该避免由原开发软件的人或小组承担；
- 在设计测试方案时，不仅要确定输入数据，而且要根据系统功能确定预期的输出结果；
- 既包含有效、合理的测试用例，也包含不合理、失效的用例；
- 检验程序是否做了该做的事，且是否做了不该做的事;
- 严格按照测试计划进行;
- 妥善保存测试计划和测试用例;
- 测试用例可以重复使用或追加测试。
软件测试类型
软件测试方法可分为静态测试和动态测试。
静态测试
【静态测试】：指被测试程序不在机器上运行，而采用人工检测和计算机辅助静态分析的手段对程序进行检测，包括对文档的静态测试和对代码的静态测试。对文档的静态测试主要以检查单的形式进行，而对代码的静态测试，包括【桌前检查】、【代码审查】、【代码走查】的方式。使用这种方法能够有效地发现30%-70%的逻辑设计和编码错误。
- 控制流分析：是否存在没有使用的语句/无法达到的语句/调用并不存在的子程序。
- 数据流分析：引用未定义的变量、对以前未使用的变量再次赋值。
- 接口分析：模块之间接口的一致性、子程序和函数之间的接口一致性、函数形参与实参的数量、顺序、类型的一致性。
- 表达式分析：括号不配对、数组引用越界、除数为零。
动态测试
【动态测试】：指在计算机上实际运行程序进行软件测试，一般采用白盒测试和黑盒测试方法。
- 黑盒测试：功能性测试，不了解软件代码结构，根据功能设计用例，测试软件功能。
- 灰盒测试
- 白盒测试：结构性测试，明确代码流程，根据代码逻辑设计用例，进行用例覆盖。
测试用例设计
黑盒测试用例
黑盒测试用例：将程序看做一个黑盒子，只知道输入输出，不知道内部代码，由此设计出测试用例，分为下面几类：
- 等价类划分：把所有的数据按照某种特性进行归类，而后在每类的数据里选取一个即可。
- 等价类测试用例的设计原则：设计一个新的测试用例，使其尽可能多地覆盖尚未被覆盖的有效等价类，重复这一步，直到所有的有效等价类都被覆盖为止；设计一个新的测试用例，使其仅盖一个尚未被覆盖的无效等价类，重复这一步，直到所有的无效等价类都被覆盖为止。
- 边界值划分：将每类的边界值作为测试用例，边界值一般为范围的两端值以及在此范围之外的与此范围间隔最小的两个值，如年龄范围为0-150，边界值为0.150，-1.151四个。
- 错误推测：没有固定的方法，凭经验而言，来推测有可能产生问题的地方作为测试用例进行测试。
- 因果图：由一个结果来反推原因的方法，具体结果具体分析，没有固定方法。
- 错误推测：
- 判定表：最适合描述在多个逻辑条件取值组合所构成的负载情况下，分别要执行哪些不同的动作
白盒测试用例
白盒测试用例：知道程序的代码逻辑，按照程序的代码语句，来设计覆盖代码分支的测试用例，主要用于单元测试阶段。可分为：控制流测试、数据流测试、程序变异测试（错误驱动测试）
控制流测试：覆盖级别从低至高分为下面几种：
- 语句覆盖SC：逻辑代码中的所有语句都要被执行一遍，覆盖层级最低，因为执行了所有的语句，不代表执行了所有的条件判断。
- 判定覆盖DC：逻辑代码中的所有判断语句的条件的真假分支都要覆盖一次
- 条件覆盖CC：针对每一个判断条件内的**每一个独立条件都要执行一遍真和假；
- 条件判定组合覆盖CDC：同时满足判定覆盖和条件覆盖
- 路径覆盖：逻辑代码中的所有可行路径都覆盖了，覆盖层级最高
MrCabe度量法
McCabe度量法：又称为环路复杂度，以程序流程图为基础，有三种计算公式：
- 边数-顶点数+2
- 封闭区域个数+1
- 判定节点个数+1（推荐使用方法)
测试阶段
单元测试
也称为模块测试，测试的对象是可独立编译或汇编的程序模块、软件构件或OO软件中的类(统称为模块)，测试依据是软件【详细设计说明书】。
主要是对该软件的模块进行测试，通过测试以发现该模块的功能不符合/不满足期望的情况和编码错误。
由于模块的规模不大，功能单一，结构较简单，且测试人员可通过阅读源程序清楚知道其逻辑结构：
- 首先应通过静态测试方法，比如静态分析、代码审查等，对该模块的源程序进行分析，按照模块的程序设计的控制流程图，以满足软件覆盖率要求的逻辑测试要求。
- 另外，也可采用黑盒测试方法提出一组基本的测试用例，再用白盒测试方法进行验证。若用黑盒测试方法所产生的测试用例满足不了软件的覆盖要求，可采用白盒法增补出新的测试用例，以满足所需的盖标准。其所需的覆盖标准应视模块的实际具体情况而定。对一些质量要求和可靠性要求较高的模块，一般要满足所需条件的组合覆盖或者路径覆盖标准。
集成测试
目的是检查模块之间，以及模块和已集成的软件之间的接口关系，并验证已集成的软件是否符合设计要求。测试依据是软件【概要设计文档】，集成测试通常要对已经严格按照程序设计要求和标准组装起来的模块同时进行测试，明确该程序结构组装的正确性，发现和接口有关的问题。
- 在这一阶段，一般采用白盒测试和黑盒测试结合的方法进行测试，验证这一阶段设计的合理性以及需求功能的实现性。
集成测试策略：
一次性组装【风险高】
增量式组装【测试全面】
自顶向下【需要桩模块】
自底向上【需要驱动模块】
混合式【桩模块和驱动模块都需要】
系统测试
依据【需求文档】。
- 本阶段的主要测试内容包括功能测试、性能测试、健壮性测试、安装或反安装测试、用户界面测试、压力测试、可靠性及安全性测试等。一般情况下，系统测试采用黑盒测试，以此来检查该系统是否符合软件需求。
- 测试人员必须进行多轮回归测试。
- 系统测试的结束标志是测试工作已满足测试目标所规定的需求覆盖率，并且测试所发现的缺陷都已全部归零。
- 【性能测试】：是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。
- 负载测试：各种工作负载下系统的性能
- 压力测试【测上限】：系统的瓶颈或不能接受的性能点
- 强度测试【测下限】：系统资源特别低的情况下运行
- 容量测试【并发测试】：同时在线的最大用户数
- 可靠性测试：MTTF之类的参数
- 负载测试和压力测试都属于性能测试，两者可以结合进行。
- 通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。
- 压力测试是通过确定一个系统的瓶颈或者不能接受的性能点，来获得系统能提供的最大服务级别的测试
- 【验收测试】，属于确认测试的一种。主要用于验证软件的功能、性能和其他特性是否与用户需求一致。根据用户的参与程度，通常包括以下类型：
- 内部确认测试：主要由软件开发组织内部按照SRS进行测试。
- Alpha测试：用户在开发环境下进行测试。
- Beta测试：用户在实际使用环境下进行测试，通过该测试后，产品才能交付用户。
- 验收测试：在真实的用户工作环境下，检验软件系统是否满足开发技术合同或SRS。
其他测试
- AB 测试是为Web 或App 界面或流程制作两个或多个版本，在同一时间维度，分别让组成成分相同(相似)的访客群组(目标人群)随机的访问这些版本，收集各群组的用户体验数据和业务数据，最后分析、评估出最好版本，正式采用。
- Web测试是软件测试的一部分，是针对web 应用的一类测试。由于Web 应用与用户直接相关，又通常需要承受长时间的大量操作，因此Web项目的功能和性能都必须经过可靠的验证。
- 链接测试。链接是Web应用系统的一个主要特征，它是在页面之间切换和指导用户去一些未知地址页面的主要手段。链接测试可分为3个方面。首先，测试所有链接是否按指示那样确实链接到了该链接的页面:其次，测试所链接的页面是否存在:最后，保证Web 应用系统上没有孤立的页面。
- 表单测试。当用户通过表单提交信息的时候，都希望表单能正常工作。如果使用表单来进行在线注册，要确保提交按钮能正常工作，当注册完成后应返回注册成功的消息。如果使用表单收集配送信息，应确保程序能够正确处理这些数据，最后能让用户收到信息。
- 回归测试：测试目的是测试软件变更之后，变更部分的正确性和对变更需求的符合性，以及软件原有的、正确的功能、性能和其他规定的要求的不损害性。
自动化测试
自动化测试：
先写脚本–>自动化执行
不适合场景：项目周期短、需求变动频繁
自动化测试工具主要使用脚本技术来生成测试用例，脚本是一组测试工具执行的指令集合。
脚本的基本结构主要有五种：
- 线性脚本是录制手工测试的测试用例时得到的脚本；
- 结构化脚本具有各种逻辑结构和函数调用功能；
- 共享脚本是指一个脚本可以被多个测试用例使 用；
- 数据驱动脚本是指将测试输入存储在独立的数据文件中，而不是脚本中；
- 关键字驱动脚本是数据驱动脚本的逻辑扩展，用测试文件描述测试用例。