理论思想篇2

第6回 软件测试的十大原则

 

原则是最重要的，方法应该在这个原则指导下进行。软件测试的基本原则是站在用户的角度，对产品进行全面测试，

尽早、尽可能多地发现Bug, 并负责跟踪和分析产品中的问题，对不足之处提出质疑和改进意见。

零缺陷(Zero-Bug) 是一种理念，足够好（Good-Enough）是测试的基本原则。

在软件测试过程中，应注意和遵循的具体原则，可以概括为十大项：

1. 所有测试的标准都是建立在用户需求之上。正如我们所知，软件测试的目标就是验证产品的一致性和确认产品是否满足客户的需求，所以测试人员要始终站在用户的角度去看问题、去判断软件缺陷的影响，系统中最严重的错误是那些导致程序无法满足用户需求的缺陷。
2. 软件测试必须基于“质量第一”的思想去开展各项工作，当时间和质量冲突时，时间要服从质量。质量的理念和文化（如零缺陷的“第一次就把事情做对”）同样是软件测试工作的基础。
3. 事先定义好产品的质量标准。有了质量标准，才能依据测试的结果对产品的质量进行正确的分析和评估，例如，进行性能测试前，应定义好产品性能的相关的各种指标。同样，测试用例应确定预期输出结果，如果无法确定测试结果，则无法进行校验。
4. 软件项目一启动，软件测试也就是开始，而不是等程序写完，才开始进行测试。在代码完成之前，测试人员要参与需求分析、系统或程序设计的审查工作，而且要准备测试计划、测试用例、测试脚本和测试环境，测试计划可以在需求模型一完成就开始，详细的测试用例定义可以在设计模型被确定后开始。应当把“尽早和不断地测试”作为测试人员的座右铭。
5. 穷举测试是不可能的。甚至一个大小适度的程序，其路径排列的数量也非常大，因此，在测试中不可能运行路径的每一种组合，然而，充分覆盖程序逻辑，并确保程序设计中使用的所有条件是有可能的。
6. 第三方进行测试会更客观，更有效。程序员应避免测试自己的程序，为达到最佳的效果，应由第三方来进行测试。测试是带有 ”挑剔性” 的行为，心理状态是测试自己程序的障碍。同时对于需求规格说明的理解产生的错误也很难在程序员本人测试时被发现。
7. 软件测试计划是做好软件测试工作的前提。所以在进行实际测试之前，应制定良好的、切实可行的测试计划并严格执行，特别要确定测试策略和测试目标。
8. 测试用例是设计出来的，不是写出来的，所以要根据测试的目的，采用相应的方法去设计测试用例，从而提高测试的效率，更多地发现错误，提高程序的可靠性。除了检查程序是否做了应该做的事，还要看程序是否做了不该做的事；不仅应选用合理的输入数据，对于非法的输入也要设计测试用例进行测试。
9. 不可将测试用例置之度外，排除随意性。特别是对于做了修改之后的程序进行重新测试时，如不严格执行测试用例，将有可能忽略由修改错误而引起的大量的新错误。所以，回归测试的关联性也应引起充分的注意，有相当一部分最终发现的错误是在早期测试结果中遗漏的。
10. 对发现错误较多的程序段，应进行更深入的测试。一般来说，一段程序中已发现的错误数越多，其中存在的错误概率也就越大。错误集中发生的现象，可能和程序员的编程水平和习惯有很大的关系。

 

第7回 软件测试方法的应用之道

测试工作的质量，首先取决于先进的质量理念和文化，坚持质量第一的原则，其次，就是取决于对各种测试方法有着辩证统一的理解和正确地、有效地的运用。在这一回，将探讨软件测试方法的应用之道。在次之前，实际上，我们对测试方法的应用之道，已做了较多的讨论，详见：

测试方法的辩证统一（之一）

测试方法的辩证统一（之二）

测试方法的辩证统一（之三）

测试方法的辩证统一（之四）

这里对测试方法的应用进行全面系统的总结，使大家更好地理解和掌握测试方法应用之道。

 

