毕业5年多的我，再次回过头来看看刚入行时所写的文章，感概良多。尤其是文章中的第三个小故事，过了这么久依旧可以激励到现在的我，通过自动化的手段减少团队日常测试的时间开销、开发提高团队效率的工具都是目前时常思考的事情。自己也从一个职场新人变成了一个职场老人，虽然很多事情处理得游刃有余，但也存在大量需要学习的东西。保持谦逊，继续前行，也把当时的原文分享到这里吧。
原文如下：
时间从来都是有加速度的，不知不觉已经毕业10个月了，就是说做测试这行也差不多300多天了。我自认为自己算是一个“好总结”的人，虽然离“擅总结”有一定的距离，但还是希望通过我的三则小故事，给新手朋友们帮助，哪怕只是那么微小的一丁点。
1.
那是刚入坑测试的第一个月，萌新到连自己都觉得好笑。有一天，接到一个不紧不急的任务，为某APP写测试用例。
测试用例？我当然知道是什么，但为什么写它和怎么才能写好它这两件事我当时并不知道。心想应该是个随便搞搞就能交差的任务，也没先去理解写用例的意义和实际方法。只知道那如照本宣科般的几大用例设计方法，你在入行前多少也听过，等价类划分法、边界值法、错误推断法、因果图法、判定表驱动法等等，这些也许是你作为应届生搪塞考官的利器。当然，这里我不是想表达这些方法有问题，而是想说当我们真正去设计用例却只知道这写些方法时，会感觉手足无措。
没错，我当时就感觉到手足无措了，并且做了一件自认为有理的事情，去找人要了一份其他APP的用例，我竟然天真的以为那就是完成此任务最重要的东西，觉得那个APP和我要测的APP还是有几分相像，应该可以借鉴。
一天过后，快下班时，老大路过我身旁，很好奇的问我为何看着别的APP用例写自己要测APP的用例，我把我天真的想法告诉了她。结果可想而知，老大对我的印象突然发生了改变，没说太多，只是简单的一句话：“我想你需要去买本书系统的学习测试”，就离开了，眼神是失望的。而后听到她大声与别人议论我：“他表现很差，连需求可能都没理解到位！”
天哪，才刚入职就收到这样的否定，这能忍？于是当天晚上回家就琢磨如何写用例，在各种测试论坛里搜索，发现自己真的是很傻很天真啊，可能在那天以前，都不知道一份好用例代表了什么。所以，为了新手朋友不像那时的我一样，特意总结了下面一段满满的干货送给大家。
测试用例是通过提炼测试点，经过归纳整合及科学的方法设计出来的一个给自己也给他人看的执行文档。其有但不限于以下三种目的：让写测试用例的人能够更加明确需求，对需求的把握更精准；能够让其他测试人员在不看需求时，快速进行测试；反思自己的测试思路，通过用例评审能够了解用例的覆盖情况。设计用例时，需要先通过划分系统模块定好测试点，再次发散测试点，为每个测试点以正向逆向两种思维方式去思考测试步骤，写好每个测试点的具体测试步骤后，还没完事，需要去整合精简用例，免去冗余的步骤，并且反观用例的编写规范问题，包括用例的可读性、可执行性、合理性、颗粒度。每次执行用例时，也需要测试人员理解用例，去思考用例为什么要这样设计，是否还可以补充，并保持观察，不仅要注意实际结果与预期结果是否一致，执行过程中遇到的其他不正常现象也要验证。
2.
下面这个事情依旧发生在我属于新手期的阶段。
有一天，我在项目沟通群里被产品经理叫住，“xx，你过来下，我们看不懂你提的这个BUG”。带着鄙夷的心情我快步走了过去，心想：“这群人，难道连个简单的BUG都看不懂？”过去复现完BUG之后，我表达了我的想法，认为自己简单两句话的BUG描述没有问题，然而产品却和我说，你问问他们（指着程序员）看懂了吗？并且直接跟我说：“描述清楚BUG是测试人员的基本能力！”听到这句话，我的心情久久不能平静，选择不去理论而是默默回到座位上，站在不懂上下文的角度，再次通读了几遍该段BUG描述，原来这段描述确实有几分晦涩难懂，原本以为言简意赅的简短文字原来是那么简陋，简陋到都不能把我想表达的意思完全描述清楚。
你可别笑，上述问题不仅可能发生在新手中，还有可能发生在拥有倦怠心理的老手中。以为自己能够以简单的一句话或者两句话把BUG描述清楚，以为开发者都和自己一样，完全知道BUG出现的环境及操作步骤，其实真相往往并非如此。
所以，在描述BUG时，请不管任务有多繁忙也要竭尽全力把BUG描述清楚，因为提BUG的目的就是让这个BUG被修改，而被修改的前提是别人能够读懂你的描述。我会通过下面两种方法保证我的BUG描述是清晰的：1.每次按照固定的格式去描述BUG，这个固定的格式包括BUG标题、测试环境、复现步骤、异常现象、期望结果。2.描述完BUG之后，不要慌着提交，而是站在小白的角度去通读一遍该段描述，力求能够完全被读懂。
3.
入行时，大多数人都会从手工测试开始做起，这里有个响亮的绰号—“点点点工程师”，使用鼠标或者手指对着屏幕就是点。开始的新鲜感可能会由于日复一日的上述操作而消磨殆尽。不管你以后会不会是，反正我当时是这样的。直到有一天，我看到了下面一则故事，这个故事的名字叫做《九段秘书》。
一段秘书的做法:发通知——用电子邮件或在黑板上发个会议通知，然后准备相关会议用品，并参加会议。
二段秘书的做法:抓落实——发通知之后，再打一通电话与参会的人确认，确保每个人被及时通知到。
三段秘书的做法:重检查——发通知，落实到人后，第二天在会前30分钟提醒与会者参会，确定有没有变动，对临时有急事不能参加会议的人，立即汇报给总经理，保证总经理在会前知悉缺席情况，也给总经理确定缺席的人是否必须参加会议留下时间。
四段秘书的做法:勤准备——发通知，落实到人，会前通知后，去测试可能用到的投影、电脑等工具是否工作正常，并在会议室门上贴上小条:此会议室明天几点到几点有会议，会场安排到哪，桌椅数量够用吗？音响、空调是否正常？白板、笔、纸、本是否充分？我的准备，在物品上，环境上，可以满足开会的需求了吗？
五段秘书的做法:细准备——发通知，落实到人，会前通知，也测试了设备，还先了解这个会议的性质是什么?议题是什么?议程怎么安排，然后给与会者发与这个议题相关的资料，供他们参考(领导通常都是很健忘的，否则就不会经常对过去一些决定了的事，或者记不清的事争吵）。提前的目的是让参会者有备而来，以便大家开会时提高效率。
六段秘书的做法:做记录——发通知，落实到人，会前通知，测试了设备，也提供了相关会议资料，还在会议过程中详细做好会议记录(在得到允许的情况下，做一个录音备份)。
会议开完，就完了吗？会议上大家讨论的问题，做出的承诺，领导的安排，部门之间的配合，都有许多会议的成果，需要有人记录下来。
七段秘书的做法:发记录——会后整理好会议记录(录音)给总经理，然后请示总经理会议内容没有问题后，是否发给参加会议的人员，或者其他人员。要求他们按照执行。
八段秘书的做法:定责任——将会议上确定的各项任务，一对一地落实到相关责任人，然后经当事人确认后，形成书面备忘录，交给总经理与当事人一人一份，以纪要为执行文件，监督，检查执行人的过程结果和最终结果，定期跟踪各项任务的完成情况，并及时汇报总经理。
九段秘书的做法:做流程——把上述过程做成标准化的“会议”流程，让任何一个秘书都可以根据这个流程，复制优秀团队，把会议服务的结果做到九段，形成不依赖于任何人的会议服务体系！
我开始深层次的思考，我现在的工作真的就没有上升空间了吗？我还有哪些地方没有做好，没有做到位？就算做到位了以后，我还能如何拓展强化我的工作？不想不要紧，细思则极恐，原来我还能做balabala...一堆事情去改善自己的工作，完善流程，减少沟通成本，帮助团队更高效的工作。
仅以此文献给或许迷茫但认真的你。