Fiddler模拟弱网测试

Fiddler模拟弱网

1. Fiddler>Rules>Customize Rules…

1

2.搜索m_SimulateModem, 修改以下参数,并保存

oSession[“request-trickle-delay” ] = “300”;(每上传1KB延迟300ms)

oSession[“response-trickle-delay” ] = “150”;(每下载1KB延迟150ms)

2

3. Save后,之前勾选的Simulate Modem Speeds会被取消勾选,需要重新再勾选回来

3

总结:

千里之行始于足下 !

有赞测试团队介绍读后感

       看了有赞测试团队的分享,让我对优秀的测试团队有了更清晰的认识,一个优秀的测试团队需要具备以下几点:人员分工明确,团队目标一致,相互学习资源互补,有条不紊的测试流程等方面。有赞测试团队的强大不是一朝一夕能够实现的,我们可以吸收他们的长处补充自己的不足,设计出一套适合本公司的一个测试平台,让我们的测试团队更加强大。
       1.对于测试平台的搭建。我们需要探索出适合本公司发展的测试平台,让自动化测试不断的融入我们的测试过程中。对于功能测试,UI测试,安全性测试,性能测试,自动化测试要有一个合适的平台去合理的分工协作。
       2.对于自动化测试,每个测试人员都应有意识的去学习,去探索更好更快更精准的测试方法。自动化是必修课,我们也要学着从接口层、端对端的数据层、端对端的UI层来做自动化建设,尽可能的去朝着自动化 的方向去发展,不能一味的停滞不前,要不断的学习,不断的向自动化测试靠拢,尽可能的减少不必要的人工测试。
       3.对于不同的项目有不同的解决方案。对于标准需求项目或者跨多个业务的项目,一定会有测试投入,并且会有一位PTM来协调测试工作。即哪些业务的功能测试PTM可顺带执行掉,哪些确实需要对应业务线测试同学来完成,以避免一个项目投入过多测试同学。 对于重构改造项目,测试同学要做的就是对新系统进行自动化覆盖。对于小型项目,如果开发的自测场景与测试同学的测试场景基本一致,那开发自行搞定即可;或者测试同学把需要特别关注的或者风险点给开发同学简单介绍。对于有差异的,测试同学把差异点向开发同学描述清楚即可。
        以上几点是我读完有赞测试团队后的感想,一个强大的团队必有它的强大之处,我们要正确的认识自己,去努力追赶超越他们。加油!!!

在做自动化测试之前你需要知道的

什么是自动化测?

       做测试好几年了,真正学习和实践自动化测试一年,自我感觉这一个年中收获许多。一直想动笔写一篇文章分享自动化测试实践中的一些经验。终于决定花点时间来做这件事儿。

  首先理清自动化测试的概念,广义上来讲,自动化包括一切通过工具(程序)的方式来代替或辅助手工测试的行为都可以看做自动化,包括性能测试工具(loadrunner、jmeter),或自己所写的一段程序,用于生成1到100个测试数据。狭义上来讲,通工具记录或编写脚本的方式模拟手工测试的过程,通过回放或运行脚本来执行测试用例,从而代替人工对系统的功能进行验证。

当然,我们更普遍的认识把“自动化测试”看做“ 基于产品或项目UI层的自动化测试”。

分层的自动化测试

       这个概念最近曝光度比较高,传统的自动化测试更关注的产品UI层的自动化测试,而分层的自动化测试倡导产品的不同阶段(层次)都需要自动化测试。1

  相信测试同学对上面的金字塔并不陌生,这不就是对产品开发不同阶段所对应的测试么!我们需要规范的来做单元测试同样需要相应的单元测试框架,如java的Junit、testNG,C#的NUnit ,python 的unittest、pytest 等,几乎所有的主流语言,都会有其对应的单元测试框架。

  集成、接口测试对于不少测试新手来说不太容易理解,单元测试关注代码的实现逻辑,例如一个if 分支或一个for循环的实现;那么集成、接口测试关注的一是个函数、类(方法)所提供的接口是否可靠。例如,我定义一个add()函数用于计算两个参数的结果并返回,那么我需要调用add()并传参,并比较返回值是否两个参数相加。当然,接口测试也可以是url的形式进行传递。例如,我们通过get方式向服务器发送请求,那么我们发送的内容做为URL的一部分传递到服务器端。但比如 Web service 技术对外提供的一个公共接口,需要通过soapUI 等工具对其进行测试。

  UI层的自动化测试,这个大家应该再熟悉不过了,大部分测试人员的大部分工作都是对UI层的功能进行测试。例如,我们不断重复的对一个表单提交,结果查询等功能进行测试,我们可以通过相应的自动化测试工具来模拟这些操作,从而解放重复的劳动。UI层的自动化测试工具非常多,比较主流的是QTP,Robot Framework、watir、selenium 等。

 为什么要画成一个金字塔形,则不是长方形 或倒三角形呢? 这是为了表示不同阶段所投入自动化测试的比例。如果一个产品从没有做单元测试与接口测试,只做UI层的自动化测试是不科学的,从而很难从本质上保证产品的质量。如果你妄图实现全面的UI层的自动化测试,那更是一个劳民伤财的举动,投入了大量人力时间,最终获得的收益可能会远远低于所支付的成本。因为越往上层,其维护成本越高。尤其是UI层的元素会时常的发生改变。所以,我们应该把更多的自动化测试放在单元测试与接口测试阶段进行。

  既然UI层的自动化测试这么劳民伤财,那我们只做单元测试与接口测试好了。NO! 因为不管什么样的产品,最终呈现给用户的是UI层。所以,测试人员应该更多的精力放在UI层。那么也正是因为测试人员在UI层投入大量的精力,所以,我们有必要通过自动化的方式帮助我们“部分解放”重复的劳动。

  在自动化测试中最怕的是变化,因为变化的直接结果就是导致测试用例的运行失败,那么就需要对自动化脚本进行维护;如何控制失败,降低维护成本对自化的成败至关重要。反过来讲,一份永远都运行成功的自动化测试用例是没有价值。

  至于在金字塔中三种测试的比例要根据实际的项目需求来划分。在《google 测试之道》一书,对于google产品,70%的投入为单元测试,20%为集成、接口测试,10% 为UI层的自动化测试。

我为什么要做自动化测试?

   根据51testing的《中国软件测试从业人员调查报告》,手工测试占到的89% ,相对开发来说,测试的门槛底,薪资普遍较底,所要求的知识面虽然有一定广度,但缺乏深度。这是测试的普遍现状。

  正因为手功测试人门槛不高,使大量的毕业生,甚至是非专业人员涌入这个行业。从而增加了这个行业的激烈竞争。对于工作几年扔处于手工测试的人员来说都会有强列的危机感。由于工作的技术含量不高,薪资的涨幅遇到瓶颈,另一方面受到新进入者的威胁,同样的工作公司花5K招来的人就可以做,那么就不会花8K 的招。

  好吧,这个问题不应该出现讨论技术的话题中,但他的确是大多测试人员不得不面对的一个问题。所以,从测试人员自身的发展来说,我其实非常需要通过自动化技术来增加自己有竞争力。当然,做到一定年限测试人员会选择转管理或其它岗位,这又是另一个话题了。

  从测试行业的发展来说,国内产品由于产品特点,世界级的产品不多,技术含量相对不高,质量要求相对要求不高,外包国外项目,测试人力成本低廉,所以需要大量的手工测试人员。

  所以,在不远的未来,我认为纯的工手测试人员的需求是递减,公司更需要更高技术能力的测试。质量需要测试,测试行为永远不会消失,但纯的手工测试人员是否消失是有可能的。

  好吧,你可以说测试多朝阳的行业,我纯属在危言耸听。不管未来如何,我们都需要提升自身的技能对吧!

什么项目适合做自动化测试?

  假如你已经决定要学习自动化测试了,如何学习是要面临的下一个问题?这个问题以被测试产品为出发点进行分析,假如你所学的技术不能得到应用(验证),将会使你的学习过程寸步难行。

  首先考考虑产品是否适合做自动化测试。这方法比较普遍的共识是从三个方面进行权衡。

  软件需求变动不频繁

  测试脚本的稳定性决定了自动化测试的维护成本。如果软件需求变动过于频繁,测试人员需要根据变动的需求来更新测试用例以及相关的测试脚本,而脚本的维护本身就是一个代码开发的过程,需要修改、调试,必要的时候还要修改自动化测试的框架,如果所花费的成本不低于利用其节省的测试成本,那么自动化测试便是失败的。

  项目中的某些模块相对稳定,而某些模块需求变动性很大。我们便可对相对稳定的模块进行自动化测试,而变动较大的仍是用手工测试。

  项目周期较长

由于自动化测试需求的确定、自动化测试框架的设计、测试脚本的编写与调试均需要相当长的时间来完成。这样的过程本身就是一个测试软件的开发过程,需要较长的时间来完成。如果项目的周期比较短,没有足够的时间去支持这样一个过程,那么自动化测试便成为笑谈。

  自动化测试脚本可重复使用

  自动化测试脚本的重复使用要从三个方面来考量,一方面所测试的项目之间是否很大的差异性(如C/S系统和B/S系统的差异);所选择的测试工具是否适应这种差异;最后,测试人员是否有能力开发出适应这种差异的自动化测试框架。

选择什么工具进行自动化测试

  假如你已经确认了XX 项目适合做自动化测试,那么接下来你要做的就是选测试工具了。

  首先要先确认你所测试的产品是桌面程序(C/S)还是web应用(B/S)。

  桌面程序的工具有:QTP、 AutoRunner

  web应用的工具有:QTP、AutoRunner、Robot Framework、watir、selenium

  由于B/S架构的诸多优势,早几年前大量C/S架构的应用转为B/S结构。从而也推动了web开发与测试技术的发展。假如,被测试有产品是C/S架构的,那么推荐QTP ,QTP在UI自动化测试领域占到了一半的试用率。所以,足以说明QTP在自动化领域强大,易用性等。学习主流的工具也可以使你获得更多的机会。市面上关于QTP的书籍也非常丰富。当然,要想学好QTP ,你必须要掌握VBS脚本语言。

  如果,被测产品是B/S 结构,那么推荐selenium ,为什么不是QTP 或其它工具?因为selenium 对B/S应用支持很好,更重要的一点,它支持多语言的开发,真正的试用selenium ,你所要掌握的不仅仅是一个工具而已,你还需要学习一门语言。我为什么要选择selenium?还要学一门语言,这无疑增加了我的学习成本。增加成本的同时,也增加的你的竞争力,而且,在这个过程中你不单单只是学会了一个自动化工具而已,你完全可以使用所学的语言去做更多的事情。

  好吧!假如你决定试用selenium 了之后,你又面临了一个新的问题,选择一门语言。selenium 是支持java、python、ruby、php、C#、JavaScript 。

  从语言易学性来讲,首选ruby ,python

  从语言应用广度来讲,首选java、C#、php、

  从语言相关测试技术成度(及 资料)来讲:ruby ,python ,java

  或者你可以考虑整个技术团队主流用什么语言,然后选择相应的语言。

selenium 用前须知

  OK!经过上的过程,我相信你一定做出的相应的选择,如果你选择的是selenium 工具,那么接着往下阅读。

首选你在开始selenium之前,需要花一到两个月时间去学一门语言,这里是根据没有语言基础的同学而定的。我推荐ruby ,python ,java 任意一门语言来进行学习。

  当然,已经如果有很好的语言基础略过这个环节,或者你的丰富的java编程能力,那么学习python 可能只需要几天时间或更短。

  假如,你已经搞定了一门语言的基础,接下来你需要先了解selenium ,selenium 并不是单纯的一个工具,他是一组工具的集合,而且,他还有1.0与2.0之分,当然3.0也已经到来。

  selenium 也不是简单一个工具,而是由几个工具组成,每个工具都有其特点和应用场景。

2

selenium IDE

  selenium IDE 是嵌入到Firefox浏览器中的一个插件,实现简单的浏览器操作的录制与回放功能。那么什么情况下用到它呢?

  快速的创建bug重现脚本,在测试人员的测试过程中,发现了bug之后可以通过IDE将重现的步骤录制下来,以帮助开发人员更容易的重现bug。

  IDE录制的脚本可以可以转换成多种语言,从而帮助我们快速的开发脚本,关于这个功能后而用到时再详细介绍。

selenium Grid

  Selenium Grid是一种自动化的测试辅助工具,Grid通过利用现有的计算机基础设施,能加快Web-app的功能测试。利用Grid,可以很方便地同时在多台机器上和异构环境中并行运行多个测试事例。其特点为:

· 并行执行

· 通过一个主机统一控制用例在不同环境、不同浏览器下运行。

· 灵活添加变动测试机

selenium RC

  selenium RC 是selenium 家族的核心工具,selenium RC 支持多种不同的语言编写自动化测试脚本,通过selenium RC 的服务器作为代理服务器去访问应用从而达到测试的目的。

  selenium RC 使用分Client Libraries和selenium Server,Client Libraries库主要主要用于编写测试脚本,用来控制selenium Server的库。

  Selenium Server负责控制浏览器行为,总的来说,Selenium Server主要包括3个部分:Launcher、Http Proxy、Core。其中Selenium Core是被Selenium Server嵌入到浏览器页面中的。其实Selenium Core就是一堆JS函数的集合,就是通过这些JS函数,我们才可以实现用程序对浏览器进行操作。Launcher用于启动浏览器,把selnium Core加载到浏览器页面当中,并把浏览器的代理设置为Selenium Server 的Http Proxy。

selenium 2.0

  搞清了selenium 1.0 的家族关系,selenium 2.0 是把WebDriver 加入到了这个家族中;简单用公式表示为:

  selenium 2.0 = selenium 1.0 + WebDriver

  需要强调的是,在selenium 2.0 中主推的是WebDriver ,WebDriver 是selenium RC 的替代品,因为 selenium 为了向下兼容性,所以selenium RC 并没有彻底抛弃,如果你使用selenium开发一个新自动化测试项目,强列推荐使用WebDriver 。那么selenium RC 与webdriver 主要有什么区别呢?

  selenium RC 在浏览器中运行JavaScript应用,使用浏览器内置的JavaScript 翻译器来翻译和执行selenese命令(selenese 是selenium命令集合)。

  WebDriver通过原生浏览器支持或者浏览器扩展直接控制浏览器。WebDriver针对各个浏览器而开发,取代了嵌入到被测Web应用中的JavaScript。与浏览器的紧密集成支持创建更高级的测试,避免了JavaScript安全模型导致的限制。除了来自浏览器厂商的支持,WebDriver还利用操作系统级的调用模拟用户输入。

  如果是新项目直接学习webdriver 就OK了,RC是过时技术。

selenium学习路线

  配置你的测试环境,真对你所学习语言,来配置你相应的selenium 测试环境。selenium 好比定义的语义—“问好”,假如你使用的是中文,为了表术问好,你的写法是“你好”,假如你使用的是英语,你的写法是“hello”。 所以,同样有语义在不同的语言下会有不同的写法(语法)。

   接着你需要熟悉webdriver API ,API就是selenium 所定义一方法,用于定位,操作页面上的各种元素。

  先学习元素的定位,selenium 提供了id、name、class name、 tag name、link text、partial link text、 xpath、css、等定位方法。xpath和css 功能强大语法稍微复杂,在这其间你可能还需要了解更多的前端知识。xml ,javascript 等。

  定位元素的目的是为了操作元素,接就要学习各种元素有操作,输入框,下拉框,按钮点击,文件上传、下载,分页,对话框,警告框…等等。

  经过一段时间的学习,你可以游刃有余的模拟手工测试来操作页面上的各种元素了。接着你需要做的就是把这些“用例”组织起来,统一来跑。

  那么你需要做的就是学习并使用单元测试框架,单元测试框架本身就解决了用例的组织与运行。

  当你写了一些“测试用例” 之后,你会发现用例中有大量重复的操作,能不能写到一个单独的文件中,需要的时候调用这些操作?当然可以,运用你的编程能力来实现这一点将非常简单。然后,你又发现每个用例中都有一些数据,这些数据也是一样的,但如果变化了修改起来非常麻烦,你也可以把他写到一个单独的文件中进行读取。

  接着你又遇到了新的疑问,我写的脚本(用例)都是流水式的,我怎么知道用例运行失败还是成功。那么就需要在脚本中加一些验证与断言。

  接着你又有了更多的想法,单元测试框架的log太简陋了,能不能生成一张漂亮的测试报告出来。我能不能定时的来跑这个脚本。能不能把每一次跑脚本的测试结果直接发到我的邮箱。能不能……

  为解决这些问题,你不得不学习更多的编程技术,然后你的“测试结构”会功能越来越强大,越来越灵活。产生了一定的通用性和移植性。一个有模有样的自动化测试框架诞生了。

   假如,有一天你不再做UI的自动化测试了,你会发现你去做单元测试 或接口测试基本没什么难度。开发个测试工具之类的也不在话下,感谢selenium 吧!顺便也感谢一下我吧!

总结:每天学习一点点!

测试流程与测试方法

1. 产品-开发-测试流程

测试流程图.png

需求分析
需求分析由产品人员制定,细化每一个功能的细节,每一个按钮的位置,对于稍大或复杂一点的需求进行建模。

