测试用例:围绕着软件需求文档来进行设计测试用例

测试用例:本质上是一种集合，是为了实施测试而向被测试系统发出的一组集合，实施测试集合，这个集合的操作者设计者就是测试人员，这组集合的内容包括:测试环境，操作步骤，测试数据，预期结果等要素

1)包括测试产品(小红书）

2)所属模块(登录模块)

3)用例模型(功能测试)

4)测试环境:(测试的系统所在的设备环境以及版本，WEB系统到底在哪一个浏览器，这个系统到底是在windows系统(多少位)上面打开的还是在mac系统上面打开的)

5)测试平台(系统所在的设备)，测试步骤(对这个性能做了哪些操作，都点击了那些按钮)

6)测试数据，测试点(电话号码格式验证，验证码文本框验证)

7)还有预期结果(根据需求的出来的，根据iPhone来得出测试结果，根据android来得出测试结果)

8)标题，重要性，功能模块，优先级，是否手工，执行方式等，附件，测试用例写得好，就可以更好的保证软件的质量，用excel xmind 来写测试用例；

这里面的测试环境包括:硬件+版本，软件+版本

网易邮箱测试用例

1)标题:邮箱注册输入项测试

2)测试环境:Chrome 版本：90.0.4430.212 Windows11 64位 小米电脑

3)测试数据:邮箱地址，密码，手机号，验证码

6-18个字符，ljw-123456@139.com(工作的时候测试数据是给定好的）

4)测试步骤：

1）打开谷歌浏览器，输入链接，输入网易注册网址，进入到网易邮箱注册页面，输入网址，http://......

2）输入邮箱地址，输入符合需求密码和手机号码，获取验证码并输入密码

3）勾选用户协议，点击勾选同意，点击注册

5)预期结果:注册成功或者注册失败的最终页面，如果注册成功，我们使用账号可以进行正常的登陆

6)执行方式:手工

考验测试思路的整理，功能的测试点

1)同一个web页面在浏览器上面的不同版本展现的效果是不一样的)

2)64位和32位是不一样的，Java的可移植性是很好的，在64位机器上和32位机器上跑是没有什么区别的，但是C++语言64位机器和32为机器上面跑的结果可能是不一样的，因为C++的数据类型在不同系统上面的字节数可能是不同的

3)还要描述清楚版本

1.关于手机号码的测试格式验证:

1)输入11位数字且以1开头:输入成功

2)输入11位数字况且不以1进行开头

3)输入12位数字，10位数字或者是其他

4)输入以1开头的数字+其他字符(重点进行测试#和*)

5)输入其他无效字符

除了第一条之外，其他的点应该都是"请输入正确的电话号码"；

2.关于验证码文本框进行验证:

1)输入正确的验证码:输入成功

2)等待五分钟之后输入正确的验证码:验证码超时

3)输入验证码+字符组合:请输入有效的验证码

4)输入空格+验证码:输入成功

5)输入验证码+空格:输入成功

6)输入验证码中间加入空格:输入成功

为什么要进行设计测试用例？

1)复用性:避免用后即弃，在进行回归测试的时候不需要进行重新编写，解决重复测试

2)存在大量冗余测试影响测试效率，不知道哪一个测试了，哪一个没有测试，记录下来比较清晰

3)衡量测试需求的覆盖率，看看我们的测试用例是否覆盖了我们所有的需求

4)自动化测试的依据(手工测试转化成自动化测试)

5)方便其他人借鉴

开发模型: 

一:瀑布模型:瀑布模型的突出缺点是不适应用户需求的变化

start-需求分析-计划-设计-编码-测试-运行维护-end

特点:是线性的顺序的开发模式模型，是所有其他模型的基础框架，适用于需求固定的小项目，提供了一个很好的项目思维，上一步的结果才能作为下一步的理由，上一步完成下一步才可以开始

缺点:

1)风险往往要迟至后期的测试阶段才会暴露，因此失去了今早纠正的机会，甚至可能遗留给线上用户

2)测试被后置，不能够应对需求的变化(需求改变了还需要向前进行调整，从头再来一遍)

3)必须要预留给足够的时间给测试活动，否则会导致测试不充分，从而把缺陷直接遗留给用户了

4)可以进行运行的产品很迟才可以上线

补充:瀑布模型:适用于需求比较稳定的项目，因为他的每一个阶段都是独立的，一个阶段完成之后在下一个阶段才可以进行，一旦前面的需求发生错误，那么后面做的都是无效功或者说一旦需求发生变化，只能再下一次迭代中进行修改，不能适应需求的变化

