软件测试52讲
开篇词 | 从“⼩⼯”到“专家”，我的软件测试修炼之道
随着⾃动化测试⽤例设计与开发、测试框架选型、测试框架⾃⾏研发、测试基础架构设计以及最新的测试服务化（Test as a Service，TaaS）等⼀系列技术的变⾰与发展，测试项⽬⼏乎涵盖了所有种类，包括嵌⼊式系统测试、⾦融平台单元测试、平台 SDK 测试、轨道交通安全软件测试、Web Service 测试、⼤型电商⽹站 GUI ⾃动化以及性能全链路压测等。
第⼀步，成为互联⽹时代合格的测试⼯程师。
你必须具有快速学习的能⼒，能迅速掌握被测软件的业务功能与内部架构，并在此基础上运⽤各种测试⽅法，尽可能多地发现潜在缺陷，并能够在已知缺陷的基础上进⼀步发现相关的连带缺陷。
从知识体系上看，你需要有⽐开发⼈员更全⾯的计算机基础知识，还需要了解互联⽹的基础架构、安全攻击、软件性能、⽤户体验和常见缺陷等知识。
从测试技术上看，你需要能够使⽤常见的测试框架或者⼯具，需要具有⼀定的⾃动化测试脚本的开发能⼒，这可以把你从⼤量重复的⼯作中解放出来，然后你才能有时间去做更有意思的⼯作。
第⼆步，成为互联⽹时代优秀的测试⼯程师。
⾸先，合格的测试⼯程师关注的是纯粹的测试，⽽优秀的测试⼯程师关注更多的是软件整体的质量，需要根据业务风险以及影响来制定测试策略，有效控制测试的时间和成本，并且能够对测试框架以及⼯具做出适合项⽬需求的选型。
第三步，成为互联⽹时代的测试架构师。
⾯对⼤量测试⽤例的执⾏，⽆论是 GUI 还是 API，都需要⼀套⾼效的能够⽀持⾼并发的测试执⾏基础架构；再⽐如，⾯对测试过程中的⼤量差异性数据要求，需要统⼀的测试数据准备平台；再⽐如，为了可以更⽅便地和持续集成与发布系统（CI/CD）以解耦的形式做集成，需要统⼀发起测试执⾏的接⼝。
这样的例⼦还有很多，如果你已经能够站在这样的⾼度看待软件测试，那么恭喜你，你已经具备了测试架构师的视野。当然，你还必须对⼀些前沿的测试⽅法和技术有⾃⼰的理解，并能够在恰当的时候、因地制宜地把它们应⽤到实际项⽬中。
01 | 你真的懂测试吗？从“⽤户登录”测试谈起
功能测试⽤例：
基本
1. 输⼊已注册的⽤户名和正确的密码，验证是否登录成功；
2. 输⼊已注册的⽤户名和不正确的密码，验证是否登录失败，并且提⽰信息正确；
3. 输⼊未注册的⽤户名和任意密码，验证是否登录失败，并且提⽰信息正确；
4. ⽤户名和密码两者都为空，验证是否登录失败，并且提⽰信息正确；
5. ⽤户名和密码两者之⼀为空，验证是否登录失败，并且提⽰信息正确；
6. 如果登录功能启⽤了验证码功能，在⽤户名和密码正确的前提下，输⼊正确的验证码，验证是否登录成功；
7. 如果登录功能启⽤了验证码功能，在⽤户名和密码正确的前提下，输⼊错误的验证码，验证是否登录失败，并且提⽰信息正确。
⾼级
1. ⽤户名和密码是否⼤⼩写敏感；
2. 页⾯上的密码框是否加密显⽰；
3. 后台系统创建的⽤户第⼀次登录成功时，是否提⽰修改密码；
4. 忘记⽤户名和忘记密码的功能是否可⽤；
5. 前端页⾯是否根据设计要求限制⽤户名和密码长度；
6. 如果登录功能需要验证码，点击验证码图⽚是否可以更换验证码，更换后的验证码是否可⽤；
7. 刷新页⾯是否会刷新验证码；
8. 如果验证码具有时效性，需要分别验证时效内和时效外验证码的有效性；
9. ⽤户登录成功但是会话超时后，继续操作是否会重定向到⽤户登录界⾯；
10. 不同级别的⽤户，⽐如管理员⽤户和普通⽤户，登录系统后的权限是否正确；
11. 页⾯默认焦点是否定位在⽤户名的输⼊框中；
12. 快捷键 Tab 和 Enter 等，是否可以正常使⽤。
⼀个质量过硬的软件系统，除了显式功能性需求以外，其他的⾮功能性需求即隐式功能性需求也是极其关键的。安全性测试⽤例：
1. ⽤户密码后台存储是否加密；
2. ⽤户密码在⽹络传输过程中是否加密；
3. 密码是否具有有效期，密码有效期到期后，是否提⽰需要修改密码；
4. 不登录的情况下，在浏览器中直接输⼊登录后的 URL 地址，验证是否会重新定向到⽤户登录界⾯；
5. 密码输⼊框是否不⽀持复制和粘贴；
6. 密码输⼊框内输⼊的密码是否都可以在页⾯源码模式下被查看；
7. ⽤户名和密码的输⼊框中分别输⼊典型的“SQL 注⼊攻击”字符串，验证系统的返回页⾯；
8. ⽤户名和密码的输⼊框中分别输⼊典型的“XSS 跨站脚本攻击”字符串，验证系统⾏为是否被篡改；
9. 连续多次登录失败情况下，系统是否会阻⽌后续的尝试以应对暴⼒破解；
10. 同⼀⽤户在同⼀终端的多种浏览器上登录，验证登录功能的互斥性是否符合设计预期；
11. 同⼀⽤户先后在多台终端的浏览器上登录，验证登录是否具有互斥性。
性能压⼒测试⽤例:
1. 单⽤户登录的响应时间是否⼩于 3 秒；
2. 单⽤户登录时，后台请求数量是否过多；
3. ⾼并发场景下⽤户登录的响应时间是否⼩于 5 秒；
4. ⾼并发场景下服务端的监控指标是否符合预期；
5. ⾼集合点并发场景下，是否存在资源死锁和不合理的资源等待；
6. 长时间⼤量⽤户连续登录和登出，服务器端是否存在内存泄漏。
兼容性测试⽤例：
1. 不同浏览器下，验证登录页⾯的显⽰以及功能正确性；
2. 相同浏览器的不同版本下，验证登录页⾯的显⽰以及功能正确性；
3. 不同移动设备终端的不同浏览器下，验证登录页⾯的显⽰以及功能正确性；
4. 不同分辨率的界⾯下，验证登录页⾯的显⽰以及功能正确性。
⼀个优秀的测试⼯程师必须具有很宽⼴的知识⾯，如果你不能对被测系统的设计有深⼊的理解、不明⽩安全攻击的基本原理、没有掌握性能测试的基本设计⽅法，很难设计出“有的放⽮”的测试⽤例。
在绝⼤多数的软件⼯程实践中，测试由于受限于时间成本和经济成本，是不可能去穷尽所有可能的组合的，⽽是采⽤基于风险驱动的模式，有所侧重地选择测试范围和设计测试⽤例，以寻求缺陷风险和研发成本之间的平衡。
总结
⾸先，对于⾼质量的软件测试，⽤例设计不仅需要考虑明确的显式功能性需求，还要涉及兼容性、安全性和性能等⼀系列的⾮功能性需求，这些⾮功能性需求对软件系统的质量有着举⾜轻重的作⽤。
其次，优秀的测试⼯程师必须具有宽⼴的知识⾯，才能设计出有针对性、更易于发现问题的测试⽤例。
最后，软件测试的⽤例设计是不可穷尽的，⼯程实践中难免受制于时间成本和经济成本，所以优秀的测试⼯程师需要兼顾缺陷风险和研发成本之间的平衡。
02 | 如何设计⼀个“好的”测试⽤例？
“好的”测试⽤例⼀定是⼀个完备的集合，它能够覆盖所有等价类以及各种边界值，⽽跟能否发现缺陷⽆关。
“好的”测试⽤例必须具备哪些特征？
⼀个“好的”测试⽤例，必须具备以下三个特征。
1. 整体完备性： “好的”测试⽤例⼀定是⼀个完备的整体，是有效测试⽤例组成的集合，能够完全覆盖测试需求。
2. 等价类划分的准确性： 指的是对于每个等价类都能保证只要其中⼀个输⼊测试通过，其他输⼊也⼀定测试通过。
3. 等价类集合的完备性： 需要保证所有可能的边界值和边界条件都已经正确识别。
做到了以上三点，就可以肯定测试是充分且完备的，即做到了完整的测试需求覆盖。
对⼤多数的软件测试⽽⾔，综合使⽤等价类划分、边界值分析和错误推测这三⼤类⽅法就⾜够了。
具体到测试⽤例本⾝的设计，有两个关键点需要你注意。
1. 从软件功能需求出发，全⾯地、⽆遗漏地识别出测试需求是⾄关重要的，这将直接关系到⽤例的测试覆盖率。 ⽐如，如果你没有识别出⽤户登
录功能的安全性测试需求，那么后续设计的测试⽤例就完全不会涉及安全性，最终造成重要测试漏洞。
2. 对于识别出的每个测试需求点，需要综合运⽤等价类划分、边界值分析和错误推测⽅法来全⾯地设计测试⽤例。 这⾥需要注意的是，要综合运
⽤这三种⽅法，并针对每个测试需求点的具体情况，进⾏灵活选择。
以“⽤户登录”的功能性测试需求为例，你⾸先应该对“⽤户名”和“密码”这两个输⼊项分别进⾏等价类划分，列出对应的有效等价类和⽆效等价类，对于⽆效等价类的识别可以采⽤错误猜测法（⽐如，⽤户名包含特殊字符等），然后基于两者可能的组合，设计出第⼀批测试⽤例。
等价类划分完后，你需要补充“⽤户名”和“密码”这两个输⼊项的边界值的测试⽤例，⽐如⽤户名为空（NULL）、⽤户名长度刚刚⼤于允许长度等。
⽤例设计的其他经验
除了上⾯介绍的⽅法外，我再跟你分享三个独家“秘籍”，希望能够帮你设计出“好的”测试⽤例集。
1. 只有深⼊理解被测试软件的架构，你才能设计出“有的放⽮”的测试⽤例集，去发现系统边界以及系统集成上的潜在缺陷。
作为测试⼯程师，切忌不能把整个被测系统看作⼀个⼤⿊盒，你必须对内部的架构有清楚的认识，⽐如数据库连接⽅式、数据库的读写分离、
消息中间件 Kafka 的配置、缓存系统的层级分布、第三⽅系统的集成等等。
2. 必须深⼊理解被测软件的设计与实现细节，深⼊理解软件内部的处理逻辑。
单单根据测试需求点设计的⽤例，只能覆盖“表⾯”的⼀层，往往会覆盖不到内部的处理流程、分⽀处理，⽽没有覆盖到的部分就很可能出现缺陷遗漏。在具体实践中，你可以通过代码覆盖率指标出可能的测试遗漏点。
同时，切忌不要以开发代码的实现为依据设计测试⽤例。因为开发代码实现的错误会导致测试⽤例也出错，所以你应该根据原始需求设计测试⽤例。
3. 需要引⼊需求覆盖率和代码覆盖率来衡量测试执⾏的完备性，并以此为依据来出遗漏的测试点。 关于什么是需求覆盖率和代码覆盖率，我会
在后续的⽂章中详细介绍。
总结
最后，我来简单总结⼀下今天的主要内容。
⾸先，你需要明⽩，“好的”测试⽤例⼀定是⼀个完备的集合，它能够覆盖所有等价类以及各种边界值，⽽能否发现软件缺陷并不是衡量测试⽤例好坏的标准。
其次，设计测试⽤例的⽅法有很多种，但综合运⽤等价类划分、边界值分析和错误推测⽅法，可以满⾜绝⼤多数软件测试⽤例设计的需求。
再次，“好的”测试⽤例在设计时，需要从软件功能需求出发，全⾯地、⽆遗漏地识别出测试需求⾄关重要。
最后，如果想设计⼀个“好的”测试⽤例，你必须要深⼊理解被测软件的架构设计，深⼊软件内部的处理逻辑，需求覆盖率和代码覆盖率这两个指标可以帮你衡量测试执⾏的完备性。
03 | 什么是单元测试？如何做好单元测试？
1. 代码要做到功能逻辑正确，必须做到分类正确并且完备⽆遗漏，同时每个分类的处理逻辑必须正确；
2. 单元测试是对软件中的最⼩可测试单元在与软件其他部分相隔离的情况下进⾏的代码级测试；
3. 桩代码起到了隔离和补齐的作⽤，使被测代码能够独⽴编译、链接，并运⾏。
04 | 为什么要做⾃动化测试？什么样的项⽬适合做⾃动化测试？
⾃动化测试是，把⼈⼯对软件的测试转化为由机器执⾏测试⾏为的⼀种实践，可以把测试⼯程师从机械重复的测试⼯作中解脱出来，将更多的精⼒放在新功能的测试和更全⾯的测试⽤例设计上。
然⽽⾃动化测试试⼀把“双刃剑”，虽然它可以从⼀定程度上解放测试⼯程师的劳动⼒，完成⼀些⼈⼯⽆法实现的测试，但并不适⽤于所有的测试场景，如果维护⾃动化测试的代价⾼过了节省的测试成本，那么在这样的项⽬中推进⾃动化测试就会得不偿失。
06 | 你真的懂测试覆盖率吗？
这章以后要多看⼏遍，了解的还是有很⼤的⽋缺 。
测试覆盖率通常被⽤来衡量测试的充分性和完整性，从⼴义的⾓度来讲，测试覆盖率主要分为两⼤类，⼀类是⾯向项⽬的需求覆盖率，另⼀类是更偏向技术的代码覆盖率。
需求覆盖率
需求覆盖率是指测试对需求的覆盖程度，通常的做法是将每⼀条分解后的软件需求和对应的测试建⽴⼀对多的映射关系，最终⽬标是保证测试可以覆盖每个需求，以保证软件产品的质量。
代码覆盖率
简单来说，代码覆盖率是指，⾄少被执⾏了⼀次的条⽬数占整个条⽬数的百分⽐。
测试覆盖率通常被⽤来衡量测试的充分性和完整性，包括⾯向项⽬的需求覆盖率和更偏向技术的代码覆盖率。⽽需求覆盖率的统计⽅式不再适⽤于现在的敏捷开发模式，所以现在谈到测试覆盖率，⼤多是指代码覆盖率。
但是，⾼的代码覆盖率不⼀定能保证软件的质量，因为代码覆盖率是基于现有代码，⽆法发现那些“未考虑某些输⼊”以及“未处理某些情况”形成的缺陷。
另外，对于代码覆盖率的统计⼯具，我希望你不仅仅是会⽤的层次，⽽是能够理解它们的原理，知其然知其所以然，才能更好地利⽤这些⼯具完成你的测试⼯作。
07 | 如何⾼效填写软件缺陷报告？
具体看⽂章⽐较好，讲的很详细。
缺陷报告是测试⼯程师与开发⼯程师交流沟通的重要桥梁，也是测试⼯程师⽇常⼯作的重要输出。
⼀份⾼效的软件缺陷报告，应该包括缺陷标题、缺陷概述、缺陷影响、环境配置、前置条件、缺陷重现步骤、期望结果和实际结果、优先级和严重程度、变通⽅案、根原因分析，以及附件这⼏⼤部分。
缺陷报告的每⼀部分内容，都会因为⽬的、表现形式有各⾃的侧重点，所以想要写出⼀份⾼效的软件缺陷报告，需要对其组成有深⼊的理解。08 | 以终为始，如何才能做好测试计划？
需要的时候看原⽂，写的很详细。
软件测试同软件项⽬⼀样，也要制定详细的测试计划。虽然在敏捷开发模式下，软件测试不再局限于厚重的、正式的计划⽂档，但是测试计划的重要性丝毫没有发⽣变化。
⼀份成功的测试计划，必须清楚地描述：测试范围、测试策略、测试资源、测试进度和测试风险预估这五个最重要的⽅⾯。
重定向过多是什么意思测试范围需要明确“测什么”和“不测什么”；测试策略需要明确“先测什么后测什么”和“如何来测”；测试资源需要明确“谁来测”和“在哪⾥测”；测试进度是需要明确各类测试的开始时间，所需⼯作量和预计完成时间；测试风险预估是需要明确如何有效应对各种潜在的变化。
09 | 软件测试⼯程师的核⼼竞争⼒是什么？
我把测试⼯程师按照⼯作内容，分为了功能测试⼯程师（即传统测试⼯程师）和测试开发⼯程师两类，分别给你分享了他们的核⼼竞争⼒。
对于功能测试⼯程师来说，其核⼼竞争⼒包括：测试策略设计能⼒、测试⽤例设计能⼒、快速学习能⼒、探索性测试思维、缺陷分析能⼒、⾃动化测试技术和良好的沟通能⼒这七⼤部分，你可以有针对性地提升⾃⼰某⽅⾯的能⼒，去获取更⼤发展空间的“敲门砖”。
⽽对于测试开发⼯程师来说，你需要具备优秀的测试系统需求分析能⼒和完备的知识体系，这样才能保证你设计的测试⼯作和平台，可以更好地满⾜提升测试效率的要求。
11 | 互联⽹产品的测试策略应该如何设计？
传统软件通常采⽤⾦字塔模型的测试策略，⽽现今的互联⽹产品往往采⽤菱形模型。菱形模型有以下四个关键点：
以中间层的 API 测试为重点做全⾯的测试。
轻量级的 GUI 测试，只覆盖最核⼼直接影响主营业务流程的 E2E 场景。
最上层的 GUI 测试通常利⽤探索式测试思维，以⼈⼯测试的⽅式发现尽可能多的潜在问题。
单元测试采⽤“分⽽治之”的思想，只对那些相对稳定并且核⼼的服务和模块开展全⾯的单元测试，⽽应⽤层或者上层业务只会做少量的单元

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。