叶子，软件测试sky下度过四载生涯。 若干手机测试和web测试经验，对性能测试和测试工具稍有所得。希望以后能更加踏实的走向属于我的明天~~ 希望在测试的道路上有更多的同路人。

我的最新日志

  • 分享：国际化软件测试简介

    2008-8-19

    文章作者：崔启亮   文章来源：中国本地化网   发表时间：2005-7-13 11:08:00

    国际化软件测试是近年来逐渐发展的新兴测试领域，与传统的面向单一区域和语言的常规软件测试相比，具有很多不同的特征，表现在跨区域的全球测试、测试内容广泛、测试周期时效性强等多个方面。

    1. 跨国家/地区的全球测试

    国际化测试的各方分布在不同的国家和地区，是典型的全球分布测试，离岸外包测试的兴起使得全球测试的特征愈加明显。由于测试各方相隔遥远，因地区时差、文化观念和办公时间等的差异增加了国际化软件测试管理的复杂程度，要求测试管理人员具有较强的区域协调能力、交流沟通能力、远程项目跟踪和控制能力。

    国际化软件测试的参与各方包括软件开发商的质量保证人员、技术支持人员和软件开发人员以及测试管理人员；软件测试服务商的软件测试人员、质量保证人员和测试管理人员；软件开发商在各个国家/地区的分支机构或其邀请委托的行业领域专家（技术和语言方面）；软件外包测试服务商邀请委托的行业领域专家（技术和语言方面）。

     2. 核心功能测试为基础，软件国际化和本地化测试为重点

    国际化测试的测试内容广泛，包括核心功能/性能测试、国际化特征测试和本地化测试。

    核心功能测试以测试软件的功能和性能为主。从测试阶段可以细分为单元测试、集成测试、系统测试和验收测试；从测试实现方式上可以分为手工测试和自动测试。

    国际化特征测试包括国际化支持能力测试和本地化能力测试。国际化支持能力测试在于发现软件支持不同区域数据的能力，例如日期、时间、数字、货币和不同语言字符集；本地化能力测试在于检测软件是否考虑了本地化的方便性，是否容易实现本地化而不需要修改软件源代码。

    本地化测试包括本地化功能测试和本地化语言质量测试。本地化功能测试检测软件本地化后的软件的功能是否全部可用，不会丢失某些功能；本地化语言质量测试在于测试软件本地化的文字是否准确、一致、符合当地用户的表达习惯，还包括对软件的用户界面进行外观测试，本地化的字符串能够完整地显示在软件界面上。依据本地化软件的语言数量，多种语言的版本往往与源语言版本同时展开测试。

    3. 复杂的测试项目管理

    国际化软件是一项复杂的系统工程，参与的公司和人员分布在全球各地，需要同步本地化的语言可能超过几十种，报告的软件缺陷数量可能多达几千上万，而且由于软件外包将带来很多交流和管理的问题。因此，对国际化软件测试管理提出了更高的要求，项目计划和预算管理与跟踪，测试文档管理、测试缺陷管理、技术支持和沟通交流等都比传统的软件测试项目复杂。

    4. 测试周期时效性强

    随着软件市场全球竞争的加剧，软件的开发周期不断缩短，对于全球发布的国际化软件来说，越来越多的国际大型软件公司追求多语言版本与源语言版本同时发布或者相隔时间尽量缩短。为了达到同步发布的目的，软件的国际化测试和本地化测试以及核心功能测试需要与软件开发过程并行进行。由于软件测试依赖于软件开发过程，而且随着软件项目周期的缩短，留给软件测试的时间经常比较紧张，尤其在软件即将发布的后期测试，对测试时间提出了较为苛刻的要求。

     

    查看(22) 评论(0)

  • 外派的出路

    2008-8-01

    外派，一个在IT领域一点都不陌生的词汇。外语一般称之为on-site

    在中国已经有一段时间的历史了。

    外派，最初对于所有人来说都是一个美丽的梦

    因为门槛或者技术或者外语等等限制，想到世界top级别公司上班却无法去的人，可以作为某一个外派公司员工的身份，可以以技术，外语以及门槛略低的条件进入那样的公司工作。如果表现突出，则可以找到合适的时机，成为梦想中的公司的正式员工。

    外派，走到了今天，又几乎成了很多人的一个伤痛

    因为外派，工作地点不在自己的公司，除了当初找自己进门的hr,公司小的领导会认识你，公司大的领导都不会知道你这个人的存在，除非你惹出了大的麻烦。。公司的福利待遇，公司的免费培训，公司的员工的归属感，优越感。。等等都与你天生没有关系。。

    而你派往的那家公司，即使知名度很高，既是薪资待遇很高，福利很高，对员工很人性化，跟你也没有关系。因为你不是他们的员工，他们的待遇几乎可以说是天经地义的跟你没有任何关系。虽然你在为他们干活。

    劳动力成本在上升，公司在缩减成本第一个想到的就是把项目到期，后续项目没有消息的你，开出去。。

    于是，你回到了似乎陌生又似乎熟悉的自己的公司。

    面对的是公司老总一张阴沉不定的脸。良久，告诉你说，因为你没有项目了，暂时无法给公司创造价值。所以经过公司领导的商议，决定给你开基本工资-800抑或1000，等你找到项目，工资再行调整。。

    于是，你无语问苍天，于是，你终于知道，外派，原来是这样的一个过程。。

    这不是开玩笑，是真实的发生在我身边很多外派同仁的故事。

    写到这里，我想说，如此的待遇，如果你是外派员工，你还会以外派的身份工作多久？还能坚持多久？

    同样，秉承着有项目有待遇，只能从员工汗水中榨取剩余价值，却无法为员工分担风险的外包公司？你的路还能走多远？

    查看(134) 评论(3)

  • 软件测试的目的

    2008-7-29

    一个很古老的话题

    每一本书都会有自己的解释，无论作者有多少的测试体会

    每一个人都会有自己的觉悟，而不论有多少的经验

    民间的包括所谓官方的（IEEE）,如果你愿意，可以在网络上都到成千上万也不同的说法。

    软件测试的目的到底是什么？

    相信每一个步入测试领域的人都曾经问过或者想过这样的问题

    这个问题也曾在我学习的过程中困扰了我许久许久。

    最终，至少在理论上我们可以找到这样的答案：

    软件测试的目的在于通过各种手段来验证需求的正确性

    软件测试的目的在于尽早的发现bug..

    但是实际的测试中，我们发现，我们测试的目的其实是两者兼有的。

    如果说测试的目的在于验证需求的正确性，没有什么不对。验证的方法也多种多样，比如静态/动态的测试，比如通过性和破坏性测试，比如黑盒测试和白盒测试，比如手动测试和自动化测试。。

    只不过，验证需求的正确性作为目的话似乎也不全面。原因在于，1.发行bug一定程度上可以激发测试人员的测试积极性。在很多的公司，也是考核测试人员绩效的一个很重要的数据。2.用最少的测试用例，在最短的时间内发现迄今为止没有发现出来的bug，特别是对系统影响深远的bug对于一个产品的成败有着很大的意义，对于客户的修复成本也有重要的意义。如果仅仅因为验证需求，有一些潜在的问题就不会有人有那么大的兴趣去挖掘。最终的结果就会导致，测试的质量在某种程度上难以保证。

    但是发行bug也绝对不是软件测试的唯一目的。其道理很简单。一味的强调bug的重要性，发行bug作为测试的唯一目的势必导致测试人员盲目的为了发行defect而偏离了测试的重心。

    所以软件测试的目的应该是双方面的，通过各种手段验证软件的需求，并且尽早的发现bug以促使软件得到尽快的修复。

    首先，保证了第一方面，验证软件的需求，可以保证测试的覆盖率，客户关注的功能可以不被忽视。尽早的发现和发行bug,可以促使问题可以得到早日的解决，对于客户来说，也可以节约大量的修复成本。

    测试之路，路漫漫，其修远兮，吾将上下而求索。。

     

     

    查看(44) 评论(0)

  • 测试同化现象

    2008-7-28

    前几日，和同事讨论起这个问题，偶有所感

    1。 何谓测试同化现象

    所谓同化现象，一方面是指随着时间的推移，开发人员会逐渐影响测试人员的思维和对缺陷的判断能力，尤其是针对同一产品，同一组开发人员和同一组测试人员共同配合了很长时间，很多本来是缺陷的问题，由于测试人员对软件“习惯成自然”的使用，会不被当成缺陷，尤其是在开发人员的解释和说服下。这是从主观上讲，也就是说从人的主观能动性上来讲这个现象。

    此类同化现象的发生可能意味着“恶性循环”的开始：测试人员会帮着开发人员解释一个个缺陷的合理性，一轮有一轮的测试都不会发现问题。可是这种没有问题却真正的意味着软件风险的扩大。


    从另外一方面来讲，测试同化现象也被称之为“杀虫剂现象。术语“杀虫剂现象”（1990年，Boris Berizer在其《software testing techniques》中杜撰了“杀虫剂怪事”）用来描述软件测试越多，其对测试的免疫力就越强的现象。同样的事情发生在对昆虫使用杀虫剂上。如果你总是用同样一种农药，害虫最后就有了抵抗力，杀虫剂将不再发挥作用。

    这样的现象是从客观角度来看。不是因为人为的疏忽而是一种客观无法回避的事实。

    2。如何避免测试的同化

    很多人建议说，应该多发布测试版本，应该多招聘新的测试人员来避免这样的事情。而实际上，这不是能解决这个问题的根本。

    从主观来说，主观方面造成测试同化的原因是在于人的因素。是习惯了开发人员思维，并且相信了开发人员解说的人造成的一部分测试同化。对于这样的原因，用招聘新的测试人员来觉得其实是不明智的。

    首先要加强测试人员的自我修养，让他们认识到测试的原则在哪里，而且要挖掘自己的怀疑精神（怀疑精神是测试人员的必要的素质之一），不能轻易相信开发人员似是而非的理论。要学会一切用事实证据说话，没有证据证明的东西不要轻易的去相信。

    另外要加强测试员之间的互动，不能由一个测试员总是测试相同的测试项目/模块。而是要时常进行轮换，这样一方面可以避免之前被遗漏的点尽快地被找出来，也会避免因为太熟悉而忽略某个测试的严格度。当然对于主观上确保降低测试同化，也起到很大的作用。

    对于客观方面成就的测试同化，测试员应该养成从多角度来观察问题的习惯。并且在自己之前设计的测试用例，几轮之后已经无法测试出bug的时候，要学会补充设计新的测试用例，从而从别的角度发现新的问题。

    查看(9) 评论(0)

  • 软件测试的原则

    2008-7-28

     
    1)1.在测试工作开始以前，不应设想程序中没有缺陷或找不出缺陷。（测试心理学)
    2)2.测试以前应预知测试的结果数据。
    3)3.程序员尽可能避免测试自己写的程序。坚持独立测试原则，必要的情况下建立独立测试机构。
    4)4.测试用例应兼顾有效输入和无效输入。即 不仅要检验程序是否做了该做的事，还应检验是否做了不该做的事。 事实也证明，忽视无效输入的测试往往会遗漏在复杂或者非常态下的重大问题。5)6)测试的充分性。
    7)5.测试的有效性。
    8)6.限于人力、物力，测试工作适可而止。最优化测试的图表还记得吗？（测试经济学）
    9)7.保留一切测试用例。 这些测试用例也属于测试成果物的一部分。此外还有提交的缺陷文件，测试数据等等。这对于测试结束后，下一个版本的更新都是重要的参考资料。
    10)8.任何已测程序的变更都应重新进行测试。这也是回归测试的重要意义和原则。不能因为以前没有问题，在发生版本变更或者程序修改的时候就忽视对其的测试。不进行相对的充分测试，是无法知道修改到底是否导致了多少个模块发生了变化。
     

    查看(88) 评论(2)

  • 转：软件测试基础：测试用例设计

    2008-7-03

    测试需求收集完毕后，开始测试设计。测试用例是什么？测试用例就是一个文档，描述输入、动作、或者时间和一个期望的结果，其目的是确定应用程序的某个特性是否正常的工作。设计测试用例需要考虑以下问题：

    测试用例的基本格式

    软件测试用例的基本要素包括测试用例编号、测试标题、重要级别、测试输入、操作步骤、预期结果，下面逐一介绍。

    用例编号： 测试用例的编号有一定的规则，比如系统测试用例的编号这样定义规则： PROJECT1-ST-001 ，命名规则是项目名称＋测试阶段类型（系统测试阶段）＋编号。定义测试用例编号，便于查找测试用例，便于测试用例的跟踪。

    测试标题： 对测试用例的描述，测试用例标题应该清楚表达测试用例的用途。比如 “ 测试用户登录时输入错误密码时，软件的响应情况 ” 。

    重要级别： 定义测试用例的优先级别，可以笼统的分为 “ 高 ” 和 “ 低 ” 两个级别。一般来说，如果软件需求的优先级为 “ 高 ” ，那么针对该需求的测试用例优先级也为 “ 高 ” ；反之亦然，

    测试输入： 提供测试执行中的各种输入条件。根据需求中的输入条件，确定测试用例的输入。测试用例的输入对软件需求当中的输入有很大的依赖性，如果软件需求中没有很好的定义需求的输入，那么测试用例设计中会遇到很大的障碍。

    操作步骤： 提供测试执行过程的步骤。对于复杂的测试用例，测试用例的输入需要分为几个步骤完成，这部分内容在操作步骤中详细列出。

    预期结果： 提供测试执行的预期结果，预期结果应该根据软件需求中的输出得出。如果在实际测试过程中，得到的实际测试结果与预期结果不符，那么测试不通过；反之则测试通过。

    软件测试用例的设计主要从上述 6 个域考虑，结合相应的软件需求文档，在掌握一定测试用例设计方法的基础上，可以设计出比较全面、合理的测试用例。具体的测试用例设计方法可以参见相关的测试书籍，白盒测试方法和黑盒测试方法在绝大多数的软件测试书籍中都有详细的介绍，这里不作赘述。

    重用同类型项目的测试用例

    如果我看得远，那是因为我站在巨人的肩上 －－牛顿。

    一般来说，每个软件公司的项目可以分为固定的几大类。可以按业务类型划分，比如 ERP 软件、产品数据管理软件、通信软件、地理信息系统软件等等；可以按软件结构来划分，比如 B/S 架构的软件、 C/S 架构的软件、嵌入式软件等等。参考同类别软件的测试用例，会有很大的借鉴意义。如果，公司中有同类别的软件系统，千万别忘记把相关的测试用例拿来参考。如果，系统非常接近，甚至经过对测试用例简单修改就可以应用到当前被测试的软件。 “ 拿来主义 ” 可以极大的开阔测试用例设计思路，也可以节省大量的测试用例设计时间。

    利用已有的软件 Checklist

    在上面一个小节中，按照不同的规则划分了不同的软件类型。每种类型的软件都有一定的测试规范，比如， WEB 软件系统在系统测试过程中，会有一系列的范式，比如针对 Cookie 就会有很多测试点。在设计测试用例的时候，不妨到网上去搜索相关的 Checklist ，不过国内外的网站很少有这方面的资料，即便有，也不是特别系统。可以先找一份粗糙的 Checklist ，然后，在设计测试用例的时候不断的去完善它，以作为下次测试用例设计的基础。

    加强测试用例的评审

    测试用例设计完毕后，最好能够增加评审过程。同行评审是 CMM3 级的一个 KPA ，如果因为公司没有通过 CMM3 级，就不开展同行评审是不恰当的。测试用例应该由产品相关的软件测试人员和软件开发人员评审，提交评审意见，然后根据评审意见更新测试用例。如果认真操作这个环节，测试用例中的很多问题都会暴露出来，比如用例设计错误、用例设计遗漏、用例设计冗余、用例设计不充分等等；如果同行评审不充分，那么，在测试执行的过程中，上述本应在评审阶段发现的测试用例相关问题，会给测试执行带来大麻烦，甚至导致测试执行挂起。

    定义测试用例的执行顺序
    　　　
    在测试用例执行过程中，你会发现每个测试用例都对测试环境有特殊的要求，或者对测试环境有特殊的影响。因此，定义测试用例的执行顺序，对测试的执行效率影响非常大。比如某些异常测试用例会导致服务器频繁重新启动，服务器的每次重新启动都会消耗大量的时间，导致这部分测试用例执行也消耗很多的时间。那么在编排测试用例执行顺序的时候，应该考虑把这部分测试用例放在最后执行，如果在测试进度很紧张的情况下，如果优先执行这部分消耗时间的异常测试用例，那么在测试执行时间过了大半的时候，测试用例执行的进度依然是缓慢的，这会影响到测试人员的心情，进而导致匆忙地测试后面的测试用例，这样测试用例的漏测、误测就不可避免，严重影响了软件测试效果和进度。因而，合理地定义测试用例的执行顺序是很有必要的。
    　　
    测试用例执行
    　　
    测试用例设计完毕后，接下来的工作是测试执行，测试执行中应该注意以下几个问题：
    　　
    搭建软件测试环境，执行测试用例
    　　
    测试用例执行过程中，搭建测试环境是第一步。一般来说，软件产品提交测试后，开发人员应该提交一份产品安装指导书，在指导书中详细指明软件产品运行的软硬件环境，比如要求操作系统系统是 Windows 2000 pack4 版本，数据库是 Sql Server 2000 等等，此外，应该给出被测试软件产品的详细安装指导书，包括安装的操作步骤、相关配置文件的配置方法等等。对于复杂的软件产品，尤其是软件项目，如果没有安装指导书作为参考，在搭建测试环境过程中会遇到种种问题。
    　　
    如果开发人员拒绝提供相关的安装指导书，搭建测试中遇到问题的时候，测试人员可以要求开发人员协助，这时候，一定要把开发人员解决问题的方法记录下来，避免同样的问题再次请教开发人员，这样会招致开发人员的反感，也降低了开发人员对测试人员的认可程度。
    　　
    测试执行过程应注意的问题
    　　
    测试环境搭建之后，根据定义的测试用例执行顺序，逐个执行测试用例。在测试执行中需要注意以下几个问题：
    　　
    全方位的观察测试用例执行结果： 测试执行过程中，当测试的实际输出结果与测试用例中的预期输出结果一致的时候，是否可以认为测试用例执行成功了？答案是否定的，即便实际测试结果与测试的预期结果一致，也要查看软件产品的操作日志、系统运行日志和系统资源使用情况，来判断测试用例是否执行成功了。全方位观察软件产品的输出可以发现很多隐蔽的问题。以前，我在测试嵌入式系统软件的时候，执行某测试用例后，测试用例的实际输出与预期输出完全一致，不过在查询 CPU 占用率地时候，发现 CPU 占用率高达 90 ％，后来经过分析，软件运行的时候启动了若干个 1ms 的定时器，大量的消耗的 CPU 资源，后来通过把定时器调整到 10ms ， CPU 的占用率降为 7 ％。如果观察点单一，这个严重消耗资源的问题就无从发现了。
    　　
    加强测试过程记录： 测试执行过程中，一定要加强测试过程记录。如果测试执行步骤与测试用例中描述的有差异，一定要记录下来，作为日后更新测试用例的依据；如果软件产品提供了日志功能，比如有软件运行日志、用户操作日志，一定在每个测试用例执行后记录相关的日志文件，作为测试过程记录，一旦日后发现问题，开发人员可以通过这些测试记录方便的定位问题。而不用测试人员重新搭建测试环境，为开发人员重现问题。
    　　
    及时确认发现的问题： 测试执行过程中，如果确认发现了软件的缺陷，那么可以毫不犹豫的提交问题报告单。如果发现了可疑问题，又无法定位是否为软件缺陷，那么一定要保留现场，然后知会相关开发人员到现场定位问题。如果开发人员在短时间内可以确认是否为软件缺陷，测试人员给予配合；如果开发人员定位问题需要花费很长的时间，测试人员千万不要因此耽误自己宝贵的测试执行时间，可以让开发人员记录重新问题的测试环境配置，然后，回到自己的开发环境上重现问题，继续定位问题。
    　　
    与开发人员良好的沟通： 测试执行过程中，当你提交了问题报告单，可能被开发人员无情驳回，拒绝修改。这时候，只能对开发人员晓之以理，做到有理、有据，有说服力。首先，要定义软件缺陷的标准原则，这个原则应该是开发人员和测试人员都认可的，如果没有共同认可的原则，那么开发人员与测试人员对问题的争执就不可避免了。此外，测试人员打算说服开发人员之前，考虑是否能够先说服自己，在保证可以说服自己的前提下，再开始与开发人员交流。
    　　
    及时更新测试用例
    　　
    测试执行过程中，应该注意及时更新测试用例。往往在测试执行过程中，才发现遗漏了一些测试用例，这时候应该及时的补充；往往也会发现有些测试用例在具体的执行过程中根本无法操作，这时候应该删除这部分用例；也会发现若干个冗余的测试用例完全可以由某一个测试用例替代，那么删除冗余的测试用例。
    　　
    总之，测试执行的过程中及时地更新测试用例是很好的习惯。不要打算在测试执行结束后，统一更新测试用例，如果这样，往往会遗漏很多本应该更新的测试用例。
    　　
    提交一份优秀的问题报告单
    　　
    软件测试提交的问题报告单和测试日报一样，都是软件测试人员的工作输出，是测试人员绩效的集中体现。因此，提交一份优秀的问题报告单是很重要的。软件测试报告单最关键的域就是 “ 问题描述 ” ，这是开发人员重现问题，定位问题的依据。问题描述应该包括以下几部分内容：软件配置、硬件配置、测试用例输入、操作步骤、输出、当时输出设备的相关输出信息和相关的日志等。
    　　
    软件配置： 包括操作系统类型版本和补丁版本、当前被测试软件的版本和补丁版本、相关支撑软件，比如数据库软件的版本和补丁版本等。
    　　
    硬件配置： 计算机的配置情况，主要包括 CPU 、内存和硬盘的相关参数，其它硬件参数根据测试用例的实际情况添加。如果测试中使用网络，那么网络的组网情况，网络的容量、流量等情况。硬件配置情况与被测试产品类型密切相关，需要根据当时的情况，准确翔实的记录硬件配置情况。
    　　
    测试用例输入 \ 操作步骤 \ 输出： 这部分内容可以根据测试用例的描述和测试用例的实际执行情况如实填写。
    　　
    输出设备的相关输出信息： 输出设备包括计算机显示器、打印机、磁带等等输出设备，如果是显示器可以采用抓屏的方式获取当时的截图，其他的输出设备可以采用其它方法获取相关的输出，在问题报告单中提供描述。
    　　
    日志信息： 规范的软件产品都会提供软件的运行日志和用户、管理员的操作日志，测试人员应该把测试用例执行后的软件产品运行日志和操作日志作为附件，提交到问题报告单中。
    　　
    根据被测试软件产品的不同，需要在 “ 问题描述 ” 中增加相应的描述内容，这需要具体问题具体分析。
    　　
    测试结果分析
    　　
    软件测试执行结束后，测试活动还没有结束。测试结果分析是必不可少的重要环节， “ 编筐编篓，全在收口 ” ，测试结果的分析对下一轮测试工作的开展有很大的借鉴意义。前面的 “ 测试准备工作 ” 中，建议测试人员走读缺陷跟踪库，查阅其他测试人员发现的软件缺陷。测试结束后，也应该分析自己发现的软件缺陷，对发现的缺陷分类，你会发现自己提交的问题只有固定的几个类别；然后，再把一起完成测试执行工作的其他测试人员发现的问题也汇总起来，你会发现，你所提交问题的类别与他们有差异。这很正常，人的思维是有局限性，在测试的过程中，每个测试人员都有自己思考问题的盲区和测试执行的盲区，有效的自我分析和分析其他测试人员，你会发现自己的盲区，有针对性的分析盲区，必定会在下一轮测试用避免盲区。

     

    查看(110) 评论(0)

  • 转：关于测试的一些技巧和经验

    2008-7-01

    在制定测试计划的时候，就要考虑到测试的风险，并抉择要执行哪些测试，并放弃哪些测试；测试计划的评审应该让开发人员参与；测试模型的制作应该尽可能贴近用户，或者站在用户的使用立场上来观测软件，此时应该能发现更多的问题。

    　由于测试发现问题，在解决问题后还要重新测试，因此测试的时间可能会比实际更长一些

    　识别和注意少数重要的方面，而忽略多数次要的方面，有时候少数的问题足以致命，这些问题将是软件测试结果中重要性最高的错误。

    　错误的定位有时是很难的，要找出必然发生的前因后果，而不至于因为描述错误而误导开发人员。有时候确实存在错误不能重建的问题。解决办法之一是在错误报告中给予说明。

    　对错误的描述，应该是准确、完整而简练。因为描述的问题或者不完整的描述会引起开发人员的误解，其后果是可以想见的。

    　有时有经验的测试人员凭借直觉就可以发现一些问题，这可称为“错误猜测”。

    　测试人员容易犯2种错误：一是测试人员发生判断错误，将本没有错误的系统行为报告为错误，或者将错误指定了过高的严重级别，或者过高估计了问题的严重性，这样会引起开发人员的不信任，产生一种象“狼来了”一样的效果；二是测试人员将错误的严重性或优先级定得过低，从而产生“测试逃逸”，这样会造成产品质量的风险。以上两种错误应该尽量避免

    查看(86) 评论(0)

  • 转载：应该考虑进行何种测试

    2008-7-01

    黑盒测试(Black box testing)  ____不考虑内部设计和代码,根据需求和功能进行测试

    白盒测试 (White box testing) ── 根据应用软件的代码的内部逻辑，按照代码的语句、分支、路径和条件进行测试。

    部件测试 (Unit testing) ——最小范围的测试,针对特定的函数和代码模块进行测试。因为需要了解程序的设计和代码的细节才能进行，所以部件测试一般是程序员。而不是由测试人员来做。除非应用软件的结构设计良好，而且代码也写得清楚，否则部件测试并非易事。也许需要开发测试驱动模块或测试工具。

    递增的综合测试（incremental integration testing）——不断进行的测试过程，每增加一个新的功能模块，都进行测试。这要求一个应用软件在最终完成之前，各功能模块要相对独立，或者已根据需要开发出测试驱动软件。这种测试可由程序员或测试人员进行。

    综合测试（integration testing）——对应用软件的各个部分进行组合测试，来检查各功能模块在一起工作是否正常，“部件“可以是代码模块、独立的应用程序、也可以是网络中的客户/服务器应用软件。这种测试特别使用客户/服务器环境和分布式系统

    功能测试（functional testing）——对一个应用软件的功能模块进行黑盒测试。这种测试应当由测试人员进行。但这并不意味着程序员在推出软件之前不进行代码检查。（这一原则适用于所有的测试阶段。）

    系统测试 —— 针对全部需求说明进行黑盒测试，包括系统中所有的部件

    端到端测试 (end-to-end testing) ── 类似于系统测试，但测试范围更“宏观”一些。模仿实际应用环境，对整个应用软件进行使用测试。例如与数据库进行交互作业、使用网络通信、与其他硬件、应用程序和系统之间的相互作用是否满足要求。

    健全测试 (sanity testing) ── 是一种典型的初始测试。判断一个新的软件版本的运行是否正常，是否值得对它作进一步的测试。例如，如果一个新的软件每 5 分钟就破坏系统、大大降低系统的运行速度、或者破坏数据库，那么这样的软件就算不上是“健全”的，不值得在目前状态下进行进一步的测试。

    回归测试 (regression testing) ── 每当软件经过了整理、修改、或者其环境发生变化，都重复进行测试。很难说需要进行多少次回归测试，特别是是到了开发周期的最后阶段。进行此种测试，特别适于使用自动测试工具。

    认同测试 (acceptance testing) ── 基于说明书的、由最终用户或顾客来进行的测试。或者由最终用户/顾客来进行一段有限时间的使用。

    负荷试验 (load testing) ── 在大负荷条件下对应用软件进行测试。例如测试一个网站在不同负荷情况下的状况，以确定在什么情况下系统响应速度下降或是出现故障。

    压力测试 (stress testing) ── 经常可以与“负荷测试”或“性能测试”相互代替。这种测试是用来检查系统在下列条件下的情况：在非正常的巨大负荷下、某些动作和输入大量重复、输入大数、对数据库进行非常复杂的查询，等等。

    性能测试 (performance testing) ── 经常可以与“压力测试”或“负荷测试”相互代替。理想的“性能测试”(也包括其他任何类型的测试) 都应在质量保障和测试计划的文档终予以规定。

    可用性测试 (usability testing) ── 是专为“对用户友好”的特性进行测试。这是一种主观的感觉，取决于最终用户或顾客。可以进行用户会见、检查、对用户会议录像、或者使用其他技术。程序员和测试人员通常不参加可用性测试。

    安装/卸载测试 (install/uninstall testing) ── 对安装/卸载进行测试 (包括全部、部分、升级操作)。

    恢复测试 (recovery testing) ── 在系统崩溃、硬件故障、或者其他灾难发生之后，重新恢复系统的情况。

    安全测试 (security testing) ── 测试系统在应付非授权的内部/外部访问、故意的损坏时的防护情况。这需要精密复杂的测试技术。 

    兼容性测试 (compatability testing) ── 测试在特殊的硬件/软件/操作系统/网络环境下的软件表现。

    认同测试 (acceptance testing) ── 看顾客是否对软件满意。

    比较测试 (comparison testing) ── 与竞争产品进行比较，以找出弱点和优势。

     α 测试 (alpha testing) ── 在开发一个应用软件即将完成时所进行的测试。此时还允许有较小的设计修改。通常由最终用户或其他人进行这种测试，而不是由程序员和测试人员来进行。

     β 测试 (beta testing) ── 当开发和测试已基本完成，需要在正式发行之前最后寻找毛病而进行的测试。通常由最终用户或其他人进行这种测试，而不是由程序员和测试人员来进行。

    查看(44) 评论(1)

  • 转载：软件评测师学习笔记--黑盒测试

    2008-7-01

    软件评测师学习笔记之一－黑盒测试

    2005-4-18
     黑盒测试
    一． 黑盒测试概述（2.10 黑盒测试）
    1    ．定义
    l     也称功能测试，它是通过测试来检测每个功能是否都能正常使用
    l     把程序看成一个黑盒子，完全不考虑程序内部结构和内部特性，着眼于程序外部结构，不考虑内部逻辑结构
    l     在程序接口进行测试，只检查程序功能是否按照需求说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息
    l     主要针对软件界面和软件功能进行测试
    2    ．试图发现的错误类型
    l     功能不正确或遗漏
    l     界面错误（输入能否正确的接受？能否输出正确的结果）
    l     数据库访问错误（如数据结构定义错误或外部信息（如数据文件）访问错误）
    l     性能错误
    l     初始化和终止错误
    3    ．黑盒测试用例设计方法
    （1） 等价类划分法：把程序的输入域划分成若干部分，然后从每个部分中选取少数代表性数据作为测试用例。每一类的代表性数据在测试中的作用等价于这一类的其他值
    （2） 边界值分析法：通过选择等价类边界的测试用例。不仅重视输入条件边界，而且也必须考虑输出域边界
    （3） 错误推测法：基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性地设计测试用例的方法
    （4） 因果图法：从用自然语言书写的程序规格说明的描述中找出因（输入条件）和果（输入或程序状态的改变），可以通过因果图转换成判定表
    （5） 判定表驱动法：利用判定表进行测试用例的设计
    （6） 正交试验设计法：使用已设计好的正交表格来安排试验，并进行数据分析的一种方法，目的是用最少的测试用例达到最高的测试覆盖率
    （7） 功能图法：用功能图形象地表示程序的功能说明，并机械地生成功能图的测试用例。功能图模型由状态迁移图和逻辑功能模型构成
    二． 黑盒测试用例设计方法
    1    ．等价类划分法
    （1）划分基础：需求规格说明书中输入、输出要求
    （2）等价类：某个输入域的子集合；分为有效等价类和无效等价类
    l     有效等价类：指对于程序规格说明书来说是合理的、有意义的输入数据构成的集合。利用有效等价类可以检验程序是否实现了规格说明书中的功能和性能
    l     无效等价类：与有效等价的定义恰巧相反
    （3）划分等价类原则（6条）
    序号 输入条件（数据） 划分等价类
    1     规定了取值范围值的个数 一个有效等价类两个无效等价类
    2     规定了输入值的集合规定了“必须如何”的条件 一个有效等价类一个无效等价类
    3     是一个布尔量 一个有效等价类一个无效等价类
    4     输入数据的一组值（n个），并且程序对每一个输入值分别进行处理 n个有效等价类一个无效等价类
    5     规定必须遵守的规则 一个有效等价类（符合规则）若干个无效等价类
    6     在确知已划分的等价类中，各元素在程序处理中的方式不同的情况下，则应再将该等价类进一步地划分为更小的等价类
        
    （4） 列出等价类表
    在确定了等价类之后，建立等价类表，列出所有划分出的等价类
    输入条件 有效等价类 无效等类
    …… …… ……
    （5） 确定测试用例步骤
    l     第一步：为每个等价类规定一个惟一的编号
    l     第二步：设计一个新的测试用例，使其尽可能多地覆盖尚未覆盖的有效等价类。重复这一步骤，最后使得所有有效等价类均被测试用例所覆盖
    l     第三步：设计一个新的测试用例，使其只覆盖一个无效等价类。重复这一步骤，最后使得所有有效等价类均被测试用例所覆盖
    小结：采用等价类划分方法设计测试用例，按照划分等价类、列出等价列表、确定测试用例三个步骤完成，目标是把可能的测试用例组合缩减到仍然足以满足软件测试需求为止。
    2    ．边界值分析法
    （1） 边界类型
    l     边界条件：可以在产品说明书中有定义或者在使用软件过程中确定
    l     次边界条件：在软件内部，也称为内部边界条件
    l     其他边界条件：如输入信息为空（对于此类问题应建立单独的等价类空间）、非法、错误、不正确和垃圾数据
    （2）边界值的选择方法（遵循原则）
    序号 输入条件（数据） 输入边界值数据
    1     规定了取值范围 刚刚达到这个范围刚刚超越这个范围
    2     规定值的个数 最大个数、比最大个数大1最小个数、比最小个数少1
    3     根据规格说明书的每个输出条件，使用 原则1、2
    4     输入或输出是个有序集合 集合的第一个、最后一个元素
    5     程序中使用一个内部数据结构 内部数据结构边界上的值
    6     分析规格说明，找出其他可能的边界
    （3）例子：
    l     允许文本输入1～255个字符：测试用例－1、255、254、0、256
    l 程序读写软盘：测试用例－文件很小、等于软盘容量限制之内、空、超过
    l     程序允许在一张纸上打印多个页面：测试用例－只打印一页，规定最大页，0页，大于允许最大页数
    3    ．错误推测法
    基本思想：列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据它们选择测试用例
    4    ．因果图法
           侧重于输入条件的各种组合，各个输入情况之间的相互制约关系
    （1） 因果图设计方法
    从用自然语言书写的程序规格说明的描述中找出因果，通过因果图转换成判定表
    （2） 因果图导出测试用例步骤
    l     第一步：分析程序规格说明的描述中，哪些是原因，哪些是结果。原在因常常是输入条件或是输入条件的等价类，结果是输出条件
    l     第二步：分析程序规格说明的描述中语义的内容，并将其表示成连接各个原因与各个结果的‘因果图’
    l     第三步：标明约束条件
    l     第四步：把因果图转换成判定表
    l     第五步：为判定表中每一列表示的情况设计测试用例
    （3） 因果图基本图形符号
    通常在因果图中，用Ci 表示原因，Ei表示结果，各结点表示状态，可取值0（状态不出现） 或1（某状态出现）
    l     恒等：若原因出现，则结果出现；若原因不出现，则结果不出现
    l     非（～）：若原因出现，则结果不出现；若原因不出现，则结果出现
    l     或（V）：若几个原因中有一个出现，则结果出现；若几个原因都不出现，则结果不出现；
    l     与（∧）：若几个原因都出现，结果才出现；若其中有一个原因不出现，则结果不出现
    （4） 因果图的约束符号
    从输入（原因）考虑四种约束
    l E    （互斥）：表示两个原因不会同时成立，两个中最多有一个可能成立
    l I    （包含）：表示三个原因中至少有一个必须成立
    l O    （惟一）：表示两个原因中必须有一个，且仅有一个成立
    l R    （要求）：表示两个原因，a出现时，b也必须出现，a出现时，b不可能不出现
    从输出（结果）考虑一种约束
    l M    （屏蔽）：两个结果，a为1时，b必须是0，当a为0时，b值不定

    2005-4-19
    5    ．判定表驱动法
    （1） 判定表：是分析和表达多逻辑条件下执行不同操作的情况的工具
    （2） 判定表组成
    l     条件桩：列出了问题的所有条件
    l     动作桩：列出了问题规定可能采取的操作
    l     条件项：列出针对它所列条件的取值，在所有可能情况下的真假值
    l     动作项：列出在条件项的各种取值情况下应该采取的动作
    l     规则：任何一个条件组合的特定取值及其相应要执行的操作
    注：判定表中贯穿条件项和动作项的一列就是一条规则；
    （3） 判定表的建立（步骤）
    l     第一步：确定规则的个数。假如有n个条件，每个条件有两个取值（0,1），故有