软件测试复习与几道常见题型

第一章

1.1 软件测试定义

1.软件测试的理解：

软件测试的正向理解 ：验证软件是否符合用户需求，给用户以信心。

软件测试就是为程序或系统能够按预期设想运行而建立信心的过程。
软件测试是一系列活动以评价一个程序或系统的特性或能力并确定是否达到预期的结果”。
测试是为了验证软件是否符合用户需求，即验证软件产品是否能正常工作。

软件测试的反向理解：发现错误

测试是为了证明程序有错，而不是证明程序无错误
一个好的测试用例是在于它能发现至今未发现的错误
一个成功的测试是发现了至今未发现的错误的测试

2.软件测试狭义和广义概念：

狭义的软件测试
仅仅指动态测试，即运行程序或系统以发现缺陷或验证是否满足需求、是否能正常工作。
广义的软件测试

不仅是运行程序或系统而进行测试，还包括需求/设计/代码等评审活动。
静态测试+动态侧试

3.测试=V&V 验证与确认

“验证(Verificationy）”是检验软件是否已正确地实现了产品规格书所定义的系统功能和特性
“有效性确认（Validation）”是确认所开发的软件是否满足用户真正需求的活动

1. 黑盒，白盒，静态，动态测试（四个组合）

单元测试(unit testing)：单元测试又称模块测试，针对软件设计中的最小单位——程序模块，进行正确性检查的测试工作。单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试。
集成测试(integration testing)：集成测试又叫组装测试，通常在单元测试的基础上，将所有程序模块进行有序的、递增的测试。重点测试不同模块的接口部分。

1.什么时候进行集成测试br> ? 单元测试&集成测试同步进行，理论上先有单元测试。
2.由谁来做集成测试br> ? 白盒测试工程师或者开发工程师
3.集成测试的依据br> ? 单元测试的模块+《概要设计》文档。

系统测试(system testing)：指的是将整个软件系统看为一个整体进行测试，包括对功能、性能、以及软件所运行的软硬件环境进行测试。
目前系统测试主要由黑盒测试工程师在系统集成完毕后进行测试，前期主要测试系统的功能是否满足需求，后期主要测试系统运行的性能是否满足需求，以及系统在不同的软硬件环境中的兼容性等
验收测试(acceptance testing)：验收测试指按照项目任务书或合同、供需双方约定的验收依据文档进行的对整个系统的测试与评审，决定是否接收或拒收系统。在系统测试的后期，以用户测试为主或有测试人员等质量保证人员共同参与的测试。
它包括Alpha测试和Beta测试，系统开发生命周期方法论的一个阶段，由相关的用户和/或独立测试人员根据测试计划和结果对系统进行测试和接收。它让系统用户决定是否接收该系统。它是一项确定产品是否能够满足合同或用户所规定需求的测试。这是管理性和防御性的控制。
α测试：指的是由用户，测试人员、开发人员等共同参与的内部测试。既可以是一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试。Alpha测试由程序员或测试员完成。
β测试：指的是内测后的公测，即完全交给最终用户测试软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场，Beta测试不能由程序员或测试员完成。验收测试的重要性：验收签字,收钱。

3.功能测试、性能测试

功能测试(function testing)：是黑盒测试的一方面，它检查实际软件的功能是否符合用户的需求。
? 逻辑功能测试(function testing)
? 界面测试(UI testing)
? 易用性测试(usability testing)
? 安装测试(installation testing)
? 兼容性测试(compatibility testing)
性能测试（performance testing）：Performance testing，在一定的负载情况下，系统的响应时间、资源利用、效率等特性是否满足特定的性能需求。
是软件测试的高端领域，性能测试工程师的待遇和白盒测试工程师不相上下，通常我们所说的高级软件测试工程师一般就是指性能测试或是白盒测试工程师。
? 时间性能（事务响应时间等）
? 空间性能（系统资源消耗）
? 一般性能测试
? 可靠性测试
? 负载测试
? 压力测试

4.基准测试，负载测试，压力测试

基准测试的关键是要获得一致的、可再现的结果。可再现的结果有两个好处：减少重新运行测试的次数；对测试的产品和产生的数字更为确信。
性能基准测试是一项系统性能测量工作，基准测试有更短的回归周期与直观的趋势分析，并同时为混合业务性能场景的脚本线程配比计算提供依据。基准测试在日常中进行，特别是在发生重大变更事件（例如：系统配置、环境发生变更）之前与之后的测试，让测试结果数据更有实质上的参考意义。基准测试为系统创建性能基准后，基准数据作为性能指标的参照物，可用于判断任意一项变更为系统带来的具体影响。

Web基准测试：把新服务器的性能和已知的参考标准进行比较

负载测试：确认服务器在不同的负载条件下性能的可接受性
（操作条件不变）
压力测试：确认服务器在异常或者极限的条件时性能的可接受性
例如，减少资源或大数量的用户

5.回归测试，冒烟测试，随机测试

回归测试(regression testing):是指软件被修改后重新进行的测试，如重复执行上一个版本测试时的用例，是为了保证对软件所做的修改没有引入新的错误而重复进行的测试。
冒烟测试（smoke testing）:是指在对一个新版本进行系统大规模的测试之前，先验证一下软件的基本功能是否实现，是否具备可测试性。
随机测试（random testing）:是指测试中所有的输入数据都是随机生成的，其目的是模拟用户的真实操作，并发现一些边缘性的错误。

1.4软件缺陷管理

1.软件缺陷的定义，属性，级别，举例和生命周期

软件缺陷定义:

软件未达到产品说明书中标明的功能。
软件出现了产品说明书中指明的不会出现的功能。
软件功能超出了产品说明书中指明的范围。
软件未达到产品说明书中指明应达到的目标。
软件测试人员认为软件难以理解和使用、运行速度慢，或最终用户认为不好。

软件缺陷属性发现缺陷后，需要提交缺陷单，通常情况下，缺陷单需要包含以下的内容：

ID
标题(Title)
测试环境(Environment)
严重等级(Severity)
优先级(Priority)
类别(Category)
状态(Status)
描述信息(Description)
重现步骤(Reproduce)
附件(Attachment)
测试人员(Created by)
处理人员（Assign to）
…

软件缺陷严重程度（Severity）:描述因缺陷引起的故障对软件产品影响的程度。通常划分为以下几个级别：

软件缺陷类别（Category）：类别描述缺陷所属的类型，以便查找对应开发人员，以及后期缺陷分析。类别通常可以分为以下几种情况：

一般的，测试人员识别缺陷，其初始状态是“新建”；
项目经理或技术领导分析缺陷，分配给合适的开发人员来解决，状态流转为“待解决”；
指定的工程师解决缺陷，将其状态跟踪到“已解决”；
测试人员回归该缺陷，如果回归通过，则关闭缺陷，如果回归不通过，则重新打开该缺陷（“Reopen”状态）。

1.5软件测试停止标准

软件测试充分性的定义和度量：
“充分性”就是用来度量一个给定的测试集T是否能验证软件P 满足其需求R。
度量：覆盖域（测试集的充分性评估是由一个有限集来度量，根据所依赖的充分性准则，有限集中的元素由软件需求或者代码导出。对于每一个测试准则C，我们都可以得到一个有限集，称之为覆盖域 Ce）、测试覆盖率（如果测试集T只覆盖了覆盖域Ce中的k(k

充分性度量是相对于具体的测试充分性准则C的。
当一个测试集T 满足准则C 时，即认为 T 相对于C 是充分的。
相反，如果 T 不能完全满足C，那么就认为用例集 T 对于C是不充分的。

因此，确定程序P 的测试集T 是否满足充分性准则 C，是依赖于准则自身的。
假设测试充分性准则C1 为：
如果针对需求R中的每一个需求r，测试集T中至少有一个测试用例测试证明了P满足r，则认为测试集T对于程序P的需求R是充分的。
测试充分性准则 C2为:
如果软件 P 中的每一条路径都被遍历至少一次，则认为测试集 T 针对（P, R）是充分的。
覆盖域:
测试集的充分性评估是由一个有限集来度量，根据所依赖的充分性准则，有限集中的元素由软件需求或者代码导出。对于每一个测试准则C，我们都可以得到一个有限集，称之为覆盖域 Ce 。

如果覆盖域Ce 仅依赖于被测软件的代码，则称准则C为一个白盒测试充分性准则；如语句覆盖、分支覆盖、路径覆盖等。
如果覆盖域Ce 仅依赖于被测软件的需求，则称准则C是一个黑盒测试充分性准则。
其他的测试充分性准则都是二者的混合。
测试覆盖率：
给定测试集 T，覆盖标准C，覆盖域Ce，假设Ce包含n个元素(n>=0),我们说T覆盖Ce, 是指对于Ce中的每一个元素e，在T中都至少有一个测试用例测试了它。如果T覆盖了Ce中所有的元素，则称T相对于C是充分的；如果T只覆盖了Ce中的k(k覆盖率。

软件测试终止准则：

基于测试阶段的原则
每个软件都经过单元测试、集成测试、系统测试这几个测试阶段，我们可以对单元测试、集成测试、系统测试制定各自具体的测试结束标准，当每个阶段的测试结束标准都符合时，我们认为该软件达到测试停止标准。
基于测试用例的原则
测试设计人员设计测试用例，并请项目组成员参与用例评审，一旦评审通过，就可以作为后面测试结束的一个参考标准。比如测试过程中如果发现测试用例通过率太低，可以拒绝继续测试，待开发人员修复后再继续。在比如可以制定功能测试用例通过率100%，非功能性测试用例通过率达到95%以上，即可允许正常测试结束。该准则的关键在于测试用例质量的把握。
基于缺陷收敛趋势及缺陷修复率原则
可以通过软件缺陷的趋势图的走向，来定测试是否可以结束；
缺陷修复率也是常用的一个指标，如严重级别错误和主要级别错误要100%修复，较小缺陷修复率达85%以上。
基于验收测试的原则
即项目通过验收测试，并得到验收测试通过结论，即可结束该项目的测试活动。
基于覆盖率的原则
如需求覆盖率达100%，测试用例执行覆盖率达100%，单元测试中语句覆盖率不低于85%等这些准则在软件测试活动中都是比较常用的。
软件项目暂停或终止，则测试活动也应响应暂停或终止
如在开发生命周期内出现重大估算、进度偏差，需要暂停调整或者终止项目，那么测试活动也随之暂停或终止，并备份响应测试数据。

1.7软件质量及软件测试相关特性

软件质量特性
- 静态质量特性
- 动态质量特性
软件测试特性
- 复杂性
- 经济性

第二章

2.1测试用例概述

测试用例的作用，准则，原则，特性测试用例，组成部分
测试用例的定义（测试用例的包括元素）：
测试用例，英文为TestCase,缩写为TC，指的是在测试执行之前设计的一套详细的测试方案，包括测试环境、测试步骤、测试数据和预期结果。
在软件测试活动中最关键的步骤就是设计有效的测试用例。

测试用例是测试工作的指导，是软件测试的必须遵守的准则，
更是软件测试质量稳定的根本保障。

根据什么写测试用例br> 我们编写测试用例的唯一标准就是用户需求 ,具体的参考资料是《需求规格说明书》
为什么需要测试用例：
软件测试是有组织性、步骤性和计划性的，为了能将软件测试的行为转换
为可管理的、具体量化的模式，需要创建和维护测试用例。

好的测试用例的特征
可以最大程度地找出软件隐藏的缺陷
可以最高效率的找出软件缺陷
可以最大程度地满足测试覆盖要求
既不过分复杂、也不能过分简单
使软件缺陷的表现可以清楚的判定
测试用例包含期望的正确的结果
待查的输出结果或文件必须尽量简单明了
不包含重复的测试用例
测试用例内容清晰、格式一致、分类组织

设计测试用例基本原则
设计测试用例的基本原则如下：
利用成熟的测试用例设计方法来指导设计
测试用例的针对性
测试用例的代表性
测试用例的可判定性
测试用例的可重现性
足够详细、准确和清晰的步骤
测试用例必须符合内部的规范的要求

良好测试用例的特征

可以最大程度地找出软件隐藏的缺陷
可以最高效率的找出软件缺陷
可以最大程度地满足测试覆盖要求
既不过分复杂、也不能过分简单
使软件缺陷的表现可以清楚的判定
测试用例包含期望的正确的结果
待查的输出结果或文件必须尽量简单明了
不包含重复的测试用例
测试用例内容清晰、格式一致、分类组织

测试用例的4性
测试用例的4性是指代表性、针对性、可判定性、可重现性：
代表性： 能够代表并覆盖各种合理的和不合理、合法的和不合法的、
边界的和越界的以及极限的输入数据、操作等。
针对性： 对程序中的可能存在的错误有针对性地测试
可判定性： 测试执行结果的正确性是可判定的，每一个测试用例都应
有相应的期望结果
可重现性： 对同样的测试用例，系统的执行结果应当是相同的。

测试用例的元素
测试用例是对测试场景和操作的描述,所以必须给出测试目标、测试对象、
测试环境要求、软件数据和操作步骤，预期结果，概括为5W1H1E。
测试目标：Why—为什么而测能、性能、易用性、可靠性、兼容性、
安全性等。
测试对象：What—测什么测试的项目、如对象、菜单、按钮等。
测试环境：Where 在哪里测试用例运行时环境，包括系统配置和
设定等要求，也包括操作系统、浏览器、网络环境等。
测试前提：When 什么时候开始测试用例运行的前提或条件限制。
输入数据：Which—哪些数据操作时系统所接受的数据。
操作步骤：How—如何测行软件的先后次序步骤。
预期结果：—判定依据行用例后的判定依据。

测试用例的元素
测试用例通常包括以下几个组成元素：
测试用例编号
测试用例名称
测试用例设计者
软件版本号
测试目的
参考信息
测试条件
测试环境
输入数据 ★
操作步骤 ★
预期结果 ★

测试用例的分类
测试用例的分类如下:
接口测试用例
路径测试用例
功能测试用例
容错能力测试用例
性能测试用例
界面测试用列
安全性测试用例
压力测试用例
可靠性测试用例
安装/反安装测试用例

第三章：白盒测试用例设计方法

白盒测试用例，语句覆盖，分支覆盖（就是判定覆盖），条件覆盖，路径覆盖
基本路径测试，程序控制流图，圈复杂度

控制流图（可简称流图）是对程序流程图进行简化后得到的，它可以更加突出的表示程序控制流的结构。
环形复杂度也称为圈复杂度，它是一种为程序逻辑复杂度提供定量尺度的软件度量。
独立路径是指程序中至少引入了一个新的处理语句集合或一个新条件的程序通路。

白盒测试用例的设计方法
逻辑覆盖：以程序的内部逻辑结构为基础，分为语句覆盖、判定覆盖、判定-条件覆盖、条件组合覆盖等

白盒测试用例注意事项
由于测试路径可能非常多，由于时间和资源问题，选出足够多的路径测试由于深入到程序编码，通常开发人员协助测试人员书写白盒测试用例
基本路径测试：在程序控制流程的基础上，分析控制构造的环路复杂性，导出基本可执行路径集合，从而设计测试用例。

基本路径测试步骤
在程序控制流图的基础上，通过分析控制构造的环路复杂性，导出基本可执行路径集合，从而设计测试用例。
包括以下4个步骤：

程序的控制流图：描述程序控制流的一种图示方法。
程序圈复杂度：McCabe复杂性度量。从程序的环路复杂性可导出程序基本路径集合中的独立路径条数这是确定程序中每个可执行语句至少执行一次所必须的测试用例数目的上界。
导出测试用例：根据圈复杂度和程序结构设计用例数据输入和预期结果。
准备测试用例：确保基本路径集中的每一条路径的执行。

语句覆盖：语句覆盖就是设计若干个测试用例，运行被测试程序，使得每一条可执行语句至少执行一次；
判定覆盖（也称为分支覆盖）：设计若干个测试用例，运行所测程序，使程序中每个判断的取真分支和取假分支至少执行一次；
条件覆盖：设计足够多的测试用例行所测程序使程序中每个判断的每个条件的每个可能取值至少执行一次；
判定-条件覆盖：设计足够多的测试用例，运行所测程序，使程序中每个判断的每个条件的所有可能取值至少执行一次，并且每个可能的判断结果也至少执行一次，换句话说，即是要求各个判断的所有可能的条件取值组合至少执行一次；
条件组合测试：设计足够多的测试用例，运行所测程序，使程序中每个判断的所有可能的条件取值组合至少执行一次；
路径测试：设计足够多的测试用例，运行所测程序，要覆盖程序中所有可能的路径。

面向对象覆盖

继承上下文覆盖
- 由于传统的结构化度量没有考虑面向对象的一些特性（如多态、继承和封装等），所以在面向对象领域，传统的结构化覆盖必须被加强，以满足面向对象特性。
- 继承上下文覆盖考虑在每个类的上下文内获得的覆盖率级别。它是扩展到面向对象领域里的一种覆盖率度量方法，用于度量在系统中的多态调用被测试得多好。
- 继承上下文定义将基类上下文内例行程序的执行作为独立于继承类上下文内例行程序的执行。同样，它们在考虑继承类上下文内例行程序的执行也独立于基类上下文内例行程序的执行。为了获得100％继承上下文覆盖，代码必须在每个适当的上下文内被完全执行。
基于状态的上下文覆盖
- 在绝大多数面向对象的系统中存在这样的一些类：这些类的对象可以存在于众多不同状态中的任何一种，并且由于类的行为依赖于状态，每个类的行为在每个可能的状态中其性质是不同的。
- 基于状态的上下文覆盖对应于被测类对象的潜在状态。
- 这样基于状态的上下文覆盖把一个状态上下文内的一个例行程序的执行认为是独立于另一个状态内相同例行程序的执行。为了达到100％的基于状态的上下文覆盖，例行程序必须在每个适当的上下文（状态）内被执行。

面向循环的测试方法
从本质上说，循环测试的目的就是检查循环结构的有效性。
通常，循环可以划分为简单循环、嵌套循环、串接循环和非结构循环4类。
（1）测试简单循环。设其循环的最大次数为n ，可采用以下测试集：

跳过整个循环；
只循环一次；
只循环两次；
循环 m 次，其中m
分别循环 n-1、n 和 n+1 次。

（2）测试嵌套循环。如果将简单循环的测试方法用于嵌套循环，可能的测试次数会随嵌套层数成几何级数增加。此时可采用以下办法减少测试次数：

测试从最内层循环开始，所有外层循环次数设置为最小值；
对最内层循环按照简单循环的测试方法进行；
由内向外进行下一个循环的测试，本层循环的所有外层循环仍取最小值，而由本层循环嵌套的循环取某些“典型”值；
重复上一步的过程，直到测试完所有循环。

（3）测试串接循环。若串接的各个循环相互独立，则可分别采用简单循环的测试方法；否则采用嵌套循环的测试方法。

（4）对于非结构循环这种情况，无法进行测试，需要按结构化程序设计的思想将程序结构化后，再进行测试。

最少测试用例计算

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

文本框接受字符个数，比如用户名长度，密码长度等。
报表的第一行和最后一行。
数组元素的第一个和最后一个。
循环的第 1 次、第 2 次和倒数第 2 次、最后一次。

因果图法 Chapter06 page30
因果图法比较适合输入条件比较多的情况，测试所有的输入条件的排列组合。所谓的原因就是输入，所谓的结果就是输出。
利用因果图导出测试用例需要经过以下几个步骤:
① 分析程度规格说明的描述中,哪些是原因,哪些是结果.原因常常是输入条件或输入条件的等价类,而结果是输出条件
② 分析程度规格说明的描述中语义内容,并将其表示成连接各个原因与各个结果的”因果图”
③ 标明约束条件。由于语法或环境的限制，有些原因和结果的组合情况是不可能出现的。
④ 把因果图转换成判定表。
⑤ 为判定表中的每一列表示的情况设计测试用例
正交试验设计法 Chapter06 page37
什么是正交试验设计br> 正交试验设计法，是一种成对测试交互的系统的统计方法。它提供了一种能对所有变量对的组合进行典型覆盖（均匀分布）的方法。
可以从大量的试验点中挑出适量的、有代表性的点，利用“正交表”，合理的安排试验的一种科学的试验设计方法。

正交表的构成
行数：正交表中的行的个数，即试验的次数，也是我们通过正交实验法设计的测试用例的个数。
因素数：正交表中列的个数，即要测试的功能点。
水平数：任何单个因素能够取得的值的最大个数，即要测试功能点的取值个数。
正交表的形式：L 行数 (水平数因素数 ) 如：L 8 (2 7 )

用正交表设计测试用例的步骤
(1) 有哪些因素（功能点）
(2) 每个因素有哪几个水平（功能点的取值）
(3) 选择一个合适的正交表
(4) 把变量的值映射到表中
(5) 把每一行的各因素水平的组合做为一个测试用例
(6) 加上你认为可疑且没有在表中出现的组合

流程图法
我们在编程时，一般都需要画程序的算法流程图，可以将这一思想应用到黑盒测试领域。算法流程图是针对程序的内部结构的，而黑盒测试的流程图是针对整个系统业务功能流程的。
流程图法的步骤：
第一步：详细了解需求
第二步：根据需求说明或界面原型，找出业务流程的各个页面以及各页面之间的流转关系
第三步：画出业务流程
第四步：写用例，覆盖所有的路径分支

测试需求：
需求规格说明书的检查要点
? 正确性、必要性、优先级、明确性、可测性、完整性、可修改性、一致性
需求文档的检查步骤 5.2 page5
? 测试人员则可以通过设计测试用例来检查需求。

测试计划：
测试计划通常作为关于质量的重要文档呈现给管理层。测试计划具有内部作用和外部作用。
软件测试计划是对测试过程的一个整体上的设计。
测试计划的要点包括以下内容。
确定测试范围制定测试策略测试资源安排进度安排风险及对策
制定测试计划步骤：
首先要明确测试的对象，制定测试策略，需要安排测试资源，安排测试进度。

测试设计及测试用例：
基于需求的测试用例设计：基于需求的测试是一种最根本的软件测试。基于需求的测试方法会使测试更加有效，因为它使测试专注与质量问题产生的根源，即需求。软件质量差的两大原因是：软件需求规格说明书的错误、有问题的系统测试覆盖。
测试用例的粒度及评价
测试用例写得过于复杂或详细
测试用例写得过于简单
测试用例的检查：同行评审、用户评审。
测试的执行：
测试用例的选择需要考虑本次测试的上下文
测试的分工能避免测试人员的思维局限性，即使是同样一个用例，由不同的人来执行，可能会发现不同的问题。
BVT测试，也叫编译检查测试，主要检查源代码是否能正确编译成一个新的、完整可用的版本。如果BVT测试不通过，则测试人员不能拿到新的版本进行测试。
软件测试中的冒烟测试，是对软件基本的功能进行测试，目的是确认软件基本的功能正常，保证软件系统能跑的起来

软件测试度量的目的和原则
软件测试度量的目的是改进软件测试的质量，提高测试效率。任何度量的行为都是有目的进行的，度量的数据用于说明某些问题。软件测试的度量是为了项目质量服务的，选择的度量标准和方法都是为了能让测试进行得更加科学和规范，以创造更多的测试价值。
测试的度量应该遵循以下原则：

要制定明确的度量目标；
度量标准的定义应该具有一致性、客观性；
度量方法应该尽可能简单、可计算；
度量数据的收集应该尽可能自动化。

影响软件产品质量的各个因素

基于未加过滤的Bug来计算，则会多少有些不公平。
解决办法：制定缺陷级别评估规范，用于指导测试人员进行Bug等级的划分。此外，每个缺陷的等级划分应该得到评审，对于不符合划分标准的应予以纠正。对于那些经确认拒绝处理的Bug，也不能纳入统计范畴。
定性评估是指对测试人员发现的Bug质量进行相对主观的衡量，可包括以下方面的评价：

Bug的类型分布；
Bug重现率；
Bug录入的清晰程度、简明程度等；
Bug的新颖性。
有关于Bug定性评估方面，需要注意的评估指标还有：
（1）Bug的类型分布比较平均，能够涉及多方面以及多种类型的Bug。例如，既有功能性的Bug,又有性能和易用性方面的Bug。
（2）大部分的Bug应该是可重现的，而且是重现率高的。
（3）录入的Bug能够清晰地描述、简明易懂，重现步骤精简，描述的Bug不会造成误解。

Bug综合评价模型包括哪些因素

第七章第三方测试

第三方测试的概念、模式和职责

软件能力成熟度模型概念 CMMI

Capability Maturity Model Integration 能力成熟度模型集成
用途：帮助软件企业对过程进行管理和改进，增强开发和改进能力，从而能按时地、不超预算地开发出高质量的软件
过程改进框架，不是过程程序
CMMI是世界公认的软件产品进入国际市场的通行证，它不仅仅是对产品质量的认证，更是一种软件过程改善的途径。是推动软件企业在产品的研发、生产、服务和管理上不断成熟和进步的手段，是一种持续提升和完善企业自身能力的过程。如果一家公司最终通过CMMI认证，标志着该公司在质量管理的能力已经上升到一个新的高度。

开发者测试：使用断言的方式测试代码功能
移动测试：使用了Appium和确定app的控件的工具uiautomatorviewer实现移动端自动化测试
嵌入式测试：使用ETest工具进行嵌入式测试
安全测试：是在IT软件产品的生命周期中，特别是产品开发基本完成到发布阶段，对产品进行检验以验证产品符合安全需求定义和产品质量标准的过程。通过sql注入等方式进行安全测试
web测试：保证web页面静态元素如：文字、图片、链接的正确性、时效性，包括内容测试、界面测试、功能测试、性能测试、兼容性测试、安全性测试等情况