`

功能测试经验

阅读更多

测试准备:

 1、实际测试总比你预想的要花更多的时间,遇到更多的麻烦,所以要尽量争取足够的测试时间,不要不加思索的说这个东西我一星期肯定可以测完。还要尽可能考虑到测试过程中的风险,比如测试环境的问题、部署失败的问题、开发延期的问题、人员变动的问题等等。

 2、实际上从来都没有过完善的需求,可惜的是教科书从来也没讲过如何应对不完善的需求。我曾不止一次的想如果让做需求的和编程人员都来做两个月的测试,他们的工作能力肯定会有质的飞跃,可惜这只是我的梦想。需求说明书中总会遗漏很多细节,通常需求人员认为那些地方都是理所当然无需赘言的,但开发人员却会有不同的理解,所以测试人员要尽可能的在开始编程之前找出需求中所有不明确、有遗漏的地方。如果能在讨论需求的时候就提出问题那比从已经写好的需求说明书中挑错要好的多。问题越早发现越容易解决。

 3、测试人员最好能在开发开始之前,总结出一个列表,列表中列出需要开发人员统一处理的一些细节,比如表单中表头和表内容用什么字体字号;是左对齐还是居中;翻页控件是放在表单左下角还是右下角还是居中;标点符号是用中文半角还是全角;选择框和下拉菜单中的内容按什么排序;搜索结果是否需要排序;错误提示是弹出窗口还是显示在原界面;错误提示语也应尽量统一风格;查询后是否要保存查询条件;浏览器的前进后退是否需要限制等等。项目经理最好统一给开发人员讲一下这些规矩,这样会在测试时省很多事。

测试用例

 1、测试用例要因人而异,如果自己已经很熟练了,测试用例可以只是简单的提示,不需写出详细的执行步骤和测试数据,以免因为无谓的文档浪费太多时间。如果很可能别人还要复用你的测试用例而且有充足的时间,这时就可以把测试用例写详细点。

 2、至于测试数据需不需要在设计测试用例时就写出需要根据实际项目情况来定,我一般认为最好把测试用例都写完之后,再准备测试数据,一条数据可以覆盖多个测试用例,这样很可能四五条数据就可以覆盖十几个测试用例,这样可以提高效率。教科书通常认为一条测试数据最好对应一个测试用例,这样测试执行失败时就容易定位问题出在哪里。但实际情况是只有极少数的测试会执行失败并因此发现bug,但如果因为这极少数的失败的情况来降低整个测试执行的效率就显得缺乏实践性了,况且并不是说一条测试数据覆盖了多个用例时就不容易定位错误的根源。所以测试要根据实际情况灵活进行。

 3、如果要写详细的测试用例,就一定要写的非常的清楚明了,最好让一个不懂项目情况的人也能根据用例执行测试。而且测试用例和测试数据中的关键值一定要用颜色标出。最好还能写出每条用例的测试目的,这样方便日后别人补充你的测试用例。

  测试执行:

 1、如果时间允许,测试一个页面时,要把这个页面的所有功能点的正常异常情况都测完之后再去测下一个页面,这样不容易遗漏。大多时候时间都不很充足,这时要先测主要流程和主要的功能点,这些完成之后再去测细节和异常情况,因为并不是有bug就不能上线的。

 2、如果发现了很多界面性的小问题,不要连续提出,最好先提一两个功能性的问题,再提一两个界面性的问题,这样间隔着提bug有利于开发人员接收,免得他把你提的连续的四五个界面性的bug都拒绝了。另外,一个bug里最好不要既包括功能性问题又包括界面性问题,这样有可能开发人员只解决了功能性问题就把bug 关了。

3、可以一条测试数据覆盖多个测试用例,这样可以提高效率,前提是程序的质量还可以或者可以根据测试结果(结果数据和log)定位是哪个功能点的问题。

 4、如果时间充足的话,测试要在安静的环境中不慌不忙地进行,这样容易联想到更多的测试功能点,也可能因此发现更多的bug。如果测试太匆忙,通常测试人员只是想尽快地执行完所有测试用例。

 5、如果测试还要进行多个版本,则需要不断完善测试用例,并总结为什么一开始会遗漏这些测试点。

  6、测试的目的是发现bug,不是执行完所有用例或者覆盖尽可能多的路径。所以如果全面的测试已无益于发现新的bug时,要让测试人员充分发挥自己的主观能动性,随机地对可疑的地方进行测试。

  7、发现bug时要确定自己操作和理解没有问题再向开发人员提出,而且要注意表达方式。

  8、平日最好能和开发人员保持不错的关系,这样有利于测试的进行。

  9、不要迷信功能测试的自动化,我认为只有在版本稳定后还需要进行多个版本的测试时才需要测试自动化,而且要求测试人员都可以熟练使用测试自动化工具。自动化测试的最大困难可能是需求和界面的频繁变化。

 

 

分享到:
评论

相关推荐

    软件测试 性能测试 性能测试报告 系统性能测试方案 性能测试经验 测试模板

    软件测试 性能测试 性能测试报告 系统性能测试方案 性能测试经验 测试模板 “苍蝇式的战斗精神”和“XX性能测试”.pdf Mercury性能测试模板.doc web项目测试实战性能测试结果分析样章.doc XX性能测试报告.pdf XX性能...

    性能测试经验分享.ppt

    性能测试经验分享 性能测试是一种验证系统性能的方法,旨在评估系统在高负载或高压力下的表现。性能测试可以分为三个方面:指标测试、性能压力测试和性能优化。 一、指标测试 指标测试是对系统性能的评估,通常...

    性能测试经验

    性能测试一点经验,可以参考一下

    手机性能测试经验分享PPT学习教案.pptx

    手机性能测试经验分享PPT学习教案.pptx 本资源是一个关于手机性能测试经验分享的PPT学习教案,主要涉及到手机性能测试的经验分享和学习指南。下面是对该资源的详细知识点解析: 1. 手机性能测试经验分享主叫流程 ...

    性能测试经验(转).pdf

    ### 性能测试经验知识点详解 #### 一、性能测试背景 - **系统概况**:X银行营销服务系统总行版使用DB2数据库和WebLogic应用服务器,支持约5000名用户(包括各分行、支行主管及客户经理)。系统部署在总行机房,各地...

    功能和性能测试经验谈

    在软件测试领域,功能测试和性能测试是两个关键的环节,它们对于软件质量的保障至关重要。功能测试关注的是软件是否能够按照预期执行其预定功能,而性能测试则侧重于评估软件在各种负载和压力下的响应速度、稳定性和...

    LoadRunnet性能测试经验总结

    ### LoadRunnet性能测试经验总结 #### 一、性能测试规划阶段 **1. 明确测试目标** - **确定压力点**:首先要明确测试的目的,即确定系统的哪些部分需要承受压力测试,例如数据库访问、高并发请求处理等。 - **...

    性能测试经验总结CIU软考联盟

    【性能测试经验总结】 性能测试是评估软件系统在高负载和大并发情况下的稳定性和响应时间的关键环节。本文主要从CIU软考联盟的角度总结了性能测试的主要步骤,包括计划测试、生成测试脚本和建立场景,以及如何进行...

    存储性能测试经验分享.doc

    存储性能测试经验分享.doc

    互联网性能测试经验分享

    ### 互联网性能测试经验分享 #### 案例一:测试结果与实际情况不符 - **测试对象**:检索模块 - **表现**: - 线下测试时,在请求量为400条/秒的情况下,机器的CPU空闲率(cpuidle)为40%; - 线上服务时,在...

    第一次性能测试后的经验总结

    ### 第一次性能测试后的经验总结 #### 一、性能测试流程方面 在进行性能测试之前,需要对业务流程有深入的了解,明确测试的目的和范围。对于初次接触性能测试的人来说,以下几点尤为重要: 1. **熟悉业务流程**:...

    性能测试经验总结、心得分享和实际案例展示.zip

    本资料包“性能测试经验总结、心得分享和实际案例展示.zip”旨在为初学者提供全面的性能测试知识,帮助他们理解并掌握这一领域的核心技能。 一、性能测试流程 性能测试通常包括以下步骤: 1. 需求分析:明确测试...

    [17个软件测试文档]-8性能测试经验总结

    下面是对8个性能测试经验的详细总结: 1. **计划测试** - 明确压力点:确定系统的关键性能指标,如并发用户数、数据处理速率等。 - 设计测试场景:根据压力点创建多种场景组合,考虑不同用户行为和负载情况。 - ...

    金蝶ERP性能测试经验分享.docx

    金蝶ERP性能测试经验分享.docx金蝶ERP性能测试经验分享.docx金蝶ERP性能测试经验分享.docx金蝶ERP性能测试经验分享.docx金蝶ERP性能测试经验分享.docx金蝶ERP性能测试经验分享.docx金蝶ERP性能测试经验分享.docx金蝶...

    性能测试经验总结资料,适宜初学和中级(由于是公司内部资料,不想花分勿下)

    ### 性能测试经验总结资料知识点详述 #### 一、概述 - **编写目的**:此文档旨在为参与性能测试的相关人员(如需求分析师、开发人员、测试人员等)提供一套全面且实用的性能测试指导手册。目的是帮助他们更好地...

Global site tag (gtag.js) - Google Analytics