用例设计与敏捷测试

　　写在前面
　　在 Google Testing Blog 的一篇文章中有这么一段话： it’s COOL (Constant learner, Out-of-the-box thinker, Orchestrator, Leading-edge user) to be a Test Engineer at Google
　　Friday, May 08, 2020 原文链接
　　人肉翻译下就是：
　　在谷歌，做测试工程师是一件很酷（不断进取者、打破常规者、协调者、前沿追逐者）的事。Orchestrator 应该是管弦乐演奏家的意思，从岗位性质上来看说协调者更合适，因为测试一直在协调着开发和产品质量的之间的关系。对，测试工程师（TE）是最可爱的人。在某种程度上，TE 可以说是质量的守护者。
　　既然是守护者，那就有被动和主动技能。被动技能就是科学严谨的用例设计规范和方法，主动技能就是敏捷测试（为快不破）。
　　先来自我介绍下，本人在某厂带领十几人的测试团队负责一个云产品的测试。测试执行包括产品功能和性能，安全涉及较少。测试开发覆盖黑盒、白盒、静态白盒和单元测试，以及自动化测试持续集成，还有测试团队管理（包括测试计划制定、执行、跟进，bug 管理等）。
　　市面上讲测试的书很多，本场 chat 希望可以给大家不一样的角度来快速了解软件测试，提供一些经验和一条捷径来掌握它，不必被晦涩枯燥的理论吓跑。接下来跟大家一起聊聊用例设计和敏捷测试。
　　首先来回答 Chat 描述中提到的问题。
　　1. 项目时间紧来不及测试？怎么办？ 最大可能评估风险，先给上级沟通打好预防针（做好兜底方案）。 如果你是开发，一定要尽可能跑下静态白盒测试（后面会详细介绍），也可以借助静态检查工具如 pylint、pyflakes。 通过 Python 的 faker 库来轻松构造测试数据，GitHub 地址。 外包出去（一般都是黑盒测试，如果是白盒要注意数据安全）。 用一些用例设计方法和自动化测试技术尽可能做好测试覆盖。
　　2. 产品经理催着上线心里没底？如何是好？ 用好手里的资源（人肉、代码库和自动化脚本等） 不会 mock 的开发不是好的测试（用好 mock 你就是会测试的开发） 其他方法同问题 1
　　3. 代码总是各种 bug？何时是个头？ 先弄清楚你的 bug 是来自不断变更的需求还是你自身 人生苦短，你需要掌握白盒测试 如果代码 push 上去代码评审总是被主管批，你需要 git commit hook。 加强语言语法学习和逻辑思维训练
　　4. 不知道如何写测试用例？ 笨方法就是用高中所学排列组合知识把各种输入条件（数据类型，取值范围，先后顺序）穷举出来 你需要好好学习下用例设计方法
　　5. TDD 测试驱动开发真的有效吗？ 视项目人力资源和周期来决定 单元测试能写就写，用白盒有空就写（不要嫌自己的 bug 多）
　　6.测试真的可以做到自动化吗？ 可以。绝大部分测试都可以做到自动化。 当然也要考虑项目需求和成本。成本包括人力和时间，有团队花了一年时间做移动端自动化，为了兼容不同手机型号做了大量的适配工作。然后回过头来发现人肉测试反而效率更高。有时候自动化还是无法代替人力。selenium 也好，appinum 也罢。
　　如果有疑问，会放在后面答疑环节一一为大家解惑。 用例设计
　　用例的设计是一场思维锤炼的盛宴。 什么是测试用例
　　先来回想下以下场景： 在学校每学完一章要做单元测试以检测学习成果 通过 ph 试纸检验溶液的酸碱度 刷算法题来验证算法掌握程度 GPU 测试需要不同的深度学习框架、算法 web 应用需要测试不同浏览器的兼容性
　　九年义务教育，到高中，再到大学，为了应试我们一直都在践行题海战术。但市场经济下生产环境中我们不可能题海战术进行穷举测试， 为了节省时间和资源、提高测试效率，必须要从数量极大的可用测试数据中精心挑选出具有代表性或特殊性的测试数据来进行测试。
　　为了将测试行为具体量化达到最佳的测试效果（或高效的揭露隐藏的错误），而精心设计的少量测试数据，称之为测试用例。
　　在操作系统中，系统进行资源分配和调度的基本单位叫进程。而在软件测试中，测试执行的基本单元就是用例。对于开发，好的架构稳如泰山；对于测试，好的用例决胜千里。 DAMP not DRYDRY: Don＂t repeat yourself.
　　DAMP: Descriptive And Meaningful Phrases.
　　当我们在写单元测试的时候，需要在 DRY 和 DAMP 原则之间做一个选择或者说平衡，那么 DAMP 应该更合适。DAMP 重视代码重用的可读性。在测试用例中 DAMP not DRY 的想法是测试应该易于理解，即使这意味着测试用例有时会重复代码。 def setUp(self):   self.users = [User(＂alice＂), User(＂bob＂)]  # This field can be reused across tests.   self.forum = Forum()  def testCanRegisterMultipleUsers(self):   self._RegisterAllUsers()   for user in self.users:  # Use a for-loop to verify that all users are registered.     self.assertTrue(self.forum.HasRegisteredUser(user))  def _RegisterAllUsers(self):  # This method can be reused across tests.   for user in self.users:     self.forum.Register(user)
　　尽管上面的测试代码很简洁，但你的同事可能需要一些时间去了解它，例如，通过_RegisterAllUsers() 来跟踪 self.users 从 setUp() 的流程。由于测试没有调试，人工操作应该很容易，即使以更大的代码重复为代价，也可以手动对其进行正确性检查。这意味着尽管 DRY 原则是生产代码的最佳实践，但它通常不适合单元测试。在测试中，我们可以使用 DAMP 原则，该原则强调了可读性而非唯一性。
　　为了全面了解测试结果，现在必须将所有这些部件重新组合在一起。由于测试代码重复通常风险较小，并且提高了可读性，因此很容易看出它被认为是可接受的。 def setUp(self):   self.forum = Forum()  def testCanRegisterMultipleUsers(self):   # Create the users in the test instead of relying on users created in setUp.   user1 = User(＂alice＂)   user2 = User(＂bob＂)    # Register the users in the test instead of in a helper method, and don＂t use a for-loop.   self.forum.Register(user1)   self.forum.Register(user2)    # Assert each user inpidually instead of using a for-loop.   self.assertTrue(self.forum.HasRegisteredUser(user1))   self.assertTrue(self.forum.HasRegisteredUser(user2))
　　以上代码来自 Google Testing Blog
　　作为一个原则，在生产代码中支持 DRY，在测试代码中支持 DAMP。虽然两者同样重要，但只要评估好，你就可以为自己提供平衡。 用例设计方法
　　软件测试的方法主要基于数据和逻辑，数据有输入和输出，逻辑有语法和表达式，所以有了基于数据驱动和基于逻辑驱动的测试。很多书籍和教程都在讲黑盒和白盒用例设计方法，对于刚接触测试行业的人来讲，其实并不理解该用哪个，更不用说做到灵活运用了。 黑盒测试
　　以数据为驱动的测试用专业术语来说叫黑盒（Black box）测试，又叫工程测试，测试对象是测试数据输入和测试结果输出。测试目标与程序的内部机制和结构完全无关，重点集中放在发现程序运行的条件上。
　　抛开长篇大论简言之，主要的黑盒用例设计方法如下：
　　编号
　　设计方法
　　说明
　　1
　　流程（场景）分析法
　　拆解业务流程，分而治之
　　2
　　等价类划分法
　　压缩用例集，求同存异
　　3
　　边界值分析法
　　取边界极限值，物极必反
　　4
　　因果图法
　　寻找逻辑关系，追根溯源
　　5
　　判定表法
　　逻辑判定，是非分明
　　6
　　状态迁移图法
　　聚焦状态变化，见微知著
　　7
　　输入域分析法
　　分析输入值，面向对象
　　8
　　输出域分析法
　　输出反推输入，逆向思维
　　9
　　异常分析法
　　列举异常，未雨绸缪
　　10
　　错误猜测法
　　推测异常，防患未然
　　11
　　正交实验法
　　基于正交表理论，加权去重
　　能掌握前面 6 种，就算登堂入室了。由于篇幅原因，就先跟大家讲讲前面 6 种黑盒用例设计方法。
　　设计方法 流程分析法
　　日常工作中流程分析有助于我们熟悉业务流程、软件功能，从而能发现用户在使用产品/软件过程中可能存在的问题。
　　流程分析法又叫场景分析法。目的是把一个大的软件系统分析成多个路径，根据路径的不同组合来进行测试，使得软件的各个分支都能得到测试。一个都没真正体验过产品无脑执行用例的测试不是好的产品经理。流程分析法可以说是一种分而治之的策略，或者战略。
　　如网站注册发送验证码的流程：（拆分成获取验证码、输入验证码和验证验证码三步）
　　再比如网络测试需要熟悉 TCP 通信流程：
　　安全测试需要知道 CSRF 攻击流程：
　　流程分析法的重点是需要熟悉产品的业务流程，才能设计出高质量的测试用例。可以把业务流程想象成一条公路，用户相当于上路的新手，你需要替用户验证好路标及路线，勘测好不同的岔路是否有障碍，是否会迷路失去方向，做好这些用户的体验才会更好。
　　有的网站交互流程太复杂导致用户迷失，用户好不容易从一个个链接出来回到首页，一个 500、404，结果导致用户无法忍受，从而流失。
　　产品经理、项目经理包括研发需要跟测试工程师沟通清楚业务流程，测试工程师也需要自己主动去熟悉业务，画出流程图，流程图可以借助工具如 xmind、Visio、processon 来完成。
　　现在的软件几乎都是由事件触发来控制流程的，事件触发时的情景便形成了场景， 而同一事件不同的触发顺序和处理结果形成事件流。这种在软件设计方面的思想也可被引入到软件测试中，生动的描绘出事件触发时的情景，有利于测试设计者设计测试用例，同时测试用例也更容易的得到理解和执行。
　　那么＂流程图＂如何转化为＂业务流程用例＂呢，你还需要执行以下步骤： 定义状态节点和条件分支 确定测试路径
　　那如何定义状态节点和条件分支呢？
　　可以针对被测试特性的每一状态节点分析其输入（条件）、下一状态节点、输出，这个流经过程要从用例开始到结束遍历其中所有基本流、备选流和异常流。
　　流程类型 基本流：是经过用例的最简单的路径。每个步骤操作均正确，完成期望的业务。（举例登录流程：首次输入正确的用户名、密码，登录成功） 备选流：因错误操作或者是异常操作，导致流程反复，最终完成期望的业务。自基本流开始，之后，会在某个特定条件下执行。可能会重新加入基本流中，还可能起源于另一个备选流，或者终止用例而不再重新加入某个流。（举例登录流程：首次输入正确的用户名、错误的密码，登录失败；再次尝试输入正确的用户名、密码，登录成功） 异常流：因错误操作或者是异常操作，导致流程中断，最终未完成期望的业务。同样，会自基本流开始直接终止或者通过某个备选流而终止（举例登录流程：首次输入正确的用户名、错误的密码，登录失败；总共输入 3 次正确的用户名、错误的密码，账号被锁定。）
　　举个 ATM 的例子。
　　很多书和教程都拿 ATM 来举例，没办法，这个＂栗子＂实在太经典了，跟钱有关的肯定印象深刻（还记得上次被 ATM 吞卡是什么时候吗）。
　　基本流 1：
　　场景
　　说明
　　流程 2
　　1
　　成功的提款
　　--
　　2
　　银行卡无效
　　备选流 1
　　3
　　ATM 内没有现金
　　备选流 2
　　4
　　ATM 内现金不足
　　备选流 3
　　5
　　密码有误（还有输入机会）
　　备选流 4
　　6
　　密码有误（不再有输入机会）
　　备选流 4
　　7
　　帐户不存在/帐户类型有误
　　备选流 5
　　8
　　帐户余额不足
　　备选流 6
　　9
　　设备正在维修
　　备选流 8
　　10
　　系统故障
　　异常流 1
　　基本流 2：出了基本流 1 提到的外，还有以下场景。 输入超过最大金额 输入金额超时 反复订正输入金额
　　按照上面流程就可以开始设计用例了：
　　TC
　　场景/条件
　　密码
　　输入金额
　　卡余额
　　ATM 余额
　　预期结果
　　--
　　--
　　--
　　--
　　--
　　--
　　--
　　根据以上表格各位朋友可以想想怎么设计测试数据。
　　各位朋友你们的测试项目中，如果用流程分析来设计用例，基本流、备选流、异常流又是如何呢？ 等价类划分法在软件工程中，是把所有可能输入的数据，即程序的输入域划分成若干部分（子集），然后从每一个子集中选取少数具有代表性的数据作为测试用例，从而减少了数据输入量从而提高了效率，称之为等价类方法。
　　有效等价类：是指对于程序的规格说明来说是合理的、有意义的输入数据构成的集合。利用有效等价类可检验程序是否实现了规格说明所规定的功能和性能。无效等价类：指对程序的规格说明是不合理的或无意义的输入数据所构成的集合。对于具体的问题，无效等价类至少应有一个，也可能多个。
　　——百度百科
　　为避免穷举带来巨大工作量通常用等价类划分法，通过划分输入数据集来减少测试所需的用例，与程序的基本特性＂对数据分类处理＂是相匹配的方法。等价类划分的好，测试相对也就越高效。这也符合 敏捷测试 之道。
　　对于一个函数来说，如果对数据的分类正确且完整，每一个分类处理正确，那么，程序就没有问题。同样，测试时，只要依据设计功能，找出所有等价类，那么，用例就是完整的。所以，用例的完整性，本质上是指等价类是否划分正确且完整，每一类的正确输出是否均依据设计功能正确设定。 还记得＂任意键＂是哪个键的笑话吗。其实＂任意键＂就是一个有效等价类。 在看某视频的时候按音量，反而音量加满（事后知道因为手机出厂音量加减电路接反导致），音量-键能增加音量就是一个无效等价类。
　　能够划分等效类的对象有： 数值范围 字符串长度 文件后缀 文件大小 屏幕分辨率 超时时间 重复次数 系统版本 系统内核 软件版本 可用内存 其他
　　等价类划分可以从三个方面来考虑： 有哪些正常输入（数据类型、取值范围）？ 有哪些边界输入（最小值，最大值，后面要提的边界值法其实就是等价类法的一部分）？ 有哪些非法输入（通常是指＂不合法则的输入＂，而不是＂违反法律的输入＂）？
　　以一个评分系统打分为例（分数范围 0~10 分），等价类划分如下：
　　有效等价类通常还可以细分，比如 0~59 不及格，60~79 一般，80~89 良好， 90~100 优秀。 边界值分析法
　　《吕氏春秋·博志》：＂全则必缺，极则必反。＂
　　事物发展到极端，会向相反方向转化。软件运行也是如此。最常见的莫过于内存泄露了，因为程序滥用内存没有及时回收导致内存泄露、应用崩溃用户数据丢失，已经屡见不鲜了。边界值分析法借鉴了极限的思想，它是近代数学的一种重要思想。
　　在 Python 2.7.x 中，要表示最大整数、最大浮点数： >>> import sys >>> print(sys.maxint) 2147483647 >>> sys.float_info.max 1.7976931348623157e+308
　　如果用边界值分析法，就能发现在新版本的发行版中，sys.maxint 已经被去掉了,且最大值已经变化。标准库提供了 sys.maxsize 来表示一个大于任何我们实际工作中能够表示的最大的整型数值，在新版本中对于整型数值再也没有限制了。 >>> import sys >>> print(sys.maxint) >>> AttributeError: module ＂object＂ has no attribute ＂maxint＂ >>> print(sys.maxsize) 9223372036854775807 >>> print(float(＂inf＂)) inf
　　用边界值分析再看看 Python 列表最多可以放多少数据。 32 位 Python 的限制是 536870912 个元素。 64 位 Python 的限制是 1152921504606846975 个元素。
　　从另一角度去分析如果要存放这么多数据，列表是不是已经不适用了。
　　C 语言中 char 的取值范围是 -128 ~ +127 (1 Byte)，当 char 类型的变量取值超过这个范围时，会发生截断。
　　例：char a=128 00000000 00000000 00000000 10000000
　　发生截断后取低 8 位为 10000000，即表示的是 -128；同样，char b=-130 截断后表示的是 126。
　　再比如超卖事故：
　　秒杀商品是 500 部苹果手机，活动结束以后，居然产生了 1000 个订单！老板很生气，后果很严重，这个锅必须有人得背。是测试没及时发现还是开发没有处理经验？
　　大多数互联网事故都源于测试环节边界值没有覆盖到位，边界值分析法的重要性不言而喻。
　　边界值方法中常说的边界 5 点，即上点、内点和离点。 上点：是指边界上的点，如果域的边界是闭区间的，上点就是在域范围内，如果是开区间的话，上点就是在域范围外。 离点：是指离上点最近的点，如果域的边界是是开区间，那么离点就在范围域内，如果是闭区间，那么离点就在域范围外。 内点：域内的任意一个点都是内点。
　　举例说明边界值中上点、离点、内点的取值。如下： 区间为正整数值域 [66,99]，上点就是 66，99，并且都是在域范围内。内点就是域内得任意点，离点是 65，100。 区间为正整数值域 (66,98]，这种情况上点是 66，99，其中一个是域内，一个是域外，内点就是域内的任意点，离点是：67，99。 区间为正整数值域 (66,98)，这样的情况上点还是 66，99，只是都是在域外，内点还是域内的任意点，离点此时为：67，97。
　　使用方法 分析输入参数的类型：从测试规格中分析得到输入参数类型 等价类划分（可选）：对于输入等价类划分方法进行等价类划分 确定边界：运用域测试分析方法确定域范围的边界（上点、离点与内点） 相关性分析（可选）：针对多个输入域，运用因果图、判定表分析（后面会讲） 形成测试项：选择这些上点、离点与内点或者这些点的组合形成测试项
　　关于边界值分析，推荐一篇知乎的文章，讲的很系统：链接 因果图法
　　道生一，一生二，二生三，三生万物。——《道德经》
　　因果图用于描述系统的输入和输出之间的因果关系、输入和输出之间的约束关系。利用图解法分析输入输出的各种组合情况。用数学的方式来解释，就是描述自变量与变量之间的关系（比如线性相关、非线性相关）。绘制因果图需要对测试系统的外部特征进行建模。根据输入和输出之间的因果图可以得到判定表，从而设计出测试用例。逻辑关系非常明确的系统有时候不需要因果图法，可以只使用判定表法。
　　输入（a,b,c,...z） 和输出 （Y）之间的因果关系因果关系。
　　恒等关系（出现输入项产生对应输出项，没有输入就不会输出）： Y1 if  a else Y2 if b else Y3  .. else ＂＂
　　非关系（输入与输出没有任何关系）： Y not in list([f(x1),f(x2),...,f(xn)]) and x not in list( f_1(Y1),f_1(Y2),...,f_1(Yn)]
　　f _1(Y) 表示反函数。
　　或关系（只要有一个输入项出现才会产生对应输出项）： Yn if  any([a,b,c,...,z]) else ＂＂
　　Yn 表示对应输出项。
　　与关系（只有所有输入项出现才会产生对应输出项）： Yn if all([a,b,c,...,z]) else ＂＂
　　图示：
　　输入和输入之间的约束关系（a,b,c,...n）。
　　异关系 （只有一个输入条件出现）： len(filter(lambda x:x,[a,b,c,...,n])) <= 1
　　或关系（至少一个输入条件出现）： len(filter(lambda x:x,[a,b,c,...,n])) >= 1
　　唯一关系 （有且只有一个输入条件出现）： len(filter(lambda x:x,[a,b,c,...,n])) == 1
　　要求关系（只要有一个输入条件出现，其他输入也会出现）： len(filter(lambda x:x,[a,b,c,...,n])) >= 1 and all([a,b,c,...n]) == true
　　图示：
　　因果图法设计用例的步骤如下： 提取输入和输出，赋予标识符（比如输入 x1，输出 y1）。 分析分解后待测的系统规格，找出哪些是原因，哪些是结果。 画出因果图。 把因果图转换成判定表。 简化判定表（可选，逻辑关系明确则跳过）。 用判定表中的每一项生成测试用例。
　　实例分析
　　产品说明书：有一个处理单价为 3 元饮料的自动售货机软件。仅支持 5 元纸币和 1 元硬币，若投入硬币或纸币，按下＂可乐＂、＂雪碧＂、或＂冰红茶＂按钮，相应的饮料就送出来。若投入的是 5 元纸币，在送出饮料的同时退还硬币。
　　确定需求中的原因与结果：
　　编号
　　原因
　　C1
　　投入 5 元纸币
　　C2
　　投入 3 元硬币
　　C3
　　按入＂冰红茶＂按钮
　　C4
　　按入＂可乐＂按钮
　　C5
　　按入＂雪碧＂按钮
　　编号
　　结果
　　E1
　　退还 2 元硬币
　　E2
　　送出＂冰红茶＂饮料
　　E3
　　送出＂可乐＂饮料
　　E4
　　送出＂雪碧＂饮料
　　确定原因与结果的逻辑关系：
　　C1 与 C2 需要一个中间结果 Cm1, C3、C4、C5 需要一个中间结果 Cm2。
　　确定因果图中的约束：
　　C1 与 C2 是或的关系, C3、C4、C5 是或的关系。
　　画出因果图并转化为判定表：
　　判定表：
　　简化版：
　　根据决策表设计测试用例：
　　判定表法
　　判定表通常被当做编写程序的工具，用于验证逻辑和多条件组合。
　　判定表是分析和表达多种输入条件下系统执行不同动作的工具，它可以把复杂的逻辑关系和多种条件组合的情况表达得既具体又明确。
　　判定表通常由四部分组成，如下： 条件桩：它列出决定一组条件的对象； 条件项：它列出各种可能的条件组合； 动作桩：它列出所有的操作； 动作项：它列出在对应的条件组合下的动作。
　　以一个生产服务器部署脚本为例：需求规定仅支持在 Intel、CentOS 6+ 下运行。
　　说明
　　条件桩
　　CentOS 版本低于 6；CPU 型号非 Intel
　　条件项
　　是；否
　　动作桩
　　正常运行
　　动作项
　　是；否
　　判定表：
　　Y: 是；N: 否
　　针对该判定表，可以化简。规则 1、规则 2 的动作完全相同，条件桩只有条件 2 的取值不同，因此可将规则 1、规则 2 合并。条件桩化简后：
　　以上案例还是比较简单的。功能需求中涉及到复杂逻辑处理的，就越有必要使用判定表。像在分布式部署、控制系统、游戏系统中应用就比较多。 状态迁移图法
　　对对象建模，我们使用流程图、结构图、OOP。对对象行为建模，我们采用有限状态机。人有生老病死。任何产品、软件、业务也是如此。均有它的生命周期。为了描述对象在生命周期所经历的状态序列以及如何响应来自外界的各种事件，引入状态迁移图法来设计用例达到对系统状态的覆盖、状态-条件以及状态迁移路径的覆盖。
　　本人所在的团队负责测试的一个业务需要做在线热迁移。该业务有以下几个状态： 初始状态（running） 中间状态（migrating） 完成状态（success） 回滚状态（callblack） 异常状态（stopped）
　　如果不能准确完善描述业务的生命周期，以及如何转变，转变条件如何，将发生灾难级事故。状态迁移图法为我们避免了大量潜在的客服投诉。
　　状态迁移图法具体的实施步骤如下。
　　1. 绘制状态迁移图。
　　2. 填写状态—时间表。
　　3. 根据状态迁移图推导测试路径：
　　覆盖路径 指的是该测试用例覆盖路径的分支序列，覆盖的状态—条件组合是指该分支序列上的各状态点和条件的组合（可以不填）。
　　为了更好遍历，可以使用状态转换树。先确定根节点，然后从该状态延伸，直到所有的状态转换都包含到该状态转换树中。从根节点到最后的叶子节点之间的路径就是需要测试的路径。
　　4. 选取测试数据，构造测试用例：
　　关于常用的 6 种黑盒用例设计方法就说到这了。其他的方法大家可以自行查阅资料。下面综合来说说如何设计黑盒测试用例。
　　用例设计步骤 根据设计规格、产品需求说明书构造基本的功能测试用例； 流程分析用例（梳理业务流程）； 边界值测试用例； 因果图（或判定表）测试用例； 状态迁移图测试用例； 错误猜测测试用例； 异常分析测试用例； 性能测试用例； 压力测试用例；
　　优化方法 利用设计测试用例的 11 种方法不断的对测试用例进行分解与合并； 在测试时利用发散思维举一反三构造测试用例； 多画流程图梳理业务和测试用例。
　　综合策略 首先根据产品原型、需求说明熟悉业务流程，设计出业务流程用例 在任何情况下都必须使用边界值分析方法，经验表明用这种方法设计出测试用例发现程序错误的能力最强。（比如内存泄露、磁盘写满） 必要时用等价类划分方法补充一些测试用例。 用错误推测法再追加一些测试用例。 对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度，如果没有达到要求的覆盖标准，应当再补充足够的测试用例。 如果程序的功能说明中含有输入条件的组合情况，则一开始就可选用因果图法。 白盒测试
　　Testing your code.
　　以逻辑为驱动的测试用专业术语来说叫白盒（White box）测试，测试对象是程序的内部机制和结构。通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作，跟黑盒测试相反并不关心它的功能，主要用于软件验证。
　　主要的白盒用例设计方法如下：
　　编号
　　设计方法
　　1
　　静态白盒测试
　　2
　　语句覆盖法
　　3
　　判定覆盖法
　　4
　　条件覆盖法
　　5
　　判定条件覆盖法
　　6
　　条件组合覆盖法
　　7
　　路径覆盖法
　　8
　　基本路径覆盖法
　　9
　　循环路径测试
　　由于篇幅原因，这里只详细介绍前面几个常见方法，其他的只做简单概述。 静态白盒测试
　　静态白盒测试是指在不执行软件的条件下条理地仔细审查软件设计、体系结构和代码，从而找出软件缺陷的过程，又称为结构化测试。静态白盒测试能够尽早发现软件缺陷，并且能够为黑盒测试员在接受软件测试时设计和应用测试用例提供思路。
　　可以从以下方面来审查： 数据引用 （边界值错误、访问非法内存） 数据声明 计算（如被零除） 比较 控制流程（如判断逻辑不严密、分支不可达） 子程序参数（冗余参数） 输入/输出（返回码错误） 内存泄漏 冗余参数 日志记录 代码健壮性建议
　　静态代码审查工具
　　1. Python pyflakes：分析程序并且检查各种错误 pyLint：Python 源代码分析器，可以分析 Python 代码中的错误 Bandit：python 安全性分析
　　2. Shell shellcheck：shell 脚本静态分析工具
　　3. C/C++ dmalloc: 用于检查 C/C++ 内存泄露 (leak) 的工具 cqmetrics – C 代码的质量度量工具 cppcheck – C/C++ 代码静态分析 flawfinder – 寻找可能存在的安全漏洞 flint++ – 跨平台, 无依赖端口的 flint, 由 C++ 程序开发， Facebook 也在用 tis-interpreter – 由标准 C 写的一款用于寻找敏感 bug 的解释器 vera++ – Vera++是一个可用于验证，分析以及变换 C++ 源代码的可编程工具
　　4. 其他 DeepCode: 人工智能代码审查平台，为编程语言提供添加基于 AI 的静态代码分析支持。
　　前端代码质量审查资源清单：
　　https://github.com/thedaviddias/Front-End-Checklist
　　代码审查资源列表：
　　中英文对照 github
　　白盒测试的核心是  testing your code 。代码审查举足轻重。即可以自审，也可以他审。有的公司提倡结对编程，这样可以做到相互审查。
　　整理了一份代码审查清单，也可以自己去搜索。万变不离其宗。
　　常规项 代码能够工作么？它有没有实现预期的功能，逻辑是否正确等。 所有的代码是否简单易懂？ 代码符合你所遵循的编程规范么？这通常包括大括号的位置，变量名和函数名，行的长度，缩进，格式和注释。 是否存在多余的或是重复的代码？ 代码是否尽可能的模块化了？ 是否有可以被替换的全局变量？ 是否有被注释掉的代码？ 循环是否设置了长度和正确的终止条件？ 是否有可以被库函数替代的代码？ 是否有可以删除的日志或调试代码？
　　安全 所有的数据输入是否都进行了检查（检测正确的类型，长度，格式和范围）并且进行了编码？ 在哪里使用了第三方工具，返回的错误是否被捕获？ 输出的值是否进行了检查并且编码？ 无效的参数值是否能够处理？
　　文档 是否有注释，并且描述了代码的意图？ 所有的函数都有注释吗？ 对非常规行为和边界情况处理是否有描述？ 第三方库的使用和函数是否有文档？ 数据结构和计量单位是否进行了解释？ 是否有未完成的代码？如果是的话，是不是应该移除，或者用合适的标记进行标记比如‘TODO’？
　　测试 代码是否可以测试？比如，不要添加太多的或是隐藏的依赖关系，不能够初始化对象，测试框架可以使用方法等。 是否存在测试，它们是否可以被理解？比如，至少达到你满意的代码覆盖（code coverage）。 单元测试是否真正的测试了代码是否可以完成预期的功能？ 是否检查了数组的＂越界＂错误？ 是否有可以被已经存在的 API 所替代的测试代码？ 语句覆盖法
　　通过设计用例使程序中的 每条可执行语句 至少可执行一次。举个简单的例子：       def test(a,b,c):           if a > 1 and b == 0:               c = c / a           if a == 2 and c > 1:               c = c + 1
　　如果我们设计如下的测试用例： TestCase: a = 2, b = 0,c = 3。
　　这时候我们会发现，该函数的代码覆盖率达到了 100%，并且设计的 case 可以顺利通过测试。如果换成 TestCase: a = 2, b = 3,c = 0 就不能达到 100% 的语句覆盖率了。
　　通常语句覆盖被认为是＂最弱的覆盖＂，原因是它只考虑对代码中的执行语句进行覆盖而不考虑各种条件和分支，因此在实际运用中语句覆盖很难发现代码中的问题。 判定覆盖法
　　通过设计用例使程序中的 每个分支 至少可执行一次。即 if 判定为真，为假各一次。一般通过多个用例来满足要求。判定覆盖法弥补了语句覆盖法不考虑分支的不足。
　　还是以上面的 test 函数为例设计测试用例： TestCase1: a = 2, b = 0,c = 3；TestCase2: a = 1, b = 0,c = 1；
　　使用判定覆盖的法的时候一定要注意 别漏了为假 的情况。很多时候判定容易写成等价if True 或 if not False的形式反而多此一举。 条件覆盖法
　　通过设计用例使程序中的每一个单独条件至少为真，为假各一次。 判定条件覆盖法
　　通过设计用例使程序中的所有可能的值至少出现一次，并且每个判断本身所有的结果也至少出现一次。 条件组合覆盖法
　　通过设计用例使程序中的所有可能的条件组合都出现一次。 路径覆盖法
　　通过设计用例覆盖程序中所有可能的路径。只要达到 100% 的路径覆盖率，就能完全满足判定覆盖和条件覆盖。 基本路径覆盖法
　　基本路径覆盖法是在程序控制流图的基础上，通过分析控制流程的环路复杂性，导出基本的可执行路径集合，设计测试用例的方法。该方法把覆盖的路径数精简到可测试的响度内，程序中的循环体最多可执行一次。设计出的测试用例要保证在测试中程序的每一条可执行语句至少要执行一次。 循环路径测试
　　循环路径测试包括简单循环测试和嵌套循环测试。
　　1. 简单循环测试 0 次循环（从入口直接到出口） 1 次循环（检查循环初始值） 2 次循环（检查多次循环） 最大次数的循环 比最大次数多一次的循环 比最大次数少一次的循环 对于增量和减量不足 1 的循环
　　2. 嵌套循环测试 对最内层做简单循环的全部测试，把其他层的循环次数设置为最小值； 逐步外推，对外层循环进行测试。在测试时，保持所有外层循环的循环次数取最小值，对其他嵌套的内层循环的次数取＂典型＂值； 反复进行，知道所有循环测试完毕。 对全部循环同时取最小循环次数，或者同时区最大循环次数。
　　白盒测试的方法就说到这了，本人认为通过本 chat 很难完全描述清楚，需要举例详细说明，但并非所有的方法都适合每个人使用。建议平时还是不要写判定、路径覆盖太复杂的代码，这样设计用例也会花很久时间。大家重点关注后面要讲的敏捷测试就好了。 敏捷测试敏捷价值观
　　敏捷一词在互联网中经常被提起。如何算敏捷，敏捷方法学的领导者们在《敏捷软件开发宣言》总结道： 我们一直在实践中探寻更好的软件开发方法，身体力行地同时也帮助他人。由此我们建立了如下价值观：
　　个体和互动  高于  流程和工具工作的软件  高于  详尽的文档客户合作  高于  合同谈判响应变化  高于  遵循计划
　　也就是说，尽管右项有其价值，我们更重视左项的价值。
　　原文链接
　　敏捷计划
　　我在的项目刚开始就一个人，做性能测试开发，几乎是从 0 开始。什么流程、规范、文档都没。我为了在团队推动敏捷价值观，第一步还是从传统着手从 0 开始： 先建立流程、测试脚本； 编写文档、普及业务； 需求讨论、确定方案； 制定计划、遵循计划。
　　这些工作做完后，已经 3 个月过去了，不算太慢。但随着测试需求的增多和项目的迭代，我们发现做测试计划已经跟不上项目需求。不管做再好的测试计划，跟实际测试工作总会有出入。
　　比较认同 James 的 ** 10 分钟测试计划**：在 30 分钟内或更多时间内完成 80%。高度提炼测试计划，去掉其他所谓的细枝末节。只做最有必要的部分，把详细的细节留给测试执行人员。 敏捷实践
　　1. 建立任务列表
　　我们公司内部有一套系统可以建立项目、版本、需求、任务列表。类似早期的禅道。我个人比较喜欢建任务列表。可以按模块划分，比如热迁移测试用例开发，功能测试，压力测试，性能测试。对应到人，进度，截止时间。任务描述一般很少写，每个任务写下来要花费很少时间，也不符合敏捷价值观。测试同学一般心里有数，我会统一开会讲，写好测试说明文档。再结合提供的 HTTP API 可以获取到任务列表，通过钉钉定时通知到钉钉群，提醒对应的测试同学去更新任务状态、进度。
　　2. 增量开发（迭代）
　　提倡做项目排期、开发或重构计划。每 1-4 周完成一个模块的用例，更新迭代记录，日积月累。
　　3. 持续集成（CI） 每日（周、月）构建 测试结果输出和量化 配合版本发布自动迭代
　　4. 测试驱动开发（TDD）
　　发挥你的脑动力，黑盒、白盒用例设计方法用起来。 如果你为构造数据犯难，推荐 Python 的 faker 库。来轻松构造测试数据 github 地址
　　5. 自动化测试
　　把测试交给机器，用最少的时间成本去执行测试。定时任务、异步任务用起来。测试脚本循环跑起来。
　　6. 敏捷团队
　　我在的团队，测试同学很不喜欢写文档，那我说不写文档没事，那就多跑测试、多跟进 bug、多反馈进度吧。团队要做到敏捷，只有三个要求： 持续反馈 持续改进 响应变化
　　没有团队？那就外包出去。
　　7. 协作工具 知识库协作：多鼓励大家写文档，沉淀专业技术和业务能力。 钉钉即时交流：钉钉的消息通知做的很好，消息是否已读能及时明确，对于长时间不读消息的来一个 ding 通知（应用内通知、短信提醒、语音电话，组合更佳）。 代码协作：对于做测试的人来说，git 并不是一个最常用的工具。所以代码协作这块相对较弱。测试开发的代码债务越多，协作就越困难，合并代码的周期就变的越长，所以早用总比晚用好。 开发环境：组内每次来新同学，pycharm 都用不好，停留在只会打开项目配置解释器的程度。起初以为 vi、vscode 玩得好，是我想多了。我们团队的测试开发项目很多库都是内部自己研发，都集成在测试环境，无法通过第三方包来安装，拷贝到开发机也不太现实，因为很多依赖问题，只能通过配置 sftp 来远程连接项目了。用好 IDE 就不用倒腾代码了。 自动化工具 测试框架
　　1. Python 最详细的 Python 测试工具列表：链接 不同测试框架如何做测试：https://docs.python-guide.org/writing/tests/
　　2. C/C++ cunit：C 语言单元测试框架 cmock：C 语言 mock 测试框架 https://github.com/ThrowTheSwitch/CMock googletest：谷歌的 C++ 单元测试框架，能够大大缩短测试代码的编写效率 https://github.com/google/googletest
　　8. 以用户视角测试产品
　　我经常跟团队内测试同学强调要站在用户的角度去测试： 你能接受一个冒烟测试都不过的产品吗？ 如果你是一个用户，你会怎么用产品？ 作为用户你最不能忍受什么 bug？
　　同时也要最大可能评估风险，先给上级沟通打好预防针（做好兜底方案）。像没有经过测试的功能就上线，一旦出故障，客户会有什么反应，怎么去沟通，也是值得思考的问题。
　　9. 探索性测试
　　探索性测试是敏捷测试的重要测试方式。作为一个研究性的工具，探索性测试是基于以用户视角测试产品和自动化回归测试的重要补充。探索性测试依赖测试人员的业务能力、知识储备、主观能动性、学习能力和自我驱动力。 比如在没有可以参考的测试用例情况下开始测试 从 0 开始测试一个业务、功能
　　去年我在接到一个测试需求的时候，头皮发麻。因为要绕过上层控制系统，再怎么 mock 测试也不能脱离这个依赖。没办法，只能硬着头皮上，既然耦合性高，那我就一步步解耦。通过画流程图分析业务，提炼出流程测试用例，抓取日志验证测试思路，思路不对然后找不同链路上的人请教，订正思路整理测试脚本，完善测试流程，最后集成到自动化测试。
　　又比如通过钉钉 NLP 机器人实现交互式测试任务分配和管理； 通过消息队列分发测试任务并自动执行代替人肉通知和监督执行。
　　我经常跟测试同学强调，每天的测试任务跑完，可以多想想有没有更好、更高级、更 AI 的方式去执行测试，统计测试结果。主要是为了激发团队的探索能力，学到新东西，把测试做的更  cool  。 写在最后
　　由于时间和个人经验的问题，鄙人就分享到这里了。本 Chat 参考了一些已有的教程，为了更系统更直观更有温度，加上自己的工作经验来提炼润色，经验也不一定全值得参考，希望大家在用例设计和敏捷测试上有所收获，也希望在测试这块越做越好。
　　最后分享一个软件测试相关的书单，大家可以根据自己的情况查漏补缺： 书单
　　书名
　　推荐理由
　　软件测试 [美]Ron Patton
　　软件测试理论经典
　　Google 软件测试之道
　　看 Google 如何做测试
　　微软的软件测试之道
　　看微软如何做测试
　　软件测试经验与教训
　　学习经验避免走弯路
　　Web 性能权威指南
　　系统了解 Web 性能从而优化 Web 测试
　　pytest 测试实战
　　Python 测试豆瓣评分最高
　　软件测试技术基础教程（理论、方法、面试）
　　工业和信息化人才培养规范教材
　　Selenium 2 自动化测试实战
　　Web 测试自动化实战
　　Robot Framework 自动化测试修炼宝典
　　Robot Framework 中文入门首选
　　移动 App 测试实战
　　移动端测试入门与实战