软件测试理论

软件生命周期（开发流程）

阶段	角色	输出物/产出物	主要工作内容
项目计划	项目经理	项目计划书	确定项目的人员，开发时间，开发范围，需要的资源
需求分析	产品经理/需求人员	需求规格	从业务方面明确要开发那些功能，业务的标准，最终完成的标准
	由产品经理或需求人员收集零散的需求点，分析并整理成文档，三方一起对需求进行评审，如果评审通过，形成需求规格
概要设计	架构师	概要设计说明书	从整体框架方面对整个系统进行设计，划分系统的模块结构，确定模块与模块之间的调用关系，确定系统与子系统的关系
详细设计	资深开发人员	详细设计说明书	对模块内部进行进一步设计，包括类的定义，方法，函数的定义
实现/编码	开发	程序（源程序=>目标程序）	开发人员根据需求的要求，在概设与详设的基础上，编写程序代码，运行，调试代码，确保功能被实现出来
测试	测试团队	测试报告	对程序进行操作，发现程序中的错误，衡量软件的质量，并判断其是否满足需求及设计的要求
发布上线	发布负责人	将已经测试通过的程序，数据，脚本。文档交付给客户，并上线到生产环境
运维	运维人员	收集并解决客户或用户在使用过程中的问题

开发模型

1. 边做边改模型
2. 瀑布模型
3. V模型

工作流程：需求人员先收集用户需求，分析整理并评审形成需求规格，对产品进行概要设计，对每个模块进行详细设计，每个开发人员针对自己负责的模块进行代码编写，完成一个模块内的一个一个单元的代码，测试立刻对该单元进行单元测试，其他单元的代码依次完成，测试依次对其进行单元测试，当一个模块内的所有单元都完成后，开发将模块内的单元集成为完整的模块，测试立刻对该模块进行集成测试，其他模块依次完成，测试依次对各模块进行集成测试，当所有的模块集成测试完成后，开发将各模块生成整个系统，测试对该系统进行完整的系统测试，当系统测试完成后，进行上线前的验收测试。

测试的定义

在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并判断其是否满足需求及设计要求的过程

测试的原则

1.测试可以显示缺陷的存在：体现的是测试工作在软件开发过程中的重要性

2.穷尽测试是不可能的：体现的是测试方法在测试工作中的重要性

3.测试要尽早介入：体现的是测试介入时间的重要性，在需求阶段就要介入

4.缺陷的集群效应，即被测试对象中80%的缺陷来自于20%的核心模块，体现的是在测试过程中，尤其时间比较紧促的情况下，要优先保障核心功能

5.杀虫剂悖论：同样的测试用例被重复执行多次，将很难发现新的缺陷，体现的是在测试过程中，如果固守一种思维方式，很难在重复测试中发现新的缺陷，在实际工作中，要尽量降低杀虫剂悖论的影响。

6.测试活动依赖于测试对象的背景：体现的是业务的重要性

7.不存在缺陷的系统并不代表是有用的系统：体现的是需求的重要性

测试的目标

1. 发现一些可以通过测试避免的开发风险
2. 实施测试可以降低所发现的风险
3. 确定测试何时可以结束

软件的测试对象

1. 程序（源程序->目标程序）
2. 数据
3. 文档
4. 脚本

测试分类

分类		定义	依据	方法
开发阶段	单元测试	对系统中的最小可测单元进行检查与验证	参考详细设计说明书	采用白盒测试，比如语句覆盖，条件覆盖，判定覆盖，路径覆盖
	集成测试	将已经测试过的单元组合成组件，测试其组装调用的接口，接口测试属于集成测试的范畴，但不完全等价于集成测试	参考概要设计说明书	可以采用白盒或黑盒设计方法
	系统测试	对整个系统进行全面的测试，包括软件，硬件，外设，网络等方面	参考需求规格	采用黑盒测试，比如：等价类，边界值，判定表，流程分析法，正交实验法
	验收测试	在上线前，测试是否满足最终的客户或用户的使用场景	用户需求
		阿尔法测试：开发环境下；早期的，功能不稳定的情况下；技术人员操作
		贝塔测试：用户实际使用环境下；晚期的，功能比较稳定的情况下；实际用户操作
