系统测试（重点知识）

1. 软件的生命周期：计划——分析——设计——编码——测试——运维

2. 软件的研发模型：

3.     （1）大爆炸模型： 开发人员不遵循任何特定过程，从资金投入开始，到检查是否与客户要求一致结束。
4.     （2）边写边改模型：根据用户的需求，完成一个版本后，再根据用户的修改意见，继续发布新的版本，直到用户满意。
5.     （3）瀑布模型：从可行性研究（或称系统分析）开始，逐步进行阶段性变换，直至通过确认测试并得到用户确认的软件产品位置，瀑布模型上一阶段的变换结果是下一阶段变换的输入，相邻两个阶段具有因果关系，紧密相连，一个阶段工作的失误将蔓延到以后各个阶段，为了保障软件开发的正确性，每一个阶段任务完成后， 都必须对的阶段性产品进行评审，确认之后再转入下一阶段的工作。适用于传统企业的固定流程，不适用于大规模的和市场变化快的软件产品。
6. 
7.     （4）迭代增量模型：
8.     增量：将产品按功能模块分为多个部分。每次只完成其中一部分
9.     迭代：通过多次方式，将增量划分的功能逐项实现
10.     特点： 每次只设计和实现这个产品的一部分, 逐步逐步完成的方法叫迭代开发, 每次设计和实现一个阶段叫做一个迭代.
11.    （5）螺旋模型：它将瀑布模型和快速原型模型结合起来，强调了其他模型所忽视的风险分析，特别适合于大型复杂的系统。 “螺旋模型”刚开始规模很小，当项目被定义得更好、更稳定时，逐渐展开。
12.   （6）敏捷模型：
13. scrum

三个角色：product owner、scrum master、scrum team

三个工件：product backlog(产品待办事项)、sprint backlog(sprint待办事项)、increment(可交付

增量)

四个会议：sprint planning meeting(sprint 计划会议)、Sprint Daily Standup(每日站会)、Sprint

Review(sprint回顾会议)、Sprint Retrospective（总结会议）

3.测试模型：

（1）V模型：按瀑布模型的方式完成测式。

（2）双v模型（w模型）：

在研发的瀑布模型上，增加了针对每一个过程的测试工作。让测试尽早介入。降低缺陷修复成本。

（3）H模型

（4）X模型

4.质量模型

（1）ISO25010质量模型（八个特性）

（2）六大测试类型

#功能性测试（Functionality）：关注功能是否正确。

常见关注点：

是否有不正确或遗漏了的功能

功能实现是否满足用户需求和系统设计的隐藏需求

输入能否正确接受？能否正确输出结果？

需求中没有提及，规范中也没有要求的额外功能

#可用性测试（Usability）：关注产品是否好用。

 常见关注点：

过分复杂的功能或指令

困难的安装过程

错误信息过于简单

用户被迫去记住太多的信息

语法、格式和定义不一致

#兼容性测试（Compatibility）：关注产品是否适用多种平台。

常见关注点：

兼容不同的OS

Web项目兼容不同的浏览器

兼容不同的数据库

兼容不同的分辨率

兼容不同的厂家的硬件设备，耳机、音响等。

#可靠性测试（Reliability）：关注产品是否稳定可靠。

常见关注点：

输入异常的数据

操作异常的文件

长时间工作后保持正常

多次打开应用程序

#安全性测试（Security）：关注产品是否存在漏洞。

常见关注点：

SQL注入

口令认证

加解密技术

权限管理

安全日志

#性能测试（Performance）：关注产品是否能够高效运行。

系统资源，cpu、内存、io读写

并发用户数

最大数据量

响应时间

处理成功率

5.测试概念：

狭义：找bug

广义： 通过手工或者自动的手段在不同的软硬件环境下，找预期结果与实际结果异同的过程。

（1）判断软件缺陷的原则：

1. 软件未达到产品说明书标明的功能。（缺失）
2. 软件出现了产品说明书指明不会出现的错误。（错误）
3. 软件功能超出产品说明书指明范围。（额外实现）
4. 软件未达到产品说明书虽未指出但应达到的目标。（隐性需求）
5. 软件测试员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好。（可用性不行）

（2）缺陷产生的原因：

1. 交流不够、交流上有误解或者根本不进行交流
2. 软件复杂性
3. 程序设计错误
4. 需求变化
5. 时间压力
6. 代码文档贫乏
7. 软件开发工具

（3）缺陷放大模型；与成本直接相关，测试越早，成本越低。

（4）各测试阶段参考文件：

单元测试: 详细设计说明书（low level document LLD）

接口测试: 概要设计说明书（High level document HLD）|接口文档 

系统测试: 需求规格说明书（software requirment speciŨcation SRS）| 原型图

用户验收测试：合同|需求规格说明书|验收计划

（5）测试方法：

黑盒测试：不能看到项目源码，只对编译后的项目进行功能、性能、可靠、可用、兼容、安全方面的测试。 （系统测试，用户验收测试 ）

白盒测试：在看得见源码情况下，对代码进行的测试。（单元测试 ）

     静态测试：不用运行源码，直接阅览代码。 代码走读（代码走查）

     动态方式：通过单元、接口方式对源码进行运行并断言。

灰盒测试：既可以按黑盒方法，也可以按白盒方法进行的测试。 （接口测试）

