2010软考软件评测师对测试的重新认识和感悟

　　为什么要选择软件测试”并非出身名校的我，每每在面试中面临着个问题时，总是觉得百感交集。测试对我就如同我历经的求职过程——痛苦并快乐着。在品味它的过程中，我彷徨，迷茫，经历着感情的低潮，这个过程不会很快乐，甚至是痛苦。同样品味测试，有人拿驾驭它易如反掌折枝，不费吹灰之力;有人虽历经波折，但最后总算苦尽甘来，尝到“拥有”的甜美果实;但也有人即便吃尽苦中苦、用尽千方百计，终了却仍与“它”擦身而过。结果永远难以预测，我渴望快乐，那就要蜕变，意味着要经历痛苦而漫长的磨练，意味着所有的一切都将从头开始，一切都将变的陌生，但如果蜕变成功，那一刻就如同蝴蝶破茧而出的那一瞬间，美丽却又让人感动。一直以来对测试的认识存在误区，认为测试的目标和价值就是在黑盒测试活动中找bug，但当测试经验的逐渐的积累，重新回头再重新审视测试，发现我所理解的测试逐渐浮现出它自身的价值，在这里我对自己的感悟和理解做了一个梳理，有不完整和理解不正确的地方，希望大家多多指教。

　　测试=重复+枯燥

　　也许我要讲测试不过是每天重复一些操作来发现Bug(错误)。事实的确如此，哪怕是非常热爱这项职业的人也承认它的枯燥。测试它是机械、枯燥、重复的过程，尤其是在项目接近尾声的时候，修改测试，再修改再测试，像无法摆脱的轮回，有时候更像是一场与开发组不间断的战争，不过，摒弃枯燥的外衣，测试本身有它的价值所在，它更让人能从用户的角度来考虑问题，更能深入了解程序开发过程中可能出现的问题，尽管可能一整天都为了一个很小的问题“循规蹈矩”地反复测试并撰写测试文档，这样的重复将会是重要的积累。我喜欢新东方学校的徐小平新书《骑驴找马》中的一句话：“重复做汉堡，就是麦当劳;重复煮咖啡，就是星巴克;重复教托福，就是俞敏洪;重复做好事，就是活雷锋。”工作本身的满足也是来自于填补缺陷，测试亦是如此。

　　其实在现实的软件测试环境中，没有两条测试路径是完全相同的，没有测试是可以精确的重复执行，就好像你不能精确的沿着你的足迹往回走，你可以很接近，但你总会有一点偏移。所以你无法确保其中某些因素会影响你下次的测试，重复测试也其实只是重复其它测试的某些方面，在以下某些方面重复的测试是非常有必要的：

　　1.重试：当你不确定一个测试在其它的时候是否被正确的执行时，这种情况的一种处理方法就是让几个测试员沿着同样的测试说明执行测试，检查他们是否得到相同的结果。

　　2.改变：当开发修改了一个测试中的重要部分，但同时保持其它部分不变时，即使这个测试的一部分元素是保持不变的，但对整个测试来说，它是新的，并且可能会引发新的行为。之所以会对一个测试作改变，那是因为虽然之前的测试涵盖了某些方面，但涵盖的范围还不足够。这个时候需要重复测试。

　　3.重要性：当可以通过重复测试发生的问题可能比其它检测出来的问题更重要时，产品行为的重要性的结果是不一样的，有时一个特殊的问题或者只要影响用户一次就可能被认为难以接受的(“决不允许再次发生”的情况)。这并不意味着需要执行完全相同的测试，只要重复的测试包含可检测出问题的足够相似的元素就可以了(查看改变部分)。

　　4.旧问题：原有的问题在原有的环境中已经解决，但是将其应用到新的环境中时，然后会偶现，这是需要在新的环境中重复的测试。

　　测试= 没有技术含量

　　踏上测试这条路的人何止千万，但是不同的人对这个行业有不同的感叹。有人叹息成长为测试的高手犹如星星之火，难以燎原，有人在唏嘘，测试毫无技术含量，也有人感叹因为目的不同而踏入测试道路的人们，经过实践的历练，岁月的打磨，会有那么多不一样的结果。

　　其实软件测试并不是简单，虽然它所进行的主要工作就是在软件开发过程中的排错。但是这种排错的工作却并非像我作为新人初涉入这个行业所了解那样，仅仅是一个寻找bug的工作，任何人，都能找到出来，区别在于，熟手找到的速度和数量大于生手而已。它的根本原则是站在客户/终端用户的角度上来衡量和评价软件产品的质量。如果不清楚客户真正的需求，那么我们的工作也只不过是机械的劳作而已。我们需要将需求分解为可测的功能点，并且根据自己的思维去想，在有限的测试时间内，如何设计测试用例，能够保证最佳有效的测试覆盖，检测出软件产品中的种种功能及性能隐患。在这个过程中我们就像在掘宝，宝藏隐藏的越深，条件越复杂，级别越高，找到后，就会越开心。