系统测试	功能测试	测试软件中的功能是否符合功能需求的要求
	界面测试	测试系统界面是否符合效果图或原型图，界面的显示等是否符合要求
	兼容性测试	测试软件在不同的系统或平台上是否正常工作
	易用性测试	主要从用户角度考虑用户的使用习惯
	健壮性测试（容错性测试）	主要考虑软件在使用过程中出现一些意外的恢复能力
	性能测试	主要考虑软件在使用过程中是否满足性能的要求 从用户角度来讲，关注相应时间，业内有2，5，8（秒）原则 从服务器角度来讲，关注资源占用情况，服务器的cpu，内存，磁盘等
	压力测试	关注极限，测试系统的最大承压能力（系统的压力来自于用户）
	负载测试	关注持续性，测试系统在不同的用户量下，各项功能是否正常使用
	容量测试	如果是类似于手机短信容量，购物车中商品容量，会由功能测试覆盖，此处的容量测试更关注的是数据库重点数据量，比如数据库中有大数据量或数据库的表中的数据已满时的处理情况
	安全测试	测试程序使用时数据传输，存储等是否安全
	网络测试	主要针对App应用，比如说断网，弱网，网络切换
	流量测试	主要针对App应用，目前关注度比较低
	电量测试	主要针对App应用，目前关注度比较低
	专项测试（App）	主要针对App应用，包括终端的cpu，内存，fps，中断测试等
	文档测试	主要有帮助文档，说明书，需求文档，设计文档
	安装、升级、卸载测试	能否正常安装，升级，卸载
测试技术角度分类	黑盒测试	在测试过程中，看不到程序内部的代码，只能通过输入和输出判断被测试对象是否符合要求		常见方法：等价类，边界值，判定表，正交实验，流程分析法/场景法
	白盒测试	在测试过程中，程序代码可见		常见方法：语句覆盖，条件覆盖，条件组合覆盖，判定覆盖，路径覆盖
按测试方法分类	手工测试	由测试人员执行操作，人工判断测试结果是否符合要求
	自动化测试	功能自动化，接口自动化
按是否运行程序分类	动态测试	在测试过程中，需要运行程序代码
	静态测试	在测试过程中，不需要运行程序代码
其他	回归测试	重复测试
		大范围的回归：基于计划或项目整体安排的回归
		小范围的回归：一般来说，针对某个bug修改完成后，需要验证bug，并且回归bug的周边
	冒烟测试	在全面正式测试前，先对系统最基本的，最核心的功能进行检查和验证
	国际化测试	如果系统支持多语言，测试在不同语言下的各项功能是否符合要求
	本地化测试	测试软件是否符合当地使用习惯，比如日期，标点符号，货币符号
	随机测试	在非正式安排下的测试
	探索性测试	相对全面测试而言，在测试之前先分析各功能或模块的风险，针对高风险的区域多测，低风险区域少测，甚至不测

功能测试流程

阶段	角色	输出物	主要工作内容
制定测试计划	测试经理/测试主管	测试计划书（管理性的文档）	确定测试的时间，测试范围，资源，任务，人员等安排
编写测试方案	测试经理/资深测试工程师	测试方案文档（指导性文档）	明确具体的测试类型，确定每种测试类型的测试策略，明确具体的测试环境，确定相关的测试工具，明确具体使用的测试方法，分析可能会出现的测试风险及明确应对方法
分析测试需求	测试工程师	测试范围及测试点	结合需求规格，分析具体测试范围，列出测试点
设计并编写测试用例	测试工程师	测试用例	结合分析的测试范围及测试点，将其通过用例模板描述出来
	用例的八要素：用例编号，模板，标题，预置条件，操作步骤，输入数据，预期结果，优先级
