软件测试理论

软件测试理论知识

软件产品的定义：软件是一种逻辑产品，不是客观的实体，具有无形性，它是脑力劳动的结晶，它以程序和文档的形式保存在计算机存储器的磁盘和光盘介质上，通过操作计算机才能体现出它的功能和作用。

软件产品的构成：包装、源程序、相关文档（安装部署说明、帮助文档、用户手册）

软件开发过程中产生的文档
需求分析阶段：可行性研究报告、项目开发计划、软件需求说明、用户需求说明 需求分析工程师 产品部
设计阶段：概要设计说明书、详细设计说明书、数据库设计说明书 研发部
测试阶段：测试计划、测试方案、测试用例、测试报告 测试部（300人左右的软件公司测试人员15个左右，60-70个开发人员）
总结阶段：项目总结
用户阶段：安装手册、用户手册

公司组织架构：
人力资源、财务、行政、市场部、产品部、开发部、测试部、项目管理部（配置管理员、）、工程部（也叫实施、部署部、售后部，人数较多）

测试前准备：
1.编写测试计划
2.测试要点提取
3.设计测试用例（接口用例、功能用例、自动化方案、性能方案）
4.评审用例
5.创建测试数据

执行测试用例需要进行的工作：
1.搭建测试环境（功能测试、自动化测试、性能测试环境不一样）
2.执行用例、提交bug
3.回归测试
4.更新用例

迭代次数，即对外发布的版本数
迭代原因：修复上一版本发现的问题，用户需要更该的功能

实例：一个APP 两个月内测试了10个包（内部包）
一天写一百个用例，执行130-150个用例
测试人员在一个项目过程中最忙的时候是最后一个月

假如项目过程中一共有20个软件包，从第8-10个包开始进行回归测试，从第13个包开始做性能测试，从第15个包开始做外部接口测试

项目组成员构成
项目经理（PM）：驱动整个项目的运转，负责制定计划，安排人力，管理进度，协调团队，进行重大决策
需求分析工程师（BA）：对产品/项目的需求进行调研与分析，输出产品需求规格说明书
架构师（FD）系统工程师（SE）：技术专家、经验丰富，负责整个系统体系的架构的设计以及关键模块的设计
程序员/开发人员(PG):设计、编写软件，并修复软件中的缺陷；
测试工程师（TE）：负责找出软件产品存在的问题并报告；
项目管理工程师（QA）：负责在研项目开发过程的流程质量监管；
配置管理人员（CMO）：负责代码和项目相关洗脸的管理，以及进行编译、打包，组合成一个软件包。

软件工程定义： 将系统化的、严格约束的、可量化的方法应用于软件的开发、运行和维护上。
软件工程过程范围：为了生产出一个最终能满足需求且达到工程目标的软件产品。软件工程过程覆盖了需求、设计、开发、测试、维护等活动。
软件工程作用：提高软件开发的效率和质量，使软件开发标准化，工业化。

软件产品从最初构思到消亡的整个过程，称为软件开发过程。
软件开发过程类型：普通瀑布模型、V型瀑布模型、W型瀑布模型、快速原型模型、敏捷开发模型
普通瀑布模型特点：严格按照线性方式进行；各阶段具有里程碑特征；基于文档的驱动；严格的阶段评审机制
快速原型模型特点：快速原型方法可以克服瀑布模型的缺点；适用于需求不明确，变更频繁的软件；如果软件实现与用户评价偏差很大，开发人员会推倒重来。
敏捷迭代模型流程：产品经理根据需求规格说明书整理出产品功能列表–开计划会（根据目前人员资源确定迭代次数，确定每次迭代的功能点个数，一般来说大概一个月迭代一次，确定每次迭代的内容，迭代的时间节点；分配功能点给开发，工作内容分解：把任务分解，确定每天做什么–每次迭代完开评审会，讨论迭代完的产品能否个用户体验-- 上一次迭代的总结会–开启第二次迭代，重复之前步骤）
敏捷迭代模型特点：完整地开发，每少数几周或是少数几个月里可以测试功能；强调在获得最简短的可执行功能的部分，能够及早给予企业价值；在整个项目的生命周期里，可以持续的改善、增加未来的功能。
敏捷迭代模型-WBS（工作分解结构 Work Breakdown Structure） 创建WBS：创建WBS是把项目可交付成果和项目工作分解成较小任务）
敏捷迭代模型-Scrum框架（三个角色：产品负责人、流程经理scrum Master、团队；四个仪式：Sprint计划会议、每日站会、sprint评审会议、sprint回顾会议；三个物件：产品功能列表backlog、冲刺订单sprint backlog、燃尽图）

