这些测试中的奇怪问题你见过吗？

lsekfe

测试过程中，无论案例怎么设计、怎么执行，都需要测试人员有一定的敏感度去发现问题，测试人员的经验积累无论对于案例的设计、测试执行还是缺陷的发现都有很重要的意义，所以接下来我想给大家分享一些我自己在测试中遇到的经典或非经典场景。

　　1 需求了解不到位
　　有些问题其实并不算很难或很复杂，只是需要测试人员在测试前仔细阅读需求，明确需求要求实现的功能、需求给定的请求和应答报文字段、需求阐明的业务规则，所有需求里明确写了的内容在测试中应当务必保证覆盖。我在测试中遇到的问题有返回报文字段和需求不一致，业务规则要求取值范围大于等于固定值，在实现中变成了大于固定值等等情况。相关场景多是疏忽没有仔细阅读需求所致，有时候是由于任务多次分解，最后一个接收到代码任务的人没有接触到需求直接完成了代码工作，这种场景就需要测试人员足够细致耐心，如果测试环节无法发现，很有可能相关问题就会逃逸到生产上，再次修复成本更高，甚至可能已经产生了负面影响。

　　2 查询条件是否包含等于
　　涉及到查询交易中查询条件如何设置需要认真按需求完成，例如上一个问题中提到过的内容。但是也有其他场景，这次遇到的并不是开发代码问题，而是我在测试中对代码逻辑没有充分了解所以将正常逻辑误判为缺陷，开发同事在拒绝缺陷后又解释了相关场景和逻辑，我认为还是很有意义的一种场景，可以写下来给测试小伙伴们参考。在某交易明细查询中，查询条件有一个是20位时间戳，格式例如：20210101102533760702，在查询过程中，当上送时间戳字段的时候，返回的是时间戳大于该值的结果，不包括等于该值的场景，原因是该交易一般取上一次返回的时间戳为查询条件进行续查，如包含等于的场景会导致数据出现重复。由此可见，是否需要包含等于需要视应用场景而定，避免按自己的理解想当然，同时，相关场景如果不确定或未事先沟通的话，最好充分了解后再确定处理方案。

　　3 空格在交易中的影响
　　空格分全角空格和半角空格，我测试中遇到过两种情况。一种是一致性校验的过程中，一方数据混入了空格，需要额外进行处理；另外是在查询过程中，查询条件输入的值包含空格，需要考虑是否进行处理。以上两种情形，对空格的处置需要考虑多种情况，全角空格、半角空格、空格在数值前（例：  20210101）、空格在数值中（例：2020  0101）、空格在数值末尾（例：20210101  ），其中，空格在数值末尾和半角空格的场景相对比较常见和易于处理，另外几种场景则需要根据需求及应用场景充分考虑、适当处置，避免影响交易执行或交易成功率。

　　4 数据校验的适当性
　　在用户注册交易中，个人用户常常需要使用身份证号进行注册，通常大家默认身份证号为18位数字，第7位到第14位为8位年月日，但是实际中，有可能出现15位身份证号码，如果按18位且7-14位为日期进行校验，有可能拦住部分用户注册，导致用户注册失败。因此，在类似的数据校验中，校验规则应当松紧适宜，如果输入要素规则明确，可以适当细化校验规则，在输入的要素规则不明确的前提下，校验规则不应过于具体，以保证数据校验的适当性，避免出现上述问题。
　　以上是我在近期的功能测试工作中遇到的我认为值得分享的事例。测试工作需要我们常常保持警惕，细致耐心完成工作任务，同时，在未完全明确的场景中，充分沟通也是非常重要的，提高事前沟通成本总好过大量精力花在时候修改上，沟通成本并不会减少，还要承担重复劳动修改代码的成本。