需求评审
这里会叫上所有参与项目人员进行,开发人员、测试人员。测试人员提出需求,开发人员考虑功能实现的方案与可行性、当然开发负责也是要参与的。测试人员主要是对需求的理解提出疑问,以便才能根据需求写用例。

开发人员制定开发计划
开发人员需求根据需求功能点进行排期。然后将开计划转交给测试人员。

测试计划制定测试计划
测试人员根据开发计划,对测试具体测试时间,也就是开发功能完成后的时间,进行几轮测试等。然后,把项目的开发与测试计划提交到Teambiton进行任务管理。

编写测试用例
根据详细的需求文档,开始进行用例的编写。

用例评审
在用例进行评审之间,先以邮件形式将用例发送给相关人员,以便他们事先了解用例对哪些功能进行验证以及验证的细节。
然后,测试人员组进行用例评审,开发人员对用例与实际功能不符合有哪些,产品人员对会通过用例对功能的具体实现进行把握等等。

提交代码
开发人员完成所有功能后,会对自己的功能进行一个自测。自测完成后提交测试人员进行测试。

具体测试流程
开发人员对于提测的功能进行测式,发现的问题通过缺陷管理工具进行反馈,开发人员对问题进行修复,然后,准备第二轮测试。
测试人员完成第一轮测试后,需要写测试结论,发到相关人员。然后进行第二轮测试,并且对第一轮中发现的问题进行重点回归。

测试通过
经过两到三轮或四轮的测试后,直到没发现新的问题,或暂时无法解决,或不紧急的问题。通过上级确认,可以通过。编写测试报告与验收方案。

2. 测试方法与流程

执行测试时的流程图.png

冒烟测试
是指在对一个新版本进行系统大规模的测试之前,先验证一下软件的基本功能是否实现,是否具备可测性。
引入到软件测试中,就是指测试小组在正规测试一个新版本之前,先投入较少的人力和时间验证一个软件 的主要功能,如果主要功能都没有实现,则打回开发组重新开发。这样做的好处是可以节省大量的时间成本和人力成本。

功能测试
功能测试检查实际的功能是否符合用户的需求。测试的大部分工作也是围绕软件的功能进行,设计软件的目的也就是满足客户对其功能的需求。
功能测试又可可以细分为很多种:界面测试、逻辑功能测试、易用性测试、安装测试、兼容性测试等。

  • 界面测试:确保产品UI符合产品经理和设计师的界面设计,并且文案正确。
  • 逻辑功能测试:根据需求文档与测试用例,测试产品的逻辑,确保逻辑正确。
  • 兼容性测试:原有功能优化后在新旧版本上的兼容测试;服务号、PC Web、组织号与APP之间相互功能的交互与兼容测试。

回归测试
回归测试是指修改了旧代码后,重新实行测试以确认修改后没有引入新的错误或导致其他代码产生错误。

  • 原有功能在新版本上进行回归测试,保证运行准确。目前APP回归测试上测试主要基于底部导航Tab,对报名吧首页、通讯录、发布、发现、我四个tab下的主要功能进行回归测试。服务号和pc web会进行发布-报名-签到整一个业务流程进行回归测试。组织号是进行组织的申请-资料编辑-审核会员-审核组织的业务流程进行测试。
  • 第一轮功能测试中发现的bug得到修复后,对该功能进行第二轮测试。回归也是一个循环的过程,如果回归的问题通不过,则需要开发人员修改后再次进行回归,直到通过为止。

验收测试
验收测试是部署软件之前的最后一个测试操作。一般是对产品功能、用户界面、性能、业务关联性的全局测试,确保产品达到产品经理的需求,没有阻碍产品使用的大bug。

升级测试
从历史版本升级到当前新版本的测试,确保升级后,软件可以正常使用,重点对升级后的新功能进行测试。

3. issue管理

issue处理流程

issue处理流程图.png

issue优先级(priority)
当题开发测试人员在面对许多issue需要处理进,就需要进行优先级排序。
优先级的划分:
低(4)——>中(3)——>高(2)——>紧急(1)
延迟处理——>正常排队——>优先处理——>紧急处理
issue 的严重程度和优先级是含义不同但相互联系密切的两个概念,它们从不同的侧面描述了软件缺陷对软件质量和最终用户的影响程序和处理方式。
一般地,严重程序高的软件缺陷具有较高的优先级。严重程度高说明缺陷对软件造成的危害性大,需要优先处理,而来严重程序低的缺陷可能只是软件不太尽善尽美,可以稍后处理。
严重程度高优先级不一定高:
如果某个严重的软件缺陷只在非常极端的条件下产生,则没有必要马上处理。
如果某一个软件缺陷,需要重新修改软件的整体架构,可能会产生更多的潜在缺陷,此时即使缺陷的严重性很高,是否需要修正,需要全盘考虑。
严重程度低优先级不一定低:
如果是软件名称错误或版本号错误,虽然说其属于界面错误,严重程度不高,但其关系到软件和公司的市场,必须尽快修正。

4. 测试中用到的工具

任务分配及管理平台:Teambition
需求文档、UI设计、测试文档管理平台:Teambition
issue管理平台:gitlab
数据库:bmbtest
打包工具:Xcode、Android Studio
内测APP上传和下载地址:
Android: fir.im/luyi
iOS: fir.im/bmbtest

原网址:http://www.jianshu.com/p/543855d30556

总结:通过这篇文章我更加清楚的了解了测试的一个整个流程以及测试方法,以及bug的处理方式。对于我最近的工作模式,我也进行了一些反思。对于测试的主流程以及测试方法我自身的欠缺是比较大的。对于一个任务,没有一条清晰的主线,盲目的测试,反复的重复前一天的操作,这是非常不应该的。希望在以后的工作中,我能有一个明确的规划,更好的完成自己的任务。

 

测试用例的设计方法(全)

等价类划分方法:

一.方法简介

1.定义
是把所有可能的输入数据,即程序的输入域划分成若干部分(子集),然后从每一个子集中选取少数具有代表性的数据作为测试用例。该方法是一种重要的,常用的黑盒测试用例设计方法。

2.划分等价类:
等价类是指某个输入域的子集合。在该子集合中,各个输入数据对于揭露程序中的错误都是等效的,并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试,因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件就可以用少量代表性的测试数据取得较好的测试结果。等价类划分可有两种不同的情况:有效等价类和无效等价类。
1)有效等价类
是指对于程序的规格说明来说是合理的、有意义的输入数据构成的集合。利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能。
2)无效等价类
与有效等价类的定义恰巧相反。无效等价类指对程序的规格说明是不合理的或无意义的输入数据所构成的集合。对于具体的问题,无效等价类至少应有一个,也可能有多个。
设计测试用例时,要同时考虑这两种等价类。因为软件不仅要能接收合理的数据,也要能经受意外的考验,这样的测试才能确保软件具有更高的可靠性。

3.划分等价类的标准:
1)完备测试、避免冗余;
2)划分等价类重要的是:集合的划分,划分为互不相交的一组子集,而子集的并是整个集合;
3)并是整个集合:完备性;
4)子集互不相交:保证一种形式的无冗余性;
5)同一类中标识(选择)一个测试用例,同一等价类中,往往处理相同,相同处理映射到”相同的执行路径”。

4.划分等价类的方法
1)在输入条件规定了取值范围或值的个数的情况下,则可以确立一个有效等价类和两个无效等价类。如:输入值是学生成绩,范围是0~100;                     2)在输入条件规定了输入值的集合或者规定了”必须如何”的条件的情况下,可确立一个有效等价类和一个无效等价类;
3)在输入条件是一个布尔量的情况下,可确定一个有效等价类和一个无效等价类。
4)在规定了输入数据的一组值(假定n个),并且程序要对每一个输入值分别处理的情况下,可确立n个有效等价类和一个无效等价类。例:输入条件说明学历可为:专科、本科、硕士、博士四种之一,则分别取这四种这四个值作为四个有效等价类,另外把四种学历之外的任何学历作为无效等价类。
5)在规定了输入数据必须遵守的规则的情况下,可确立一个有效等价类(符合规则)和若干个无效等价类(从不同角度违反规则);
6)在确知已划分的等价类中各元素在程序处理中的方式不同的情况下,则应再将该等价类进一步的划分为更小的等价类。

5.设计测试用例
在确立了等价类后,可建立等价类表,列出所有划分出的等价类输入条件:有效等价类、无效等价类,然后从划分出的等价类中按以下三个原则设计测试用例:
1)为每一个等价类规定一个唯一的编号;
2)设计一个新的测试用例,使其尽可能多地覆盖尚未被覆盖地有效等价类,重复这一步,直到所有的有效等价类都被覆盖为止;
3)设计一个新的测试用例,使其仅覆盖一个尚未被覆盖的无效等价类,重复这一步,直到所有的无效等价类都被覆盖为止。

