软件测试过程

目录

软件测试与软件工程模型

 软件测试的阶段

         1.单元测试

        单元的粒度

        单元测试完成人

        单元测试的目标

        1. 正确性：

        2. 清晰性：

        3. 规范性、一致性：

         4. 高效性：

        单元测试的辅助模块

         驱动模块（driver）：

        桩模块（stub）：

单元测试的测试环境

单元测试采用的技术

        1．静态测试

        2．白盒和黑盒测试相结合

单元测试的考虑点

 2. 集成测试

        概念

        集成测试的必要性

        ① 一个模块可能对另一个模块产生不利的影响

        ② 将子功能合成时不一定产生所期望的主功能。

        ③ 独立可接受的误差，在多个模块组装后可能会被放大，超过可接受的误差限度。

        ④ 可能会有单元测试中未发现的接口方面的错误。  

        ⑤ 在单元测试中无法发现时序问题。

        ⑥ 在单元测试中无法发现资源竞争问题

        ⑦ 共享数据或全局数据的问题  

         ⑧ 数据单位、环境参数不统一的问题

 集成测试的层次

 集成测试的策略

        非增量式测试

         增式测试

 集成测试方法对比

集成测试技术和人员

3.系统测试

系统测试采用的测试技术

系统测试的人员

系统测试的分类

        功能测试

        兼容性测试 ：

        安装测试：

        界面测试：

        性能测试：

安全测试 

4.验收测试

        概念：

        验收测试的人员

        验收测试的分类

β测试优点：

        1. 可以节约大量测试成本

        2.可以大幅度缩短测试时间  

        3.大范围获得用户反馈，以利于软件的改进和完善。

        4.可以尽快填补市场空间，占领市场

        5. 对于收费软件，可以通过免费的β版，吸引和培养用户。

用户正式验收测试        

5.回归测试

概念

目的

关于回归测试的认识误区      

回归测试的特点

         复用

        自动化

回归测试策略     

---

软件测试与软件工程模型

        

 软件测试的阶段

        

        软件测试的不同阶段，被测试对象和测试依据是不同的。

         1.单元测试

         单元测试是针对软件设计的最小单位——程序模块，进行检查和验证，确保每个模块能正常工作。

        单元测试中的一个可测“单元”应符合以下要求：  

        (1)是可测试的、最小的、不可再分的程序模块。

          (2)有明确的功能、规格定义。

          (3)有明确的接口定义，清晰地与同一程序的其他单元划分开来。

        单元的粒度

         单元测试是对软件基本组成单元的测试，单元的粒度具体划分可以不同，例如：

          结构化编程语言如C语言中，单元一般是函数或子过程；

         C++中，单元是类或类的方法；

        单元测试完成人

         单元测试通常是由程序员自己来完成，有时测试人员也加入进来，但编程人员仍会起到主要作用。  单元测试是程序员的一项基本职责，程序员有责任对自己编写的代码进行单元测试。程序员必须对自己所编写的代码保持认真负责的态度，这是基本职业素质之一。  单元测试能力也是程序员的一项基本能力，这种能力的高低直接影响到程序员的工作效率与软件的质量。

        单元测试的目标

        1. 正确性：

        代码逻辑必须正确，能够实现预期的功能。    

        2. 清晰性：

        代码必须简明、易懂，注释准确没有歧义。      

        3. 规范性、一致性：

        代码必须符合企业或部门所定义的共同规范包括命名规则，代码风格等。    

         4. 高效性：

        代码不但要满足以上性质，而且需要尽可能降低代码的执行时间。 ... ...

        单元测试的辅助模块

         驱动模块（driver）：

        :对底层或子层模块进行测试所编写的调用这些模块的程序。可理解为被测单元的主程序。  

        桩模块（stub）：

        对顶层或上层模块进行测试时所编写的替代下层模块的程序。

        ​​​​

