qileilove

blog已经转移至github,大家请访问 http://qaseven.github.io/

测试人员的脑子里到底在想什么

 目前开发人员对测试人员的工作有一些不太理解:用户不可能进行的操作,测试人员非要进行操作,甚至找出一些开发人员都没有想到的操作;有时还设计一些用户没有的流程进行测试;还有时提出一些用户没有提出的要求,比如非要增加一个列表排序功能;测试组的数据库服务器本身就是一台PC机,配置不高,运行复杂程序比较慢,非要提出来要求修改。等等、等等。在开发任务不太忙的时候还能忍受,如果开发任务很紧的时候就容易发生摩擦了。

  测试人员到底是怎么想的?怎么有时总是往牛角尖里钻呢?怎么总是让人搞不懂?后续章节里就简单的说说“测试人员的脑袋里到底在想什么呢?”

  测试人员测试考虑问题基本有几个方面:

“测试人员的脑子里到底在想什么呢?”(一)

  在一个项目中,测试人员与开发人员的良好合作往往起到事倍功半的作用。纵观一个成熟的项目,测试与开发都是紧密合作、相得益彰的。在软件行业说明举例中大家都习惯于用微软IBM、HP等国际大企业来说明,也确实如此,这些大公司都是一些好的借鉴。好像有这么一个规律:凡是做的好的项目,测试与开发的合作也都是比较好的。而在国内一些企业里,由于软件工程发展相对晚一些,这方面的经验比较少,好多项目中测试人员和开发人员经常会发生一些摩擦、甚至冲突,一些有经验的管理人员、开发人员和测试人员还比较好一些,而经验较少的人员表现比较突出,如果再加上一些管理方面不够到位的话这种冲突就比较严重了,有的项目测试人员和开发人员甚至到了互相不能容忍的地步。这不是夸大其辞,确认经历过这样的公司和这样的人,往往是经验越丰富的人员对测试与开发的作用越理解的比较透彻。

  追其原因,主要是因为测试和开发的工作内容虽然相同,但考虑问题的角度却各异。这样有时候站在这个角度看到的问题与另一个角度看到的问题是不相同的。有时这种不相同就会导致争议发生。如果双方都能够站在对方的角度考虑一下就会明白对方为什么要提出这样的问题。但是站在对方的角度来考虑不是说说就能明白的,有时非得亲身体验一回不可,否则还是有一些不理解。更何况对方是怎么想的、原则是什么都不一定能够说的很清楚。

  往往会听到这样的评价:测试人员不知道怎么想的,总是做一些用户不可能进行的操作;我真服了测试人员,不是好好的测试功能,不知道都在想些什么,非要搞一大堆没用的数据录入;我看测试人员故意找茬,本来好好的功能非要钻牛角尖,找出几个没用的BUG来表现自己的水平。等等。

  后续章节就测试人员考虑问题的思想因素做一说明,试图起到抛砖引玉的作用,供开发人员和测试人员来参考。文章中的描述或用词不妥之处也希望大家指出来我尽快更正,提前道谢了!

“测试人员的脑子里到底在想什么呢?”(二)

  系统是否做了该做的事情?还有就是系统是否做了不该做的事情?

  今天,在用户现场的测试人员打电话回来:“我们的系统出现了一个大的问题:通过前台界面修改一条记录没有成功,系统也很正确的进行了提示,可是后台系统却把修改信息发了出去,其他厂家开发的系统接收到消息后同时进行了响应的修改,并且把修改成功的信息发送回来了,可是我们的系统却没有成功修改,导致业务不能正常进行,这样的系统根本就不能放行。”

  这个案例就是一个很好的说明。测试人员在测试的时候首先会考虑系统是否实现了预期的功能-前台界面修改记录不成功进行提醒,但同时还要考虑系统是否做了不该做的事情,在这个案例中就是既然没有修改成功,那就不应该发送消息给其他系统要求修改相关信息。

  这种问题多发生在功能之间的接口或者是多个人开发的系统中。例如在航天史上有名的案例:美国发射火星探测器,整个研发过程都比较严密,但是最终登录失败了。问题的原因就在于系统出现了问题:火星着陆与着陆后出现不衔接。着陆后系统运行应该在着陆的数据基础上运行,而项目研发的时候着陆后的系统运行实在数据清空的基础上运行,根本就没有考虑到实际情况。

  这种情况开发人员与测试人员容易发生争议的地方是:开发人员认为我做的系统或功能没有问题,我已经测试通过。有的还会说当初没有告诉我要这样做,或者是别人没有在我的基础上考虑,或者别人没有给我传送我需要的数据。这时如果项目组织不够好的话测试人员往往要协调多名开发人员或开发团队来解决问题,有如果不乐观的话会吃力不讨好,无人理睬。

“测试人员的脑子里到底在想什么呢?”(三)

  不仅要进行合法性的测试,同时还要考虑非法的是否可以进行。

  测试人员认为合法输入或流程等一定能够正常进行,同时非法的输入或者流程不能够进行,系统应该有所判断并有相关信息提示。为什么要有提示?不一定所有使用系统的人都知道哪些是非法的。

  举个很简单的例子:数据录入的时候,如果没有进行非法检查,一些非法字符进入系统很可能会给以后造成很大的数据错误,比如一些保留字、特殊字符等等。例如在一个文本框中输入一个单引号(‘)成功的话,在数据库中有时执行一条SQL语句的时候会把单引号做为SQL命令而导致SQL脚本执行不成功或者录入错误数据。试想如果在远程紧急救护系统中把紧急抢救时间1分钟错误成10分钟后果会是什么?如果关键时刻系统出现崩溃会是什么后果?那就不是BUG了,是杀人!

  这种情况开发人员往往会说:测试的都是些什么呀?不痛不痒。能不能发现一些重要的、深层的BUG呀?岂不是这个不中要的BUG如果把数据放行进入数据库,后面就会出现重要的、深层的BUG了。有时对这些BUG不置可否。

“测试人员的脑子里到底在想什么呢?”(四)

  健壮性、稳定性

  这是测试人员和开发人员最容易产生争议的问题。测试人员总是从各个角度进行测试,尤其是各个非法操作角度进行测试,测试人员想:不能因为用户的误操作导致系统出错或者崩溃,所以尽量考虑各种非常情况,有的情况开发人员都觉得有点变态了。下面是测试人员和开发人员的一段对话,从中可以看出一些不同点:

  开发人员:“用户输入数据时怎么可能按住键盘不放呢?你这样按着不放能不出错吗?”

  测试人员:“用户是不会故意按着键盘不放的,但是有可能不小心会用手或者书之类的东西压着键盘,如果发生这样的事情,我们的系统总不能崩溃吧?怎么着也应该给个提示或者警告一下。”

  有时候用户是会发生错误的,人吗,误操作总是难免的,如果有了误操作系统就出一点小错,用户还能忍受,如果出打错或者崩溃,用户估计会有意见了。测试人员正式从这个方面进行考虑的。

 易用性

  一般经常与用户接触的人员会对易用性理解深刻,用户觉得操作繁琐会要求系统修改的,上帝不满意了你能不管吗?

  测试人员说了:我操作都感到麻烦,用户会操作的舒服吗?

  这是测试人员对待系统在易用性方面的心态。

  比如测试人员说“在查询结果中增加一个排序功能或者模糊匹配功能吧,要不查出这么多的数据,要找用户要的那个数据太不容易了。”

  “这个增加功能太慢了,我都等的有点不耐烦了!”

  有时这些提示会被开发人员忽略掉的。

“测试人员的脑子里到底在想什么呢?”(五)

  安全性
  (略)

  响应速度、容量、压力负载

  “这个增加功能太慢了,我都等的有点不耐烦了!”如果测试人员觉得时间长,用户也会有这种感觉的,更何况到用户使用的时候数据量可能会更多,随着用户数据量的增加,速度还会下降的。有时测试人员提出有关速度等性能问题的时候就是基于这个思路提出来的。

  尽可能多的发现BUG

  测试人员的职责就是找BUG,尽可能多的发现BUG,不管BUG是严重的还是轻微的,都要提出来。如果有时系统相对稳定或者测试人员不熟悉系统的时候,会发现很多轻微的BUG,比如显示错字、位置不对等等,开发人员会认为这些问题都不是问题而轻视测试人员,从而造成矛盾。

  提前、尽早、不断

  测试人员的原则之一。提前发现问题有助于尽早的解决问题降低成本(时间、人力、金钱等成本),也有助于对系统有全盘的把握。

  不断测试原则比较典型的矛盾是这样:

  开发人员:“能不能一次测试完就告诉我有多少问题?总是没个完。”

  要知道BUG是永远都存在的,不可能一下子发现全部问题的。

  足够好的测试

  测试不是无休止的,所以即使你想进行完全的测试是不可能的,这在好多教科书中都有介绍,再加上测试是有成本的,需要花费时间、金钱、人力资源等成本的,有时过多的测试对企业来说是亏本的,因此测试有一个结束时间。但是总不能在不该停止测试的时候停止,否则系统中包含很多问题怎么办?因此测试既不能过度,也不能过少,进行足够好的测试就可以了。

  这怎么会有矛盾呢?可以看一看开发人员的这句话就明白了:“用户都发现问题了,测试人员怎么不测试了呢?害的我们费这么大劲去修改。”

  管理方式(处理方式)

  有的管理人员对测试认识比较深刻,只要是测试人员发现问题,就要求开发人员必须限期修改完成,而不是对问题进行分析、评估并根据开发人员的工作量进行适当的安排。这样有时开发人员容易与测试人员造成矛盾:这么简单的问题也要提出来,而且这么多小问题,我哪有时间去改那!测试人员也不高兴了,我没有错呀,我都把问题发现了,提前告诉你不是很好吗?要是到了用户那里岂不是麻烦了?我做了好事不但不感谢,反倒成了我的不是了。但是测试人员也不愿意得罪开发人员呀,所以有时矛盾发展结果就成了开发人员与测试人员私下里达成协议:不记录问题,与双方都有利。

  争议处理流程
  (略)

  缺陷处理成本  环节少
  (略)