　　如何完全界定有没有技术含量，我也说不好，但是我认为对测试悟得越透，经验越多，测试也就会做得越好，取得成效越好，从这个角度上讲，测试是很需要能力的，这种能力我们也可以理解成“技术含量 ”， 在软件开发过程中测试人员不仅需要具备技术能力，还需要具备沟通能力，怀疑精神，极强的洞察力，耐心，甚至是幽默感(在遇到狡辩的情况下，幽默的批评是很有帮助的)。所以所谓的技术含量在某种程度上并不完全是纯粹的技术，更多时候是测试人员本身的素质。

　　测试+开发 = 不可调和的矛盾

　　在好的项目组中，和谐的测试和开发犹如一对好的矛和盾，相互制约又相互协调，在求职面试时，经常会遇到一个相同的问题，在测试项目或者产品的过程如何协调与开发人员的关系，即如何处理工作性质所带来的开发和测试的矛盾。刚涉足测试时，我不能很好的体会到这种矛盾，只能浅层的想象测试是挑开发的毛病，开发当然也不乐意老让人挑毛病，所以就有了矛盾。之后翻阅一些书籍，里面谈到测试和开发的协调需要上升到一定的高度，即“双赢”，就是大家共同的目标是一致的，就是维护好整个项目让客户打到最佳满意度，这样会这很大程度上避免一些“冲突”，实现工作中的双赢，理论上这是个很好很和谐的概念，这样回答面试官不加分也不至于扣分。

　　但是在实际操作中，很多现实因素会制约这种思想，比如其一：大家为了减少项目出错的风险，卯足了劲去查bug，免不了有钻牛角尖的情况发生，再要是同时开发人员会将bug的数量作为其考核的标准，那么测试和开发之间的“硝烟”是终日挥散不去的。其二：测试和开发获取的信息的不平等抑或不一致，由于开发人员在整个项目开发过程中获取的需求信息，需求变得信息，项目流程信息等比测试人员更广泛或者时间上更快捷，导致与最终测试人员的思想不一致而产生一些错报或者漏报的bug，倘若再加上沟通不善，会对整个项目进度和流程产生很大的影响;信息不一致则是开发和测试在理解需求上产生分歧，从需求阶段就产生矛盾势必会满意至编码阶段和测试阶段，解决这样的矛盾的结果就是拖延项目的进度。

　　测试如矛，开发如盾，在初期，矛若知道盾之强弱，便可及时修补其弱点，那么这就首先要求开发和测试从项目出去就需要保持一个一致的状态，无论从需求信息，需求变更信息，风险信息，技术瓶颈信息，项目难度信息，都需要保持同等及时的认知，这就需要测试和开发人员相互沟通得当及时。其次在处理bug的问题上，好习惯的测试人员会在开发之前撰写case阶段就根据自身经验预测开发人员容易忽视的逻辑从而预先告知防止错漏的发生。其三，对于bug的分析和争议，测试人员应该多从用户的可重现性，bug的风险性，解决bug所需要的时间和价值性价比等方面共同商榷，最后定夺一个处理bug的最佳方案，一个被提出的bug也并非只有解决，不解决和无效者几种状态，可以根据整个项目的情况来定夺它，目前不解决也不一定是永远都不解决，最重要的是它对产品的影响力和投入的估计要得当适合，才能查出一个高性价比的产品，最终获得收益的最大化，同时开发和测试也获得了双赢的局面。

　　以子之矛，攻子之盾，在古代或许是绝对的对立，但是对于测试和开发谁说一支好的矛一定要攻破盾，一支好的盾一定抵御得了任何矛，好的矛与好的盾，不断的磨合和进步，终有一天会默契得强过任何矛盾，所向披靡。

　　我的测试 == 痛&&快乐

　　我的第一份实习工作是在一个外企做黑盒WEBGUI测试。刚刚进入软件测试的我那个时候对软件测试也一无所知，甚至一开始我的职位都是：测试执行人员。跟我一起奋斗的同伴们，每天都在不断的自我抱怨中拿着那些别人写好的测试用例，一遍一遍在同一个页面上重复的点击某个按钮。大家都似乎认同一个道理：这就算测试运行自己写或者别人写的case，机械的像在碰运气一样的去寻找或许存在的bug。

　　我曾在心里质疑过自己的选择，但是我最终还是觉得，即便是在这样的环境里面，我能学到应该不止这些。我能做的应该也不止这样，否则我的路在哪里人无法预料未来，只能把握现在。如果你想未来能走得更远，更宽，那么今天就一定要努力。这也是我当时想的，并且努力去做的。其实喜欢与否，有的时候也在于你是否有兴趣去探求，去思考和了解这个行业里面的浮在表面之外那些东西。不了解，就很难喜欢，不喜欢，又有什么机会会因为兴趣而去努力呢或许，世界本来就是不公平的，在某些人的眼中，看别人潇洒的谈笑，自己却要如此艰涩的生活着;或许，世界本来就是公平的，你善待了你的生命，虔诚的为了自己的理想去努力，即使不能硕果累累，取得的成绩可圈可点，对于我的人生，痛并快乐着，这就已经足够。