为什么要软件测试？

为什么要软件测试？

• 软件的非正常运行或其自身的缺陷（BUG）会引发很多问题
• 软件是由代码和文档组成的，而这些都是由“人”来设计和编写的，人都有可能犯错
• 环境也会影响软件，以致出现软件“失效”现象
• 软件测试活动只是关键的质量保证活动之一，但不是唯一把控质量标准的手段
  

什么是软件测试？

• 验证软件的正确性
• 尽早发现软件中的缺陷，使公司的成本尽可能降到最低，在需求阶段介入成本才是最低的
• 测试是为了证明程序有错
• 一个好的测试用例，能发现之前没有发现过的bug
• 一个好的测试人员，具备发现之前没有发现过的bug的能力
  

软件生命周期的概念？

• 软件生命周期的别称：软件生存周期或软件开发生命周期
• 指的是软件从产生到报废的整个过程，是一种时间的概念
• 例如：一个手机的正常使用到报废
  

通常软件生命周期包括哪些阶段？

1.客户问题引入或定义（客户要求的功能点，上线的时间，达成的目的）
2.可行性分析（涉及经济(商业论证)、政治、法律、技术等）
①成本和盈利
②政治风险
③法律因素（设计黄赌毒）
④技术问题，主要是看当前项目组的技术水平，是否能实现客户的要求
3.项目招投标（主要是哪个公司要的钱少）
4.项目立项（组建项目组）
①成立项目组
②人力安排
③采购服务器，办公用品之类的设施
5.需求分析（产品经理输出需求文档，进一步细化客户的需求，比如采用什么样的形式实现客户的需求）
6.开发阶段（设计、编码、测试）
①项目经理
②产品经理
③开发经理
a.开发人员：写代码
b.前端开发、后端开发
c.UI设计师：输出效果图
④测试经理
a.测试人员：对开发出来的软件进行测试，保证交付的产品的质量
7.维护阶段（运维人员：处理客户问题或者上线的问题）
8.停服（下架不在提供相关服务）

典型的软件生命周期模型有哪些？

• 瀑布模型
  

1.顺序流程：系统需求（system requirements）→软件需求（software requirements）→分析（analysis）→程序设计（program design）→编码（coding）→测试（testing）→运行（run）
2.优点：每一个工作节点都比较清晰，工作的先后顺序比较分明
3.缺点：工作流程比较固化，比较难以应对频繁变更需求的项目，在每个阶段的工作，标准不明确

• V模型
  

   
顺序流程：
    用户需求               ←            验收测试(UAT)
        ↘                                                            ↗
        需求分析           ←          系统测试(ST)
             ↘                                             ↗
            概要设计       ←      集成测试(IT)
                  ↘                             ↗
                详细设计   ←   单元测试(UT)
                                          ↘          ↗
                                          编码和实现
1.用户需求阶段：产品经理对接客户
2.需求分析阶段：产品经理去引入客户的需求，将客户的需求进行提炼，召开需求澄清会议，又叫需求评审（经过多次讨论输出一个基线化的文档，也叫需求文档，也叫需求规格说明书)，需求澄清会议是产品经理召开，开发和测试同时参会）
3.概要设计：又叫HLD，就是把项目中需要实现的功能区域，划分为A模块、B模块，概要设计一般是开发做，输出概要设计文档
4.详细设计：又叫LLD，把概要设计中区分好的模块，针对每个模块的功能点怎样实现，做出详细的规定，输出详细设计文档
5.编码和实现：又叫coding阶段，开发人员编写代码，然后将编写好的代码进行打包（rar,war,jar）
6.单元测试：简称UT，又叫白盒测试，主要是开发对于代码的语法和逻辑进行的测试，代码走查
7.集成测试：简称IT，又叫灰盒测试，也称为API接口测试，主要是保证模块单独的测试没有问题，和模块的交互功能正常
8.系统测试：简称ST，又叫黑盒测试，也称为功能测试，主要是关注软件的功能是否正常，系统与系统之间的交互是否正常，包括第三方系统的交互
9.验收测试：简称UAT测试
①α测试：公司内部的人员进行模拟用户的操作进行验收，发现缺陷的话，此时开发人员对内部缺陷进行修改
②β测试：产品交付到客户的手中，客户参与验收进行测试，有客户进行问题收集，以邮件的形式统一交给项目组，由项目组来修改
                           输入                          输出
用户需求              用户提出的需求                需求文档（出版）   
需求分析              需求文档（出版）              需求规格说明书（SRS）
概要设计              需求规格说明书（SRS）         概要设计文档（HLD）
详细设计              概要设计文档（HLD）           详细设计文档（LLD）
编码实现              详细设计文档（LLD）           代码包
单元测试              代码包                        单元测试报告
集成测试              单元测试报告                  集成测试报告
系统测试              集成测试报告                  系统测试报告
验收测试              系统测试报告                  验收测试报告

