软件测试基础篇(3)

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

测试用例:是为了实施测试而向被测试系统发出的一组集合，这组集合包括测试标题，测试环境，操作步骤，测试数据预期结果等要素；

错误:是为了实施测试而向被测试系统发出的一个测试用例；

软件生命周期是指从软件产品的设想开始到软件不再使用而结束的时间

测试环境:硬件+版本+软件+版本

1)包括测试产品:小红书；

2)所属模块:登录模块；

3)用例模型:功能测试;

4)测试环境

5)测试平台(系统所在的设备)

6)测试步骤(对这个性能做了哪些操作，都点击了那些按钮)

7)测试数据

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

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

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

知道预期结果才可以知道执行测试用例之后才知道程序是否出现了BUG；

为什么要进行设计测试用例？参考软件需求文档设计测试用例

1)复用性:避免用后即弃，在进行回归测试的时候不需要进行重新编写，解决重复测试问题，比如说版本迭代的时候，软件要对老版本的历史功能也是需要进行测试的，所以说之前的测试用例拿出来直接用，比如说测试人员提出了bug，开发人员对bug进行修复完毕以后，针对于bug来做回归验证和版本迭代，对于新版本的历史功能也是需要进行测试的

2)存在大量冗余测试影响测试效率，不知道哪一个测试了，哪一个没有测试，记录下来比较清晰，前面的某一个测试用例我已经执行过了，但是后来我又忘了有没有测，很影响测试的执行，因为历史的功能比较多，所以要使用自动化测试；

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

4)自动化测试的依据:测试用例是手工测试转化成自动化测试；

5)方便其他人借鉴；

测试用例为什么要指明测试版本？

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)输入验证码中间加入空格:输入成功

开发模型: 

一:瀑布模型:

最基础的一个模型，瀑布模型的突出缺点是不适应用户需求的变化

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

1)特点:

1)每一个阶段只执行一次，是线性的顺序的开发模式模型，是所有其他模型的基础框架，适用于需求固定的小项目，提供了一个很好的项目思维，上一步的结果才能作为下一步的依据，上一部分工作完成下一部分工作才可以开始，提供了一个很好的线性基础；

需求分析之后才可以进行计划，计划完成之后才可以进行设计，设计完成之后才可以进行编码，编码完成之后才可以进行测试；

2)不能适用于需求的变化，需求发生变化，从头再来；

3)瀑布模型的每一个阶段都只执行一次，因此是按照线性顺序进行的软件开发测试，对我们的前期需求分析看的比较重要，分成计划，需求分析，概要设计，详细设计，编码，单元测试，运行维护在瀑布模型中，软件开发的各项活动严格按照线性方式进行，当前活动接受上一项活动的工作结果，实施完成所需的工作内容，当前活动的工作结果需要进行验证，如果验证通过，则该结果作为下一项活动的输入，继续进行下一项活动，否则返回修改；        

2)缺点:

2.1)测试被后置，风险往往要推迟至后期的测试阶段才会暴露，因此失去了今早纠正的机会，还需要向前回溯，向前返工，交付产品周期拉长；

比如说需求分析的结果可能不太正确，然后错误一步一步地放大直到测试阶段才发现问题，

比如说测试的过程中发现了问题，测试人员肯定是现在编码过程中发现了问题，但是还是要从编码过程中向前进行回溯，再来到设计阶段，再向前不断进行回溯

2.2)开发人员编码之后测试人员才可以进行看需求，编写测试用例，所以要预留出足够的时间来编写测试用例，但是有时候项目周期比较短，测试时间不够，测试质量不够，测试不充分，缺陷最终暴露给线上的用户，最终导致可以进行运行的产品很迟才可以上线；

2.3)瀑布模型的突出缺点是不适应用户需求的变化；

3)优点:

3.1)瀑布模型在软件工程中带有重要地位，是所有模型的基础框架，其他模型都是瀑布模型的优化，是线性的顺序的开发模式模型，提供了一个很好的项目思维，上一步的结果才能作为下一步的理由，上一步完成下一步才可以开始

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

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

4)适用于:

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

要预留足够的时间给测试，比如说如果测试被耽搁导致项目不能及时的上线，不能按时的交付一个可交付的产品，那么就会导致别的公司的项目提前发布并且抢占市场，失去了市场；