posted @ 2011-12-01 15:52 顺其自然EVO 阅读(164) | 评论 (0)编辑 收藏

软件Web测试中应用性能测试的探析

 一、引言

  跟着收集手艺的迅速成长,尤其是WEB及其应用轨范的普及,各类基于WEB的应用轨范以其便利、快速,易操作等特点不竭成闻敉件开发的重点。与此同时,跟着需求量与应用规模的不竭扩年夜,对WEB应用软件的正确性、有用性和对WEB处事器等方面都提出了越来越高的机能要求,对WEB应用轨范进行有用的系统的测试也逐渐成为人们研究的主要课题。

  今朝可以见到各类WEB处事器平台,然而按照Mereury的研究陈述,98%的WEB处事器都没能达到人们所期望的机能,平均只能阐扬人们所期望机能的1/6摆布。WEB机能测试能够确定影响WEB处事器机能的关头身分,年夜而可以有针对性地进行剖析和改良,避免WEB处事器研究和优化过程中的盲目行为;同时,它也是拔取分歧的WEB处事器的主要参考。

  跟着WEB应用轨范使用越来越普遍,针对其机能测试的要求也越来越多,然而因为WEB轨范综合了年夜量的新手艺,诸如HTML、JAVA、Javascript、VBScript等,同时它还依靠良多其它的身分,好比Link、Database、Network等,使得WEB应用轨范测试变得很是复杂。例如:WEB压力测试是评价一个WEB应用轨范的首要手段,它的测试就是一个代表性的方面。

  在整个web应用的测试中,机能测试占很是主要位置,因为机能直接纺暌钩了Web应用所供给处事的质量水平。Web应用设计的复杂性和用户使用的不成展望性给若何切确地展望它的机能带来了很年夜的挑战,而且跟着Web应用的规模越来越年夜、用户越来越多,这个挑战变得加倍严重。文中就若何切确地设计负载测试进行了深切研究,提出了对用户导航、用户延迟进行建模的体例来设计负载测试,以使负载测试能够切确地模拟现实用户情形和展望Web应用的机能。最后应用工具loadrunner进行负载测试拭魅战。

  WEB应用轨范的测试有别于传统软件的测试,它有其自身的特点。下面我们进行斗劲深切的谈判。

  二、WEB测试手艺

  (一)WEB应用轨范系统结构

  WEB应用轨范采用B/S结构,它是伴跟着Internet手艺的不竭前进,由C/S结构改良和成长起来的新型系统结构。在这种结构下,用户界面完全经由过程WWW浏览器实现,一部门事务逻辑在前端实现,可是首要事务逻辑则在处事器端实现,形成所谓3tier结构。B/S结构操作不竭成熟和普及的浏览器手艺实现原本需要复杂专用软件才能实现的强年夜功能,并节约了开发成本,是一种全新的软件系统机关手艺。这种结构更成为当今应用软件开发的首选系统结构,今朝最风行的mi?鄄crosoft.net也是在这样一种布景下被提出来的架构。

  传统的软件一般采用C/S结构,此结构把数据库内容放在远程的处事器上,而在客户机上安装响应软件。C/S软件一般采用两层结构,C/S结构在手艺上很成熟,它的首要特点是交互性强、具有平安的存取模式、收集通信量低、响应速度快、利于措置年夜量数据。可是该结构的轨范是针对性开发,变换不够矫捷,维护和打点的难度较年夜。

  (二)WEB测试的内容与目的

  在很多时候我们都把测试的目的定位为寻找软件的BUG,而且是尽可能的找出BUG来,而测试人员所做的工作就是找软件的短处,只要找出短处就可以了,这样很轻易带了一系列的问题。好比测试人员给某网站做测试,并递交了一份简单的测试陈述:“当100用户配合按某提交按钮时,发生年夜量的提交失踪败”。对于测试人员来说,他已经完成了他自己的使命,找出了BUG,可是,这样的测试陈述对于开发人员和项目打点者却毫无用处。陈述中并未说起造成提交失踪败的原因,是硬件资本不足、收集问题、支撑软件参数设置错误仍是应用开发问题等等。

  测试的目的是证伪,但不能片面的理解为简单的找不BUG就可以了。软件测试应该履历以下四个轨范:

  1、测试人员描述发现的问题(找到BUG);

  2、测试人员具体说明是在何种情形下测试发现的问题,搜罗测试的情形、输入的数据、发现问题的类型、问题的严重水平等情形;

  3、测试人员协同开发人员一路去剖析BUG的原因,找出软件的缺陷地址;

  4、测试人员按照解决的情形进行分类汇总,以便日后进行软件设计的时候供给参考,避免往后呈现近似软件缺陷。

  (三)拟定WEB测试打算

  当我们明晰了测试的目的之后,真正起头针对一个WEB应用轨范进行测试的时候,我们需要拟定一套具体的测试计划,这样才能顺遂的完成所有的测试内容,打算的内容归纳为以下几步:

  1、首先对被测的WEB应用轨范进行需求剖析,即对你所做的测试做一个简要的介绍,搜罗描述测试的方针和规模,所测试的方针要实现一个什么样的功能,总结根基文档,首要勾当。

  2、写出测试策略和体例,这里搜罗测试起头的前提,测试的类型,测试起头的尺度以及所测试的功能,测试经由过程或失踪败的尺度,竣事测试的前提,测试过程中碰着什么样的情形终止和怎么措置后恢复等。

  3、确定测试情形的要求(搜罗软件和硬件方面),选择合适的测试工具。

  4、首要针对你测试的行为,描述你测试的细节,搜罗测试用例列表,进度表,错误品级剖析,对测试打算的总结,和在测试过程会呈现的风险剖析等。

  (四)测试的类型

  WEB测试的类型搜罗内容测试、界面测试、功能测试、机能测试、兼容性测试、平安性测试等情形。内容测试、界面测试和兼容性测试都斗劲简单,在此不再细谈。WEB的功能测试与传统的软件测试区别不年夜,主若是在毗连测试方面有点区别,数据的传递方面会稍微复杂点。因为WEB软件都是采用B/S结构,客户端所需的处事都是由处事器供给的,所以主若是测试处事器上软件运行的机能。WEB应用轨范的测试搜罗客户端毗连处事器速度方面的测试和压力测试这两方面,机能测试的轨范:

  第一,剖析产物结构,明晰机能测试的需求,搜罗并发、极限、设置装备摆设和指标等方面的机能要求,需要时基于LOAD测试的不异测略需同时考虑不变性测试的需求。

  第一,剖析应用场景和用户数据,细分用户行为和相关的数据流,确定测试点或测试接口,列示系统接口的可能瓶颈,一般是先主干接口再支线接口,并完成初步的测试用例设计。

  第三,依据机能测试需乞降确定的测试点进行测试组网设计,并明晰分魄鬃曾方案的主要水平或优先级作为取舍评估的依据,需要时在前期产物设计中提出撑持机能测试的可测试性设计方案和对测试工具的需求。

  第四,完成机能测试用例设计、分类选择和依据用户行为剖析设计测试规程,并筹备好测试用例将用到的测试数据。

  第五,确定采用的测试工具。

  第六,进行初验测试,以主干接口的可用性为主,按照测试结不美观剖析机能瓶颈,经由过程迭代保证根基的指标等测试的情形。

  第七,迭代进行周全的机能测试,完成打算中的机能测试用例的执行。

  第八,完成机能测试评估陈述。

  在进行机能测试的时候,我们需要知道一些有用的机能指标,下面我们来列出一些首要的机能指标:

  一是,通用指标(指Web应用处事器、数据库处事器必需测试项):

  ● ProcessorTime:指处事器CPU占用率,一般平均达到70%时,处事就接近饱和;

  ● Memory Available Mbyte:可用内存数,如不美观测试时发现内存有转变情形也要注重,如不美观是内存泄露则斗劲严重;

  ● Physicsdisk Time :物理磁盘读写时刻情形。

  二是,Web处事器指标:

  ● Avg Rps:平均每秒钟响应次数=总请求时刻/秒数;

  ● Avg time to last byte per terstion(mstes):平均每秒营业剧本的迭代次数;*Successful Rounds:成功的请求;

  ● Failed Rounds:失踪败的请求;

  ● Successful Hits:成功的点击次数;

  ● Failed Hits:失踪败的点击次数;

  ● Hits Per Second:每秒点击次数;

  ● Successful Hits Per Second:每秒成功的点击次数;

  ● Failed Hits Per Second:每秒失踪败的点击次数;

  ● Attempted Connections:考试考试链接数。

 三是,数据库处事器指标:

  ● User 0 Connections :用户毗连数,也就是数据库的毗连数目;

  ● Number of deadlocks:数据库死锁;

  ● Butter Cache hit:数据库Cache的射中情形。

  (五)测试工具介绍

  1、ACT(或者MSACT)。ACT是微软的Visual Studio 和Visual Studio.NET带的一套进行轨范测试的工具,ACT不单可以记实轨范运行的具体数据参数,用图表显示轨范运行状况,而且安装和使用都斗劲简单,结不美观阅读也很便利,是一套较理想的测试工具。

  Microsoft Web Application Stress Tool (WAS):这个工具和ACT一样是微软的产物,可是这个工具没有和Visual Studio集成,可以零丁使用。感受这个轨范此刻还在测试,可是一些根基的功能已经很完整,可以完成ACT几乎所有功能,而且WAS使用加倍简单,设置也加倍完整了然。这个工具的此吐矣闽特点是,它的报表是纯文本文件,而不是风行的HTML文件名目,但内容方面一点也不减色。

  2、Open System Testing Architecture (OpenSTA)。OpenSTA的特点是可以模拟良多用户来访谒需要测试的网站,它是一个功能强年夜、自界说设置功能完整的软件,但这些设置年夜部门需要经由过程Script来完成,是以在真正的使用这个软件之前,必需进修好它的Script编写。如不美观需要完成很复杂的功能,Script的要求还斗劲高,当然,这也是它的利益,一些轨范员不会在意这些Script的。这个软件完全免费而且源代码可以下载,可以自己改削达到特定的要求。

  3、PureLoad。PureLoad是基于Java的测试工具,它的Script代码完全使用XML,所以这些代码的编写很简单,它的测试报表包含文字和图形并可以输出为HTML文件。因为是基于Java的软件,所以可以经由过程Java Beans API来增强软件功能。

  4、QALoad。QALoad不单单测试WEB应用,还可以测试一些后台的工具,好比SQL Server等,只若是它撑持的和谈,都可以测试;此外一点,QALoad不单可以测试Windows,而且可以测试AIX, HP-UX 和 Solaris等系统。可是,这款软件价钱很高。

  5、LoadRunner。Mercury LoadRunner是一种展望系统行为和机能的负载测试工具。经由过程以模拟上万万用户实施并发负载及实时机能监测的体例来确认和查找问题,LoadRunner能够对折个企业架构进行测试。经由过程使用LoadRunner,企业能最年夜限度地缩短测试时刻,优化机能和加速应用系统的发布周期。

  对于财年夜气粗的年夜公司而言,这款软件可能斗劲适合,它的功能和QALoad对比八两半斤,市道上驰誉的公司如IBM、SUN、Oracle等都用这个软件。可是它的价钱也高不成攀,和功能成正比。

  三、进一步的工作与谈判

  跟着周全质量打点思惟在软件开发规模的应用和不竭向前推进,软件测试也由最初的仅仅针对软件制品扩展到了针对软件半制品甚至过程产物的全过程测试,这是对软件测试的一种必然扩充。WEB测试也会跟着这一思惟,不竭地扩展到WEB软件的各个生命周期中去,这将使WEB应用轨范取得更高的质量,这也是我们往后需要进一步研究的内容。出格是对WEB压力测试自顺应模子的试探才刚刚起头,有良多不足之处,例如:今朝的测试人机交互较多,而自动完成的轨范较少等,这些都有待日后的改良。

  除了前面介绍的WEB压力测试外,今朝WEB测试的首要研究热点还有:WEB应用测试的框架研究,WEB应用轨范测试的对象模子研究及其应用,WEB测试的高度自动化研究等等,都将是未来一段时代内的研究重点。

