2020-08-31

软件测试理论
●1.软件生命周期
●有三种生命周期（记住任意一种！）：
●1. 6个阶段：计划->需求分析->设计->编码->测试->运维
●2. 7个阶段：计划->需求分析->设计->编码->测试->运维-评价
●3. 8个阶段：问题定义->可行性分析->需求分析->概要设计->详细设计->编码和单元测试->系统测试->运维
●软件定义时期
●问题定义
●可行性分析 =（计划）
●考虑以下内容：
●1.开发的总目标；
●2.软件功能/性能/可靠性/接口等方面的设想；
●3.开发进度、投入成本、产出收益、所需资源等问题。
●输出结果为：立项
●软件开发时期
●需求分析
●产品经理（PRD）OR 需求工程师OR策划
●需求来源：市场调研（自主研发） 和用户 （客户定制）
●输出结果为：《需求规格说明书》=SRS
●概要设计
●设计是软件工程的核心，概要设计为HLD，把需求转化为具体可实现的架构。
●输出为：《概要设计说明书》
●详细设计
●详细设计是LLD，对具体实现的模块进行设计。
●输出为：《详细设计说明书》
●编码和单元测试
●使用不同的编程语言（JAVA、Python、C、C++、PHP等），实现软件具体功能。
●输出为：源代码
●系统测试
●测试软件是否符合需求，划分4个测试阶段：单元测试、集成测试、系统测试、验收测试。
●软件维护时期
●运行维护
●软件修复BUG、软件新增需求、软件优化性能、提升用户体验等情况所进行的更新和维护。
●（隐性，不希望）下线关闭
●2.开发模型（开发流程）
●瀑布模型
●就是生命周期模型，线性化，从上之下一次性执行。适用于需求明确的项目。（质量高、不支持需求变更）
●适用于：需求明确、二次开发的项目
●优点：自顶向下，顺序性通过，按阶段划分进行检查，软件质量较好。
●缺点：文档多，维护麻烦，缺乏灵活性，返回上一级开发代价大，不支持需求变更。
●

●原型模型
●也称为快速原型模型，在构建的基本框架之上进行二次开发。
●适用于：需求模糊、用户不清楚需求的项目
●优点：关注用户需求，减少需求不明确带来的开发风险。
●缺点：软件边做边改，可能质量低下，原型的开发语言不一定适应当前的开发环境。
●

●增量模型-渐增模型
●基于瀑布模型，增加了需求的变更迭代。
●适用于：需求不断变化的项目
●优点：人员分配灵活，可短时间内交付
●缺点：需开放式体系结构，后加入的构建不能破坏之前的结构。容易四不像。
●

●螺旋模型
●分为四个象限，加入了风险分析，保证软件质量及需求变更。（既支持需求变更也保证软件质量，但成本高）
●适用于：需求变化的大型且复杂的项目
●优点：1.制定计划 2.风险分析 3.实施工程 4.客户评估。 先设计评估再开发，并保证符合用户需求，提高开发效率和软件质量
●缺点：风险分析不到位时，项目风险较大。建设周期长，成本较高。
●

●敏捷开发模型
●以设计-开发-交付的方式，快速的迭代，输出高质量的软件。（时间短、周期快，频繁交付高质量软件）但是对技术人员要求高。
●适用于：所有项目
●优点：注重沟通，可及时响应需求变更，研发周期快，版本质量高、时间周期短。
●缺点：不注重文档的维护，对人员技术要求高，经验丰富，项目人员流动时，风险大。
●

●3.测试模型（测试流程）
●V模型
●内容： 需求分析—概要设计—详细设计—软件编码—单元测试—集成测试—系统测试—验收测试
●优点：自顶向下，顺序性对应，体现了设计与开发与测试之间的关系。
●缺点：把测试阶段置于开发之后的阶段，不利于尽早的发现BUG。
●

●W模型
●内容：需求分析—概要设计—详细设计—软件编码—单元测试—集成测试—系统测试—验收测试
● 需求测试—概要设计测试—详细设计测试— 集成 — 实施 —交付
●优点：尽可能早的执行测试，增加了针对前期文档的测试，发现前期阶段的问题。
●缺陷：不支持需求迭代，返回上一级代价高。
●