冒烟测试：在测试正式开始前，先对项目中核心功能进行有效等价类用例执行，检查核心功能是否有异常。

回归测试：在至少完成一轮测试后，验证开发是否正常修改已提交缺陷，或者是否有引入新的缺陷的测试。

    回归策略：

     完全重复回归：将所有用以从头到尾全部运行。选择性回归：

      覆盖修改法：只测开发修复部分

      周边影响法：测修复缺陷部分和与之有上下文关联关系的部分。

     指标达成法：先预定一个百分比，达到预定目标就完成本次回归。

（6）测试流程：分析--设计--实现--执行

分析：从需求规格说明书中，筛选出原始需求项，根据原始需求项提取出测试要点。将测试要点转化为需求跟踪矩阵。

测试工程师：提取需求。

测试经理、测试组长：编写测试计划。 测试计划：指导测试做什么。

设计：由测试经理编写测试方案，

实现：编写测试用例，搭建测试环境，构建测试数据

执行：执行测试用例，提交缺陷，测试报告

#1.测试方案与测试计划

测试计划：  主要包括的内容有：版本号，项目概述，组织形式，人力分布，测试进度，测试范围，测试通过/失败的标准（用例执行覆盖100%，通过95%以上，缺陷修复率达80%以上，无致命和严重级别的缺陷未修复），测试挂起及恢复的必要条件（挂起：发生致命问题，导致50%用例无法执行或者是高优先级用例未能100%执行；恢复：导致阻塞的bug被修复后，并且回归测试通过，恢复测试），测试交付物清单。（测试报告，用户文档，交付产品）

         $1封面

    $2.修改履历

 $3.目录

 

 

 测试方案：主要包括封面、履历及目录中的内容（概述，测试环境，测试策略，测试风险评估和预防，本方案评估意见）

$1.封面

$2.修改履历

$3.目录

 

 

 

     #2.需求跟踪矩阵举例：

至少包含产品需求id，原始需求，提取测试点，用例编号，用例标题。

--注意，为了方便后面写测试用例，标题尽量不要用是否代替，而是以肯定的语气。（下图的测试点就用了是否，比如第4个测试点，应该是“输入正确的手机号，验证码，能够成功登录）

（一个需求点可以分解出多个测试点，一个测试点可以分解出多个测试用例，例如：登录板块测试需求：使用正确的账号和密码能够成功登录--->测试点：使用正确的账号和密码能够成功登录；使用错误的账号名或密码不能成功登录。

     #3.测试用例设计的方法：

       测试用例设计方法，包括等价类，边界值，正交试验法，流程分析法，状态迁移法，因果图，判定表的定义等。

     #4.用例设计的八大用例要素：(可用禅道导出，用例标题要肯定）

编号：项目名称--模块名称--功能名称（阶段）--数字编号

             标题

             模块

             优先级

             前置条件

             操作步骤：

             预期结果

             备注

ps：编写用例的注意点：1.标题应用凝练的语言，有过程和预期结果，而且要加上肯定的语气，和测试点类似。比如：输入错误的密码，弹窗提示：“密码错误，请重新输入”。  

2.测试用例，比如有多种格式搭配的输入框……具体又可以细分成各种格式的搭配（参考判定表，可以分解出很多个用例，这其实也没错，但是太多的bug会让开发怀疑自己水平。这里只要有一个bug出现就可以说明这里的输入框有问题了，不管是怎样的格式问题，通常是由于开发的正则表达式写错了。）——>用例标题：输入正确的账号和错误的密码，弹窗提示：“密码错误，请重新输入”，（不用写明白，错误的密码格式是怎样的）而在执行的过程中，我们会输入很多种错误的密码格式，进行验证，比如（密码输入框为空，密码个数超过指定个数，密码个数少于指定个数，密码为中文，密码为数字+中文……拆开可以写很多种用例，但这些用例都是为了检测那一个密码的输入框，在执行中，有一种用例检验出了问题，那么这个输入框就有问题）——>这个输入框就有bug。）            如果出现了bug，在禅道等bug提交系统的步骤中，写明白是哪一种格式出现了问题就行。

3.前置条件：在……的前提下，比如，以管理员身份进入。

4.操作步骤和预期结果，一步步对应，一个操作步骤，一个语气结果。

      #5.缺陷等级的判定：

           致命：系统崩溃，如软件的意外退出，甚至操作系统崩溃，数据丢失。

           严重：功能无法使用

           一般：软件的非核心功能失效， 小问题、错别字、UI 布局（颜色，文字没对齐等），罕见故障          

            提示：不影响使用的瑕疵或更好的实现

    #6.缺陷报告包括哪些项？

缺陷报告包括：缺陷编号，缺陷标题，发现者，发现日期，所属模块，所属版本，指派给谁，缺陷状态，严重程度，优先级别，详细描述（所属模块，概述bug，预期结果，实际结果），复现步骤（附件，截图，日志）。

 #7.软件测试缺陷报告的 5C 原则

• Correct（准确）：每个组成部分的描述准确，不会引起误解；
• Clear（清晰）：每个组成部分的描述清晰，易于理解；
• Concise（简洁）：只包含必不可少的信息，不包括任何多余的内容；
• Complete（完整）：包含复现该缺陷的完整步骤和其他本质信息；
• Consistent（一致）：按照一致的格式书写全部缺陷报告。