[测试]读书笔记(二)

原创 2006年05月18日 18:45:00

第二章 测试技术

 

2.1 软件开发V模型

              软件评审的优点:1 早发现错误早纠正,降低开发成本。2 除开发人员外还有其他人员       参加,特别是用户,兼容各家之长。3 发现的缺陷较显见。4 评审往往可以发现成批的    错误并成批的纠正,效率较高。5 开发人员可以从容对待,全面权衡选择修改方案。

              据统计,在典型的软件开发项目中,30%~70%的缺陷是通过评审发现的。

 

 

2.2 软件评审方法

              1)组织评审组,负责人主持整个评审工作

              1 评审组成员的聘任,准备工作。

              2 组成员应该包括项目管理人员,开发人员,同行专家(报告者,召集人,秘书,维           护者,标准检查员,用户代表,其他人员)。

              3 人数不宜太多,以利于讨论。

              2)评审会准备

              1 资料提前5天分发,要求会前准备,阅读并记下问题。

              2 准备检查表(check list)。

              3 了解准备情况,必要时开预备会。

              3)评审会

              1 负责人主持,可由报告者介绍,也可按检查表逐项进行。

              2 做记录。

              3 只讨论问题是否存在,不问原因和责任,不讨论如何解决。

              4 会议时间不要过长。

              4)评审会后续事项

              1 开发人员根据评审会提出的问题进行修正。

              2 评审会负责人视情况决定是否再评审,确认修正的有效性。

 

 

2.3 程序静态检查方法

             

              2.3.1 桌前检查(desk checking

              程序员检查自己编写的程序,在程序通过编译之后,单元测试之前,对程序源代码进行       分析,校验并补充相关的文档,目的是发现程序中的错误。

              检查项目有:

                     检查变量的交叉引用表

                     检查标号的交叉引用表

                     检查子程序,函数,宏

                     等价性检查

                     常量检查

                     风格检查

                     比较控制流

                     选择,激活路径

                     对照程序的模块设计书,详细阅读代码

                     补充文档

             

              2.3.2 代码评审(code reading review

              由若干的程序员和测试员组成的一个评审小组,通过阅读,讨论和争议,对程序进              行静态分析的过程。

              在代码评审之后,需要做以下几件事:把发现的错误登记造表,并交给程序员;发现错       误较多,或发现重大错误,则在改正之后,再次组织代码评审;对错误登记表分析,归    类,精炼,以提高审议效果。

 

              2.3.3走查(walk-through

 

2.4 测试用例的设计原则

              1)注重有效性

              2)注重经济性

              3)为排错提供有效依据

              4)考虑多重性

              5)分析功能完备性

              描述测试用例的质量:有效性,可效仿性,经济性,修改性。

 

2.5 软件测试基本技术

             

              软件测试的基本内容包括:

(1)       测试计划:开始测试之前,针对被测对象制定测试内容,步骤,方法,标准,进度以及人员,资源等在内的测试计划,使整个测试工作能按规定要求进行。测试计划一般包括(每个测试阶段的目的;每个测试阶段完成的标志;时间进度表;每个测试阶段的负责人员,所需资源以及测试用例;测试所使用的工具)。测试活动中,应对测试的实际情况做好记录,内容有(发现的缺陷和错误;纠错时对软件进行的修改;回归测试的情况;错误原因,类型,比率的分析和统计。)

(2)       白盒测试:根据程序内部逻辑来设计测试用例。语句覆盖率(100%);分支覆盖率(80%~90%);条件覆盖率(60%~80%);分支/条件覆盖率(实际上不一定);条件组合覆盖率(级别最高,用例设计困难)。

(3)       黑盒测试:根据程序功能说明来设计测试用例。等价分类法;边界值分析法;因果图法;错误推测法。

(4)       集成测试:根据设计规约将各个模块连接起来,用测试用例来发现结构设计时留下的软件缺陷或错误,如模块之间的接口。(常用黑盒测试)渐增式和非渐增式(渐增式就是在N个已连接模块执行测试的基础上再加上一个模块,对N+1个模块执行测试用例);由底向上;由顶向下。

(5)       回归测试:发现存在缺陷后,首先把错误定位,其次提出修改方案,经审定后正式修改。然后将原有的测试用例重新测试,并验证测试结果。(注意,不能简单的执行发现错误的用例,有时修改程序时,会造成软件在其他处的缺陷)

