關于測試的几篇小文章

来源:互联网 发布:ug8.0编程教程入门图解 编辑:程序博客网 时间:2024/03/28 17:08

测试用例——测试notepad的文件保存功能

 

发布时间: 2009-9-22 12:15    作者: 未知    来源: 51Testing博客转载

字体:  小  中  大  | 上一篇 下一篇 | 打印  | 我要投稿  | 每周一问,答贴有奖 

  测试notepad的文件保存功能,就是file/save弹出对话框的功能,从那几个方面写测试用例?

  ——分析:

  ●     本题主要考察功能性测试。

  ●     功能性测试

  要能成功实现保存,需要比较保存前文件的内容和保存后的文件的内容,比较行数,字符数等,保存为几个文件名,用工具确认它们的异同。

  等价类划分:Windows文件的测试:Windows文件名可以包含除了// : * ? " < > 和 |之外字符.文件名为 1 to 255 字符. 测试文件名的等价类可以如下划分:合法字符,非法字符,合法的长度名称,长度过长的名称和长短过短的名称。文本格式和所有格式保存的测试。所有编码格式的测试。

  状态测试:完成保存后点击关闭,无提示退出,如果改动未保存,应该提示保存,提示菜单的按钮均有效。

  互操作测试:保存的文件和其他编辑工具可以互通。

  竞争条件和时序错乱:多个notepad同时保存。保存时时按键或者单击鼠标。

  重复,压迫和重负:如不停的保存,保存超级大文件至网络服务器(比如samba)

  ●     可靠性测试:

  无

  ●     易用性测试:

  按F1根据光标所在位置有合适的帮助。存储覆盖文件、未保存关闭时有合适的提示。

  UI测试:

  规范性测试:符合现行windows标准

  合理性测试:界面与软件功能是否相融洽,界面的布局是否协调

  一致性测试:使用的控件、标签风格、错误提示信息、操作方法是否一致

  窗口测试:大小、显示、窗口大小改变、多个窗口同时打开、支持操作方法等

  图标测试:是否符合表达习惯;不同的目标是否采用不同的图标;图标尺寸是否合适;建议与对应功能相似;图标上是否有标注。

  鼠标测试:交互环境中是否可以识别鼠标操作;多次点击是否识别;无规则点击是否会产生无法预料的结果;右键弹出菜单是否正确;

  文字测试:界面文字是否正确,准确,无二义性;

  ●     效率:

  存储特大文件的效率

  ●     维护性测试:

  无

  ●     移植性测试:

  无

 

 

TAG: 软件测试技术 测试用例

 

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

 

初感设计测试用例

 

发布时间: 2009-10-20 16:09    作者: xiangyang    来源: Taobao QA Team

 

