2023年6月21日发(作者：)

⽤例设计（⼀）：如何测试⼀个应⽤的登录场景如何测试⼀个应⽤的登录场景可能你会说，“⽤户登录”这个测试对象也有点⼉太简单了吧？我只要找个⽤户，让他在界⾯上输⼊⽤户名和密码，然后点击“确认”按钮，验证以下是否登录成功就可以了。的确，这构成了⼀个最基本、最典型的测试⽤例，这也是终端⽤户在使⽤系统时最典型的Happy Path场景。但是作为测试⼯程师，你的⽬标是要保证系统在各种应⽤场景下的功能是符合设计要求的，所以你需要考虑的测试⽤例就需要更多、更全⾯，于是你可能会根据“⽤户登录”功能的需求描述，结合等价类划分和边界值分析⽅法来设计⼀系列的测试⽤例。那什么是等价类划分和边界值分析⽅法呢？⾸先，这⼆者都⾪属于最常⽤、最典型、也是最重要的⿊盒测试⽅法。等价类划分⽅法，是将所有可能的输⼊数据划分成若⼲个⼦集，在每个⼦集中，如果任意⼀个输⼊数据对于揭露程序中潜在错误都具有同等效果，那么这样的⼦集就构成了⼀个等价类。后续只要从每个等价类中任意选取⼀个值进⾏测试，就可以⽤少量具有代表性的测试输⼊取得较好的测试覆盖结果。边界值分析⽅法，是选取输⼊、输出的边界值进⾏测试。因为通常⼤量的软件错误是发⽣在输⼊或输出范围的边界上，所以需要对边界值进⾏重点测试，通常选取正好等于、刚刚⼤于或刚刚⼩于边界的值作为测试数据。功能测试⽤例从⽅法论上可以看出来，边界值分析是对等价类划分的补充，所以这两种测试⽅法经常结合起来使⽤。现在，针对“⽤户登录”功能，基于等价类划分和边界值分析⽅法，我们设计的测试⽤例包括：1.输⼊已注册的⽤户名和正确的密码，验证是否登录成功；2.输⼊已注册的⽤户名和不正确的密码，验证是否登录失败，并且提⽰信息正确；3.输⼊未注册的⽤户名和任意密码，验证是否登录失败，并且提⽰信息正确；4.⽤户名和密码两者都为空，验证是否登录失败，并且提⽰信息正确；5.⽤户名和密码两者之⼀为空，验证是否登录失败，并且提⽰信息正确；6.如果登录功能启⽤了验证码功能，在⽤户名和密码正确的前提下，输⼊正确的验证码，验证是否登录成功；7.如果登录功能启⽤了验证码功能，在⽤户名和密码正确的前提下，输⼊错误的验证码，验证是否登录失败，并且提⽰信息正确。列出这些测试⽤例后，你可能已经觉得⽐较满意了，因为你感觉已经把⾃⼰的测试知识都⽤在这些⽤例设计中了。的确，上⾯的测试⽤例集已经涵盖了主要的功能测试场景，但是在⼀个优秀的测试⼯程师眼⾥，这些⽤例只能达到勉强及格的标准。什么?才刚刚及格？如果你有这个想法，那我建议你在继续看下⾯的内容前，先仔细思考⼀下，这些测试⽤例是否真的还需要补充。现在，我跟你分享⼀下有经验的测试⼯程师会再增加的测试⽤例：1.⽤户名和密码是否⼤⼩写敏感；2.页⾯上的密码框是否加密显⽰；3.后台系统创建的⽤户第⼀次登录成功时，是否提⽰修改密码；4.忘记⽤户名和忘记密码的功能是否可⽤；5.前端页⾯是否根据设计要求限制⽤户名和密码长度；6.如果登录功能需要验证码，点击验证码图⽚是否可以更换验证码，更换后的验证码是否可⽤；7.刷新页⾯是否会刷新验证码；8.如果验证码具有时效性，需要分别验证时效内和时效外验证码的有效性；9.⽤户登录成功但是会话超时后，继续操作是否会重定向到⽤户登录界⾯；10.不同级别的⽤户，⽐如管理员⽤户和普通⽤户，登录系统后的权限是否正确；11.页⾯默认焦点是否定位在⽤户名的输⼊框中；12.快捷键 Tab 和 Enter 等，是否可以正常使⽤。看完这些⽤例，你可能会说：“哇塞，原来⼀个简简单单的登录功能居然有这么多需要测试的点”。但是，你别⾼兴得太早，“⽤户登录功能的测试还没结束。虽然改进后的测试⽤例集相⽐之前的测试覆盖率的确已经提⾼了很多，但是站在资深测试⼈员的⾓度来看，还有很多⽤例需要设计。经我这么⼀说，你可能已经发现，上⾯所有的测试⽤例设计都是围绕显式功能性需求的验证展开的，换句话说，这些⽤例都是直接针对“⽤户登录”功能的功能性进⾏验证和测试的。但是，⼀个质量过硬的软件系统，除了显式功能性需求以外，其他的⾮功能性需求即隐式功能性需求也是极其关键的。显式功能性需求（Functional requirement）的含义从字⾯上就可以很好地理解，指的是软件本⾝需要实现的具体功能， ⽐如“正常⽤户使⽤正确的⽤户名和密码可以成功登录”、“⾮注册⽤户⽆法登录”等，这都是属于典型的显式功能性需求描述。.那什么是⾮功能性需求（Non-functional requirement）呢？从软件测试的维度来看，⾮功能性需求主要涉及安全性、性能以及兼容性三⼤⽅⾯。 在上⾯所有的测试⽤例设计中，我们完全没有考虑对⾮功能性需求的测试，但这些往往是决定软件质量的关键因素。明⽩了⾮功能性需求测试的重要性后，你可以先思考⼀下还需要设计哪些测试⽤例，然后再来看看我会给出哪些⽤例，相信这种⽅式对你的帮助会更⼤。安全性测试⽤例包括：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.不同移动设备终端的不同浏览器下，验证登录页⾯的显⽰以及功能正确性；5.不同分辨率的界⾯下，验证登录页⾯的显⽰以及功能正确性。说到这⾥，你还会觉得“⽤户登录”功能的测试⾮常简单、不值⼀提么？⼀个看似简单的功能测试，居然涵盖了如此多的测试⽤例，除了要覆盖明确的功能性需求，还需要考虑其他诸多的⾮功能性需求。另外，通过这些测试⽤例的设计，你也可以发现，⼀个优秀的测试⼯程师必须具有很宽⼴的知识⾯，如果你不能对被测系统的设计有深⼊的理解、不明⽩安全攻击的基本原理、没有掌握性能测试的基本设计⽅法，很难设计出“有的放⽮”的测试⽤例。看完了这些测试⽤例，你可能会说还有⼀些遗漏的测试点没有覆盖到，这个功能的测试点还不够全⾯。那么，接下来我再跟你说说测试的不可穷尽性，即绝⼤多数情况下，是不可能进⾏穷尽测试的。所谓的“穷尽测试”是指包含了软件输⼊值和前提条件所有可能组合的测试⽅法，完成穷尽测试的系统⾥应该不残留任何未知的软件缺陷。 因为如果有未知的软件缺陷，你可以通过做更多的测试来找到它们，也就是说你的测试还没有穷尽。但是，在绝⼤多数的软件⼯程实践中，测试由于受限于时间成本和经济成本，是不可能去穷尽所有可能的组合的，⽽是采⽤基于风险驱动的模式，有所侧重地选择测试范围和设计测试⽤例，以寻求缺陷风险和研发成本之间的平衡。总结⾸先，对于⾼质量的软件测试，⽤例设计不仅需要考虑明确的的显式功能性需求，还要涉及兼容性、安全性和性能等⼀系列的⾮功能性需求对软件系统的质量有着举⾜轻重的作⽤。其次，优秀的测试⼯程师必须具有宽⼴的知识⾯，才能设计出有针对性、更易于发现问题的测试⽤例。最后，软件测试的⽤例设计是不可穷尽的，⼯程实践中难免受制于时间成本和经济成本，所以优秀的测试⼯程师需要兼顾缺陷风险和研发成本之间的平衡。