使用场景:适用于需求固定的小项目，不用报需求变化

 二:螺旋模型:在瀑布模型的基础上引入全流程的风险分析，适用于规格较大，复杂度比较高的项目

 

为什么要生成新的原型:生成新的原型作为后续版本的跟进，既然在瀑布模型中的每一步都会有风险，那么就专门请一个人来管理协助每一个流程的把关，减少尽可能少的一个返工

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

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

三:增量和迭代模型:某一个分支和瀑布模型差不多

假设此时用户有一个需求，功能包含A，B，C

项目完整的模块:A+B+C

1)螺旋模型和瀑布模型都是等到A，B，C三个功能开发完毕之后才会进行上线操作

2)此时的增量模型是:

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

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

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

优点:产品可以进行迅速的发布，线上用户可以进行快速的使用，在较短时间内交付一个可需要的产品；

四)增量与迭代模型

一)增量模型适用于需求比较明确，架构比较稳定的软件开发，每次增量不影响已有的架构，在已有的架构下增加新的功能

二)迭代模型适用于需求不甚明确、难度比较大的软件开发，先上线一个基础版本；

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

下面：抗风险的能力较高

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

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

五:敏捷模型:重于和用户的沟通

之前的模型任务是非常繁重的，每一步的任务都是必不可少的，而不是每一步都按部就班，每一步都是按照固定的流程来走；

拥抱需求变化:响应变化重于遵循计划，就是用户在某一段时间内可能要使用到什么功能，用户提出了需求，可能过了一段时间以后，用户发现我不想要再换一个功能

1)开发方式工作方式不会做具体要求，非常适用于轻文档，时间很短，没有时间写各种各样的文档)，轻流程，重目标，重产出，重沟通，拥抱需求变化；周期短1-4周，团队人员少，注重人与人之间的交流，客户与研发团队的交流，产品经理和开发人员测试人员，一定要在规定时间内交出高质量，可用性强的软件，拥抱需求变化，不管在实际开发中遇到了什么困难，最终是要一个可交付的软件，测试人员最后也要测试记录以及缺陷管理，以及编写测试用例以及测试报告；

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

敏捷开发的一个开发模型，scrum流程:三个角色，五个会议

PO:将用户需求转化成软件需求文档

SM:推动项目执行的一个人

product backlog:是一个需求池，专门放没有实现的用户的需求，也叫做需求待办列表

每日站会:时间长度高达2-4个周

1)昨天干了什么

2)今天要干什么

通过这两个问题要知道项目进度是什么？如果说当前的项目进度比较慢和项目风险，就需要采取一定的措施来解决项目延迟风险的一个问题，避免后期产品交付的时候出现了一些问题

3)说说自己遇到了什么问题，希望项目组内成员大家一起想想办法，提出自己的想法和解决方案，能不能针对这个问题做出合理的解决，防止问题到最后才暴露出来，

4)还有需求池里面的需求是供应不断的呀，产品经历在不断的收集需求，一方面也表现出来敏捷模型是能够及时地捕捉用户的需求，捕捉我们产品的变化，为了让产品功能更符合用户的需求，一直是精益求精的过程；

举个例子来理解敏捷开发模型:

为什么说敏捷模型可以支持需求的一个变化，就是因为每次一个项目周期在可交付的一个软件后面都会进行演示会议，通过演示会议能够及时拿到用户的需求，因为此时用户提出了意见，并且用户期望功能是什么样子的，并进行需求的一个优化迭代，这样软件才能及时满足用户的需求，及时把用户需求进行总结，放到需求池子里面；

产品经历在产品发布会议里面从product backlog里面选择一些需求

迭代计划会议:比比东来负责黑洞的开发，桃夭负责永动机的开发，唐三负责五颜六色的黑的开发

回顾会议:整个项目执行过程中哪些做得好，哪些做得不好，不断地进行精益求精

唐三说我在设计五颜六色的黑的过程中在开发阶段我的设计没有做好，下次一定改正；

桃夭说我的开发时间没有考虑好，时间太紧张了，要好好的合理的考虑一下开发周期；

有的时候开发人员喜欢让产品经理提需求，然后开发人员才协助产品经理