第一章 软件测试概念

1.1团队构成与工作

一、项目经理

协调客户与用户之间的沟通，向各个项目组分配资源与任务

二、产品经理

根据客户产品需求进行需求设计、需求变更，并安排等工作

三、UI设计师

根据客户需求来领导和协调 Web 界面的原型设计和正式设计

四、软件开发工程师

包括：前端开发,后端开发(java,c++,php,python),服务端开发,(数据库管理 )

软件工程师负责完成设计师的设计意图， 根据设计文档编写代码； 根据设计文档编

写单元测试代码，根据测试报告 BUG 记录修改 BUG。

五、软件测试工程师

根据需求对产品设置并执行测试，根据测试提出BUG并记录。

六、实施工程师

负责软件产品安装调试和部署，完成项目相关系统工程工作，客户技术支持，编写使用手册，维护手册

七、运维工程师

负责产品上线后的运行维护工作。

1.2了解测试软件

一、什么是软件测试

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

正确概念：

（1）测试是为了发现程序中的错误

（2）成功的测试是发现了至今为止尚未发现的错误

（3）测试并不仅仅是为了找出错误

（4） 没有发现错误的测试也是有价值的

错误概念：

（1）测试是为了证明程序没有错误

（2）软件开发完成后进行软件测试

（3）软件发布后如果发现质量问题，那是软件测试人员的错

（4）软件测试要求不高，随便找个人多都行

（5）软件测试是测试人员的事情，与程序员无关

（6）项目进度吃紧时少做些测试，时间富裕时多做测试

（7）软件测试是没有前途的工作，只有程序员才是软件高手

（8）通过测试达到零缺陷率

二、软件测试目的

把尽可能多的问题在产品交给用户之前发现并改正

确保最终交给用户的产品功能符合用户的需求

确保产品完成了所承诺或公布的功能

确保产品满足性能和效率的要求

确保产品健壮和适应用户环境

建立软件质量的信心，度量和提高被测软件的质量

三、软件测试过程

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

四、软件测试阶段

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

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

五、软件测试的原则

 

缺陷的集群性：28原则（80%的软件缺陷，聚集在20%的软件模块中）

杀虫剂悖论：相同方法重复测试，能效逐渐降低（应更换方法，使用交叉测试法）

穷尽测试是不可能的：软件的bug是无穷的，无法100%测试出来

没有失效不代表系统可用的：测试没有问题并不代表满足客户需求

六、测试人员素质具备

必备：测试计划、测试方案、编写用例、提交bug、跟踪bug，编写测试报告

测试工具的使用

操作系统

编写代码的能力

数据库知识

业务知识、网络知识

辅助：主动沟通，清晰了解掌握需求逻辑，和专业的问题反馈。

胆大心细；相信自己，自己是专业的

不被别人绑架；要有职业标准，也要有自己的态度

对一切都要有怀疑的态度

责任心；站在公司和用户的角度考虑问题。

1.3软件系统架构

一、B/S架构

（Browser/Server，浏览器/服务器模式）

Web端通过Web服物器向数据库提取数据

二、C/S架构

client/Server客户端/服务器体系结构）

客户端经过简单处理后直接向数据库提取数据

三、B/S架构和C/S架构区别

1、客户端要求： C/S客户端的计算机电脑配置要求较高。

B/S客户端的计算机电脑配置要求较低。

2、软件安装： C/S每一个客户端都必须安装和配置专用的软件。

B/S不用安装任何专门的软件，只要有一个浏览器就可以。

3、软件升级和维护 ：C/S每一个客户端都要进行升级和维护。

B/S客户端不必安装及维护。

4、安全性：C/S相比B/S较为安全

1.4软件测试分类

 

一、按是否看代码分

黑盒测试：看不见代码，不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试

白盒测试：看得见代码，知道产品内部工作过程，来测试程序结构和运行逻辑。

灰盒测试：综合测试

二、按开发阶段分

单元测试：测试组成功能的每个小模块的代码

集成测试：测试由各模块组成的功能

系统测试：对产品全面测试

验收测试：交付测试,一般由用户或第三方进行。

三、按是否运行分

静态测试：不运行软件情况下检查和审阅规范测试、软件模型测试、文档测试

动态测试：运行软件进行测试

四、按是否手动测试分

手动测试：测试过程由测试工程师人工测试完成（功能测试）

自动化测试：使用软件来控制测试执行过程（性能测试）

五、其他划分

冒烟测试：指初步地进行测试，并以此展示一些简单但足以影响软件运行的错误

随机测试：对被测软件的一些重要功能进行复测

安全测试：验证产品是否符合安全需求定义和产品质量标准的过程

探索测试：

α测试：内部人员、客户使用测试（内测）

β测试：交给最终用户测试 公司外部展开的测试（公测）

测试需求：需求分析，以软件开发为基础，形成可测试的内容。

测试计划：计划编写（人员、工具、范围的计划）。

测试设计：编写测试用例。

测试记录：对测试过程、结果和数据进行记录。

分析：风险分析。

完毕：测试完成产品交付。

测试总结：根据发现和改正BUG完成情况写出报告并提交。

1.5软件生命周期模型

一、什么是模型

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

更容易理解。

二、软件开发模型