组合	静态测试	动态测试	自动化测试
白盒 测试	①静态白盒测试方法： 走查、复审、评审程序源代码、数据字典、系统设计文档、环境设置、软件配置项等。	②动态白盒测试方法： 通过驱动程序、桩程序来调用、驱动程序的运行，如进行单元测试、集成测试和部分性能、可靠性、恢复性测试等	白盒测试工具： Logiscope, C++ Test, Jtest, DevPartner、Purify, TrueCoverage等
黑盒 测试	③静态黑盒测试方法： 文档测试，特别是产品需求文档、用户手册、帮助文件等的审查。	④动态黑盒测试方法： 通过数据输入并运行程序来检验输出结果，如功能测试、验收测试和一些性能、兼容性、兼容性、安全性测试等。	黑盒测试工具： Rational公司的Robot GUI, Compuware的QACenter和MI的WinRunner等等。
自动化 测试	静态测试工具： Logiscope, CheckMate, QA C++, QStudio Java, TrueJ和语言编译器等。	动态测试工具： DevPartner, Purify, Robot GUI, QACenter, WinRunner, Load Runner, WebKing
手工 测试	走查、评审、会审。	单元、集成测试，功能、安装、性能、可靠性测试等。	测试用例和测试脚本依然是自动化测试中的关键内容之一，但这是来自于手工，并依赖手工测试来验证自动化测试结果。
回归 测试	复审、变更审查。	所有测试领域	最好的结合区域：自动化回归测试
注：①②③④构成了测试的四种基本方法，基本覆盖了测试领域。

 

 

第8回 测试的三维空间

软件测试是一个过程，是哲学思想在软件工程中的运用，更是质量目标的扩展和延伸。软件测试构成了具有丰富内容的三维空间。

  1. 测试目标— 质量特性的验证

1.  正确性测试 (Correctness testing) 或功能性测试：是基于产品功能规格说明书、从用户角度针对产品特定的功能和特性所进行的验证活动，以确认每个功能是否得到完整的实现，用户能否正常使用这些功能。功能测试一般要在完成集成测试后进行，而且是针对应用系统、在实际运行环境下而进行的测试。
2. 性能测试（Performance testing）：是测试在一定条件下系统行为表现，是否在设计的性能指标范围内。如测试网站在并发用户数为10、100、1000、10000等情况下，页面的响应时间是否在3秒或5秒内，响应时间最长是否不超过15秒或30秒。性能测试不同于负载测试（Stress/load testing），性能测试是在定义的各种条件下去衡量系统的有关性能指标，而负载测试只测试在一些极端条件下，系统还能否正常工作，或加载到系统崩溃而找出系统性能的瓶颈，所以也可以和性能测试结合起来做。
3.  可靠性测试（Reliability testing）：是评估软件在运行时的可靠性，即通过测试确认平均无故障时间（MTTF, Mean Time To Failure）或最初平均寿命，即故障发生前平均工作时间（MTTFF, Mean-Time -TO-First-Failure）。可靠性测试强调随机输入，并通过模拟系统实现，很难通过实际系统的运行来实现。可靠性测试，一般伴随着强壮性测试（Robustness/strong testing）。
4.  安全性测试（Safety or Security testing）：是测试系统在应付非授权的内部/外部访问、非法侵入或故意的损坏时的系统防护能力，以检验系统有能力使可能存在来自于内/外部的伤害或损害的风险限制在可接受的水平内。软件可靠性要求，通常包括了安全性的要求。但是软件的可靠性不能完全取代软件的安全性，因为安全性还涉及到数据加密、保密、存取权限等方面的要求。
5. 容错性测试（Tolerance testing）：是检查软件在异常条件下自身是否具有防护性的措施或者某种灾难性恢复的手段。如当系统出错时，能否在指定时间间隔内修正错误并重新启动。容错性测试看作由系统异常处理测试和恢复测试组成。
6.  恢复测试 (Recovery testing)，在系统崩溃、硬件故障、或者其他灾难发生之后，重新恢复系统和数据的能力测试，包括确定软件系统的平均修复时间（MTTR，Mean Time to Repair）。
7.  兼容性测试 (Compatibility testing)，测试在各种的硬件/软件/操作系统/网络环境下的软件表现，包括硬件接口、软件新旧版本兼容、已存在数据的兼容能力。

2. 测试方法 — 哲学的思考

测试的方法技术，经过多年的发展，已经相当成熟，方法比较多。如白盒测试方法 (White-box test) 、灰盒测试方法(Gray-box test)和黑盒测试方法(Black-box test)，就是一种哲学思想在软件测试中的体现和延伸。从哲学观点看，分析问题和解决问题的方法有两种：白盒子方法和黑盒子方法。如果我们对被测的对象/世界（软件）认知很少，可以不用了解其内部结构，完全只关注其外部的变化，如外部的输入、外部作用或被测的对象所处的条件以及被测的对象输出的结果，就可以完成测试，这就是黑盒测试方法。随着对被测的对象的认知越来越多，就可以采用灰盒测试方法；当我们完全认知被测的对象时，就可以用白盒测试方法。也见：  测试方法的辩证统一 （1）和  第7回 软件测试方法的应用之道。

3. 测试阶段 － 生命周期的显现

          随着软件开发的生命周期所包含的活动——进程的不断推进，测试与之对应，也划分了不同的测试阶段，包括单元测试、集成测试、系统测试和验收测试等，我们将在后面陆续讨论。

 

第9回 验证和确认——缺一不可

在软件测试中不仅要检查程序是否出错、程序是否和软件产品的设计规格说明书一致，而且还要检验所实现的正确功能是否就是客户或用户所需要的功能，两者缺一不可，这两部分活动构成了一个完整的测试活动。这就是软件测试中有名的V&V，即Verification和Validation。实际上，在整个软件开发生命周期，Verification和Validation每时每刻都存在着。

1. 验证——Verification
     Verification，翻译为“验证”，也可以译为“检验”，即验证或检验软件是否已正确地实现了产品规格书所定义的系统功能和特性。验证过程提供证据表明，软件相关产品与所有生命周期活动（需求分析、设计、编程、测试等）的要求（如正确性、完整性、一致性、准确性等）相一致。
    验证是否满足生命周期过程中的标准、实践和约定；验证为判断每一个生命周期活动是否已经完成，以及是否可以启动其他生命周期活动建立一个新的基准。
    在 ISO9000 中，“验证”的严格定义是：验证是通过检查和提供客观证据，表明规定要求已经满足的认可。“验证”强调的是“规定规格要求”

2. 有效性确认——Validation
    Validation，翻译为“确认”，但更准确地翻译，应该是“有效性确认”，这种有效性确认要求更高，要能保证所生产的软件可追溯到用户需求的一系列活动。确认过程提供证据，表明软件是否满足客户需求（指分配给软件的系统需求），并解决了相应问题。
    在 ISO9000 中，“确认”的严格定义是： 确认：是通过检查和提供客观证据，表明一些针对某一特定预期用途的要求已经满足的认可。“确认”强调的是“预期用途的要求”

3. 两者的区别和联系
       为了更好地理解这两个测试活动的区别，可以概括地说，验证（Verification）是检验开发出来的软件产品和设计规格书的一致性，即是否满足软件厂商的生产要求。但设计规格书本身就可能有问题、存在错误，所以即使软件产品中某个功能实现的结果和设计规格书完全一致，但所设计的功能不是用户所需要的，依然是软件严重的缺陷。因为设计规格书很有可能一开始就对用户的某个需求理解错了，所以仅仅进行验证（Verification）测试还是不充分的，所以还需要进行性确认（Validation）测试。确认（Validation）就是检验产品功能的有效性，即是否满足用户的真正需求。
       这就是BOEHM对V＆V的最著名又最简单的解释是

• Verification：Are we building the product right？是否正确地构造了软件？即是否正确地做事，验证开发过程是否遵守已定义好的内容
• Validation： Are we building the right product? 是否构造了正确的软件？即是否正在做用户真正所需要的事。

我们还可以给出在目的、对象、参与人员和时机等各个方面的区别和联系。

目的：

• 验证的目的是证实设计阶段输出是否确保设计阶段输入要求；
• 确认的目的是通过产品确认设计是否满足使用要求。

对象：

• 验证的对象是设计输出文件，计算书或样品等；
• 确认的对象是最终产品（样品）。

参与人员：

• 验证的参与人员通常是设计部门；
• 确认的参与人员必须包括使用者或能代表使用要求的人员。

时机：

• 验证的时机是设计适当阶段，一般是设计阶段输出形成结果时；
• 确认的时机是成功的设计验证后，一般针对最终产品，也可分阶段确认。