二.实战演习
1.某程序规定:”输入三个整数 a 、 b 、 c 分别作为三边的边长构成三角形。通过程序判定所构成的三角形的类型,当此三角形为一般三角形、等腰三角形及等边三角形时,分别作计算 … “。用等价类划分方法为该程序进行测试用例设计。(三角形问题的复杂之处在于输入与输出之间的关系比较复杂。)
分析题目中给出和隐含的对输入条件的要求:
(1)整数    (2)三个数    (3)非零数   (4)正数
(5)两边之和大于第三边     (6)等腰     (7)等边
如果 a 、 b 、 c 满足条件( 1 ) ~ ( 4 ),则输出下列四种情况之一:
1)如果不满足条件(5),则程序输出为 ” 非三角形 ” 。
2)如果三条边相等即满足条件(7),则程序输出为 ” 等边三角形 ” 。
3)如果只有两条边相等、即满足条件(6),则程序输出为 ” 等腰三角形 ” 。
4)如果三条边都不相等,则程序输出为 ” 一般三角形 ” 。
列出等价类表并编号

覆盖有效等价类的测试用例:
a     b     c             覆盖等价类号码
3     4     5             (1)–(7)
4     4     5             (1)–(7),(8)
4     5     5             (1)–(7),(9)
5     4     5             (1)–(7),(10)
4     4     4             (1)–(7),(11)
覆盖无效等价类的测试用例:

2.设有一个档案管理系统,要求用户输入以年月表示的日期。假设日期限定在1990年1月~2049年12月,并规定日期由6位数字字符组成,前4位表示年,后2位表示月。现用等价类划分法设计测试用例,来测试程序的”日期检查功能”。
1)划分等价类并编号,下表等价类划分的结果

输入等价类

有效等价类 无效等价类
日期的类型及长度

①6位数字字符

②有非数字字符

③少于6位数字字符

④多于6位数字字符

年份范围

⑤在1990~2049之间

⑥小于1990

⑦大于2049

月份范围

⑧在01~12之间

⑨等于00

⑩大于12

2)设计测试用例,以便覆盖所有的有效等价类在表中列出了3个有效等价类,编号分别为①、⑤、⑧,设计的测试用例如下:
测试数据    期望结果      覆盖的有效等价类
200211      输入有效     ①、⑤、⑧
3)为每一个无效等价类设计一个测试用例,设计结果如下:
测试数据   期望结果     覆盖的无效等价类
95June     无效输入         ②
20036      无效输入          ③
2001006   无效输入         ④
198912     无效输入         ⑥
200401     无效输入         ⑦
200100     无效输入         ⑨
200113     无效输入         ⑩

3.NextDate 函数包含三个变量:month、 day 和 year ,函数的输出为输入日期后一天的日期。 例如,输入为 2006年3月 7日,则函数的输出为 2006年3月8日。要求输入变量 month 、 day 和 year 均为整数值,并且满足下列条件:
①1≤month≤12
②1≤day≤31
③1920≤year≤2050
1)有效等价类为:
M1={月份:1≤月份≤12}
D1={日期:1≤日期≤31}
Y1={年:1812≤年≤2012}
2)若条件 ①~ ③中任何一个条件失效,则NextDate 函数都会产生一个输出,指明相应的变量超出取值范围,比如 “month 的值不在 1-12 范围当中 ” 。显然还存在着大量的 year 、 month 、 day 的无效组合, NextDate 函数将这些组合作统一的输出: ” 无效输入日期 ” 。其无效等价类为:
M2={月份:月份<1}
M3={月份:月份>12}
D2={日期:日期<1}
D3={日期:日期>31}
Y2={年:年<1812}
Y3={年:年>2012}
弱一般等价类测试用例
月份   日期      年              预期输出
6      15       1912           1912年6月16日
强一般等价类测试用例同弱一般等价类测试用例
注:弱–有单缺陷假设;健壮–考虑了无效值

(一)弱健壮等价类测试
用例ID  月份  日期    年         预期输出
WR1      6     15    1912      1912年6月16日
WR2     -1    15    1912      月份不在1~12中
WR3     13    15    1912      月份不在1~12中
WR4      6     -1    1912      日期不在1~31中
WR5      6     32    1912      日期不在1~31中
WR6      6     15    1811      年份不在1812~2012中
WR7      6     15    2013      年份不在1812~2012中

(二)强健壮等价类测试
用例ID  月份    日期     年         预期输出
SR1       -1     15       1912     月份不在1~12中
SR2       6      -1       1912      日期不在1~31中
SR3       6      15      1811      年份不在1812~2012中
SR4       -1     -1       1912      两个无效一个有效
SR5       6      -1       1811      两个无效一个有效
SR6       -1     15       1811      两个无效一个有效
SR7       -1     -1       1811      三个无效

4.佣金问题等价类测试用例,它是根据佣金函数的输出值域定义等价类,来改进测试用例集合。
输出销售额≤1000元     佣金10%
1000<销售额≤1800    佣金=100+(销售额-1000)*15%
销售额>1800             佣金=220+(销售额-1800)*20%
测试用例        枪机(45)   枪托(30)     枪管(25)         销售额     佣金
1              5            5              5                 500        50
2             15          15             15                1500       175
3             25          25             25                2500       360
根据输出域选择输入值,使落在输出域等价类内,可以结合弱健壮测试用例结合。

边界值分析方法:

一.方法简介
1.定义:边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充,这种情况下,其测试用例来自等价类的边界。

2.与等价划分的区别
1)边界值分析不是从某等价类中随便挑一个作为代表,而是使这个等价类的每个边界都要作为测试条件。
2)边界值分析不仅考虑输入条件,还要考虑输出空间产生的测试情况。

3.边界值分析方法的考虑:
长期的测试工作经验告诉我们,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部。因此针对各种边界情况设计测试用例,可以查出更多的错误。
使用边界值分析方法设计测试用例,首先应确定边界情况。通常输入和输出等价类的边界,就是应着重测试的边界情况。应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据。

4.常见的边界值
1)对16-bit 的整数而言 32767 和 -32768 是边界
2)屏幕上光标在最左上、最右下位置
3)报表的第一行和最后一行
4)数组元素的第一个和最后一个
5)循环的第 0 次、第 1 次和倒数第2 次、最后一次

5.边界值分析
1)边界值分析使用与等价类划分法相同的划分,只是边界值分析假定错误更多地存在于划分的边界上,因此在等价类的边界上以及两侧的情况设计测试用例。
例:测试计算平方根的函数
–输入:实数
–输出:实数
–规格说明:当输入一个0或比0大的数的时候,返回其正平方根;当输入一个小于0的数时,显示错误信息”平方根非法-输入值小于0″并返回0;库函数Print-Line可以用来输出错误信息。

2)等价类划分:
I.可以考虑作出如下划分:
a、输入 (i)<0 和 (ii)>=0
b、输出 (a)>=0 和 (b) Error
II.测试用例有两个:
a、输入4,输出2。对应于 (ii) 和(a) 。
b、输入-10,输出0和错误提示。对应于 (i) 和(b) 。

  3)边界值分析:
划分(ii)的边界为0和最大正实数;划分(i)的边界为最小负实数和0。由此得到以下测试用例:
a、输入{最小负实数}
b、输入{绝对值很小的负数}
c、输入0
d、输入{绝对值很小的正数}
e、输入{最大正实数}

4)通常情况下,软件测试所包含的边界检验有几种类型:数字、字符、位置、重量、大小、速度、方位、尺寸、空间等。
5)相应地,以上类型的边界值应该在:最大/最小、首位/末位、上/下、最快/最慢、最高/最低、  最短/最长、 空/满等情况下。
6)利用边界值作为测试数据

边界值 测试用例的设计思路
字符

起始-1个字符/结束+1个字符

假设一个文本输入区域允许输入1个到255个 字符,输入1个和255个字符作为有效等价类;输入0个和256个字符作为无效等价类,这几个数值都属于边界条件值。

数值

最小值-1/最大值+1

假设某软件的数据输入域要求输入5位的数据值,可以使用10000作为最小值、99999作为最大值;然后使用刚好小于5位和大于5位的 数值来作为边界条件。

空间

小于空余空间一点/大于满空间一点

例如在用U盘存储数据时,使用比剩余磁盘空间大一点(几KB)的文件作为边界条件。

