软件测试流程--卢璐

软件测试流程及现阶段流程讨论F验收测试B单元测试C整合测试D系统测试E性能测试A测试计划、测试设计立项结束测试工作总体流程图（测试阶段）A测试计划、测试设计依据《项目需求规格说明书》、《项目开发架构设计》和《项目整体计划》设计《测试计划》和《测试设计》审核进入下一阶段《测试计划》根据用户需求报告中关于功能要求和性能指标的规格说明书，定义相应的测试需求报告，即制订黑盒测试的最高标准，以后所有的测试工作都将围绕着测试需求来进行，符合测试需求的应用程序即是合格的，反之即是不合格的；同时，还要适当选择测试内容，合理安排测试人员、测试时间及测试资源等。《测试设计》将测试计划阶段制订的测试需求分解、细化为若干个可执行的测试过程，并为每个测试过程选择适当的测试用例审核通过B单元测试〈测试设计文档〉单元测试方案依据需求和设计描述作为指南，对重要的控制路径进行测试以发现模块内的错误。产生测试用例BUG记录开发人员提供新版本回归测试单元测试总结单元测试执行BUG记录版本提交使用测试工具对BUG测试记录的版本进行控制针对上个测试版本的BUG记录进行测试在BUG出现的曲线图逐渐收敛并且得到控制的情况下进入下一阶段C整合测试整合测试方案产生测试用例BUG记录开发人员提供新版本回归测试整合测试总结整合测试执行主要针对模块之间互相叠加的功能设计测试用例。上一阶段使用测试工具对BUG测试记录的版本进行控制BUG记录提交针对上个测试版本的BUG记录进行测试D系统测试系统测试方案产生测试用例BUG记录开发人员提供新版本回归测试系统功能达到需求标准系统测试执行上一阶段BUG记录版本提交系统测试综合报告针对上个测试版本的记录进行测试系统测试综合报告提交报告申请进入下一阶段(1)设计测试所有从系统的其他元素来的信息的错误处理路径；(2)在软件接口处进行一系列仿真错误数据或者其他潜在错误的测试；(3)记录测试的结果作为当“互相指责”时出现的“证据”；(4)参与系统测试的计划和设计来保证系统进行了足够的测试。使用测试工具对BUG测试记录的版本进行控制E性能测试依据性能测试脚本使用压力测试工具进行压力测试性能测试报告依据需求规格说明书的要求设计性能测试脚本性能测试方案依据系统各页面的实际访问量大小设计压力大小。例如：应该给予首页比较大的访问压力测试评估运行环境优化调试对系统进行优化调试脚本优化调整提交报告申请进入下一阶段达到产品需求规格标准测试报告提交包含压力测试过程中出现的异常和不符合产品需求的情况。性能测试与压力测试同步F验收测试主要由客户依据＜需求规格说明书＞在客户的验收环境下进行测试测试人员进行ＢＵＧ记录提交BUG记录验收测试设计验收测试方案开发人员提供修改后的版本产品质量验收合格证书测试工作总结符合需求规格说明书标准测试流程详述一般而言，软件测试从项目确立时开始，前后要经过以下一些主要环节：需求分析→测试计划→测试设计→测试环境搭建→测试执行→测试记录→缺陷管理→软件评估→RTM首先明确分工，一般而言，需求分析、测试用例编写、测试环境搭建、测试执行等属于高级测试人员工作范畴，而测试执行以及缺陷提交等属于普通测试人员的工作范畴，测试负责人负责整个测试各个环节的跟踪、实施、管理等。说明：1．以上流程各环节并未包含软件测试过程的全部，如根据实际情况还可以实施一些测试计划评审、用例评审，测试培训等。在软件正式发行后，当遇到一些严重问题时，还需要进行一些后续维护测试等。2．以上各环节并不是独立没联系的，实际工作千变万化，各环节一些交织、重叠在所难免，比如编写测试用例的同时就可以进行测试环境的搭建工作，当然也可能由于一些需求不清楚而重新进行需求分析等。所以在实际测试过程中也要做到具体问题具体分析，具体解决。需求分析需求分析（RequirmentAnalyzing）应该说是软件测试的一个重要环节，测试人员对这一环节的理解程度如何将直接影响到接下来有关测试工作的开展。可能有些人认为测试需求分析无关紧要，这种想法是很不对的。需求分析不但重要而且至关重要！一般而言，需求分析包括软件功能需求分析、测试环境需求分析、测试资源需求分析等。其中最基本的是软件功能需求分析，测一款软件首先要知道软件能实现哪些功能以及是怎样实现的。那我们就应该知道软件是怎样来实现这些功能的，为了实现这些功能需要哪些测试设备以及如何搭建相应测试环境等。测试需求分析的依据有软件需求文档、软件规格说明书以及开发人员的设计文档等。测试计划测试计划（TestPlan）一般由测试负责人来编写。测试计划的依据主要是项目开发计划和测试需求分析结果而制定。测试计划一般包括以下一些方面：1．测试背景a.软件项目介绍；b.项目涉及人员（如软硬件项目负责人等）介绍以及相应联系方式等。2．测试依据a.软件需求文档；b.软件规格书；c.软件设计文档；d.其他，如参考产品等。3．测试资源a.测试设备需求；b.测试人员需求；c.测试环境需求；d.其他。测试计划4.测试策略a.采取测试方法；b.搭建哪些测试环境；c.采取哪些测试工具以测试管理工具；d.对测试人员进行培训等。5．测试日程a.测试需求分析；b.测试用例编写；c.测试实施，根据项目计划，测试分成哪些测试阶段（如单元测试、集成测试、系统测试阶段，α、β测试阶段等），每个阶段的工作重点以及投入资源等。6．其他测试计划还要包括测试计划编写的日期、作者等信息，计划越详细越好了。计划赶不上变化，一份计划做的再好，当实际实施的时候就会发现往往很难按照计化开展。如在软件开发过程中资源匮乏、人员流动等都会对测试造成一定的影响。所以，这些就要求测试负责人能够从宏观上来调控。测试设计测试设计主要包括测试用例编写和测试场景设计两方面。一份好的测试用例对测试有很好的指导作用，能够发现很多软件问题。关于测试用例编写，以后有机会我们再详细进行培训。测试场景设计主要是测试环境问题。测试环境搭建不同软件产品对测试环境有着不同的要求。如C/S及B/S架构相关的软件产品，那么对不同操作系统，如Windows系列、unix、linux甚至苹果OS等，这些测试环境都是必须的。而对于一些嵌入式软件，如手机软件，如果我们想测试一下有关功能模块的耗电情况，手机待机时间等，那么我们可能就需要搭建相应的电流测试环境了。当然测试中对于如手机网络等环境都有所要求。测试环境很重要，符合要求的测试环境能够帮助我们准确的测出软件问题，并且做出正确的判断。为了测试一款软件，我们可能根据不同的需求点要使用很多不同的测试环境。有些测试环境我们是可以搭建的，有些环境我们无法搭建或者搭建成本很高。不管如何，我们的目标是测试软件问题，保证软件质量。测试环境问题，还是根据具体产品以及开发者的实际情况而采取最合适的方式。测试执行测试执行过程又可以分为以下阶段：单元测试→集成测试→系统测试→验收测试，其中每个阶段还有回归测试等。从测试的角度而言，测试执行包括一个量和度的问题。也就是测试范围和测试程度的问题。比如一个版本需要测试哪些方面？每个方面要测试到什么程度？从管理的角度而言，在有限的时间内，在人员有限甚至短缺的情况下，要考虑如何分工，如何合理地利用资源来开展测试。当然还要考虑以下问题：1．当测试人员测试的执行不到位、敷衍了事时该如何解决？2．测试效率问题，怎样提高测试效率？3．根据版本的不同特点是只做单元测试还是采取冒烟测试亦或是系统全面测试？4．当测试过程中遇到一些偶然性随机问题该怎样处理？5．当版本中出现很多新问题时该怎样对待？测试停止标准？6．……总之，测试执行过程中会遇到很多复杂的问题，要学会具体问题具体解决！测试记录缺陷记录总的说来包括两方面：由谁提交和缺陷描述。一般而言，缺陷都是谁测试谁提交，当然有些公司可能为了保证所提交缺陷的质量，还会在提交前进行缺陷评估，以确保所提交的缺陷的准确性。在缺陷的描述上，至少要包括以下一些方面内容：序号、标题、预置条件、操作步骤、预期结果、实际结果、注释、严重程度、概率、版本、测试者、测试日期以上是描述一个bug时通常所要描述的内容，当然在实际提交bug时可以根据实际情况进行补充，如附上图片、log文件等。另外，一个版本软件测试完毕，还要根据测试情况出份测试报告，这也是所要经过的一个环节。软件评估、测试总结、测试维护软件评估这里评估指软件经过一轮又一轮测试后，确认软件无重大问题或者问题很少的情况下，对准备发给客户的软件进行评估，以确定是否能够发行给客户或投放市场。软件评估小组一般由项目负责人、营销人员、部门经理等组成，也可能是由客户指定的第三方人员组成。测试总结每个版本有每个版本的测试总结，每个阶段有每个阶段的测试总结，当项目完成RTM后，一般要对整个项目做个回顾总结，看有哪些做的不足的地方，有哪些经验可以对今后的测试工作做借鉴使用，等等。测试维护由于测试的不完全性，当软件正式release后，客户在使用过程中，难免遇到一些问题，有的甚至是严重性的问题，这就需要修改有关问题，修改后需要再次对软件进行测试、评估、发行。Q&A