《软件测试的艺术》 笔记I

测试哲学：测试不是为了验证功能有效，而是为了发现程序针对用例的错误

软件测试中最重要的因素是设计和生成有效的测试用例。
完全的测试是不可能的，最显然的测试策略是努力使测试尽可能完全。
推荐方法：通过使用特定的面向黑盒测试的测试用例设计方法，而后使用白盒测试方法对程序的逻辑结构进行检查以补充这些测试用例，借此来设计出一个相当严格的测试   功能测试是一个试图发现程序与其外部规格说明之间存在不一致的过程。外部规格说明是一份从最终用户的角度对程序行为的精确描述。

软件开发过程与测试过程

软件测试的目标是发现问题

 模块测试的目的是发现程序模块与其接口规格说明之间的不一致。

·功能测试的目的是为了证明程序未能符合其外部规格说明。

·系统测试的目的是为了证明软件产品与其初始目标不一致。

功能测试

在进行功能测试时，需要对规格说明进行分析以提炼测试用例。
 应记住对无效和未预想到的输入条件给予足够的重视
功能测试的目的是为了暴露程序的错误以及发现程序与规格说明书中的不一致之处，而不是为了证明程序符合其规格说明书。 

系统测试

系统测试有着特定的目的：将系统或程序与其初始目标进行比较。系统测试的目的是为了证明程序不能实现其目标，应设计用例来证明目前没有得到满足。
 系统测试依据的是程序目标和用户文档。

分类

系统测试包括能力测试、容量测试、强度测试、可用性测试...
 能力测试-判断目标文档提及的每一项能力或者功能，是否都确实已实现。
 容量测试-使程序经受大容量数据的检验。
 强度测试-使程序承受高负载或强度的检验。所谓高强度是指在很短的时间间隔内达到的数据或操作的数量峰值。如打字员能否达到每分钟50个单词的速度。如可能访问站点的最大人群的情况。（疑问：这里的强度测试是否就是压力测试）
  可用性测试，又叫用户体验测试。
  安全性测试，设计测试用例来突破程序安全检查的过程。我们必须向客户群证明软件是安全的，否则就会有失去客户的风险。
  性能测试，特定负载和配置环境下程序的响应时间和吞吐率
  存储测试，程序使用的内存，辅存容量。
  配置测试，硬件配置，也包括兼容性测试，如软件在不同浏览器，不同操作系统下。
  兼容性测试，涉及与现有系统的兼容转换。
  安装测试，安装程序如果出现故障，会影响用户对软件的成功体验。
  可靠性测试，这里指的是长时间运行。
  可恢复性测试，系统发现错误，能否恢复？多长时间可以恢复？
  服务/可维护性测试，系统提供的服务辅助功能，如帮助文档是否完善，质量如何？
  文档测试，用户文档应成为审查对象，检查其正确性和清晰性。在文档中描述的任何范例应编成测试用例，并提交给程序。
  过程测试，在系统测试中，必须对所有已规定的人工过程，如系统操作员、数据库管理员或最终用户的操作过程进行测试。

  系统测试由谁来执行？1、不能由程序员来进行 2、不能由负责该程序开发的机构来执行。
  理想的系统测试小组应由几位专业的系统测试专家（以执行系统测试作为职业）、一位或两位最终用户的代表、一位人类工程学工程师以及该程序主要的分析人或设计者所组成
  也许最经济的执行系统测试的方式（所谓经济，是指花一定的成本发现最多的错误，或利用更少的费用发现相同数量的错误）是将测试分包给一个独立的公司来完成。
 

验收测试

验收测试是将程序与其最初的需求及最终用户当前的需要进行比较的过程

该测试通常是由程序的客户或最终用户来进行

将程序的实际操作与原始合同进行对照

验收测试最好的方法是设计测试用例，尽力证明程序没有满足合同要求

测试计划与控制

在计划测试过程中最常出现的主要错误是默认为不会发现软件缺陷

一个良好的测试计划应包括：

目标--结束准则--进度--责任--测试用例库及标准--工具--计算机时间--硬件配置--集成--跟踪步骤--调试步骤--回归测试

测试结束准则

