表达输出+知识技能 ； JD-（JobDuty）岗位职责

一、软件相关知识

1、什么是软件

软件 = 程序 + 数据+ 文档

注：
（1）程序 = 源程序（部署在服务器上） + 目的程序；
（2）数据包括用户产生的数据和后台管理员产生的数据（用户产生的数据有误不算BUG）
（3）文档主要是整个软件研发过程中产生的需求、设计文档
（4）软件BUG包括程序BUG、数据BUG、文档BUG

2、软件生命周期

调研，可行性分析（报告）
（1）计划：项目计划文档，由项目经理编写，主要包括工作内容、人员分配、时间安排、成本分析、风险分析；
（2）需求：需求规格说明书（SRS），产品部的产出物（输入工件/交付件），包括界面原型图；
（3）设计：
* 概要设计文档：项目的整体架构，包括哪些模块及模块间的接口；
* 详细设计文档：每个模块具体实现的逻辑设计；
* 数据库设计文档：数据表的设计；
（4）编码：程序员依据需求文档和设计文档写代码，得到程序；
（5）测试：测试人员比对程序（实际结果）与需求、设计文档（预期结果）是否一致；
（6）上线，运维：运维人员负责软件上线及后期的维护工作；
注：测试在需求阶段介入；

3、测试流程（重点）

（1）需求评审：产品部、开发部、测试部三方针对需求文档进行评审，确认需求是否完善、是否准确、是否具备可行性等，经过多次修改后输出需求规格说明书（SRS）；
（2）测试计划：由测试经理完成，包括测试范围、人员分配、时间安排及风险分析等等；
（3）测试方案：测试经理/高级测试工程师编写，包括测试策略、测试工具、测试资源、测试方法等；
（4）测试点分析（重）：根据需求分析测试点，每个需求可以分析出若干个知识点，测试点分析越全面越好；
（5）编写测试用例：将每个测试点以规范的用例模板编写出来；
（6）评审测试用例：产品、开发、高级测试与测试用例作者一起参与，评审用例是否准确、覆盖是否全面；
（7）开发部编码完成，将源程序提测给测试部门；
（8）测试部门 拿到源代码后，搭建 测试环境；（对于网站，搭建成功就是能访问到对应网页）不用每个人都搭建
（9）冒烟测试：找1-2名有经验的工程师针对软件的主要功能进行测试，如果存在致命问题或大量问题，则测试挂起（暂停），冒烟测试不通过，不展开测试用例执行工作；
（10）执行测试用例：冒烟测试通过后，测试人员根据 用例优先级 开始执行测试用例；
（11）提交并跟踪缺陷报告：执行测试用例时，遇到实际结果（软件界面现象、数据库中数据变化）与预期结果不一致的，则为发现缺陷（BUG），并提交；
（12）多伦回归测试，直到最后一个版本达到上线标准：验证缺陷修复是否完成并重新测试通过的用例；（自动化测试 可以提高效率）
（13）发布上线，撰写测试总结报告；（版本迭代又重新开始）

4、项目组成员

（1）项目经理
（2）需求人员
（3）设计人员
（4）编码人员
（5）测试人员：发现缺陷
（6）运维人员
（7）QA（Quality Assessment)）质量保障人员：

• 工作目标：预防缺陷
• 工作职责：制定流程规范；监督项目组成员是否按流程工作；评审项目成果（尤其是测试产出物）；

（8）配置管理人员：使用专业的 配置管理工具 管理软件整个研发过程中涉及的所有产出物；

5、软件研发模型（软件研发过程）

（1）瀑布模型：按步骤，每步走完了才进行下一步；

• 优点：需求稳定，重复工作少，质量相对较高；
• 缺点：周期长，成本相对较高；

（2）螺旋模型（目前平均3-6月迭代一个版本）
（3）敏捷开发模型（目前平均3周迭代一个版本）

• 优点：周期短，上线灵活；
• 缺点：需求频繁变更，重复工作多，质量相对较低；

6、BUG类型

（1）遗漏：软件 中未实现 需求 中明确规定内容；
（2）错误：软件 中实现效果与 需求 中描述的 不一致；
（3）冗余（额外实现）：软件中实现了需求中未明确规定的内容；

二、测试基础

1、什么是软件测试

使用人工和自动手段来运行或测试某个系统的过程，目的在于检验软件是否满足规定需求或是弄清实际结果与预期结果之间的差别。

2、软件测试目的

（1）发现错误
（2）检测软件是否满足规定的需求（功能需求、性能需求、可靠性需求等）

注：软件测试无法证明软件不存在缺陷

3、软件测试原则（经验）

（1）所有的测试都应该追溯到用户需求
（2）测试尽早介入（需求阶段）
（3）穷尽测试是不可能的
（4）并非所有的缺陷都值得修复
（5）BUG的群集效应（bug扎堆，发现的缺陷越多，存在的缺陷越多）
（6）28法则（帕累托法则）：80%的缺陷存在于20%的核心业务模块中
（7）good-enough：不做不充分的测试，不做过分的测试
（8）小规模测试到大规模测试
（9）杀虫剂怪事：测试用例对缺陷具有免疫
（10）前进（版本更新）2步，后退1步（回归测试是重复测试工作）

三、测试方法

1、按是否关注程序内部结构分

（1）黑盒测试：根据需求规格说明书，在 软件界面 上做各种情况输入，验证输出与预期是否一致
（2）白盒测试：依据详细设计说明书，分析源代码逻辑与预期是否一致
（3）灰盒测试：结合使用黑盒测试与白盒测试

2、根据是否动态运行软件分

（1）静态测试：不运行软件，静态测试包括代码走查，文档测试，需求评审，用例评审等
（2）动态测试：运行软件找BUG

黑盒测试是动态测试（或者动态测试是黑盒测试），这个说法是错误的，就像按学历与性别区分一群人一样。

3、根据是否使用自动化工具分

（1）手工测试
（2）自动化测试

四、测试阶段

1、单元测试

（1）测试范围：测试程序的最小单位，如 函数 或 类
（2）测试依据：详细设计说明书
（3）测试方法：白盒测试
（4）评估基准：逻辑覆盖（代码中发生的情况都去测试一遍）

2、集成测试（组装测试）

（1）测试范围：测试模块与模块间的接口，及集成后的功能
（2）测试依据：概要设计说明书
（3）测试方法：灰盒测试
（4）评估基准：接口覆盖

3、系统测试

（1）测试范围：整个系统的功能及非功能（性能、兼容、安全…）
（2）测试依据：需求规格说明书
（3）测试方法：黑盒测试
（4）评估基准：需求覆盖

4、验收测试（3小点）

（1）正式验收测试（适用外包项目）
（2）α测试（适用自研项目）：在开发场地完成，技术人员指导，用户参与；如 游戏的内测
（3）β测试：在用户时间场地完成，无技术人员指导，用户参与；如 游戏的公测

五、系统测试

目前国外主要应用的单元测试比较多，国外相比成本更看重质量；
国内呢目前st（系统）测试为主，偏向接口发展…

1、测试范围

整个系统的功能及非功能

2、测试依据

需求规格说明书（SRS）

3、测试方法

黑盒测试

4、评估基准

需求覆盖

5、15种测试类型（测试策略）

（01）功能测试
单用户操作下，测试软件的逻辑功能是否正常
（02）性能测试
多用户操作下，测试软件的响应时间及资源消耗情况等性能表现
（03）界面测试（UI测试）
测试软件的界面布局是否合理、是否美观、是否具有吸引性等
（04）兼容测试
测试软件从一种环境迁移到另一种环境的能力
（05）安全测试
测试软件是否能安全的提供功能（功能下边的一个子特性）
（06）易用性测试
测试软件使用是否方便、易操作、易理解
（07）可靠性测试
测试软件的能力和易恢复能力
（08）稳定性测试
测试软件是否能够长期正常运行
（09）文档测试
测试软件研发过程中的需求、设计、用户手册、安装手册、帮助文档等进行的测试
（10）安装测试
（安装测试、卸载测试、升级测试都是CS架构下的）
对CS架构软件的一个安装测试
（11）卸载测试
对CS架构软件的卸载测试
（12）升级测试
对CS架构软件的升级测试
（13）容量测试
测试软件消耗客户端资源的一个情况
（14）接口测试
包括 系统内服务器端的接口与系统间的服务器接口（谁提供谁测试）；