7)内部边界值分析:
在多数情况下,边界值条件是基于应用程序的功能设计而需要考虑的因素,可以从软件的规格说明或常识中得到,也是最终用户可以很容易发现问题的。然而,在测试用例设计过程中,某些边界值条件是不需要呈现给用户的,或者说用户是很难注意到的,但同时确实属于检验范畴内的边界条件,称为内部边界值条件或子边界值条件。
内部边界值条件主要有下面几种:
a)数值的边界值检验:计算机是基于二进制进行工作的,因此,软件的任何数值运算都有一定的范围限制。

范围或值

位(bit)

0或者1
字节(byte) 0——225

字(word)

0~65535(单字)或 0~4294967295(双字)

千(K)

1024

兆(M)

1048576
吉(G)

1073741824

b)字符的边界值检验:在计算机软件中,字符也是很重要的表示元素,其中ASCII和Unicode是常见的编码方式。下表中列出了一些常用字符对应的ASCII码值。

字符

ASCII码值

字符

ASCII码值

空 (null)

0 A 65

空格 (space)

32 a 97

斜杠 ( / )

47 Z 90
0 48 z 122

冒号 ( : )

58

单引号 ( ‘ )

96
@ 64

c)其它边界值检验

6.基于边界值分析方法选择测试用例的原则
1)如果输入条件规定了值的范围,则应取刚达到这个范围的边界的值,以及刚刚超越这个范围边界的值作为测试输入数据。
例如,如果程序的规格说明中规定:”重量在10公斤至50公斤范围内的邮件,其邮费计算公式为……”。作为测试用例,我们应取10及50,还应取10.01,49.99,9.99及50.01等。
2)如果输入条件规定了值的个数,则用最大个数,最小个数,比最小个数少一,比最大个数多一的数作为测试数据。
比如,一个输入文件应包括1~255个记录,则测试用例可取1和255,还应取0及256等。
3)将规则1)和2)应用于输出条件,即设计测试用例使输出值达到边界值及其左右的值。
例如,某程序的规格说明要求计算出”每月保险金扣除额为0至1165.25元”,其测试用例可取0.00及1165.24、还可取一0.01及1165.26等。
再如一程序属于情报检索系统,要求每次”最少显示1条、最多显示4条情报摘要”,这时我们应考虑的测试用例包括1和4,还应包括0和5等。
4)如果程序的规格说明给出的输入域或输出域是有序集合,则应选取集合的第一个元素和最后一个元素作为测试用例。
5)如果程序中使用了一个内部数据结构,则应当选择这个内部数据结构的边界上的值作为测试用例。
6)分析规格说明,找出其它可能的边界条件。

二.实战演习
1.现有一个学生标准化考试批阅试卷,产生成绩报告的程序。其规格说明如下:程序的输入文件由一些有80个字符的记录组成,如右图所示,所有记录分为3组:

①标题:这一组只有一个记录,其内容为输出成绩报告的名字。
②试卷各题标准答案记录:每个记录均在第80个字符处标以数字”2″。该组的第一个记录的第1至第3个字符为题目编号(取值为1一999)。第10至第59个字符给出第1至第50题的答案(每个合法字符表示一个答案)。该组的第2,第3……个记录相应为第51至第100,第101至第150,…题的答案。
③每个学生的答卷描述:该组中每个记录的第80个字符均为数字”3″。每个学生的答卷在若干个记录中给出。如甲的首记录第1至第9字符给出学生姓名及学号,第10至第59字符列出的是甲所做的第1至第50题的答案。若试题数超过50,则第2,第3……纪录分别给出他的第51至第100,第101至第150……题的解答。然后是学生乙的答卷记录。
④学生人数不超过200,试题数不超过999。
⑤程序的输出有4个报告:
a)按学号排列的成绩单,列出每个学生的成绩、名次。
b)按学生成绩排序的成绩单。
c)平均分数及标准偏差的报告。
d)试题分析报告。按试题号排序,列出各题学生答对的百分比。
解答:分别考虑输入条件和输出条件,以及边界条件。给出下表所示的输入条件及相应的测试用例。

输出条件及相应的测试用例表。

2.三角形问题的边界值分析测试用例
在三角形问题描述中,除了要求边长是整数外,没有给出其它的限制条件。在此,我们将三角形每边边长的取范围值设值为[1, 100] 。

3.NextDate函数的边界值分析测试用例
在NextDate函数中,隐含规定了变量mouth和变量day的取值范围为1≤mouth≤12和1≤day≤31,并设定变量year的取值范围为1912≤year≤2050 。

因果图方法

一.   方法简介

1.定义:是一种利用图解法分析输入的各种组合情况,从而设计测试用例的方法,它适合于检查程序输入条件的各种组合情况。

2.因果图法产生的背景:

等价类划分法和边界值分析方法都是着重考虑输入条件,但没有考虑输入条件的各种组合、输入条件之间的相互制约关系。这样虽然各种输入条件可能出错的情况已经测试到了,但多个输入条件组合起来可能出错的情况却被忽视了。

如果在测试时必须考虑输入条件的各种组合,则可能的组合数目将是天文数字,因此必须考虑采用一种适合于描述多种条件的组合、相应产生多个动作的形式来进行测试用例的设计,这就需要利用因果图(逻辑模型)。

3.因果图介绍

1) 4种符号分别表示了规格说明中向4种因果关系。

2) 因果图中使用了简单的逻辑符号,以直线联接左右结点。左结点表示输入状态(或称原因),右结点表示输出状态(或称结果)。

3) Ci表示原因,通常置于图的左部;ei表示结果,通常在图的右部。Ci和ei均可取值0或1,0表示某状态不出现,1表示某状态出现。

4. 因果图概念

1)    关系

①恒等:若ci是1,则ei也是1;否则ei为0。

②非:若ci是1,则ei是0;否则ei是1。

③或:若c1或c2或c3是1,则ei是1;否则ei为0。“或”可有任意个输入。

④与:若c1和c2都是1,则ei为1;否则ei为0。“与”也可有任意个输入。

2)    约束

输入状态相互之间还可能存在某些依赖关系,称为约束。例如, 某些输入条件本身不可能同时出现。输出状态之间也往往存在约束。在因果图中,用特定的符号标明这些约束。

A.输入条件的约束有以下4类:

   ① E约束(异):a和b中至多有一个可能为1,即a和b不能同时为1。

   ② I约束(或):a、b和c中至少有一个必须是1,即 a、b 和c不能同时为0。

   ③ O约束(唯一);a和b必须有一个,且仅有1个为1。

   ④R约束(要求):a是1时,b必须是1,即不可能a是1时b是0。

B.输出条件约束类型

   输出条件的约束只有M约束(强制):若结果a是1,则结果b强制为0。

5. 采用因果图法设计测试用例的步骤:

1)分析软件规格说明描述中, 那些是原因(即输入条件或输入条件的等价类),那些是结果(即输出条件), 并给每个原因和结果赋予一个标识符。

2)分析软件规格说明描述中的语义,找出原因与结果之间, 原因与原因之间对应的关系,根据这些关系,画出因果图。

3)由于语法或环境限制, 有些原因与原因之间,原因与结果之间的组合情况不可能出现,为表明这些特殊情况, 在因果图上用一些记号表明约束或限制条件。

4)把因果图转换为判定表。

5)把判定表的每一列拿出来作为依据,设计测试用例。

二. 实战演习

1. 某软件规格说明书包含这样的要求:第一列字符必须是A或B,第二列字符必须是一个数字,在此情况下进行文件的修改,但如果第一列字符不正确,则给出信息L;如果第二列字符不是数字,则给出信息M。

解答:

1) 根据题意,原因和结果如下:

       原因:

         1——第一列字符是A;

         2——第一列字符是B;

         3——第二列字符是一数字。

       结果:

         21——修改文件;

         22 ——给出信息L;

         23——给出信息M。

2) 其对应的因果图如下:

11为中间节点;考虑到原因1和原因2不可能同时为1,因此在因果图上施加E约束。

3)根据因果图建立判定表。

 表中8种情况的左面两列情况中,原因①和原因②同时为1,这是不可能出现的,故应排除这两种情况。表的最下一栏给出了6种情况的测试用例,这是我们所需要的数据。

2.有一个处理单价为5角钱的饮料的自动售货机软件测试用例的设计。其规格说明如下:若投入5角钱或1元钱的硬币,押下〖橙汁〗或〖啤酒〗的按钮,则相应的饮料就送出来。若售货机没有零钱找,则一个显示〖零钱找完〗的红灯亮,这时在投入1元硬币并押下按钮后,饮料不送出来而且1元硬币也退出来;若有零钱找,则显示〖零钱找完〗的红灯灭,在送出饮料的同时退还5角硬币。

1) 分析这一段说明,列出原因和结果

原因:

1.售货机有零钱找

2.投入1元硬币

3.投入5角硬币

