软件测试的艺术

所谓软件测试，就是一个过程或一系列过程．用来确认计算机代码完成了其应该完成的功能不执行其不该有的操作。软件应当是可预测且稳定的，不会给用户带来意外惊奇。作者眼中的测试：2.1软件测试的心理学测试执行得差，其中一个主要原因在于大多数的程序员一开始就测试这个术语的定义搞错了，他们可能会认为：1.软件测试就是证明软件不存在错误的过程。2.软件测试的目的在于证明软件能够正确完成其预定的功能。3.软件测试就是建立一个‘软件做了其应该做的’信心的过程。那么，对于测试，更为合适的定义应该是：测试是为发现错误而执行程序的过程2.2软件测试的经济学2.2.1黑盒测试黑盒测试：又被称为功能测试、数据驱动测试或基于规格说明的测试，是通过使用整个软件或某种软件功能来严格地测试,而并没有通过检查程序的源代码或者很清楚地了解该软件的源代码程序具体是怎样设计的。测试人员通过输入他们的数据然后看输出的结果从而了解软件怎样工作。2.2.2白盒测试白盒测试：是通过程序的源代码进行测试而不使用用户界面这种类型的测试，需要从代码语法发现内部代码在，算法，溢出，路径，条件等等中的缺点或者错误，进而加以修正。2.3软件测试的原则原则l：测试用例中一个必需部分是对预期输出或结果的定义。原则2：程序员应当避免测试自己编写的程序．原则3：编写软件的组织不应当测试自己编写的软件．原则4：应当彻底检查每个测试的执行结果。原则5：测试用例的编写不仅应当根据有效和预期的输入情况，而且也应当根据无效和未预料到的输入情况。原则6：检查程序是否“未做其应该做的”仅是测试的一半，测试的另一半是检查程序是否“做了其不应该做的”。原则7：应避免测试用例用后即弃，除非软件本身就是一个一次性的软件。原则8：计划测试工作时不应默许假定不会发现错误。原则9：程序某部分存在更多错误的可能性，与该部分已发现错误的数目成正比。原则10软件测试是一项极富创造性、极具智力挑战性的工作。3.1代码检查一个代码检查小组通常由四人组成，其中一人发挥着协调作用。协调人应该是个称职的程序员，但不是该程序的编码人员，不需要对程序的细节了解得很清楚。协调人的职责包括以下几点：1.为代码检查分发材料、安排进程。2.在代码检查中起主导作用。3.记录发现的所有错误。4.确保所有错误随后得到改正。3.2用于代码检查的错误列表3.2.1数据引用错误3.2.2数据声明错误3.2.3运算错误3.2.4比较错误3.2.5控制流程错误3.2.6接口错误3.2.7输入/输出错误3.2.8其他检查3.3代码走查代码走查也是采用持续一至两个小时的小间断会议的形式。代码走查小组由三至五人组成，其中一个人扮演类似代码检查过程中“协调人”的角色，一个人担任秘书（负责记录所有查出的错误）的角色，还有一个人担任测试人员。关于这二到五个人的组成结构，有各种各样的建议。当然，程序员应该是其中之一。我们建议另外的参与者应该包括：(1)一位极富经验的程序员；(2)一位程序设计语言专家；(3)一位程序员新手（可以给出新颖，不带偏见的观点），(4)最终将维护程序的人员；(5)一位来自其他不同项目的人员；(6)一位来自该软件编程小组的程序员。4.1黑盒测试等价类划分边界值分析判定表分析错误测试4.2白盒测试语句覆盖判定覆盖条件覆盖判定/条件覆盖多重条件覆盖等价类划分：等价类的定义：等价类是指某个输入域的子集合，在该子集合中，各个输入数据对于揭露软件中的错误都是等效的。等价类的划分：有效等价类、无效等价类等价类如何划分？1.如果确定了取值范围，可以划分1个有效，2个无效2.如果规定了必须如何的情况下，可以划分为1个有效，1个无效3.如果是布尔量，可以划分为1个有效，1个无效。特殊情况下，可以划分为2个有效4.如果确定了取值范围假定N个并且程序要对每一个输入值分别处理的情况下，可以确定n个有效等价类和1个无效等价5.在规定了输入数据必须遵守的规定的情况下，可以确定一个有效等价类符合规则和若干个无效等价类（从不同的角度违反规则）6.划分等价类可以先粗分，再细分等价类覆盖法设计测试用例的步骤：1.进行等价类划分（等价类划分是所有测试用例设计方法的基础）2.进行用例覆盖2.1设计一个测试用例让其尽可能多的覆盖有效等价类，循环直到所有的有效等价类全部达到覆盖2.2设计一个测试用例让其仅覆盖一个无效等价类，循环直到所有的无效等价类全部达到覆盖3.确定测试数据，完成测试用例边界值的定义：有效等价类边界点以及超出有效等价类边界的点边值点的定义：上点：边界上的点，如果域的边界是封闭的，上点就在域范围内；如果域的边界是开放的，上点就在域范围外离点：就是离上点最近的点，如果域的边界是封闭的，离点在域的范围外,如果域的边界点是开放的,离点就在域的范围内内点：就是在范围内的任意一点判定表的定义：判定表是分析和表达多种输入条件下系统执行不同动作的工具判定表的四个组成部分：条件装：列出了系统的所有输入，列出的输入次序无光紧要（输入项）动作装：列出了系统可能采取的操作，这些操作的排列顺序没有约束（输出项）条件项：列出针对它左列输入的取值，在所有可能情况下的真假值（输入项的取值组合）动作项：列出在输入项的各种取值情况下应该采取的动作（每组条件的预期输出）判定表设计用例的步骤：1.确定条件桩（输入项）和动作桩（输出项）2.构建判定表（条件项1的取值*条件项2的取值*条件项3的取值）3.填写动作项4.对判定表进行合并/化简合并的原则：动作桩完全相同，条件项只有一个不相同，可以考虑合并合并有风险，因为减少了用例，破坏了原有的规则。所以一般来说条件项小于8个，不建议合并。5.去除无效的组合错误猜测：在软件测试中,人们可以靠经验和直觉推测系统中可能存在的各种错误,从而有针对性地编写检查这些错误的例子步骤：1.确定合适的错误猜测2.确定需要进行错误猜测的测试子项3.根据checkList检查对应测试子项的规格进行错误猜测软件测试的原则：原则l：测试用例中一个必需部分是对预期输出或结果的定义。原则2：程序员应当避免测试自己编写的程序．原则3：编写软件的组织不应当测试自己编写的软件．原则4：应当彻底检查每个测试的执行结果。原则5：测试用例的编写不仅应当根据有效和预期的输入情况，而且也应当根据无效和未预料到的输入情况。原则6：检查程序是否“未做其应该做的”仅是测试的一半，测试的另一半是检查程序是否“做了其不应该做的”。原则7：应避免测试用例用后即弃,除非软件本身就是一个一次性的软件原则8：计划测试工作时不应默许假定不会发现错误。原则9：程序某部分存在更多错误的可能性，与该部分已发现错误的数目成正比。原则10软件测试是一项极富创造性、极具智力挑战性的工作。6.1功能测试6.2系统测试6.3验收测试6.4安装测试6.5测试的计划与控制6.6测试的结束准则6.7独立的测试机构功能测试功能测试是一个试图发现程序与其外部规格说明之间存在不一致的过程。外部规格说明是一份从最终用户的角度对程序行为的精确描述。系统测试系统测试最容易被错误理解，也是最困难的测试过程。系统测试并非是测试整个系统或程序功能的过程，因为有了功能测试，这样会显得多余。系统测试有着特定的目的：将系统或程序与其初始目标进行比较。给定这个目标之后，隐含两方面的含义：1.系统测试并不局限于系统。如果产品是一个程序，那么系统测试就是一个试图说明程序作为一个整体是如何不满足其目标的过程。2.根据定义，如果产品没有一组书面的、可度量的目标，系统测试也就无法进行。系统测试能力测试容量测试强度测试易用性测试安全性测试性能测试存储测试配置测试兼容性/配置/转换测试安装测试可靠性测试可恢复性测试适用性测试文档测试过程测试系统测试的执行验收测试验收测试是将程序与其最初的需求及最终用户当前的需要进行比较的过程。这是一种不寻常的测试类型，因为该测试通常是由程序的客户或最终用户来进行，一般不认为是软件开发构的职责。对于软件按合同开发的情况，由订购方（用户）来进行验收测试，将程序的实际操作与原始合同进行对照。安装测试安装测试有些不寻常，它与所有其他测试过程不同。与设计过程中的任何阶段都没有联系。它的不寻常是由于其目的不是为了发现软件中的错误，而是为了发现在安装过程中出现的错误。测试的计划与控制与大多数项目的情况一样，计划是管理测试过程中至关重要的一环。一个良好的测试计划应包括：•1.目标。必须定义每个测试阶段的目标。•2.结束准则。必须制定准则以规定每个测试阶段何时可以结束•3.进度。每个阶段都须有时间表.应指出何时设计、写和执行测试用例.•4.责任。对于每一个阶段，应当确定谁来设计、编写和验证测试用例，谁来修改发现的软件错误。由于在大型项目中讨论特定的测试结果是否代表错误时，有可能出现争端，因此还需要确定一名仲裁者。•5.测试用例库及标准。在大型项目中，用于确定、编写以及存储测试用例的系统方法是必须的。•6.工具。必须确定需要使用的测试工具，包括计划由谁来开发或采购、如何使用工具以及何时需要使用工具。测试的计划与控制•7.计算机时间。计划每个测试阶段所需的计算机时间，包括用来编译应用程序的服务器（如果需要的话）、用来进行安装测试所需的桌面计算机、用来运行基于web应用程序的web服务器、联网的设备（如果需要的话）等等。•8.硬件配置。如果需要特别的硬件配置或设备，则需要一份计划来描述该需求，该如何满足需求以及何时需要满足。•9.集成。测试计划的一部分是定义程序如何组装在一起的方法（例如自顶向下的增量测试）。一个系统如果包含大的子系统或程序，可按增量的方式组装在一起，例如可以使用自顶向下或自底向上的方法，但是这些构造块是程序或子系统，而不是模块。如果是这种情况，就需要一个系统集成计划。系统集成计划规定了系统集成的顺序、系统每个版本的功能以及编写“脚手架”代码以模拟不存在的部件的职责分工。•10.跟踪步骤。必须跟踪测试进行中的方方面面，包括对错误易发模块的定位，以及有关进度、资源和结束准则的进展估计。•11.调试步骤。必须制定上报已发现错误、跟踪错误修改进程以及将修改部分加入系统中去的机制。调试计划中还应包括进度、责任分工、工具以及计算机时间/资源等。•12.回归测试。回归测试在对程序作了功能改进或进行了修改之后进行，其目的是判断程序的改动是否引起了程序其他方面的退步。测试的结束准则有三类较为有用的结束准则第一类，但不是最佳的准则，根据的是特定的测试用例设计技术第二类，也许也是最有价值的准则，是以确切的数量来描述结束测试的条件•1.预测出程序中错误的总数量。•2.预测这些错误中有多大比例可能通过测试而发现。•3.预测这些错误中有多少是由各个设计阶段产生的，以及在什么样的测试阶段能够发现这些问题。第三类结束准则表面上似乎很容易，其中却涉及许多判断和直觉。它需要我们在测试过程中记录每单位时间内发现的错误数量。通过检查统计曲线的形状，常常可以决定究竟是继续该阶段的测试，还是结束它并开始下一测试阶段。