字体:  小  中  大  | 上一篇 下一篇 | 打印  | 我要投稿  | 每周一问,答贴有奖

 

  第一次从头参加项目,参与前期的需求,UC评审,自己完成负责部分的测试设计,测试用例(TC),执行TC。自己按期完成测试设计,测试用例。感觉不是太困难,但明白自己用例是很粗糙的,具体有什么不足之处也说不上来。时间推移到自己执行时,自己才明白自己的测试用例的粗糙是怎样体现的。

 

  测试用例 bug  一:功能操作TC多管页面校验TC闲事。一个页面显示bug,使得我的TC大批量 failed,其实多数TC死的很冤。一个页面显示错误,校验页面显示的TC已经用自己的failed把好关了。但我却总是在校验功能操作的TC中,跳转新页面的结果中描述一下出现新页面的元素显示。直接后果,一个页面显示错误,挂点掉 N 多TC,包括很多验证功能操作的TC。这些验证功能的TC就是很冤,本来他们负责把关的功能是正确的,而他们 failed 了。这样的恶劣影响就是, failed TC个数不能有效反映 bug 个数。而且也是让这些冤死的TC,多一个条失责罪,因为他们的pass/failed不能有效的反映他们负责把关的功能是OK/NO。

 

  解决方案:大家不要多管闲事,页面显示校验过了,那么操作TC中不要再提,转到一个新页面,不要怕简单,结果就给一句话,多了没有:跳转到XX页面

 

  测试用例 bug  二:功能步骤分家,藕断丝连。如果说上面是让功能TC不要帮页面校验TC,那么 bug 二就是让功能TC兄弟之间也是一定分工分明,不要互帮互助。这次项目中一个惨痛教训。收货地址有一个规则,大概描述是:收货地址默认选中上次使用的收货地址。那么这个功能的本质是通过数据库中一个字段来判断的实现的。那个测试收货地址功能本应分解:1.使用收货地址后设置数据库默认地址字段值;2.使用收货地址时,根据数据库默认地址字段值来选中默认地址。 3.选择使用收货地址创佳订单。  但是当初我却认识不太清楚,设计TC成:第1部分功能是单独一个TC。但是第2部分感觉步骤太小,没有单独成TC,融合到第3部分中。而我又在第3部分很多TC中,每个前面都是加入一句验证:“默认选中上次使用的收货地址”。虽然简单简短一句话,它包含了第1.2两个部分的功能。时间也是推移到执行用例时,没有想到第1部分的简单功能有缺陷,不能设置数据库中的默认值,而且长期没有得到修复。第3部分的很多TC,因为前面一句简短的话:“默认选中上次使用的收货地址”而failed。这个也是误死误伤,和bug 一中的恶劣影响一样。

 

  解决方案:功能分解一定要彻底,步骤不要嫌弃它小,分解成单独TC。分工后一定也只守自己的关。 当然考录到测试的覆盖率,测试完整,需要考虑完全每个步骤的前置和后续场景应该就没有问题了。

 

  只能是初感测试用例设计,谈到的问题应该是大多Tester 不会犯的错误。但对于我自己却是亲身体会得来,意义不同,对自己设计TC有帮助意义,所以在此记下。 自己TC设计还有很多不足之处,希望大家指导帮助。我也将不断学习,提高自己。

 

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

我对测试的感悟

 

发布时间: 2009-10-21 14:19    作者: 周京生    来源: 51Testing软件测试博客