评审测试用例	三方（测试+开发工程师产品经理）	评审通过的测试用例	测试完成用例编写后，发送用例评审会议邀请给到相关人员到了具体开会时间，大家一起开会评审，由测试讲解用例，其他成员有建议或补充的，会后会对用例进行补充
搭建测试环境	测试工程师/其他专人	测试环境	开发完成程序后，提交程序代码包给到测试（提测/开发转测试），测试在测试服务器上安装相关软件，部署代码
冒烟测试	测试工程师	由一到两名测试工程师在测试环境下，对软件的核心的，基本的功能进行检查和验证
全面执行测试用例	测试工程师	缺陷（Bug）	执行负责功能模块的测试用例，发现缺陷，上报并跟踪缺陷
回归测试	测试工程师	缺陷（Bug）	对新老功能进行全面回归测试，确保新开发的功能能正常使用，也要确保已经存在的功能能正常使用
编写测试报告	测试工程师	功能模块的测试报告	测试工程师完成测试后，针对自己负责的功能，编写测试报告（主要包括用例的执行情况，缺陷的发现情况），提交给测试经理
测试总结	测试经理/测试主管	测试总结报告	整个项目完成测试后，测试经理对整体测试情况进行分析并总结，编写总结报告（主要包括实际测试时间，实际测试范围，整体的用例执行情况，缺陷发现情况，做的好的方面，需要改进的方面，测试的结果是否通过）

敏捷开发

1. 理想状态下的敏捷开发流程

由高端人员（客户，市场，高层）提出一些原始的需求（创意，缺陷，功能），由产品负责人收集并整理（进一步明确功能点的要求，确定优先级等）在产品功能列表中，在一个迭代开始后，产品负责人根据优先级，提取出当前迭代要完成的功能并和项目团队一起召开计划会/【迭代规划会议】，在会议上最终明确当前迭代要开发的功能并对功能进行进一步的任务细分，将具体任务分配给每名开发团队人员，开发人员依次完成各自任务直到迭代结束，在整个迭代周期内，开发团队每天召开每日站立会议，迭代结束后，生成可工作的软件产品，相关人员（产品负责人，流程管理员，开发团队）一起召开评审会，在会议上由每名开发成员对自己的成果进行操作演示，其他成员一起评审最终的产出是否具备发布的标准，如果具备，迭代发布，项目团队如开回顾会议

三大角色： 产品负责人：负责需求的收集并整理

流程管理员：负责开发过程中保障开发成员的进度，协调各项事务

开发团队：负责开发出高质量的工作产品

四大会议： 迭代规划会议/计划会：可以取代项目计划

每日站立会议：每天的工作内容的例行沟通，如有新任务，安排新任务等，快速处理一些遇到的问题

评审会议：评审工作的产出是否符合发布的标准，可以取代测试工作

回顾会议/反思会：总结迭代的工作，对于做好的方面予以推广，做得不好的方面提出改进事项，对下一个迭代进行一些初步沟通

1. 当前企业实际的敏捷开发流程

由端人员（客户，市场，高层）提出一些原始需求（创意，缺陷，功能），由产品经理收集并整理（进一步明确功能点的要求，确定优先级等）在产品功能列表中，在一个迭代开始后，产品经理根据优先级，提取出当前迭代要完成的功能，项目经理编写迭代的项目计划，并确定时间，范围，资源，人员及任务安排等，每名开发成员都明确了自己的任务，并依次完成各自任务直到迭代结束，在整个迭代周期内，开发团队每天召开每日站立会议，迭代结束后，生成可工作的软件产品，开发提交程序给到测试团队，测试完成测试工作后，迭代发布，项目团队成员如开回顾会议。

三大角色：产品经理（产品负责人）

项目经理（流程管理员）

开发+测试（开发团队）

1. 敏捷中的测试

测试会参与需求评审，确定需求后，测试经理编写测试计划，测试方案，并分配任务给测试人员，测试人员结合需求，针对自己所负责的功能分析测试范围并列出测试点，设计并编写测试用例，用例完成后，与三方一起评审用例，确保用例对需求的覆盖是完整的，正确的，当开发完成代码后，提测，测试人员搭建测试环境，并在测试环境执行冒烟测试，冒烟通过后，开始全面执行测试用例，发现缺陷后上报并跟踪缺陷，对项目进行回归测试，当测试人员完成各自的功能的测试后，编写测试报告提交给测试经理，测试经理对整个项目的测试情况进行总结，编写总结报告。