软件开发过程模型的目的：保证最终产品满足用户需求;提高产品质量，降低产品开发成本;保证项目可管理，进度可控制;作为测试人员的职责，是在所处项目的开发模式中，尽量运用自身的知识和技能，创造出尽量完善的软件。

软件的生命周期：需求（可行性分析、需求分析）-设计（概要设计、详细设计、数据库设计）-编码-测试-维护-升级-维护
软件测试流程：需求分析-测试计划-测试要点分析-测试方案-测试用例-测试执行-测试报告-测试总结

质量：反映实体满足明确或隐含需求的能力的特性总和
软件质量六大特性：功能性、可靠性、可维护性、效率性、可移植性、易用性

功能性：适合性、准确性、互操作性、保密安全性、
可靠性：成熟性、容错性、易恢复性
易用性：易理解性、易学性、易操作性、吸引性
效率性：时间特性、资源利用性
可维护性：易分析性、易改变性、稳定性、易测试性、稳定性、
可移植性：适应性、已安装性、共存性、易替换性

使用质量模型四大特性：有效性、生产率、安全性和满意度
有效性：软件产品在指定的使用环境下，使用户能达到与准确性和完备性相关的规定目标的能力
生产率：在指定的使用环境下，使用户为达到有效性而消耗适当数量的资源的能力
安全性：在指定使用环境下，达到对人类、业务、软件、财产或环境造成损害的可接受的风险级别的能力
满意度：使用户满意的能力。

QC:主要是事后的质量检验类活动为主，默认错误是允许的，期望发现并选出错误。
QA:主要是事先的质量保证类活动，以预防为主。期望降低错误的发生几率。
QC和QA的区别：
QA偏重于质量管理体系的建立和维护，客户和认证机构质量体系审核工作，质量培训工作等，QC主要集中在质量检验和控制方面。
QA的工作涉及公司的全局，各个相关职能，覆盖面比较宽广，而QC主要集中在产品质量检查方面，只是质量工作的其中一个方面。

软件质量最权威的体系：CMMI 和 ISO9000质量标准体系

CMMI:Capability Maturity Model Integration (能力成熟度模型集成)
CMMI成熟度等级：初始级（initial）-已管理级(managed)-已定义级(defined)-量化管理级（quantitatively managed）-持续优化级(optimizing)

测试工程师如何提高软件质量
（1）高质量用例：引入合适的测试用例设计方法 ；引入测试用例评审机制       
（2）良好的测试执行：要求用例执行率达到100%，多次的测试轮次；引入测试工具，让测试可以做得更深入（通过查看日志，查数据库）     
（3）良好的缺陷管理：良好的缺陷写作和过Bug机制（缺陷修复效率可以提高，修复率也更高）；引入合适的缺陷管理工具和缺陷管理流程      
（4）良好的测试流程：引入更合适的测试流程和测试方法；采用更多的非功能测试，不要忽略非功能测试

测试计划：描述所有要完成的测试工作，包括被测试项目的目的、背景、范围、资源、进度、环境、策略、任务，以及与测试有关的风险和措施等方面。
测试计划作用：
1.领导能够根据计划做宏观调控，进行相应资源配置等
2.测试人员能够了解整个项目测试情况，不同阶段所要进行的工作
3.便于其它人员了解测试人员的工作内容，进行相关配合工作

制定测试计划的时间：需求分析通过后制定测试计划，在整个测试工作过程中不断修改
测试计划包含的内容：目的、背景、范围、测试进度、测试资源、测试环境、测试策略、测试风险评估
测试风险评估：进度风险、人员风险、成本风险、质量风险

测试启动条件：版本基本稳定、测试用例、测试代码准备完成、测试环境搭建完成、冒烟测试通过
测试正常结束条件：需求覆盖率达到100%、用例执行率达到100%、缺陷解决率达到95%以上，没有致命和重大缺陷没解决
测试异常结束条件：业务流程未实现、大量的缺陷、严重的缺陷、测试环境不完整、资源短缺

