作者：admin 发布时间：2022-12-17 08:15 分类：算命 浏览：332
本篇文章给大家谈谈身份证号码测试用例，以及测试用的身份证号对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。
身份证号的特点是16位或者18位，当然了，现在16位的越来越少，但也要考虑进去。那么，你这个文本框就要有判断，比如，只可以输入数字，数字必须是16位或者18位，并且要屏蔽一些可能的胡乱输入的数字。比如：18个1,18个2.......如果针对某一地区，则还要判断前几位。
做这些就是为了保证获得的数字是一个真实的身份证号，而不会是一个胡乱输入的数列串。
测试身份证号码不光要用到等价类的方法，边界值也必须要用到，等价类的方法可以分成合法字符、非法字符两大类，然后合法字符中又可以分为完全数字和数字与字母的结合，然后用到边界值测试方法，测试身份证位数分别为0位、1位、17位、18位、19位；非法字符中可以包括特殊字符、全是字母等，具体举例：
1.null
2.0
3.01
4.11111111111111111
5.111111111111111111
6.aaaaaaaaaaaaaaaaaa
7.aaaaaaa11111111111
8.1111111111111111111
9.370103198812233432
等等
大家好，我是十一。
前面我们用了7篇介绍了5种测试用例设计方法，分别是 等价类划分法 、 边界值分析法 、 因果图法 、 判定表法 、 正交实验法 。5种方法各有利弊，根据我多年测试经验，综合使用多种设计方法比使用一种设计方法更有效，设计出来的测试用例覆盖率更高。另外，我们在设计测试用例的时候需要根据任务说明、需求说明、选定的测试策略以及自身因素来综合考虑具体选择哪些设计方法对当前的测试工作更有效！
接下来我为大家分享一个我认为合理有效的策略，该策略原型来源于梅尔斯的《软件测试的艺术》，根据我的经验做了稍微改变以及说明，供大家参考：
1.如果规格说明中包含输入条件组合的情况。
a.如果输入条件较少，应优先考虑因果图分析法；
b.如果输入条件较多，测试用例量过大，则应优先考虑正交实验法。
2.在任何情况下都应使用边界值分析方法。
边界值分析可以产生一系列补充的测试条件。事实上，我们在实际工作中边界值分析法是一个必不可少的重要的设计方法。但是缺点也显而易见，他不能担起测试用例设计的重任，必须与其他设计方法结合使用。
3.应为输入和输出确定有效和无效等价类。
a.等价类划分法可以同边界值分析法一样与其他测试用例结合使用，在必要情况下对上面确认的测试用例进行补充
b.另外，为其他设计方法提供技术支持，比如：在正交表构建过程中，我们确定因素水平就会用到等价类划分法和边界值分析法。
4.使用错误推测法补充更多的测试用例。
这个方法主要是根据规范、经验、常识等提取/增补测试用例。
5.针对上述测试用例集检查程序的逻辑结果。
此处会用到白盒测试用例设计方法，比如：判定覆盖、条件覆盖、判定/条件覆盖或者多重条件覆盖准则。（这些设计方法我们往后放放，暂时先忽略这部分）
要注意的是：使用上述策略并不可能发现所有的错误，但实践证明，这是一个有效的且合理的方案。
另外，关于测试用例还有一些点需要大家注意。
1.一个测试用例必须包含前置条件（背景）、测试输入、测试输出（期望结果）；
2.测试用例的粒度越小越好；粒度小的测试用例具有如下优点：
a测试用例的覆盖边界定义更清晰
b.测试结果对产品问题的指向性更强
c.测试用例间的耦合度最低，彼此之间的干扰也就最低
d.测试用例可读性比较高，信息含量越小，可读性越高
3.测试用例必须描述简洁清晰；
a.测试用例必须描述清晰。因为测试用例并不是给自己用的，而且测试用例大多数不是一次性的，所以我们必须要描述清晰，保证下次可用，他人可用。
b.测试用例必须简洁。通常，我们的工作周期都是有限的，且现在迭代更新速度越来越快，所以我们在编写测试用例的时候要注意在描述清晰的前提下，使用简洁的语言。
4.测试用例必须要持续更新；
a.需求大多数情况不是永恒不变的，所以我们在需求发生了改变的时候或者在测试时候发现测试用例描述不准确，不完全时就要及时修改测试用例，以保障测试用例的准确性；
b.测试用例都是人工设计出来的，设计者可能对需求的理解或者功能知识点的理解存在偏差，这样就会造成设计出来的测试用例不准确甚至不正确，这时候我们就需要有辨别是非的能力，且发现测试用例错误后要及时修订，以免造成二度损失/二度浪费。
5.测试用例集合必须是一个“完备”的集合，保证需求中的每个功能点都被覆盖到；这里要注意的是，测试用例要覆盖所有的功能点，而不是要做完全测试；
a. 完全测试： 对产品进行穷尽测试，把所有可能以及所有可能的组合均测试一遍
b. 覆盖所有的功能点： 要求覆盖需求中所有显性功能点（需求说明书提到的）、隐性功能点（没有提到，但是是约定俗成的或者常识性的点，比如我们在测试身份证号码的文本框时候，需求说明书可能只会写：合法允许保存，不合法文本框后提示非法用户，此处不会给出身份证号码具体什么是合法，什么是非法；那么这个点就是隐性功能点；再比如：密码框必须是密文，很多需求中也不会强调，但是我们在测试时候一定要设计这个点的测试用例），我们可以对所有数据通过等价类划分和边界值分析法提取出有代表性数据来做测试即可。
6.只有在深入理解软件需求、甚至架构设计后，我们才有可能设计出“完备”的测试用例集 ；因此，我们在设计测试用例之前一定要好好研究软件需求（对于初级测试人员来讲,大家只要做好这点即可）、架构设计、实际设计等。
7.先正常再异常，且一定要对异常进行测试。 这个很重要，很多人不是忽略了异常情况，就是次序混乱，导致测试用例遗漏或者重复。
8.最最重要的一点，我们在测试用例设计之前一定要先对需求进行测试！ 这个就是在需求分析、需求评审阶段测试一定要参与进去，测试参与到项目的时间越早越好。
好了，今天到此结束。如有任何问题请留言及时与我沟通，我会尽快回复大家！谢谢大家~我们下次再见！
首先判断位数，就用leanth 吧。判断 出生 这个可以先 取 字串，在判断！ 判断是不是数字，就用正者表达式撒，最后一位的判断还是用substing吧
首先是长度测试18为
1、测试17位号码与19位号码无效18位号码有效
2、输入类型测试，18位号码只有2种1种是18位纯数字，第二种是17位数字+X
边界值测试就是前18位为其他类型字符；17位数字和1位非X类型字符，17位数字符和X字符和18位纯数字字符，
3、细分还有就是身份证前6为地址码，中间8位生日码，3位顺序码，1位校验码
地址码的边界值根据国家地区编码规定（这个具体值我不是很清楚）例如范围值是100001~899999，那就分别给钱6位数字输入100000和900000不成功100001和899999成功，中间8位为出生日期，则根据时期测试规则来判定，网上有也很成熟了，无非就是年月日的合法关系，只要测试日期的合法性就好了。最后3位顺序码就是000~999包含所有数字字符，最后一位就是0~9+X，其他不合法
最后4位上面2个用例已经测试完毕了
设计具体用例数时，因为b=ABS（a）中ABS中是与关系，也就是说任何一个条件不通过，该号码合法性就不通过，故ABS（a）中4部门号码可以分别验证，当验证一段号码时，其他号码都选择有效号码，而不是所有的非法性排列组合去验证，举个例子就是100000199901010000，100001199901010000，这两个号码，前一个号码无效，后一个号码有效。
关于身份证号码测试用例和测试用的身份证号的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。