单元测试的测试环境

         驱动模块和桩模块的编写会产生一定的工作量，带来额外的开销。特别是桩模块，为了能够正确、充分的测试软件，桩模块可能需要模拟实际子模块的功能。

        例如，某工资计算程序根据输入的年月计算当月工资，计算方式与当月天数有关： 30天：6000元 31天：6000+300元 29天：6000-100元 28天：6000-300元

        程序实现时分为三个子函数 getSalary(year,month) getWorkDays(year,month) isLeap(year) 测试getSalary()时若getWorkDays()尚未开发完成，则需要用一个桩函数替代，例如：

单元测试采用的技术

        1．静态测试

        通过静态检查发现代码的逻辑错误，其次还要检查代码的清晰性、规范性、一致性，反复执行的代码，还需要分析算法是否高效。

        2．白盒和黑盒测试相结合

        通过设计测试用例，执行被测程序，比较实际结果与预期结果以发现程序中的错误。

单元测试的考虑点

        算法和逻辑 模块接口 数据结构（全局和局部） 边界条件 错误处理 ......

 2. 集成测试

        概念

         集成测试（也叫组装测试、联合测试）：把多个经过单元测试的模块按照软件概要设计书组装起来进行测试，检查模块组装后，其功能实现情况、模块接口连接情况、数据传递等是否正确、符合要求。

        集成测试的主要依据是软件的概要设计书，即验证程序和概要设计说明的一致性。

        集成测试的必要性

        ① 一个模块可能对另一个模块产生不利的影响

         例如，A 模块发送数据，B 模块接收数据并进行加工，如果 A 模块发送数据的速度快于 B 模块加工数据的速度，则两个模块集成起来后连续工作的时间长了，就会出现阻塞或者是数据丢失。

        ② 将子功能合成时不一定产生所期望的主功能。

         例如，某成绩管理软件，把成绩输入功能设计成两个子功能，输入百分制成绩和输入五级记分制成绩，但集成测试时发现，这两项子功能合起来并不能覆盖所有可能的成绩输入，因为成绩输入时还可能出现“缺考”、“作弊”等特殊情况！

        ③ 独立可接受的误差，在多个模块组装后可能会被放大，超过可接受的误差限度。

        某计算利息的程序，计算过程是模块 A 由年利率计算得出单日的利率 I_day，计算结果提供给模块 B 乘以金额和天数，得出总的利息 I_all。设年利率为 3%。 如果 I_day 保留 5 位小数，则 I_day ≈ 0.00008，设某客户存款 1 亿元，存期 100 天，算出的利息为 80万元。 如果 I_day 保留 7 位小数，则 I_day ≈ 0.0000822，算出的利息应为 82.2万元。 这两者之间的误差达到了 2.2 万元。

        ④ 可能会有单元测试中未发现的接口方面的错误。  

        例如模块 A 有三个形式参数（Str_1，Str_2，Str_3)，功能：把 字符串Str_1 中的子串Str_2 去掉后保存到 Str_3中。 模块 B 调用模块 A 时参数位置写反了，把原始字符串作为第二个参数，而把要删除的字符串作为了第一个参数。  这种情况单元测试时有可能没有发现，因为单元测试主要关注模块内部的具体实现，只能通过集成测试发现。

        ⑤ 在单元测试中无法发现时序问题。

        某购票软件中有购票和退票模块，单独运行时都没有问题。当购票和退票模块并发执行，出现了时序错误

        ⑥ 在单元测试中无法发现资源竞争问题

        例如，A 模块和 B 模块运行时都同时需要资源 X 和 Y，当前运行环境下资源 X 和 Y 各有 1 个，A 模块先申请到了资源 X ，B 模块先申请到了资源 Y，然后 A 模块等待资源 Y，B 模块等待资源 X， A、B 陷入死锁。

        ⑦ 共享数据或全局数据的问题  

        例如，成绩管理软件中，成绩是全局数据，在输入模块获得初值后传入统计模块进行统计。但集成测试时发现，输入模块为方便接收各种不同类型的成绩，把成绩数据默认为字符类型，而在统计模块，为便于计算，把成绩数据默认为数值类型，这样两个模块一对接，就出现了数据类型不一致的问题。

         ⑧ 数据单位、环境参数不统一的问题

        例如，某收费软件系统中有两个模块单元，一个称重，一个计费，但称重模块中重量单位为克，而计费模块中把重量的数据单位默认为公斤。

 集成测试的层次

 集成测试的策略

        非增量式测试

        也称大爆炸式集成，采用一步到位的方法来构造测试：对所有模块进行单元测试后，按程序结构图将各模块联接起来，把联接后的程序当作一个整体进行测试。

        非增量式一次性集成：在对软件所有模块逐个进行单元测试后，采用一步到位的方法来构造测试，按程序结构图将各个模块单元全部联接起来，把联接后的程序当作一个整体来进行测试。

        一次性集成的优点有： ①集成次数少，能快速完成集成测试 ②所需测试用例较少，测试工作量较小 ③不需要辅助性的驱动模块和桩模块    

        一次性集成的缺点包括： ①发现错误的时间较迟 ②错误较难定位 ③测试不够充分和彻底，即使通过测试，程序中可能还隐藏着一些错误 ④测试的并行性差

        一次性集成适用的情况主要是： ① 小型的、良构的软件系统 ② 一个已经存在的软件系统，只是做了少量的修改 ③ 通过复用可信赖的构件构造的软件系统

         增式测试

        把下一个要测试的模块同已经测试好的模块结合起来进行测试，一次增加一个测试的模块。

       增量式集成： 增按照某种次序关系，先把一部分模块组装起来进行测试，然后逐步扩大集成的范围，最后再把整个程序组装起来完成集成测试。

        实施方法： 自顶向下结合 自底向上结合

        自顶向下增式测试集成步骤： 主控模块作为测试驱动，所有与主控模块直接相连的模块作为桩模块； 根据集成的方式（深度或广度），每次用一个替换从属的桩模块； 在每个模块被集成时，都必须已经进行单元测试；

        自底向上增式测试集成步骤：组装从最底层的模块开始，组合成一个构件，用以完成指定的软件子功能。 编制驱动程序，协调测试用例的输入与输出。 测试集成后的构件。 按程序结构向上组装测试后的构件，同时除掉驱动程序。

           增式测试优点： ① 集成测试可以较早的开始，测试的并行性较好 ② 发现错误的时间较早 ③ 错误定位较为容易 ④ 测试比较充分

        增式测试：缺点： ① 需要驱动模块和桩模块等辅助模块 ② 所需集成次数较多 ③ 所需测试用例较多，测试工作量较大

        适用情况： ① 增量式开发、框架式开发 ② 并行软件开发 ③ 较为复杂或者有一定规模的系统

 集成测试方法对比

	非增式测试	增量式测试
