测试用例的编写——当别人不愿意编写测试用例，甚至觉得编写用例是浪费时间时，倘若你体会到了用例编写在测试过程中带来的功能点覆盖的全面性。那么你就站在了比他人更高的高度。细到用例的每条，当别人只是简单的划分出这是某个测试点，而你已经清晰的知道这个测试点是使用什么方法划分出来的测试点-例如边界值，等价类，因果图。那么你的确要比那些简单罗列测试点的人技能上要更高一些。当别人还因为测试功能点未全面，而在赶工期忙碌时，倘若你能够很坦然的根据自己的测试用例通过率确定已测试功能的质量时，你就会知道你站在了更高的台阶上。这些都是理论，测试用例要写的好，要覆盖面全，那是需要思考的，是绝对全心投入的思考。是一种创作，不是你拷贝策划案里的条目就能够理清的。而是通过把策划案中的功能点不断的划分，直至精确到某个输入和输出结果。这是一个急需要脑力劳动的过程，一方面要肯定策划案中的正确的内容，另外一方面要考虑这些正常的内容是否存在何种异常的操作，而任何一个异常的内容都是不允许没有输出结果的。
测试的执行——不是所有的用例都会精确到点击鼠标左右键。所以测试执行的速度反应着一个测试人员基本功的扎实程度。同样是一个功能我们会发现，熟悉系统的测试人员在执行测试过程中往往比不熟悉系统的测试人员快。但是不熟悉系统本身就是测试人员自身的素质问题。没有任何借口，既然你是做这个的，那么允许你开始的懵懂，却不允许你一而再，再而三的愚蠢。想要比别人突出，那么好好熟悉你得系统，最好做到别人知道的你清楚，别人不知道的你知道。
bug的上报——其实就是把bug的出现方法和具体出现导致的问题说清楚的过程。语言要简洁，但是不能简洁到别人看不懂。要步骤分明，要在执行测试过程中不断尝试，直至把bug的重现过程缩短到最短。可能会浪费你很多时间，但是你要看到这个的另外一个好处。当别的测试员跟程序人员重现bug，总是找不到重点步骤时，你已经深刻理解到要获得程序人员的重视，bug的步骤越短，越是能够得到程序人员的赞许。这个赞许积蓄到一定时间就成了你自负的资本。测试结果的汇报也很重要，清晰而明了的告诉程序人员或者测试主管，用例的执行情况，需要解决的问题-最好指出你问题在用例内的出处。这样有便于程序人员养成查看你用例的习惯。一般用例生成和程序实现是同步进行的，在这个过程中，如果程序人员发现你用例内有的测试点而自己没有实现，那么可以节省很多时间。当他多次出现你用例有的内容，他没有实现到时这种深刻的记忆将驱使他检查你的用例。
测试时间点的把控——根据测试用例中测试点的执行难易程序，以及测试用例中测试点的条数可以初步判定功能点的测试完成时间。最初这个是需要积累的，当用例达到某个数量，当用例难度与其它用例执行难度可进行比较时就很容易把控时间点。最好的时间把控不是预期3天而实际只测试1天半，也不是预期3天实际测试了5天。最好的时间点应该控制在半个工作日内。测试点的时间把控对于测试人员来说也很重要。有时如果为了进度需要宁可多几个人一起来完成测试，也不可以因为时间点的问题导致版本发布延迟。
另，以上纯属个人闲暇时间的总结，不具有参考价值。有兴趣的朋友可以看下，觉得说的不好的也言论自由。但是拒绝个人人身攻击。毕竟这里写这个的也是新手，段段两年测龄，打击新人的积极性的话，不算用以让自己看起来很自负的好方法。
文章来源于领测软件测试网 https://www.ltesting.net/