1)软件生命周期是指从软件产品的设想开始到软件不再使用而结束的时间
2)瀑布模型在软件工程中带有重要地位，是所有模型的基础框架，瀑布模型的每一个阶段都只执行一次，因此是按照线性顺序进行的软件开发测试，对我们的前期需求分析看的比较重要

瀑布模型的过程:需求分析-计划-设计-编码-测试
3)优点:强调开发的阶段性，强调早期计划及需求调查(只能进行一次)，强调产品测试(在编码之后才会进行)，是串行的一个过程，况且测试是最后一个过程，如果说测试出现了问题，那么问题会直接暴露给用户;

缺点:依赖于早期的进行的唯一一次需求调查，是不能适应需求的变化的，它的每一个阶段比较独立，是单一流程，开发中的经验教训是不可以反馈应用于本产品的过程，编码后期才开始进行测试，需求分析，编码方式都没有进行测试，适用于需求稳定的项目，不适用于善于变化的项目，前期的风险往往迟致编码后期的测试阶段才暴露，往往会失去较早纠正的机会

分成计划，需求分析，概要设计，详细设计，编码，单元测试，运行维护在瀑布模型中，软件开发的各项活动严格按照线性方式进行，当前活动接受上一项活动的工作结果，实施完成所需的工作内容。当前活动的工作结果需要进行验证，如果验证通过，则该结果作为下一项活动的输入，继续进行下一项活动，否则返回修改。        

 二:螺旋模型:

特点:

1)我们的螺旋模型引入全流程的风险分析，每一次分析完成之后都会生成一个新的原型

需求分析------>计划------>设计-------->编码--------->测试--------->end在每一步都进行了风险评估

2)使用场景:适用于规模庞大，复杂度高，风险比较大的项目

3)缺点:做项目的时间拉长，况且风险分析能力和产品遗留的风险成反比，如果说想要找到风险能力比较强的人，那么时间会拉长，况且人力成本和资金成本都比较高

补充:

2)螺旋模型:进行多次迭代，多次风险分析， 螺旋模型支持用户需求的动态变化。

适用于项目比较庞大，项目不是很明确，复杂度高，采用渐进式的开发方式，并且有一定风险的项目，进行风险分析；耗资很大，如果风险比较大(后续用户比较少或者投资超出预期)，可以较快的叫停这个项目

1.优点:他不允许有一段独立的测试时间和阶段，测试不许反复迭代而迭代，回归测试在这里面非常重要，他强调严格的全过程风险管理，强调个开发阶段的质量，提供机会讨论该项目是否有价值继续延续下去(咱们的每一次迭代都有风险分析)
2.缺点：

2.1螺旋模型强调风险分析，但要求许多客户接受和相信这种分析，并做出相关反应是不容易的，因此，这种模型往往适应于内部的大规模软件开发。
2.2如果执行风险分析将大大影响项目的利润，那么进行风险分析毫无意义，因此，螺旋模型只适合于大规模软件项目。
2.3软件开发人员应该擅长寻找可能的风险，准确地分析风险，否则将会带来更大的风险 。
2.4引入非常严格的风险识别，风险分析和风险控制，这就对风险管理的技能水平提出了很高的要求，这就需要大量的人员，资金和时间的投入

（1） 制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件；

（2）风险分析：分析评估所选方案，考虑如何识别和消除风险；

（3） 实施工程：实施软件开发和验证；

（4） 客户评估：评价开发工作，提出修正建议，制定下一步计划。

三:增量和迭代模型: 

增量模型:

需求分析---->设计

1)增量1--->编码1---->测试2---->增量1发布

2)增量2---->编码2----->测试2---->增量2发布

3)增量3--->编码3----->测试3----->增量3发布

假设此时用户有一个需求，功能包含A，B，C---->A+B+C，咱们的螺旋模型和瀑布模型都是等到A，B，C三个功能开发完毕之后才会进行上线操作

但是我们此时的增量模型是:

开发完A我就直接上线供用户去使用

开发完C我就直接上线供用户去使用

开发完B我就直接上线供用户去使用

迭代模型:

先进行开发一个基础版本(包含功能A，B，C),但是A，B，C功能是很简陋的，接下来会继续对ABC功能进行优化

比如说要进行画画操作:

增量模型:先进行画头，在进行画身体，在进行画四肢

迭代模型:先画一个轮廓，在进行细化，再进行补色

增量与迭代模型

增量模型适用于需求比较明确，架构比较稳定的软件开发，每次增量不影响已有的架构，在已有的架构下增加新的功能。迭代模型适用于需求不甚明确、难度比较大的软件开发