集成次数	少，仅需1次	多
集成工作量	小	大
所需测试用例	少	多
驱动模块和桩模块	不需要	需要
发现错误的时间	较晚	早
错误定位	难	较容易
测试程度	不彻底	较为彻底
测试的并行性	差	较好
适用情况	结构良好的小型系统；原有系统做了少量的修改；通过复用可信赖的构件构造的软件系统。	增量式开发、框架式开发；并行软件开发；较为复杂或者有一定规模的系统。

集成测试技术和人员

           集成测试主要测试软件的结构问题，因为测试建立在模块的接口上，所以多为黑盒测试，适当辅以白盒测试。 集成测试工作一般由开发人员或者开发人员和测试人员共同完成。

3.系统测试

         购买某个产品时会从多个角度考虑它是否和我们的预期相符。

        不仅检验软件是否满足用户的功能需求，还需要进行一系列非功能性测试。

         系统测试是将经过集成测试的软件与计算机硬件、数据、网络、支撑软件及第三方软件等综合在一起，进行一系列测试；以验证系统在功能性性能、易用性、可靠性等方面是否满足用户需求和预期。

        在尽可能模拟真实运行环境下，软件系统是否与需求规格说明相一致；检验软件UI是否美观、操作是否便捷等。

系统测试采用的测试技术

        系统测试基本完全采用黑盒测试技术，因为这时已不需要考虑组件模块的实现细节，而主要是根据需求分析时确定的标准检验软件是否满足功能、性能和安全等方面的要求。

