我希望有很多很多的爱,如果没有很多的爱,我希望有很多很多的钱;没有很多的钱,我希望拥有健康! I am like the road in the night listening to the footfalls of its memories in silence.

发布新日志

  • 忙~

    2007-05-15 22:35:38

      今年一直都在忙,忙得几个月都没有整理资料了,我知道我应该只有周末才能腾出时间来弄,但连续计划了几个星期,最终还是不想动。

      一直都想做个自动化脚本,去年年底的时候开始动了工,但到现在都还没做好,原因是今年来都没有机会再去动它了。

      一直都在忙,忙得已经不想再忙,可事情怎么忙都是忙不完,现在已经不想再忙

     

     

  • 第一次给老妈送礼物

    2007-05-13 21:11:44

      常常听到老妈说谁家谁家的女儿给谁家谁家的母亲买了什么礼物,谁家谁家的女儿母亲节的时候又给谁家谁家的母亲买了什么,进行了什么什么样的庆祝,谁谁穿的衣服是谁谁的女儿买的,从老妈的眼神和面容中,我可以看出老妈是很羡慕她们的。

     我,之前从来都没给老妈买过什么礼物,不知道为什么,总觉得不好意思。也许是老妈在我的心目中是一个独立有主张的女性,是一个威严的母亲,很多事情我在她的面前还是......

     今天是母亲节,给老妈买了一束花。老妈问我花了多少钱,我跟她说只花了10多块,因为我知道老妈如果知道真的价钱的话,肯定会心痛不已,她宁愿不要,对我更会是一通的训话了。

     

  • 怎样衡量公平?

    2007-05-12 23:24:46

     

    公平?这个社会是否还有公平?怎样衡量公平?不公平又能怎么样?

     

    毕业后参加工作的第一年,我一个软件工程师跟一个新来的文员工资参不多。大半年后,老板自动给我加了工资,但其实还不如一个老员工文员。想想自己那时整天加班加点,外出调试工作环境的恶劣(灰尘、各种噪音、各种油漆的味道),手端着笔记本,坐在地上、蹲在地上写程序、改程序、调试程序,每天中饭晚饭蹲在草地上吃饭像个民工一样、每天回来拖着疲惫的身体一屁股坐在那铁牛车上,看着后面的路,感觉自己像个难民一样,而那些文员在舒适的办公室里面坐着,舒适地坐着吃饭,按时下班,这公平不?

     

    跳了个大公司,年终考核我没有加工资的份,原因是公司广为流传的第一次考核都是这样子的。但我自认为我的工作量和贡献并不比他们差。

     

    说到待遇,我进来的基本工资都比他们进来时的要低,原因并不是能力的问题,而是他们有了比我早参加工作几年的经验,但并不是相关的工作的经验。工作年期越长工资越高,从他们身上看起来似乎是个规律。

     

    目前的KPI考核又会公平吗?漏洞百出,有心思的人大可以重上面按照指标的统计方式造假,这又有何用呢?何不把心思放在干实事上面呢?

     

    都是一些不公平,但又能怎么样呢?干脆不干了?可以!但过不了心理的那一关,你怎么可以把进行了一半的项目甩给被人呢?不负责任的态度!一分钱干一分力?可以!但你能对得起你自己的良心吗?

     

    其实不公平又能怎么样?怨恨计较这些不公平又能怎么样?受苦的是自己,何不放宽自己的胸怀,做自己就好了呢?

     

     

     

     

  • 随意总结

    2007-05-12 19:48:40

    一、开发常对我说的话,听了心里蛮高兴的,这是开发对我们测试工作的一种肯定和支持:

    1幸好有你帮我把关

    2有你把关,我们放心多了

    3我发现你测得好细阿

    4你好细心阿

    5你辛苦了

     

    二、测试有时候并不是仅仅测试需求点,更需要站在用户的角度上去考虑他们的使用感受、操作习惯、及用户可能出现的操作流程。

     

    三、缺陷应该从一开始就要杜绝。缺陷如果从一开始就没有杜绝的话,那么有关这方面的功能或流程,开发就会延用或仿照原来的流程和设计方案走下去,结果缺陷就越积越多了。我目前所负责的系统就是这样子,发现了很多缺陷,结果开发说:‘这个问题系统一直都是存在的,其他的产品也是这么做的’、‘业务不会这样子操作的, 业务会人工逻辑控制的了’、‘因为以往相关功能也是这么处理的,如果要改的话,那么就需要业务提需求,把原来的也一起改掉’,结果跟业务、开发电话会议沟通后,业务说“没关系的,系统是一直都是这样子的,我们会自己人为控制了”,最后我们就无话可说了,只有把缺陷拒绝关闭了。(我们没有业务的权利大啊,呵呵~ 纳闷~)。可我之前听说公司的财务系统出现了一个严重的错误,造成了大量批处理后的数据错误,原因是一位不熟悉该系统业务操作流程的同事由于操作错误引起的。公司的财务系统使用了那么多年,这个缺陷就一直存在了,想想中间可能有过测试人员发现过这个缺陷,但也许是因为开发或业务类当时似上面的话而放弃了自己的坚持了。所以缺陷必须在一开始就杜绝,绝不可因为“不会那样操作的”而放弃了,因为这不仅仅是这个需求的问题,而是关系到后面系统功能在不断增强的问题,我们不可给开发以后说“系统一直都是这样子做”的推词机会。

     

    四、一个新增的业务操作流程一定要仔细和重点测试。这是因为这关系到后面系统有关这个流程功能的不断增加,如果第一步功能实现没走好,那么后面的功能需求也将会跟着错下去的。这其实业是上面第三点的一个补充了。(最近测试了一个需求(主要业务流程为“机构申请、中心审核、机构跟踪等”),我是最有这个体会了。因为开发说后面还有很多需求都是关于这个流程的,他以后的需求都是在此基础去做的,所以我就很细心地测了,因为我怕影响到开发后面的开发,所以我尽量尽早地去发现错误了)

     

    五、关于功能实现所采用的技术的安全性和可靠性。最近接触到一个需求,这个需求的功能实现涉及到跨多个数据库访问的问题。在这个需求的测试过程中,开发还进行过两次的有关跨数据库访问技术的调整。过程中,开发问了我个问题说“你们黑盒测试的话,怎么保证这个程序的对后台数据的正确性,及技术实现的安全性和可靠性呢?因为有时候前台的功能是实现了,但程序里面的缺陷怎么办?”。是啊,谁来保证功能实现所采用的技术呢?只有开发自己吗?......

     

    六、与开发、业务的相处。这个怎么说呢,不过我是抱着互相帮助的心理的。平常业务有不懂系统功能有关程序实现方面的问题,他们问我,我会很快地尽量详细回答他们。有关测试数据和测试环境的问题,我也都会努力的帮助他们。我平常有不懂的业务知识我就找业务他们,他们也很乐意地为我讲解。对于开发,他们咨询我有关我们的测试流程、测试环境问题、他们需求有关测试的情况等等,我都会尽可能地告诉他们。测试发现的缺陷我一般都会先跟开发打个招呼沟通一下确认一下,或如果是很明确的缺陷在我报了之后,我都会第一时间告诉开发的,好让他们先有个心理准备。在开发程序移交部署后告诉了我,我也会尽早的去验证的,缺陷验证通过后我也会第一时间告诉他们,因为我明白他们也焦急,通过了他们就放心了,呵呵~。我平常咨询需求问题和需求实现方式等,、开发也会很快地回复我的。所以我跟他们相处得都很好,工作也很开心和顺利。

     

    七、与开发、业务关系太好的问题。最近发现了些问题,跟业务同事关系太好了,他们测试的时候总是不放心自己测试,总是会问我我的测试结果。他们发现了缺陷也会不敢确定,总让我给他们验证一遍,这样我总是处于很忙之中,分心去处理他们的事情了(我们的ITUAT测试阶段界限不清晰,所以很多时候我们的测试时间都是混在一起测的了)。而对于开发,当我一发现缺陷的时候,除了报了缺陷,还直接把缺陷告诉开发了(我想尽早地让他们知道缺陷以便尽快修复),但不知道这样不停地告诉他们缺陷,会不会影响他们的工作? 这个得问一问才行,呵呵~

     

    八、与开发的沟通。前段时间公司举行了一次测试理论和流程的培训,其间讲师说了一句话“我们要对事不对人,开发写出的程序不管是好是坏,对他们自己来说他们都是喜好不已的,我们不可妄加评论他们的代码,更不可一句话地说好还是坏(对业务需求也一样)”。其实与开发沟通不必太过于针对和强调BUG,如果是认为是其哪个地方的代码的问题,应该用探讨性语气来与他们沟通。

     

    九、站在开发的角度,体谅他们的苦。我自己也做过开发,不过幸好我们的一个项目,客户最多来两三次来检查项目质量,但我都受不了客户,每次来都提一大堆问题,之后我们就得改程序。现在想想我们的开发还真可怜,业务不断地要求完善功能,提新需求;我们测试发现的缺陷他们也要改阿改的,所以他们总是处于被动之中,忙碌之中、紧张之中(现在我想,如果我在公司是做开发的,我还真吃不消呢。其实想想,公司那么多的IT部门之中,我们测试部门是最幸福的了)。所以不要埋怨开发有时候不及时回复你的邮件,不接你的电话。我想开发也不是故意不理你的,他们忙啊。有的可能还需要了解他的性格,有的开发做起事情来真的太投入和专注了,他们不想被打断。(其实自己这样想心理也会舒服很多的)

     

     十、有个同事经常问我“你发现了那么多bug,是不是很高兴啊”,每当这时我就会去查一查自己发现的bug的数量,看着统计的数字心理确实是蛮高兴的。但说实在的,我自己真的不会像其他人那样因为发现一个bug而很开心。其实我的目标很简单,就是把工作做好,把系统维护好,把系统弄得清新点、干净点,让大家舒服(业务可以顺利地使用,开发不用为处理业务上报的紧急缺陷而很焦虑)。

     

  • [转] 无忧测试论坛《每日一帖》

    2007-05-10 22:19:11

    无忧测试论坛《每日一帖》5月份精华

    http://www.51testing.com/Integ/20041227_1.htm

     

    来自 http://www.51testing.com 这是论坛版主天网每天提供给测试网友的精神食粮,感谢天网

    1 帖【 2004 5 10 】:软件测试的理想模式是什么?

    Brian Marick :我不认为存在什么理想模式。我觉得让开发人员承担某些测试也许会更加有效,而其他测试则由独立测试组来进行。因为如果你把所有测试都交给独立测试组,他们不可能有时间把所有测试都做好。所以,最佳的方式是让开发人员承担一定量的测试,独立测试组给予他们支持。独立测试组主要承担整个系统的测试,去寻找开发人员还没有发现的缺陷,如子系统间的交互、运行条件、内存使用等。

    如何更有效地开展系统测试呢?让测试人员在项目初期就参与进去,让他们看到第一版的系统需求、用户手册和系统原型,在系统实现前就对需求进行捕获和跟踪。在该过程中,他们从这些文档构造最初的测试设计。这也可以通过检视或评审的形式进行,并且在该过程中会发现一些缺陷。大家都知道,这个阶段,问题发现是非常 “ 便宜 ” 的。

    这样,系统测试工程师在项目早期就介入,产生测试设计及基本的需要测试的项目列表。这时不可能产生一个绝对完备的测试设计,因为书写完整测试的条件还不成熟,但这却是构建完整测试的基础。

    注: Brian Marick 是 Reliability Software 公司的专职测试技术顾问。

    2 帖【 2004 5 11 】:测试经理角色定位

    Johanna Rothman :测试经理服务于两种完全不同的客户:测试工程师和高层管理者。对于测试工程师,测试经理帮助他们开发产品测试策略,积累产品测试经验并在测试组内充分共享。对于高层管理者,测试经理搜集尽可能全面的产品信息,供其就产品是否可以发布进行决策。但是有一点是相同的:无论是对于测试工程师还是高层管理者,测试经理将帮助其定义和校验产品发布标准。

    产品发布标准的定义和校验:作为一个测试经理,应该找机会与市场、开发人员商讨产品发布标准,并根据客户的反馈对该标准进行修正和校验。开发部门的工作是如何达到公司对产品的期望,要用客户需求为开发人员勾画出客户眼中的产品以及产品应如何工作。一旦产品被清楚地定义,就可以通过测试去验证产品在多大程度上满足了客户需求。

    对于测试工程师而言有一点非常重要:将测试任务按优先级划分,使产品发布标准得以满足。由于只有极少数的项目有充足的时间去完成所有事情,所以告诉测试工程师关于 “ 测什么和何时测 ” 测试经理的一个重要职责。

    高层管理者需要充分理解产品发布标准,以决定产品是否可以按时发布。我不认为测试组有权利裁决产品是否应该被发布,该权利在组织高层管理者那里。在有了一个通过讨论、达成一致的产品发布标准后,项目组也可以更清楚地了解和认识产品质量。

    3 贴【 2004 5 12 】:测试的基本原则

    (美) Roger S. Pressman
    在设计有效测试用例之前,测试工程师必需理解软件测试的基本原则。这里有一组测试原则:
    1 、所有的测试都应追溯到用户需求。正如我们所知:软件测试的目标在于揭示错误。而最严重的错误(从用户角度来看)是那些导致程序无法满足需求的错误。
    2 、应该在测试工作真正开始前的较长时间内就进行测试计划。测试计划可以在需求模型一完成就开始,详细的测试用例定义可以在设计模型被确定后立即开始。因此,所有测试应该在任何代码被产生前就进行计划和设计。
    3 、 Pareto 原则应用于软件测试。简单地讲, Pareto 原则暗示着测试发现的错误中的 80 %很可能起源于程序模块中的 20 %。当然,问题在于如何孤立这些有疑点的模块并进行彻底的测试。
    4 、测试应从 “ 小规模 ” 开始,逐步转向 “ 大规模 ” 。最初的测试通常把焦点放在单个程序模块上,进一步测试的焦点则转向在集成的模块簇中寻找错误,最后在整个系统中寻找错误。
    5 、穷举测试是不可能的。即使是一个大小适度的程序,其路径排列的数量也非常大。因此,在测试中不可能运行路径的每一种组合。然而,充分覆盖程序逻辑,并确保程序设计中使用的所有条件是有可能的。
    6 、为了达到最佳效果,应该由独立的第三方来构造测试。 “ 最佳效果 ” 指最有可能发现错误的测试(测试的主要目标),所以创建系统的软件工程师并不是构造软件测试的最佳人选。

    4 贴【 2004 5 13 】:什么是 的测试?

    什么是 “ 好 ” 的测试? Kaner , Falk & Nguyen
    1 、一个好的测试发现错误的可能性很高
    为了达到这个目标,测试者必需理解软件、并尝试设想软件如何才能失败,例如:在 GUI (图形用户界面)中有一种潜在的错误,即错误识别鼠标位置,那么就应该设计一个测试集来验证是否存在鼠标位置识别的错误。
    2 、一个好的测试并不冗余
    测试的时间和资源是有限的,没有必要构造一个与其他测试用例完全相同的测试,每一个测试都应该有不同的用途〔哪怕是细微的差异〕。例如,软件 SafeHome 中有一个模块被用来识别用户密码以决定是否启动系统,为了测试密码输入的错误,测试者设计了一系列的输入密码。在不同的测试中输入有效与无效密码( 4 个数字),然而,每一个有效 / 无效密码将只检测一种不同错误模式,例如一个将 8080 作为有效密码的系统将不会接受非法密码 1234 ,如果接受 1234 ,将产生错误,另一个测试输入 1235 ,与 1234 的测试意图相同,因此是冗余的,然而,非法输入 8081 或 8180 就有些细微的差异,即对与有效密码相近但并不相同的密码应该进行测试。
    3 、一个好的测试应该是 “ 最佳品种 ”
    在一组目的相似的测试中,时间和资源的限制可能只影响其某个子集的执行,此时,应该使用最可能找到所有错误的测试。
    4 、一个好的测试既不会太简单,也不会太复杂
    虽然有时会将一组测试组合到一个测试用例中,其副作用可能屏蔽错误,通常每一个测试应该独立执行。

    5 贴【 2004 5 14 】:软件可测试性

    Roger S. Pressman
    理想情况下,软件工程师在设计计算机程序、系统或产品时应该考虑可测试性,这就使得测试工程师能够更容易地设计有效的测试用例。

    什么是 “ 可测试性 ” ?软件的可测试性是指软件发现故障并隔离、定位其故障的能力特性,以及在一定的时间和成本前提下,进行测试设计、测试执行的能力。 James Bach 这样描述可测试性:软件可测试性就是一个计算机程序能够被测试的容易程度。

    以下是一个常见的软件可测试性检查表:
    · 可操作性- “ 运行地越好,被测试的效率越高。 ”
    · 可观察性- “ 所看见的,就是所测试的。 ”
    · 可控制性- “ 对软件的控制越好,测试越能够被自动执行与优化。 ”
    · 可分解性- “ 通过控制测试范围,能够更好地分解问题,执行更灵巧的再测试。 ”
    · 简单性- “ 需要测试的内容越少,测试的速度越快。 ”
    · 稳定性- “ 改变越少,对测试的破坏越小。 ”
    · 易理解性- “ 得到的信息越多,进行的测试越灵巧。 ”

    6 贴【 2004 5 15 】:实时系统测试

    Roger S. Pressman

    很多实时系统的时间依赖性和异步性给测试带来新的困难--时间!测试用例的设计者考虑的不仅是白盒和黑盒测试用例,而且包括事件处理(如中断处理)、数据的时间序列以及处理数据的任务(进程)的并发性。很多情况下,提供的测试数据有时使得实时系统在某状态下可以正常运行,而同样的数据在系统处于不同状态时有时又会导致错误。

    另外,实时系统的软件和硬件之间的密切关系也会导致测试问题,软件测试必须考虑硬件故障对软件处理的影响,这种故障很难实时仿真。由于实时系统的特殊性和复杂性,还没有一个完善的综合性的测试用例设计方法,但是,大致可以分为以下四个步骤:

    1 、任务测试。测试实时系统的第一步是独立的测试各个任务。对每一个任务设计白盒和黑盒测试用例,并在测试时执行每个任务。任务测试能够发现逻辑和功能错误,但是不能发现时间和行为错误。

    2 、行为测试。利用 CASE 工具创建软件模型,就可能仿真实时系统,并按照外部事件的序列检查其行为,这些分析活动可作为创建实时系统时设计测试用例的基础。

    3 、任务间测试。在隔离了任务内部和系统行为错误以后,测试就要转向时间相关的错误。用不同的数据率和处理负载来测试与其他任务通讯的异步任务,看任务间的同步是否会产生错误。另外,测试通过消息队列和数据存储进行通讯的任务,以发现这些数据存储区区域大小方面的错误。

    4 、系统测试。集成软件和硬件,并进行大范围的系统测试,以发现软件 / 硬件接口间的错误。

    7 贴【 2004 5 16 】:单元测试、集成测试、系统测试、验收测试、回归测试

    Software Research
    单元测试:单元测试是对软件中的基本组成单位进行的测试,如一个模块、一个过程等等。它是软件动态测试的最基本的部分,也是最重要的部分之一,其目的是检验软件基本组成单位的正确性。一个软件单元的正确性是相对于该单元的规约而言的。因此,单元测试以被测试单位的规约为基准。单元测试的主要方法有控制流测试、数据流测试、排错测试、分域测试等等。

    集成测试:集成测试是在软件系统集成过程中所进行的测试,其主要目的是检查软件单位之间的接口是否正确。它根据集成测试计划,一边将模块或其他软件单位组合成越来越大的系统,一边运行该系统,以分析所组成的系统是否正确,各组成部分是否合拍。集成测试的策略主要有自顶向下和自底向上两种。

    系统测试:系统测试是对已经集成好的软件系统进行彻底的测试,以验证软件系统的正确性和性能等满足其规约所指定的要求,检查软件的行为和输出是否正确并非一项简单的任务,它被称为测试的 “ 先知者问题 ” 。因此,系统测试应该按照测试计划进行,其输入、输出和其他动态运行行为应该与软件规约进行对比。软件系统测试方法很多,主要有功能测试、性能测试、随机测试等等。

    验收测试:验收测试旨在向软件的购买者展示该软件系统满足其用户的需求。它的测试数据通常是系统测试的测试数据的子集。所不同的是,验收测试常常有软件系统的购买者代表在现场,甚至是在软件安装使用的现场。这是软件在投入使用之前的最后测试。

    回归测试:回归测试是在软件维护阶段,对软件进行修改之后进行的测试。其目的是检验对软件进行的修改是否正确。这里,修改的正确性有两重含义:一是所作的修改达到了预定目的,如错误得到改正,能够适应新的运行环境等等;二是不影响软件的其他功能的正确性。

    8 贴【 2004 5 17 】:软件测试策略

    Roger S. Pressman
    测试是一系列可以事先计划并且可以系统地进行管理的活动。正是由于这个原因,应当为软件工程过程定义一个软件测试的模板-我们可以把特定的测试用例方法放置进去的一系列步骤。

    人们已经提出了许多软件测试策略,所有这些策略都为如开发人员提供了一个供测试用的模板,而且它们都包含下列的类属特征:
    · 测试开始于模块层,然后 “ 延伸 ” 到整个基于计算机的系统集合中。
    · 不同的测试技术适用于不同的时间点。
    · 测试是由软件的开发人员和(对于大型系统而言)独立的测试组来管理的。
    · 测试和调试是不同的活动,但是调试必须能够适应任何的测试策略。

    软件测试策略必须提供可以用来检验一小段源代码是否得以正确实现的低层测试,同时也要提供能够验证整个系统的功能是否符合用户需求的高层测试。一种策略必须为使用者提供指南,并且为管理者提供一系列的重要的里程碑。因为测试策略的步骤是在软件完成的最终期限的压力已经开始出现的时候才开始进行的,所以测试的进度必须是可测量的,而且问题要尽可能早的暴露出来。

    9 贴【 2004 5 18 】:白盒测试

    Rex Black
    白盒测试,也称为结构化测试、基于代码的测试,是一种测试用例设计方法,它从程序的控制结构导出测试用例。用白盒测试产生的测试用例能够:
    1 )保证一个模块中的所有独立路径至少被使用一次;
    2 )对所有逻辑值均需测试 true 和 false ;
    3 )在上下边界及可操作范围内运行所有循环;
    4 )检查内部数据结构以确保其有效性。

    “ 我们应该更注重于保证程序需求的实现,为什么要花费时间和精力来担心(和测试)逻辑细节? ” 答案在于软件自身的缺陷:
    1 、逻辑错误和不正确假设与一条程序路径被运行的可能性成反比。当我们设计和实现主流之外的功能、条件或控制时,错误往往开始出现在我们工作中。日常处理往往被很好地了解,而 “ 特殊情况 ” 的处理则难于发现。
    2 、我们经常相信某逻辑路径不可能被执行,而事实上,它可能在正常的基础上被执行。程序的逻辑流有时是违反直觉的,这意味着我们关于控制流和数据流的一些无意识的假设可能导致设计错误,只有路径测试才能发现这些错误。
    3 、笔误是随机的。当一个程序被翻译为程序设计语言源代码时,有可能产生某些笔误,很多将被语法检查机制发现,但是,其他的会在测试开始时才会被发现。笔误出现在主流上和不明显的逻辑路径上的机率是一样的。

    正如 Beizer 所说的: “ 错误潜伏在角落里,聚集在边界上 ” ,而白盒测试更可能发现它。

    10 贴【 2004 5 19 】:黑盒测试

    黑盒测试注重于测试软件的功能性需求,也即黑盒测试使软件工程师派生出执行程序所有功能需求的输入条件。黑盒测试并不是白盒测试的替代品,而是用于辅助白盒测试发现其他类型的错误。黑盒测试试图发现以下类型的错误:
    1 )功能错误或遗漏;
    2 )界面错误;
    3 )数据结构或外部数据库访问错误;
    4 )性能错误;
    5 )初始化和终止错误。

    白盒测试在测试的早期采用,而黑盒测试主要用于测试的后期。黑盒测试故意不考虑控制结构,而是注意信息域。黑盒测试用于回答以下问题:
    1 )如何测试功能的有效性?
    2 )何种类型的输入会产生好的测试用例?
    3 )系统是否对特定的输入值尤其敏感?
    4 )如何分隔数据类的边界?
    5 )系统能够承受何种数据率和数据量?
    6 )特定类型的数据组合会对系统产生何种影响?

    运用黑盒测试方法,可以导出满足以下标准的测试用例集:
    1 )所设计的测试用例能够减少达到合理测试所需的附加测试用例数;
    2 )所设计的测试用例能够告知某些类型错误的存在或不存在,而不是仅仅与特定测试相关的错误。

    11 贴【 2004 5 20 】:软件测试充分性准则

    ( 1 )空测试对任何软件都是不充分的。
    ( 2 )对任何软件都存在有限的充分测试集合。
    ( 3 )如果一个软件系统在一个测试数据集合上的测试是充分的,那么再多测试一些数据也应该是充分的。这一特性称为单调性。
    ( 4 )即使对软件所有成分都进行了充分的测试,也并不意味着整个软件的测试已经充分了。这一特性称为非复合性。
    ( 5 )即使对一个软件系统整体的测试是充分的,也并不意味着软件系统中各个成分都已经充分地得到了测试。这个特性称为非分解性。
    ( 6 )软件测试的充分性应该与软件的需求和软件的实现都相关。
    ( 7 )软件越复杂,需要的测试数据就越多。这一特性称为复杂性。
    ( 8 )测试得越多,进一步测试所能得到的充分性增长就越少。这一特性称为回报递减率。

    12 贴【 2004 5 21 】:静态测试

    在软件开发过程中,每产生一个文档,都必须对它进行测试,以确定它的质量是否满足要求。这样的检查工作与全面质量管理的思想是一致的,也与项目管理过程相一致。每当一个文档通过了静态测试,就标志着一项开发工作的总结,标志着项目取得了一定的进展,进入了一个新的阶段。

    静态测试的基本特征是在对软件进行分析、检查和测试时不实际运行被测试的程序。它可以用于对各种软件文档进行测试,是软件开发中十分有效的质量控制方法之一。在软件开发过程中的早期阶段,由于可运行的代码尚未产生,不可能进行动态测试,而这些阶段的中间产品的质量直接关系到软件开发的成败与开销的大小,因此,在这些阶段,静态测试的作用尤为重要。在软件开发多年的生产实践经验和教训的基础上,人们总结出了一些行之有效的静态测试技术和方法,如结构化走通、正规检视等等。这些方法和测试技术可以与软件质量的定量度量技术相结合,对软件开发过程进行监视、控制,从而保障软件质量。

    13 贴【 2004 5 22 】:什么是测试需求?

    Brian Marick
    测试需求的概念比较简单。例如,比方说一个计算平方根的程序,如果输入一个大于或等于零的数,程序可以给出一个结果;如果输入一个小于零的数,程序将指出输入错误。读过《软件测试的艺术》一书的工程师都会立即联想到边界值。对数值零进行测试;对零非常接近的负数进行测试,这就是两个具体的测试需求。

    在一个更加复杂的程序中,你可以将打算测试的项目做成一个列表。但是,这些测试需求都不会确定具体的测试数据。例如,一个银行交易程序,一个测试需求是试图支付客户的金额为负数,另一个测试需求是交易中的客户并不存在,等等。你有一系列这样的测试需求,它们并没有指出具体的数值或数据,如客户的姓名。

    测试的下一步是选择满足这些测试需求的输入值 / 测试数据。一个简单的测试用例可能会同时满足好几个测试需求。一个用例能同时满足好几个测试需求,当然是最理想的情况,但是这样做的代价较高。另外一种方法是为每一个测试需求设计一个单独的测试用例,就可以不必考虑那些复杂的测试用例,但是这些相对简单的测试用例发现缺陷的能力就会有所下降。

    这里有一个测试需求的实例:对一个哈希表的插入操作进行测试,有以下这些测试需求:
    1 )插入一个新的条目
    2 )插入失败-条目已经存在
    3 )插入失败-表已满
    4 )哈希表在插入前为空
    这些就是测试需求,而非测试用例,因为它们没有对被插入元素进行描述。另外你也不能马上就着手书写用例,就好象软件需求完成后不能立即进行编码一样。还需要对测试需求进行评审,确保正确和没有需求遗漏。

    14 贴【 2004 5 30 】: GUI 测试

    Roger S. Pressman

    图形用户界面( GUI )对软件测试提出了有趣的挑战,因为 GUI 开发环境有可复用的构件,开发用户界面更加省时而且更加精确。同时, GUI 的复杂性也增加了,从而加大了设计和执行测试用例的难度。因为现在 GUI 设计和实现有了越来越多的类似,所以也就产生了一系列的测试标准。下列问题可以作为常见 GUI 测试的指南:

    窗口:
    · 窗口是否基于相关的输入和菜单命令适当地打开?
    · 窗口能否改变大小、移动和滚动?
    · 窗口中的数据内容能否用鼠标、功能键、方向键和键盘访问?
    · 当被覆盖并重新调用后,窗口能否正确地再生?
    · 需要时能否使用所有窗口相关的功能?
    · 所有窗口相关的功能是可操作的吗?
    · 是否有相关的下拉式菜单、工具条、滚动条、对话框、按钮、图标和其他控制可为窗口使用,并适当地显示?
    · 显示多个窗口时,窗口的名称是否被适当地表示?
    · 活动窗口是否被适当地加亮?
    · 如果使用多任务,是否所有的窗口被实时更新?
    · 多次或不正确按鼠标是否会导致无法预料的副作用?
    · 窗口的声音和颜色提示和窗口的操作顺序是否符合需求?
    · 窗口是否正确地被关闭?

    下拉式菜单和鼠标操作:
    · 菜单条是否显示在合适的语境中?
    · 应用程序的菜单条是否显示系统相关的特性(如时钟显示)?
    · 下拉式操作能正确工作吗?
    · 菜单、调色板和工具条是否工作正确?
    · 是否适当地列出了所有的菜单功能和下拉式子功能?
    · 是否可以通过鼠标访问所有的菜单功能?
    · 文本字体、大小和格式是否正确?
    · 是否能够用其他的文本命令激活每个菜单功能?
    · 菜单功能是否随当前的窗口操作加亮或变灰?
    · 菜单功能是否正确执行?
    · 菜单功能的名字是否具有自解释性?
    · 菜单项是否有帮助,是否语境相关?
    · 在整个交互式语境中,是否可以识别鼠标操作?
    · 如果要求多次点击鼠标,是否能够在语境中正确识别?
    · 光标、处理指示器和识别指针是否随操作恰当地改变?

    数据项:
    · 字母数字数据项是否能够正确回显,并输入到系统中?
    · 图形模式的数据项(如滚动条)是否正常工作?
    · 是否能够识别非法数据?
    · 数据输入消息是否可理解?

    15 贴【 2004 5 31 】: Client/Server 测试

    Roger S. Pressman

    通常,客户 / 服务器软件的测试发生在三个不同的层次:
    ( 1 )个体的客户端应用以 “ 分离的 ” 模式被测试 —— 不考虑服务器和底层网络的运行;
    ( 2 )客户端软件和关联的服务器端应用被一起测试,但网络运行不被明显的考虑;
    ( 3 )完整的 C/S 体系结构,包括网络运行和性能,被测试。

    下面的测试方法是 C/S 应用中经常用到的:
    应用功能测试 —— 客户端应用被独立地执行,以揭示在其运行中的错误。
    服务器测试 —— 测试服务器的协调和数据管理功能,也考虑服务器性能(整体反映时间和数据吞吐量)。
    数据库测试 —— 测试服务器存储的数据的精确性和完整性,检查客户端应用提交的事务,以保证数据被正确地存储、更新和检索。
    事务测试 —— 创建一系列的测试以保证每类事务被按照需求处理。测试着重于处理的正确性,也关注性能问题。
    网络通信测试 —— 这些测试验证网络节点间的通信正常地发生,并且消息传递、事务和相关的网络交通无错的发生。

  • [转] 软件测试常识

    2007-05-06 12:02:44

    [转]软件测试常识

    Acceptance testing(验收测试),系统开发生命周期方法论的一个阶段,这时相关的用户和/或独立测试人员根据测试计划和结果对系统进行测试和接收。它让系统用户决定是否接收系统。它是一项确定产品是否能够满足合同或用户所规定需求的测试。这是管理性和防御性控制。

    Ad hoc testing (随机测试),没有书面测试用例、记录期望结果、检查列表、脚本或指令的测试。主要是根据测试者的经验对软件进行功能和性能抽查。随机测试是根据测试说明书执行用例测试的重要补充手段,是保证测试覆盖完整性的有效方式和过程。

    Alpha testing (α测试),是由一个用户在开发环境下进行的测试,也可以是公司内部的用户在模拟实际操作环境下进行的受控测试,Alpha测试不能由程序员或测试员完成。

    Automated Testing(自动化测试),使用自动化测试工具来进行测试,这类测试一般不需要人干预,通常在GUI、性能等测试中用得较多。

    Beta testing(β测试),测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场,Beta测试不能由程序员或测试员完成。

    Black box testing(黑盒测试),指测试人员不关心程序具体如何实现的一种测试方法。根据软件的规格对软件进行各种输入和观察软件的各种输出结果来发现软件的缺陷的测试,这类测试不考虑软件内部的运作原理,因此软件对用户来说就像一个黑盒子。

    Bug (错误),有时称作defect(缺陷)或error(错误),软件程序中存在的编程错误,可能会带来不必要的副作用,软件的功能和特性与设计规格说明书或用户需求不一致的方面。软件缺陷表现特征为:软件未达到产品说明书标明的功能;软件出现产品说明书指明不会出现的错误;软件功能超出产品说明书指明的范围;虽然产品说明书未指出但是软件应达到的目标;软件测试人员或用户认为软件难以理解,不易使用,运行速度缓慢等问题。

    Bug report(错误报告),也称为“Bug record(错误记录)”,记录发现的软件错误信息的文档,通常包括错误描述、复现步骤、抓取的错误图像和注释等。

    Bug tracking system(错误跟踪系统,BTS),也称为“Defect tracking system,DTS”,管理软件测试缺陷的专用数据库系统,可以高效率地完成软件缺陷的报告、验证、修改、查询、统计、存储等任务。尤其适用于大型多语言软件的测试管理。

    Build(工作版本),软件开发过程中用于内部测试的功能和性能等不完善的软件版本。工作版本既可以是系统的可操作版本,也可以是展示要在最终产品中提供的部分功能的部分系统。

    Compatibility Testing(兼容性测试),也称“Configuration testing(配置测试)”,测试软件是否和系统的其它与之交互的元素之间兼容,如:浏览器、操作系统、硬件等。验证测试对象在不同的软件和硬件配置中的运行情况。

    Capture/Replay Tool (捕获/回放工具),一种测试工具,能够捕获在测试过程中传递给软件的输入,并且能够在以后的时间中,重复这个执行的过程。这类工具一般在GUI测试中用的较多。

    Crash(崩溃),计算机系统或组件突然并完全的丧失功能,例如软件或系统突然退出或没有任何反应(死机)。

    Debug(调试),开发人员确定引起错误的根本原因和确定可能的修复措施的过程。一般发生在子系统或单元模块编码完成时,或者根据测试错误报告指出错误以后,开发人员需要执行调试过程来解决已存在的错误。

    Deployment(部署),也称为shipment(发布),对内部IT系统而言,指它的第一个版本通过彻底的测试、形成产品、交付给付款客户的阶段。

    Dynamic testing(动态测试),通过执行软件的手段来测试软件。

    Exception(异常/例外),一个引起正常程序执行挂起的事件。

    Functional testing (功能测试),也称为behavīoral testing(行为测试),根据产品特征、操作描述和用户方案,测试一个产品的特性和可操作行为以确定它们满足设计需求。本地化软件的功能测试,用于验证应用程序或网站对目标用户能正确工作。使用适当的平台、浏览器和测试脚本,以保证目标用户的体验将足够好,就像应用程序是专门为该市场开发的一样。

    Garbage characters(乱码字符),程序界面中显示的无意义的字符,例如,程序对双字节字符集的字符不支持时,这些字符不能正确显示。

    GB 18030 testing(GB 18030测试),软件支持GB 18030字符集标准能力的测试,包括GB 18030字符的输入、输出、显示、存储的支持程度。

    Installing testing(安装测试),确保该软件在正常情况和异常情况的不同条件下,例如,进行首次安装、升级、完整的或自定义的安装都能进行安装。异常情况包括磁盘空间不足、缺少目录创建权限等。核实软件在安装后可立即正常运行。安装测试包括测试安装代码以及安装手册。安装手册提供如何进行安装,安装代码提供安装一些程序能够运行的基础数据。

    Integration testing(集成测试),被测试系统的所有组件都集成在一起,找出被测试系统组件之间关系和接口中的错误。该测试一般在单元测试之后进行。

    International testing(国际化测试),国际化测试的目的是测试软件的国际化支持能力,发现软件的国际化的潜在问题,保证软件在世界不同区域中都能正常运行。国际化测试使用每种可能的国际输入类型,针对任何区域性或区域设置检查产品的功能是否正常,软件国际化测试的重点在于执行国际字符串的输入/输出功能。国际化测试数据必须包含东亚语言、德语、复杂脚本字符和英语(可选)的混合字符。

    Localizability testing(本地化能力测试),本地化能力是指不需要重新设计或修改代码,将程序的用户界面翻译成任何目标语言的能力。为了降低本地化能力测试的成本,提高测试效率,本地化能力侧是通常在软件的伪本地化版本上进行。本地化能力测试中发现的典型错误包括:字符的硬编码(即软件中需要本地化的字符写在了代码内部),对需要本地化的字符长度设置了国定值,在软件运行时以控件位置定位,图标和位图中包含了需要本地化的文本,软件的用户界面与文档术语不一致等。

    Load testing(负载测试),通过测试系统在资源超负荷情况下的表现,以发现设计上的错误或验证系统的负载能力。在这种测试中,将使测试对象承担不同的工作量,以评测和评估测试对象在不同工作量条件下的性能行为,以及持续正常运行的能力。负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外,负载测试还要评估性能特征,例如,响应时间、事务处理速率和其他与时间相关的方面。

    Localization testing(本地化测试),本地化测试的对象是软件的本地化版本。本地化测试的目的是测试特定目标区域设置的软件本地化质量。本地化测试的环境是在本地化的操作系统上安装本地化的软件。从测试方法上可以分为基本功能测试,安装/卸载测试,当地区域的软硬件兼容性测试。测试的内容主要包括软件本地化后的界面布局和软件翻译的语言质量,包含软件、文档和联机帮助等部分。

    Performance testing(性能测试),评价一个产品或组件与性能需求是否符合的测试。包括负载测试、强度测试、数据库容量测试、基准测试等类型。

    Pilot testing(引导测试),软件开发中,验证系统在真实硬件和客户基础上处理典型操作的能力。在软件外包测试中,引导测试通常是客户检查软件测试公司测试能力的一种形式,只有通过了客户特定的引导测试,软件测试公司才能接受客户真实软件项目的软件测试。

    Portability testing(可移植性测试),测试瞄准于证明软件可以被移植到指定的硬件或软件平台上。
    Priority(优先权),从商业角度出发是指错误的重要性,尤其是从客户和用户的角度出发,是指错误对于系统的可行性和可接受性的影响。与“Severity(严重性)”相对照。

    Quality assurance(质量保证QA),采取的所有活动以保证一个开发组织交付的产品满足性能需求和已确立的标准和过程。

    Regression testing(回归测试),在发生修改之后重新测试先前的测试以保证修改的正确性。理论上,对软件的任何新版本,都需要进行回归测试,验证以前发现和修复的错误是否在新软件版本上再现。

    Review(评审),在产品开发过程中,把产品提交给项目成员、用户、管理者或其它相关人员评价或批准的过程。

    Sanity testing(健全测试),软件主要功能成分的简单测试以保证它是否能进行基本的测试。参考“Smoke testing(冒烟测试)”。

    Screen shot(抓屏、截图),软件测试中,将软件界面中的错误(窗口、菜单、对话框等)的全部或一部分,使用专用工具存储成图像文件,以便于后续处理。

    Severity(严重性),错误对被测系统的影响程度,在终端用户条件下发生的可能性,软件错误妨碍系统使用的程度。与“Priority(优先权)”相对照。

    Smoke testing(冒烟测试),冒烟测试的对象是每一个新编译的需要正式测试的软件版本,目的是确认软件基本功能正常,可以进行后续的正式测试工作。冒烟测试的执行者是版本编译人员。参考“Sanity testing(健全测试)”。

    Software life cycle(软件生命周期),开始于一个软件产品的构思,结束于该产品不再被使用的这段期间。

    Static testing(静态测试),不通过执行来测试一个系统。如代码检查,文档检查和评审等。

    Structured query language(结构化查询语句,SQL),在一个关系数据库中查询和处理数据的一种语言。

    TBD(To be determined,待定),在测试文档中标是一项进行中的尚未最终确定的工作。

    Test(测试),执行软件以验证其满足指定的需求并检测错误的过程。检测已有条件之间的不同,并评价软件项的特性软件项的分析过程。软件工程过程的一个活动,它将软件在预定的条件下运行以判断软件是否符合预期结果。

    Test case(测试用例),为特定目标而开发的一组测试输入、执行条件和预期结果,其目标可以是测试某个程序路径或核实是否满足某个特定的需求。

    Testing coverage(测试覆盖),指测试系统覆盖被测试系统的程度,一项给定测试或一组测试对某个给定系统或构件的所有指定测试用例进行处理所达到的程度。

    Testing environment(测试环境),进行测试的环境,包括测试平台、测试基础设施、测试实验室和其他设施。

    Testing item(测试项),作为测试对象的工作版本。

    Testing plan(测试计划),描述了要进行的测试活动的范围、方法、资源和进度的文档。它确定测试项、被测特性、测试任务、谁执行任务,并且任何风险都要冲突计划。

    Testing procedure(测试过程),指设置、执行给定测试用例并对测试结果进行评估的一系列详细步骤。

    Testing scrīpt(测试脚本),一般指的是一个特定测试的一系列指令,这些指令可以被自动化测试工具执行。

    Testing suite(测试包),一组测试用里的执行框架;一种组织测试用例的方法。在测试包里,测试用例可以组合起来创造出独特的测试条件。

    Unit testing(单元测试),指一段代码的基本测试,其实际大小是未定的,通常是一个函数或子程序,一般由开发者执行。

    User interface(用户界面,UI),广义是指使用户可以和计算机进行交互的硬件和/或软件。狭义是指软件中的可见外观及其底层与用户交互的部分(菜单、对话框、窗口和其它控件)。

    User interface testing (用户界面测试),指测试用户界面的风格是否满足客户要求,文字是否正确,页面是否美观,文字,图片组合是否完美,操作是否友好等等。UI 测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。确保用户界面符合公司或行业的标准。包括用户友好性、人性化、易操作性测试。

    White box testing(白盒测试),根据软件内部的工作原理分析来进行测试,基于代码的测试,测试人员通过阅读程序代码或者通过使用开发工具中的单步调试来判断软件的质量,一般黑盒测试由项目经理在程序员开发中来实现。

    Acceptance testing(验收测试),系统开发生命周期方法论的一个阶段,这时相关的用户和/或独立测试人员根据测试计划和结果对系统进行测试和接收。它让系统用户决定是否接收系统。它是一项确定产品是否能够满足合同或用户所规定需求的测试。这是管理性和防御性控制。

    Ad hoc testing (随机测试),没有书面测试用例、记录期望结果、检查列表、脚本或指令的测试。主要是根据测试者的经验对软件进行功能和性能抽查。随机测试是根据测试说明书执行用例测试的重要补充手段,是保证测试覆盖完整性的有效方式和过程。

    Alpha testing (α测试),是由一个用户在开发环境下进行的测试,也可以是公司内部的用户在模拟实际操作环境下进行的受控测试,Alpha测试不能由程序员或测试员完成。

    Automated Testing(自动化测试),使用自动化测试工具来进行测试,这类测试一般不需要人干预,通常在GUI、性能等测试中用得较多。

    Beta testing(β测试),测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场,Beta测试不能由程序员或测试员完成。

    Black box testing(黑盒测试),指测试人员不关心程序具体如何实现的一种测试方法。根据软件的规格对软件进行各种输入和观察软件的各种输出结果来发现软件的缺陷的测试,这类测试不考虑软件内部的运作原理,因此软件对用户来说就像一个黑盒子。

    Bug (错误),有时称作defect(缺陷)或error(错误),软件程序中存在的编程错误,可能会带来不必要的副作用,软件的功能和特性与设计规格说明书或用户需求不一致的方面。软件缺陷表现特征为:软件未达到产品说明书标明的功能;软件出现产品说明书指明不会出现的错误;软件功能超出产品说明书指明的范围;虽然产品说明书未指出但是软件应达到的目标;软件测试人员或用户认为软件难以理解,不易使用,运行速度缓慢等问题。

    Bug report(错误报告),也称为“Bug record(错误记录)”,记录发现的软件错误信息的文档,通常包括错误描述、复现步骤、抓取的错误图像和注释等。

    Bug tracking system(错误跟踪系统,BTS),也称为“Defect tracking system,DTS”,管理软件测试缺陷的专用数据库系统,可以高效率地完成软件缺陷的报告、验证、修改、查询、统计、存储等任务。尤其适用于大型多语言软件的测试管理。

    Build(工作版本),软件开发过程中用于内部测试的功能和性能等不完善的软件版本。工作版本既可以是系统的可操作版本,也可以是展示要在最终产品中提供的部分功能的部分系统。

    Compatibility Testing(兼容性测试),也称“Configuration testing(配置测试)”,测试软件是否和系统的其它与之交互的元素之间兼容,如:浏览器、操作系统、硬件等。验证测试对象在不同的软件和硬件配置中的运行情况。

    Capture/Replay Tool (捕获/回放工具),一种测试工具,能够捕获在测试过程中传递给软件的输入,并且能够在以后的时间中,重复这个执行的过程。这类工具一般在GUI测试中用的较多。

    Crash(崩溃),计算机系统或组件突然并完全的丧失功能,例如软件或系统突然退出或没有任何反应(死机)。

    Debug(调试),开发人员确定引起错误的根本原因和确定可能的修复措施的过程。一般发生在子系统或单元模块编码完成时,或者根据测试错误报告指出错误以后,开发人员需要执行调试过程来解决已存在的错误。

    Deployment(部署),也称为shipment(发布),对内部IT系统而言,指它的第一个版本通过彻底的测试、形成产品、交付给付款客户的阶段。

    Dynamic testing(动态测试),通过执行软件的手段来测试软件。

    Exception(异常/例外),一个引起正常程序执行挂起的事件。

    Functional testing (功能测试),也称为behavīoral testing(行为测试),根据产品特征、操作描述和用户方案,测试一个产品的特性和可操作行为以确定它们满足设计需求。本地化软件的功能测试,用于验证应用程序或网站对目标用户能正确工作。使用适当的平台、浏览器和测试脚本,以保证目标用户的体验将足够好,就像应用程序是专门为该市场开发的一样。

    Garbage characters(乱码字符),程序界面中显示的无意义的字符,例如,程序对双字节字符集的字符不支持时,这些字符不能正确显示。

    GB 18030 testing(GB 18030测试),软件支持GB 18030字符集标准能力的测试,包括GB 18030字符的输入、输出、显示、存储的支持程度。

    Installing testing(安装测试),确保该软件在正常情况和异常情况的不同条件下,例如,进行首次安装、升级、完整的或自定义的安装都能进行安装。异常情况包括磁盘空间不足、缺少目录创建权限等。核实软件在安装后可立即正常运行。安装测试包括测试安装代码以及安装手册。安装手册提供如何进行安装,安装代码提供安装一些程序能够运行的基础数据。

    Integration testing(集成测试),被测试系统的所有组件都集成在一起,找出被测试系统组件之间关系和接口中的错误。该测试一般在单元测试之后进行。

    International testing(国际化测试),国际化测试的目的是测试软件的国际化支持能力,发现软件的国际化的潜在问题,保证软件在世界不同区域中都能正常运行。国际化测试使用每种可能的国际输入类型,针对任何区域性或区域设置检查产品的功能是否正常,软件国际化测试的重点在于执行国际字符串的输入/输出功能。国际化测试数据必须包含东亚语言、德语、复杂脚本字符和英语(可选)的混合字符。

    Localizability testing(本地化能力测试),本地化能力是指不需要重新设计或修改代码,将程序的用户界面翻译成任何目标语言的能力。为了降低本地化能力测试的成本,提高测试效率,本地化能力侧是通常在软件的伪本地化版本上进行。本地化能力测试中发现的典型错误包括:字符的硬编码(即软件中需要本地化的字符写在了代码内部),对需要本地化的字符长度设置了国定值,在软件运行时以控件位置定位,图标和位图中包含了需要本地化的文本,软件的用户界面与文档术语不一致等。

    Load testing(负载测试),通过测试系统在资源超负荷情况下的表现,以发现设计上的错误或验证系统的负载能力。在这种测试中,将使测试对象承担不同的工作量,以评测和评估测试对象在不同工作量条件下的性能行为,以及持续正常运行的能力。负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外,负载测试还要评估性能特征,例如,响应时间、事务处理速率和其他与时间相关的方面。

    Localization testing(本地化测试),本地化测试的对象是软件的本地化版本。本地化测试的目的是测试特定目标区域设置的软件本地化质量。本地化测试的环境是在本地化的操作系统上安装本地化的软件。从测试方法上可以分为基本功能测试,安装/卸载测试,当地区域的软硬件兼容性测试。测试的内容主要包括软件本地化后的界面布局和软件翻译的语言质量,包含软件、文档和联机帮助等部分。

    Performance testing(性能测试),评价一个产品或组件与性能需求是否符合的测试。包括负载测试、强度测试、数据库容量测试、基准测试等类型。

    Pilot testing(引导测试),软件开发中,验证系统在真实硬件和客户基础上处理典型操作的能力。在软件外包测试中,引导测试通常是客户检查软件测试公司测试能力的一种形式,只有通过了客户特定的引导测试,软件测试公司才能接受客户真实软件项目的软件测试。

    Portability testing(可移植性测试),测试瞄准于证明软件可以被移植到指定的硬件或软件平台上。
    Priority(优先权),从商业角度出发是指错误的重要性,尤其是从客户和用户的角度出发,是指错误对于系统的可行性和可接受性的影响。与“Severity(严重性)”相对照。

    Quality assurance(质量保证QA),采取的所有活动以保证一个开发组织交付的产品满足性能需求和已确立的标准和过程。

    Regression testing(回归测试),在发生修改之后重新测试先前的测试以保证修改的正确性。理论上,对软件的任何新版本,都需要进行回归测试,验证以前发现和修复的错误是否在新软件版本上再现。

    Review(评审),在产品开发过程中,把产品提交给项目成员、用户、管理者或其它相关人员评价或批准的过程。

    Sanity testing(健全测试),软件主要功能成分的简单测试以保证它是否能进行基本的测试。参考“Smoke testing(冒烟测试)”。

    Screen shot(抓屏、截图),软件测试中,将软件界面中的错误(窗口、菜单、对话框等)的全部或一部分,使用专用工具存储成图像文件,以便于后续处理。

    Severity(严重性),错误对被测系统的影响程度,在终端用户条件下发生的可能性,软件错误妨碍系统使用的程度。与“Priority(优先权)”相对照。

    Smoke testing(冒烟测试),冒烟测试的对象是每一个新编译的需要正式测试的软件版本,目的是确认软件基本功能正常,可以进行后续的正式测试工作。冒烟测试的执行者是版本编译人员。参考“Sanity testing(健全测试)”。

    Software life cycle(软件生命周期),开始于一个软件产品的构思,结束于该产品不再被使用的这段期间。

    Static testing(静态测试),不通过执行来测试一个系统。如代码检查,文档检查和评审等。

    Structured query language(结构化查询语句,SQL),在一个关系数据库中查询和处理数据的一种语言。

    TBD(To be determined,待定),在测试文档中标是一项进行中的尚未最终确定的工作。

    Test(测试),执行软件以验证其满足指定的需求并检测错误的过程。检测已有条件之间的不同,并评价软件项的特性软件项的分析过程。软件工程过程的一个活动,它将软件在预定的条件下运行以判断软件是否符合预期结果。

    Test case(测试用例),为特定目标而开发的一组测试输入、执行条件和预期结果,其目标可以是测试某个程序路径或核实是否满足某个特定的需求。

    Testing coverage(测试覆盖),指测试系统覆盖被测试系统的程度,一项给定测试或一组测试对某个给定系统或构件的所有指定测试用例进行处理所达到的程度。

    Testing environment(测试环境),进行测试的环境,包括测试平台、测试基础设施、测试实验室和其他设施。

    Testing item(测试项),作为测试对象的工作版本。

    Testing plan(测试计划),描述了要进行的测试活动的范围、方法、资源和进度的文档。它确定测试项、被测特性、测试任务、谁执行任务,并且任何风险都要冲突计划。

    Testing procedure(测试过程),指设置、执行给定测试用例并对测试结果进行评估的一系列详细步骤。

    Testing scrīpt(测试脚本),一般指的是一个特定测试的一系列指令,这些指令可以被自动化测试工具执行。

    Testing suite(测试包),一组测试用里的执行框架;一种组织测试用例的方法。在测试包里,测试用例可以组合起来创造出独特的测试条件。

    Unit testing(单元测试),指一段代码的基本测试,其实际大小是未定的,通常是一个函数或子程序,一般由开发者执行。

    User interface(用户界面,UI),广义是指使用户可以和计算机进行交互的硬件和/或软件。狭义是指软件中的可见外观及其底层与用户交互的部分(菜单、对话框、窗口和其它控件)。

    User interface testing (用户界面测试),指测试用户界面的风格是否满足客户要求,文字是否正确,页面是否美观,文字,图片组合是否完美,操作是否友好等等。UI 测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。确保用户界面符合公司或行业的标准。包括用户友好性、人性化、易操作性测试。

    White box testing(白盒测试),根据软件内部的工作原理分析来进行测试,基于代码的测试,测试人员通过阅读程序代码或者通过使用开发工具中的单步调试来判断软件的质量,一般黑盒测试由项目经理在程序员开发中来实现。

    Acceptance testing(验收测试),系统开发生命周期方法论的一个阶段,这时相关的用户和/或独立测试人员根据测试计划和结果对系统进行测试和接收。它让系统用户决定是否接收系统。它是一项确定产品是否能够满足合同或用户所规定需求的测试。这是管理性和防御性控制。

    Ad hoc testing (随机测试),没有书面测试用例、记录期望结果、检查列表、脚本或指令的测试。主要是根据测试者的经验对软件进行功能和性能抽查。随机测试是根据测试说明书执行用例测试的重要补充手段,是保证测试覆盖完整性的有效方式和过程。

    Alpha testing (α测试),是由一个用户在开发环境下进行的测试,也可以是公司内部的用户在模拟实际操作环境下进行的受控测试,Alpha测试不能由程序员或测试员完成。

    Automated Testing(自动化测试),使用自动化测试工具来进行测试,这类测试一般不需要人干预,通常在GUI、性能等测试中用得较多。

    Beta testing(β测试),测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场,Beta测试不能由程序员或测试员完成。

    Black box testing(黑盒测试),指测试人员不关心程序具体如何实现的一种测试方法。根据软件的规格对软件进行各种输入和观察软件的各种输出结果来发现软件的缺陷的测试,这类测试不考虑软件内部的运作原理,因此软件对用户来说就像一个黑盒子。

    Bug (错误),有时称作defect(缺陷)或error(错误),软件程序中存在的编程错误,可能会带来不必要的副作用,软件的功能和特性与设计规格说明书或用户需求不一致的方面。软件缺陷表现特征为:软件未达到产品说明书标明的功能;软件出现产品说明书指明不会出现的错误;软件功能超出产品说明书指明的范围;虽然产品说明书未指出但是软件应达到的目标;软件测试人员或用户认为软件难以理解,不易使用,运行速度缓慢等问题。

    Bug report(错误报告),也称为“Bug record(错误记录)”,记录发现的软件错误信息的文档,通常包括错误描述、复现步骤、抓取的错误图像和注释等。

    Bug tracking system(错误跟踪系统,BTS),也称为“Defect tracking system,DTS”,管理软件测试缺陷的专用数据库系统,可以高效率地完成软件缺陷的报告、验证、修改、查询、统计、存储等任务。尤其适用于大型多语言软件的测试管理。

    Build(工作版本),软件开发过程中用于内部测试的功能和性能等不完善的软件版本。工作版本既可以是系统的可操作版本,也可以是展示要在最终产品中提供的部分功能的部分系统。

    Compatibility Testing(兼容性测试),也称“Configuration testing(配置测试)”,测试软件是否和系统的其它与之交互的元素之间兼容,如:浏览器、操作系统、硬件等。验证测试对象在不同的软件和硬件配置中的运行情况。

    Capture/Replay Tool (捕获/回放工具),一种测试工具,能够捕获在测试过程中传递给软件的输入,并且能够在以后的时间中,重复这个执行的过程。这类工具一般在GUI测试中用的较多。

    Crash(崩溃),计算机系统或组件突然并完全的丧失功能,例如软件或系统突然退出或没有任何反应(死机)。

    Debug(调试),开发人员确定引起错误的根本原因和确定可能的修复措施的过程。一般发生在子系统或单元模块编码完成时,或者根据测试错误报告指出错误以后,开发人员需要执行调试过程来解决已存在的错误。

    Deployment(部署),也称为shipment(发布),对内部IT系统而言,指它的第一个版本通过彻底的测试、形成产品、交付给付款客户的阶段。

    Dynamic testing(动态测试),通过执行软件的手段来测试软件。

    Exception(异常/例外),一个引起正常程序执行挂起的事件。

    Functional testing (功能测试),也称为behavīoral testing(行为测试),根据产品特征、操作描述和用户方案,测试一个产品的特性和可操作行为以确定它们满足设计需求。本地化软件的功能测试,用于验证应用程序或网站对目标用户能正确工作。使用适当的平台、浏览器和测试脚本,以保证目标用户的体验将足够好,就像应用程序是专门为该市场开发的一样。

    Garbage characters(乱码字符),程序界面中显示的无意义的字符,例如,程序对双字节字符集的字符不支持时,这些字符不能正确显示。

    GB 18030 testing(GB 18030测试),软件支持GB 18030字符集标准能力的测试,包括GB 18030字符的输入、输出、显示、存储的支持程度。

    Installing testing(安装测试),确保该软件在正常情况和异常情况的不同条件下,例如,进行首次安装、升级、完整的或自定义的安装都能进行安装。异常情况包括磁盘空间不足、缺少目录创建权限等。核实软件在安装后可立即正常运行。安装测试包括测试安装代码以及安装手册。安装手册提供如何进行安装,安装代码提供安装一些程序能够运行的基础数据。

    Integration testing(集成测试),被测试系统的所有组件都集成在一起,找出被测试系统组件之间关系和接口中的错误。该测试一般在单元测试之后进行。

    International testing(国际化测试),国际化测试的目的是测试软件的国际化支持能力,发现软件的国际化的潜在问题,保证软件在世界不同区域中都能正常运行。国际化测试使用每种可能的国际输入类型,针对任何区域性或区域设置检查产品的功能是否正常,软件国际化测试的重点在于执行国际字符串的输入/输出功能。国际化测试数据必须包含东亚语言、德语、复杂脚本字符和英语(可选)的混合字符。

    Localizability testing(本地化能力测试),本地化能力是指不需要重新设计或修改代码,将程序的用户界面翻译成任何目标语言的能力。为了降低本地化能力测试的成本,提高测试效率,本地化能力侧是通常在软件的伪本地化版本上进行。本地化能力测试中发现的典型错误包括:字符的硬编码(即软件中需要本地化的字符写在了代码内部),对需要本地化的字符长度设置了国定值,在软件运行时以控件位置定位,图标和位图中包含了需要本地化的文本,软件的用户界面与文档术语不一致等。

    Load testing(负载测试),通过测试系统在资源超负荷情况下的表现,以发现设计上的错误或验证系统的负载能力。在这种测试中,将使测试对象承担不同的工作量,以评测和评估测试对象在不同工作量条件下的性能行为,以及持续正常运行的能力。负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外,负载测试还要评估性能特征,例如,响应时间、事务处理速率和其他与时间相关的方面。

    Localization testing(本地化测试),本地化测试的对象是软件的本地化版本。本地化测试的目的是测试特定目标区域设置的软件本地化质量。本地化测试的环境是在本地化的操作系统上安装本地化的软件。从测试方法上可以分为基本功能测试,安装/卸载测试,当地区域的软硬件兼容性测试。测试的内容主要包括软件本地化后的界面布局和软件翻译的语言质量,包含软件、文档和联机帮助等部分。

    Performance testing(性能测试),评价一个产品或组件与性能需求是否符合的测试。包括负载测试、强度测试、数据库容量测试、基准测试等类型。

    Pilot testing(引导测试),软件开发中,验证系统在真实硬件和客户基础上处理典型操作的能力。在软件外包测试中,引导测试通常是客户检查软件测试公司测试能力的一种形式,只有通过了客户特定的引导测试,软件测试公司才能接受客户真实软件项目的软件测试。

    Portability testing(可移植性测试),测试瞄准于证明软件可以被移植到指定的硬件或软件平台上。
    Priority(优先权),从商业角度出发是指错误的重要性,尤其是从客户和用户的角度出发,是指错误对于系统的可行性和可接受性的影响。与“Severity(严重性)”相对照。

    Quality assurance(质量保证QA),采取的所有活动以保证一个开发组织交付的产品满足性能需求和已确立的标准和过程。

    Regression testing(回归测试),在发生修改之后重新测试先前的测试以保证修改的正确性。理论上,对软件的任何新版本,都需要进行回归测试,验证以前发现和修复的错误是否在新软件版本上再现。

    Review(评审),在产品开发过程中,把产品提交给项目成员、用户、管理者或其它相关人员评价或批准的过程。

    Sanity testing(健全测试),软件主要功能成分的简单测试以保证它是否能进行基本的测试。参考“Smoke testing(冒烟测试)”。

    Screen shot(抓屏、截图),软件测试中,将软件界面中的错误(窗口、菜单、对话框等)的全部或一部分,使用专用工具存储成图像文件,以便于后续处理。

    Severity(严重性),错误对被测系统的影响程度,在终端用户条件下发生的可能性,软件错误妨碍系统使用的程度。与“Priority(优先权)”相对照。

    Smoke testing(冒烟测试),冒烟测试的对象是每一个新编译的需要正式测试的软件版本,目的是确认软件基本功能正常,可以进行后续的正式测试工作。冒烟测试的执行者是版本编译人员。参考“Sanity testing(健全测试)”。

    Software life cycle(软件生命周期),开始于一个软件产品的构思,结束于该产品不再被使用的这段期间。

    Static testing(静态测试),不通过执行来测试一个系统。如代码检查,文档检查和评审等。

    Structured query language(结构化查询语句,SQL),在一个关系数据库中查询和处理数据的一种语言。

    TBD(To be determined,待定),在测试文档中标是一项进行中的尚未最终确定的工作。

    Test(测试),执行软件以验证其满足指定的需求并检测错误的过程。检测已有条件之间的不同,并评价软件项的特性软件项的分析过程。软件工程过程的一个活动,它将软件在预定的条件下运行以判断软件是否符合预期结果。

    Test case(测试用例),为特定目标而开发的一组测试输入、执行条件和预期结果,其目标可以是测试某个程序路径或核实是否满足某个特定的需求。

    Testing coverage(测试覆盖),指测试系统覆盖被测试系统的程度,一项给定测试或一组测试对某个给定系统或构件的所有指定测试用例进行处理所达到的程度。

    Testing environment(测试环境),进行测试的环境,包括测试平台、测试基础设施、测试实验室和其他设施。

    Testing item(测试项),作为测试对象的工作版本。

    Testing plan(测试计划),描述了要进行的测试活动的范围、方法、资源和进度的文档。它确定测试项、被测特性、测试任务、谁执行任务,并且任何风险都要冲突计划。

    Testing procedure(测试过程),指设置、执行给定测试用例并对测试结果进行评估的一系列详细步骤。

    Testing scrīpt(测试脚本),一般指的是一个特定测试的一系列指令,这些指令可以被自动化测试工具执行。

    Testing suite(测试包),一组测试用里的执行框架;一种组织测试用例的方法。在测试包里,测试用例可以组合起来创造出独特的测试条件。

    Unit testing(单元测试),指一段代码的基本测试,其实际大小是未定的,通常是一个函数或子程序,一般由开发者执行。

    User interface(用户界面,UI),广义是指使用户可以和计算机进行交互的硬件和/或软件。狭义是指软件中的可见外观及其底层与用户交互的部分(菜单、对话框、窗口和其它控件)。

    User interface testing (用户界面测试),指测试用户界面的风格是否满足客户要求,文字是否正确,页面是否美观,文字,图片组合是否完美,操作是否友好等等。UI 测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。确保用户界面符合公司或行业的标准。包括用户友好性、人性化、易操作性测试。

    White box testing(白盒测试),根据软件内部的工作原理分析来进行测试,基于代码的测试,测试人员通过阅读程序代码或者通过使用开发工具中的单步调试来判断软件的质量,一般黑盒测试由项目经理在程序员开发中来实现。
     
    此文来源于51testing博客,转载请注明出处

  • 软件测试工程师

    2007-04-23 13:08:07

    软件测试工程师

    一提到软件测试工程师,很多人就会想到那些反复使用软件,试图在频繁操作中寻找到错误发生的低层次人员或者软件用户。其实这是一种错误的概念,软件测试早已超越了用户使用来发现Bug的基本测试阶段。

    陈宏刚介绍说,微软的软件测试工程师分为三种:测试执行者(Basic Software Tester)、测试工具软件开发工程师(Software Development Engineer in Test)和高级软件测试工程师(Ad_hoc Tester)

    测试执行者负责理解产品的功能要求,然后根据测试规范和测试案例对其进行测试,检查软件有没有错误,决定软件是否具有稳定性,属于最低级的执行角色。

    测试工具软件开发工程师负责写测试工具代码,并利用测试工具对软件进行测试;或者开发测试工具为软件测试工程师服务。产品开发后的性能测试、提交测试等过程,都有可能要用到开发的测试工具。对技术要求最强的是这些人,因为它们要具备写程序的技术。“因为不同产品的特性不一样,对测试工具要求也是不同的,就像Windows的测试工具不能用于Office,office的也不能用于SQLserver,微软很多测试工程师就是负责专门为某个产品写测试程序的。”

    而Ad_hoc Testet属于比较有经验,自己会找方向并做的很好的测试工程师,这要求具有很强的创造性。刚进入微软时,老板也是只给陈宏刚一个操作流程,每天就按照这个规程去做,几天下来,一个Bug都没有发现。陈宏刚也很沮丧,觉得这样挺对不起公司,后来自己问自己:为什么非要这样做!于是换了其他的方法试试,令他吃惊的是,一下就找到很多严重的Bug,当时也不敢声张。有一天,他找到10多个非常严重的Bug,开发经理一下就惊呆了,怒冲冲的跑到陈宏刚面前问:“你是不是改变了测试方式和测试步骤?”陈宏刚有些吓住,说道:“可能改变了一点。”对方说:“我非常生气,但我不是生你的气,而是因为以前测试人员水平太差,或者以前的测试方面有问题,软件中有些Bug存在了半年甚至一年,但直到现在才发现,现在修补这些错误要困难很多!”后来陈宏刚得到了老板的赞许,可以按照自己的想法去做测试。对此,陈宏刚感受颇深:“一方面我体会到了微软非常鼓励创造的文化,同时也感到只遵守教条不是好的测试人员,就和用户一样了。做软件测试工程师同样需要开拓和创造性。”

    在开发管理上,测试不应该归属于项目管理,也不应该归属开发人员。这三个部门应该是并驾齐驱,相互协作,测试工程师最终决定产品是否能够发布。

    软件测试工程师的素质

    因为软件测试仍然处在发展阶段,还没有上升到理论层次。对人员的评测,包括微软在内,都还没有一个统一标准,因此评定软件测试工程师只能根据工作实践进行自然淘汰。

    软件测试对逻辑思维、学习能力、反应要求很高,是否有严密的思维和逆向思维也非常重要。陈宏刚介绍说,在五六个人的测试小组时,一半以上的Bug都是他找到的。他认为这同自己数学专业的背景关系密切,数学中有逻辑思维的培训,要善于找出来各方面的因素。比如要证明一个定理,各个方面都考虑到,一个条件不满足就无法证明;但如果证明其不成立,最常用的就是找到一个反例,只要有一点证明不成立就可以了,软件测试也是找这一点。

    做测试还要考虑到所有出错的可能性,还要做一些不是按常规做的、非常奇怪的事。除了漏洞检测,测试还应该考虑性能问题,也就是要保证软件运行得很好,没有内存泄漏,不会出现运行越来越慢的情况;在不同的使用环境下,考虑软件的兼容性同样重要。软件测试同产品的规模也有很大的关系,因为软件的bug往往出在大型软件的连接处。

    做软件测试工程师需要对软件抱有怀疑态度。这是因为开发人员喜欢想当然,总是找一些有利于自己程序执行的数据,有些开发人员甚至认为不利于程序执行的数据是对代码的玷污和亵渎。而软件测试却要策略性的准备各种数据,从每个细节上设计不同的应用场景,不去想当然的假定任何一个数据是可行的。

    在职业素质和交际方面方面,并不是测试工程师爱挑别人毛病才好,反而这个工作要求很强的沟通能力。经常的和开发人员进行沟通,说话办事要很得当,不能指责别人,否则会事倍功半。性格随和才能和开发人员顺畅的沟通,对人和对事是完全不同的两个问题。


  • CMMI (能力成熟度模式整合)

    2007-04-22 21:40:16

       CMMI背景:
    CMMI是SEI于2001年9月推出的系统工程和软件工程的集成成熟度模型,取代了原来的CMM。与原有的能力成熟度相比,CMMI(Capability Maturity Model Integration)涉及面更广,专业领域覆盖软件工程、系统工程、集成产品开发和系统采购

    • SEI = 'Software Engineering Institute' at Carnegie-Mellon University; initiated by the U.S. Defense Department to help improve software development processes.
    • CMM = 'Capability Maturity Model', now called the CMMI ('Capability Maturity Model Integration'), developed by the SEI. It's a model of 5 levels of process 'maturity' that determine effectiveness in delivering quality software. It is geared to large organizations such as large U.S. Defense Department contractors. However, many of the QA processes involved are appropriate to any organization, and if reasonably applied can be helpful. Organizations can receive CMMI ratings by undergoing assessments by qualified auditors.
           Level 1 - characterized by chaos, periodic panics, and heroic
                     efforts required by individuals to successfully
                     complete projects.  Few if any processes in place;
                     successes may not be repeatable.
     (初始级:项目管理混乱,没有计划、预算、功能和产品质量管理等;项目的成功取决于个人的能力)
    
           Level 2 - software project tracking, requirements management,
                     realistic planning, and configuration management
                     processes are in place; successful practices can
                     be repeated.
    (可重复级[项目级]:焦点集中在软件管理过程,包括需求管理、项目管理、质量管理、配置管理、子合同管理等;项目的成功取决于个人能力及管理层的支持)
    
           Level 3 - standard software development and maintenance processes
                     are integrated throughout an organization; a Software
                     Engineering Process Group is is in place to oversee
                     software processes, and training programs are used to
                     ensure understanding and compliance.
    (定义级:进行了综合性的管理,对软件生命周期的管理进行了标准化的定义,建立了软件工程过程小组,长期跟踪、评估及调整项目。所有人对过程定义熟悉,项目于小组形式进行,并形成产品团队)
    
           Level 4 - metrics are used to track productivity, processes,
                     and products.  Project performance is predictable,
                     and quality is consistently high.
    (管理级:对软件过程和产品质量建立了定量的质量目标,定制了软件过程和产品质量的详细而具体的度量标准)
    
           Level 5 - the focus is on continouous process improvement. The
                     impact of new processes and technologies can be
                     predicted and effectively implemented when required.
    (优化极:企业把重点放在软件过程改进的持续性、预见性及自身增强上,防止缺陷和问题的发现,不断地提高过程处理能力。可进行成本/利润分析、可总结经验、防止重复错误,不断提高产品质量和生产率;团队意识强烈)
    

    问题:什么是CMMI?CMMI是什么意思?

    CMMI(Capability Maturity Model Integration,能力成熟度模式整合)

    CMMI( Capability Maturity Model Integration)的本質是軟件管理工程的一個部分。軟件過程改善是當前軟件管理工程的核心問題, 50多年來計算的發展使人們認識揭咝省⒏哔|量和低成本地開發軟件,必須改善軟件生產過程。基於模型的過程改進是指用採用能力模型來指導組織的過程改進,使之過程能力穩定的進行改善,該組織也能變得更加成熟。

    然而,軟件組織形成一套完整而成熟的軟件過程不是一蹴而就的事情,需要經歷一系列的成熟度。軟件組織首先要進行差異分析,評定自己比較接近哪一個成熟度,然後再根據自身的情況來決定要採取哪些改進活動,來更有效地改進自己的軟件過程。這就對軟件過程的評定提出了一個客觀的標準。美國卡內基梅隆大學軟件工程學院於1987年研究成功的SW-CMM(Capability Maturity Model for Software)就是這樣的一個理論模型,其目的在於幫助軟件組織改善軟件生產流程,以探索一個保證軟件產品質量、縮短開發週期、提高工作效率的軟件工程模式與標準規範。

    CMMI是一個可以改進系統工程和軟件工程的整合模式。1997年10月SEI停止對CMM的研究,改而致力於CMMI,以解決使用多個過程改進模型的問題。SEI同時宣佈CMMI將取代CMM,與2000年8月11日頒布了CMMI-SE/SW 1.0版本,2001年12月頒布了1.1版本,這次發佈標誌著CMMI正式啟用,並準備今年內完成CMM到CMMI的過渡。

  • 独立的测试执行--带来一环不必要的风险

    2007-04-21 22:42:08

       公司的测试执行作为一个单独的步骤已经开始推广了 ,上个星期我的测试案例大都让执行人员来执行了,但测试执行的结果却让我大跌眼镜。我随便挑了几个执行通过案例来看,查了一下系统数据记录,我需要看到的数据都没有产生,不放心阿,那这是什么原因呢?

      有的其实很明显就可以看到是执行人员从中偷懒了。而有的呢,经与他们沟通后发现他们没有看清楚的我的案例或是没有理解案例所要求的操作意思。对于前两者我能说什么呢?我只能说测试执行一给测试带来一环不必要的风险了。而对于后者,我得改进,但如何改进呢?

      那就得改进案例使得无歧义了,可这个难度可大了。即使是一篇研究报告可能都会存在歧义的,更何况我们编写案例的时候只是在寻找如何用案例来验证需求程序,没有那么多精力去咬文嚼字啊或去考虑更多的执行人员到时候会怎么理解自己的案例了。

      其实我个人认为,只要对系统稍了解的人员都应该比较容易理解我的操作要求了,只是公司领导对执行人员的要求和理解就是像一部机器那样,按照设定好步骤来执行,他们不需要了解系统。可这真的可行吗?也许可以,那就是要求我们这些编写案例的人员需要写清楚点击哪个菜单,哪个按钮了。但我们没有精力放在这些操作上阿,我们也没有必要把精力放在这些无聊的操作上阿。测试的目的是什么? 不就是为了发现更多的缺陷吗?

      也许公司推行测试需求分析、测试案例设计、测试执行分别独立的测试流程对于管理上是比较好的,但对于系统的改善是否有好处呢?从改善方面我们就不好说了,因为我们还没看到结果。但却增加了我们的工作量和沟通量(特别是开发人员),目前测试流程各步骤是这样子的:

    1、测试需求分析:测试需求分析的人员将需要跟开发和业务需求提出人沟通需求

    2、测试案例设计:测试案例设计人员需要跟需求分析人员沟通测试需求,并且需要与开发人员沟通系统程序设计的实现等

    3、测试执行:执行人员需要与案例设计人员沟通如何执行;案例设计人员需要去跟踪执行情况,验证缺陷是否是真的存在,还需要与开发沟通缺陷、协助查错等。(当然按照流程的话,案例设计人员可以不管这些事情的,但能放心得下吗?)

      当然,这种场面绝对不是领导们所愿意看到的,特别是执行步骤上,他们的理想状态是没有沟通。不过如果真的如他们所要求的那样--案例说明点击的按钮或菜单,执行人员把所使用的数据保留,也许是可以零沟通的。但我还是怀疑,文字真的可以代替沟通吗?真是难为开发了

      总之啊,如果真的需要做到领导们的那理想状态,测试需求分析人员和案例设置人员都必须要努力地去减少歧义,减少沟通。但实际真的能做到吗?大家追求了那么多年的业务需求清晰性,不也始终在努力中吗?沟通始终都是在所难免,必不可少的。

     也许我们这些下属们站的低,看不到全局吧。希望这样子流程在有得有失中,得大于失吧。

  • Arousing fighting

    2007-04-14 20:26:42

     
     I have been far from English so long,I found.When I leave from my last company XinLeishen to now,It is more than half a year, nearly entire a year.

      Today ,I find a English Web to read, but I find it hard to me to read,especially structure of the sentence and the using of some words .In fact,I knew it long ago that if I keep from not touching it ,I will be strange to it and hard to learn it again , but I really had no attemption and can't keep emotion to do it.
     
     I don't know why I became so lazy and no fighting. Maybe it is the age,the tiring,no_fighting,no_English work,or no objective resulting in no fighting. To arouse my study fighting, maybe only by changing a work environment. But in fact,it is really hard to decide and choose,you know. My recent work is not bad.


     

  • 突然想起~

    2007-04-14 19:47:37

       今天看到一个文章,提到需求测试和案例测试,突然想起了公司半年前开始实施推广的测试流程(测试需求、测试案例、测试执行分别独立进行)曾经也提过这两个词,但那时并不在意,今天再看到这两个词,结合对当前公司所实施的测试流程的体会,其实我们已经在进行这两项的测试工作了。真是茅塞顿开啊,另有一幡体会啊,呵呵~

  • 网站

    2007-04-14 19:31:45

  • [转] 软件测试的14种类型

    2007-04-14 18:12:18

     

    软件测试是指使用人工或者自动的手段来运行或测定某个软件产品系统的过程,其目的是在于检验是否满足规定的需求或者弄清预期的结果与实际结果的区别。本文主要描述软件测试的类型。

    1 数据和数据库完整性测试

    数据与数据库完整测试是指测试关系型数据库完整性原则以及数据合理性测试。
    数据库完整性原即:
    主码完整性:主码不能为空;
    外码完整性:外码必须等于对应的主码或者为空。
    数据合理性指数据在数据库中的类型,长度,索引等是否建的比较合理。
    在项目名称中,数据库和数据库进程应作为一个子系统来进行测试。在测试这些子系统时,不应将测试对象的用户界面用作数据的接口。对于数据库管理系统 (DBMS),还需要进行深入的研究,以确定可以支1持测试的工具和技术。

    比如,有两张表:部门和员工。部门中有部门编号,部门名称,部门经理等字段,主码为部门编号;员工表中有员工编号,员工所属部门编号,员工名称,员工类型等字段,主码为员工编号,外码为员工所属部门编号,对应部门表。如果在某条部门记录中部门编号或员工记录员工编号为空,他就违反主码完整性原则。如果某个员工所属部门的编号为##,但是##在部门编号中确找不到,这就违反外码完整性原则。
    员工类型如下定义:0:职工,1:职员,2:实习生。但数据类型为Int,我们都知道Int占有4个字节,如果定义成char(1).就比原来节约空间。


    2 白盒测试

    白盒测试是基于代码的测试,测试人员通过阅读程序代码或者通过使用开发工具中的单步调试来判断软件的质量,一般黑盒测试由项目经理在程序员开发中来实现。白盒测试分为动态白盒测试和静态白盒测试
    2.1 静态白盒测试
    利用眼睛,浏览代码,凭借经验,找出代码中的错误或者代码中不符合书写规范的地方。比如,代码规范中规定,函数必须为动宾结构。而黑盒测试发现一个函数定义如下:
    Function NameGet(){
    ….
    }
    这是属于不符合开发规范的错误。
    有这样一段代码:
    if (i<0) & (i>=0)

    这段代码交集为整个数轴,IF语句没有必要
    I=0;
    while(I>100){
    J=J+100;
    T=J*PI;
    }
    在循环体内没有I的增加,bug产生。

    2.2 动态白盒测试
    利用开发工具中的调式工具进行测试。比如一段代码有4个分支,输入4组不同的测试数据使4组分支都可以走通而且结果必须正确。
    看一段代码
    if(I<0){
    P1
    }else{
    P2
    }
    在调试中输入I=-1,P1程序段通过, P2程序段未通过,属于动态黑盒测试的缺陷

    3.功能测试

    功能测试指测试软件各个功能模块是否正确,逻辑是否正确。
    对测试对象的功能测试应侧重于所有可直接追踪到用例或业务功能和业务规则的测试需求。这种测试的目标是核实数据的接受、处理和检索是否正确,以及业务规则的实施是否恰当。此类测试基于黑盒技术,该技术通过图形用户界面 (GUI) 与应用程序进行交互,并对交互的输出或结果进行分析,以此来核实应用程序及其内部进程。功能测试的主要参考为类似于功能说明书之类的文档。
    比如一个对电子商务系统,前台用户浏览商品-放入购物车-进入结账台,后台处理订单,配货,付款,发货,这一系列流程必须正确无误的走通,不能存在任何的错误。

    4.UI测试

    UI测试指测试用户界面的风格是否满足客户要求,文字是否正确,页面美工是否好看,文字,图片组合是否完美,背景是否美观,操作是否友好等等
    用户界面 (UI) 测试用于核实用户与软件之间的交互。UI 测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。另外,UI 测试还可确保 UI 中的对象按照预期的方式运行,并符合公司或行业的标准。包括用户友好性,人性化,易操作性测试。UI测试比较主观,与测试人员的喜好有关
    比如:页面基调颜色刺眼;用户登入页面比较难于找到,文字中出现错别字,页面图片范围太广等都属于UI测试中的缺陷,但是这些缺陷都不太严重。

    5.性能测试

    性能测试主要测试软件测试的性能,包括负载测试,强度测试,数据库容量测试,基准测试以及基准测试
    5.1负载测试
    负载测试是一种性能测试指数据在超负荷环境中运行,程序是否能够承担。
    在这种测试中,将使测试对象承担不同的工作量,以评测和评估测试对象在不同工作量条件下的性能行为,以及持续正常运行的能力。负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外,负载测试还要评估性能特征,例如,响应时间、事务处理速率和其他与时间相关的方面。
    比如,在B/S结构中用户并发量测试就是属于负载测试的用户,可以使用webload工具,模拟上百人客户同时访问网站,看系统响应时间,处理速度如何?
    5.2强度测试
    强度测试是一种性能测试,他在系统资源特别低的情况下软件系统运行情况。这类测试往往可以书写系统要求的软硬件水平要求。
    实施和执行此类测试的目的是找出因资源不足或资源争用而导致的错误。如果内存或磁盘空间不足,测试对象就可能会表现出一些在正常条件下并不明显的缺陷。而其他缺陷则可能由于争用共享资源(如数据库锁或网络带宽)而造成的。强度测试还可用于确定测试对象能够处理的最大工作量。
    比如:一个系统在内存366M下可以正常运行,但是降低到258M下不可以运行,告诉内存不足,这个系统对内存的要求就是366M。
    5.3数据库容量测试
    数据库容量测试指通过存储过程往数据库表中插入一定数量的数据,看看相关页面是否能够及时显示数据。
    数据库容量测试使测试对象处理大量的数据,以确定是否达到了将使软件发生故障的极限。容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。例如,如果测试对象正在为生成一份报表而处理一组数据库记录,那么容量测试就会使用一个大型的测试数据库,检验该软件是否正常运行并生成了正确的报表。做这种测试通常通过书写存储过程向数据库某个表中插入一定数量的记录,计算相关页面的调用时间。
    比如,在电子商务系统中,通过insert customer 往user表中插入10 000数据,看其是否可以正常显示顾客信息列表页面,如果要求达到最多可以处理100 000个客户,但是顾客信息列表页面不能够在规定的时间内显示出来,就需要调整程序中的SQL查询语句;如果在规定的时间内显示出来,可以将用户数分别提高到20 000 , 50 000, 100 000进行测试。
    5.4基准测试
    基准测试与已知现有的系统进行比较,主要检验是否与类似的产品具有竞争性的一种测试。
    如果你要开发一套财务系统软件并且你已经获得用友财务系统的性能等数据,你可以测试你这套系统,看看哪些地方比用友财务系统好,哪些地方差?以便改进自己的系统,也可为产品广告提供数据。
    5.5竞争测试
    软件竞争使用各种资源(数据纪录,内存等),看他与其他相关系统对资源的争夺能力。比如:一台机器上即安装您的财务系统,又安装用友财务系统。当CPU占有率下降后,看看是否能够强过用友财务系统,而是自己的系统能够正常运行?

    6. 安全性和访问控制测试

    安全性和访问控制测试侧重于安全性的两个关键方面:
    应用程序级别的安全性,包括对数据或业务功能的访问
    系统级别的安全性,包括对系统的登录或远程访问。
    6.1应用程序级别的安全性
    可确保:在预期的安全性情况下,主角只能访问特定的功能或用例,或者只能访问有限的数据。例如,可能会允许所有人输入数据,创建新账户,但只有管理员才能删除这些数据或账户。如果具有数据级别的安全性,测试就可确保“用户类型一”能够看到所有客户消息(包括财务数据),而“用户二”只能看见同一客户的统计数据。
    比如B/S系统,不通过登入页面,直接输入URL,看其是否能够进入系统?
    6.2系统级别的安全性
    可确保只有具备系统访问权限的用户才能访问应用程序,而且只能通过相应的网关来访问。
    比如输入管理员账户,检查其密码是否容易猜取,或者可以从数据库中获得?

    7.故障转移和恢复测试

    故障转移和恢复测试指当主机软硬件发生灾难时候,备份机器是否能够正常启动,使系统是否可以正常运行,这对于电信,银行等领域的软件是十分重要的。
    故障转移和恢复测试可确保测试对象能成功完成故障转移,并能从导致意外数据损失或数据完整性破坏的各种硬件、软件或网络故障中恢复。
    故障转移测试可确保:对于必须持续运行的系统,一旦发生故障,备用系统就将不失时机地“顶替”发生故障的系统,以避免丢失任何数据或事务。
    恢复测试是一种对抗性的测试过程。在这种测试中,将把应用程序或系统置于极端的条件下(或者是模拟的极端条件下),以产生故障(例如设备输入/输出 (I/O) 故障或无效的数据库指针和关健字)。然后调用恢复进程并监测和检查应用程序和系统,核实应用程序或系统和数据已得到了正确的恢复。一定要注意主备定时备份
    比如电信系统,突然主机程序发生死机,备份机器是否能够启动,使系统能够正常运行,从而不影响用户打电话?

    8.配置测试

    又叫兼容性测试。配置测试核实测试对象在不同的软件和硬件配置中的运行情况。在大多数生产环境中,客户机工作站、网络连接和数据库服务器的具体硬件规格会有所不同。客户机工作站可能会安装不同的软件例如,应用程序、驱动程序等而且在任何时候,都可能运行许多不同的软件组合,从而占用不同的资源。(如浏览器版本,操作系统版本等)
    下面列出主要配置测试
    8.1浏览器兼容性
    测试软件在不同产商的浏览器下是否能够正确显示与运行;
    比如测试IE,Natscape浏览器下是否可以运行这套软件?
    8.2操作系统兼容性
    测试软件在不同操作系统下是否能够正确显示与运行;
    比如测试WINDOWS98,WINDOWS 2000,WINDOWS XP,LINU, UNIX下是否可以运行这套软件?
    8.3硬件兼容性
    测试与硬件密切相关的软件产品与其他硬件产品的兼容性,比如该软件是少在并口设备中的,测试同时使用其他并口设备,系统是否可以正确使用.
    比如在INTER,舒龙CPU芯片下系统是否能够正常运行?
    这样的测试必须建立测试实验室,在各种环境下进行测试。

    9.安装测试

    安装测试有两个目的。第一个目的是确保该软件在正常情况和异常情况的不同条件下: 例如,进行首次安装、升级、完整的或自定义的安装_都能进行安装。异常情况包括磁盘空间不足、缺少目录创建权限等。第二个目的是核实软件在安装后可立即正常运行。这通常是指运行大量为功能测试制定的测试。
    安装测试包括测试安装代码以及安装手册。安装手册提供如何进行安装,安装代码提供安装一些程序能够运行的基础数据。

    10.多语种测试

    又称本地化测试,是指为各个地方开发产品的测试,如英文版,中文版等等,包括程序是否能够正常运行,界面是否符合当地习俗,快捷键是否正常起作用等等,特别测试在A语言环境下运行B语言软件(比如在英文win98下试图运行中文版的程序),出现现象是否正常。
    本地化测试还要考虑:
    l 当语言从A翻译到B,字符长度变化是否影响页面效果。比如中文软件中有个按键叫“看广告”,翻译到英文版本中为 “View advertisement”可能影响页面的美观程度
    l 要考虑同一单词在各个国家的不同意思,比如football在英文中为足球,而美国人使用中可能理解为美式橄榄球。
    l 要考虑各个国家的民族习惯,比如龙个美国中被理解邪恶的象征,但翻译到中国,中国人认为为吉祥的象征。

    11.文字测试

    文字测试测试软件中是否拼写正确,是否易懂,不存在二义性,没有语法错误;文字与内容是否有出入等等,包括图片文字。
    比如:“比如,请输入正确的证件号码!”何谓正确的证件号码,证件可以为身份证,驾驶证,也可为军官证,如果改为“请输入正确的身份证号码!”用户就比较容易理解了。

    12.分辨率测试

    测试在不同分辨率下,界面的美观程度,分为800*600,1024*768,1152*864,1280*768,1280*1024,1200*1600大小字体下测试。一个好的软件要有一个极佳的分辨率,而在其他分辨率下也都能可以运行。

    13发布测试

    主要在产品发布前对一些附带产品,比如说明书,广告稿等进行测试

    13.1说明书测试
    主要为语言检查,功能检查,图片检查
    语言检查:检查说明书语言是否正确,用词是否易于理解;
    功能检查:功能是否描述完全,或者描述了并没有的功能等;
    图片检查::检查图片是否正确
    13.2宣传材料测试
    主要测试产品中的附带的宣传材料中的语言,描述功能,图片
    13.3帮助文件测试
    帮助文件是否正确,易懂,是否人性化。最好能够提供检索功能。
    13.4广告用语
    产品出公司前的广告材料文字,功能,图片,人性化的检查

    14 文档审核测试

    文档审核测试目前越来越引起人们的重视,软件质量不是检查出来的,而是融进软件开发中来。前置软件测试发越来越受到重视。请看一个资料:

    文档审核测试主要包括需求文档测试,设计文档测试,为前置软件测试测试中的一部分。

    14.1需求文档测试

    主要测试需求中是否存在逻辑矛盾以及需求在技术上是否可以实现;

    14.2设计文档测试

    测试设计是否符合全部需求以及设计是否合理。

    总结

    据美国软件质量安全中心2000年对美国一百家知名的软件厂商统计,得出这样一个结论:软件缺陷在开发前期发现比在开发后期发现资金,人力上节约90%;软件缺陷在推向市场前发现比在推出后发现资金,人力上节约90%。所以说软件的缺陷应该尽早发现。不是所有的软件都要进行任何类型的软件测试的,可以根据产品的具体情况进行组装测试不同的类型。
  • 软件测试类型知多少?

    2007-04-14 13:11:16

    软件测试类型知多少?

    软件测试的类型多种多样,测试类型与被测软件的测试需求相关。对于初学者,需要了解最常见的测试类型,也有必要了解其他的测试类型,作为进一步提高的目标。 

    以下转载了比较齐全的测试类型,请那位朋友帮助把全文翻译一下。

    • 黑盒测试(Black box testing)
      • not based on any knowledge of internal design or code. Tests are based on requirements and functionality.
    • 白盒测试(White box testing)
      • based on knowledge of the internal logic of an application's code. Tests are based on coverage of code statements, branches, paths, conditions.
    • 单元测试(unit testing)
        
      • the most 'micro' scale of testing; to test particular functions or code modules. Typically done by the programmer and not by testers, as it requires detailed knowledge of the internal program design and code. Not always easily done unless the application has a well-designed architecture with tight code; may require developing test driver modules or test harnesses.
    • 增量集成测试(incremental integration testing)
      • continuous testing of an application as new functionality is added; requires that various aspects of an application's functionality be independent enough to work separately before all parts of the program are completed, or that test drivers be developed as needed; done by programmers or by testers.
    • 集成测试(integration testing)
      • testing of combined parts of an application to determine if they function together correctly. The 'parts' can be code modules, individual applications, client and server applications on a network, etc. This type of testing is especially relevant to client/server and distributed systems.
    • 功能测试(functional testing)
      • black-box type testing geared to functional requirements of an application; this type of testing should be done by testers. This doesn't mean that the programmers shouldn't check that their code works before releasing it (which of course applies to any stage of testing.)
    • 系统测试(system testing)
      • black-box type testing that is based on overall requirements specifications; covers all combined parts of a system.
    • 端到端测试(end-to-end testing)
      • similar to system testing; the 'macro' end of the test scale; involves testing of a complete application environment in a situation that mimics real-world use, such as interacting with a database, using network communications, or interacting with other hardware, applications, or systems if appropriate.
    • 健全测试或冒烟测试(sanity testing or smoke testing)
      • typically an initial testing effort to determine if a new software version is performing well enough to accept it for a major testing effort. For example, if the new software is crashing systems every 5 minutes, bogging down systems to a crawl, or corrupting databases, the software may not be in a 'sane' enough condition to warrant further testing in its current state.
    • 回归测试(regression testing)
      • re-testing after fixes or modifications of the software or its environment. It can be difficult to determine how much re-testing is needed, especially near the end of the development cycle. Automated testing tools can be especially useful for this type of testing.
    • 验收测试(acceptance testing)
      • final testing based on specifications of the end-user or customer, or based on use by end-users/customers over some limited period of time.
    • 负载测试(load testing)
      • testing an application under heavy loads, such as testing of a web site under a range of loads to determine at what point the system's response time degrades or fails.
    • 压力测试(stress testing)
      • term often used interchangeably with 'load' and 'performance' testing. Also used to describe such tests as system functional testing while under unusually heavy loads, heavy repetition of certain actions or inputs, input of large numerical values, large complex queries to a database system, etc.
    • 性能测试(performance testing)
      • term often used interchangeably with 'stress' and 'load' testing. Ideally 'performance' testing (and any other 'type' of testing) is defined in requirements documentation or QA or Test Plans.
    • 易用性测试(usability testing)
      • testing for 'user-friendliness'. Clearly this is subjective, and will depend on the targeted end-user or customer. User interviews, surveys, video recording of user sessions, and other techniques can be used. Programmers and testers are usually not appropriate as usability testers.
    • 安装/卸载测试(install/uninstall testing)
      • testing of full, partial, or upgrade install/uninstall processes.
    • 恢复测试(recovery testing)
      • testing how well a system recovers from crashes, hardware failures, or other catastrophic problems.
    • 故障复原测试(failover testing)
      • typically used interchangeably with 'recovery testing'
    • 安全性测试(security testing)
      • testing how well the system protects against unauthorized internal or external access, willful damage, etc; may require sophisticated testing techniques.
    • 兼容性测试(compatability testing)
      • testing how well software performs in a particular hardware/software/operating system/network/etc. environment.
    • 探索性测试(exploratory testing)
      • often taken to mean a creative, informal software test that is not based on formal test plans or test cases; testers may be learning the software as they test it.
    • 随机测试(ad-hoc testing)
      • similar to exploratory testing, but often taken to mean that the testers have significant understanding of the software before testing it.
    • 上下文驱动测试(context-driven testing)
      • testing driven by an understanding of the environment, culture, and intended use of software. For example, the testing approach for life-critical medical equipment software would be completely different than that for a low-cost computer game.
    • 用户验收测试(user acceptance testing)
      • determining if software is satisfactory to an end-user or customer.
    • 对比测试(comparison testing)
      • comparing software weaknesses and strengths to competing products.
    • Alpha 测试(alpha testing)
      • testing of an application when development is nearing completion; minor design changes may still be made as a result of such testing. Typically done by end-users or others, not by programmers or testers.
    • Beta测试(beta testing)
      • testing when development and testing are essentially completed and final bugs and problems need to be found before final release. Typically done by end-users or others, not by programmers or testers.
    • 植入测试(mutation testing)
      • a method for determining if a set of test data or test cases is useful, by deliberately introducing various code changes ('bugs') and retesting with the original test data/cases to determine if the 'bugs' are detected. Proper implementation requires large computational resources.

    原始出处:http://www.softwareqatest.com/qatfaq1.html

543/3<123
Open Toolbar