环境指的是被测试软件所运行的软件环境（操作系统、数据库、服务器、编程语言、浏览器）和硬件环境（客户端PC和服务端SERVER）。
环境分类：开发环境、测试环境和用户环境

软件测试定义：使用人工或自动的手段来运行或测定某个软件系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。
软件测试正向思维：验证软件正常工作
软件测试逆向思维：假定软件有错误

软件测试的目的：
（1）以最少的人力、物力和时间，系统地找出软件中潜在的各种错误和缺陷。通过修正各种错误和缺陷提高软件质量，尽量规避软件发布后的风险。
（2）测试是对软件质量的度量与评估，以验证软件的质量满足用户的需求，为用户选择和接受软件提供有力的证据。
（3）通过分析错误产生的原因，可帮助发现当前软件过程的缺陷，以便进行过程改进。
（4）测试是为了证明软件中存在错误，而不是证明软件正确的。
（5）软件测试最终的目的是交给用户的软件产品符合用户的需求。
软件测试的原则：Good-Enough原则（测试既不要不充分，也不是过分）、木桶原理、80~20原则
（1）所有的软件测试都应追溯到用户需求。
（2）尽早地和不断地进行软件测试。
（3）完全（穷举）测试是不可能的，测试需要终止。
（4）测试无法显示软件潜在的缺陷。
（5）充分注意测试中的群集现象。
（6）程序员应避免检查自己的程序。
（7）尽量避免测试的随意性。
（8）测试用例应包括合理的输入条件和不合理的输入条件。
（9）应当彻底检查每个测试的执行结果。
（10）妥善保存测试相关的文档及数据，为管理提供依据，为维护提供方便。

软件测试对象：程序、数据、文档
软件测试的两个手段：确认（保证软件满足用户要求的过程）与验证（保证软件符合产品规格说明书的过程）

软件测试分类
按阶段分类：单元测试、集成测试（非增量式集成、增量式集成：自顶向下、自底向上）、系统测试、验收测试
按是否运行软件分类：静态测试、动态测试
按是否查看源代码分类：白盒测试、灰盒测试、黑盒测试（功能测试：逻辑功能测试、界面测试、易用性测试、安装测试、兼容性测试；性能测试：一般性能测试、稳定性测试、负载测试、压力测试）
其他分类：回归测试、冒烟测试、随机测试、安全测试

系统测试的对象包括需测试的软件，软件所依赖的硬件、外设甚至某些数据、某些支持软件及其接口等
系统测试类型：功能测试、兼容性测试、负载测试、压力测试、容量测试、安全性测试、可用性测试、GUI测试、安装测试、配置测试、异常测试、备份测试、容错性测试、文档测试、在线帮助测试、网络测试、稳定性测试

Alpha 测试（α测试）、Beta 测试（β测试）的区别
测试环境不同：α测试在开发环境或者模拟实际操作环境下进行；β测试在实际使用环境中进行
测试人员不同：α测试人员可以是终端用户也可以是企业内部的用户；β测试人员是终端用户（包括潜在用户）
开发人员是否在场不同：α测试时有开发人员在场，实际上是一种受控的测试；β测试时开发人员通常不在测试现场，测试情况通常不受控
关注点不同：Alpha测试关注软件产品的FLURPS（即功能、局域化、可使用性、可靠性、性能和支持），尤其注重产品的界面和特色。（功能性(Functionality)、可用性(Usability)、可靠性(Reliability)、性能(Performance)、可支持性(Supportability))；Beta测试着重关注产品的支持性，包括文档、客户培训和支持产品的生产能力。

白盒测试设计技术可分为逻辑覆盖和路径覆盖
黑盒测试设计技术可分为：等价类划分、边界值分析、错误推测法、判定表驱动法、因果图法、正交试验法、场景法
兼容性测试：硬件兼容性测试、软件兼容性测试、数据兼容性测试
硬件兼容性测试：与整机兼容、与板卡和外设兼容
软件兼容性测试：操作系统/平台的兼容、应用软件之间的兼容、不同浏览器的兼容、数据库的兼容、软硬件配合兼容、网络环境兼容性测试、分辨率兼容性测试
数据兼容性测试：不同版本间的数据兼容、不同软件间的数据兼容
WEB兼容性测试的侧重点：操作系统兼容性测试、浏览器兼容性测试、分辨率兼容性测试
C/S兼容性测试的侧重点：操作系统兼容性测试、客户端版本与服务器版本兼容性测试
APP兼容性测试的侧重点：手机系统、屏幕尺寸、分辨率、机型、支持的语言、网络兼容、与其他APP