posted @ 2011-12-01 15:50 顺其自然EVO 阅读(203) | 评论 (0)编辑 收藏

实时控制软件的质量

 如何确保嵌入式实时控制软件的质量?对这类软件的生产过程如何进行有效的质量控制?这是一个重要的研究课题。为解决软件危机而产生和发展起来的软件工程成功地解决了软件开发中存在的许多问题。它不仅对软件开发、设计和生产有直接影响,而且对提高软件质量有显著成效。实践表明,使用软件工程方法,可达到一般的质量要求。但当软件质量要求更高时,则必须在实施软件工程的同时,采取一些专门的可靠性工程技术和方法,以保证需求的可靠性。

  软件工程是指按照工程的规律来组织软件的生产与开发。软件工程化要求以软件质量控制为核心,紧紧抓住软件生产方法、需求分析、软件设计、软件生产工具、测试、验证与确认、评审和管理等8个主要环节(图1)。

  软件生产方法

  软件是产品。从产品的意义上说,所谓软件开发应为软件生产。软件应采用工程化、结构化和规范化方法进行生产。软件工程化是指使用软件工程的理论、技术、要求和管理等来规范软件开发过程中的全部活动。硬件生产已有一套成熟的工程化方法,软件要向硬件学习,使软件硬化,把软件看作是软件工厂中的产品。

  软件规范化是指在软件生存周期中,软件的生产活动必须严格遵循各项软件规范和标准。经验证明,没有规范就没有产品,也就没有软件。执行规范必须动真格。执行规范工作量是大些(工作量主要在文档、审查、验证、评审和管理上),但受益却是明显的。由于软件开发过程规范提高了软件质量,这样不仅减轻了损失,而且还促进了软件的生产进度,提高了软件的生产率。

  软件结构化是指软件生产过程中采用了结构化分析和结构化设计方法。

  软件需求分析

  软件需求分析的目的是使软件设计人员和用户之间进行全面和深入的沟通,以明确用户所需的究竟是一种什么样的软件。需沟通的主要内容有:将要开发的软件所涉及的概念、定义、目标、指标、功能、控制逻辑、算法、环境、时序、执行过程和特点等。通过需求分析产生的软件规格说明书是此后软件设计、调试和测试工作的基础,是软件评审、鉴定和验收的依据之一。因此,需求分析是软件生产中的一个首要步骤。一份软件规格说明书的质量优劣,一方面取决于需要分析深入的程度,另一方面取决于系统分析员刻画软件需求的正确性、完整性、合理性和一致性达到的程度。

  众所周知,软件怕修改,更怕需求变更。原因在于:

  ● 软件修改的工作量大,关键软件的任何修改,必须经历一个调试、测试、验证与确认的步骤。

  ● 花费的代价高,经试验考核过的软件,又要更改软件需求,即使是只改了一个参数,也需要对更改的软件作重复考核。有的实时控制系统一次试验的代价是相当大的。

  ● 软件修改的牵涉面广,往往有牵一发而动全身的问题。尤其是由多个分系统组成的系统(例如军事指挥的C3I系统),任何·一项修改均要考虑是否会影响其他的分系统。

  软件可靠性需求分析要求全面、细致和深入。

  不难看出,软件需求分析的过程,也是软件设计方案的酝酿过程。通过分析应得出用户需求的正确性、合理性和完整性的结论;同时,也应得出软件付诸实现的可行性、可靠性和安全性的结论。软件需求分析的衔接关系见图2。





软件设计

  软件也和硬件一样,它的质量是设计出来的,生产出来的。其中,设计对软件质量具有关键性的影响。设计的重要性可从图3看出,其中(a)为经历了设计步骤后的效果,在软件使用和维修阶段,软件的问题少;反之,(b)为跳过设计步骤,到了使用和维修阶段,软件问题成堆,到了不可收拾的地步。基于这种情况,应强调:软件设计未完成,不得转入软件编码阶段。

  良好的软件设计与所采用的软件设计方法、设计工具和设计准则有关。软件设计方法主要有面向数据流的设计、面向对象的设计和面向数据的设计方法等。这些方法均有其优缺点和不同的应用领域。目前,大多数嵌入式的实时控制软件使用的是面向数据流的设计方法。该方法的目标是以一种全局的软件观点和体系结构设计的角度派生出程序结构。

  面向数据流的设计又称为结构化设计。它强调模块化、层次化和自顶向下等设计思想。这些思想的根本目的是对复杂问题的解决采用一个简化过程以获得满意的答案。通过这种简化,纵有千头万绪也能理得清清楚楚。一个设计准则是要将复杂的问题简化,切忌将简单的问题复杂化。好的程序设计语言,无疑对设计高质量的软件是有益的。例如,Ada语言,与一般语言比较,它所特有的一些语言成分旨在突出软件可靠性和安全性,便于软件维护,便于实行程序的层次式管理和提高程序的易读性、高效性等。

  软件可靠性设计主要将软件的检错、避错、容错和异常处理技术灌输到软件设计中去,设计时应处处关心:

  ● 控制逻辑的完整性;

  ● 软件与硬件、软件与软件界面之间的协调性;

  ● 人机交互的有效性;

  ● 信息交换的正确性;

  ● 设备控制的安全性;

  ● 时序控制的合理性;

  ● 数学运算中变量定义域的合法性。

  软件生产工具

  软件生产的主要工具是软件试验台(Software Testbed)或软件开发平台。在软件需求分析的同时,就要考虑到这类软件开发环境的创造。它应满足下列要求:

  (1)它的组成、结构、性能、功能和工作的方式与状态,力求与实际系统一致。优点是:

  ● 它与实际系统出现的故障现象是一样的,便于故障隔离。

  ● 软件试验台与实际系统的软件可彼此互相复制,便于软件开发过程交替上升。

  ● 具有互补性,试验台有局限性的问题可在实际系统解决;实际系统上有困难的,代价太大的检测活动可在试验台上进行。

  (2)配上多媒体工作站,提供软件测试过程中综合信息的显示和生产真实工作环境中的音响效果。

  (3)配备实时数据采集器。

  (4)能支持实时与非实时两种运行方式的调试活动。

