软件测试知识概括_stage环境

软件测试基础

什么是软件：

• 软件是计算机程序、程序所用的数据以及有关文档资料的集合。
• 软件是计算机的灵魂。软件又可以分为两大类:系统软件和应用软件。
• 系统软件:系统软件是生成、准备和执行其他程序所需要的一组文件和程序。如操作系统Windows，数据库SQL-Server,驱动程序(网卡，声卡)，java语言系统编译环境等。
• 应用软件:计算机用户为了解决某些具体问题而购买、开发或研制的各种程序或软件包。如APP. QQ，微信等。

软件的生命周期：

• 软件生命周期(SDLC，Systems Development Life Cycle)是软件开始研制到最终被废弃不用所经历的各个阶段。—软件开发模型

软件开发模型：

• 瀑布型生命周期模型：
  ①在1970年人类整理了第一个软件生命周期，即瀑布型生命周期模型也叫瀑布模型。规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落，具有顺序性和依赖性。每个阶段规定文档并需进行评审。
  <1>测试介入项目特别晚:回溯成本非常高--好
  <2>项目周期很长
  

• V模型：
  ①RAD (Rap Application Development，快速应用开发）模型是软件开发过程中的一个重要模型，由于其模型构图形似字母V，所以又称软件开发的V模型。它通过开发和测试同时进行的方式来缩短开发周期，提高开发效率。
  <1>测试介入早，可以提前对需求进行评审和测试--回溯成本减少
  <2>测试提前在测试文档(用例)----可以直接执行测试===节省准备文档时间--提高项目效率。周期拉短

• 敏捷开发模型：
  ①从1990年代开始逐渐引起广泛关注，是一种以人为核心、快速迭代、循序渐进的开发方法。强调以人为本，专注于交付对客户有价值的软件。是一个用于开发和维持复杂产品的框架。就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
  <1>微信:文字聊天，语音聊天，视频聊天，朋友圈，红包，小程序，零钱通，公众号(需求)=== 3年
  <2>第一次迭代版本:文字聊天，语音聊天=== 3个月–上线，用户量，占领
  <3>第二次迭代:视频聊天，朋友圈==2个月 --用户量，吸引新用户
  <4>第三次迭代:红包，小程序，零钱通=3个月
  <5>…
  <6>产品不选的重复–完善，丰富
  ②项目周期多久?迭代周期多久?(1个月，2周，1周)
  ③敏捷开发模型特点：
  <1>弱化文档。
  <2>强调人之间沟通：站会–站着开会：10分钟：今天的任务，昨天问题，协调处理。

软件开发过程：

• 一、问题的定义及规划：
  ①主要确定软件的开发目的及其可行性。制定项目总体开发计划。
• 二、需求分析：
  ①在确定软件开发可行的情况下，对软件需要实现的各个功能进行详细分析,明确客户的需求(需求评审–产品，开发，测试)，输出需求规格说明书终版(原型图)。
• 三、设计：
  ①把需求分析得到的结果转换为软件结构和数据结构，形成系统架构。
  ②概要设计:主要是架构的实现，指搭建架构、表述各模块功能、模块接口连接和数据传递的实现等项事务。
  ③详细设计:对概要设计中表述的各模块进行深入分析等，其中需要包含数据库设计说明。
• 四、编码：
  ①按照详细设计好的模块功能表，编程人员编写出计算机可运行的程序代码
  
• 五、软件测试
  ①软件设计完成后要经过严密的测试，以发现软件在整个设计过程中存在的问题并加以纠正，测试的方法主要有白盒测试跟黑盒测试两种。建立详细的测试计划并严格按照计划进行。
  <1>单元测试：主要是测试程序代码，为的是确保各单元模块被正确的编译，比如有具体到模块具体到类，函数、方法的测试等。
  <2>集成测试:单元测试后，将各单元组合成完整的体系，测试软件单位之间的接口是否正确、数据能否正常传递。---接口测试
  <3>系统测试:把软件系统搭建起来，按照软件规格说明书中所要求，测试软件其性能功能等是否和用户需求相符合，在系统中运行是否存在漏洞等。----最重要，常见的(web，APP)
  <4>验收测试:主要就是用户在拿到软件的时候，在使用现场，会根据前边所提到的需求，以及规格说明书来做相应测试，以确定软件达到符合效果的。---UAT(用户，产品（领导) )
  <5>α(阿尔法)(alpha)测试：封闭式内测，由开发公司发放一定数量的激活码或账号给玩家。
  <6>β(贝塔)(beta)测试：开放式内测，不限数量，全民参与。
  
