软件测试基本理论
1、软件测试：
-
软件测试：验证软件是否满足用户的需求。
-
IEEE定义：
在规定条件下运行系统或构件的过程：观察和记录结果，并对系统或构件的某些方面做出评价。
分析软件项目的过程：检测现有状况和所需状况之间的不同，并评估软件项目的特性。
2、软件测试和软件开发的区别：
软件测试和软件开发中的调试的区别
-
目的：
软件测试的目的：测试人员根据需求去判断软件是否满足用户的需求。
调试的目的：软件开发人员为了验证程序是否可以让程序实现的功能。
-
角色：
调试：开发人员
测试：测试人员、开发人员（单元测试）
-
阶段：
调试：软件开发阶段
测试：整个软件开发的生命周期
-
方法：
调试：程序和逻辑算法
测试：测试方法和技术
测试左移：需求前的调研阶段和需求阶段，测试人员参加。
测试右移：产品上线后，系统监控、日志记录和分析。
3、软件测试的目的和原则
目的：
直接目的：找bug,保证bug被修复。（以最少的人力、物力、时间找出软件中潜在的各种错误或缺陷，保证各种错误和缺陷得 以修复。）
长远目标：利用测试过程中得到的测试结果和测试信息，作为后续项目开发和测试过程改进的重要输入，避免在未来的开发和 测试中出现重复的错误。
原则：以客户为中心，遵循软件测试的规范、流程、标准和要求。
4、需求
需求：满足用户的期望或符合合同规定的标准、规范以及文档所需要的条件和权限。
用户需求：用户想要软件实现的功能。
软件需求：用户需求的具体细化和具体实现细节，开发人员据此软件需求而必须实现的软件功能。
软件需求是由用户需求转化而来的。
5、BUG
（1）软件需求规格（软件需求）存在且合理，但软件功能和软件规格不相符合，即为软件错误。
（2）软件需求规格不存在时，若用户需求存在且合理，软件功能和用户需求不相符，即为软件错误。
6、测试用例
向被测试系统发起的一组集合，包括测试数据、测试步骤、测试平台、预期结果。
7、开发模型
（1）瀑布模型
优点：各个阶段较独立，着重需求分析和软件测试。
缺点：无法适应需求的变化，测试到编码之后才介入，导致前期的缺陷无法及时发现，无法及时修改。
适用场景：适用于需求稳定的项目。
（2）螺旋模型
优点：强调软件的质量，进行严格 的风险分析，提供项目是否有必要继续进行下去的风险。
缺点：引入风险管理，成本高。
适用场景：前期需求不是很明确，且有风险，项目比较庞大的系统开发。
（3）迭代、增量模型
迭代模型：迭代是反复求精的概念。
增量模型：增量是逐块建造的概念，增量开发能显著降低项目风险。
（4）敏捷模型
轻文档，轻流程，重目标，重质量，拥抱变化，适应需求的变化
目标：交付高质量的可用的软件。
scrum流程：
PO，product owner 产品经理：将客户的需求整理成user story，根据user story的紧急程度排出本期要迭代 的user story ，并形成sprint backlog，PO是客户的代表方。
SM，scrum master 项目经理：负责保证整个敏捷流程的顺利实施。
ST，scrum team 研发团队：目标是交付一个高质量可用的软件。
（1）发布计划会议
（2）迭代计划会议：细化user story ，分配任务。
（3）每日站会：开发过程中，汇报昨天完成情况、所遇困难及今日计划。
（4）产品演示评审会：给用户演示完成的产品，PO将用户提出的意见整理成新的user story放到下一次迭代中。
（5）回顾会议：对本期迭代进行总结。
8、软件测试模型
（1）V模型
优点：明确的标注了测试过程中存在的不同类型的测试，并且清楚的描述了这些测试阶段和开发过程期间各阶段的对应关系。
缺点：仅仅把测试作为在编码之后的一个阶段，未在需求阶段就进入测试。
（2）W模型
优点：测试与开发是同步进行的，有利于尽早地全面的发现问题
缺点：需求、设计、编码等活动被视为串行的；测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下 一个阶段工作。无法支持敏捷开发模式。对于当前软件开发复杂多变的情况，W模型并不能解除测试管理面临着困惑。
9、软件测试的生命周期（软件测试的流程）
需求分析——测试计划——测试设计/开发——测试执行——测试报告
（1）需求分析：分析需求、细化需求，验证需求的正确性和合理性。
（2）测试计划：规划测试人员数量、规划时间、测试范围、测试目的。
（3）测试设计/开发：分析需求，从细化的需求中提炼功能点，设计测试用例。
（4）测试执行：执行测试用例，记录BUG。
（5）测试报告：测试的范围、测试用例的数量、已执行测试用例的数量、未执行测试用例的数量、已发现BUG数量、已修改BUG数量（修改之后需再测）、遗留BUG以及解决方案。
10、如何描述一个BUG?
（1）版本号（代码版本号）
（2）测试环境（平台）：不同的浏览器
（3）测试步骤和测试数据
（4）实际结果、预期结果
（5）附件（错误截图、错误日志等）
11、BUG级别的定义
（1）崩溃：系统运行阻断，严重影响开发人员和测试人员的工作，需立即修复。（线上出现崩溃级别的BUG，可先回退到之前的一个稳定版本）
（2）严重：系统还可以运行，但不稳定，继续运行可能会产生严重的后果。
（3）一般：系统可以稳定运行，但一些次要功能未实现，影响用户体验。
（4）次要：（建议性BUG）影响用户的视觉体验，如界面展示、排版等等（是否需要修改可和产品经理商量）。
12、BUG的生命周期
7838
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