客户端的形式多样化，为避免重复工作，可以提前介入测试服务器；
不同软件间数据共享（eg：京东购物调用微信支付）
做接口测试可能会涉及到安全测试、性能测试等；

（15）网络测试
主要针对移动APP开展网络测试

6、系统测试 执行活动

（测试流程后半段，实际操作测试的流程）
（1）搭建测试环境
（2）冒烟测试
（3）执行测试用例
（4）提交并跟踪缺陷报告
（5）回归测试
（6）撰写测试总结报告

7、研发模型 补充（软件研发的流程）

（1）瀑布模型
（2）螺旋模型
（3）敏捷开发模型
（4）V模型

• 特征：左边是开发流程，右边是测试流程；横向看左边开发的产出物正好是右边测试的依据
• 缺点：测试在编码后介入，违背了尽早启动测试的原则
  

（5）W模型
双v（开发、测试），开发工作测试工作并行完成；

• 特征：一个V是开发流程，另一个V是测试流程；测试包括设计阶段与执行阶段，正好对应V的左右
  

六、软件质量

1、质量的定义

实体（具体的产品）基于实体特性满足需求的程度

实体:

• 产品: 手机、MP3、汽车、ERP软件、桌子…
• 服务：酒店、出租车、快递、培训、美容…

2、质量的层次

（1）满足需求规格
（2）符合客户的显性需求（客户明确提出的需求）
（3）符合客户的实际需求（用户明确说明的和隐含的需求）

3、质量三要素

（1）组织（人才）
（2）技术（前沿技术）
（3）标准（严格）

4、软件质量模型特性（理解）

定义：一组特性及特性之间的关系，提供了规定质量需求和评价质量的基础
外部（用户关注的）质量：功能性、可靠性、易用性、效率、可移植性
内部（开发者关注的）质量：维护性

（1）功能性（5个）
A.适合性：软件必须提供最基本的功能

Eg：Word提供打开、新建、输入、保存文档的功能
Eg：淘宝提供的注册、登录、搜索、浏览、购买、订单跟踪等基本功能

B.准确性：准确的提供功能，精度要够

Eg：Word中对齐功能是否准确，
Eg：淘宝中订单金额 精度是否够
Eg：饿了么中定位功能是否准确

C.互操作性：与其它软件互操作的能力

Eg：一般是不同公司研发或者维护的系统之间存在互操作性
Eg：淘宝支付调用支付宝、银行卡支付

D.保密安全性：
数据的安全性，权限的安全性。

Eg：网站登录信息是否有做加密处理，属于数据的安全性
Eg：需要登录才能访问的网页，如果不登录是否也能访问，属于权限的安全性
Eg：SQL注入

E.功能性的依从性：符合行业规范、标准、用户习惯等

（2）可靠性（4个）
A.成熟性：能够很好的处理软件的内部错误（通过代码异常处理机制将可能发生的错误在内部消化处理）

eg：微信，在使用过程中，占用的内存不会一直增加

B.容错性：能够很好的处理软件的外部错误（用户输入）
C.易恢复性：软件失效后，能够恢复正常运行的能力
D.可靠性的依从性
（3）易用性（5个）
A.易理解性

Eg：Word未选中文本时，复制功能置灰
Eg：Word分页功能中，最后一页的下一页按钮置灰

B.易学性

Eg：Word中提供的丰富的帮助文档

C.易操作性：操作简单，建议不超过3个步骤
D.吸引性：界面美观，样式统一，布局合理
E.易用性的依从性

（4）效率（3个）：描述系统的性能表现
A. 时间特性

358原则：3s以内响应用户感受良好，3-5s内用户可以接受；5-8s内用户可以忍受；8s以上用户无法忍受

B. 资源利用性：消耗设备的CPU、内存、流量、电量等
C. 效率的依从性

