七、软件测试流程（测试方案-测试用例-缺陷报告-测试报告）

七、测试流程

测试计划/方案（需求分析）-- 设计测试用例（编写用例）-- 执行测试（提交bug）-- 缺陷报告（测试报告）。

（一）拟定软件测试计划、方案（在测试之前写的，指导整个测试过程，一般由经理完成）

 

1.测试计划：

（1）时间进度和人员安排、风险管理；

（2）测试范围的确定、测试数据的生成；

（3）测试工具、方法的选择和工具开发；

（4）测试完成标准；

（5）影响资源分配的特殊考虑等；

2.测试方案：

（1）定义被测软件功能以及相关的测试，并详细说明的测试方法和策略；

（2）创建测试方案是开始测试设计的第一步。测试方案的定义应当基于需求分析和设计文档，并遵从测试计划文档；

3.步骤：

（1）确定测试目标、最终交付物；

（2）确定测试阶段、确定里程碑和交付物；

（3）测试工作范围细化，生成WBS；

（4）对WBS中的每项任务估计完成时间，需要哪些和多少资源；

（5）对WBS中的每项任务估计成本；

（6）估计整个测试的工期和成本步骤；

（7）判断测试是否可以在预定的时间、成本、资源等约束下完成；

（8）如果无法完成，需要调整范围、工期、预算和资源配置直至建立切实可行的测试规划；

4.内容 ：

（1）测试计划标识、目录、参考文献、词汇表、简介；

（2）测试项目：在测试计划范围内需要对哪些内容进行测试及其相关工作（产品基本情况调研、测试需求的说明）；

（3）软件风险、系统风险评估（模块关联问题的风险评估、人力、启动条件）；

（4）待测特性、不被测特性；

（5）测试方法（策略）：如何进行测试以及对测试成功与否起关键作用的问题；

（6）测试项通过/失败标准、挂起和激活标准；

（7）测试交付件（测试计划的发布）；

（8）软硬件环境（测试资源配置）；

（9）计划表、问题跟踪报告；

（二）设计和生成测试用例、准备测试数据（测试用例是指导测试过程的具体方法，一般是先写用例，再执行测试）

1.测试用例

（1）为实施一次测试而向被测系统提供的输入数据、操作或各种环境设置；

（2）控制着软件测试的执行步骤；

（3）是对测试方案中每个测试项的进一步实例化；

（4）测试用例设计方法：等价类、边界值、因果图、决策表、正交法、预测法、场景法、状态法、覆盖法、路径法；

（5）测试用例：重用性、易读性、可维护性；

（6）测试用例的重要性划分：最主要、主要和一般；

2.测试用例的几条基本准则：测试用例的代表性、测试结果的可判定性和可再现性；

3.如何编写/生成测试用例：

（1）对于手动执行的测试用例：确定测试用例，描述执行步骤及预期结果；

（2）对于可自动执行的测试用例：采用工具录制／回放脚本、性能测试工具、使用通用的脚本语言；

4.用例一般执行几次：

（1）验证功能的（目标是把所有问题都找到）；

（2）执行所有的用例（每个模块都覆盖到）；

（3）随意测试/重要模块（发现可能被忽略的问题）；

5.用例的维护（维护阶段：评审阶段、执行阶段、结束之后）：

（1）与当前产品不一致；

（2）发现覆盖不全面的；

（3）用例多余；

（4）需求要求指标调整；

（5）用例描述不清的；

（6）部署后发现的缺陷；

6.用例怎么写比较好：

（1）整体用例逻辑清晰；

（2）执行环境，模块，步骤，结果（页面展现/数据库）；

7.用例怎么写，写在哪？

（1）根据需求文档写测试点，再转化成用例，测试点一般可以用xmind梳理；

（2）根据公司要求，写在禅道或者excel，或者是其他地方；

　　 

（三）执行测试，记录原始数据，对缺陷进行管理（缺陷报告记录bug，通知开发组）

1.软件测试的执行：

（1）执行测试用例；

（2）记录原始测试数据；

（3）记录缺陷；

（4）对所发现的缺陷进行跟踪、管理和监控；

2.可能遇到的问题（解决办法）：

（1）提交缺陷不能被重现；（清晰的描述，必要的前提条件，100%重现的步骤，输入的数据，缺陷的版本号，测试的平台，截图，日志；）