1. 敏捷流程中的一些术语

Sprint - 迭代

Product backlog - 产品需求清单/产品功能列表

Sprint/Project backlog - 迭代需求

User Story - 用户故事/需求点/功能点

Demo - 演示

kanban board - 任务看板

Burndown chart - 燃烬图

软件质量

1. 软件质量的三个层次

• 满足需求规格
• 满足用户的显式需求
• 满足用户的实际需求（显式需求+隐含需求）

1. 影响软件质量的因素（质量的铁三角）

• 技术：直接影响软件质量，比如编码技术，分析技术，测试技术
• 流程：直接影响软件质量，体现的是活动的先后顺序
• 组织：间接影响软件质量，体现的是管理

质量管理体系

1. ISO 9000

八项质量管理原则：以顾客为中心，以顾客的需求为导向

1. CMM/I - Capability-Maturity Model/Integration - 能力成熟度模型/集成

从低到高分别是：初始级，可重复级，已定义级，已管理级，优化级

1. 六西格玛

百万样本中3.4个缺陷

质量模型

1. 功能性

• 适合性：满足特定用户的基本需求，比如老人机的功能，字体大，按钮大，声音大
• 准确性：功能是否正确，精度是否足够，比如金额计算的精度
• 完备性：功能对指定用户或目标的覆盖的程度
• 互操作性：功能之间的互相跳转或调用，比如注册界面有登录链接
• 保密安全性：保护信息与数据安全的能力，比如：敏感数据加密传输及保存，限制有风险的文件上传，权限控制等

1. 可靠性

• 成熟性：体现在是否能很好的处理内部的错误，比如能否捕获相关异常
• 容错性：体现在是否能很好的处理外部的错误，比如用户的非法操作，异常输入要有合理的提示
• 易恢复性：体现在出现一些意外的恢复能力，比如断网，打断，弱网等

1. 易用性

• 易学性：体现在用户能否很好的学习软件，比如是否有操作手册，帮助文档等
• 易理解性：功能是否被用户很好的理解，比如一些交互或提示是否清晰易懂
• 易操作性：体现在用户是否能很好的操作系统，比如菜单不能太深，按钮不能太小等
• 易吸引性：体现在能否很好的吸引用户，比如界面是否整齐，美观，布局是否合理等

1. 效率（关注点是性能测试）

• 时间特性：体现在响应时间方面，比如一个操作多久能返回结果
• 资源利用率：体现在对服务器资源消耗方面，比如cpu，内存，磁盘
• 数据库容量：体现在数据库中有大量数据或会产生大量数据时的处理

1. 维护性

• 易分析性：体现在出现问题后对问题的分析与定位方面，比如增加日志等
• 易改变性：体现在指定功能被修改或实现的能力，与设计有关
• 稳定性：体现在相关修改是否会破坏其他结构或功能，与架构有关
• 易测试性：体现在测试软件时能否快速判断是否符合要求

1. 可移植性

• 适应性：体现在能否适应不同的环境，比如不同操作系统，浏览器等
• 易安装性：能否快速安装，升级，卸载
• 共存性：体现在和其他软件或系统同时存在的能力
• 易替换性：体现在同样的环境下，替代另一个具有相同功能的软件的能力

软件质量活动

1. SQA与测试的关系

• SQA从流程方面保证软件的质量
• 测试从技术方面保证软件的质量

1. SQA的主要职责范围

指导并监督项目按照过程实施；

对项目进行度量、分析，增加项目的可视性；

审核工作产品，评价工作产品和过程质量目标的符合度；进行缺陷分析，缺陷预防活动，发现过程的缺陷，提供决策参考，促进过程改进

1. 软件度量

• 规模：软件产品大小，如文档页数，代码行数，用例个数
• 工作量：一个人完成某个任务所用的时间叫该任务的工作量，工作量的单位有 人天（Man Day） 或 人时(Man Hour)如一个开发完成2.0版本的所有功能，需要10天，则2.0的开发工作量为10人天，如果一天的工作时间为7小时，则2.0的开发工作量为70人时
• 进度：各个阶段的开始，结束时间
• 质量：不同阶段的Bug数，不同维度的Bug数