4.押下橙汁按钮

5.押下啤酒按钮

结果:

21.售货机〖零钱找完〗灯亮

22.退还1元硬币

23.退还5角硬币

24.送出橙汁饮料

25.送出啤酒饮料

2)画出因果图,如图所示。所有原因结点列在左边,所有结果结点列在右边。建立中间结点,表示处理的中间状态。中间结点:

11. 投入1元硬币且押下饮料按钮

12. 押下〖橙汁〗或〖啤酒〗的按钮

13. 应当找5角零钱并且售货机有零钱找

14. 钱已付清

3)转换成判定表:

4) 在判定表中,阴影部分表示因违反约束条件的不可能出现的情况,删去。第16列与第32列因什么动作也没做,也删去。最后可根据剩下的16列作为确定测试用例的依据。

判定表驱动分析方法

一.    方法简介

1.定义:判定表是分析和表达多逻辑条件下执行不同操作的情况的工具。

2.判定表的优点

能够将复杂的问题按照各种可能的情况全部列举出来,简明并避免遗漏。因此,利用判定表能够设计出完整的测试用例集合。

在一些数据处理问题当中,某些操作的实施依赖于多个逻辑条件的组合,即:针对不同逻辑条件的组合值,分别执行不同的操作。判定表很适合于处理这类问题。

3.“阅读指南”判定表

4. 判定表通常由四个部分组成如下图所示。

1)条件桩(Condition Stub):列出了问题得所有条件。通常认为列出的条件的次序无关紧要。

2)动作桩(Action Stub):列出了问题规定可能采取的操作。这些操作的排列顺序没有约束。

3)条件项(Condition Entry):列出针对它左列条件的取值。在所有可能情况下的真假值。

4)动作项(Action Entry):列出在条件项的各种取值情况下应该采取的动作。

5.规则及规则合并

1)规则:任何一个条件组合的特定取值及其相应要执行的操作称为规则。在判定表中贯穿条件项和动作项的一列就是一条规则。显然,判定表中列出多少组条件取值,也就有多少条规则,既条件项和动作项有多少列。

2)化简:就是规则合并有两条或多条规则具有相同的动作,并且其条件项之间存在着极为相似的关系。

6.规则及规则合并举例

1)如下图左端,两规则动作项一样,条件项类似,在1、2条件项分别取Y、N时,无论条件3取何值,都执行同一操作。即要执行的动作与条件3无关。于是可合并。“-”表示与取值无关。

2)与上类似,下图中,无关条件项“-”可包含其他条件项取值,具有相同动作的规则可合并。

3)化简后的读书指南判定表

1

2

3

4

你觉得疲倦吗?

Y

N

你对内容感兴趣吗?

Y

Y

N

N

书中内容使你胡涂吗?

Y

N

 

请回到本章开头重读

x

继续读下去

X

跳到下一章去读

x

停止阅读,请休息

x

7.判定表的建立步骤:(根据软件规格说明)

1)确定规则的个数.假如有n个条件。每个条件有两个取值(0,1),故有2n种规则。

2)列出所有的条件桩和动作桩。

3)填入条件项。

4)填入动作项。等到初始判定表。

5)简化.合并相似规则(相同动作)。

二. 实战演习

1.问题要求:”……对功率大于50马力的机器、维修记录不全或已运行10年以上的机器,应给予优先的维修处理……” 。这里假定,“维修记录不全”和“优先维修处理”均已在别处有更严格的定义 。请建立判定表。

解答:

①确定规则的个数:这里有3个条件,每个条件有两个取值,故应有2*2*2=8种规则。

②列出所有的条件茬和动作桩:

③填入条件项。可从最后1行条件项开始,逐行向上填满。如第三行是: Y N Y N Y N Y N,第二行是: Y Y N N Y Y N N等等。

④填入动作桩和动作顶。这样便得到形如图的初始判定表。

1

2

3

4

5

6

7

8

功率大于50马力吗?

Y

Y

Y

Y

N

N

N

N

维修记录不全吗?

Y

Y

N

N

Y

Y

N

N

运行超过10年吗?

Y

N

Y

N

Y

N

Y

N

进行优先处理

x

x

X

X

X

作其他处理

X

x

x

初始判定表

⑤化简。合并相似规则后得到图。

1

2

3

4

5

功率大于50马力吗?

Y

Y

Y

N

N

维修记录不全吗?

Y

N

N

运行超过10年吗?

Y

N

Y

N

进行优先处理

x

x

X

作其他处理

x

x

2.NextData函数的精简决策表

M1={月份, 每月有30天}

M2={月份, 每月有31天}

M3={月份,2月}                 有29=512条规则

D1={日期,1~28}                 12月末31日和其它31

D2={日期,29}                    日月份的31日处理不同

D3={日期,30}                    平年2月28日处理不同

D4={日期,31}                    于2月27日

Y1 ={年:年是闰年}

Y2 ={年:年不是闰年}

改进为

M1={月份: 每月有30天}

M2={月份: 每月有31天,12月除外}

M4={月份:12月}

M3={月份:2月}

D1={日期:1<=日期<=27}

D2={日期:28}

D3={日期:29}

D4={日期:30}

D5={日期:31}

Y1 ={年:年是闰年}

Y2 ={年:年不是闰年}

输入变量间存在大量逻辑关系的NextData决策表

3. 用决策表测试法测试以下程序:该程序有三个输入变量month、day、year(month、day和year均为整数值,并且满足:1≤month≤12和1≤day≤31),分别作为输入日期的 月份、日、年份,通过程序可以输出该输入日期在日历上隔一天的日期。例如,输入为2004年11月29日,则该程序的输出为2000年12月1日。

1)分析各种输入情况,列出为输入变量month、day、year划分的有效等价类。

2)分析程序规格说明,结合以上等价类划分的情况给出问题规定的可能采取的操作(即列出所有的动作桩)。

3)根据(1)和(2),画出简化后的决策表。

案例分析如下:

1)month变量的有效等价类:

 M1: {month=4,6,9,11}

 M2: {month=1,3,5,7,8,10}

M3: {month=12}

 M4: {month=2}

2)day变量的有效等价类:

    D1:{1≤day≤26}         D2: {day=27}         D3: {day=28}                    D4: {day=29}                    D5: {day=30}                D6: {day=31}

3)year变量的有效等价类:

Y1: {year是闰年}                Y2:  {year不是闰年}

4)考虑各种有效的输入情况,程序中可能采取的操作有以下六种:

a1: day+2                       a2: day=2                    a3: day=1

a4: month+1                     a5: month=1                  a6: year+1

4. 判定表在功能测试中的应用

1)一些软件的功能需求可用判定表表达得非常清楚,在检验程序的功能时判定表也就成为一个不错的工具。如果一个软件的规格说明指出:

I. 当条件1和条件2满足,并且条件3和条件4不满足,或者当条件1、3和条件4满足时,要执行操作1。

II. 在任一个条件都不满足时,要执行操作2。

III. 在条件1不满足,而条件4被满足时,要执行操作3。 根据规格说明得到如下判定表:

这里,判定表只给出了16种规则中的8种。事实上,除这8条以外的一些规则是指当不能满足指定的条件,执行3种操作时,要执行1个默许的操作。在没必要时,判定表通常可略去这些规则。但如果用判定表来设计测试用例,就必须列出这些默许规则(如下表)。

规则5

规则6

规则7

规则8

条件1

N

Y

Y

条件2

Y

Y

N

条件3

Y

N

N

N

条件4

N

N

Y

默许操作

x

x

x

x

默许的规则

2)判定表的优点和缺点

I.  优点:它能把复杂的问题按各种可能的情况一一列举出来,简明而易于理解,也可避免遗漏。

II. 缺点:不能表达重复执行的动作,例如循环结构。

3)B. Beizer 指出了适合使用判定表设计测试用例的条件:

①规格说明以判定表形式给出,或很容易转换成判定表。

②条件的排列顺序不会也不影响执行哪些操作。

③规则的排列顺序不会也不影响执行哪些操作。

④每当某一规则的条件已经满足,并确定要执行的操作后,不必检验别的规则。

⑤如果某一规则得到满足要执行多个操作,这些操作的执行顺序无关紧要。

B. Beizer提出这5个必要条件的目的是为了使操作的执行完全依赖于条件的组合。其实对于某些不满足这几条的判定表,同样可以借以设计测试用例,只不过尚需增加其它的测试用例罢了。

正交实验设计方法

一.方法简介

利用因果图来设计测试用例时, 作为输入条件的原因与输出结果之间的因果关系,有时很难从软件需求规格说明中得到。往往因果关系非常庞大,以至于据此因果图而得到的测试用例数目多的惊人,给软件测试带来沉重的负担,为了有效地,合理地减少测试的工时与费用,可利用正交实验设计方法进行测试用例的设计。