系统测试的人员

         系统测试应有一定的独立性，应由独立的测试小组在测试组长的监督下进行，测试组长负责保证在合理的质量控制和监督下使用合适的测试技术执行充分的系统测试。  

        在系统测试过程中，可以有一个独立的测试观察员来监督测试过程，也可考虑邀请用户代表参与测试过程，同时得到用户反馈意见，并在正式验收测试之前尽量满足用户的要求。

系统测试的分类

        功能测试

         功能测试是首要。  功能逻辑清楚, 系统的各种状态按照业务流程而变化，并保持稳定, 每项功能符合实际要求  菜单、按钮操作正常、灵活，能处理一些异常操作  能接受正确的数据输入，对异常输入的容错处理  数据的输出结果准确，格式清晰，可以保存和读取   ……  并不是每一种测试项目都必须要进行，可根据软件的特点和实际需要，选做系统测试项目。

        兼容性测试 ：

        兼容性测试是针对被测软件与其他软件之间，以及被测软件与不同硬件之间的兼容性进行的测试。兼容测试应包括以下内容： 与操作系统的兼容性 与硬件的兼容性 与其它软件的兼容性 与数据库的兼容性 与软件所用到的各种数据的兼容性

        安装测试：

        验证软件在正常情况能够顺利安装，在安装后能立即正常运行；在异常情况下（如磁盘空间不足、缺少目录创建权限），安装不会出现不良后果，并给出必要提示或者警告。重点关注： 在安装过程中给用户的提示是否清楚明了、 安装过程是否太冗长、系统设置是否正确、 安装完成后软件是否能正常运作、 安装过程有没有干扰其他的程序 等。

        界面测试：

        图形用户界面（简称GUI）需要测试的对象主要是窗口、菜单、鼠标操作、提示信息等。 窗口能否正确打开、改变大小和移动、窗口中的下拉式菜单、工具条、滚动条、输入框、按钮等控件是否显示正确又完全可用、多次或不正确按鼠标是否会产生无法预料的结果、窗口能否正确被关闭等； 菜单显示是否正确、菜单操作能否正确进行、菜单功能是否正确、菜单项能否随当前的适用情况正常显示或变灰，即当前不能用的菜单项是否变成灰色显示等； 是否有必要的提示信息、提示信息是否简明、准确、完备、是否使用过于专业的术语等。

        性能测试：

        性能测试（performance testing）是为了发现系统性能问题或获取系统性能相关指标而进行的测试。一般在真实环境、特定负载条件下，通过工具模拟实际软件系统的运行及其操作，同时监控性能各项指标，最后对测试结果进行分析来确定系统的性能状况。

        性能测试的目的 获取系统性能某些指标数据 验证系统是否达到用户提出的性能指标 发现系统中存在的性能瓶颈，优化系统的性能。

        不同视角的系统性能： 用户视角：响应时间、处理速度。 系统运维人员视角：不仅关注响应时间，更关注系统支持的并发数、并发数达到一定规模后系统的响应时间、服务器的CPU使用率、内存占用率、网络带宽占用率等。 开发人员视角：更加关注系统的性能瓶颈在什么地方、引起系统性能衰退的原因是什么、如何才能提高系统的性能等。

        性能测试一般通过自动化测试工具模拟多种正常、峰值、以及异常负载条件和使用场景组合，对软件系统的各项性能指标进行测试； 目标是检验软件系统是否具备其宣称的能力 。 系统性能受很多因素影响，在进行性能测试时，需要明确给出测试环境。

        常见指标 ：响应时间：从用户角度看，系统对请求作出响应所需要的时间。 吞吐量：单位时间内系统处理客户请求的数量。 并发数：系统可以同时承载的正常使用系统功能的用户的数量。 资源利用率：运行软件系统的服务器的资源占用情况 ... ...

        某ATM系统性能测试示例

编号	场景名称	并发用户数	平均响应时间	平均吞吐量	CPU使用	内存占用
1	查询卡余额	100	0.187	36.8	65%	76%
2	取款	200	0.681	34.7	78%	81%
3	查询卡余额	200	0.217	35.1	72%	81%
4	存款	100	0.560	36.2	76%	88%
5	存款	200	0.633	35.7	78%	89%
.....

