软件测试

1、什么是软件测试

使用人工操作或软件自动运行的方式来检验它是否满足规定的需求；弄清预期结果和实验结果之间的差别的过程。

预期结果
指用户的预期结果（产品经理和需求分析员根据客户需求）
实际结果
指的是软件的实际运行结果
软件缺陷
预期结果与实际结果之间的差别

边开发边测试

敏捷测试：快速上线（一周）自动化

2、软件测试的目的

把尽可能多的问题在产品交给用户之前发现并改正
确保最终交给用户的产品功能符合用户的需求
​ 1.确保产品完成了所承诺或公布的功能
​ 2.确保产品满足性能和效率的要求
​ 3.确保产品健壮和适应用户环境
建立软件质量的信心，度量和提高被测软件的质量。

3、软件测试的原则

1. 测试能显示缺陷的存在
2. 穷尽测试是不可能的
3. 测试尽早介入
4. 缺陷的集群性（二八原则：在任何一组东西中，最重要的只占其中一小部分，约20%，其余80%尽管是多数，却是次要的，因此又称二八定律。要辨别事情的重要程度，先解决最重要的事，要有目的性和次序性）
5. 杀虫剂悖论（在软件测试中用来描述这样一种现象，对软件进行越多的测试 ，那么该软件对软件测试人员的测试就越具有免疫力。）
6. 测试活动依赖于测试内容
7. 没有失效不代表系统是可用的
8. 测试的标准是用户的需求
9. 测试贯穿软件整个生命周期
10. 独立的测试团队

4、测试的阶段

SIT（开发阶段）内部的测试人员

UAT（验证阶段）用户验收产品——第三方的测试人员

5、测试的过程

需求分析=评审==>测试计划==>测试计划（方案）>测试用例>执行测试==>测试报告

6、测试人员应具备的素质（了解）

必备技能

1. 软件测试知识：测试计划、测试方案、编写用例、提交bug、跟踪bug，编写测试报告
2. 测试工具的使用
3. 操作系统
4. 编写代码的能力
5. 数据库知识
6. 业务知识、网络知识

辅助素质

1. 主动沟通，清晰了解掌握需求逻辑，和专业的问题反馈。
2. 胆大心细；相信自己，自己是专业的
3. 不被别人绑架；要有职业标准，也要有自己的态度
4. 对一切都要有怀疑的态度
5. 责任心；站在公司和用户的角度考虑问题

7、win+R(系统软件自带的命令）

输入cmd、control、mspaint

8、常见的软件系统架构

B/S架构（Browser/Server，浏览器/服务器模式）

该模式统一了客户端，将系统功能实现的核心部分集中到服务器上，简化了系统的开发、维护和使用成本。

B/S架构的几种形式

1. 客户端–服务器–数据库

2. 客户端–web服务器–应用服务器–数据库

3. 客户端–负载均衡器（Nginx）–中间服务器（Node）–应用服务器–数据库

C/S架构全称为客户端/服务器体系结构

它是一种网络体系结构，其中客户端是用户运行应用程序的PC端或者工作站，客户端要依靠服务器来获取资源。

9、软件测试分类

10、软件测试流程图

1. 需求分析，需求评审（RPD、产品原型图）
2. 制定测试计划（产品项目计划，人员安排、任务安排）
3. 制定测试方案（测试需求点分析，测试模块划分，流程图分析，制定测试规程）
4. 编写测试用例（功能测试用例、脚本测试用例）
5. 执行测试用例（功能点测试、脚本测试）
6. 进行回归测试，出阶段性测试报告（跟踪bug修改情况，缺陷修复进度）
7. 进行验收测试，出验收测试报告（完成测试环境测试，提交生产环境进行验收测试）
8. 产品上线后跟踪与维护（收集用户反馈问题）

10、软件生命周期

什么是模型

模型是一种工具，它把庞大、复杂、零乱的信息通过抽象简化这样的整理，让人更容易理解。

软件开发模型

软件开发模型也叫软件生命周期模型。是软件开发全过程。能够覆盖软件生命周期的基本阶段。
典型的软件开发模型有：瀑布模型、快速原型模型、螺旋模型、演化模型

11、软件测试模型
（1）V模型

（2） W模型

（3）H模型

软件测试模型总结

12、敏捷开发模型(Agile Development)
以用户的需求进化为核心、迭代、循序渐进的开发方法，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试具备集成和可运行的特征。
1、详细的产品需求列表，排定优先级，这些便需要产品经理来完成的工作，同时一般会有研发、UI、运营等人的配合;
2、工作量的评估：这一项需要技术人员的支持，同时也需要产品经理，内容就是沟通各方面的资源、权衡技术难度，制定详细的规划;
3、计划会议：这里是迭代的目标以及时间，同时把每一个大的任务细化到每个小任务——2、3天完成;
4、站立会议：每日开站立会议，每个人说明自己昨天完成了什么任务，今天要做什么，把已经完成的任务从未完成区域放在燃尽图的已完成区域;
5、做到每日集成，每天都有一个成功编译、并且可以演示的版本;
6、当一次迭代完成的时候，组织演示会议，也叫评审会议，邀请部门经理等管理者参加;
7、总结：轮流发言、讨论需要改进的地方，放入下一轮产品的需求中。
13、专有名词解释
（1）Product Owner ，简称“PO”，翻译为“产品负责人”或者“产品拥有者”。PO主要是Built the right thing,即做对的事情。通过开发团队，最大化地实现产品的价值。

（2)Product Backlog，简称“PB”，中文翻译是“产品待办事项”，就是要实现产品价值，需要做的事情。这里包括业务功能和非业物功能。