软件试验台是辅助软件调试、测试、试验和验证的重要工具。在某种程度上可以得出这样的结论:没有软件试验台就不能顺利地开发出实时控制系统软件。原因在于:

  (1)这类复杂的软件在实际系统上开发是不可能的,其代价太大,效率太低,效果太差。

  (2)软件开发是个做细致研究、分析和不断探索的过程,软件试验台能适应这种工作方式。

  (3)它是软件编程、调试、测试、集成和试验的综合环境。

  (4)它是支持软件原型化开发方法的重要手段。

  一般来说,实时控制系统软件的第一个原型是在软件试验台上开发出来的。有了软件原型,就有了与用户深入讨论、分析和确认软件需求的基础。实践证明,经过软件试验台测试通过的软件,基本上能用于实际实时控制系统的系统联调、测试、试验和系统验收。

  软件测试

  从软件生存周期看,软件测试是卡住软件质量,尤其是卡住软件可靠性的最后一道关口。但软件测试并不仅仅局限于这个阶段,而应贯穿于软件开发的全过程(见图4)。应解决这样一个认识问题——用于实时控制系统一类的复杂软件,自认为没有错误的想法是不切合实际的。因此,测试的主要目的是:

  1)对软件的质量或可接受性作出判断;

  2)发现问题。

  从图4看出,会产生错误的阶段是在需求说明、设计和编程过程中。这些错误若不排除,均会遗传到测试阶段,甚至会遗传到使用阶段。利用测试用例测出问题进行故障分类、故障隔离和故障消除等步骤,直到获得满意的测试结果为止。

  测试用例的编写格式和内容如图5所示。测试的设计。难就难在试图利用这组测试用例能找出软件的全部问题。格式中含有测试管理信息——测试用例标识和执行史。测试用例标识是按一定规律统一为每个测试例赋予的代号,便于需求追踪。执行史中有测试日期、测试结果(给出结论:通过/失败)、版本号和主管的测试者签字,这些都是有保存价值的资料。测试用例是需要精心设计、编写、评审、使用、管理和保存的。


  软件测试要求在测试过程中,采集软件可靠性数据,并利用软件可靠性模型进行可靠性评估。分析其是否达到了预期的可靠性要求。并据此作出该软件能否放行的决断。若不满足要求,需继续进行测试,直到满足要求为止。可见这是一项十分花精力的活动。

 软件验证与确认

  软件验证(Verification)和确认(Validation),简称为V&V 或V2。验证和确认的区别在于:验证关心的是确保软件模块或功能内在的正确性;确认则表明要与规定的需求进行比较是否满足要求,它所关心的是该软件产品的价值。

  软件验证与确认是贯穿于软件开发过程中十分细致的软件检验活动。每个开发阶段的结果可认为是下一开发阶段的一个规格文件,但要进入下一阶段之前必须对该结果作出确认。验证和确认的主要方法有:代码走查、审查、测试和正确性证明等。代码走查就是对软件文档进行书面检查。它通过人工模拟执行源程序的过程,检查软件设计的正确性。人工模拟也像计算机执行那样,可以仔细推敲、校验和核实每一步的执行结果,进而确定其执行逻辑、控制模型、算法和使用参数与数据的正确性。

  审查是软件验证和确认中的一个主要方法,可弥补其他方法的一些不足之处。它是一种用形式的、有效的和经济的方法查找设计和编程中的错误。审查的主要目的是1)找出软件中的缺陷;2)核实是否符合需求;3)早期生产评价;4)过程评价等。由第三方进行软件评测工作是十分重要的,其评测工具软件对软件进行静态的和动态的评测,能发现软件设计的缺陷、瓶颈和多余物等。值得指出的是,用于软件测试的各种方法、技术、工具和措施等,对提高软件的可靠性都是必要的,但不是充分的。这就表明,其中任何一个手段,均不能绝对保障软件的可靠性,但只要能发现软件中任何一个微小的错误,就起到了它的作用。

  软件评审

  从某种意义上说,软件中的多数错误是人为的。软件评审是软件生产过程中过滤软件错误的一个“滤波器”。软件评审涉及评审的组织机构、管理、准则、类别、内容、文件和要求等。

  一般要求在软件研制阶段的里程碑点进行软件评审。评审的主要类别有:软件定义评审、软件需求评审、概要设计评审、详细设计评审、软件实现评审和软件验收评审等。

  评审的原则:

  ● 某阶段未通过阶段评审不得进入下一个软件研制阶段;

  ● 评审时对事不对人,评审的是产品,而不是评审生产者;

  ● 评审就要挑刺,找问题、缺陷和隐患;

  ● 评审组的人员面越广越好;

  ● 评审组不作无休止的争论和辩驳,将争论点记录下来,供以后甄别;

  ● 评审只是提出问题,没有解决问题的任务;

  ● 使用“评审检查单”以提高评审的效果;

  评审的作用:

  ● 技术把关,避免软件人员的想当然;

  ● 概念沟通,吸收用户和总体人员参加,审查软件人员理解的正确性;

  ● 集思广益,吸收有关的分系统人员参加,从不同侧面确认软件的协调性;

  ● 总结汇报,使实时控制系统总指挥、总设计师了解软件生产的进度、问题和要求,作出新的部署。

  评审很容易走过场、走形式。评审效果的好坏,与当事人(软件人员)密切相关。基于有问题才需要评审,不能轻信自己的软件,导致对评审产生对立情绪。对评审出的问题进行整理、分类和汇总,不忽视任何一个细小的疑点。

  软件管理

  科学的管理能够出可靠性、出效果、出效益。软件的管理工作不完善、不严格,是引起意外事故的原因之一。软件管理主要包括软件项目管理、软件配置管理、软件可靠性管理和软件质量管理等方面。

  软件项目管理的内容包括软件开发过程管理、软件可靠性度量、风险管理(包括风险分析和估计)、确定项目任务、建立可操作的工程计划等。软件项目管理是软件管理工作的第一层。需要强调的是,它不是一个阶段,也不仅仅是个步骤,而是贯穿于整个软件开发工程中的一个层次。从其管理内容来看,这是一种十分重要的管理工作。其管理的好坏,直接影响产品的质量。这项管理尚处于起步状态,是个薄弱环节。软件配置管理是软件人员和管理人员确定、组织和开展软件修改的手段,目的是在软件修改过程中设法少犯差错来最大限度地提高软件产品的生产率。软件配置管理涉及软件配置项和基线的确定。

  软件配置项可理解为在软件生产的某个阶段应具备的软件文档和保存软件的介质等。软件基线(基准)又称里程碑。软件配置项经软件验证、确认、评审和认定后,形成了软件基线,也就成了该阶段的一个基准。下一个阶段只能在这个基准上进行开发活动。

软件配置管理要求:

  ● 软件修改必须遵循软件更改规范;

  ● 未经批准的更改,任何人无权修改;

  ● 更改后必须测试、验证和确认;

  ● 软件验收,必须对相应的软件进行评审。

  具备评审的条件包括:相对该基线的软件配置项齐全、有测试结果和测试分析报告及软件优化报告。

  文档管理是一项十分艰巨而又琐碎的工作,要求:文档编写必须规范、文实相符、文文相符、描述具有一致性、确切性和简明性、签署完整、职责明确。软件可靠性管理作了一些初步的尝试。在软件生产过程中,设计了软件可靠性数据采集表格。对软件中的需求、模型、设计、编码和定义域等方面的错误均要填表。填写产生该错误的时间(计算机执行的累计时间)、错误性质、出错原因和排除错误的结果等。

  主要问题与解决方法

  对实时控制系统软件工程化的重要性的认识尚处于起步阶段,重视程度也不平衡。主要问题:

  (1)部分系统的软件开发由硬件人员承担。硬件、软件、模型设计均由一个组完成,仍是典型的“自编、自导、自演”小作坊的工作方式。

  (2) 还不太习惯于软件工程化、规范化、结构化和模块化的软件生产方法。往往跳过了软件设计阶段,而是先有编码,为了软件检查才补设计。

  (3)缺少配套的软件测试工具。试图利用实时控制系统进行软件的调试、测试、验证、确认和试验工作,这样的软件测试必然是不完整的,也是有局限性的,更是不科学的。

  (4)实时控制系统软件可靠性工程的研究是自发的,未纳入实时控制系统研制计划,影响这项工作的深入开(5)需要解决实时控制系统软件工程化方面的若干模糊认识:

  ● 软件就是编程;

  ● 没有测试工具照样可以开发出软件;

  ● 舍不得在软件可靠性上化成本;

  ● 出了问题,才发现软件似乎比硬件更重要。

  (5)实时控制系统软件可靠性指标不好定。原因是软件可靠性的评估涉及模型、方法、工具和条件等问题。当前,要求软件的可靠性为100%,对软件是不公正的,也是过于苛刻的。

  建议

  (1)软件可靠性工程也是一项涉及面很广的系统工程,应加强这项技术的研究力度。尤其要结合具体实时控制系统设置研究课题,使实时控制系统软件的生产过程同时也是软件可靠性工程的实施过程。使自发的可靠性工作成为有计划、有组织和有目标的研究工作。

  (2)适用于嵌入式计算机的实时软件,例如实时操作系统、Ada语言等,应像美国国防部那样,要强制推行。

  (3)计算机技术发展很快,软件技术及软件可靠性工程技术也发展很快,应对重点实时控制系统的软件人员定期组织培训。

  (4)为了解决软件生产的小作坊问题,可否考虑逐步推行实时控制系统软件人员考核制,作出资格认证。