最常见的两个准则是：1.用完了安排的测试时间后，测试便结束。2.当执行完所有测试用例都未发现错误，测试便结束。也就是说，当所有的测试用例不成功时便结束。但在本书中，这两条准则都解释为没用。

本书建议用另外三类准则的组合来判断测试是否应该结束。

第一类，但不是最佳的准则，根据的是特定的测试用例设计技术。举例来说，我们会这样定义模块测试的结束准则：测试用例来源于（1）满足多重条件覆盖准则，（2）对模块接口规格说明进行边界值分析，产生的所有测试用例最终都是不成功的。我们会在满足下列情况时规定功能测试结束：测试用例来源于（1）因果图分析，（2）边界值分析，（3）错误猜测，产生的所有测试用例最终都是不成功的。这里的不成功，意思是没有发现更多缺陷。

第二类，也许也是最有价值的准则，是以确切的数量来描述结束测试的条件。

第三类，它需要我们在测试过程中记录每单位时间内发现的错误数量。通过检查统计曲线的形状，常常可以决定究竟是继续该阶段的测试，还是结束它并开始下一测试阶段。（发现缺陷曲线收敛）

这三类准则都有不足之处，但对于模块测试而言，建议用第一类。对于功能测试和系统测试，建议综合三类并考虑最常见的两个准则。

可用性测试（用户体验测试）

可用性或基于用户的测试基本上属于黑盒测试的范畴

黑盒测试就是竭力找寻被测软件不符合设计规格的情况。

用户可用性测试应该从功能缺陷到不符合人机工程学的设计失误来揭示软件设计存在的问题。

一个“局外人”却能通过对软件不按常理出牌的使用方式在很短时间内发现问题和故障。

基本要素

1.是否每一个用户交互设计都考虑到最终用户的理解力、教育背景以及环境压力？

2.程序的输出是否有意义、没有侮辱性的词语，以及是否含糊不清？

3.用来错误诊断的提示的信息（error message）是直白易懂，还是需要计算机博士才可读懂？

4.用户界面上是否保持概念的一致、内部的连贯性、语法的一致性？

5.需要高精确性和准确度的软件系统是否提供了足够有效的输入验证？如验证码

6.系统是不是包含了太多选项，或者包含的一些选项不会被使用

7.对于来自用户的输入，系统是否能够及时做出反应？

8.程序的操作是否很容易上手？

9.软件的设计是否有助于用户准确输入？

10.用户的操作可以轻松重复吗？

11.用户是否确定能够在众多的功能和菜单中来回切换而不发生意外

12.软件的功能实现是否达到了设计规格要求？

本章还讲解了一些用户体验测试的细节。

互联网应用测试

web应用系统分为三层，表示层、业务层、数据层。

表示层。互联网应用系统的这一层提供了GUI（图形用户接口）。

·业务逻辑层。该层模拟业务流程，比如用户身份验证、事务处理等。

·数据访问层。该层存储了供应用系统使用的或从最终用户收集来的数据。

测试面对的挑战：用户群体五花八门、业务环境、安全性、测试环境、浏览器兼容性、性能、保持网站对用户的可用性、网络连通性。

 测试基于互联网的应用系统最好采用“分而治之”的方法。

测试表示层的主要目的是发现应用程序的GUI或前端中的错误。

表示层测试中的三个主要内容：1.内容测试。包括整体审美、字体、色彩、拼写、内容准确性和默认值。2.Web站点结构。包括无效的链接或图形。3.用户环境。包括Web浏览器版本和操作系统配置。

业务层测试的重点是发现互联网应用系统的业务逻辑中的错误

对于内部开发的部件，应使用白盒测试。第三方组件，最好采用黑盒测试技术。

且要注意性能、数据有效性、事务。

数据层的测试，主要是指对应用系统用于储存和获取信息的数据库管理系统的测试。

注意响应时间、数据完整性、容错性和可恢复性。

移动应用测试

挑战：移动设备多样、网络基础设备、脚本编程、可用性测试。

1、在需求收集和规格书创建阶段，就得在众多的机型中做出艰难的抉择，首先挑选出可以作为程序的目标支持机型，随后用它来进行测试

2、必须克服基于位置的服务带来的障碍