安全测试 

        安全测试（security testing）用于检验系统权限设置有效性、防范非法入侵的能力、数据备份和恢复能力等，设法找出上述各种安全性漏洞。

        安全功能测试 (Security Functional Testing)：数据机密性、完整性、可用性、不可否认性、身份认证、授权、访问控制、审计跟踪、委托、隐私保护、安全管理等。 安全漏洞测试 (Security Vulnerability Testing)：从攻击者的角度, 以发现软件的安全漏洞为目的。安全漏洞是指系统在设计、实现、操作、管理上存在的可被利用的缺陷或弱点。

        SQL注入攻击例子： 某个网站的登录验证SQL查询代码为： strSQL = "SELECT * FROM users WHERE name = '" + userName + "' and pw = '"+ passWord +"';" 若恶意填入： userName = "1' OR '1'='1"; passWord = "1' OR '1'='1"; 则最终SQL语句变成： strSQL = "SELECT * FROM users WHERE name = '1' OR '1'='1' and pw = '1' OR '1'='1';" WHERE条件恒为真，相当于执行： strSQL = "SELECT * FROM users;"

        常见的安全测试方法有静态测试、模糊测试等。

        静态测试：代码安全审查和安全走查、漏洞扫描、漏洞检测。

        模糊测试 ：在一个被测试程序中附加上随机数据（fuzz）作为程序的输入。如果被测试程序出现问题（例如 Crush ,或者异常退出、健壮性差、缓冲区溢出等）。

4.验收测试

        系统测试之后.........软件开发和测试人员不可能完全预见用户实际使用软件的各种情况和各种具体的细节要求。 例如，用户可能错误的理解功能，误操作，或输入一些特殊的数据组合，也可能对软件设计者自认为简单明了的输出信息迷惑不解。  软件是否能真正满足最终用户的需求，应由用户进行“验收测试”。

        概念：

        验收测试是指，以用户为主导，测试即将正式发布、投入使用的软件产品是否符合用户各方面的需求。  

        验收测试主要以开发合同为依据，并结合需求规格说明书和相关标准对软件系统进行一系列检查，验证软件质量是否达标。

        验收测试的人员

        验收测试应当由用户为主导，软件开发人员、测试人员、项目经理以及软件质量保证人员一起参与。

        验收测试的分类

         软件根据用户的情况可以分为专用软件和通用软件，针对这两类不同的软件，可以采用不同的验收测试策略。 1. 对于用户数量众多的通用软件，可以采用 α测试和β测试的方式； 3.而对于针对特定用户的专用软件，则可以采用最终用户正式验收的方式。

        α测试和β测试：  一个通用软件产品，可能拥有成千上万的用户，甚至于更多，例如腾讯QQ的注册账号数达到数以亿计。   对于这样的软件，不可能要求每个用户都来对软件产品进行验收测试，此时多采用α、β测试。 α测试是软件公司组织内部人员，模拟各类用户行为，对即将面市的软件产品进行测试，此时的软件版本可称为α版，也叫内测版。 β测试由软件的多个用户在实际使用环境下进行的测试，这些用户返回有关错误信息给开发者，该测试是在开发者无法控制的环境下进行的软件现场应用，此时的软件版本被称为β版，也叫公测版。

        β测试： β 测试反馈的问题、意见和建议并不是专职测试人员撰写的测试报告，需要加以整理和分析；  有的可能毫无价值，只能被忽略掉；有的可能具有特殊性或者带有很强的主观性，只代表特殊情况或者是少数用户的感受和想法；  但这样也可以发现更多软件在适应各种情况或者是满足不同用户感受等方面的缺陷和不足。

β测试优点：

        1. 可以节约大量测试成本

          β 测试由于引入用户参与到了软件测试工作当中，可以充分利用用户资源节约成本。  例如，某软件在 β 测试环节，共收到来自3万用户使用该测试版本的有效反馈，梳理出软件问题1000个，而成本几乎为0。但如果要让3万名测试员来对该软件版本进行测试，或者是要通过测试员来找出这1000个软件问题，测试成本可能是数以十万、百万计。

        2.可以大幅度缩短测试时间  

        β 测试通过引入大量用户来并行完成测试过程，可以在短时间内实现对软件的大量测试，从而能够缩短测试所需的时间。  例如，某 APP 在  β 版推出之后一周之内，就累计测试运行达到 16 万小时，大约相当于单机测试 20 年。

        3.大范围获得用户反馈，以利于软件的改进和完善。

           β 测试通过大量并且分散的用户参与，可以广泛获得来自不同用户的信息反馈，这些反馈代表不同的软件执行环境条件和不同用户的观点，有利于综合各种情况，集思广益，对软件进行改进和完善。

        4.可以尽快填补市场空间，占领市场

         在有用户需求的时候，一个并不完善的软件产品，总还是要好过没有这样的产品，在某种应用刚开始兴起的时候，快速开发出相应产品，然后以 β 版的形式推出，可以快速填补市场空间，占领市场。

        5. 对于收费软件，可以通过免费的β版，吸引和培养用户。

         对于收费软件而言，有的用户不愿意贸然花钱购买。而通过推出 β 版，可以吸引用户先免费试用，等到收费的正式版推出时，用户可能已经喜欢或者习惯于使用该软件，从而会花钱购买。

用户正式验收测试        

        针对特定用户的专用软件，用户面很小，并且可能还涉及到复杂的现场安装、部署、调试等，应当采用最终用户正式验收的方式。 例如某汽车生产企业的 ERP 软件、某钢铁厂的生产控制软件等，这样的软件基本上都是针对某个用户定制的，一个软件版本可能只有一个用户，软件投入正式使用之前，还需要到现场进行有针对性的安装和部署，由该软件的最终用户在具体的应用场景下对其进行验收测试。

5.回归测试

概念

         回归测试是指，在对软件代码进行修改之后，重新对其进行测试，以确认修改是正确的，没有引入新的错误，并且不会导致其他未修改的代码产生错误。

        回归是指回到原来的状态，通常被认为是“程序重新确认”。软件的改变可能是由于发现了错误并做了修改，也有可能是因为加入了新的模块。 回归测试需要测试的对象不仅仅是软件中发生了修改的部分，还需要对整个软件重新进行测试。 例如，某软件修改了登录模块，将原来只能用手机号码登录改为允许用手机号码或者昵称登录。 软件修改后，单独测试登录模块没有发现问题，但在用户留言模块发现了问题。原因是，留言模块中用户标识字段只有11位，因为原来版本中用户都是用11位手机号码登录的，现在当用户用昵称登录，并且昵称超过11位时，用户标识会被截断，导致留言保存后就关联不到用户了。

目的

         回归测试的目的是为了检查验证修改的正确性以及修改对其它部分的影响。

关于回归测试的认识误区      

        回归测试并不是软件测试工作中跟在验收测试之后的第 5 个测试阶段，而是在软件开发的各个阶段都有可能会进行多次回归测试。      

          回归测试不是一项新的测试活动，它是为检查是否因修改软件而引入新的错误而对软件再次进行测试的过程。

        在增量式开发、快速迭代开发、极限编程等开发模式以及版本快速更新的运维模式中，回归测试进行得更加频繁，有的甚至要求每天都进行若干次回归测试。

回归测试的特点

         复用

         回归测试当中，除了对新增加或者作修改的代码进行测试时，可能会要增加新的测试之外，其它可以复用以前已经做过的测试，这样可以节约一部分工作量。例如测试前一版本时用的测试方案、测试设计、测试用例等都可以直接或者修改后重复使用。

        自动化

         回归测试通常是前面已经执行过的测试过程的重复，通过自动化的回归测试，可以降低测试成本，节约测试时间。  

回归测试策略     

        关注关键性模块，包括发生修改的模块和与发生修改的模块存在耦合的模块。  

         提高自动化水平。回归测试过程存在大量的重复测试，也适合于采用自动化的方式来完成。

        维护测试用例库。软件修改后，一些测试用例可能会失去针对性和有效性，必须对用例库进行维护，包括追加新的用例来测试软件新增的功能或特征。

        优选回归测试包。根据情况优选一个缩减的回归测试包来完成回归测试。例如采用代码相依性分析等安全的缩减技术，决定哪些测试用例可以被删除而不会让回归测试的效果受到影响。