(6)       系统测试:把软件产品放到应用环境下由最终用户进行的测试,以检查是否符合需求描述的要求。(对测试人员的要求较高)。

(7)       验收测试:用于商品化方面的测试。α测试(软件企业在商品发布前的综合测试);β测试(投入市场前提供给某些用户进行试用的测试)。

 

 

 2.6 排错

               注意事项:(1)确定错误的性质和位置(使用联想和逻辑推理,充分分析和思考与错误              征兆有关的信息;当遇到困难时,应该先搁置一段时间,使头脑思考避开死胡同;充分              利用排错工具做为辅助手段,但绝不是代替思考;召集有关人员,自己讲解这段程序的           设计和编码的具体情况,比较有效的方法)。

               2)修改错误(由于错误有群集现象,如已发现某段程序有缺陷时,在修改的同时,                尚需检查其近邻是否还存在别的错误;修改了某个错误的征兆或表现,还需再次检查该           错误导致的本质,一定要修改能够解释清楚与这个错误有关的全部线索;努力避免修改           了一个已发现的错误,而带进了一个新的错误。回归的必要;修改错误时,追溯到前一           段的工作时必须要谨慎;修改了源程序,同时要修改相应的文档)。

 

 2.7 软件测试自动化技术

              (节省的资金为手工测试的80%

              2.7.1测试工具分类

                     测试设计工具

                     测试管理工具

                     静态分析工具

                     覆盖工具

                     排错工具

                     动态分析工具

                     性能模拟工具

                     测试执行和比较工具

              2.7.2 脚本技术

                     脚本语言是一种编程语言。它所遵循的原则是:注释(为用户和管理者提供帮助);                   功能(执行单个任务且可复用);结构(应易懂,易理解和易维护);文档(有助于                  复用和维护)。

                     脚本技术的分类:线性脚本;结构化脚本;共享脚本(好的技术人员和配置管理系                     统);数据驱动脚本;关键字驱动脚本。

              2.7.3 测试件结构

                     测试件是由测试使用和产生的所有元组成(文档,脚本,输入数据,期望输出,实                     际输出,差异报告,总结报告)。

                     一种有效的方法:建立4种测试件组

                     测试组:一个或多个测试用例,及与该组测试用例有关的所有测试材料,脚本,数                     据,期望输出和文档。

                     脚本组:脚本和文档,所有的脚本,可供重复使用。

                     数据组:只包含数据文件和文档。

                     实用程序组:是被一个以上测试组中测试用例使用的实用程序。

             

              2.7.4 自动测试的前后处理

                     前处理:创建(文件,数据或数据库),校验某些条件是否具备(如有无足够的磁                       盘空间),重新组织文件及转换数据。

                     后处理:删除(文件,数据或数据库,测试结果,副产物),校验(如文件是否存                       在),重组(如把测试结果放到测试件结构中),转换(把输出结果转换成易处理的                格式)。

版权声明:本文为博主原创文章,未经博主允许不得转载。

相关文章推荐

软件测试读书笔记

  • 2008-08-19 14:43
  • 212KB
  • 下载

《软件测试经验与教训》读书笔记(二)

程序错误分析(编写表达BUG报告) 55)错误报告,文如其人。 56)好的错误报告,能推动错误的改正。测试员的责任不是保证所有错误都得到改正,而准确报告问题,使读者能够理解问题的影响。 57)使...

软件测试--读书笔记

  • 2011-03-28 14:14
  • 208KB
  • 下载

探索性测试读书笔记(一)

全局探索性测试方法(用例执行时机,一些用例在特有的场景中将触发难以预料的缺陷)《如何攻破软件》(How to  Break SoftWare)探索性测试的目标:1、理解应用程序如何工作,它的接口看起来...
  • nilxin
  • nilxin
  • 2012-05-03 14:58
  • 5084

代码大全第二版读书笔记 第五部分-代码改善 二十二、开发者测试

开发者测试p499 开发者测试在软件质量中的角色P500 开发者测试的推荐方法P503 测试技巧锦囊p505 典型错误 测试支持工具 改善测试过程 保留测试数据 开发者测试(p499)软件测试一般分为...
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:深度学习:神经网络中的前向传播和反向传播算法推导
举报原因:
原因补充:

(最多只允许输入30个字)