项目需求：完成ABCD四个功能模块

下面：抗风险的能力较高

1)增量模型：第一周完成AB模块，第二周完成CD模块

2)迭代模型：第一周完成ABCD四个模块的基础功能，第二周完成ABCD模块的升级功能和细化

四:敏捷模型:

上面开发模型的每一个流程都是十分繁重的，每一步都是必不可少的

轻流程:想的是怎么能够激发大家的一个工作热情，强调人与人之间一个面对面高效的沟通，而不是每一个步骤都是按照固定的模型去走，只看最终的一个结果

1)开发方式(工作方式)不会做具体要求，非常适用于轻文档(时间很短，没有时间写各种各样的文档)，轻流程，重目标，重产出；周期短1-4周，团队人员少，注重人与人之间的交流(客户与研发团队的交流，产品经理和开发人员测试人员)，一定要在规定时间内交出高质量，可用性强的软件，拥抱需求变化

2)咱们的以前的开发模型--->需求分析有描述需求的文档，计划有计划文档，设计有设计文档，编码也是以文档形式来进行的，测试也是最后要进行编写测试报告，上面开发的每一步都有文档

3)敏捷开发拥抱需求变化

scrum流程:三个角色，五个会议

角色:

1)PO：客户的代表方，整理收集客户需求，编写需求文档，形成user story会形成product backlog，并对userStory进行排序，选出这一次迭代需要做的需求；

2)SM：项目经理，管理整个开发流程，保证敏捷开发流程的顺利实施，维护开发过程的一个运行，负责召开各种会议，协调项目，为研发人员来进行服务

3)ST：研发团队，由各种技术人员组成，开发测试人员，目标就是交付一个高质量可用软件

会议:

前置工作:产品经理和PO把一个个的用户需求整理好，整理user story形成product backlog(需求代办列表)；

一:产品发布会议：产品经理从需求池中选取几个需求，开展发布计划会议，进行讲解userstory，并进行估算和评估，发布计划会议的产出就是制作出这一期迭代要完成的story列表

二:迭代计划会议：项目经历确定任务的完成时间，细化需求，对需求进行拆解，划分成一个个小的任务，并进行讲解user story，确定任务多长时间完成，进行排序，分配开发人员，分配测试人员

三:开发过程中的每日站会：让开发人员开会每一天做了哪些事情，遇到了什么困难，测试开发人员对一天天工作总结以及新一天的计划，及时了解项目进度

四:产品演示会议：产品给boss进行演示，boss在此过程中会提各种各样的需求，还需要添加那些元素，客户会根据演示的结果提出一些修改意见；

然后项目经理会把这些意见添加到下一次要进行的产品的需求userstory，方便下次进行迭代，放到池子里面

五:回顾会议：回顾本次迭代产生的一些问题，总结，哪些地方做得好，哪些地方做得不好，以便会使以后的敏捷会议变得更加顺利；

举个例子:

前置工作:产品经理整理用户需求，把用户的需求放到需求池里面

1)现在在需求池里面，有三个需求:

A:我要五颜六色的黑

B:我想要永动机

C:我想要逛一下黑洞

1)产品发布会议:产品经理拿出一些需求，开始进行举行产品发布会议；

产品经理说:我现在有一些需求来需要大家来进行协助，拿出来的需求是A，B，C，产品经理来进行介绍需求内容是什么，要有哪些具体的功能来进行实现

2)迭代计划会议:产品经理来进行分工，就是A，B，C三个需求都分配给那些人来进行实现，进行划分负责人初步定位工时

唐三说我实现A只需要两天

桃夭说我实现B只需要两天

比比东说我实现C这个需求只需要1天

3)每日站会:

唐三说:我完成了红黑蓝，今天打算完成黑

桃夭说:我昨天只是造了个轮子，今天打算造车身

比比东说:我打算在黑洞里玩两天

最终做成了集成与五颜六色的黑，永动机，黑洞的为一体的神器

4)产品演示会议: 因为这个神器只有项目组的人会使用，对于用户来说并不会使用这个神器，有负责人来进行产品的演示，及时拿到用户需求

菊花关进行演示这个软件有什么功能，该怎么进行使用？

这个时候鲁班七号说你这个五颜六色的黑少了一个颜色，是灰色呀(用户需求)--->这个需求被放到需求池子里面

5)回顾会议:项目组的人都要进行参加

唐三说我的开发阶段过程中设计没有做好

桃夭说我的开发时间没有考虑好