1、结构化开发：通过结构化、模块化，一步一步的完成每一项开发工作的模式。

2、迭代化开发：通过对软件模块、功能的不断更新完善的迭代形式。

3、瀑布模型：类似结构化开发模式，直线式类似瀑布直流而下的逐步进行产品开发。

4、快速原型模型：根据客户需求快速实现一款样板产品供客户使用，再根据客户反馈进行完善修改。

5、螺旋模型：结合瀑布模型和快速原型模型并加入风险分析的形式。

（1）制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件；

（2）风险分析：分析评估所选方案，考虑如何识别和消除风险；

（3）实施工程：实施软件开发和验证；

（4）客户评估：评价开发工作，提出修正建议，制定下一步计划。

6、软件开发增量模型：软件交付后逐渐增加改进功能

三。软件测试模型

1、V模型：由瀑布模型演变而来，不同阶段的测试与不同阶段的开发形成对应。

阶段步骤:需求分析、概要设计、详细设计、软件编码、单元测试、集成测试、系统测试、验收测试。

2、W模型：开发与测试同步进行，测试人员尽早进入软件测试，以减少软件开发周期并过早发现问题。

3、H模型：揭示了软件测试是一个独立的流程参与在软件开发的各个阶段。

四、敏捷开发模型

1、定义 以用户需求进化为核心、迭代、循序渐进的开发方法。

软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试。

2、原则 （1）尽早、持续交付有价值的软件来使客户满意。

（2）满足客户需求可变性。

（3）项目开发期间，业务人员和开发人员在一起工作。

（4）在团队内部，最富有效果和效率的信息传递方法是面对面交谈.

（5）团队要定期反省如何更有效地工作，并相应地调整自己的行为.

（6）好的架构、需求和设计出自于组织团队自身。

3、专有名词 （1）product Owner：简称 “PO”，产品负责人、产品经理。

职责：1、首先能够向团队清楚地传达PB的内容。

2、确保团队能够理解PB中的内容。

3、为了达到产品的目标和任务，PO对PB中的内容进行最优排序。

4、确保PB中的内容是可视化的，透明的，对任何人都是清晰的。同时要告知团 队接下来做什么。

5、优化团队工作的价值。

（2）product Backlog：简称“PB”，需求列表、待办事项。由PO管理。

（3）Scrum Master：简称“SM”，敏捷专家。

角色定义：Scrum Master是团队的导师和组织者，与Product Owner紧密合作，及时为团队成员提 供帮助。促使team按照scrum方式运行，为Scrum过程负责的人。

工作职责：1、保证团队资源合理利用；

2、保证各个角色及职责良好协作；

3、解决团队开发中的障碍；

4、作为团队和团队外部的接口，协调解决沟通中的问题；

5、保证开发过程按计划进行，组织Scrum Planning Meetings（Sprint计 划会议）

（4）Sprint（冲刺）包含计划会议、每日例会、开发工作、评审会议、回顾会议。

4、优点：（1）、迭代快，开发周期短

（2）、人与人直接交流，高效

（3）、分工详细

（4）、沟通多，容易发现问题

缺点：（1）、人与人之间的信任环节比较难完成，成员间不愿意沟通等。

（2）、团队很难持续保持激情。

5、敏捷测试：

（1）、测试人员基本素质：：代码编写（Coding）、测试 (Testing) 和分析 (Analysis)。

具有质量检测和编写代码的能力–> 测试开发

具有防止缺陷 (Quality Assurance) 和质量控制 (Quality Control) 的能力–> 质量分析员

具有开发和执行测试程序的能力 -> 软件质量工程师

（2）、测试人员主要职责：1、定义质量 (Define Quality)

2、交流缺陷（Communication）

3、及时反馈 (Feedback)

（3）、测试人员主要工作：用户故事设计和发布计划=》Sprint 周期的迭代开发和测试=》产品发布阶段。

6、 DevOPS（Development和Operations）定义：DevOps是一组过程、方法与系统的统称，用于促进开发（Development）、技术运营（Operations）和质量保障（Quality Assurance）部门之间的沟通、协作与整合。

1.6需求分析

需求分类：

1、原始需求

2、产品需求

3、软件需求 SRS（软件需求说明书）

4、测试需求

需求分析对于开发和测试的影响

1、开发：（1）如果需求不明确，系统功能研发不合理，导致软件包含大量bug

（2）大量bug修改，影响进度和团队情绪

（3）进度收到影响，可能造成公司产品失去市场先机

2、测试：（1）如果不能很好理解需求，会被开发牵着鼻子走，也会被人怀疑测试能力

（2）不能及时发现开发的bug，没法保证测试质量

1.7软件开发文档评审

1、定义：评审是对软件元素或项目状态进行评估的活动，用以确定与预期结果之间的偏差和相应的改进意见

2、测试文档评审：内部评审和现场评审

3、代码评审：（1）代码走查：是一个开发人员与架构师集中讨论代码的过程。代码走 查的目的是交换有关代码是如何书写的思路，并建立一个对代码的标准集体阐述。

（2）代码审查（Code review）：是指对计算机源代码系统化地审查。其目的是在找出及修正在软件开发初期未发现的错误，提升软 件质量及开发者的技术。