（2）对缺陷的理解不一致；（检查测试环境；）

（3）环境引起的缺陷是否算bug；（多次重现缺陷，确保正确性；）

（4）开发认为是重复的缺陷；（实际结果=预期结果，没有引起其他缺陷；）

3.什么是bug？基本概念：所谓bug，在程序中是指软件运行中因为程序本身有的错误而造成的功能不正常、死机、数据丢失、非正常中断等现象。

4.什么是软件缺陷：

（1）要求的功能未实现；

（2）画蛇添足；

（3）出现指明不应该出现的错误（软件应该有一定的异常处理能力--当用户输入错误的数据时，程序应该给出恰当的处理）；

（4）需求虽未明确提及，但应该实现的功能（需求也是人写的，可能写的不全面）；

（5）软件难以理解、不易使用、运行缓慢，站在用户角度，所有不好的地方；

5.缺陷报告的组成

（1）缺陷编号(Defect ID)：表明提交bug的顺序、在实际项目中，整个项目统一编号，一般是由缺陷管理系统自动生成；

（2）缺陷标题(summary)：简明扼要的描述一下该bug；标题：简洁、具体；

（3）缺陷的发现者(Detected By)：一般就是自己；

（4）发现缺陷的日期(Detected on date)：一般是当天；

（5）缺陷所属的模块(subject)：在测试程序的哪个功能模块时发现的bug、开发经理据此-分配bug给开发人员；

（6）发现缺陷版本(Detected in release)：在测试程序的哪个版本时发现的bug；

（7）指派给谁处理(Assigned to)：测试人员指派给开发经理、开发经理根据bug所在的模块-指派给具体的开发人员；

（8）缺陷的状态(status)：表明bug此时所处的状况或被处理情况；

　　A.测试人员发现bug，提交缺陷报告给开发经理，把缺陷的状态置为：new（新提交）;

　　B.开发经理验证提交的bug，如果是bug，把缺陷的状态改为：open（打开的bug，开发组承认的bug），并指派给相应的开发人员修改；如果不是bug，把缺陷的状态改为：rejected（拒绝）;

　　C.开发人员看到指派给自己bug，进行缺陷修复，改完后，把缺陷的状态改为：fixed（修改完的bug、待返测的bug）;

　　D.测试人员对修复的bug进行返测，如果返测成功，把缺陷的状态改为：closed（关闭、返测成功的bug、归档）；如果返测失败，把缺陷的状态改为：reopen（重新打开的bug、返测失败的bug）;

　　--------------------------------------

　　以上过程一般称为“缺陷（报告）的处理流程”，或者“缺陷的跟踪过程”，或者“缺陷的生命周期”：New->Open->Fixed->Closed。

　　

（9）缺陷的严重程度(severity)：表明bug有多糟糕或者对软件的影响有多大；

　　Urgent：造成死机、崩溃等重大bug；

　　VeryHigh：非常严重的bug；

　　High：严重的bug；

　　Medium：中等程度的bug；

　　Low：小的bug；

　　--------------------------------------

　　严重级别：
　　Block——崩溃的、致命的；

　　Critical——主干功能出错；

　　Major——次要的功能出错，或次要的分支出错；

　　Normal——非重要分支出错；

　　Minor——样式，细节问题；

　　--------------------------------------

　　说明：每个级别代表的含义在不同公司可能不同，一般会在专门文档中或测试计划中定义出详细的准则。

　　　　案例：Bug Level（级别） Definition（定义）；

　　　　性能：Performance；

　　　　功能：Function；

（10）缺陷的优先级（priority）：测试人员希望程序员在什么时间内或程序的哪个版本修改该bug；

　　Urgent：立即修改，否则会影响开发或测试进度；

　　VeryHigh：本版本修改；

　　High：下版本修改；

　　Medium：发布之前修改；

　　Low：在发布中允许存在的bug；

　　--------------------------------------

　　说明：每个级别代表的具体含义在不同公司会略有不同。

　　　A.严重程度：一般严重程度越高，优先级越高；

　　　B.影响范围：一般影响范围越广，优先级越高；

　　　C.开发组当前任务：任务越轻，优先级越高；

　　　D.解决bug的成本：成本越低，优先级越高；

（11）缺陷描述（description）：把发现bug的步骤、过程、使用的数据等记录下来，使程序员可以通过描述再现该bug；描述：详细的重现步骤、提供平台信息、截图；