• 六、运行维护：
  ①软件维护是软件生命周期中持续时间最长的阶段。在软件开发完成并投入使用后，由于多方面的原因，软件不能继续适应用户的需求。要延续软件的使用寿命，就必须对软件进行维护。软件的维护主要包括纠错性维护和改进性维护两个方面。
  ①纠错性：bug修复，修改代码—新版本
  ②改进性：优化，完善，改良—新版本(需求–立项–需求分析)

一个软件产品从开发到用户使用都涉及哪些环境？

• 1、开发环境(dev)：
  ①顾名思义，开发同学开发时使用的环境，每位开发同学在自己的dev分支上干活，提测前或者开发到一定程度，各位同学会合并代码，进行联调。
• 2、测试环境(test/System Integration Test (sit))：
  ①也就是我们测试同学干活的环境啦，一般会由测试同学自己来部署，然后在此环境进行测试。bug修复后，需要发版更新测试环境来回归bug。
• 3、回归环境：
  ①回归bug的环境，其实就是我们的测试环境，在测试环境上测试、回归验证bug。
• 4、预发布环境(stage)：
  ①测试环境到生产环境的过渡。测试环境可能会受到一些限制，一些流程或者数据没有测试到，就可以在预发布环境进行验证，从而保证产品上线质量。
  ②预发布环境和生产环境区别：
  <1>预发环境中新功能为最新代码，其他功能代码和生产环境一致。
  <2>预发环境和生产环境的访问域名不同。
  ③注意事项：
  <1>预发布环境一般会连接生产环境的数据库，测试时要注意，以免产生脏数据，影响生产环境的使用。
• 5、生产环境(produce)：
  ①即线上环境，用户使用的环境。由特定人员来维护，一般人没有权限去修改。
  ②另外，还有个灰度发布，发生在预发布环境之后，生产环境之前。
  <1>生产环境一般会部署在多台机器上，以防某台机器出现故障，这样其他机器可以继续运行，不影响用户使用。灰度发布会发布到其中的几台机器上，验证新功能是否正常。如果失败，只需回滚这几台机器即可。

灰度发布版本和灰度环境：

• 预发布环境过后，就是灰度发布了。由于一个项目，一般会部署到多台机器，所以灰度1台至3台，看看新功能是否ok，如果失败则只需要回滚几台，比较方便。注意，由于是灰度发布几种几台，所以一般会使用跳板机，然后进行域名绑定，这样才可以保证只访问有最新代码的服务器。
• 灰度发布也叫金丝雀发布，起源是，矿井工人发现，金丝雀对瓦斯气体很敏感，矿工会在下井之前，先放一只金丝雀到井中，如果金丝雀不叫了，就代表瓦斯浓度高。
  ①在灰度发布开始后，先启动一个新版本应用，但是并不直接将流量切过来，而是测试人员对新版本进行线上测试，启动的这个新版本应用，就是我们的金丝雀。如果没有问题，那么可以将少量的用户流量导入到新版本上，然后再对新版本做运行状态观察，收集各种运行时数据，如果此时对新旧版本做各种数据对比，就是所谓的A/B测试。
  ②当确认新版本运行良好后，再逐步将更多的流量导入到新版本上，在此期间，还可以不断地调整新旧两个版本的运行的服务器副本数量，以使得新版本能够承受越来越大的流量压力。直到将100%的流量都切换到新版本上，最后关闭剩下的老版本服务，完成灰度发布。
  ③如果在灰度发布过程中（灰度期）发现了新版本有问题，就应该立即将流量切回老版本上，这样，就会将负面影响控制在最小范围内。
  ④链接：什么是灰度发布?
