一根筋

        继上次神经质的故事再说说偶一根筋的故事，一根筋也有个很好听的解释叫做 坚持，也有不好的说法叫顽固不化。

        当然我们都希望能做到美好的一面，会要求自己 坚持得要有尺度，以免变成不通情理、不识大局的家伙，但这个边界线如何把握呢？

        说说偶们滴项目吧，项目功能非常简单，根据卖家的id mod 32的值作为分表ID， 把相应卖家的交易数据放入对应的32张备份表里，再观察后续所有交易操作的备份情况。
项目环境、日常环境我们都特意从用户表中搜到mod32后各个取值的用户帐号，来观察各种备份数据的正确性。执行过程非常顺利，每一个细小点我们都已经校验到位，很自信的面对预发的到来。
预发过程中因为测试人员无法操作数据库，只能获取到页面卖家NICK和交易号，然后提交给DBA去校验，当时DBA用了select count(*) from..的SQL去校验，这只能看该分库表有没有数据插入，但并不能校验插入的数据是否正确。

        当时出于偶的一根筋作祟，跟PM提出进一步要求，应该继续核对表里的信息，PM缘自DBA的自信拒绝了偶的要求，表明入库就行，没有必要再进一步校验。当时偶怕自己滴一根筋会处于边界线的另一端–顽固不化，必竟考虑到前期我们已经经过非常充分的测试，故 妥协了，同意了这样的校验操作。所以顺利的进入了正式发布。一发布就发现入库数据全部错误，DBA拿了交易ID取了模。虽然说最后责任定位并非在测试，PM和DBA也已主动承担了错误，但作为测试人员，也该检讨，因为我们没有坚持。

        这又让偶想起了另外一件事情，这事我也跟新来的同事们分享过：交易列表里有个商品图片无论如何就是显示不出来，但商品详情页面或在其它地方显示就是正确的，找开发定位原因，无果。临近测试结束时间还未解决，找项目经理，他查寻了一番，说是数据问题，说发布到线上不会有问题。这种说法相信大多人也无法接受，但可能会出于PM的身份，而听从了他，就此罢手。但当时偶的一根筋又不知怎滴触发了，找了位技术专家来确定，在他分析确定后是项目中的图片地址引用都是错误的，套用了旧的地址。此时偶是庆幸当初的坚持的。

        对于坚持亦或妥协，偶无法给出很确定的说法，在此跟大家分享偶滴故事，希望大家日后能识别出自己所要坚持的立场。