• W模型
• H模型
  

   
SRS澄清会议：需求评审会议，产品经理召开，参会人员：开发、测试、产品
review：审阅、评审
TPM（测试经理）：负责输出测试计划和测试方案（规定的测试范围，人力安排，时间节点安排，风险分析(时间上的风险，组内有新人加入要重点关注一下新人负责的模块，可能会有漏测或者效率不高的情况)）
1.项目组中有哪些评审会议？
①需求评审：产品经理召开，参会人员（开发、测试、产品），在需求评审中，一般测试人员主要项目中的异常场景的处理和开发进行确认和约定，并保持对需求文档的理解跟开发和产品是一致的
②用例评审：测试人员召开，参会人员（开发、测试、产品），在用例评审中，测试人员主讲，主要是看我们测试组编写的测试用例的覆盖度和测试方法以及测试策略是否正确，还要对测试用例的预期结果跟开发保持一致，避免后续返工以及因为缺陷的问题与开发有争执
③交叉评审：测试组内同事之间进行评审，一般没有产品参与
④组内评审：项目组的开发、测试、UI设计师、产品一起评审
⑤会议评审：有客户参与的评审会议
testlink:是一款用例管理工具，相似的平台有禅道等
2.TPM搭建测试环境，项目组中有哪些环境？
①开发环境：开发人员进行编码和代码调试的环境，又叫dev环境
②测试环境：测试人员进行测试活动的环境，sit环境
③准生产环境/预发布环境：模拟用户的场景，产品经理进行验收的环境，这里的代码跟将要上线的代码是一样的，uat环境
④生产环境/线上环境/正式环境：真实的客户使用的环境
3.环境搭建好以后，开发人员进行代码打包，由TPM或者测试骨干或者运维部署项目包，项目包一般部署在Linux系统上
4.冒烟测试：在集成测试和系统测试之前进行，一般选择一些主线的流程/主体功能进行测试，主要是看主体功能是否能够跑的通，冒烟测试不通过，直接打回给开发人员进行修复，修复完成以后继续冒烟测试，直到冒烟测试通过才可以进行接下来的测试
5.sit1：又称为全量测试，就是把所有的案例全部都执行一边，有bug的话要协助定位bug
6.sit2：又称为回归测试，主要是针对第一轮出现bug的案例和有可能会影响到的案例进行重复执行，重点复测，防止开发在修复bug的时候引发新的bug
①第一轮出现缺陷的案例
②可能会影响到的模块
③增量案例（在测试过程中增加的案例）
④冒烟测试
7.测试准出的标准：
①需求中规定的功能，全部得以实现
②所有的案例全部都执行通过
③发现的缺陷，要全部修复，或者可以遗留1-2个建议性的缺陷，不影响功能的使用和客户体验
8.项目、产品、版本之间有什么关系？
答：先有项目，后有产品，一个产品可以有多个不同的版本
9.项目上线：
①上线前：测试人员进行交叉测试或者随机测试
②上线中：测试人员整理当前版本输出的文档，进行归档（需求文档、测试计划、测试大纲、测试用例）
③上线后：测试人员在正式环境环境中进行线上验证（所有的测试活动都要按照用户的操作来进行，测试环境中出现过bug的模块进行验证）
10.测试报告：
①测试范围
②不测试范围
③bug list：又bug列表，主要是每一轮测试测出来有哪些bug，bug的修复情况，产生的原因分析
④风险分析
a：遗留缺陷的影响
b：新人负责的模块，有可能漏测
⑤本次迭代业务总结
a：业务上的总结，比如加入了优惠券的功能
b：工作方法的总结，比如工作中遇到了哪些阻塞性的问题，占用太长时间，以后怎么规避
11.如果发版以后出现了很严重的bug，导致项目崩溃，一时间难以修复，怎么办？
答：回滚，也叫版本回退

• 敏捷开发模型和迭代开发模型
  

①周期短，1-2周就一个版本
②轻量级，每个版本的任务量不大
③晨会，15-20分钟（昨天预计做什么，实际做了什么，有哪些差异，产生差异的原因今天预计做什么，做多少，预计进度如何，有没有发现风险）

• 增量开发模型
  

1.比较适合复杂且周期比较长的项目，可以将项目进行独立的功能划分，分多个版本上线
2.可以避免前期公司投入太多的人力物力，降低风险

测试的基本原则有哪些？
1.测试不仅仅是软件本身的测试
①了解项目的背景和目的
②考虑外在的环境因素对项目的影响--》弱网
2.测试应该尽早介入
①需求评审的时候介入，对需求更为透彻的理解，为后面的编写测试用例打下基础
②降低项目延期的风险
③测试介入的越早，问题修复的成本就越低
3.二八原则
80%的缺陷会集中在20%的区域内--》开发修复缺陷的过程中很有可能引发新的bug
4.杀虫剂效应
在测试过程中，发现案例存在遗漏，或者案例的回归已经发现不了新的bug了
解决方法：做案例增量

测试活动的生命周期
1.测试计划
2.测试分析与设计：主要是做一些测试大纲类和测试用例的文件
3.测试的执行：根据测试用例进行测试活动
4.测试报告的输出
5.测试资产：需求文档、测试计划、测试大纲、测试用例、测试报告，业务上的知识沉淀文档