●X模型
●内容：单独的设计开发，频繁进行软件集成，再加上探索性测试。
●优点：支持需求不断变化，并且加入探索性测试，便于发现测试计划之外，更多的缺陷。
●

●H模型（敏捷测试的思想）
●强调软件测试活动是独立的！不依附任何流程，只要测试准备点就绪，就可开展测试。
●

●敏捷测试模型
●对测试人员要求高，重沟通表达（会议），对自动化测试有一定的要求，能独立负责测试流程（计划、方案、执行等）
●4.软件测试流程
●1.立项
●

●2.设计测试总计划，编写测试方案及测试用例
●

●3.单元测试阶段
●

●4.集成测试阶段
●

●5.系统测试阶段
●5.1功能测试
●

●5.2性能测试
●

●6.验收测试阶段
●

●7.运行维护
●5.在做项目时，工作流程如下：
●绿色表示为：会议 蓝色标识为：技术文档
●

●6.测试阶段
●单元测试
●概念：验证软件模块的源代码正确性。
●测试依据：《详细设计说明书》
●测试策略：白盒测试
●测试方法：语句覆盖/判定覆盖/条件覆盖/判定条件覆盖/路径覆盖
●测试人员：开发、研发自测
●集成测试
●概念：也称作：组装测试。验证软件模块之间的组装和调用，接口的测试。
●测试依据：《概要设计说明书》
●测试策略：灰盒测试
●测试方法：增式集成法（先1个模块的测，然后增加1个模块，N+1）、非增式集成法（先单独测试每个模块，然后直接组装测试）
●测试人员：测试工程师（接口和自动化测试）
●（确认测试）
●概念：验证集成的软件是否符合需求规格。
●测试依据：《需求规格说明书》
●测试策略：冒烟测试
●测试人员：测试工程师
●适用于软件各个阶段的每个版本。
●系统测试
●概念：验证软件本身及软件所运行的环境进行测试，包含功能测试、性能测试等。
●测试依据：《需求规格说明书》
●测试策略：黑盒测试
●测试方法：安装测试、配置测试、兼容性测试、界面测试、安全性测试、网络测试、异常测试、文档测试、备份测试等。（功能、性能测试方法+质量6大特性）
●测试人员：测试工程师
●验收测试
●概念：由客户方进行验收，抽查软件是否符合需求，验收通过则部署软件。
●测试依据：《需求规格说明书》+用户的实际需求
●测试策略：随机测试
●测试方法：alpha测试和beta测试
●alpha测试：又称实验室测试，内测，A测试。由测试人员和开发人员在场，受限的环境，邀请用户执行测试，并提交BUG。
●beta测试：又称为外场测试，公测，B测试。把软件直接放到网络环境中，未知的用户群体参与执行测试。
●测试人员：客户方，用户
●7.测试策略
●按照是否测试源代码角度：（重点+常用）
●黑盒测试
●白盒测试
●灰盒测试
●按照软件系统角度划分：（重点+常用）
●功能测试
●性能测试
●按照是否运行软件角度划分：
●静态测试
●动态测试
●按照是否使用工具角度划分：
●手动测试
●自动化测试
●按照测试活动角度划分：（重点+常用）
●冒烟测试
●全面测试
●回归测试
●随机测试
●8.测试用例
●根据测试方案中所设计的方法，编写项目的测试用例。
●编写用例的工具：禅道、CQ、TestLink。
●用例组成要素
●1.用例编号
●规则：项目名_测试阶段_模块名_子模块名_序号
●注意事项：由整体到局部，由大到小输出。使用英文或英文简写。
●2.测试项目（模块）
●指代：测试模块名或子模块名（测试子项）
●3.用例标题
●一句话概述测试点（测试步骤+预期结果）。
●建议输入方式为：测试点，预期结果。
●举例：当验证码超过60S时，注册失败。
●4.重要级别
●高、中、低
●可通过软件基本功能，或者使用频率来判定。
●回归测试时，会根据重要级别进行筛选用例。
●5.预置条件
●1.执行测试前，所需的测试环境。
●网络正常，测试样机A、B已到位。
●2.可预置其他用例，或者数据。
●如测试登录，可预置注册成功的用例。或者直接内置，已存在用户XX，密码XX。
●6.测试输入
●包含：输入的数据，文件、图片等。
●需构造具体输入的数据，如：用户名为：中国_1！
●7.操作步骤
●从主界面进入XX功能界面，再写到软件功能点。（路径）
●当前测试点，所必经的每一个步骤都单独输出。
●一个操作步骤，都对应一个预期结果。
●建议：先写如何进入XX模块的路径，在写XX模块的全部有效等价类覆盖。
●8.预期结果
●每个步骤应输出的结果为XX。给出结果，和后续的动作。
●举例：登录成功，跳转至网站首页。
●9.实测结果（执行测试时，很重要）
●PASS、FAIL、NG 也可写作：通过、未通过、阻塞
●10.测试人员（执行测试时，很重要）
●测试人员就是用例执行人员，不是写用例的人。任何人都可以执行写好的用例。
●11.测试日期（执行测试时，很重要）
●执行测试的当天日期
●12.用例作者
●用例编写人，需要负责所写用例的质量。
●13.创建日期
●写用例的日期时间
●14.修改日期
●维护用例的日期时间
●15.用例类型
●常见类型有：功能、性能、界面、安全、兼容性等等。
●16.是否自动化
●是否用于自动化。
●用例的分类
●1.可分为大粒度用例和小粒度用例
●大粒度用例，就是一条用例中，包含多种测试情况 。写出测试点，就输出测试结果。
●小粒度用例，就是一条用例中，只包含一种测试情况。写出详细操作步骤及结果。
●2.用例可分为：
●2.1 全功能用例库
●2.2 通用用例
●2.3 冒烟用例（筛选主要功能-高级别用例）
●2.4 专项用例
●用例设计方法
●等价类划分法
●概念：针对输入域，输入框进行设计，把无穷的测试划分为有限的测试。
●设计步骤：
●1.找到输入条件：如用户名、密码、确认密码等等
●2.划分等价类，划分有效等价类（符合需求的）和无效等价类（不符合需求的）；
●3.建立等价类表 （包含：输入条件、有效等价类、无效等价类）；
●4.给所有的等价类进行编号，编号是唯一的，目的是为了组合覆盖；
●5.进行组合覆盖等价类，覆盖原则：
●尽可能多的覆盖所有的有效等价类，（所有有效的先写为一条，再进行单个覆盖、两两组合覆盖、三三组合覆盖…）
●有且只覆盖一个无效等价类（每种错误情况，各自写一条无效的用例）
●6.构造测试输入，测试数据，转化为正式的测试用例。（包含：用例标题、操作步骤、预期结果…）
●边界值分析法
●概念：针对边界情况，进行划分，发现错误的能力最强，也最容易出错。也是等价类划分的补充。
●包含：软件的长度边界、内容边界、大小边界、高低边界、上下左右前后、温度、容量等等。
●一般边界值：（长度的有效类）5个值。（3个值）
●取值：最小值、最小值+1、中间值、最大值-1、最大值
●举例：用户名长度为：5-10，密码长度为10-20
●公式：4N+1 （N代表有几个条件）
●最坏情况所有用例的覆盖总数为：5^N次方
●健壮性边界值：（加上长度的两个无效等价类）7个值。（5个值，4个值）
●取值：最小值-1、最小值、最小值+1、中间值、最大值-1、最大值、最大值+1
●公式：6N+1 （N代表有几个条件）
●最坏情况所有用例的覆盖总数为：7^N次方
●补充：常用边界值取值为，健壮性取5个值：越界两个值、边界两个值、中间值。（最小值-1、最小值、中间值、最大值、最大值+1）
●等价类+边界值结合设计用例
●等价边界表=输入条件+有效等价类+一般边界值+无效等价类+健壮性边界值
●覆盖所有的有效等价类，及单个覆盖每条无效等价类。
●设计步骤：
●1.（先使用等价类划分法）找出所有的输入条件；
●2.针对每个条件，分别划分有效等价类和无效等价类；
●3.建立等价类表，把等价类进行唯一的编号；
●4.（再使用边界值分析法）找出等价类中，所有的边界（长度边界）；
●5.在等价类表中，插入2列：一般边界值（在有效等价类旁）和健壮性边界值（无效等价类旁）的列；
●6.写出所有的长度边界并编号，一般边界值：最小值、中间值、最大值；健壮性边界值：最小值-1、最大值+1；
●7.（等价类+边界值组合覆盖）先覆盖所有条件的有效等价类，写一条成功的用例。
●8.在覆盖单个条件的有效等价类，（有效等价类=长度类和内容类）
●测试长度时，默认内容是有效的。测试内容时，默认长度是中间值。
●先覆盖单个的长度
●（如：用户名为1位时，注册成功 测试输入，用户名为：Q）
●用户名为2位时，注册成功 测试输入，用户名为：哈
●用户名为14位时，注册成功 测试输入，用户名为：wyeiuwqyeuaewpz
●用户名为7位中文时，注册成功 测试输入，用户名为：等价类可厉害了
●再覆盖单个的内容，
●用户名为纯英文时，注册成功 测试输入，用户名为：HelloWord
●纯中文、纯下划线、
●内容两两组合；
●用户名为：中英文、中文+数字、中文+下划线、英文+数字、英文+下划线。。。。。。
●内容三三组合：
●用户名为：中英数、中英_、英数_。。。。。。。
●然后写出单个条件的所有无效等价类
●写下一个输入条件的，有效和无效等价类，操作步骤如上
●最后，可补充健壮性等价类
●验证【任意】两个输入条件无效【为空、错误】的情况；
●验证三个输入条件无效的情况；
●验证四个输入条件无效的情况；
●验证所有输入条件无效的情况。
●状态迁移法
●又称：流程测试，功能图法
●设计步骤：
●1.根据功能图，找出所有的状态；
●2.写出单个状态，局部的测试用例；
●3.使用xmind或其他工具，构造条件状态树；
●4.覆盖每一条初始到结束的路径；
●5.转化为具体的测试用例。
●备注：最多只覆盖两个循环。
●场景法
●设计步骤：
●1.找出场景的基本流和所有的备选流【相当于，测试用例标题=测试点】；
●2.根据基本流和备选流，写出所需满足的条件（每个条件分别触发V、I 的情况）【添加必要的条件】
●3.根据写出的场景，往条件中赋值，V（满足/有效）、I（不满足/无效）、NA（挂起/不考虑）
●4.根据场景表，写出用例编号、测试结果；
●5.使用测试数据替换V、I的值；
●6.把场景表转化成正式的一条条的测试用例。
●备注： 备选流中，只有一个 I 条件，【每个条件均可设置为一次I，作为备选输出】
●错误推测法（补充用例）
●基于经验和直觉进行补充
●基于项目经验和发现过的BUG进行补充
●用例设计方法，选取策略【体现在测试方案中！】
●1.必须使用“边界值分析法”，发现错误的能力最强！
●2.针对输入框并且是客户端的操作，优先考虑“等价类划分法”，把无穷的测试，划分有限的不同类型的测试覆盖。
●3.建议使用等价类+边界值进行组合覆盖，尽可能多的覆盖所有的测试情况，保证测试覆盖率，并提高测试效率。
●4.针对有功能图的需求，优先考虑“状态迁移法”，按照功能图提取状态，然后输出局部的测试用例，覆盖初始到结束的路径。
●5.针对业务场景，也是所有软件都适用，需验证使用场景的。优先考虑“场景法”，找出基本流和备选流，覆盖所有的测试情况。
●6.建议使用状态迁移法+场景法进行组合覆盖，考虑所有的有效路径和各种备选场景。
●7.随时使用“错误推测法”，基于项目经验和直觉和已发现的bug，进行测试用例的补充。关注测试覆盖率，避免漏测。
●9.缺陷报告
●1.缺陷定义：
●1.未实现需求规格说明书指明要实现的功能；（显性需求）
●2.未实现需求规格说明书虽未指出但应实现的功能；（隐性需求）
●3.超出需求规格说明书指明的范围；（超出需求范围）
●4.出现了指明不会出现的错误。
●5.用户体验认为不好的，使用不佳的，不易操作的，运行缓慢的问题
●2.如何识别缺陷
●通过需求规格说明书
●通过与测试用例中的预期结果对比
●同行业成熟的商业产品
●与有经验的测试工程师沟通
●与开发人员沟通
●参考同行业的隐性需求
●3.缺陷的组成：
●包含：缺陷编号、缺陷标题、操作步骤（步骤、预期结果、实际结果、备注）、严重程度、优先级、缺陷类型、影响版本号、附件（截图、视频、日志）
●缺陷编号：1～+∞，顺序排列
●缺陷标题：一句话概述，在XX模块，做了XX操作，出现XX问题。（概率性要写出来）
●缺陷模块：软件的功能模块
●问题描述：操作步骤+预期结果+实测结果+备注 （概率性的问题，在备注中，要写出测试多少次，出现多少次）
●严重程度：致命、严重、一般、较小、改进建议
●优先级： 立即解决、高优先级、正常排队、低优先级
●缺陷状态：新建、打开、修复、拒绝、激活、延期、重复、关闭
●缺陷概率：必现、偶现、不可复现   OR 10%～100%
●软件版本：VXXXX
●操作系统：WinXP、Win7、Win8、Win10
●浏览器  ：firefox、chrome、IE、opera、safari
●指派人  ：开发
●提交人  ：测试
●提交时间：当前日期
●修改时间：XXXX年XX月XX日 XX:XX:XX
●4.缺陷的生命周期：
●简单周期：发现-打开-修复-关闭
●复杂周期：发现-打开-拒绝-激活-修复-关闭
●发现-打开-修复-复现-修复-关闭
●发现-打开-延期-修复-关闭
●5.缺陷跟踪处理流程
●A、测试人员获取新版本，执行测试；
●B、发现缺陷，在缺陷管理工具提交BUG；
●C、开发人员修复缺陷；
●D、针对不宜修复、无法修复的问题，TOCCB（专家会诊）确定如何解决；
●E、开发check in并提交代码到代码服务器；
●F、bulid人员合并代码，编译新版本，上传至SVN服务器；
●G、测试人员在SVN服务器获取新版本，开启新一轮测试。
●6.缺陷跟踪的目的
●6.1 跟踪缺陷状态，直至修复关闭
●6.2 进行缺陷分析、进行软件度量
●7.缺陷管理工具
●缺陷工具：禅道、QC、TD、Bugfree、Jira
●免费开源：Bugfree 、禅道免费版、Bugzero
●付费软件：TD、CQ、Jira、禅道专业版
●10.需求规格
●输出：SRS需求规格说明书（技术文档） 、游戏行业称为：策划案
●需求=获取用户的需要 = 转化成技术可实现的功能 = 需提取的功能模块！
●需求的定义包含：产品功能+行业标准规范。 输出技术文档为：需求规格说明书、各行业规范。
●需求的分层：金字塔模型
●用户需求：顶级需求。
●系统特性：软件技术功能+性能特性。
●系统需求：硬件，软件开发技术及架构。
●需求的变化：
●合理的变化： 用户需求不明确导致的，市场技术竞争导致的。
●不合理的变化：需求文档质量差、需求在技术和管理上不规范。
●需求变化的原因：需求获取不准确、遗漏需求、低效的需求分析。
●需求规格说明书的类型
●包含：业务需求、用户需求、系统需求、功能需求、非功能性需求、行业规范限制、质量特性要求等。
●业务需求：市场前景文件或项目轮廓图，确定要做什么类型的项目，面向什么样的市场。
●用户需求：进行市场调研或根据客户方要求，收集用户对软件的具体要求有哪些。（收集用户需求，并筛选有用的，去掉无用的需求）
●系统需求：包含软件需求和软硬件结合的需求。需考虑当今的软件技术和硬件是否能实现用户需求。若技术原因无法实现，则去掉该用户需求。
●功能需求：在满足系统需求的情况下，所有需实现的用户需求，被确定为必须实现的功能需求。若未实现功能需求，则是bug。
●非功能性需求：除功能之外的需求，常见为性能需求，可靠性，安全性需求等。也称为软件应满足的其他特性。
●行规：不同类型的软件产品，需满足各个行业的标准规范，法律法规，合同要求。如：入网规范、信息安全、加密认证、3C认证。
●质量特性：软件的整体质量如何，对需求的吻合程度。
●需求工程
●需求两大过程域
●需求开发过程
●1.需求获取
●2.需求分析
●3.需求定义
●4.需求验证
●需求管理过程
●1.需求实现
●2.需求跟踪
●3.需求变更控制
●11.软件质量
●质量要关注：内部质量、外部质量、使用质量
●质量的6大特性： 功能性、可靠性、易用性、效率、维护性、可移植性。
●质量管理体系：ISO国标、CMM能力成熟度模型、CMMI能力成熟度模型的集成。
●测试部门的质量目标： 项目版本进度按时完成 +资源使用情况+ 缺陷检出率 。
●测试项目的质量目标： 测试覆盖率 + BUG评估
●12测试计划
●13.测试方案
●14.测试报告
●15.软件测试方法
●分为功能测试方法和性能测试方法
●功能测试方法：安装测试、卸载测试、升级测试、配置测试、兼容性测试、易用性测试、界面测试、安全性测试、异常测试、备份测试、文档测试、网络测试
●性能测试方法：压力测试、负载测试、容量测试、稳定性测试、并发测试等
●安装测试：
●应包含：安装测试、卸载测试、升级测试！要考虑正常及异常情况。
●安装测试：
●1.安装前测试：测试软件安装包，包含软件本身和说明文档等。
●2.安装中测试：安装成功、及安装失败的情况，不同的安装方法和路径测试。
●3.安装后测试：验证软件安装成功，生成桌面图标，并可成功运行。安装后卸载、卸载后重装、重复安装、软件升级等。
●常见的安装方式：顺序性安装、自定义安装、一键安装、完全安装、部分安装、必选项安装、第三方安装、绿色版软件 C/S
●A/S 手机自带应用市场下载并安装【授权】、第三方应用市场下载并安装、下载apk至手机点击安装、电脑端连手机下载并安装、更多考虑异常安装内存空间满时安装、无权限时安装、。。
●Web端后台的考虑：部署软件包至服务器的安装、在服务器端的升级、
●常见的升级方式：
●软件自动更新、软件手动更新【跨版本更新、卸载后重安装】、第三方软件更新。
●卸载测试：
●卸载的几种方式、完全卸载和保留数据卸载、卸载后重装
●升级/更新测试：
●强制更新版本OR 非强制更新，自动更新、手动更新，跨版本进行更新
●配置测试：
●包含：服务器的软硬件配置、客户端的软硬件配置、软件的系统参数配置（最低配置和初始化参数）
●服务器软硬件配置：所选服务端软件的最低版本，硬件所需的最低配置。公司现有的配置，直接使用。服务器的硬件、web服务器、数据库服务器的选择。
●客户端软硬件配合：最低硬件配置、操作系统、浏览器、屏幕分辨率、颜色色彩等配置。（如android5.0以上，最低支持的就是5.0版本）
●软件系统参数配置：软件设置的参数默认值。
●兼容性测试：
●包含：软件兼容性、硬件兼容性、浏览器兼容性、网络兼容性、数据兼容性等
●软件兼容性：操作系统win、linux、OS X，移动端android、ios的所有待验证版本。
●硬件兼容性：不同厂家的电脑品牌，不同公司的手机品牌等
●浏览器兼容性：基于浏览器不同的内核，重点验证：IE、Google、firefox、opera、360/UC等
●网络兼容性：有线网（不同带宽8M/20M/100M）、无线网（加密/不加密、2.4G/5.8G）、移动网络（2G/3G/4G/5G）
●数据兼容性：软件版本向前兼容，向后兼容。
●易用性测试：
●菜单级数<3级；导航栏；快捷键的组合使用。操作简便。
●UI界面测试：
●界面的展示和功能的实现。界面层，接口层，功能层。
●导航测试、图形测试、内容测试
●界面元素外观（大小、形状、色彩、文字属性等）、
●界面元素布局（位置、对齐方式、间隔、Tab顺序）、
●界面元素行为（缺省值、输入限制/提醒、操作路径等）
●安全性测试：
●包含：系统安全性、数据安全性、网络安全性、权限、产品本身的安全性质量等
●重点考虑：权限！=软件权限+角色权限
●异常测试：
●也称为容错性测试，健壮性测试。
●需要人为构造异常，断电、断网、崩溃死机、服务器机。
●备份测试：
●分为自动备份、手动备份、
●考虑备份数据格式、备份是否成功、导入导出功能
●结合异常测试一起测试。当异常时，是否自动备份。
●手动备份，考虑：备份的文件，导回数据的正确性。
●文档测试：
●文档的规范性和实用性
●文档是否模糊遗漏
●可使用工具进行检阅：格式、中英文等
●面向的用户群体：技术人员或客户方用户等
●当前文档面向技术人员，则使用专业术语。尽量避免口语化描述。
●当前文档面向用户手册，则使用通俗易懂的语言，尽量避免使用技术用语。
●禁忌：不允许出现源代码！
●网络测试：
●网络通信方式：有线网、无线网、移动网络
●网络协议：tcp、udp、协议实现一致性
●考虑：正常网络、异常网络、弱网、无网的情况。
●总结：
●1.安装测试【安装、卸载、升级=XX测试前、XX测试中、XX测试后】、
●2.配置测试【软硬件最低配置、软件设置的参数配置、服务器端现有的配置、客户端硬件、系统、浏览器、分辨率、颜色】、
●3.兼容性测试【操作系统兼容、硬件兼容、数据兼容、浏览器兼容、版本向前向后兼容】
●4.可用性测试【菜单级数小于3级、快捷键的使用、导航栏=过于复杂的、或过于简单的、不能理解的】又称易用性测试
●5.安全性测试【数据安全、系统安全、软件本身的安全性、网络安全=重点关注权限分配、绕过鉴权、是否检测、拦截、处理】
●6.界面测试【界面与设计的实现、界面与功能的实现=界面层、界面与功能的接口层、功能层】又称GUI测试，图形化界面测试
●界面元素：最小的不可拆分的界面原子、组成界面组合元素的菜单条、构成完整的界面窗口对话框。
●界面的外观、界面的布局、界面的行为
●7.异常测试【人工干预制造断电、断网、崩溃、死机、丢失等异常情况，验证软件的自动恢复与人工干预恢复】又称容错性、可恢复性测试
●8.备份测试【自动备份、手动备份、备份后的数据格式、备份数据与原数据是否一致、恢复还原后的数据是否正确】
●9.文档测试【操作说明、协议、帮助手册、说明书=也包含技术文档（SRS、LLD、HLD、测试计划、方案、报告）的测试】
●10.网络测试【有线网、无线网、弱网、无网络 = BS、CS、AS= 协议 = 软件与协议实现的一致性、规范标准】
●
●软测岗位：
●测试员、软件测试实习生：不考虑
●软件测试工程师：【技术】
●1.根据测试计划，搭建所需的测试环境。
●2.根据测试方案，编写部分测试用例。
●3.执行测试用例，执行测试，提交BUG。
●4.输出测试日报，汇报测试情况。
●5.根据需要编写测试报告。
●软件测试设计人员：【技术】
●1.根据需求规格说明书，进行需求分析，提取测试需求；
●2.设计测试，选择所需的测试技术、测试策略、测试方法、测试用例设计方法；
●3.编写测试方案，并跟进完成情况及质量
●4.设计测试脚本，选择所需的语言、框架及结构。
●软件测试开发人员：【技术】
●1.编写自动化脚本
●2.编写所需的测试工具
●3.编写所需的测试框架等
●软件测试组长：【管理】
●1.根据项目计划，制定软件版本的测试计划；
●2.分配测试任务，跟踪测试进度及协调资源。
●3.对测试的结果负责，保质保量完成测试任务。
●软件测试经理：【管理】
●1.负责部门的组建及维护，制定测试部工作流程及考核制度
●2.定制团队组织架构及相关技术构成，
●3.制定项目的测试总计划，并对质量负责。