1. 从一次线上事故说起你确定真的测过“边界”吗做软件测试这行时间久了都会有一种感觉用户永远比你更会“找茬”。前阵子我们上线了一个活动页面里面有个优惠券金额输入框需求文档写得清清楚楚金额范围是1到500元整数。测试用例也写了正常输入、金额过大、金额过小看起来该覆盖的都覆盖了。结果上线第二天就翻车了。用户输入0元系统提示“金额不合法”但这个提示是在后端校验才触发的前端直接放行了风格还完全不统一。更离谱的是输入0.01元居然也通过校验订单生成了一个无比诡异的价格。排查下来发现根因很简单测试用例里只写了“小于1元”这种等价类数据选了0.5、0.8都拦住了但唯独没测紧贴着合法边界的那几个特殊值。1元的边界是0.9还是0.99边界本身算不算合法下边界紧邻值要不要测这些细节全被稀里糊涂地跳过去了。这不是个例我几乎每隔一段时间就会遇到一次类似的问题尤其是在时间紧、需求急的项目里。为什么边界值这么容易出现线上事故因为开发写代码时判断条件的临界点最容易被写错比如该用大于等于却写了大于该用小于却写了小于等于而数据在正常范围中间时怎么跑都不会触发这些错误只有数据刚好踩在边界附近那一毫米的位置上才能暴露出问题。这就是边界值分析法存在的意义不是去测一大堆“正常范围里的典型值”而是专门去测那些最容易出错、最容易被开发遗漏的边界附近的值。这篇文章我想好好聊聊边界值分析法。从它的原理、变体、实操步骤到怎么跟等价类划分配合使用再到测试人员在实战中容易踩的坑一次性说透。不管你是刚入行的测试新人还是已经被各种复杂规则折磨得焦头烂额的测试老手这篇文章应该都能给你一些可落地的东西。2. 边界值分析法的底层逻辑为什么临界点最容易出bug2.1 开发者的思维习惯决定了bug的分布要理解边界值分析法首先得理解开发者的编码习惯。绝大多数开发在写参数校验逻辑时思路是“在合法范围内放行在非法范围内拦截”。代码写出来大概是这样的逻辑如果值大于等于1且小于等于500就走正常流程否则就报错。看起来很简单但问题恰恰出在这个“且”字和几个比较运算符身上。人类在连续书写多个条件的比较时注意力很容易在某个瞬间发生偏移。1可以500也可以但要不要包含等于需求文档用“1到500”这种描述时开发通常会理解为闭区间也就是包含端点。但如果文档写的是“1~500元”有的开发会理解为大于1小于500虽然语言上并不严谨可代码里就会漏掉1和500这两个合法值。另一种常见写法是把下边界写成了1这样一来1本身就被拒之门外。还有个更隐蔽的问题数据类型转换带来的边界漂移。比如输入框接收的是字符串额度的意思是比较时需要转成数字类型这里就有很多坑。整数可能被转成浮点数浮点数的精度误差会直接导致比较结果与预期不符合。再比如纯数字字符串和带单位的字符串一不小心就会解析异常。与其在事后再来排查这些问题不如在设计用例的时候就专门针对这些临界区域做密集覆盖。从测试覆盖率的角度来看等价类划分解决的是“把无限输入压缩为有限子集”的问题它关注的是数据落在合法域还是非法域做得是比较粗粒度的分类。而边界值分析法是在这个基础上更进一步把注意力聚焦到每个等价类的边缘因为边缘处的判定逻辑是最复杂的、分支是最多的也是开发最容易写错的地方。2.2 边界值的数学本质开区间与闭区间边界值分析法背后其实是一个数学概念区间。我们口中常说的“1到500”在数学上可能是开区间、闭区间、左闭右开、左开右闭四种形式不同的区间表示方法针对性地需要不同的测试策略。闭区间 [1, 500]1和500都属于合法值。除了这两个端点之外紧挨着它们的外部值0和501也必须测因为它们分别是“刚好达不到下限”和“刚好超过上限”的代表。左开右闭区间 (1, 500]1不合法500合法。这时候测1本身是无效等价类而0和501自然更是无效的但0.01这个紧贴1右侧但又大于1的值反而是合法的不能漏掉。开区间 (1, 500)端点都不合法所以1、500本身要作为无效等价类的边界来测。左闭右开区间 [1, 500)1合法但500不合法500本身是无效边界499.99是有效的紧邻值。这个分析告诉我们一个道理在动手写测试用例之前先把需求中的数字描述翻译成精确的数学区间搞清楚哪些边界点属于合法域哪些属于非法域一字之差可能导致完全不同的用例设计结果。2.3 最小边界、最大边界和步进值在真正进行边界值分析的时候我一般会先找出三个东西最小值、最大值、步进值。这三个参数共同决定了整个输入域的结构。拿一个日期选择器来说假设业务规则是“可选的预约日期为今天起30天内”那么这个输入域的最小值是今天的日期最大值是今天加30天的日期。如果这个日期选择器还支持时分秒那粒度就还需要细化边界就从“天”这一层下沉到“秒”这一层边界值的数量也随之膨胀。步进值反映了系统允许的最小变化单元也隐含着数据的精度需求例如金额是0.01起步还是1起步年龄段是否必须是整数等。有些人可能会问边界值分析法到底要不要适用于布尔值、字符串等非数值类型答案是要的。字符串的边界是长度比如密码6到20位边界就是长度6和长度20对应的紧邻值是长度5和21。布尔值的边界则体现在取值集合的唯一两个元素上比如开关状态只有开和关。文件上传场景的边界则是文件大小阈值通常以字节为单位来卡。所以边界值的“值”不局限于数值任何可枚举的、可比较的数据类型都有边界只是表现形式不同罢了。3. 边界值分析的两大流派标准版与健壮版3.1 标准边界值分析最小用例集标准边界值分析法是教科书里最经典的版本。它只关注边界上及其紧邻两侧的值而不考虑超出边界太远的那些“深水区”。具体来说假设某个输入条件是闭区间[a, b]那么需要设计的测试数据是这五类略小于a的值、a本身、a和b之间正常范围里的任意值、b本身、略大于b的值。这一套组合在大多数情况下已经足够覆盖边界相关的逻辑错误了。比如在一个注册页面上密码长度要求为8到20个字符标准边界值分析会生成这些用例7个字符小于下限、8个字符等于下限、15个字符正常值、20个字符等于上限、21个字符大于上限。这里有一个细节要留意“略小于a”和“略大于b”的“略”字的粒度必须与系统的步进值一致。如果输入域是整数那略小于8就是7略大于20就是21干净利落。但如果输入域允许小数比如金额精确到分那略小于1元就是0.99元略大于500元就是500.01元而不是0元或501元。粒度不对的话测了也白测甚至可能测出一个本不该出现的问题白白浪费排查时间。标准边界的优点是用例数量少执行成本低在迭代节奏快的项目里非常实用。但它的缺点也很明确只覆盖了边界两侧各一个点的距离如果开发写错的程度比较大例如把条件写成了小于1而不是大于等于1那么测试0.5这个值也能拦截但如果开发写成了小于0那0.5测不出来只有用一个更小的值才能测出来。不过这种情况通常依赖等价类里的法外值去兜底所以标准边界并不算存在致命的漏洞。3.2 健壮边界值分析把“异常”也纳入视野健壮边界值分析法是在标准版的基础上额外增加了对“超出边界很远的异常值”的考虑。它的核心思路是不仅要保证边界处功能正确还要保证当输入的偏离程度比较大时系统的容错机制依然有效不会导致崩溃。继续用密码长度8到20作为例子。健壮版会在标准版的7、8、15、20、21之外再增加0个字符、100个字符、甚至一个null值。这些值用来验证两件事一是系统的校验提示是否友好二是系统在接收极端异常输入时是否会产生未捕获异常、超时或性能问题。比如输入0字符时有些系统会直接报空指针而不是给出“密码不能为空”的友好提示这种问题如果不提前测出来上线后就是妥妥的用户体验投诉。这两种流派该怎么选呢我的建议是如果系统对稳定性要求极高比如涉及支付、订单、医疗数据或者是要对外提供API接口优先使用健壮边界值。如果只是普通的表单校验、查询条件、配置信息维护标准边界值配合等价类就足够覆盖需求了不必过度设计造成用例冗余。如果开发语言本身类型检查很严格比如输入框对类型有限制那么null和超长字符串这类值的威胁等级会相对降低但安全类功能除外。在实际做用例评审时我不太喜欢把标准版和健壮版对立起来。正确做法是先按标准版搭好主框架然后根据功能的重要程度、代码的复杂程度挑选关键边界补充健壮性的测试数据。这样既能控制用例总数又能保证高风险点有足够密度的火力覆盖。3.3 边界值分析与等价类划分的搭配方式很多人学了一堆测试方法却不知道怎么组合用。我的习惯是“先分箱子再找边”说的就是等价类划分和边界值分析的协作关系。第一步先把整个输入域切分为若干等价类每个等价类里的数据被认为具有相同的测试价值。第二步在每个等价类内部和相邻等价类之间找边界然后针对这些边界和边界紧邻的数据设计用例。举个例子一份调查问卷里有个字段叫“月收入”选项分为四档3000以下、3000到8000、8000到20000、20000以上。等价类划分会把这些档位作为四个有效等价类再加一个“不填”作为无效等价类。边界值分析要做的就是找出每个档位的临界点3000、8000、20000这三个分界值以及它们两侧紧邻的值。于是测试数据就是2999、3000、3001、7999、8000、8001、19999、20000、20001这一串。在搭好这条主线的同时还要记得给每个有效等价类补充一个“中间段取值”用来验证正常路径能走通。边界值保证了“临界点附近不出错”中间值保证了“常规路径没问题”两者合一才是完整的覆盖。4. 手把手实操用边界值分析法设计一个真实项目的测试用例4.1 确定输入条件并转化为区间模型下面用一个我在工作中遇到过的真实场景来演示完整流程场景经过了简化但保留了精髓。某管理后台要新增一个“折扣比例”字段业务需求是折扣值在0.5%到90%之间精确到0.1个百分点。也就是说这个值不能小于0.5不能大于90.0同时精度是0.1。测试人员需要为这个字段设计功能测试用例。收到这个需求之后不要急着写用例先把关键参数列出来下边界值0.5上边界值90.0步进值0.1区间类型闭区间包含0.5和90.0数据类型数字可能为浮点数是否允许为0不允许是否允许为负数不允许这个列表整理完之后我还会问产品经理几个问题确认细节如果用户输入了带百分号的值系统是直接报错还是会自动转换如果用户输入的是中文输入法状态下的数字会不会有格式上的干扰如果这个值存储到数据库时被转换为decimal类型精度会不会丢。这些看似细微的东西其实是设计用例的重要依据。4.2 标准边界用例的完整生成过程将区间信息和步进值代入标准边界值分析的五点法可以得到以下基础数据略小于下边界0.40.5减一个步进值恰好等于下边界0.5正常范围中间值45.0恰好等于上边界90.0略大于上边界90.190.0加一个步进值这个主序列覆盖的价格逻辑是判断输入值是否被正确接收或正确拒绝。如果这些用例执行通过说明校验条件里最核心的几个比较操作符没有拼错。然后再补一组常见的次边界负数值-1零值0精度超限值50.55多了一位小数应被拒绝非常大值999.99空值不填到这里最初的用例框架就基本成型了。具体执行时每个用例都要拆分为入参、预期结果、实际结果。比如预期0.4被拒绝并提示“最低折扣为0.5%”0.5被接受且不做任何四舍五入操作90.0被接受90.1被拒绝并提示“最高折扣为90%”。这里有个常被忽视的点恰恰是0.5和90.0这两个合法边界值不仅要让系统接受还要确认存储下来的值与输入值完全一致不能出现0.5被存成0.49这样的精度丢失问题。4.3 边界值分析结果与预期结果对照表测试数据类型定位预期结果0.4下边界紧邻外部值拒绝提示低于最小值0.5下边界端点值通过允许保存45.0中间正常值通过允许保存90.0上边界端点值通过允许保存90.1上边界紧邻外部值拒绝提示超过最大值0零值拒绝提示最小值约束-1负值异常值拒绝提示非法范围50.55精度异常值拒绝提示仅保留一位小数999.99极大异常值拒绝提示超过最大值0.49下边界与零值之间非紧邻值拒绝但提示可接受这张表里最容易被漏掉的是最后一行的0.49。很多测试人员看到0.4已经测了就默认0.49不需要测理由是两者都小于0.5属于同一等价类。这种想法本身没错但从复查的角度来看0.49距离合法值只差0.01属于“临界偏差点”开发如果用了四舍五入的逻辑去处理这个值就可能出现0.49被接受的情况。虽然我们不应该对每一分的差异都穷追猛打但对于某些特别核心的字段多花一条用例去验证这种暗雷性价比其实是比较高的。实际执行这些用例的过程中有一半的测试人员在输入0.4和90.1的时候会抱有一个预期系统会给出“格式不正确”的提示。但真实产品里很多提示语写的是“数值范围错误”或者“折扣不能低于0.5%”措辞五花八门。所以在设计用例时提示文案最好不要写死只要验证了“拒绝”这个行为就足够具体措辞让产品和开发去敲定避免用例因为文案调整而频繁返工。4.4 从用例到测试报告如何判断边界测试是否真的通过写完用例并执行之后还有一个环节汇总测试结果做出通过与否的结论。我习惯把这个环节分为三个层次第一层是功能层验证输入值是否被正确接受或拒绝这是最基本的通过标准。第二层是数据层验证被接受的值是否以正确的精度、正确的格式存储到了数据库。第三层是体验层验证系统给出的提示是否清晰、友好不会让用户摸不着头脑。说起来功能层和数据层最容易引起测试和开发的认知偏差。开发在本地调试时很可能会直接在接口层做校验测试人员却是在页面上输入数据两者经过的路径不同容易被一叶障目。所以在设计边界值用例时我强烈建议测试人员把接口层的用例和页面层的用例同时设计出来分别执行。如果页面层能拦住所有非法值接口层的用例可以降级为抽测但至少得保证关键的几个边界点在接口层也有对应的校验。如果任何一个边界值在功能层被错误地接受了问题严重程度定为必修如果只是提示语不清或页面样式错乱定为次要缺陷但也要记录在测试报告中。把这些结论明确地写进缺陷跟踪系统附上输入值、预期结果、实际结果和操作路径开发拿到的就是一个无歧义的bug复现报告沟通成本会低很多。5. 边界值分析常见误区与实战经验避坑5.1 最容易犯的错误把边界值当点测而不是当区间测我见过不少刚工作两年的测试同事拿到“1到100”的需求就开始写用例1、100、0、101。用例写完之后自信满满认为覆盖已经非常完美了结果还是被线上问题打了脸。问题出在哪他们把边界值当成了离散的点而不是一个连续的区间。真实场景中输入域往往是连续的或者至少包含大量中间取值。如果只测1和100以及紧邻的两个外部点那么98.999、99.5、100.1等这些靠近边界的值就容易被忽略。特别是一些精确度比较高的业务领域比如金融、科学计算、传感器数据一个小数点后微小的数值移动都可能改变业务判定结果。所以当步进值足够小的时候边界处的取值就要更密集。比如业务要求“输入值小于10且大于0精度到0.001”那边界附近的候选值至少应该是9.999、10.0、10.001这几个层级。同样在测试一段连续区间时也可以用合适的粒度将边界附近划分出三个梯度紧邻外部值、边界值、紧邻内部值。每个梯度只取一个代表性数据就可以。如果步进值特别小可以考虑把紧邻内部的取值点再细化一层但不是无限细化四条候选数据足够了再多就是堆砌无效用例。5.2 别再忽略“非数值边界”的边界值场景很多测试人员对边界值分析法的印象还停留在“一维数值区间”上但真实的系统中充满了非数值类型的边界条件。字符串的长度是最常见的非数值边界文件上传大小是字节数的边界列表分页的总页数边界、时间选择器的时区边界、IP地址的格式边界全部都可以用边界值分析法来设计用例。拿分页功能来举例。假设一个列表接口支持pageSize为1到100默认值为20。边界值用例就围绕pageSize这个参数展开pageSize1、pageSize100、pageSize0、pageSize101、pageSize缺失。再看页码本身的边界请求第1页和第5000页超出总页数的极端情况判断系统会不会返回空的列表还是错误。这里还有一个隐藏边界当pageSize为100时如果总记录数刚好是100那么只有一个页面如果总记录数是101那么会出现第二页只有1条记录的场景。这种“边界交错”是测试人员特别需要警惕的。字符串长度边界也有典型例子昵称限制长度为2到10个字符边界用例是1字符、2字符、10字符、11字符。但多字节字符也要考虑比如一个中文字符在UTF-8编码下占3个字节在统计长度时系统用的到底是字节数还是字符数又或者数据库字段定义的varchar长度是按字符数还是按字节数。这种边界如果去测试的时候不留意上线后轻易就能被用户用emoji和生僻字玩坏。5.3 实战中屡试不爽的排查技巧双人复核边界用例边界值分析法设计出来的用例数量通常不会特别大但它的核心风险在于“测试人员是否准确地解读了业务规则”。为了减少理解偏差我在团队里推行了一个简单粗暴的做法边界值用例设计完成后测试人员两两进行交叉复核每个人检查对方的用例是否存在漏测边界和多余的无效用例。这个做法的好处在于测试人员在理解需求时很容易产生“功能性固化”意思是一旦形成了自己的看法就很难看到另一种可能性。另一个同事在旁边看的时候往往会从不同角度提出质疑比如“这个字段允不允许空值”“这个下边界值是不是应该是步进值的倍数”这些疑问常常能补上最初的用例设计盲区。交叉复核时也顺便检查提示语预期是否过于死板。很多需求文档只会说“对无效输入给出错误提示”不会写明具体文案。用例预期如果写得太死后期产品调整文案时测试用例也要跟着改显得很笨重。更好的做法是在用例中把预期描述为“拒绝输入并提示范围约束”具体文案以缺陷跟踪系统记录为准。还有一个可能是全网都不太会提的小技巧复核前先让测试人员写一段业务规则的“一句话总结”。比如“折扣比例必须介于0.5到90之间且精确到一位小数”。这句话虽然简单但能直接暴露测试人员对需求的理解是否存在偏差。要是有人把0.5忘掉了写成了“必须介于0到90”那他设计的边界用例在0.5附近就一定是漏的。这个步骤花一分钟却能在源头挡住一轮无效测试。5.4 边界值用例执行成本控制别让百分之五的边界吃掉百分之五十的时间测试行业有个尴尬的现实边界值虽然重要但它在全部用例里的占比通常只有百分之五到十然而定位和复现边界缺陷所花费的时间经常能占到整体bug排查时间的一半以上。因为在边界出现问题时往往伴随着数据格式、精度、逻辑分支的连锁反应一个字段的边界异常经常能牵扯出多个模块的联动异常。为了控制成本我通常把边界值用例分成两类核心边界和扩展边界。核心边界是那些直接决定某个功能能否正常工作的边界。例如支付金额的下限是0.01元那0.01、0.00、0.02这三个值就是核心边界必须全覆盖。扩展边界则是那些即使出错也不会造成严重影响的边界例如某个报表类型的最大值限制即使超限也只是显示异常不会影响核心交易那可以安排冒烟抽测不必每条都展开深度验证。同时也要学会利用自动化测试来兜底边界值回归。边界值用例结构稳定、预期明确非常适合参数化后加入自动化测试套件。把常见输入域的边界值、紧邻值、极端值整理成一份参数化数据表每次迭代后自动跑一遍这样手工测试的时候就不需要每次都逐个重新执行了。我在实际项目中一般会把核心边界用例做成自动化扩展边界仍然保留手工验证在特殊版本更新时再重点执行。这样既不遗漏风险也不会让测试团队被重复执行拖垮。还有一点关于测试环境的提醒边界值缺陷在测试环境一测就过、上生产就挂的案例太多了原因往往是测试环境和生产环境的配置差异比如数据库类型、精度设置、字体编码等。所以我坚持在做边界值分析的时候先确认测试环境是否与生产环境保持同规格至少要在精度设置、字符集、时区这些直接影响边界判断的配置上保持一致。很多人觉得这是运维的事但实际上测试人员最清楚哪些配置会影响当前这批用例在环境准备阶段就主动提出来能省下一大堆网上翻资料的功夫。6. 边界值分析法的进阶场景与扩展思路6.1 多维边界值当多个输入条件同时逼近边界时常规边界值分析法通常只针对一个输入条件进行设计但在复杂业务场景中多个输入条件往往会同时作用于同一个功能逻辑。比如一个“满减优惠”的功能既有订单金额的下限要求又有优惠券数量的限制还有使用期限的截止日期这些条件之间会相互影响。如果只看单个条件的边界就可能漏掉“订单金额刚好满减门槛且优惠券刚好过期”的组合场景。多维边界的处理思路是选取其中一个输入条件作为主变量将其余条件固定在边界值或正常值上然后逐个验证主变量边界的影响。要是条件数量太多无法穷举全组合就用配对测试的方法来降维也就是从全部组合中选出具有代表性的组合保证任意两个条件的所有取值都能至少相遇一次。我曾在一次涉及订单折扣、运费、优惠券三种条件叠加的项目中直接用配对思想生成了44对组合执行完之后基本所有边界和交叉问题都暴露出来了比盲目的全组合节省了好几百条用例。多维边界的难点在于业务逻辑本身可能会改变规则的“形状”。例如订单金额达到100元时才会触发免运费那这个100元就是一个交互边界但当用户用了一张满50减10的优惠券之后订单实际支付的金额可能低于100元那么免运费条件是看原始金额还是看支付金额又是一个需要确认的边界。测试人员在处理这种需求时一定要先跟产品经理确认好判定依据否则用例就是空中楼阁测出来的结果自己也解释不清楚。6.2 状态转换视角下的边界不变量与状态机的临界还有一种情况是输入本身不是单一数值而是系统状态的变迁。这时候边界值分析法和状态转换法就要结合起来使用。比如一个审批流程节点状态包括待审核、审核中、已通过、已驳回。状态转移的临界点是用户点击某个动作的瞬间测试人员需要针对每个状态的所有合法流转路径和非法流转路径设计用例此时边界值就不再是“1和100”而是“具备某种权限的角色”“只有一条审批记录”等等。这类场景下要注意的是“边界条件会导致状态机的丢失”。比如一个会话在30分钟内无操作就会自动过期测试边界就是29分钟、30分钟、31分钟。29分钟时操作应该正常30分钟整时操作可能正好过期31分钟时必然过期。这里的边界值不仅仅是时间本身还包括过期后有没有妥善跳转到登录页、有没有保留用户填写的数据等状态联动问题。状态转换和边界值结合的测试用例设计可能需要一些对业务的状态建模能力。建议在编写之前先用简单的状态表格把每个状态节点、每个动作、每个后续状态都列出来再逐一添加它们的边界用例。表单制图很麻烦就一张Excel或一张纸也能理得明明白白。6.3 经验总结边界值分析法的适用边界与局限性边界值分析法非常高效但它也不是万能的。它最适合应用在输入域明确、边界清晰、数据类型标准化的场景里比如数值字段、日期范围、文件大小。但在输入数据不规则、规则依赖上下文、或者判定逻辑高度复杂的场景中单靠边界值分析覆盖的颗粒度可能不够。举个例子一个自然语言处理模型的输入是一整段话那“边界”这个词就不好定义了因为不存在数值意义上的边界。再比如一个复杂的规则引擎它的输入是若干条件的组合边界值未必能覆盖到组合爆炸的空间。这时候边界值分析法只能作为辅助手段重点还要放到场景法、决策表法上去。更需要注意的是边界值分析法本身有一个前提假设开发和判定逻辑的正确性与否在边界附近表现得最敏感。这个假设在大多数工程场景中是成立的但不是绝对的。有些bug是整体性、结构性的与边界无关比如数据库连接池耗尽、外部服务超时这类问题用边界值分析法效果有限还得靠性能测试和错误注入等手段来解决。所以我的经验是边界值分析法应该被看作一套必备的基础工具而不是唯一工具。它和等价类划分、场景法、判定表法、错误推测法相辅相成只有根据不同的测试对象灵活组合才能获得真正稳固的测试覆盖。7. 写在最后我眼中边界值分析法的真正价值做测试的时间越长我越觉得“边界值分析法”这个名字其实有点误导人。它听起来像是一种设计用例的方法但在实战中它更是一种思维习惯。拿到任何一段需求脑海里第一反应不再是“这个功能正常能不能跑通”而是“这个需求的边界条件是什么哪些取值最容易让逻辑产生分支判断分支的每个岔路口有没有被覆盖到”。这种习惯对测试人员来说非常宝贵。很多线上事故并不是功能设计的高深逻辑出了问题而是在最不起眼的一个“等于号”上翻了车。边界值分析法把注意力放在了这些最容易致命的位置上用最低的成本、最直接的方式暴露问题。它不是一种高深难懂的理论却能在每天的测试工作中产生实实在在的价值。如果你刚刚开始接触测试用例设计我建议你从今天开始对每个字段都养成列一套边界值的习惯哪怕只是用Excel记一下下边界、略小于下边界、略大于下边界、上边界、略小于上边界、略大于上边界。坚持用下去你会发现自己发现自己写的用例越来越有章法提bug越来越准测试思维也越来越像一名真正的测试工程师了。