2023年6月21日发(作者：)

⽤例设计（⼀）：如何测试⼀个应⽤的登录场景如何测试⼀个应⽤的登录场景可能你会说，“⽤户登录”这个测试对象也有点⼉太简单了吧？我只要找个⽤户，让他在界⾯上输⼊⽤户名和密码，然后点击“确认”按钮，验证以下是否登录成功就可以了。的确，这构成了⼀个最基本、最典型的测试⽤例，这也是终端⽤户在使⽤系统时最典型的Happy Path场景。但是作为测试⼯程师，你的⽬标是要保证系统在各种应⽤场景下的功能是符合设计要求的，所以你需要考虑的测试⽤例就需要更多、更全⾯，于是你可能会根据“⽤户登录”功能的需求描述，结合等价类划分和边界值分析⽅法来设计⼀系列的测试⽤例。那什么是等价类划分和边界值分析⽅法呢？⾸先，这⼆者都⾪属于最常⽤、最典型、也是最重要的⿊盒测试⽅法。等价类划分⽅法，是将所有可能的输⼊数据划分成若⼲个⼦集，在每个⼦集中，如果任意⼀个输⼊数据对于揭露程序中潜在错误都具有同等效果，那么这样的⼦集就构成了⼀个等价类。后续只要从每个等价类中任意选取⼀个值进⾏测试，就可以⽤少量具有代表性的测试输⼊取得较好的测试覆盖结果。边界值分析⽅法，是选取输⼊、输出的边界值进⾏测试。因为通常⼤量的软件错误是发⽣在输⼊或输出范围的边界上，所以需要对边界值进⾏重点测试，通常选取正好等于、刚刚⼤于或刚刚⼩于边界的值作为测试数据。功能测试⽤例从⽅法论上可以看出来，边界值分析是对等价类划分的补充，所以这两种测试⽅法经常结合起来使⽤。现在，针对“⽤户登录”功能，基于等价类划分和边界值分析⽅法，我们设计的测试⽤例包括：1.输⼊已注册的⽤户名和正确的密码，验证是否登录成功；2.输⼊已注册的⽤户名和不正确的密码，验证是否登录失败，并且提⽰信息正确；3.输⼊未注册的⽤户名和任意密码，验证是否登录失败，并且提⽰信息正确；4.⽤户名和密码两者都为空，验证是否登录失败，并且提⽰信息正确；5.⽤户名和密码两者之⼀为空，验证是否登录失败，并且提⽰信息正确；6.如果登录功能启⽤了验证码功能，在⽤户名和密码正确的前提下，输⼊正确的验证码，验证是否登录成功；7.如果登录功能启⽤了验证码功能，在⽤户名和密码正确的前提下，输⼊错误的验证码，验证是否登录失败，并且提⽰信息正确。列出这些测试⽤例后，你可能已经觉得⽐较满意了，因为你感觉已经把⾃⼰的测试知识都⽤在这些⽤例设计中了。的确，上⾯的测试⽤例集已经涵盖了主要的功能测试场景，但是在⼀个优秀的测试⼯程师眼⾥，这些⽤例只能达到勉强及格的标准。什么?才刚刚及格？如果你有这个想法，那我建议你在继续看下⾯的内容前，先仔细思考⼀下，这些测试⽤例是否真的还需要补充。现在，我跟你分享⼀下有经验的测试⼯程师会再增加的测试⽤例：1.⽤户名和密码是否⼤⼩写敏感；2.页⾯上的密码框是否加密显⽰；3.后台系统创建的⽤户第⼀次登录成功时，是否提⽰修改密码；4.忘记⽤户名和忘记密码的功能是否可⽤；5.前端页⾯是否根据设计要求限制⽤户名和密码长度；6.如果登录功能需要验证码，点击验证码图⽚是否可以更换验证码，更换后的验证码是否可⽤；7.刷新页⾯是否会刷新验证码；8.如果验证码具有时效性，需要分别验证时效内和时效外验证码的有效性；9.⽤户登录成功但是会话超时后，继续操作是否会重定向到⽤户登录界⾯；10.不同级别的⽤户，⽐如管理员⽤户和普通⽤户，登录系统后的权限是否正确；11.页⾯默认焦点是否定位在⽤户名的输⼊框中；12.快捷键 Tab 和 Enter 等，是否可以正常使⽤。看完这些⽤例，你可能会说：“哇塞，原来⼀个简简单单的登录功能居然有这么多需要测试的点”。但是，你别⾼兴得太早，“⽤户登录功能的测试还没结束。虽然改进后的测试⽤例集相⽐之前的测试覆盖率的确已经提⾼了很多，但是站在资深测试⼈员的⾓度来看，还有很多⽤例需要设计。经我这么⼀说，你可能已经发现，上⾯所有的测试⽤例设计都是围绕显式功能性需求的验证展开的，换句话说，这些⽤例都是直接针对“⽤户登录”功能的功能性进⾏验证和测试的。但是，⼀个质量过硬的软件系统，除了显式功能性需求以外，其他的⾮功能性需求即隐式功能性需求也是极其关键的。显式功能性需求（Functional requirement）的含义从字⾯上就可以很好地理解，指的是软件本⾝需要实现的具体功能， ⽐如“正常⽤户使⽤正确的⽤户名和密码可以成功登录”、“⾮注册⽤户⽆法登录”等，这都是属于典型的显式功能性需求描述。.那什么是⾮功能性需求（Non-functional requirement）呢？从软件测试的维度来看，⾮功能性需求主要涉及安全性、性能以及兼容性三⼤⽅⾯。 在上⾯所有的测试⽤例设计中，我们完全没有考虑对⾮功能性需求的测试，但这些往往是决定软件质量的关键因素。明⽩了⾮功能性需求测试的重要性后，你可以先思考⼀下还需要设计哪些测试⽤例，然后再来看看我会给出哪些⽤例，相信这种⽅式对你的帮助会更⼤。安全性测试⽤例包括：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.不同移动设备终端的不同浏览器下，验证登录页⾯的显⽰以及功能正确性；5.不同分辨率的界⾯下，验证登录页⾯的显⽰以及功能正确性。说到这⾥，你还会觉得“⽤户登录”功能的测试⾮常简单、不值⼀提么？⼀个看似简单的功能测试，居然涵盖了如此多的测试⽤例，除了要覆盖明确的功能性需求，还需要考虑其他诸多的⾮功能性需求。另外，通过这些测试⽤例的设计，你也可以发现，⼀个优秀的测试⼯程师必须具有很宽⼴的知识⾯，如果你不能对被测系统的设计有深⼊的理解、不明⽩安全攻击的基本原理、没有掌握性能测试的基本设计⽅法，很难设计出“有的放⽮”的测试⽤例。看完了这些测试⽤例，你可能会说还有⼀些遗漏的测试点没有覆盖到，这个功能的测试点还不够全⾯。那么，接下来我再跟你说说测试的不可穷尽性，即绝⼤多数情况下，是不可能进⾏穷尽测试的。所谓的“穷尽测试”是指包含了软件输⼊值和前提条件所有可能组合的测试⽅法，完成穷尽测试的系统⾥应该不残留任何未知的软件缺陷。 因为如果有未知的软件缺陷，你可以通过做更多的测试来找到它们，也就是说你的测试还没有穷尽。但是，在绝⼤多数的软件⼯程实践中，测试由于受限于时间成本和经济成本，是不可能去穷尽所有可能的组合的，⽽是采⽤基于风险驱动的模式，有所侧重地选择测试范围和设计测试⽤例，以寻求缺陷风险和研发成本之间的平衡。总结⾸先，对于⾼质量的软件测试，⽤例设计不仅需要考虑明确的的显式功能性需求，还要涉及兼容性、安全性和性能等⼀系列的⾮功能性需求对软件系统的质量有着举⾜轻重的作⽤。其次，优秀的测试⼯程师必须具有宽⼴的知识⾯，才能设计出有针对性、更易于发现问题的测试⽤例。最后，软件测试的⽤例设计是不可穷尽的，⼯程实践中难免受制于时间成本和经济成本，所以优秀的测试⼯程师需要兼顾缺陷风险和研发成本之间的平衡。