回归测试目的：一是验证上一轮中发现的问题是否得到修复；二是验证修复问题后是否引起新问题的出现

软件测试流程：需求评审-测试计划-测试方案-测试需求提取-测试用例-测试执行-缺陷管理-测试报告-测试总结
软件生命周期：计划-需求-设计-编码-测试-运维

软件测试在软件开发各阶段工作内容：
（1）项目规划阶段：负责整个测试阶段的监控。
（2）需求分析阶段：确定测试需求分析，制定系统测试计划。
（3）概要设计和详细设计阶段：制定集成测试计划和单元测试计划。
（4）编码阶段：开发相应的测试代码或测试脚本，设计测试用例。
（5）测试阶段：实施测试，并提交相应的测试报告。

需求分析：是掌握被测系统的过程，一般测试和开发人员都要进行。测试人员做的需求分析成为测试需求分析
测试需求的特征：必须是可核实的、指明满足需求的正常的前置条件、不含具体的测试数据
测试需求的作用：软件测试需求是开发测试用例的依据、有助于保证测试的质量与进度、测试需求是衡量覆盖率的重要指标

测试需求分析方法：测试要点分析、测试类型分析、功能交互分析、质量特性分析
需求评审内容：完整性和准确性

测试用例是一份测试文档，它描述输入、动作、和一个期望的结果，其目的是确定应用程序的某个特性是否正常的工作
测试用例（Test Case）定义：是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。
测试用例构成元素：用例编号、用例标题、优先级、预置条件、操作步骤、预期结果、备注
用例编号通常为 项目简称 + 模块简称 + 顺序编号 实例：QQ登录模块： QQ-Login-001
用例标题：包括在[哪里]+操作+验证内容 实例： 百度查询页面：在百度查询页面，输入“测试”进行搜索后，验证进入搜索结果页面

测试用例的评审参与人员：项目经理、需求人员、开发人员、架构师、测试人员
测试用例评审内容：
1.是否覆盖产品需求上的所有功能点
2.测试用例本身的描述是否清晰，是否存在二义性
3.用例是否具有很好可执行性。例如用例的前提条件、执行步骤、输入数据和期待结果是否清晰、正确；期待结果是否有明显的验证方法。
4.优先级安排是否合理
5.是否存在冗余的用例
6.是否从用户层面来设计用户使用场景和使用流程的测试用例
7.是否包含充分的负面测试用例。充分考虑产品的异常流程，并编写测试用例进行覆盖