• 灰度环境：也可称为线上仿真环境或者预发布环境，在上线之前发布到灰度环境，通过后再上线，其实灰度环境的好处挺多的，其中最明显的就是观察用户反馈，即时调整产品的方向，避免因为直接上线导致用户一时半会儿适应不了新系统，导致用户流失。此外还有助于降低上线的成本，如人力成本（一般大版本上线是深更半夜，开发比较疲惫）、降低bug数量等，如果发现灰度环境的问题，可以及时把用户剔除灰度名单，尽可能减少用户的损失
  ①链接：灰度环境搭建笔记

预发布环境和灰度环境：

• 预发布环境：
  ①只是一台服务器
  ②没有真实的流量
  ③连线上数据库
• 灰度环境(pre)：
  ①1台或集群
  ②线上数据库
  ③真实流量

总结：

• 链接：各环境开发流程
• local：自己的开发分支
• dev：前后端联调分支
• test：测试分支
• 复制一份test的镜像：压测
• pre/beta：灰度分支，连接生产数据库，对接生产流量，也可以叫公测。
• stage：预发布分支，连接生产数据库，不对接生产流量。
• produce/master：生产分支。

分支解释：

• master 主分支： 对应正式环境的代码。
• develop分支：近期要发布和测试的代码分支，对应 开发分支。
• fixbug分支：要发补丁的代码分支，对应bug分支。
• release分支：本周要发布的代码分支，对应发布分支。

应用软件架构C/S与B/S架构：

• c/S: client-server:这种就是我们一定要安装一个客户端才能够用的软件，就叫C/S
  ①缺点:每次更新，都需要更新服务端与客户端，比如说超市收银系统每次更新每台电脑都必须重装客户端，特别是有分店的情况。人力物力财力都很大。–重启业务中断
• B/S: browser-server:只需要一个浏览器，就可以访问服务的，就是B/S.
  ①优点:只需要更新服务器就OK,不需要去更新浏览器。用户主动性比较高。比如说天猫、淘宝。

软件测试是什么：

• 软件测试的定义: 使用人工和自动手段来运行或测试某个系统的过程，其目的在于检验它是否满足规定的需求戎弄清预期结果与实际结果之间的差别。
• 问题:使用QQ的过程,是软件测试么? 答案：不是。
• 我们为什么要做软件测试，它的目的什么?
  ①软件测试为了发现程序(软件)存在的代码或业务逻辑错误
  ②软件测试为了检验产品是否符合用户需求
  ③软件测试为了提高用户的体验

软件测试的分类：

• 按测试技术划分：
  ①黑盒测试：
  <1>产品-黑色盒子–代码实现
  <2>输入输出—数据驱动的测试
  <3>点点点
  ②白盒测试：
  <1>产品—透明盒子—代码逻辑，会代码
  <2>不是测试做的，开发自测----代码审查
  <3>单元测试
  ③灰盒测试：
  <1>大概知道代码逻辑实现,不需要着懂所有的代码
  <2>接口测试
• 被测试对象是否运行划分：
  ①动态测试：程序是运行的
  ②静态测试(文档检查、代码走查)：程序不运行
• 按不同的测试手段划分：
  ①手工测试：(点工)
  ②自动化测试：(代码+工具)
