本故事纯属虚构，如有雷同，纯属巧合
今天是大毛入职的第一天。
糊里糊涂的办完入职手续，装好系统和软件，连水都没喝上一口，领导的邮件就来了。
“新员工须知的技术文档放在……，我需要你今天执行完这些测试用例，它们放在……，执行完了把结果写成邮件汇 给我，今天下午5点之前完成。”
啥是测试我都没完全搞清楚呢。大毛叹了口气，该干嘛干嘛去了。
问东问西弄明白了流程，大毛如同机器人一样执行了近500个测试用例之后，总算在时限之前完成第一天的任务，禁不住想，“今后的每天都将如此吗
大毛之所以成为测试人员，完全是因为得到了一个面试评价：计算机技术尚可，编程一般，算法不太熟，不如去看看测试行不行吧。
想起就有气，难不成测试是个垃圾篮，残次品都往里放来着/span>
一个星期之后大毛更来气了，测试用例设计得并不合理，浪费了他不少时间。周五找领导谈话的时候大毛抱怨了一通。
领导仿佛看出了他的心思，说，
“作为新人，进入角色比完成任务更重要。”
大毛一呆，刚想说话，领导先一步发问，
“如果你来设计测试用例，你会怎样设计呢
大毛又是一呆，他来谈话之前并没有考虑到这个。
一个星期之后，大毛又找领导，这次他滔滔不绝的说哪些地方设计得不合理，怎样设计会更好。
领导笑了一下，问道，
“你是通过什么途径发现这些地方设计得不合理的呢
大毛想，这不是废话吗，我对着这堆测试用例郁闷了俩星期呢。
还没回答，领导就替他回答了。
“你亲身体验了执行测试用例的过程并了解其中的问题，所以你能发现解决的办法。”
“对。”
“那么这种经验比起执行500个测试用例的任务来说，哪个更有价值
大毛陷入了沉思，领导拍拍他的肩膀，
“亏不能白吃，也不能让同事吃。”
又一个星期之后，大毛给领导递交了一份完整的 告。
“编 ……的测试用例可以合并，准备和清理环境的工作是一致的；
“编 ……的测试用例的目的相互交叉且重合，应该分离成独立的类别；
“编 ……的测试用例使用过于复杂的数据，其实可以用简单且等效的数据；
“编 ……的测试用例不需要这么频繁的执行，完全可以两个月才执行一次；
“编 ……的测试用例压根就设计错了，不通过的时候其实不是缺陷……”
领导看完给大毛拟了个邮件的草稿，让他把这个 告发给整个测试团队，然后跟他说，
“以后你就维护这500个测试用例吧，有什么增删改归你负责，不用你来执行了。”
文章知识点与官方知识档案匹配，可进一步学习相关知识算法技能树首页概览33838 人正在系统学习中
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！