软件测试流程与软件测试缺陷

 制定完整且具体的软件测试路线和流程，可以为快速、高效和高质量的软件测试提供基础流程框架，并且是个不断完善需求的过程。

一、软件测试在项目中的流程图

二、测试需求分析

    测试需求分析最主要的问题是“测什么”，也可以说怎么找“需求点”，一般这个是要根据产品给出的需求文档来进行思考。测试需求是整个测试过程的基础，确定测试对象以及测试工作的范围和作用，而且被确定的测试需求项必须是可核实的。即，它们必须有一个可观察、可评测的结果。

 A、为什么需要测试需求分析：

测试需求是整个测试过程的基础，确定测试对象以及测试工作的范围和时间；

获取测试点，有针对性的设计测试用例；

有助于保证测试的质量和进度；

软件测试需求是衡量测试覆盖率的重要指标；

B、测试需求分析的步骤：

根据对需求文档的理解，列出需求文档中的具有可测性的原始需求；

对每一条需求进行细化分解，形成可测试的测试点；

对形成的每一个测试点，根据软件产品的整体功能和质量，确定测试执行时需要实施的测试方法；

C、需求分析对开发和测试的影响；

    对于开发来说：

由于了解需求不明确，功能研发不合格导致很多BUG；

对于BUG反复修改，影响进度和团队情绪；

进度影响，很可能使公司产品失去市场先机；

    对于测试来说：

与开发是相互制约的关系，如果不了解需求，会大部分时间都被开发牵着鼻子走；

不能及时发现开发的偏差，影响进度和团队情绪；

没办法保证测试质量；

三、设计编写测试计划

什么是测试计划

      测试计划是一个文档，描述了进行测试的测试范围，测试策略和方法，测试资源和进度。是对整个测试活动进行的一个宏观的规划，确定了测试项目，测试任务，谁来执行任务，被测试特性，不被测试特性以及过程中可能存在的风险等。测试计划能够有效的预防计划的风险，保证了测试活动能够在计划范围内顺利的开展。

测试计划的目的

①制定一个可行性的计划，包括测试对象，测试范围，测试方法和策略，测试进度和预期结果；

②确定测试角色和职责；

③测试时间和资源，保证可行性和有效性；

④确定测试阶段完成或者成功的标准，实现的目标；

⑤识别风险，消除可能存在的风险；

 测试计划内容

        ①测试范围：明确需要测试哪些模块、明确本次测试做哪些测试。如：系统测试：在整个系统测试中会有（界面测试、功能测试、性能测试、兼容性测试、安装卸载测试、可靠性测试等测试）；

       ②测试标准：需要考虑本次测试需要输入哪些分档，需要准备的测试环境和测试数据、对bug的级别定义，优先级定义，这些要在执行测试之前明确；

       ③人力和时间分配：根据现有的测试团队成员针对整理的测试点分配测试任务；

       ④测试风险：测试风险包括项目开发延期、测试人员不足用例无法全面覆盖测试点、时间不足测试用例无法全部执行、bug无法及时修改导致无法验证、测试人员技能不足导致测试进度拉长等，这些风险必须在测试计划中写清楚；

       ⑤测试环境：根据产品需求规定的测试内容来搭建测试环境；

四、设计编写测试用例

    测试用例是指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标，测试环境，输入数据，测试步骤，预期结果，测试脚本等并形成文档。是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。 通俗的讲：就是把我们测试系统的操作步骤按照一定的格式用文字描述出来。

    一般运用的黑盒测试用例设计方法包括等价类划分法、边界值分析法、错误推测法、因果图法、判定表驱动法、征集哦啊试验设计法、功能图法、场景图法等。

    测试人员根据需求功能点编写测试用例，通过评审并且开发提测后就可以执行测试了。

五、执行测试

开发完成开发并提测，此时我们就可以打版本测试了。拿到版本我们首先搭建测试环境做冒烟测试，目的是来判断这个版本是不是课测试的，如果冒烟测试不通过，打回给开发反工，如果测试通过，这时就可以开始我们第一轮系统测试。

第一轮系统测试我们会执行编写的所有测试用例，做好测试结果的记录，发现bug并及时提交bug给对应开发人员进行修改，做好bug的管理。

在他们修复bug期间，根据第一轮测试情况，对我们的测试用例进行修改和增加，开发修改bug结束，会提交新的版本给我们，此时进行第二轮测试，首先回归我们提交的bug，然后会在测试用例中挑选一些优先级别较高的测试用例来进行测试，发现问题提交缺陷，知道bug率为0，我们就接近最后一轮回归测试了。

最后等开发修改的bug数为0，进行最终的回归测试，并且关闭所有相关bug，确定上线。

六、缺陷管理

1、什么是Bug？

　　一只虫子爬进主机引起短路的这个事件（不知道的可以咨询百度），让我们知道了软件缺陷被称为“Bug”的原因，而我也一直以为缺陷就是bug。

2、那缺陷又是什么呢？

　　还是看上面的这个例子，真正的缺陷是计算机维护工程师提出来的那个问题：在主机的散热孔那里可以加装一层更加细密的金属网，既不影响散热，又可以防止虫子爬到主机里。这是计算机设计人员疏忽的地方，是产品真正的缺陷。而虫子引发的那个故障只是这个缺陷导致的故障的其中一种表现形式。也就是说，Bug是缺陷的一种表现形式，而一个缺陷是可以引起多种Bug的。

　　所以缺陷和bug是一对多的关系，弄清楚这层关系了接下来我们就来看看缺陷报告。

　　缺陷报告是测试人员日常工作中的一部分，每天都要进行，有时可能一天要报上三四十个，因此缺陷报告的质量就显得特别重要，直接关系到缺陷修正的速度、开发人员的效率。