（5）可移植性（5个）：软件从一种环境迁移到另外一种环境的能力
A.适应性：可以适应不同环境的能力（兼容性）
B.易安装性：在不同环境下安装是否方便（期望不同环境下安装步骤一样）
C.共存性： 与其他软件（杀毒软件、同行业软件）的共存能力（eg： 3Q大战）
D.易替换性：方便升级或降级
E.可移植性的依从性
（6）维护性（5个，了解）
A.易分析性： 可能过增加日志记录功能，出现问题时方便定位分析
B.易改变性： 增加功能是否方便
C.稳定性： 修改尽量少，修改方便
D.易测试性： 直观看到页面打开的时间

Eg：开发编写代码用于记录打开时间

E.维护性的依从性

5、质量管理体系（了解）

（1）ISO9000系列
（2）CMM模型（能力成熟度模型，5级）：一种用于评估软件外包商能力的模型

A.初始级 B. 可重复级 C. 已定义级 D. 可管理级 E. 优化级

七、测试用例（必备技能）

1、写好测试用例关键要素（2点）？

（1）规范编写测试用例（公司的规范）
（2）尽可能全面的覆盖测试点

2、如何保障测试用例的覆盖率（3点）？

（1）需求100%覆盖
（2）测试人员综合使用各种用例测试方法，覆盖尽可能多的测试点
（3）测试用例评审

3、测试用例的要素有（8点）？

用例编号、测试模块、用例标题、重要级别、预置条件、测试输入、预期结果
（1）用例编号：用于唯一标记每一条测试用例（eg：学号）
编号规则（参考）：项目代号-模块名-序列号（eg：bbjz-login-001）
（2）测试模块：
一级模块名–二级模块名
（3）用例标题：描述用例的测试点
每一条用例标题不要重复（细分），写出具体测试点
简洁
（4）重要级别：用于决定用例的执行顺序，根据系统功能的重要程度划分：
高：核心业务模块的正向用例
中：核心业务模块的反向用例；一般业务模块的正向用例
低：一般业务模块的反向用列；其他模块的用例
（5）预置条件precondition：执行当前测试操作（操作步骤）需满足的前置条件

（6）操作步骤step：（测试点）
加数字序列号，每个步骤一行
写明测试点，不要写具体测试数据（下步写）

（7）测试输入Input：符合操作步骤测试点的一组参考数据

（8）预期结果：根据需求分析，写清楚预期结果和具体期望看到的界面现象

课堂练习：
编写测试用例—“笨笨家庭记账本”
登录：6条
增加账户转账：6条
删除账户转账：2条

八、缺陷报告

1、缺陷管理工具介绍

（1）禅道（以禅道为例学习）
（2）jira
（3）mantis
（4）bugfree
（5）bugzillar

2、搭建禅道（BS架构，PHP，MySQL）

Apache启动不了时，大多数是端口冲突

开发语言+服务器+数据库

用不到的取消勾选即可

然后解压到当前文件夹
然后打开浏览器 http://localhost/zentaopms/www

一直默认到

3、缺陷报告的要素（16点）

（1）缺陷编号（系统自动产生）
（2）所属产品
（3）所属模块
（4）所属版本
（5）指派给谁（注：不同公司处理流程有所区别）
测试人员–开发人员–测试人员–关闭
测试人员–测试经理–开发人员–测试人员–关闭
测试人员–开发经理–开发人员–测试人员—关闭
测试人员–测试经理–开发经理–开发人员–测试人员–关闭

（6）BUG类型：代码问题、界面问题、安全问题等
（7）测试环境：操作系统+浏览器
（8）严重程度：（参考，不同企业严重程度定义规则不同）
致命（导致系统崩溃、失效、闪退等），
严重（核心业务模块功能异常），
一般（一般业务模块功能异常），
较小（如界面错别字等）
（9）优先级：缺陷处理顺序，缺陷的严重程度越高，优先级越高
紧急处理：
优先处理：
正常排队：
延迟处理：可下个版本修复
（10）缺陷标题：一目了然，简洁，避免口语化
参考模板： 在XXX操作时，关键测试点，实际结果
Eg：在增加账户转账时，转出账户为空，保存成功
在增加账户转账时，转账金额输入负数，保存成功
在增加系统用户时，输入重复的用户名，保存成功

（11）缺陷描述
预置条件
操作步骤
预期结果
实际结果
（12）附件
（13）缺陷状态：
（14）创建人和创建时间
（15）解决人和解决时间
（16）解决方案