偶发性的缺陷分析（参数格式解析问题）
一、问题描述：
线上环境频发（格式会由yyyymmdd变为yyyy-mm-dd而导致后续代码获取的日期有误，特点：无规律可循、出错时间不固定、出错脚本不固定）格式转化问题，并影响了线上采集的使用。出现问题前后测试的行动：
（1） 我们开展过性能测试并未发现该问题。
（2） 在线上出现该问题后，我们询问了用例出现bug的操作，并尝试在测试环境复现。
（3） 在测试环境再次进行了压测，通过更大并发量并延长并发时间均未复现线上该问题。
二、追根溯源
开发的代码：在函数方法中创建了一个全局变量，在并发的时候同时执行到这段代码的时，会导致该变量被设置的其他格式覆盖到。(静态方法调用中用到了共享变量，多线程并发操作共享变量会出现线程安全问题) 解决方法：不使用共享变量，改用函数内部局部变量。
每次动态参数解析调用均会重复执行红框所示代码，根源调用了addFucntion 非线程安全。
举例：一个工作流中包含两个无依赖关系的jobA、jobB，jobA中设置了日期格式为yyyymmdd，而jobB设置的日期格式为yyyy-mm-dd，但是这种放到map中会因为key值相同，而导致种jobA的格式被jobB格式覆盖。而测试环境的压测因只采用了一种格式因此未复现。
三、启发：
对于测试人员的启发：当出现有这种特性-------无规律可循、出错时间不固定、出错脚本不固定的问题时，第一考虑是由于并发导致值的覆盖问题，为了避免以后这种问题遗漏在线上，需要构造测试场景必须要涵盖的足够的小分支。
那问题来了？如果构造测试场景？我经常有这种疑惑，无论是涉及功能用例或者是性能用例时，什么样的可以归为有效等价类，什么值又应该被分门别类，另做考虑。
这里谈谈经验体会：
1、 场景来源于用户，根据用户的使用习惯尽量精准还原。在性能测试的混合场景中很多时候在请求类型等等方面模拟用户习惯，都是属于比较大的的方面的把控。因此要求我们在设计用例时，更多的落地的实际操作中，设计的每一个变量都进行精准还原，这种情况下，编写脚本所需要的成本会大，需要测试人员根据项目进行粒度的把控。
2、 开发辅助。
设计功能用例及性能用例时，其实在从测试的方面考虑各种场景后，有些是否该分为有效等价类，也需要大致询问开发的代码逻辑，毕竟测试不能尝试去穷举，因此一个好的测试用例的设计，离不开开发的配合，只有这样，在高效迭代中，才可以设计出高效的用例。
从开发的角度来看待这个问题，其实就是在开发过程中格外注意静态变量、静态函数、全局变量这种在并发情况下容易导致非线程安全的问题。
网友评论