• 按测试包含的内容划分：
  ①功能测试：测试业务逻辑(手工，自动化)—核心重要
  ②界面测试：Ul (user interface)–外观美观，设计合理，友好—主观性强=需求文档
  ③安全测试：高级类型—攻击(工具(扫描–appscan)，代码(脚本–ql注入)）—漏洞，薄弱=账号密码，http协议–https协议
  ④兼容性测试：软件＋硬件(windows, Linux ，MAcOS,Android,iOS);软件+软件(浏览器兼容)…调用;软件不同版本之间=APP升级(老功能，数据)
  ⑤易用性测试：主观—人性化，舒适，用户使用习惯，用户体验—提bug=站在用户角度考虑，参考成熟产品
  ⑥性能测试：高级类型—双十一(访问人数多)–并发（10000)—资源,CPU，内存–正常处理(压力测试，稳定性、负载测试)
• 按测试阶段划分：
  ①单元测试
  ②集成测试
  ③系统测试
  ④验收测试
  ⑤α测试
  ⑥β测试
• 其他测试：
  ①回归测试：regression test :测试 — bug，开发修复bug(修改代码)=验证bug =其他没被修改的代码模块的测试，影响:上线之前-很多轮(2-4轮)的回归测试(重复)–策略=自动化测试实现
  ②冒烟测试：来源—硬件测试:电路板–通电–冒烟–短路被烧了=打回开发重做…软件测试:软件提测–核心业务功能，主流/程-打回开发
  ③探索性测试/自由测试(测试思维)：发散测试–能力要求非常高:依据，方法=靠经验，积累，直觉----

软件测试详解

软件测试工作流程图：

• 软件测试基本流程：
  ①测试需求分析阶段：阅读需求，理解需求，主要就是对业务的学习，分析需求点。参与需求评审会议。
  ②测试计划阶段：编写测试计划，参考软件需求规格说明书、项目总体计划，内容包括测试范围(来自需求文档)、进度的安排，人力物力的分配，整体测试策略的制定，和风险的评估与规避措施有一个制定，一般有测试负责人编写，当然我们可能也会参与相关的评审工作。
  ③测试设计阶段：主要任务是编写测试用例，会参考需求文档(原型图)、概要设计、详细设计等文档，有不明确的也会及时和开发、产品经理沟通。用例编写完成后会进行评审。
  ④测试执行阶段：首先搭建测试环境,执行预测(冒烟)，以判定当前版本可测与否，如果预测通过，正式进入系统测试(2-4轮)，遇到问题提交Bug到缺陷管理平台，并对bug进行跟踪，直到被测软件达到测试需求要求，没有重大bug，测试结束。------(完善测试用例)
  ⑤测试评估阶段：出测试报告，对整个测试的过程和版本质量做一个详细的评估(剩余bug数量/严重程度，测试用例的覆盖率)。确认是否可以上线。
  ⑥UAT测试阶段：部署到UAT测试环境，由产品或者领导来验证功能。

测试需求：

• 测试需求是什么?
  ①测试需求主要解决“测什么”的问题，一般来自需求规格说明书中原始需求
  ②测试需求应全部覆盖已定义的业务流程，以及功能和非功能方面的需求–性能，安全、兼容易用、界面–6个方面
• 为什么需要软件测试需求?
  ①简而言之:只有明确了测试需求，才能知道怎么去测试?什么时候开始测试?要多少人测试?在什么环境上测试?----提炼测试点，时间规划，人力规划，测试环境

案例分享：

• 测试点思路步骤如下：正常+异常
  ①正常功能:是否可以正常提交–注册成功–单个功能冒烟测试
  ②单个功能项验证(正常+异常)：规则:按顺序从上至下，对每一个输入项进行验证
  <1>数据长度、数据类型验证、必填项验证、重复
  <2>限制约束验证
  <3>隐形需求:充分熟悉产品业务，挖掘隐性需求
  ③功能交互验证：模块之间传递的信息和数据。对存在功能交互的功能项
  ④非功能性测试：界面，易用性，兼容性