（3）Product Owner 职责
PO最重要的一个职责就是管理好Product Backlog(PB)：
1、首先能够向团队清楚地传达Product Backlog的内容。
2、确保团队能够理解Product Backlog中的内容。
3、为了达到产品的目标和任务，PO对Product Backlog中的内容进行最优排序。
4、确保Product Backlog中的内容是可视化的，透明的，对任何人都是清晰的。同时
要告知团队接下来做什么。
5、优化团队工作的价值。

（4）敏捷开发中的SM即Scrum Master，字面意思是敏捷专家或者敏捷大师，即熟悉敏捷开发模式及敏捷实施流程的人员。
Scrum Master是规则的执行者，他是Scrum团队中的服务型领导。

工作职责
确保scrum被理解和正确使用并使得Scrum的收益最大化。主要职责如下：
1、保证团队资源合理利用；
2、保证各个角色及职责良好协作；
3、解决团队开发中的障碍；
4、作为团队和团队外部的接口，协调解决沟通中的问题；
5、保证开发过程按计划进行，组织Scrum Planning Meetings（Sprint计划会议）,Daily Stand-up Meeting（每日站会）, Sprint Review Meeting（Sprint评审会）和 Sprint Retrospective Meeting（Sprint回顾会）
总结SM角色就是：教整个团队怎么做，如何估时，跟进每天进度，风险控制，定期总结，计划排定。

（5）Sprint（冲刺）：Scrum guide中把固定时间盒周期称为sprint（冲刺）
Sprint包含计划会议、每日例会、开发工作、评审会议、回顾会议。
1）Sprint计划会议
计划会议确定Sprint中要完成的工作，有整个Scrum团队一起完成。
注意事项：首先需要明确回答两个问题：1、这个Sprint最终完成后要交付的结果2、为此需要做的具体工作
2）每日例会
目标：评估Sprint进度。同步成员的活动，并创建一天的计划。提前暴露问题，降低风险。
3）Sprint评审会议
会议内容：
产品负责人确定哪些已完成，哪些未完成开发团队讨论在Sprint中哪些进度顺利、遇到了什么问题，如何解决的开发团队演示完成的工作整个团队就下一步的工作进行探讨，根据完成的事项，最终输出一份修订的产品代办列表
4）Sprint回顾会议
Scrum团队检验自身，并列出要改进的点对前一个Sprint周期中的人、过程、工具进行验，列出 better 和 to be better，列出要改进的点

（6）其他
迭代过程（Iterative process）
用户故事（User stories）
任务（Tasks）
站立会议（Stand-up meeting）
持续集成（Continuous integration）
最简方案（Simplest solutions）
重构（Re-factoring）

14、敏捷测试优缺点
优点
1、迭代快，开发周期短;
2、不再耗费大量的时间来写文档，而是人与人面对面交流，只写一些必要的文档;
3、分工详细，每天都输出成果，客户能够看得到，会信任项目团队;
4、沟通多，容易发现问题，同时能够激起团队的协作、奋斗精神;
缺点
1、人与人之间的信任是非常重要的环节，但是这个比较难完成，技术团队的成员可能技术能力差别大，同时也有互相竞争，又或者是项目团队的成员有所保留，不愿意这样的沟通;
2、团队在开发期间的任务多、压力大，需要时刻保持“兴奋”，一般很难做到。

15、DevOps
DevOps这个词，其实就是Development和Operations两个词的组合。DevOps是一组过程、方法与系统的统称，用于促进开发、技术运营和质量保障（QA）部门之间的沟通、协作与整合。

从目标来看，DevOps就是让开发人员和运维人员更好地沟通合作，通过自动化流程来使得软件整体过程更加快捷和可靠。