3、缺陷报告的描述

　　一份有效的缺陷报告要素通常包括：标题、前提、测试环境、操作步骤、实际结果、期望结果、出现的频率、优先级、严重等级。

       ●标题：简明扼要，无歧义

　   ●优先级 Priority（4个等级）：软件被修复的紧急程度

　　1--立即解决：缺陷导致系统几乎不能运行使用 或 严重妨碍测试的执行（需立即修改）；

　　2--高优先级：缺陷严重，影响到测试了（当天或第二天要及时解决的）；

　　3--正常：一般错误；

　　4--低优先级：可以在开发有时间的时候处理，如页面文本框对齐显示；

　　●严重等级 Severity（4个等级）：缺陷引起的故障对用户使用系统的影响

　　1--致命的：主流程不通，导致系统功能缺失、用户数据被破坏、系统崩溃、死机；

　　2--严重的：影响流程的 比较严重的，比如系统主要功能部分未实现；

　　3--一般：系统的次要功能没有完全实现，但不影响用户的正常使用；

　　4--较小：操作不方便或遇到麻烦，但不影响功能的使用，如字体不美观、按钮大小不合适、文字排列对齐等（属于建议性或者美观方面的）；

　　一般来说，缺陷越严重，优先级越高，但也有例外：

　　1）从用户角度看，缺陷不是很严重，但可能影响到测试执行了（优先级高严重等级低）；

2） 有些缺陷比较严重，但由于技术的限制，暂时没法修改。这时优先级就降低了；

4、如何有效的报告缺陷？

　　●单一准确：每个报告只针对一个缺陷，如果有多个缺陷，可能开发只修正了其中一个，其他的没有得到修改，加长了缺陷的生命周期；

　　●可以再现：不能忽视或省略任何一项操作步骤，特别是关键性的操作，如描述的不够清楚，RD就会过来沟通怎么操作的，浪费了大家的时间；

　　●完整统一：完整的描述信息；

　　●短小简练：使用关键词；

　　●特定条件：有些问题只在特定环境下存在；

　　1）win7使用某个功能时提交审批时失败，而win8、win10都正常的；

2）IE 文本框搜索有问题，其余浏览器正常；

5、缺陷的生命周期

　　状态：Active（激活） ——> Resolved（已修改） ——> Closed（关闭）

而我们在实际工作中会遇到各种各样的情况，过程有时比较复杂，如：

　　不是每个bug 都能及时得到修改，可能由于时间关系或者技术问题，需要延到下一版本中去修改。

　　有些描述不清楚，RD看不懂或不能再现，将bug打回。

　　有些RD修改了（状态变为Resolved），测试人员验证后，发现bug依旧存在，没有得到彻底的处理，又将bug状态标注为Active。

　　并不是所有的bug都能被及时修复，所以很多bug会被关闭，一般原因有：

　　●Cannot Reproduce（不能再现）

　　●As Designed（设计如此）

　　●Deferred（推迟）

　　●Duplicate（重复提交）

　　●Fixed（已处理）

　　●Obsolete（现在已经不存在的bug）

●Not a bug（RD认为不是问题）

6、常见Bug类型

　　代码错误、界面优化、设计缺陷、配置相关、安装部署、安全相关、性能问题、需求问题、测试脚本、其他。

　　一般以下地方为bug多发区：浏览器兼容性及按钮操作、字符编码、页面跳转、跨域、性能。

7、如何重现在线Bug？

　　●充分利用各种测试手段复现；

　　●尽最大努力来还原当时的场景：环境，数据，前置条件及测试步骤等；

　　●服务器端问题，看log；

　　●前端问题，督促开发加上报警机制；

　　●时间允许情况下，寻求开发协助；

　　对于线上发现的Bug，如果没有分析流程，测试人员需要制定线上Bug的分析流程，先重点分析这个线上Bug产生的原因、线上Bug的影响范围，然后与PM、RD一起决定可以有哪些改进措施可以避免同类线上Bug再犯。

　　bug很严重，影响了版本的发布时，测试人员要再次确认用例设计的覆盖度及周密性。

　　对于测试而言，用例设计的覆盖不够，不够严谨就会导致bug。

　　有两种情况：

　　1）原本用例就没有好好设计过，未经评审过，测试时就很随意；

　　补救措施：赶紧把用例好好琢磨琢磨，再叫上项目相关人员进行评审，这么做的目的也是为了保证测试用例得到了项目相关人员的认可，各种情况大家都讨论过，保证在需求上大家的一致性，保证软件覆盖度能满足本次项目需求的要求，做到需求100%覆盖，开发人员若再提出更多建议，那也可以弥补一些黑盒测试时可能遗漏的情况。

　　2）该项目已经经过严格的需求评审及用例评审了，当然，即便如此也不能避免测试过程中漏测以及对特殊情况的考虑。

　　当我们绞尽脑汁，bug仍然不能复现时，需保持关注，若通过项目组决定不影响版本发布，那么在发布后验证时也需要重点关注。而且该bug不能关闭，依次往以后版本中顺延，并且每轮测试时都要尝试再次复现。

　　那何时可以关闭呢？也许3，5个版本发布后，没有出问题就可以决定关闭它了。

8、缺陷分析

　　测试完成之后，我们需要对缺陷进行一次分析，确定是什么原因造成缺陷的产生，这样可以更好的了解整体的测试效率、RD修复的效率等，可以在项目复盘会中提出。

今日福利

【Java11期开课啦】

8大实战案例模块，历时三年沉淀，Java4.0震撼发布！

偷偷告诉你前50名，还可获得价值300元的京东购物卡呦~

如有疑问，请留言告知，或者咨询柠檬班软件测试培训机构：www.ceshiren.com官网客服哦