正交实验设计方法:依据Galois理论,从大量的(实验)数据(测试例)中挑选适量的,有代表性的点(例),从而合理地安排实验(测试)的一种科学实验设计方法.类似的方法有:聚类分析方法,因子方法方法等.

利用正交实验设计测试用例的步骤:

1.提取功能说明,构造因子–状态表

把影响实验指标的条件称为因子.而影响实验因子的条件叫因子的状态.利用正交实验设计方法来设计测试用例时,首先要根据被测试软件的规格说明书找出影响其功能实现的操作对象和外部因素,把他们当作因子,而把各个因子的取值当作状态.对软件需求规格说明中的功能要求进行划分,把整体的概要性的功能要求进行层层分解与展开,分解成具体的有相对独立性的基本的功能要求.这样就可以把被测试软件中所有的因子都确定下来,并为确定个因子的权值提供参考的依据.确定因子与状态是设计测试用例的关键.因此要求尽可能全面的正确的确定取值,以确保测试用例的设计作到完整与有效。

2.加权筛选,生成因素分析表

对因子与状态的选择可按其重要程度分别加权.可根据各个因子及状态的作用大小,出现频率的大小以及测试的需要,确定权值的大小。

3.利用正交表构造测试数据集

正交表的推导依据Galois理论(这里省略,需要时可查数理统计方面的教材)。

利用正交实验设计方法设计测试用例,比使用等价类划分,边界值分析,因果图等方法有以下优点:节省测试工作工时;可控制生成的测试用例数量;测试用例具有一定的覆盖率。

功能图分析方法

一.方法简介

一个程序的功能说明通常由动态说明和静态说明组成.动态说明描述了输入数据的次序或转移的次序.静态说明描述了输入条件与输出条件之间的对应关系.对于较复杂的程序,由于存在大量的组合情况,因此,仅用静态说明组成的规格说明对于测试来说往往是不够的.必须用动态说明来补充功能说明.功能图方法是用功能图FD形式化地表示程序的功能说明,并机械地生成功能图的测试用例. 功能图模型由状态迁移图和逻辑功能模型构成.状态迁移图用于表示输入数据序列以及相应的输出数据.在状态迁移图中,由输入数据和当前状态决定输出数据和后续状态.逻辑功能模型用于表示在状态中输入条件和输出条件之间的对应关系.逻辑功能模型只适合于描述静态说明,输出数据仅由输入数据决定.测试用例则是由测试中经过的一系列状态和在每个状态中必须依靠输入/输出数据满足的一对条件组成.功能图方法其实是是一种黑盒白盒混合用例设计方法。

(功能图方法中,要用到逻辑覆盖和路径测试的概念和方法,其属白盒测试方法中的内容.逻辑覆盖是以程序内部的逻辑结构为基础的测试用例设计方法.该方法要求测试人员对程序的逻辑结构有清楚的了解.由于覆盖测试的目标不同,逻辑覆盖可分为:语句覆盖,判定覆盖,判定-条件覆盖,条件组合覆盖及路径覆盖.下面我们指的逻辑覆盖和路径是功能或系统水平上的,以区别与白盒测试中的程序内部的.)

1.功能图

功能图由状态迁移图和布尔函数组成.状态迁移图用状态和迁移来描述.一个状态指出数据输入的位置(或时间),而迁移则指明状态的改变.同时要依靠判定表或因果图表示的逻辑功能.例,一个简化的自动出纳机ATM的功能图。

2.测试用例生成方法

从功能图生成测试用例,得到的测试用例数是可接受的. 问题的关键的是如何从状态迁移图中选取测试用例.若用节点代替状态,用弧线代替迁移,则状态迁移图就可转化成一个程序的控制流程图形式.问题就转化为程序的路径测试问题(如白盒测试)问题了.

3.测试用例生成规则

为了把状态迁移(测试路径)的测试用例与逻辑模型(局部测试用例)的测试用例组合起来,从功能图生成实用的测试用例,须定义下面的规则.在一个结构化的状态迁移(SST)中,定义三种形式的循环:顺序,选择和重复.但分辨一个状态迁移中的所有循环是有困难的.(其表示图形省略)。

4.从功能图生成测试用例的过程

1)生成局部测试用例:在每个状态中,从因果图生成局部测试用例.局部测试用例由原因值(输入数据)组合与对应的结果值(输出数据或状态)构成。

2)测试路径生成:利用上面的规则(三种)生成从初始状态到最后状态的测试路径。

3)测试用例合成:合成测试路径与功能图中每个状态中的局部测试用例.结果是初始状态到最后状态的一个状态序列,以及每个状态中输入数据与对应输出数据的组合。

5.测试用例的合成算法:采用条件构造树.

场景设计方法

一.方法简介

现在的软件几乎都是用事件触发来控制流程的,事件触发时的情景便形成了场景,而同一事件不同的触发顺序和处理结果就形成事件流。这种在软件设计方面的思想也可以引入到软件测试中,可以比较生动地描绘出事件触发时的情景,有利于测试设计者设计测试用例,同时使测试用例更容易理解和执行。

基本流和备选流:如下图所示,图中经过用例的每条路径都用基本流和备选流来表示,直黑线表示基本流,是经过用例的最简单的路径。备选流用不同的色彩表示,一个备选流可能从基本流开始,在某个特定条件下执行,然后重新加入基本流中(如备选流1和3);也可能起源于另一个备选流(如备选流2),或者终止用例而不再重新加入到某个流(如备选流2和4)。

二.实战演习

1. 例子描述

下图所示是ATM例子的流程示意图

2.场景设计:下表所示是生成的场景。

表3-8 场景设计

场景1——成功提款

基本流

场景2——ATM内没有现金

基本流

备选流2

场景3——ATM内现金不足

基本流

备选流3

场景4——PIN有误(还有输入机会)

基本流

备选流4

场景5——PIN有误(不再有输入机会)

基本流

备选流4

场景6——账户不存在/账户类型有误

基本流

备选流5

场景7——账户余额不足

基本流

备选流6

注:为方便起见,备选流3和6(场景3和7)内的循环以及循环组合未纳入上表。

3.用例设计

对于这7个场景中的每一个场景都需要确定测试用例。可以采用矩阵或决策表来确定和管理测试用例。下面显示了一种通用格式,其中各行代表各个测试用例,而各列则代表测试用例的信息。本示例中,对于每个测试用例,存在一个测试用例ID、条件(或说明)、测试用例中涉及的所有数据元素(作为输入或已经存在于数据库中)以及预期结果。

表3-9 测试用例表

TC(测试用例)ID号

场景/条件

PIN

账号

输入(或选择)的金额

账面

金额

ATM内的金额

预期结果

CW1

场景1:成功提款

V

V

V

V

V

成功提款

CW2

场景2:ATM内没有现金

V

V

V

V

I

提款选项不可用,用例结束

CW3

场景3:ATM内现金不足

V

V

V

V

I

警告消息,返回基本流步骤6,输入金额

CW4

场景4:PIN有误(还有不止一次输入机会)

I

V

n/a

V

V

警告消息,返回基本流步骤 4,输入 PIN

CW5

场景4:PIN有误(还有一次输入机会)

I

V

n/a

V

V

警告消息,返回基本流步骤 4,输入 PIN

CW6

场景4:PIN有误(不再有输入机会)

I

V

n/a

V

V

警告消息,卡予保留,用例结束

4.数据设计

一旦确定了所有的测试用例,则应对这些用例进行复审和验证以确保其准确且适度,并取消多余或等效的测试用例。

测试用例一经认可,就可以确定实际数据值(在测试用例实施矩阵中)并且设定测试数据,如表3-10所示。

表3-10     测试用例表

TC(测试用例)ID号

场景/条件

PIN

账号

输入(或选择)的金额

(元)

账面
金额(元)

ATM内的金额(元)

预期结果

CW1

场景1:成功提款

4987

809-498

50.00

500.00

2 000

成功提款。账户余额被更新为450.00

CW2

场景2:ATM内没有现金

4987

809-498

100.00

500.00

0.00

提款选项不可用,用例结束

CW3

场景3:ATM内现金不足

4987

809-498

100.00

500.00

70.00

警告消息,返回基本流步骤6,输入金额

CW4

场景4:PIN有误(还有不止一次输入机会)

4978

809-498

n/a

500.00

2 000

警告消息,返回基本流步骤4,输入PIN

CW5

场景4:PIN有误(还有一次输入机会)

4978

809-498

n/a

500.00

2 000

警告消息,返回基本流步骤4,输入PIN

CW6

场景4:PIN有误(不再有输入机会)

