研发流程中的产品测试课件.ppt
- 【下载声明】
1. 本站全部试题类文档,若标题没写含答案,则无答案;标题注明含答案的文档,主观题也可能无答案。请谨慎下单,一旦售出,不予退换。
2. 本站全部PPT文档均不含视频和音频,PPT中出现的音频或视频标识(或文字)仅表示流程,实际无音频或视频文件。请谨慎下单,一旦售出,不予退换。
3. 本页资料《研发流程中的产品测试课件.ppt》由用户(三亚风情)主动上传,其收益全归该用户。163文库仅提供信息存储空间,仅对该用户上传内容的表现方式做保护处理,对上传内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即通知163文库(点击联系客服),我们立即给予删除!
4. 请根据预览情况,自愿下载本文。本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。
5. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007及以上版本和PDF阅读器,压缩文件请下载最新的WinRAR软件解压。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 研发 流程 中的 产品 测试 课件
- 资源描述:
-
1、研发流程中的产品测试本次交流的目的 我们许多技术人员往往将测试简单的理解为对产品功能性能的验证。在产品测试中他们简单的对产品需求规格说明书中所述的产品性能、功能进行分类,并按照其预想的用户操作步骤通过黑盒测试的方法来测试产品是否实现设计指标和功能。这种方法会带来严重的缺陷:本次交流的目的1、产品需求规格说明书只会对产品外在指标和功能进行定义,而不会对产品组成的单元/单板、接口等指标功能进行描述。这样的测试可以肯定比较难以发现产品内部的设计缺陷。2、产品需求规格说明书定义的指标、功能可能列写不充分。根据不充分的需求定义导出的测试用例不能够覆盖基本(正常)事件的测试,导致测试有效性的降低。本次交流
2、的目的3、产品需求规格说明书可能不会对备选事件和异常事件进行描述,即使是一一对应需求规格而设计的测试用例也会造成对备选事件和异常事件的测试遗漏,进一步降低测试有效性。4、单元测试、集成测试、系统测试所用测试用例完全一样,忽略了不同产品测试阶段所要关注的工作重点,使得产品设计缺陷难以在研发阶段暴露,后续影响量产产品的质量。本次交流的目的就是增强技术人员对测试工作的理解和认识,便于后续公司测试工作流程的持续改进。提纲 测试的目的和原则 测试的分类和方法 测试实施测试的目的和原则测试的目的 为使最终用户对产品满意,就必须保证产品功能性能达到用户需求。而验证产品功能性能否达到用户要求的唯一方法就是持续
3、有效的测试。一点共识:测试的目的 从用户的角度出发,就是希望通过测试能充分暴露产品中存在的缺陷,以便决定是否买单。从开发者的角度出发,就是希望测试能表明产品不存缺陷,已经完全正确地实现了用户需求。两种角度:测试的目的 从情感角度来看,开发者是不愿意自己设计的产品被证明存在设计缺陷。从应用角度来看,开发者往往是认为用户一定是按照自己设计好的操作模式来对产品进行操作的。三个问题:从实施角度来看,开发者总是对能够验证产品已经实现了预期功能的测试项目更加感兴趣。测试的目的 测试不仅仅是为了证明产品能够实现既定功能,还要尽可能多地发现产品中的错误和缺陷。测试只能证明错误的存在,但不能证明错误不存在。四条
4、结论:研发产品质量保证的唯一方法就是尽量大覆盖范围下的有效测试。测试的有效性是通过符合实际应用条件下的测试用例的设计及实施来保证。测试实施原则 由于惯性思维的存在使得难以发现设计缺陷,因此尽量避免设计人员来测试自己设计的产品,但是单元测试除外。确定预期输出结果是测试用例必不可少的一部分。如果只有测试数据而无预期结果,那么就不容易判断测试结果是否正确。彻底检查每个测试结果。如果不仔细检查测试结果,有些已经测试出来的错误也可能被遗漏掉。测试实施原则 对非法的和非预期的输入也要像合法的和预期的输入一样编写测试用例。检查产品是否做了应做的事仅是成功的一半,另一半是看产品是否做了不该做的事。对测试错误结
5、果一定要有一个确认的过程,一般有A测试出来的错误,一定要有一个B来确认,严重的错误可以召开评审会进行讨论和分析。测试实施原则 测试后遗留的错误数目往往与已发现的错误数目成比例。因此当A模块找出错误比B模块多得多时,很可能A模块遗留的错误仍比B模块遗留的错误多。回归测试的关联性一定要引起充分的注意,修改一个错误而引起更多的错误出现的现象并不少见。妥善保存一切测试过程文档,测试的重现性往往要靠测试文档。测试实施原则 制定严格的测试计划,并把测试时间安排的尽量宽松,不要希望在极短的时间内完成一个高水平的测试。“尽早和不断的测试”应该成为一个合格的开发者的座右铭。总结一下 对于测试重要性的理解我们都相
6、差不多,唯一的区别在于对测试所关注问题的不同看法。我们的核心问题是如何提高测试效率。测试会占用开发周期,特别是测试覆盖率要求越高周期就会越长,这与开发进度要求一定是矛盾的。开发人员、测试人员较少测试经验,不具备良好的测试技能和测试工具,使得测试进度更加不可保证。广义的测试 测试应该贯穿产品开发周期,测试不仅仅是测试所实现的产品性能与功能,还要测试开发周期中各种设计文档。需求阶段、总体(概要)设计阶段、详细设计阶段所输出的技术文档,包括需求规格说明、总体(概要)设计、详细设计、源程序(SCH、PCB)、用户文档等,都是测试的对象。测试的分类测试的分类 按测试方法划分,有静态测试和动态测试。动态测
7、试:动态测试:使被测试产品或模块有控制地运行,并从多种角度观察运行时的行为,以发现其中的错误。静态测试:静态测试:就是指人工评审设计文档,借以发现其中的错误。作为研发质量控制的重要手段,评审经常作为具体实施前的检查手段,其目的是保证设计的正确性、减小设计风险、尽早发现设计缺陷。测试的分类 按测试功能划分,有黑盒测试和白盒测试。白盒测试:白盒测试:对模块内部是不透明的。从模块/产品的设计、结构上来进行测试,检查模块/产品中的错误。黑盒测试:黑盒测试:对内部透明,仅从使用上来检查功能上是否有错误。黑盒与白盒 黑盒测试是从上到下、从宏观到微观的逐步验证过程,一般止步于单板/功能模块外部功能的测试。白
8、盒测试是从下到上、从微观到宏观的逐步验证过程,一般涉及单板/功能模块内部性能功能及单元间接口的测试。一般采用白盒测试方法来检查产品的基本功能单元内部错误,而采用黑盒测试方法来验证由各功能单元组装而成的产品/系统的功能和性能。黑盒与白盒 黑盒测试也称功能测试或数据驱动测试,它是在对产品应具功能进行抽象的基础上,将程序划分成功能单元,然后对每个功能单元设计测试用例进行测试。优点:优点:黑盒法测试用例是围绕着产品操作方式和实际应用环境来设计的,每一个测试用例表征着一种产品实际可能发生的应用场景,测试结果非常直观便于理解。缺点:缺点:黑盒测试用例的设计不可能做到完全覆盖,因此难以完全触发产品内部所有执
9、行流程/路径,也就难以完全发现深藏在产品内部单元/模块及接口的设计缺限,需要有白盒测试进行补充。黑盒与白盒 白盒测试也称结构测试或逻辑驱动测试,在知道产品内部工作过程的前提下,按照产品内部的结构,通过测试来检测产品内部动作是否符合详细设计。优点:优点:白盒法测试用例是围绕着产品设计实现角度出发,通过对其内部信号特征、接口功能性能的覆盖性检查来保证设计的正确性。缺点:缺点:以详细设计为依据,以覆盖率为最终目标,因此缺乏宏观把握的能力。不能查出详细设计本身所存在的问题,即错误的产品设计。不可能查出被详细设计所遗漏的功能、性能。灰盒测试 灰盒测试介于黑盒与白盒之间,关注输出对于输入的正确性,同时也关
10、注内部表现,但这种关注不象白盒那样详细、完整,只是通过一些表征性的现象、事件、标志来判断内部的运行状态。灰盒法在用例设计中不关心模块内处理过程,只关心被测对象的输入与输出,这是典型的黑盒思维模式。灰盒法在用例设计时基于对模块内部处理的了解,测试设计可以有针对性的进行,测试过程评估也是白盒法。模糊测试 模糊测试是黑盒法中的一种,其执行过程为:向产品有意识地进行无效输入以期望触发错误条件或引起产品的故障。模糊测试最为形象的说法是:测试过程要做的就是站在后面向目标投掷石头,等待玻璃被打破的声音。就这个意义而言,模糊测试可被归结为黑盒测试。若我们对产品内部有所了解,就可以让石头每次的飞行路线更直接并且
11、更真实。因此,模糊测试也可以应用在灰盒测试中。测试方法的选择 有一种观点认为:在单元测试阶段采用白盒法;在集成测试阶段采用灰盒法;在系统测试阶段采用黑盒法。测试的分类 按测试步骤划分,有单元测试、集成测试、系统测试。单元测试:单元测试:也称模块测试。测试的对象是设计的最小单位功能模块。单元测试的依据是详细设计描述,对模块内所有表达功能/性能的节点设计测试用例,以便发现模块内部的错误。单元测试主要发现详细设计阶段产生的错误。测试的分类 集成测试:集成测试:又称联合测试也称组装测试,它是对由各模块组装而成的产品进行测试,主要检查模块间的接口和通信。系统测试:系统测试:是把软、硬件和环境连在一起全面
12、的测试,检查系统的功能、性能及其他特征是否与用户的需求一致,它是以需求规格说明书作为依据的测试。系统测试又可细分为功能测试、容量测试、压力测试、使用性测试、安全性测试、性能测试、可靠性测试、恢复测试、强度测试、文档测试以及工序测试。测试的分类 划分测试的种类并不重要,重要的是,一定要把测试看成是产品设计全生命周期持续不断而不是阶段性的工作。测试覆盖范围 正确性测试:正确性测试:测试用例中的测试点应首先保证要至少覆盖需求规格说明书中的各项功能。健壮性测试:健壮性测试:正确信息输入将产生预期输出,非法信息输入将导致相应提示或错误处理,而不至于系统/模块崩溃。容错性测试:容错性测试:测试系统/产品的
13、功能单元、接口间出现异常的情况下系统的保护性处理,以及异常结束后系统功能性能的恢复处理。测试覆盖范围 可靠性测试:可靠性测试:测试系统/产品在实际应用环境下可保证性能功能有效性的能力。压力测试:压力测试:测试在大信息量处理情况下的系统/产品正常工作的能力。回归测试:回归测试:测试上一轮测试所发现缺陷的解决及对系统的潜在影响。软件测试与硬件测试 软件测试:软件测试:软件不涉及制造加工,因此软件测试的目的仅仅是验证设计的正确性。硬件测试:硬件测试:除了验证设计正确性以外,还要包括制造的准确性,或者一致性测试。软件测试与硬件测试 当我们只考虑验证设计正确性的话:软件测试:软件测试:发现软件代码语法错
展开阅读全文