11/15/2008

Notes: "The Art of Software Testing" - 3

The Art of Software Testing


PART III - 怎样设计测试用例


  测试用例的设计坚持的原则:用尽可能少的用例,发现经可能多的错误.或者换句话说,寻找最有效的那个测试用例集合.

一 基于白盒测试的用例设计原则

  • 1. 测试的主要关注点(目标):代码覆盖率.
  • 2. 语句覆盖(Statement Coverage)指的是代码被测试时,有多少语句被执行到.这种覆盖的语义太弱,很多逻辑分支无法反映.
  • 3. 判定覆盖(Decision Coverage)将会把所有分支语句的真假分支路径计算在覆盖率统计内,涵盖了语句覆盖的概念.
  • 4. 条件覆盖(Condition Coverage)则是要求每个判断语句中的每个条件表达式所有可能的结果都出现了,才算真正覆盖.但是请注意,判定覆盖不能确保分支覆盖,因为它并没有要求判定语句中不同条件表达式结果的组合情况.
  • 5. 判定条件覆盖,同时满足3和4的要求.但是由于逻辑表达式的by pass优化的存在,有些组合路径并没有考虑进去.
  • 6. 多重条件覆盖(multiple-condition coverage),要求将判断语句中每个条件的不同结果的组合都计算入内,作为测试应该覆盖的目标. 但是由于没有将不同判断语句间的结果进行组合,仍然不能覆盖所有的程序路径.


二 基于黑盒测试的用例设计原则

  • 1. 等价类划分:有很多测试用例,他们发现潜在错误的能力是相同的,这时候,他们属于一个等价类.这个等价类中的任何一个成员用例用作测试,作用是完全一样的.
  • 2. 边界值分析:当对输入参数有范围的限制描述时,比较适合按照边界值来设计多个测试用例.
  • 3. 因果图分析,主要用来处理输入参数进行组合的问题.


三 其它设计用例的方法

  • 1. 错误猜测,是一种依靠直觉来进行用例编写的方法.通过估计程序可能在什么地方出错而设计相应的用例,对程序进行测试.


PART VI - 调试:处理测试结果


一 调试的策略

  • 1. 暴力调试法(Brute Force):通常使用了查看内存,打印信息,集成调试工具等方法.优点是比较直观,能获得很多了解内部状态的机会.但是这忽略了思考的过程,产生的数据量过大,不利于确定问题的效率.
  • 2. 归纳调试法(Induction):归纳是一种从特殊到一般的思维方式和过程.从细节到全局,从线索出发,寻找线索之间的联系,作出假设,再验证假设,最后发现并解决问题.
  • 3. 演绎调试法(Reduction):演绎是从普遍的道理到某一个具体的问题的思考方式.先根据最后的后果列举所有的可能的假设,再利用数据进行排除,最后验证精炼后的假设,最后修改.
  • 4. 回溯调试法(Backtracking),从发生错误的地方,推断造成错误的地方.
  • 5. 测试调试法(Testing),通过修改发现错误的测试用例来帮组进一步发现定位问题.


二 调试的原则

  • 1. 先思考,再调试.
  • 2. 遇困难,先休息.
  • 3. 与人交谈,是发现问题的一种好方法.
  • 4. 尽量避免使用测试工具.
  • 5. 尽量避免使用试验法,尝试法.
  • 6. 存在一个缺陷的地方,往往也存在其它的缺陷
  • 7. 应该意识到修正一个错误可能会引入新的错误.做自动回归测试在修正错误时是非常重要的.
  • 8. 正确修改错误的可能性随着程序规模的增加而降低.


PART V - 新兴测试技术


一 极限测试


  极限编程(eXtreme Programming)是敏捷软件开发(Agile)方法学下的一种软件开发过程,产生的初衷是为了适应社会发展到今天,业务和需求的快速变化.测试在极限编程中处于非常重要的地位,称为"极限测试".

1. 极限编程的基本概念

  • 1). 适合于中小规模,需求快速变化的团队.
  • 2). 需求分析与计划,核心概念:用户场景(User Scenario)来描述需求,客户决定特性(Feature)优先级,开发人员决定功能所需时间.
  • 3). 小规模,不断迭代,递增地发布软件和功能.
  • 4). 系统隐喻(System Metaphor).(不是很理解)
  • 5). 简要设计(Simple Design),假定变化总是会发生,简要设计方便适应变化.
  • 6). 持续测试(Continuous Testing),开发之前编写单元测试用例,不断用测试来验证开发的正确性.
  • 7). 重视重构(Refactoring),迭代的过程里不断优化,重构代码.重构后,需要通过单元测试.
  • 8). 结对编程(Pair Programming),两位程序员用一台电脑进行工作.
  • 9). 代码集体拥有, 代码是由整个团队而不是某个程序员拥有的.
  • 10). 持续集成, 实现每日构建(Daily Build),让最终系统始终可得.
  • 11). 每周工作40小时, 避免加班.
  • 12). 客户在场(on-site customer),由客户不断提出反馈意见.
  • 13). 标准编码,团队所有人提交的代码必须尽量一致.


2. 极限编程下的测试

  • 1). 单元测试:在开发之前编写测试用例,好处:有助开发前了解系统规格;方便重构;开发人员更容易获得信息.由于单元测试需要持续进行,因此一个良好的测试框架,运行和报告工具非常重要.
  • 2). 验收测试:由客户根据用户场景来执行的测试.反馈结果也需要排定优先级.


二 Web测试


1. Web测试面临的挑战

  • 客户端浏览器和操作系统平台千差万别
  • 客户到服务器的连接类型比较多
  • 在涉及金融和财务时,事务概念很重要,测试事务是比较困难的任务
  • 客户可能来自不同的国家和地区,语言,时区,货币符号都需要考虑
  • 由于网站的用户粘着度较低,需要良好的用户体验才能留住客户,如果测试用户体验,是个很困难的问题
  • 网站的在不同负载时的性能表现差别很大,需要模拟各种负载
  • 由于网站的公开性,需要考虑可能的攻击(DoS)


2. 测试策略

  • 事先定义好功能性和非功能性规格说明,作为测试的依据
  • 采用分而治之的方式分别测试表现层,逻辑层和数据层


3. 表示层的测试

  • 内容测试:字体,语法,色彩等等
  • 结构测试:链接,图片,文件的可达性
  • 用户环境:浏览器和操作系统的不同组合,Javascript, ActiveX, Java Applet等等的测试


4. 业务层的测试

  • 性能测试:响应时间和吞吐率,测试时需要模拟典型用户的访问操作
  • 数据验证:测试数据收集模块的功能,检查能否正确处理各种输入
  • 事务测试


5. 数据层测试

  • 响应时间,主要是数据规模达到一定程度时的查询性能
  • 数据完整性,看数据是否满足业务规范
  • 容错性,测试数据库端在容错方面的一些表现



No comments: