测试的基本原则

1．SDLC 才是王道：软件开发生命周期（SDLC）对于软件开发而言，是如同基石般的关键流程，每一位开发人员都应该对其了如指掌。从最初的需求定义，到最终软件上线后的维护，SDLC 的各个阶段环环相扣，共同构建起软件的完整生命周期。将测试理念融入到 SDLC 的每一个环节，就像是给建筑的每一层都做好了质量检测，是确保软件质量坚如磐石的重要举措。不同的组织由于自身的业务特点、技术水平和管理模式的差异，采用的 SDLC 模型也不尽相同，这就导致各阶段的名称和具体工作内容会有所变化。但无论如何，像定义阶段精准确定软件需求，设计阶段精心规划软件架构，开发阶段将设计转化为代码，部署阶段让软件在实际环境中运行，以及维护阶段保障软件持续稳定运行，这些核心概念阶段都是开发应用程序必不可少的环节。在每个阶段，都要充分考虑测试工作，把测试计划的制定、测试用例的设计以及测试执行等内容，都纳入到现行的开发流程中。这样一来，才能保障测试计划全面覆盖软件的各个方面，确保测试的有效性。目前，软件行业中存在着各种各样的 SDLC 框架，比如瀑布模型、敏捷开发模型、迭代模型等等。这些框架提供了描述性和规范性两类建议。描述性建议侧重于阐述软件开发过程中通常会发生的情况，帮助开发团队了解实际的开发流程；规范性建议则更像是一份详细的操作指南，明确规定了每个阶段应该完成的任务和达到的标准。选择哪种建议，取决于组织 SDLC 过程的成熟度。如果一个组织已经在软件开发领域积累了丰富的经验，其 SDLC 流程已经相对成熟，那么可以依据规范性建议进一步优化流程，提高开发效率和软件质量；而如果组织仍处于发展阶段，对软件开发的流程还在不断探索和完善，描述性建议则能提供更灵活的指导，让组织根据自身情况进行调整和改进。

2．尽早开始、频繁测试：测试工作就像是一场赛跑，越早出发就越容易掌握主动权。在软件开发的早期阶段，比如需求分析和设计阶段，就应该启动测试工作，而不是等到开发完成后才匆匆忙忙开始测试。在需求分析阶段，测试人员可以对需求文档进行评审，检查需求是否清晰、完整、一致，有没有潜在的矛盾和漏洞。通过早期的介入，能够及时发现并解决潜在问题，避免问题在后续的开发过程中不断积累和放大。从成本和风险的角度来看，早期测试的优势更是显而易见。如果在软件开发生命周期的初期，也就是代码量还较少、系统架构还相对简单的时候就检测到漏洞，修复工作就如同在一张白纸上修改错误，相对简单，所需成本也较低。但随着开发进程的推进，代码量不断增加，系统架构变得越来越复杂，漏洞修复的难度和成本就会呈指数级增长。例如，在开发后期发现一个由于设计缺陷导致的问题，可能需要对整个模块甚至整个系统的架构进行调整，这不仅需要投入大量的人力、物力和时间，还可能会引入新的问题。因此，持续、频繁的测试就像是给软件的开发过程上了一道道保险，能够确保软件在整个开发过程中始终保持较高的质量水平，减少后期出现大规模问题的风险。

3．选用合适的工具：在软件测试的浩瀚海洋中，虽然不存在一把能够打开所有宝箱的万能钥匙，也就是不存在万能的测试工具，但工具在整体测试计划中所起的作用就如同航海中的指南针和地图，至关重要。当下，软件测试领域发展迅速，有大量丰富多样的开源工具和商业工具可供选择。这些工具就像是一个个得力的助手，能够自动完成许多常规的测试任务，比如功能测试中的界面元素检查、性能测试中的压力模拟等等，帮助测试人员简化繁琐的测试流程，提高测试效率。然而，就像每把钥匙都有其特定的锁孔一样，每种工具都有其独特的功能和局限性。关键在于深入了解这些工具的功能和适用场景，只有选择与测试需求相匹配的工具，才能达到事半功倍的效果。例如，对于自动化功能测试，Selenium 凭借其强大的跨浏览器支持和灵活的脚本编写能力，成为了众多测试人员的首选工具。它可以模拟用户在浏览器中的各种操作，如点击按钮、输入文本、切换页面等，实现对 Web 应用程序功能的自动化测试。而对于性能测试，JMeter 则是一款备受青睐的工具。它能够模拟大量用户并发访问，对服务器的性能指标进行监测和分析，帮助测试人员评估系统在高负载情况下的性能表现。在选择工具前，测试团队需要充分评估项目的特点，比如项目是 Web 应用、移动应用还是桌面应用；测试目标是什么，是功能测试、性能测试还是安全测试；以及团队的技术水平如何，是否有足够的能力掌握和运用所选工具。只有综合考虑这些因素，才能确保所选工具能够满足实际需求，为测试工作提供有力的支持。

图片

4．80/20 原则：在软件测试的世界里，存在着一个神奇的二八定律，也就是大约 80% 的缺陷是由 20% 的原因所引发的。这就好比一座冰山，露在水面上的部分只是一小部分，而隐藏在水下的大部分才是真正的关键所在。这意味着少数特定的原因或模块是导致大多数缺陷的根源。对于测试团队来说，这一原则就像是一盏明灯，为他们指明了工作重点。通过分析过往项目的测试数据，就像侦探寻找线索一样，找出那些容易出现问题的模块和原因。比如，在一个电商系统中，经过数据分析发现，购物车模块和支付模块虽然只占整个系统功能的一小部分，但却产生了大部分的缺陷。那么，在后续的测试工作中，就可以有针对性地对这两个模块进行更加深入、全面的测试和优化。通过对这些关键模块和原因的重点关注，能够有效降低软件的缺陷率，提高软件的质量，同时也能大大提高测试效率，避免在一些不太可能出现问题的地方浪费过多的时间和精力。

5．穷尽测试不可行，基于风险测试很必要：在软件测试的道路上，我们常常会面临一个残酷的现实，那就是由于时间、资源和技术的限制，对软件进行穷尽测试，也就是测试所有可能的输入、输出和场景，是几乎不可能实现的。想象一下，一个稍微复杂一点的软件系统，其可能的输入组合和操作场景就数以百万计，要对每一种情况都进行测试，即使投入再多的人力和时间，也是不现实的。因此，基于风险的测试方法就应运而生，它就像是一个明智的资源分配者，帮助我们在有限的条件下实现最大的价值。这种方法要求测试团队对软件系统中的各个模块和功能进行风险评估，就像医生给病人做全面检查，找出潜在的高风险区域。在进行风险评估时，需要综合考虑多个因素。功能的重要性是一个关键因素，比如对于一个在线银行系统，账户管理和交易功能就是至关重要的，一旦出现问题，可能会给用户带来巨大的损失，所以这些功能的风险等级就比较高。使用频率也不容忽视，经常被用户使用的功能模块，出现问题的概率相对较高，也需要重点关注。复杂度也是评估风险的重要指标，复杂的算法、逻辑和数据结构更容易出现漏洞。此外，还要考虑可能造成的影响，如果一个问题的出现会导致系统崩溃、数据丢失或者用户隐私泄露等严重后果，那么这个问题的风险就非常高。识别出高风险区域后，测试团队就可以优先对这些区域进行测试，通过合理分配测试资源，确保高风险的问题能够被及时发现和解决，从而在有限的资源下实现最大的测试价值。