posted @ 2011-12-01 15:47 顺其自然EVO 阅读(135) | 评论 (0)编辑 收藏

测试活动中如何应对关键风险

 测试关键风险指的是在测试活动中发生的对测试进程和测试结果又重大影响的阻碍性问题和突发事件。

  这一轮的转测试版本,有新的测试需求。需要所有的测试员都学会搭建一个比较复杂的测试工具。而且这个步骤是整轮测试的关键点。如果没有正确配置,整个测试进程都会停滞。

  在配置方式完全正确的情况下,配置好此工具的时间需要2-3个小时。然而目前要验证工具是否配置正确的唯一方式就是执行基础测试用例,此用例执行完成下来需要花费1-2个小时。也就是说一次的配置不正确,花费的代价就是4到5个小时。一天的工作时间包括加班也就10个小时。如果两次都出现错误,一整天的时间就浪费了。而且此工具的配置还因为测试场景不同配置方式也有部分差异,所以每个测试员所需要面对的问题都会不一样。

  目前手头上有的资源就是一份配置说明(不包含每个场景的细节配置),一个有过成功配置经验的老员工。下班后测试经理组织培训,叫一个有此工具配置经验的老员工给大家讲解配置步骤,要求大家必须在2天内都能上手。测试员培训完以后发现这个任务存在很大的风险,并且不可控。整个的转测试时间只有6个工作日,按照正常的版本测试周期,5天再加上每天加班3个小时,基本可以按时完成任务,突然冒出这么个复杂的东西,根本无法完成任务。因为多个场景可以同时配置,有测试员提议:找专人来负责。测试经理答曰:“找你你愿意干嘛?要是找我,我肯定不干,我付不起责任。”

  碰见这问题,测试经理关注的是不可控风险对整个测试进度和测试质量的影响,测试员关注的则是对自己任务进度的影响,延时以后可能会有更多的加班,原本有10个功能点要验证,应为赶进度只验证了9个,发生漏测!

  测试经理站在全局角度可以要求测试员必须在2天之内学会配置,但是真的在2天之内所有测试员都能学会吗?在转测试之前,测试经理和TSE没有对新的测试需求进行详细分析,没有评估新的测试需求包含的风险,没有详细的了解员工对新测试需求的理解和掌握程度,没有参考测试员对技能的掌握来设定任务时间。

  个人认为,在以后的转测试之前,测试经理一定要详细的分析每一项新的测试需求,及时的将新需求达到每个测试员,务必要详尽的罗列此出存在的风险项,结合测试员对新需求的掌握和理解程度来确定风险的大小,再根据风险的可控性来适当的延长测试时间,并且及时的对薄弱环节进行加强培训。当风险发生以后要及时的做出评估和分析,分析风险发生的原因找出解决方案,评估风险对测试进度和质量的影响,结合实际情况确认是否需要调整测试方案。

  风险发生后,测试员需要积极的面对,参与分析给出自己的意见,不能推卸责任。测试经理不能盲目的施加压力,测试员压力的大小也会直接影响到测试质量。还有一点,作为一个测试经理,必须要担负起责任,对于风险,测试员有责任,但更大的责任在于测试经理,是你没有事先没有充分分析,才导致风险发生。你付不起责任谁负责任?大家共同的在做同一件事情,测试经理在带头,大家走错路了,最大的责任肯定在测试经理。大家团结一条心才能顺利的度过各种难关,达到零漏测的目标。

posted @ 2011-12-01 15:28 顺其自然EVO 阅读(131) | 评论 (0)编辑 收藏

测试活动中如何应对关键风险

 测试关键风险指的是在测试活动中发生的对测试进程和测试结果又重大影响的阻碍性问题和突发事件。

  这一轮的转测试版本,有新的测试需求。需要所有的测试员都学会搭建一个比较复杂的测试工具。而且这个步骤是整轮测试的关键点。如果没有正确配置,整个测试进程都会停滞。

  在配置方式完全正确的情况下,配置好此工具的时间需要2-3个小时。然而目前要验证工具是否配置正确的唯一方式就是执行基础测试用例,此用例执行完成下来需要花费1-2个小时。也就是说一次的配置不正确,花费的代价就是4到5个小时。一天的工作时间包括加班也就10个小时。如果两次都出现错误,一整天的时间就浪费了。而且此工具的配置还因为测试场景不同配置方式也有部分差异,所以每个测试员所需要面对的问题都会不一样。

  目前手头上有的资源就是一份配置说明(不包含每个场景的细节配置),一个有过成功配置经验的老员工。下班后测试经理组织培训,叫一个有此工具配置经验的老员工给大家讲解配置步骤,要求大家必须在2天内都能上手。测试员培训完以后发现这个任务存在很大的风险,并且不可控。整个的转测试时间只有6个工作日,按照正常的版本测试周期,5天再加上每天加班3个小时,基本可以按时完成任务,突然冒出这么个复杂的东西,根本无法完成任务。因为多个场景可以同时配置,有测试员提议:找专人来负责。测试经理答曰:“找你你愿意干嘛?要是找我,我肯定不干,我付不起责任。”

  碰见这问题,测试经理关注的是不可控风险对整个测试进度和测试质量的影响,测试员关注的则是对自己任务进度的影响,延时以后可能会有更多的加班,原本有10个功能点要验证,应为赶进度只验证了9个,发生漏测!

  测试经理站在全局角度可以要求测试员必须在2天之内学会配置,但是真的在2天之内所有测试员都能学会吗?在转测试之前,测试经理和TSE没有对新的测试需求进行详细分析,没有评估新的测试需求包含的风险,没有详细的了解员工对新测试需求的理解和掌握程度,没有参考测试员对技能的掌握来设定任务时间。

  个人认为,在以后的转测试之前,测试经理一定要详细的分析每一项新的测试需求,及时的将新需求达到每个测试员,务必要详尽的罗列此出存在的风险项,结合测试员对新需求的掌握和理解程度来确定风险的大小,再根据风险的可控性来适当的延长测试时间,并且及时的对薄弱环节进行加强培训。当风险发生以后要及时的做出评估和分析,分析风险发生的原因找出解决方案,评估风险对测试进度和质量的影响,结合实际情况确认是否需要调整测试方案。

  风险发生后,测试员需要积极的面对,参与分析给出自己的意见,不能推卸责任。测试经理不能盲目的施加压力,测试员压力的大小也会直接影响到测试质量。还有一点,作为一个测试经理,必须要担负起责任,对于风险,测试员有责任,但更大的责任在于测试经理,是你没有事先没有充分分析,才导致风险发生。你付不起责任谁负责任?大家共同的在做同一件事情,测试经理在带头,大家走错路了,最大的责任肯定在测试经理。大家团结一条心才能顺利的度过各种难关,达到零漏测的目标。

posted @ 2011-12-01 15:28 顺其自然EVO 阅读(141) | 评论 (0)编辑 收藏

对软件测试工作的反思

 我这个人做完一件事情喜欢反思和总结,这个习惯一直保留着。在测试部做了两个月,虽然我对测试还是门外汉,只做了一些具体工作,但忍不住把自己的想法写了个系统文章,其实提意见我的看法是领导一般不反感,只要你的意见系统,有建设性,不针对个人攻击就好。

  下面就是我当时写的对测试工作的反思,有些是参考了一些资料,结合自己总结写的。