4978

809-498

n/a

500.00

2 000

警告消息,卡予保留,用例结束

错误推测方法

一.方法简介

1.定义:基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法。

2.错误推测方法的基本思想:

列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例。

1)例如, 输入数据和输出数据为0的情况;输入表格为空格或输入表格只有一行。 这些都是容易发生错误的情况。可选择这些情况下的例子作为测试用例。

2)例如,前面例子中成绩报告的程序,采用错误推测法还可补充设计一些测试用例:

I.程序是否把空格作为回答

II.在回答记录中混有标准答案记录

III.除了标题记录外,还有一些的记录最后一个字符即不是2也不是3

IV.有两个学生的学号相同

V.试题数是负数。

3)再如,测试一个对线性表(比如数组)进行排序的程序,可推测列出以下几项需要特别测试的情况:

I.输入的线性表为空表;

II.表中只含有一个元素;

III.输入表中所有元素已排好序;

IV.输入表已按逆序排好;

V.输入表中部分或全部元素相同。

测试用例设计综合策略

1.Myers提出了使用各种测试方法的综合策略:

1)在任何情况下都必须使用边界值分析方法,经验表明用这种方法设计出测试用例发现程序错误的能力最强。 【文章来源:文斯测试技术研究中心http://blog.csdn.net/vincetest

2)必要时用等价类划分方法补充一些测试用例。

3)用错误推测法再追加一些测试用例。

4)对照程序逻辑,检查已设计出的测试用例的逻辑覆盖程度,如果没有达到要求的覆盖标准,应当再补充足够的测试用例。

5)如果程序的功能说明中含有输入条件的组合情况,则一开始就可选用因果图法。

2.测试用例的设计步骤【文章来源:文斯测试技术研究中心http://blog.csdn.net/vincetest

1)构造根据设计规格得出的基本功能测试用例;

2)边界值测试用例;

3)状态转换测试用例;

4)错误猜测测试用例;

5)异常测试用例;【文章来源:文斯测试技术研究中心http://blog.csdn.net/vincetest

6)性能测试用例;

7)压力测试用例。

3.优化测试用例的方法

1)利用设计测试用例的8种方法不断的对测试用例进行分解与合并;

2)采用遗传算法理论进化测试用例;

3)在测试时利用发散思维构造测试用例。

原网页地址:http://blog.csdn.net/wanglilingb/article/details/54019467

总结:

通过这篇文章我更加详细的了解了测试用例的设计方法,对于测试用例有了更新的认识,这篇文章讲到的测试用例的设计方法有等价类划分方法、边界值分析法、因果图法、判定表驱动法、正交实验设计法、功能图分析法、场景设计法、错误推测法。这些方法我会在以后的工作中去尽量的尝试使用。

APP测试要点

APP测试要点
APP测试的时候,建议让开发打好包APK和IPA安装包,测试人员自己安装应用,进行测试。在测试过程中需要注意的测试点如下: 1.安装和卸载
●应用是否可以在IOS不同系统版本或android不同系统版本上安装(有的系统版本过低,应用不能适配)
●软件安装后是否可以正常运行,安装后的文件夹及文件是否可以写到指定的目录里。
●安装过程中是否可以取消
●安装空间不足时是否有相应提示
●如果应用需要通过网络验证之类的安装,需要测试一下断网情况下是否有相应提示
●是否可以删除应用(可通过桌面删除,也可以通过软件卸载安装。曾发现在IOS手相上有个应用安装时未完全安装,终止安装后,未完成安装的应用图标一直显示在手机上,并且无法成功删除)
●测试卸载后文件是否全部删除所有的安装文件夹
●卸载过程中出现死机,断电,重启等意外的情况,待环境恢复后是否可以正确卸载
●卸载是否支持取消功能,单击取消后软件卸载情况是否正常
2.运行
●APP安装完成后,是否可以正常打开软件
●APP运行时,是否有加载图示
●APP的速度是可以让人接受,切换是否流畅
●用户登录状态太久,sessionId会过期,会出现“虽然是登录状态,系统会提示用户没有登录。
 3.登录
●登录用户名和密码错误时,界面有提示信息
●用户主动退出登录后,下次启动APP时,应该进入登录界面
●对于支持自动登录的APP,数据交换时  ,是否能自动登录成功且数据库操作无误
●密码更改后,登录时是否做到了有效数据的校验
●对于未登录时一些页面的操作,是否做了控制
●切换账号登录,检验登录的信息是否做到及时更新
●对于多个端都进行操作时,确保数据库操作无误,且每个端可以及时看到数据的更新
●对于一些软件,支持一个账号只允许登录一台机器,这时,需要检查账号登录多个手机时,是否将原用户剔除,且能够给出提示信息
● APP切换到后台时,再次切换到前台的测试,如登录时,有电话打进来
●对于IOS与android不同设备登录同一个账号时,对个人信息等数据进行操作后,确保数据数库操作无误,且IOS与android设备看到的数据都是最新的。
 4.离线
  离线是应用程序在本地的客户端会缓存一部分数据以功程序下次调用
●对于一些程序,需要在登录进来后,这时没有网络的情况下可以浏览本地数据
●对于无网络时,刷新获取新数据时,不能获取数据且能给出友好提示
●切换到后台,再次切换到前台时,可以正常查看
●离线后又连上网,这时对数据有更新时,需要从服务器端获取新数据来更新客户端数据,且要更新本地缓存信息
●对于一些界面的数据不提供离线查看,需要给出相应提示且界面更新后无任何数据
●确认在无网情况下可以浏览本地数据
●确认退出APP再开启APP时能正常浏览
●确认切换到后台再切回APP应用时可以正常浏览
●锁屏后再解锁回到应用前台可以正常浏览
●服务端的数据有更新时有离线的提示
5.数据更新
●确认有数据更新后,哪些地方需要手动刷新,哪些地方需自动刷新。
●确认从后台切换回前台时,哪些页面需要进行数据更新
●根据需求和逻辑,确认哪些数据是从服务端请求实时响应,哪些是缓存到本地的数据。
 6.消息推送开关设置
●默认开关应该是全打开状态
●设置开关可以自由打开关闭
●设置开关打开状态下,消息推送是否可正常接收(应用启用中和应用关闭时都应该可以收到)
●确认后台未打开APP客户端时,手机消息栏可以接收到消息提醒。且点击可查看。点击后消息栏中消失
●确认APP客户端启动时,可以收到消息提醒,且点击可查看。客户端运行时,消息不会进消息栏。
●设置开关关闭时,客户端接收不到消息推送。 7.软件更新
●当客户端有新版本时,有更新提示
●软件更新一定要测,确保android软件更新可以正确更新新版本,且安装运行正确。
●确保IOS软件更新会有限制,只有上了商店且有版本更新时才会测试,但是如果真有问题,再发现问题不点晚,可以让开发先在测试机上模拟一个地址进行测试。
●用户取消版本更新时,老版本可以正常使用,但是下次启动应用时,仍出现更新提示
●当有新版本时,不删除客户端的情况下,直接更新检查是否能正常更新,且更新后客户端的功能是否最新版本(正常来讲不用强制删除本地客户端可以正常更新)
8.异常测试
●没有内存空间时,APP能否正确响应
●APP运行中手机断电
●APP运行中断开网络
●反复操作某个功能,不断点击,刷新时,是否会闪退
●APP运行时拔打或接听电话
●APP运行时发送信息、收取邮件等
●多个APP运行时
●不断切换前台和后台,是否影响应用正常功能
●APP运行时,启动相机功能
9.网络环境
●测试2G、3G,4G,wifi 网络下应用运应的速度
●内网测试时,选择到外网操作是否有异常处理
●网络不好时 , 提交数据是否一直处理提交中,是否会有延迟,数据交换失败是否会有提醒
●有网到无网再到有网环境时,数据是否可以自动恢复,正常加载
10.其它
●接口测试。让开发提供一份接口文档,一定要将接口测试通。在接口测试阶段,将缺少接口,接口不完善的缺陷挖掘出来。这个需要准备充分的后台数据。
●导航测试。在运行APP时,不管在哪个接点,导航是否直观,精准,页面切换是否正确。
●图片测试。图片,按钮是否自适应。
●内容测试。要进行超长字符,空字符校验且校验是否有错别字
●功能测试。功能是否实现。
●易用性测试。所开发的功能,是否让用户容易接受,是否符合大众的操作习惯。
●适配性测试。应用在不同设备,不同系统上是否适配。
●UI测试。应用的设计是否够美观。
总结:
这篇文章加强了我对APP测试的认识,让我更加深刻的认识了APP测试的测试点。我会在以后的测试中尽可能的去全面考虑测试点。认真分析每个可能出现问题的点。