字体:  小  中  大  | 上一篇 下一篇 | 打印  | 我要投稿  | 每周一问,答贴有奖 

  难得能从自己所从事的测试工作中闲暇下来,跳出自己的测试圈子,听听别人对实际工程中测试工作的感悟,所以我也利用听讲座的机会反思了一下自己这些年来的测试经验,简单总结如下:

  1.   在项目开始阶段,测试用例不宜太多、太细、太具体,应该随着项目的不断深入,逐渐地增加测试用例的数量、覆盖的广度和具体程度。

  解释:之所以这样,是因为项目的初始阶段,产品或者项目有太多内容和因素无法确定下来,过多的测试用例只会增加后面维护和修改用例的成本。但往往项目的初期,大家群情激昂跃跃欲试,容易把本可以简单的工作做的很复杂和过于“精致”。等到项目做完的时候,再回首项目初期时所做的“精致”的东东,多半早已被删减的所剩无几或者是改动的面目全非。那么项目的初期的,测试人员应该做些啥呢?多了解项目的背景、用户的需求,熟悉和改进已有测试框架和流程。

  2. 对于自动化测试用例而言,其每一个执行和验证步骤都应该有详细的结果输出到日志文件中。

  解释:自动化测试用例在提高测试执行效率的同时,也引入了很多需要人工辅助的地方。自动化测试用例在执行完毕后,需要人工去分析运行的结果,失败的结果有可能会有比手工测试更多因素造成,包括:产品缺陷、测试框架缺陷、测试用例缺陷、测试执行环境设置问题。没有详细的输出日志文件,你很难快速的分析和定位出测试用例失败的原因。如果每次都需要很费劲的才能分析出测试失败的原因的话,那引入自动化测试用例的优点何在呢?

  3. 寻找适合自己项目的手工测试用例和自动测试用例的合理比例关系。

  解释:2:8还是8:2,或者其它的比例关系。没有去给自己的项目设置一个别人的经验值,多花点是时间研究一下自动化测试在自己项目中的可行性、实现的难度和成本、执行的必要性和可靠性,逐步去摸索得到。理论上自动化测试用例比例越高越好,但如果你的自动化测试框架不稳定、难于开发和维护,那还是越少越好。

  4.  测试用例更需要注释,而且是需要更为详细的注释,详细到何种程度呢?应该让你的手动测试用例描述、自动化测试用例的脚本或者代码足以取代项目经理的产品功能说明。

  解释:认真观察一下软件开发从始至终整个过程中产生的各种“副产品”:项目需求说明、邮件、详细设计、开发人员的产品代码、测试用例、缺陷描述等等,这其中那些是在随着产品的开发过程在不断地更新、始终准确描述了产品的最新功能呢?应该只有两个:产品代码和测试用例。其它的呢?它们实际上都是匆匆的“过客”,服务于开发过程的某个特定的时间片段,服务于对产品代码和测试用例的更新。试想一下你在产品初期编写的需求,和产品实现完成之后功能还一样吗?绝对是不一样的。而产品代码实现了产品功能,但是它的结构复杂,很难从它直接描述出产品的功能。测试用例则不同,其结构工整,组织有序,是天生的用来描述产品的材料。

  5.  测试工作不只是要测试代码,更可以提前到去测试一下项目早期的文档。

  解释:测试人员应该在早期就去测试一下项目早期的各种文档,去读去想这些文档,发现其中不完善的逻辑、不清晰的描述、混乱的定义、哪怕是错别字和拼写错误。这样做是为了能够更早期发现项目的问题,集思广益,同时也是让测试人员更早更深的了解项目。

  6.  测试人员不应该被手工测试用例或者自动化测试用例限制手脚和广阔的思路。

  解释:已经写好的测试用例只能够帮你覆盖住已明确的功能和缺陷,无法帮你发现新的产品问题。测试的目的是去发现更多的问题,不要把自己限制在测试用编写的常规工作中,应该多留些时间去想客户还会怎样使用你产品,多些“天马行空”想象力。

  7.  调动测试人员的热情提高它们在团队中话语权。

  解释:很多人来做测试并不是真正喜欢,而是因为门槛低,在别无其他可选择的情况只好做测试了。在实际的工作中,很多更是只想把测试作为进入这个行业的“驿站”或者“敲门砖”,时刻等待着机会去转为开发人员或者管理人员。造成这样的结果也是必然,国内这个行业从对测试人员的认识和待遇就是这样一个现状,多半是道理上把你说的很重要,实际工作中测试人员总是在从属地位难有真正的话语权,很少能有自发的热情。所以自然而然的,测试人员也就时刻“居安思危”。对于一个公司而言如何来改善这种状况呢?高层领导的认知很重要;测试过程不要死气沉沉,多谢Bug Bash和Application Building这样的活动;产品经理/项目经理/开发组长等应该注意聆听测试人员的意见,团队例会时请给你的QA优先发言权;加强软件生命周期工具(如Visual Studio Team System, IBM Rational等)在测试中的应用,这样可以增强测试过程的规范性、增加测试成果的可度良性和透明性,避免开发和测试人员之间“用嘴喊”的原始合作方式,用文档/邮件来记录发现的产品缺陷、记录测试用例、测试工作项,只会让人觉得测试是一个没规范、随机的过程;发现的任何测试本身的问题,如:测试用例缺陷、测试框架缺陷等,也要以同产品Bug一样对待并记录下来,由测试人员来修复。

  8.  减少UI界面测试用例的数量,多一些单元测试和模型测试。

  解释:UI界面测试的框架都还不是很稳定,执行时间长测试结果分析困难。

  9.  任何测试框架等应该考虑它所依赖的软件生命周期(ALM)管理工具。

  解释:现在的软件开发更为复杂,更强调协作,单独的任何工具已经不再适应这样的需求了,测试工具和框架也是如此,需要喝ALM工具相结合,以促进开发过程不同角色的沟通和协作。

  10. 单个测试用例的测试步骤不要太多,6/7步足以。

  解释:过多的步骤只会带来执行、实现和分析的难度。可创建多个小的测试用例,考虑用它们的组合来实现更复杂的测试。

  11. 软件产能品的复杂性和多样性,决定了不可能有一种简单万能测试方法和自动化测试框架能聪明到把它们都覆盖住。

  随便总结了一下,没想到写了这么多。有些还仅是些初步的项目,有待进一步的完善和补充。希望这些个人的测试工作实际体验能够给大家以帮助!不早了,要休息了!身体是继续更好测试的本钱!

原创粉丝点击