软件测试工作的反思

  测试人员的配置:测试人员必须包括三类人,专业测试人员,熟练测试人员和对软件完全不熟悉的新人。专业测试人员主要负责测试规划和测试大纲,极限测试环境设计,熟练测试人员主要负责按规定完成大纲测试,属收敛性测试,新人主要负责易用性和界面合理性测试,属发散性测试,发现的各类问题由专业测试人员分析并给出解决对策。

  测试文件的准备:提前准备好软件测试需要的图、工艺文件,OFFICES,TXT,其它CAD设计文件测试标准文件,而不是临时去找

  测试软件的准备:应该提供不同的操作系统数据库平台测试环境,必要的话提供多台测试机器,减少人工浪费在安装环境上的时间。

  测试机器的准备:应给测试人员配置相对好的机器,以提高测试速度和效率,同时一定要配置相对差的机器,模拟在用户现场极端运行环境和速度。

  业务测试的准备:(针对当时软件测试主要是功能测试的情况)应该设计大量的业务测试流程,流程可以从开发,市场,实施部门配合,给予解决。

  测试阶段的划分:应该分开发测试(非常反感开发不懂操作,也不自行测试就提交测试人员验证的模式),功能测试,极限测试,BUG测试(主要是测试历史环境下有记录的BUG),现场测试(主要是易用性和测试业务流程)

  对测试大纲的意见:

  1、测试内容不全面,缺少测试文件样例,测试软件版本号

  a)很多软件存在的功能测试大纲没有涉及,我自己把只要能够用的功能都测试了一遍,超出了规定测试大纲的内容,发现了很多新错误,当时公司测试水平也确实有限,所谓软件测试就是两个临时员工负责。

  b)软件功能之间组合连续测试不完善,很多功能单独是好的,但如何把管理软件功能串合起来用的测试流程不清晰,需要测试人员自己发挥

  2、极端环境测试得不够

  对空数据,大数据,大量网络并发等环境下测试很不够,往往这个时候能测试出很多问题,例如软件运行效率

  3、对误操作或非法操作给系统带来的影响测试大纲无体现

  测试大纲都是要求你如何如何操作,应得到何种结果,但问题是用户不一定会这样操作,但我这里随意操作常常造成死机,这也是我对测试大纲很不满意的,软件应该做到即使是用户误操作系统有提示或者没反应,而不是死机,更不是要求实施人员去培训正确的操作。

  4、测试动作量化不够

  例如同一功能测试次数,测试频率,测试速度都应有规定,例如某一功能测试100次,可能才出现一次BUG,如果只测试10次可能就是OK的,或者连续使用10次就会出现BUG,但单独使用没问题,这些应该也体现的测试大纲,而不是让测试人员自己去测。

  5、测试中对开发人员的开发功能逻辑了解不够,无法自觉测试潜在的功能缺失和冲突或干扰(后来我才晓得这叫白箱测试)

  6、对软件的宜人性,友好性,WINDOWS下程序风格一致性,简洁性没有任何评估

  7、没有以用户层面对设计的功能和动作进行挑剔。

  8、缺乏软件测试质量保障体系(后来开目花了大力气建设了测试体系,通过CMM3级评估)

  9、没有单位时间内任意测试过程中死机纪录,只测功能的实现性,没有系统稳定性指标,实时性,同步性等效率量化指标

  10、没有参照软件的对比测试

  11、没有前期积累的测试文献

  12、测试工作不应该仅仅成为开发的完善工具,还要承担一部分探索开发方向的作用,甚至一定程度上和开发交融(这个观点我现在不支持,要求太高了,主要是当时我对自己测试太有信心了)

  测试目的:

  1)检查出软件中的功能设计不足或BUG以保证能满足用户正常使用

  2)在说明书中明确一些常见错误操作以防止用户误操作或给出解决方法

  3)对一些一时难以解决的难点,导致的问题给用户一个解释或变通的方法

  根本目标:

  保证开目软件的易学易用稳定的优势,以优质产品占领市场,赢得口碑。

posted @ 2011-12-01 15:25 顺其自然EVO 阅读(194) | 评论 (0)编辑 收藏

测试过程中的评审工作及关注事项

测试过程中的评审工作及关注事项

公司的软件开发EPG过程规范中对测试领域的工作及其规范做了细致的说明,虽然是CMMI3+,不过还是有些地方只是官样文章,是形而上的东西,在实际工作中不具备任何的指导作用。所以我们领导觉得这个可以自己重新定义一些在测试思维上较为技术性的东西纳入到测试领域的规范当中,而我负责关于用户需求评审系统测试用例评审的检查点整理工作。由于用户需求评审能够有助于测试人员系统测试工作的开展,所以下面就用户与需求评审所需要准备的工作、用户需求评审时所要思考的问题、系统测试用例评审过程中所需要考虑的一些检查点进行简单的列举。这些内容都是个人经验总结,并不能应用于所有类型的系统,所以请不要拿来硬套,因为不同行业、不同类型的系统特征是不同的,我所关注的只是我所负责的保险系列业务系统。

  用户需求评审准备工作

  》向用户或者BA/SA索取原始需求文档;

  》仔细阅读需求文档,大致估算系统改动;

  》向开发人员了解预计的开发工作量,并且相互印证系统改动的估算;

  》了解需求排期,预估测试所需人力,估算时需要考虑关联影响测试;

  》了解相同和接近的版本周期内的其他需求和版本,预估测试环境和人力是否足够,如果有可能资源不足则及时升级并且邀请测试经理参与需求评审会议。

  用户需求评审问题清单

  》本需求提出的背景:现有功能有什么样的问题、由什么市场、行业的变化所导致?

  》本需求所要实现的目标:操作流程简化、业务成本降低或者客户满意度提高等等?

  》本需求是否有前置和后续需求排期?其优先级是否合理,实现情况分别是怎样的?

  》本需求的内容是否会与现有业务逻辑或者系统逻辑的冲突?如果有,该如何解决?

  》本需求所包含内容是否有冗余:与现有某些系统功能或流程重复,造成重复开发?

  》本需求是否有足够的资源去实现,包括测试人力、开发人力或者测试环境等资源?

  》本需求完成之后的效益是否足够抵消其在IT版本的成本投入?是否可能会出现在这个需求上“得不偿失”或者说“入不敷出”的情况?

  》本需求用户验收测试有什么样的案例?对应的数据类型和数据量的需求是怎样的?

  》本需求的UAT所需要的时间应该有多少?用户是否有足够的测试人力投入?IT应该保证的最短UAT时间需要多少天?

  》UAT人员是否有就此需求测试的其他特殊要求或疑问?如果有,这些要求是否合理、是否有必要、是否需要IT同事支持或者是否有变通解决方法?

  系统测试用例评审关注点

  》用例描述、操作步骤、预期结果和数据使用等信息是否准确、完整、无歧义;

  》用例是否包含了足够多的业务类型分支或数据场景分支;

  》用例中是否设计了操作源表包含百、万、百万甚至亿级数据,结果集输出包含十、百、千等不同级别的数据场景,对其性能是否可接受是否有可行的验证方法;

  》用例是否考虑了用户使用的频率,若使用非常频繁,那么是否需要做并发测试;

  》被测功能是否为无操作界面的系统自动任务,若无操作界面,那么用例中是否考虑了用户测试的方法;若有界面,是否有界面规范性性检查测试用例(CQ中有界面变更项为是的需求);

  》对于查询、报表类功能:

    >> 用例设计是否包含对查询结果完整性、显示格式、排序等方面的检查;

    >> 用例是否包含足够的必输项和页面控制的检查,空值查询的数据库消耗是否正常;

    >> 用例对不同查询条件的组合场景设计是否充分;

    >> 用例是否检查了对于有导出EXCEL等文本的情况,导出查询是否同步修改;

    >> 报表生成过程中是否涉及后台数据的变化,即:是否涉及中间表、临时表的使用,如有使用,那么用例是否包含对计算过程中的中间表、临时表的数据正确性检查;

    >> 用例是否考虑了现有测试数据库的数据是否满足测试要求,是否需要造数据或者导生产数据,测试数据与用户验收测试是否可以共用等因素;

  》对于业务操作类功能:

    >> 被测功能中是否包含查询功能,如果包含则参见查询、报表类功能评审检查点;

    >> 用例中对操作产生的数据状态的流转是否有清晰的说明;

    >> 用例是否包含了对可逆数据的反复正向、逆向操作结果正确性的检查;

    >> 对于可能发生的异常,是否设计了足够多的场景,对于发生异常之后的应用健康度是否有检查,在异常场景中,是否包含对产生脏数据的可能性的检查;

    >> 对于涉及EAI、ETL等数据同步的功能或涉及不同数据库或数据表之间数据交换的功能,是否有对不同数据库、数据表的字段和前后台字段类型、长度一致性的检查;

    >> 针对本需求的修改点,是否设计了对其关联功能或潜在关联影响的测试用例,关联影响分析的依据是什么;

    >> 对界面操作的后台日志记录是否有检查其完整性和正确性,是否有单独开发监控程序的必要;

    >> 用例的优先级是怎样的,对应功能不可用的情况下,其他测试用例的执行是否受到影响,对于这种情况是否有规避的方法;反之本测试用例是否受制于其他测试用例执行结果的正确性,如果是则又该如何解决;

    >> 用例执行的前置条件是否清楚,如:测试执行时是否需要依赖特殊外设或者硬件资源、关联系统的版本进度和质量等;

    >> 是否需要为本用例所对应的功能新建功能点或分支,用例是否需要加入到回归测试用例中,本测试用例是否可自动化,是否可以立即自动化,自动化脚本开发预计需要多少时间;


posted @ 2011-12-01 15:18 顺其自然EVO 阅读(328) | 评论 (0)编辑 收藏

