1.软件测试-----软件测试的基本概念
目录
一、软件测试的基本概念
1.什么是软件测试？
2.软件测试和软件开发的区别？
3.什么是需求？
4.什么是BUG？
5.如何描述一个BUG?
6.BUG的级别？
7.BUG的生命周期？
8.软件测试的生命周期？
8.1需求阶段
8.2测试计划
8.3测试设计、测试开发
8.4测试执行
8.5测试评估
9.五个开发模型
9.1瀑布模型
9.2螺旋模型
9.3.增量模型、迭代模型
9.4敏捷模型
10.测试模型
10.1V模型
10.2W模型
一、软件测试的基本概念
1.什么是软件测试？
软件测试是使用人工或自动的手段来运行或测定某个软件系统的过程，其目的在于检验它是否满足了用户的需求。
软件测试贯穿了软件开发的生命周期。
2.软件测试和软件开发的区别？
软件测试和软件开发都是软件生命周期的重要组成部分，测试和开发有着一对一的关系，测试的工作是对开发成果的检验。
测试是由开发人员和测试人员共同完成的。
3.什么是需求？
用户期望和满足文档、规则、标准等规定所需要的条件和权限。
用户需求一般比较粗略，那么此时需要软件需求来把用户需求进行细化和规范，把用户的需求变成一个可实现化的过程文档。
需求是软件测试的依据。
验证需求，保证需求正确可实现、细化需求，从需求中提炼出一个个的测试项。
4.什么是BUG？
当且仅当，程序规格说明书(软件需求)存在并且合理，如果软件功能和软件规格说明书不相符合，那么就说是软件错误；
当软件需求不存在，用户需求存在并且合理，软件功能和用户功能不相符合，那么就是软件错误。
5.如何描述一个BUG?
（1）测试版本：出现问题的版本号。
（2）测试环境：分为硬件环境和软件环境，如果是web项目，需要描述浏览器版本，客户机操作系统等，如果是app项目，需 要描述机型、分辨率、操作系统版本等。详细的环境描述有利于故障的定位。
对于web系统，MAC、Windows操作系统，不同的浏览器：谷歌、Edge、火狐、搜狗、QQ、Safari、360、猎豹等。
对于APP：软件环境：IOS系统、安卓系统、鸿蒙系统、塞班、Windows系统；硬件环境：不同的手机品牌，不同的手机系列等。
（3）测试步骤：测试数据和执行测试的详细步骤，描述问题重现的最短步骤。为了方便开发人员复现问题。
（4）实际结果：实际出现错误的情况。
（5）预期结果：需求期望的结果。
（6）bug产生时的log日志，错误截图等。
6.BUG的级别？
（1）崩溃Blocker
系统崩溃，不能运行，死循环，数据库死锁，资源分配不均衡，黑屏，闪退，阻塞，此时可以回归上一个可用并且稳定的历史版本。
（2）严重Critical
服务器可以使用，但是不稳定，继续使用会产生严重的错误；比如以及菜单错误，数据库插入用户数据错误，威胁到用户的安全等。
（3）一般Major
系统可以稳定的运行，次要的功能没有实现，提示语言不完善，弹出框没有关闭按钮，不影响用户的使用。
（4）次要Minor
提示信息重叠，界面排版不符合用户使用习惯，颜色不符合软件的使用场景。
7.BUG的生命周期？
测试人员应该跟踪一个Bug的整个生命周期，从Open到Closed的所有状态。
- New:新发现的Bug，未经评审决定是否指派给开发人员进行修改。
- Open：确认是Bug，并且认为需要进行修改，指派给相应的开发人员。
- Fixed:开发人员进行修改后标识成修改状态，有待测试人员的回归测试验证。
- Rejected：如果认为不是Bug，则拒绝修改。
- Delay:如果认为暂时不需要修改或暂时不能修改，则延后修改。
- Closed：修改状态的Bug经测试人员的回归测斌验证通过，则关闭Bug。
- Reopen：如果经验证Bug仍然存在，则需要重新打开Bug，开发人员重新修改。
无效的bug：open->closed open-rejected-closed
问题1：发现一个BUG，开发人员修改完成后，测试人员又复现了这个BUG，可能是哪些原因引起的错误？
（1）测试环境不一致
（2）开发人员理解不到位，没有修改成功
（3）开发人员修改完成后的代码没有提交成功，测试人员还是使用之前存在BUG的代码进行测试
问题2：测试人员因为一个BUG和开发人员产生冲突，该怎么办？
（1）检查自己的BUG描述，是否存在描述不清楚的情况，确保开发人员明白Bug描述的意思
（2）可以从用户的角度考虑，说服开发人员；比如：需求要求可以上传图片作为头像，但是没有定义格式。开发人员在上传时限制为只能传png格式的。 站在用户角度考虑一下：png，jpg那种格式更多？是否要用户自己进行格式转换再上传？
（3）BUG定级要有理有据，符合公司的规范
（4）测试人员需要不断提升自己的专业技能和业务水平
（5）寻找产品经理来讨论问题的解决方案
8.软件测试的生命周期？
需求分析→测试计划→ 测试设计、测试开发→ 测试执行→ 测试评估
8.1需求阶段
分析需求，验证需求的正确性和合理性，细化需求，根据需求来提炼测试点
8.2测试计划
确定测试范围，测试的目标，测试人员，测试工具，测试时间和测试环境
8.3测试设计、测试开发
开发测试用例
8.4测试执行
开发人员已经提交代码，执行测试，提交bug
8.5测试评估
对本次迭代的测试情况进行分析和总结，写了多少测试用例，执行了多少，发现多少bug，剩余bug的解决方案，测试的覆盖率
9.五个开发模型
9.1瀑布模型
瀑布模型（Waterfall Model） 是一个项目开发架构，开发过程是通过设计一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，每个阶段都会产生循环反馈，因此，如果有信息未被覆盖或者发现了问题，那么最好 “返回”上一个阶段并进行适当的修改，项目开发进程从一个阶段“流动”到下一个阶段。
瀑布模型核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。
特点：阶段性强，每个阶段比较独立；看重前期的需求分析和后期的测试。
缺点：测试在编码后才开始介入，如果后期发现问题，补救起来比较困难。
9.2螺旋模型
螺旋模型是一种演化软件开发过程模型，它兼顾了快速原型的迭代的特征以及瀑布模型的系统化与严格监控。螺旋模型最大的特点在于引入了其他模型不具备的风险分析，使软件在无法排除重大风险时有机会停止，以减小损失。同时，在每个迭代阶段构建原型是螺旋模型用以减小风险的途径。螺旋模型更适合大型的昂贵的系统级的软件应用。
特点：适合于在软件开发初期阶段需求不是很明确,项目庞大，前期风险大的项目，强调每一个迭代的测试质量和风险分析。
缺点：风险管控人力物力投入较大，成本比较大。
9.3.增量模型、迭代模型
使用4周时间开发同一个系统的A模块，B模块，C模块，D模块
增量模型：第一周完成A模块；第二周完成B模块；第三周完成C模块；第四周完成D模块；
迭代模型：第一周完成A B C D四个模块的基础功能；第二周完成基础功能的开发和测试；第三周进一步开发复杂的功能；第四周完善细节；层次迭代
特点：抗击风险能力较强。
9.4敏捷模型
-注重和客户的沟通，整个研发团队有效沟通，注重产品质量，注重产品规定的交付日期。
-敏捷开发周期很短（2-4周时间），团队人员5-7个人
Scrum流程：
发布计划会议：产品经理需求整理成userstory，找到本次迭代需要进行开发的userstory形成product backlog；
迭代计划会议：分析用户故事，将userstory分解成为一个个的任务，分配开发人员，制定开发计划；
每日站会：昨天完成了什么内容？遇到了什么问题？今天的计划是什么；
产品展示会议：给客户和Boss演示产品研发的成果，PO把不足的地方收集成userstory，下一次迭代改进；
回顾计划会议：回顾整个迭代过程，总结这个迭代的优缺点，不足的改进，优化迭代流程；
角色：
PO（product owner）产品经理：负责整理用户需求，形成userstory。
SM（scrum Master）项目经理，负责保证整个敏捷开发流程的顺利实施，开发，和各种协调等。
ST（scrum team）研发团队，负责整个项目的研发，各种技能的人组成，测试，开发，UI设计师等。
特点：轻文档、轻流程、重目标、重产出。
10.测试模型
10.1V模型
V模型最早是由Paul Rook在２０世纪８０年代后期提出的，目的是改进软件开发的效率和效果。是瀑布模型的变种。
- 明确的标注了测过程中存在的不同类型的测试，并且清楚的描述了这些测试阶段和开发过程期间各阶段的对应关系。
- V模型指出，单元和集成测试应检测程序的执行是否满足软件设计的要求；系统测试应检测系统功能、性能的质量特性是否达到系统要求的指标；验收测试确定软件的实现是否满足用户需要或合同的要求
- 局限性:仅仅把测试作为在编码之后的一个阶段，未在需求阶段就进入测试
特点：每一个阶段独立性较强，左边每一个阶段是右边测试阶段的依据
缺点：编码后才进行测试，前期的错误到后期才会被发现，修改错误成本变大
10.2W模型
W模型增加了软件各开发阶段中应同步进行的验证和确认活动。W模型由两个V字型模型组成，分别代表测试V与开发V
- W模型特点：测试的对象不仅是程序，需求、设计等同样要测试，测试与开发是同步进行的
- W模型优点：有利于尽早地全面的发现问题。例如，需求分析完成后，测试人员就应该参与到对需求的验证和 确认活动中，以尽早地找出缺陷所在。同时，对需求的测试也有利于及时了解项目难度和测试风险，及早制 定应对措施，显著减少总体测试时间，加快项目进度。
- 局限性：需求、设计、编码等活动被视为串行的；测试和开发活动也保持着一种线性的前后关系，上一阶段 完全结束，才可正式开始下一个阶段工作。无法支持敏捷开发模式。对于当前软件开发复杂多变的情况，W模 型并不能解除测试管理面临着困惑。
特点：每一个阶段独立性较强，测试一开始就会介入，测试和开发是并行的。
缺点：每一个阶段都是串行的过程，一个阶段完了就会进行下一个阶段。