软件测试计划的5W规则
“5W”规则指的是“What(做什么)”、“Why(为什么做)”、“When(何时做)”、“Where(在哪里)”、“How(如何做)”。
利用“5W”规则创建软件测试计划,可以帮助测试团队理解测试的目的(Why),明确测试的范围和内容(What),确定测试的开始和结束日期(When),指出测试的方法和工具(How),给出测试文档和软件的存放位置(Where)。
为了使“5W”规则更具体化,需要准确理解被测软件的功能特征、应用行业的知识和软件测试技术,在需要测试的内容里面突出关键部分,可以列出关键及风险内容、属性、场景或者测试技术。
对测试过程的阶段划分、文档管理、缺陷管理、进度管理给出切实可行的方法。
就通常软件项目而言,基本上采用“瀑布型”开发方式,这种开发方式下,各个项目主要活动比较清晰,易于操作。
整个项目生命周期为“需求-设计-编码-测试-发布-实施-维护”。
然而,在制定测试计划时候,有些测试经理对测试的阶段划分还不是十分明晰,经常性遇到的问题是把测试单纯理解成系统测试,或者把把各类型测试设计(测试用例的编写和测试数据准备)全部放入生命周期的“测试阶段”,这样造成的问题是浪费了开发阶段可以并行的项目日程,另一方面造成测试不足。
相应阶段可以同步进行相应的测试计划编制,而测试设计也可以结合在开发过程中实现并行,测试的实施即执行测试的活动即可连贯在开发之后。
值得注意的是:单元测试和集成测试往往由开发人员承担,因此这部分的阶段划分可能会安排在开发计划而不是测试计划中。
软件测试的几个基本原则
我一直认为软件测试是一件很有原则的工作,这个原则是最重要的,方法都应该在原则指导下进行。
软件测试的基本原则是站在用户的角度,对产品进行全面测试,尽早、尽可能多地发现 Bug,并负责跟踪和分析产品中的问题,对不足之处提出质疑和改进意见。
软件零缺陷(Zero-Bug) 是一种理念,足够好(Good-Enough)是测试的基本原则。
为了达到这个足够好,在软件测试过程中,应注意和遵循的一些基本原则,可以概括为以下几项,我认为适合绝大多数的软件测试工作了。
1. 所有测试的标准都是建立在用户需求之上。
正如我们所知,软件测试的目标就是验证产品的一致性和确认产品是否满足客户的需求,所以测试人员要始终站在用户的角度去看问题、去判断软件缺陷的影响,系统中最严重的错误是那些,导致程序无法满足用户需求的缺陷有那些。
2. 必须基于 “ 质量第一 ” 的思想去开展各项软件测试工作,当时间和质量冲突时,时间要服从质量。
强烈质量的意识、理念和文化(如零缺陷、足够好的目标)同样是软件测试工作的基础。
3. 事先定义好产品的质量标准。
有了质量标准,才能依据测试的结果对产品的质量进行正确的分析和评估,例如,进行性能测试前,应定义好产品性能的相关的各种指标。
同样,功能及其它测试也应该事先定义好标准,包括测试用例应确定预期输出结果,如果无法确定测试结果,则无法进行校验。
4. 软件项目一启动,软件测试也就是开始,而不是等程序写完,才开始进行测试。
这个观念现在越来越受重视了,在代码完成之前,测试人员要参与需求分析、系统或程序设计的审查工作,而且要准备测试计划、测试用例、测试脚本和测试环境,测试计划可以在需求模型一完成就开始,详细的测试用例定义可以在设计模型被确定后开始。
应当把“尽早和不断地测试”作为测试人员的座右铭。
5. 穷举测试是不可能的。
甚至一个大小适度的程序,其路径排列的数量也非常大,因此,在测试中不可能运行路径的每一种组合,然而,充分覆盖程序逻辑,包括业务逻辑、数据流程逻辑等,并确保程序设计中使用的所有条件是有可能的。
6. 第三方进行测试会更客观,更有效。
程序员应避免测试自己的程序,为达到最佳的效果,应由第三方来进行测试。
测试是带有 ”挑剔性” 的行为,心理状态是测试自己程序的障碍。
同时对于需求规格说明的理解产生的错误也很难在程序员本人测试时被发现。
要做出“经得起考验和测试的产品”。
7. 软件测试计划是做好软件测试工作的前提。
所以在进行实际测试之前,应制定良好的、切实可行的测试计划并严格执行,特别要确定测试策略和测试目标。
有效的测试策略和明确的测试目标。
8. 测试用例是设计出来的,不是写出来的,所以要根据测试的目的,采用相应的方法去设计测试用例,从而提高测试的效率,更多地发现错误,提高程序的可靠性。
除了检查程序是否做了应该做的事,还要看程序是否做了不该做的事;不仅应选用合理的输入数据,对于非法的输入也要设计测试用例进行测试。
要知道好的测试用例真的会有效且事半功倍。
9. 不可将测试用例置之度外,排除随意性。
特别是对于做了修改之后的程序进行重新测试时,如不严格执行测试用例,将有可能忽略由修改错误而引起的大量的新错误。
所以,回归测试的关联性也应引起充分的注意,有相当一部分最终发现的错误是在早期测试结果中遗漏的。
其它所有工作都应该避免随意性。
10. 对发现错误较多的程序段,应进行更深入的测试。
一般来说,一段程序中已发现的错误数越多,其中存在的错误概率也就越大。
越需要深入和多次测试。
在实际的测试中时刻牵记这些基本原则,不仅会让工作更充分,而且会让工作越来越轻松,关键是有效果。
所以让我们做有“原则性”的测试工作吧!
软件测试计划的具体要求
编写软件测试计划要避免一种不良倾向是测试计划的“大而全”,无所不包,篇幅冗长,长篇大论,重点不突出,既浪费写作时间,也浪费测试人员的阅读时间。
“大而全”的一个常见表现就是测试计划文档包含详细的测试技术指标、测试步骤和测试用例。
最好的方法是把详细的测试技术指标包含到独立创建的测试详细规格文档,把用于指导测试小组执行测试过程的测试用例放到独立创建的测试用例文档或测试用例管理数据库中。
测试计划和测试详细规格、测试用例之间是战略和战术的关系,测试计划主要从宏观上规划测试活动的范围、方法和资源配置,而测试详细规格、测试用例是完成测试任务的具体战术。
测试资源的变更是源自测试组内部的风险而非开发组风险,当测试资源不足或者冲突,测试部门不可能安排如此多的人手和足够时间参与测试时,在测试计划中的控制方法与测试时间不足相类似。
没有测试经理愿意承担资源不足的测试工作,只能说公司本身是否具备以质量为主的体系或者项目经理对产品质量的重视程度如何决定了对测试资源投入的大小,最终产品质量取决因素不仅仅在于测试经理。
为了排除这种风险,除了像时间不足、测试计划变更时那样缩减测试规模等等方法以外,测试经理必须在人力资源和测试环境一栏标出明确需要保证的资源,否则,必须将这个问题作为风险记录。
软件测试计划的简介
软件 项目的测试计划是描述测试目的、范围、方法和软件测试的重点等的文档。
对于验证软件产品的可接受程度编写测试计划文档是一种有用的方式。
详细的测试计划可以帮助测试项目组之外的人了解为什么和怎样验证产品。
它非常有用但是测试项目组之外的人却很少去读它。
软件测试计划作为软件项目计划的子计划,在项目启动初期是必须规划的。
在越来越多公司的软件开发中,软件质量日益受到重视,测试过程也从一个相对独立的步骤越来越紧密嵌套在软件整个生命周期中,这样,如何规划整个项目周期的测试工作;如何将测试工作上升到测试管理的高度都依赖于测试计划的制定。
测试计划因此也成为测试工作的赖于展开的基础。
《ANSI/IEEE软件测试文档标准829-1983》将测试计划定义为:“一个叙述了预定的测试活动的范围、途径、资源及进度安排的文档。
它确认了测试项、被测特征、测试任务、人员安排,以及任何偶发事件的风险。
”软件测试计划是指导测试过程的纲领性文件,包含了产品概述、测试策略、测试方法、测试区域、测试配置、测试周期、测试资源、测试交流、风险分析等内容。
借助软件测试计划,参与测试的项目成员,尤其是测试管理人员,可以明确测试任务和测试方法,保持测试实施过程的顺畅沟通,跟踪和控制测试进度,应对测试过程中的各种变更。
如何写软件测试计划
展开全部 1 软件测试计划的编写基础知识已经分享的差不多了,之后就是我们的收尾工作,今天给大家讲讲我们做测试过程中会用到的一个文档:《软件测试计划》在我们软件测试工作阶段,一共分为五个阶段:计划、设计、执行、评估、验收。
可以看到在做软件测试工作的时候,最开始,就是要做好计划工作,也就是软件测试计划。
在软件测试计划里面应该包含哪些内容呢?包括这些:1)测试开始时间 &测试结束时间2)测试的内容模块定位(包含哪些内容测试点)3)测试的参与人员以及任务分工4)输出文档的规定以及存放5)采用的测试方法以及测试工具的申请。
其实就总结起来,就是大家看见过的5W原则:When:什么时候开始做,什么时候结束测试,要在这段时间内做好一个规划与进度。
What:我们要做什么?要明确的罗列出来,好明确我们的测试方向和重点,并方便后期划分责任模块Who:谁要参与这次项目的测试?具体负责哪个模块的功能测试?主要负责任务是?都是在这个里面进行明确的责任划分How:如何测试,确定我们的测试方法:是白盒测试还是黑盒测试?我们要不要进行自动化测试要不要进行性能压力测试?要不要进行安全性测试,都需要在这个里面计划好。
Where:这个是说把文档放在哪里,就明确的包括了我们的输出文档有哪些:比如说测试用例?Bug列表?测试报告等等文档要存放的位置,作用就是规定输出文档以及输出文档的存放位置。
怎么样,这么一说,是不是觉得软件测试报告要很好理解了呢?今天给大家分享了软件测试报告的编写!更多问题可以加群 333782754 小编每天都按时推送,关注我们打发你的琐碎时间。
如果你有别的见解,也非常欢迎留言!...
软件测试计划一般都分为哪些主题?
区别在于:测试策略相当于指导思想,测试计划相当于实践方法。
详细区别:测试计划定义:”一个叙述了预定的测试活动的范围、途径、资源及进度安排的文档。
它确认了测试项、被测特征、测试任务、人员安排,以及任何偶发事件的风险。
”内容:产品概述、测试方法、测试区域、测试配置、测试周期、测试资源、测试交流、风险分析等。
注意项:1. 明确测试的目标,增强测试计划的实用性;2. 坚持“5W”规则,明确内容与过程。
利用“5W”规则创建软件测试计划,可以帮助测试团队理解测试的目的(Why),明确测试的范围和内容(What),确定测试的开始和结束日期(When),指出测试的方法和工具(How),给出测试文档和软件的存放位置(Where);3. 采用评审和更新机制,保证测试计划满足实际需求;4. 分别创建测试计划与测试详细规格、测试用例。
测试策略定义:在一定的软件测试标准、测试规范的指导下,依据测试项目的特定环境约束而规定的软件测试的原则、方式、方法的集合。
内容:实施的测试类型和测试的目标、实施测试的阶段、技术、用于评估测试结果和测试是否完成的评测和标准、对测试策略所述的测试工作存在影响的特殊事项等内容。
注意项:a.基于测试技术的测试策略的要点:著名测试专家给出了使用各种测试方法的综合策略:任何情况下都必须使用边界值测试方法;必要时使用等价类划分方法补充一定数量的测试用例;对照程序逻辑,检查已设计出的测试用例的逻辑覆盖程度,看是否达到了要求;如果程序功能规格说明中含有输入条的组合情况,则已开始可以选择因果图方法。
b.基于测试方案的测试策略:对于基于测试方法的测试策略,一般来说应该考虑如下方面:根据程序的重要性和一旦发生故障将造成的损失来确定它的测试等级和测试重点;认真研究,使用尽可能少的测试用例发现尽可能多的程序错误,避免测试过度和测试不足。
α测试的基本原则
软件测试的原则:1、应把“尽早和不断地进行软件测试”作为软件开发者的座右铭,实践证明单元测试能够尽早发现问题,减少后期测试的错误量。
可以采用Junit和Jtest来辅助进行单元测试。
2、测试用例应由测试输入数据、测试执行步骤和与之对应的预期输出结果三部分组成。
3、应当避免由程序员检查自己的程序。
(指后期系统测试阶段,不包括单元测试)4、测试用例的设计要确保能覆盖所有可能路径。
在设计测试用例时,应当包括合理的输入条件和不合理的输入条件。
不合理的输入条件是指异常的,临界的,可能引起问题的输入条件。
5、充分注意测试中的群集现象。
经验表明,测试后程序残存的错误数目与该程序中已发现的错误数目或检错率成正比。
应该对错误群集的程序段进行重点测试。
6、严格执行测试计划,排除测试的随意性。
测试计划应包括:所测软件的功能,输入和输出,测试内容,各项测试的进度安排,资源要求,测试资料,测试工具,测试用例的选择,测试的控制方法和过程,系统的配置方式,跟踪规则,调试规则,以及回归测试的规定等等以及评价标准。
7、应当对每一个测试结果做全面的检查。
8、妥善保存测试计划,测试用例,出错统计和最终分析报告,为维护提供方便。