查看Linux系统的其他参数

 1、用vmstat来监控Linux系统的整体性能

  vmstat是一个相当全面的性能分析工具,可以用来观察系统的进程状态、内存使用情况、虚拟内存的使用情况、磁盘的I/O、中断、上下文切换、CPU的使用情况等性能信息。建议熟练掌握此命令。举例如下:

  • [root@localhost ~]# vmstat 1 4  
  • procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------  
  •  r b  swpd  free buffcache si sobibo  incsus sy idwa st  
  •  0 00225159234310474124800023100010000  
  •  0 002251592343104741248000010341930010000  
  •  0 002251592343104741248000010171470010000  
  •  0 002251592343104741248000010281830010000
  •   其中:

      procs

      r:等待运行的进程数。

      b:处在非中断睡眠状态的进程数。

      w:被交换出去的可运行的进程数。此数由Linux计算得出,但Linux并不耗尽交换空间。

      memory

      swpd:虚拟内存使用情况,单位为KB。

      free:空闲的内存,单位为KB。

      buff:被用来作为缓存的内存数,单位为KB。

      swap

      si:从磁盘交换到内存的交换页数量,单位为KB。

      so:从内存交换到磁盘的交换页数量,单位为KB。

      io

      bi:发送到块设备的块数,单位为块。

      bo:从块设备接收到的块数,单位为块。

      system

      in:每秒的中断数,包括时钟中断。

      cs:每秒的环境(上下文)切换次数。

      cpu

      按CPU的总使用百分比来显示。

      us:CPU使用时间。

      sy:CPU系统使用时间。

      id:闲置时间。

      标准情况下r和b值应该为:

      r<5,b≈0

      假设输出的信息中:

      r经常大于3或4,且id经常少于50,表示CPU的负荷很重。

      pi、po长期不等于0,表示内存不足。

      disk经常不等于0,且在b中的队列大于2或3,表示io的性能不好。

      2、查看系统内核

      查看系统内核主要是为了掌握其版本号,为安装LVS等软件做准备。我们可以用命令uname -a来查看,如下所示:

  • [root@localhost ~]# uname -a  
  • Linux localhost.localdomain 2.6.18-194.el5 #1 SMP Fri 
    Apr 2 14:58:14 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux
  •   简化的参数命令如下:

    [root@localhost ~]# uname -r

      2.6.18-194.el5如果要查看系统是32位还是64位,可以用如下命令:[root@localhost /]# ls -lF /| grep /$此命令会查找是否有/lib64的目录,有则表示系统为64位,无则表示系统为32位。大家记住一点,64位的CPU系统架构可以安装32位或64位的系统,而32位的CPU架构只能安装32位的系统。查找情况如下所示:

  • drwxr-xr-x  2 root root 4096 03-13 04:02 bin/  
  • drwxr-xr-x  4 root root 1024 03-08 16:44 boot/  
  • drwxr-xr-x  5 root root 4096 03-27 00:58 data/  
  • drwxr-xr-x 11 root root 3800 03-17 07:27 dev/  
  • drwxr-xr-x 101 root root 12288 03-26 08:47 etc/  
  • drwxr-xr-x  4 root root 4096 03-09 10:34 home/  
  • drwxr-xr-x 11 root root 4096 03-13 04:02 lib/  
  • drwxr-xr-x  7 root root 4096 03-13 04:02 lib64/  
  • drwx------  2 root root 16384 03-08 16:33 lost+found/  
  • drwxr-xr-x  2 root root 4096 2010-01-27 media/  
  • drwxr-xr-x  2 root root 0 03-16 16:23 misc/  
  • drwxr-xr-x  2 root root 4096 2010-01-27 mnt/  
  • drwxr-xr-x  2 root root 0 03-16 16:23 net/  
  • drwxr-xr-x  2 root root 4096 2010-01-27 opt/  
  • dr-xr-xr-x 142 root root 0 03-16 16:22 proc/  
  • drwxr-x--- 17 root root 4096 03-28 11:30 root/  
  • drwxr-xr-x  2 root root 12288 03-13 04:02 sbin/  
  • drwxr-xr-x  2 root root 4096 03-08 16:35 selinux/  
  • drwxr-xr-x  2 root root 4096 2010-01-27 srv/  
  • drwxr-xr-x 11 root root 0 03-16 16:23 sys/  
  • drwxrwxrwt  5 root root 4096 03-28 04:02 tmp/  
  • drwxr-xr-x 15 root root 4096 03-08 16:40 usr/  
  • drwxr-xr-x 21 root root 4096 03-08 16:47 var/
  •   另一种常见方法是通过file命令来判断系统中的文件是32位还是64位的,以此作为判断系统的依据,如下所示:

  • [root@localhost /]# file /sbin/init  
  • /sbin/init: ELF 64-bit LSB executable, AMD x86-64, 
    version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked 
    (uses shared libs), for GNU/Linux 2.6.9, stripped
  •   此结果表示系统为64位的。

      3、查看服务器使用的Linux发行版的相关信息

      下面的命令可查看服务器使用的Linux发行版的名称、版本号及描述信息等:

  • [root@localhost /]# lsb_release -a  
  • LSB Version: :core-3.1-amd64:core-3.1-ia32:core-3.1-
    noarch:graphics-3.1-amd64:graphics-3.1-ia32:graphics-3.1-noarch  
  • Distributor ID: CentOS  
  • Description: CentOS release 5.5 (Final)  
  • Release: 5.5
  •   Codename:Final如果Centos5.5或以前的版本没有此命令,我们可以通过yum -y install redhat-lsb来安装。

      4、查看系统已载入的相关模块

      Linux操作系统的核心具有模块化的特性,因此在编译核心时,无须把全部的功能都放入核心。可以将这些功能编译成一个个单独的模块,待需要时再分别载入。比如说在安装LVS+Keepalived时,我们经常会用lsmod来查看lvs模块是否已经载入,如下所示:

  • root@localhost ~]# lsmod| grep ip_vs  
  • ip_vs_wrr 35905 1  
  • ip_vs 122113 3 ip_vs_wrr5.在Linux下查找PCI设置
  •   有时需要在Linux下查找PCI设置。这时可以用lspci命令,它能列出机器中的PCI设备信息,比如声卡、显卡、Modem、网卡等的信息,主板集成设备的信息也能列出来。lspci读取的是hwdata数据库。可能有读者和我一样,最关心的还是网卡型号。

  • [root@localhost ~]# lspci | grep Ether  
  • 06:07.0 Ethernet controller: Intel Corporation 82541GI
    Gigabit Ethernet Controller (rev 05)  
  • 07:08.0 Ethernet controller: Intel Corporation 82541GI
    Gigabit Ethernet Controller (rev 05)
  •   网卡的监控一般用命令miit-tool和iptraf,这个知识点将在后面讲解。

      本文主要从服务器的CPU、内存、硬盘性能、负载及其他方面详细说明了Linux服务器的整体性能状态,希望大家能够通过以上所列的方法来了解自己的Linux服务器的性能状态,这对工作会有很大帮助。





    posted @ 2011-12-01 14:59 顺其自然EVO 阅读(611) | 评论 (0)编辑 收藏

    MySQL主从配置的一些总结

     一、做了mysql主从也有一段时间了,这两天检查磁盘空间情况,发现放数据库的分区磁盘激增了40多G,一路查看下来,发现配置好主从复制以来到现在的binlog就有40多G,原来根源出在这里,查看了一下my.cnf,看到binlog的 size是1G就做分割,但没有看到删除的配置,在mysql里show了一下variables:

    mysql>show variables like '%log%';

      查到了,

    | expire_logs_days | 0 |

      这个默认是0,也就是logs不过期,这个是一个global的参数,所以需要执行

    set global expire_logs_days=8;

      这样8天前的log就会被删除了,如果有回复的需要,请做好备份工作,但这样设置还不行,下次重启mysql了,配置又恢复默认了,所以需在my.cnf中设置,

    expire_logs_days = 8

      这样重启也不怕了。

      现在我在生产环境下的做法是将此时间设为0,然后备份mysql日志文件,然后再手动清理此文件。

      想要恢复数据库以前的资料,执行

    mysql>show binlog events;

      由于数据量很多,查看起来很麻烦,光打开个文件就要闪半天,所以应该适当删除部分可不用的日志

      并且如果使用的时间足够长的话,会把我的硬盘空间都给吃掉。

      1、登录系统,/usr/bin/mysql

      使用mysql查看日志:

  • mysql>show binary logs; 
  • +—————-+———–+ 
  • | Log_name | File_size | 
  • +—————-+———–+ 
  • | ablelee.000001 | 150462942 | 
  • | ablelee.000002 | 120332942 | 
  • | ablelee.000003 | 141462942 | 
  • +—————-+———–+
  •   2、删除bin-log(删除ablelee.000003之前的而没有包含ablelee.000003):

  • mysql> purge binary logs to ′ablelee.000003′; 
  • Query OK, 0 rows affected (0.16 sec)
  •   3、查询结果(现在只有一条记录了):

  • mysql> show binlog events\G  
  • *************************** 1. row ***************************  
  • Log_name: ablelee.000003  
  • Pos: 4  
  • Event_type: Format_desc  
  • Server_id: 1  
  • End_log_pos: 106  
  • Info: Server ver: 5.1.26-rc-log, Binlog ver: 4  
  • 1 row in set (0.01 sec)  
  • (ablelee.000001和ablelee.000002已被删除)  
  • mysql> show binary logs;  
  • +—————-+———–+  
  • | Log_name | File_size |  
  • +—————-+———–+  
  • | ablelee.000003 | 106 |  
  • +—————-+———–+  
  • 1 row in set (0.00 sec)  
  • (删除的其它格式运用!)  
  • PURGE {MASTER | BINARY} LOGS TO ‘log_name’  
  • PURGE {MASTER | BINARY} LOGS BEFORE ‘date
  •   用于删除列于在指定的日志或日期之前的日志索引中的所有二进制日志。这些日志也会从记录在日志索引文件中的清单中被删除,这样被给定的日志成为第一个。

      例如:

  • PURGE MASTER LOGS TO 'mysql-bin.010'
  • PURGE MASTER LOGS BEFORE '2008-06-22 13:00:00';

  •  二、现在手上蛮多项目的数据库用的是MySQL,由于权限等原因,暂时不方便部署Nagios监控MySQL主从复制,所以我一般在从机上配置了SHELL脚本用来监控MySQL的主从状态(设置为每十分钟运行一次),并且每次出问题时将确切日期写进错误日志,方便事后排查原因,脚本内容如下:

  • #!/bin/bash 
  • #check MySQL_Slave Status 
  • #crontab time 00:10 
  • MYSQLPORT=`netstat -na|grep "LISTEN"|grep "3306"|awk -F[:" "]+ '{print $4}'
  • MYSQLIP=`ifconfig eth0|grep "inet addr" | awk -F[:" "]+ '{print $4}'
  • STATUS=$(/usr/local/webserver/mysql/bin/mysql -u yuhongchun -pyuhongchun101 -S /tmp/mysql.sock -e "show slave status\G" | grep -i "running"
  • IO_env=`echo $STATUS | grep IO | awk ' {print $2}'
  • SQL_env=`echo $STATUS | grep SQL | awk '{print $2}'
  • if [ "$MYSQLPORT" == "3306" ] 
  • then 
  • echo "mysql is running" 
  • else 
  • mail -s "warn!server: $MYSQLIP mysql is down" yuhongchun027@163.com 
  • fi 
  • if [ "$IO_env" = "Yes" -a "$SQL_env" = "Yes" ] 
  • then 
  • echo "Slave is running!" 
  • else 
  • echo "####### $date #########">> /data/data/check_mysql_slave.log 
  • echo "Slave is not running!" >> /data/data/check_mysql_slave.log 
  • mail -s "warn! $MySQLIP_replicate_error" yuhongchun027@163.com << /data/data/check_mysql_slave.log 
  • fi
  •   建议每十分钟运行一次。

    */10 * * * * root /bin/sh /root/mysql_slave.sh

      记得在每台MySQL从机上分配一个yuhongchun的用户,权限大些也没关系,只限定在本地运行,如下所示:

  • grant all privileges on *.* to "yuhongchun"@"127.0.0.1" identified by "yuhongchun101"
  • grant all privileges on *.* to "yuhongchun"@"localhost" identified by "yuhongchun101";
  •   脚本设计思路:

      1、此脚本应该能适应各种各样不同的内外网环境,即IP不同的环境;

      2、让脚本也顺便监控下MySQL是否正常运行;

      三、innodb_buffer_pool_size的设置。

      这个参数定义了InnodDB存储引擎的表数据和索引数据的最大内存缓冲区大小。和MyISAM存储引擎不同,MyISAM的key_buffer_size只缓存索引键,而innodb_buffer_pool_size却是同时为数据块和索引块 做缓存,这个特征和Oracle是一样的,这个值设得越高,访问表中数据需求的I/O就越少。在一个专用的数据库服务器,可以设置这个参数达机器物理内存的80%,我现在一般的做法是配置成物理内存的 1/4,比如8G内存的生产数据库,我一般会配置成2G左右。

      四、测试了很长一段时间的MySQL的负载均衡,最后综合了老男孩和其它技术高手的意见,最终决定还是用LVS+Keepalived来作为MySQL的负载均衡,这是因为后端机器超过10台时,LVS的性能还是最好的;如果在3-5台左右,HAProxy也可以很轻松的搞定工作。

      五、大家都很清,磁盘I/O总会成为数据库的性能瓶颈,这时候我们应该如何在生产环境下选择合适的RAID级别呢?

      1、如果数据读写都很频繁,可靠性要求也很高,最好选择RAID10;

      2、如果数据读很频繁,写相对较少,对可靠性有一定要求,可以选择RAID5;

      3、如果数据读写都很频繁,但可靠性要求不高,可以选择RAID0。

      4、对于核心业务的数据库主从同步,建议从机的备份时间往后延迟一段时间,通常的做法是延迟一天左右。

    posted @ 2011-12-01 14:49 顺其自然EVO 阅读(148) | 评论 (0)编辑 收藏

    测试如何处理好和开发的合作关系

     日常的工作中,每天都会与开发工程师打交道。我们服务的核心对象也是开发同学,和开发同学保持较好的合作关系,很大程度上影响了测试工作的好坏。

      谈谈自己的一点看法:

      1、加强开发团队对缺陷和测试人员的重视程度,规范开发测试流程,从根源上解决问题。 开发和测试的矛盾来自于缺陷,也终止于缺陷。 开发团队的领导技术觉悟,可能会直接影响到成员和测试人员的合作,如果开发团队领导对缺陷都视而不见,对测试认知度有限,开发同学就可能会对bug产生抵触情绪。 采用适当的培训来提高开发团队对测试工作的认识,可以使开发同学提高代码质量意识,更加尊重测试的工作。如果可以有一个非常明确的开发测试流程,并能够将代码质量计算 到每个人的能力考核范围内,那么测试的工作会好做很多。目前公司很多的需求跟进、代码review工作都理所当然的由测试来负责推进,这种现状其实不利于测试人员解脱出来,专注于测试 本身。

      2、引入缺陷统计工具 缺陷解决周期及质量可以一目了然,提供给开发和测试同学一个渠道去查看团队成员的代码质量、缺陷频率、线上代码存在的隐患等等。 同时,对于某一个项目来说,缺陷统计工具提供的数据可以做为一个数据仓库以提供各位老大们做各种数据挖掘,比如某一个项目在引入自动化测试框架后,bug频度和数量是否了 下降,某开发团队引入code coverage工具后,首版本严重级别相同的bug数量是否有降低。

      3、简化开发测试间的缺陷沟通渠道,避免无效bug。 我们可以先来个换位思考,如果我们来做开发,什么样的bug我们乐意改,什么样的bug我们最讨厌?

      我大概想了想,有几下几种:

      最喜欢的bug:

      1)容易改的;
      2)可以让代码更简洁的;
      3)不需要重构的;
      4)改完了有种成就感的;
      5)这个bug不被发现可能影响重大的;
      6)可以让我有技术成长的;

      ......

      最讨厌的bug:

      1)费了半天劲但发现是个无效bug,测试根本没搞清楚需求是什么;
      2)吹毛求疵的小问题,而且很费时间的问题;
      3)可能是个问题,但我从bug描述上根本看不出是什么地方出了问题;
      4)我只是遗忘了一个sql脚本,结果QA给我提个P0级别bug,至于么?
      5)测试库都是垃圾数据,你们为什么不清一下就总说程序有问题?

      ......

      综上,应该尽量做到以下几点:

      1)前期的需求明确,达到开发和测试认识一致是前提;

      2)bug的描述尽可能清晰,优先级尽可能准确,尽可能深刻,最好深入到代码级,避免重复的bug;

      3)减少随机测试带来不可重现的bug,如有可能,尽量所提bug都是可以重现的;

      4)能够和开发同学说明bug的严重性和可能带来的具体风险;

      5)减少对开发同学的技术依赖,建立技术尊重。比如自动化部署、独立掌握测试环境、了解一定的代码逻辑等等。

      4、引用台企的一句话“Work Smart”

      1)注意bug提交的时机。严重的bug如果在上线前才提出来,大家都会很窝火,开发即使不埋怨心里对测试的信任度也会打折。同时,目标对象的心情也很重要,即使你很资深,开 发人员关机了准备走,或者和女朋友约了吃饭,这个bug被处理的可能性肯定很小的。

      2)对事不对人。一个标题鲜明的严重bug列表也许会让pm觉得项目问题很多,同时也会让开发很“没面子”,特别是一堆无关紧要的问题被标红和罗列成一屏幕的时候,会引起很 大的反感。这种情况应该尽量避免发生。同时,测试应该尽可能只就事论事,讨论bug尽可能理智和克制,有耐心,避免和开发同学因为bug争吵。这样才能够很好的说服开发修改 缺陷。

      3)和开发搞好私人关系,做开发的朋友:   尽可能站在开发角度考虑问题,特别是开发同学遇到困难的时候,使开发同学认识到测试不仅仅是找茬,而是在协助他完成他的工作。这样既能够解决问题,又能够交个朋友, 何乐而不为?

      以上仅是个人一点想法,欢迎拍砖!谢谢!

    posted @ 2011-12-01 13:23 顺其自然EVO 阅读(217) | 评论 (0)编辑 收藏

    仅列出标题
    共394页: First 上一页 354 355 356 357 358 359 360 361 362 下一页 Last 
    <2024年11月>
    272829303112
    3456789
    10111213141516
    17181920212223
    24252627282930
    1234567

    导航

    统计

    常用链接

    留言簿(55)

    随笔分类

    随笔档案

    文章分类

    文章档案

    搜索

    最新评论

    阅读排行榜

    评论排行榜