--------------------------------------------

说明：

a、严重程度和优先级不是严格正比关系；

b、严重程度确定好后一般不修改了，优先级在实际工作中经常需要调整（一般是往后推延）；

c、在产品发布之前，不是所有的bug都会被修复；

d、对于不修复的bug，需要进行缺陷讨论，确定修改它的成本和风险以及该bug给用户的影响（造成的经济损失或导致法律诉讼）；

5.缺陷报告的用途

（1）记录bug；

（2）对bug进行分类（发现者、日期、模块、版本、严重程度、优先级、状态）；

（3）跟踪bug（new->closed）；

（4）对bug进行统计分析总结；

6.如何识别软件缺陷

（1）参考测试用例的预期结果——实际结果和预期结果不一致，就是bug；

（2）参考需求文档——与需求不符的就是bug；

（3）通过与开发、需求、用户沟通进行确定；

（4）参考缺陷的5点定义：

　　A.要求的功能未实现；

　　B.画蛇添足；

　　C.出现指明不应该出现的错误（软件应该有一定的异常处理能力——当用户输入错误的数据时，程序应该给出恰当的处理）；

　　D.需求虽未明确提及，但应该实现的功能（需求也是人写的，可能写的不全面）；

　　E.软件难以理解、不易使用、运行缓慢，站在用户角度，所有不好的地方　；

　　说明：不可重现的bug又称为随机缺陷，也要提交，但是要说明它不可重现；

 7.引起软件缺陷的原因

（1）所有的人都会犯错误，因此由人设计的代码、系统和文档中很可能会引入缺陷。当存在缺陷的代码被执行时，系统就可能无法执行期望的指令（或者做了不应该执行的指令），从而引起软件失效。虽然软件、系统和文档中的缺陷可能会引起失效，但并不是所有的缺陷都会这样。

（2）产生缺陷的原因是多种多样的：人们本身容易犯错误、时间的压力、复杂的代码、复杂的系统架构、技术的革新、或者系统之间的配合工作等。

（3）失效也可能是由于环境条件引起的：放射、电磁辐射和污染等都有可能引起硬件的故障，或者由于硬件条件的改变而影响软件的执行。

（4）线上bug分析 ：非常慎重的对待线上Bug，项目组一起制定改进措施，杜绝再犯。

8.bug怎么写，写在哪？

（1）根据公司要求，写在禅道或者excel，或者是其他地方；

　　

（四）生成软件测试报告、缺陷的统计和报表（总结测试过程，对bug进行分类统计）

1.测试评估：

（1）结合量化的测试覆盖率及缺陷跟踪报告，对整个软件质量、测试工作和软件缺陷进行总结；

（2）对软件项目的质量和开发团队的工作进度及工作效率进行综合评价；

（3）生成相应报告或报表；

2.测试报告：总结测试的结果，通过与未通过的测试用例，并对被测软件对象进行评估；

（1）测试总结：

　　评价软件质量；

　　分析提交客户后的缺陷预测分析，以及维护成本分析；

　　对测试工作进行经验、教训、建议总结；

（2）测试报告：

　　缺陷实际数量与预期数量的分析：开发阶段，每千行有50~60个bug，交付后15~18个；

　　缺陷级别统计分析P1<P2<P3<P4：P1小于总数的5%，P2小于总数15%，P3≈70%，P4小于总数的10%；

　　缺陷的收敛趋势；

　　模块缺陷分布；

　　缺陷修复周期；

　　修复缺陷导致的新缺陷数（3%）；

　　测试工程师误报的缺陷；

　　各类缺陷的统计；

3.质量报告

（1）测试的基本情况：测试的时间段，被测的功能模块情况介绍；

（2）主要结论以及风险：

　　测试总结结论（测试问题发现介绍，能否上线）；

　　遗留bug风险（对遗留的，没有修复的bug重点说明）；

　　其他风险分析 （对其他的质量风险进行说明，如回归测试范围不够，某模块bug太多等）；

（3）测试执行情况：

　　冒烟测试情况（各次冒烟测试的情况）；

　　测试版本情况（各次新需求测试，回归测试的情况）；

（4）产品bug统计分析情况：

　　bug所有者分布图；

　　bug模块分布图；

　　bug级别分布图；

　　bug进度图；