6．注重细节：在软件测试中，进行表面的应用测试并认为测试任务已完成，就像是只看到了冰山的一角，而忽略了水下隐藏的巨大风险，是一种极其危险的做法。这种做法会产生一种软件质量良好的假象，就像给一个有缺陷的产品贴上了完美的标签，其危害程度与不进行测试无异。仔细审查测试结果，并剔除测试报告中可能存在的错误至关重要，这就好比医生在诊断病情时，要仔细检查每一项检查结果，确保诊断的准确性。测试结果的不准确会破坏报告其余部分的有效信息，就像一颗老鼠屎坏了一锅粥，误导后续的决策。在测试过程中，要确保所有可能的应用逻辑部分都经过了全面测试，对每种使用情况都进行了漏洞检测，不放过任何一个细节。比如，在测试一个文件上传功能时，不仅要测试正常大小、常见格式的文件上传是否成功，还要测试超大文件、特殊格式文件以及文件名为特殊字符等各种边界情况和异常情况，只有这样，才能发现潜在的问题，保证软件的质量。

图片

7．合理运用自动化与手动测试：自动化测试工具就像是不知疲倦的机器人助手，能够有效提高测试效率，尤其适用于重复性高、规律性强的测试任务。比如在每天的回归测试中，自动化测试工具可以快速地执行大量的测试用例，检查软件的基本功能是否正常，大大节省了时间和人力成本。然而，并非所有的测试场景都适合自动化测试，就像不是所有的工作都适合机器人来完成一样。对于一些复杂的、难以自动化的测试场景，手动测试仍然不可或缺。手动测试就像是经验丰富的工匠，能够凭借其敏锐的洞察力和丰富的经验，发现那些自动化测试难以捕捉到的细微问题。例如，对于一些涉及用户体验和业务逻辑的复杂场景，手动测试能够更好地模拟真实用户的操作，感受用户在使用软件过程中的痛点和问题。在测试一个电商 APP 的下单流程时，手动测试人员可以从用户的角度出发，考虑用户在不同网络环境、不同操作习惯下的使用情况，发现一些自动化测试无法发现的问题，如界面交互不友好、操作流程繁琐等。因此，在测试计划中，要合理安排自动化测试和手动测试的比例，充分发挥两者的优势，让它们相互配合，共同为软件质量保驾护航。

8．测试的本身也要被测试：就如同用尺子测量桌子长度，如果尺子本身不准确，那么测量结果必然有误。测试工作同样如此，测试方法、测试工具以及测试用例的准确性和有效性都需要进行验证。测试方法是否科学合理，直接影响到测试结果的可靠性；测试工具是否正常运行，是否能够准确地检测出问题；测试用例是否覆盖了所有关键的功能和场景，是否存在漏洞。只有确保测试的过程和结果可靠，才能为软件质量提供有力的保障。可以通过同行评审、交叉测试等方式对测试工作进行检验。同行评审就像是一场学术研讨会，让不同的测试人员对测试方法、测试用例等进行讨论和评估，发现其中存在的问题和不足之处。交叉测试则是让不同的测试团队或测试人员对同一软件进行测试，通过对比测试结果，发现可能存在的问题。通过这些方式，能够及时发现并纠正测试工作中存在的问题，确保测试的质量。

9．建立正确的思考模式：要成功地测试应用程序并找出安全漏洞，需要具备 “跳出条条框框” 的思维方式。常规的用例测试主要关注用户按预期方式使用时应用程序的正常行为，就像是在一条平坦的道路上行驶，只关注正常的交通规则。而优秀的测试需要具备 “攻其不备” 的思维，像试图攻破应用程序的攻击者一样思考，就像是在黑暗中寻找隐藏的陷阱。通过模拟各种异常情况和恶意操作，能够发现那些隐藏在正常用例测试中难以察觉的安全漏洞。例如，尝试进行 SQL 注入攻击，通过在输入框中输入特殊的 SQL 语句，测试应用程序是否存在 SQL 注入漏洞；进行跨站脚本攻击测试，在网页中插入恶意脚本，看应用程序是否能够有效防范。除了这些常见的攻击方式，还可以从用户权限绕过、文件上传漏洞利用等多个角度进行测试，全面评估应用程序的安全性。只有具备了这种独特的思考模式，才能在测试工作中发现更多潜在的问题，为软件的安全运行提供保障。

作者简介：风随水

一个从事十五年测试和质量管理者

曾经深圳乃至全国最大最活跃软件测试QQ群群主

致力于质量管理和体系规范

​