黑盒测试概念：又称功能测试、数据驱动测试或基于规格说明书的测试，是一种从用户观点出发的测试
黑盒测试主要发现什么类型的错误：
①功能不正确或遗留；
②界面错误；
③性能错误；
④数据库访问错误；
⑤初始化和终止错误的错误
黑盒用例设计技术：
等价类划分方法（重点）
界值分析方法 （重点）
判定表驱动分析方法 重点）
场景法 （重点）
错误推测方法(了解）

等价类（有效等价类、无效等价类）：是把所有可能的输入数据,划分成若干部分（子集），然后从每一个子集中选取少数具有代表性的数据作为测试用例进行合理的分类。等价类划分是一种典型的、重要的黑盒测试方法。
边界值：对输入或输出的边界值进行测试的一种黑盒测试方法。

判定法：分析输入输出条件，得出测试用例。（也称决策表）
条件桩：列出问题的所有条件
条件项：针对条件桩给出的条件列出所有可能的取值
动作桩：列出问题规定的可能采取的操作
动作项：指出在条件项的各组取值情况下应采取的动作
判定法步骤：
1.确定规则个数。假设有N个条件，则有2的N次幂规则；
2.列出所有的条件桩和动作桩；
3.填入条件项；
4.填入动作项。制定初始决策表；
5.进行简化，合并相似规则或者相同动作
6.针对判定表中每一列有效规则设计一个测试用例
决策表的化简：有n个条件的决策表,对应的规则将有2n条，当n非常大的时候，这是非常繁琐的。因此,应对决策表进行化简.

决策表的化简包括两个方面：
（1）合并：如果一个条件项(表中某列中的条件值)和另外一个条件项动作是相同的,且两个条件项对应的每一行的值只有一个是不同的,则可以将其合并.合并的项除了不同值变成”不关心”条目外,其余不变。
（2）包含：如果两个条件项的动作是相同的,对任意条件1的值和条件2中对应的值,如果满足:A.如果条件1的值是T(F),则条件2中的值也是T(F)；B.如果条件1的值是-(不关心),则条件2中的值是T,F,-,称条件1包含条件2,条件2可以撤去；重复A,B就可以得到精简的决策表.

场景法：模拟用户操作软件时的场景，主要用于测试系统的业务流程。当拿到一个测试任务时，我们并不是先关注某个控件的边界值、等价类是否满足要求，而是先要关注它的主要功能和业务流程是否正确实现，这就需要使用场景法来完成测试。当业务流程测试没有问题，也就是该软件的主要功能没有问题时，我们再重点从边界值 、等价类等方面对控件进行测试。
冒烟测试时也主要采用场景法进行测试
基本流：按照正确的业务流程来实现一条操作路径（模拟正确的操作流程）
备选流：导致程序出现错误的操作流程（模拟错误的操作流程）

错误推测法:基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法。
错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例。

测试执行是执行所有或部分选定的测试用例，并对结果进行分析的过程。执行测试用例，就是根据已有的测试用例，按照里面的操作步骤一步一步的执行，并查看预期结果与实际结果是否一致。
测试执行前搭建测试环境注意事项：
（1）注意前提条件
（2）测试用例要全部执行
（3）不要忽视任何偶然出现的现象
（4）加强测试过程记录
（5）详细预期与实际的不一致
（6）提交缺陷时与开发的关系处理
（7）提交一份优秀的问题报告单
（8）及时更新测试用例
测试环境的组成：硬件环境、软件环境、网络环境
对测试环境的要求：
（1）尽量模拟真实的环境
（2）符合软件运行的最低要求
（3）选用比较普及的操作系统和软件平台
（4）营造纯净、独立的测试环境
（5）无毒的环境

软件缺陷（bug）：计算机系统或者程序中存在的任何一种破坏正常运行能力的问题、错误，或者隐藏的功能缺陷、瑕疵。
软件缺陷包括的内容：
（1）未实现产品需求规格要求的功能；
（2）实现功能不完整；
（3）实现了需求规格要求未描述的功能（多余的功能）；
（4）实际结果和用例预期结果不一致；
（5）运行出错，包括运行中断、系统崩溃、界面混乱；
（6）数据结果不正确、精度不够；
（7）用户不能接受的其他问题，如难理解、不易使用、运行缓慢、界面不美观。
二八定理：80%的缺陷出现在 20%的模块。

软件缺陷生命周期：Bug提交 > Bug分配 > Bug处理 > Bug验证 > Bug关闭
软件缺陷状态：new-open-fixed-rejected-reopen-postponed-closed (新建-打开-已修复-被拒-重新打开-延期-已关闭)
软件缺陷严重程度：
致命：软件无法运行，或者软件的主要功能丧失，或者很大可能性会造成严重不良后果
严重：软件的次要功能丧失，或者主要功能在一些特定情况下会出错 ，比如金额计算等
一般：软件在某些情况下会出错，但是造成的后果影响不大
轻微/建议：在某些情况下会出错，但是造成的后果影响很小

一个缺陷的基本要素
（1）缺陷标题 ：概要描述出问题的内容
（2）测试环境：测试环境描述
（3）缺陷严重程度*：根据缺陷严重标准划分
（4）软件版本号*：发现缺陷的内部版号
（5）缺陷的复现步骤* ：描述出复现问题的步骤
（6）实际结果*：按照重现步骤操作后出现的实际结果
（7）预期结果*：希望达到正确结果
（8）附件 ：上传相关截图或日志等文件，方便开发人员分析定位 问题

测试报告主要内容：
（1）数据统计
（2）遗留bug情况
（3）测试风险
（4）测试对象评估
（5）测试结论

要点提取方法（要点分析方法）：
1.功能点
2.模块之间的交互
3.六大特性
4.

系统测试类型、策略：