测试之美 

测试还是有一点美妙之处的。

一旦你发现它的美，就会忍不住去寻找更多的美，遵循这个规律，你会发现正在做的测试是这样的: 

• 乐趣的
• 有挑战的
• 迷人的
• 需要丰富经验的
• 需要深思熟虑的
• 有价值的

换计划说，测试是美妙的。

 

虽然这本书前言是这样写的，但是很多测试人员觉得自己正在做的测试是这样的：

• 无趣的
• 无聊的
• 枯燥的
• 重复的
• 机械的
• 没有什么价值的
• 没有什么意义的
• 没有领导肯定的
• 没有高收入的
• 发布版本还必须要加班的
• 被认为是没有技术含量的(谁都可以来做测试)
• 。。。

 

第一章 这对你有好处吗? 

读完本文希望能深刻认识测试人员和测试人员的价值, 很多企业的管理者都不尊重测试人员. 

这么说吧，我正在测试现实世界的边界，我好奇将会发生些什么。好奇心，仅此而已。 -Jim Morrison

了解测试人员

测试人员 ： 接受门的培训来发现并报告问题，他们通过发现和报告软件中的异常问题和存在的风险，进而帮助公司、开发团队、客户和最终用户。

测试的质量的决定： 软件的代码 ，测试人员不能决定软件的质量，因为代码是开发人员的写的，大部分测试是黑盒，只能帮助开发团队优化软件的质量，但不管软件质量有多烂，大部分测试人员也无权阻止他们发布

测试人员的角色更多是顾问，而不是质量的把关人和质量的控制人，因为测试不能很好权衡风险，发布的必要性，市场需求和成本开销，评估和承担风险是项目管理层的责任，所以测试人员只是根据出自己的专业知识，发现和报告问题，决策的事情留给别人；

截然相反 ： 有些软件问题让项目经理疲惫不堪，坐立难安，甚至彻夜难眠，但却让测试人员的生活变得兴趣盎然。显而易见，生命使然。

测试人员是IT世界里的”暗黑力量”  　

　　　　测试人员喜欢找缺陷(bug)，越可恶的缺陷测试人员越喜欢，商业的大部分工作都是创造性工作，而测试人员做的却是破坏性工作，发现问题需要直言不讳。遗憾的是测试人员的角色并没有被IT部门的其他成员充分承认、理解和奖励

测试人员拿了工资就是要告诉你，他们所了解的一切事实，甚至有时候会直白的告诉你，你很丑，而且还会给出一系列证据。

测试人员的特质

有好奇心，他们希望弄清楚事物是怎么运行的

喜欢做实验，尝试使用功能的不同场景，不同用户，实验会发生什么

胆子大，测试人员不害怕破坏什么东西，不害怕有什么影响，一定要把发现的问题暴露出来

聪明，善于分析，善于学习，如果没有详细文档，需要分析软件内部实现，问出正确的问题，研究正确的问题，把谜题的各个碎片联系在一起，然后得出正确的结论

经常有人责备测试人员过于直接，粗鲁，团队合作精神不佳等。其实不然，责备他们的人不了解或者没能意识到项目组中的测试人员的角色，他们的工作任务不允许他们隐瞒和很轻易的相信开发的回答；

测试人员不太容易相信别人：就算你告诉测试人员草是绿色的，他们也要亲自看过才能相信（枯草就是是土黄色的，草也可能是任何颜色，还有云是白色的吗，云也可以是红色，黑色 ，....  无言六色,）, 测试人员质疑一切，包括权威。

测试人员的尊重与信任 ： 发现软件中的问题并报告，告诉这他们就是严酷的真相，才能获得他人的尊重和信任；

测试人员的无聊指数

只懂得执行其他人测试想法的人，不能算是一个真正意思上的测试人员，反而会增加工作的无聊指数，真正的测试人员，一定会已有测试的基础上，重新考虑其中的想法，提出问题，充实和改变测试，探究原来的分析没有考虑到的地方；

如果原来的分析确实很棒，那就应该考虑把这些用例做成自动化，不要再考虑做这些事情，让真正的测试人员不要重复运行无聊的用例，这会消耗那些富有创造力，聪明的，勤勉的测试人员的精气神儿，自主性和创造力会消耗殆尽。让测试人员做新鲜的事，发现问题和提高效率(自动化),贡献力量；

测试人员，不团队协作吗？

在态度方面，测试人员不应该团队协作吗？千真万确，测试人员也愿意扮演好团队成员角色，他们是想帮忙做贡献的，他们很希望自己得到欣赏，但是他们关注的东西让项目组其他成员难以接受和欣赏他们的贡献，他们的幽默与乐趣甚至增加了让他们融入团队的难度。更糟糕的是，如果你在一个不关注质量的公司工作，并不认同或不解决测试人员辛辛苦苦发现的问题，测试团队会认为这是对他们和他们的工作缺乏尊重和理解，如果不给予测试人员应得的尊重，很快就会让他们士气低落，然后你就很难留住市场上有能力，有技术的的测试人员。

解决所有问题

当测试人员发现了十几个问题的时候，大多数测试人员希望他们解决所有的问题，更加偏向于解决所有问题all closed，开发人员甚至项目经理，总会用各种理由说服你，他们只解决几个重要问题，其他问题不做处理。测试人员也会慢慢的学乖，不会提一些不重要的问题。。。

测试人员的幽默与乐趣

测试人员的幽默与乐趣，就像开发人员做了一道非常美味的菜，寄给测试人员，测试人员会在这从菜里挑出来很多不能吃的东西或做的非常难吃，然后非常开心的用漂亮盒子和丝带包装好，再给你开发人员寄回去，收到包裹的开发人员甚至都没意识到这一堆不能吃的东西居然是自己做出来的。

测试的意义

从本质上来说，测试的意义就是发现缺陷，测试人员通过向项目组和管理层展示缺陷，问题或瑕疵来 “保证质量” ，进而帮助他们做更好的决策；通过向开发人员展示代码中的错误，使其知错就改，引以为戒，帮助开发改进工作； 测试人员学习心新的策略和技术以便发现更多的问题，归档缺陷，帮助其他人发现缺陷

表面错误

测试人员也非常不愿意发现几百几千个，拼写，样式，显示，颜色，等微不足道的问题？ 从积极角度，易于解决，从项目进度等其他角度来说，没时间修改，从开发角度，不影响功能，开发人员不重视修改。

谁会非常在乎这些表面错误？细节错误？

研究表明：最终用户会对非常微不足道的问题深切关注，样式，颜色 ，拼写错误，这决定用户是不是喜欢这个软件，还有一个被称为“烦恼因素“的东西，这种很小的错误或者反人类操作习惯会非常让人不爽，每天要操作几千次的用户来说，这种小问题，造成的“烦恼因素”非常高，如果发现有更好用的软件，会果断放弃这个让人烦恼的软件，选择新的好用的软件或者系统。这就是为什么项目经常看起来非常微不足道的问题，会成为最终用户的大难题。

什么样的缺陷让测试人员不枉此生？

难以处理的缺陷，会严重影响最终用户的缺陷，会严重影响后续错操作的缺陷，会让程序瘫痪的缺陷，会让开发彻夜加班的缺陷，会让项目经理彻夜难眠的缺陷。

错误的优先级

测试人员报告发现的一切东西，其中经验丰富的测试人员会根据问的的严重程度报告问题有的优先级，一般来说不要根据业务的优先级排序，至于开发决定怎么处理问题和严重程度和业务的优先级，随他们去吧。

测试人员不把问题都报告出来的原因

很多测试人员，并不将发现的所有错误都报告出来。

原因1 ：报告某一种或者某一类错误没有意义，因为反正都不会被解决。项目实践中学来的

原因2： 报告一些问题是“不聪明的”，因为领导不想看到有这么多错误，只报告领导在乎的内容，因为所有问题可能影响绩效，办公室政治

项目管理的"艺术与工艺" : 在产品发布前，对推迟和解决那些缺陷做出正确的决策

总结 ： 测试人员应该报告所有错误，有可能某个错误会改变公司目前 "执行的陈规",  如果产品上线之后，用户也提出很多和测试人员同样的问题，并要求尽快解决，那么开发团队和项目经理就会开始注意这类缺陷，项目经理在产品发布之前，会根据所有的问题，作出正确的决策；

充分的测试

有经验的测试人员知道着力何处，能够指出错误的藏身之处，测试人员会进行充分的测试，在走遍整个测试的迷宫之前是不会认为测试“完成“。

什么意思呢 ？假设开发开发了一段代码，功能是从用户那里搜集信息，处理之后存入数据库，作为一个开发人员，可能只会测试数据读取没有问题，存入数据库也没有问题。

但是提测之后测试人员却发现了37个缺陷？ 可能开发人员只测试了 “好"的数据，并没有测试读取错误数据如何存储，没有时间也没有热情破坏自己写的代码，可能没有充分理解用户怎么对待这些数据，没有正确处理这些数据，可能数据库中的数据不能被其他程序以正确的格式读取，那些交互模块获得的数据之后发现某些字段是空的，所以有很多缺陷；测试人员往往能在系统交互的地方找到错误的藏身之处。

好的测试人员不必试图证明软件运行正常，他们是用来证明软件不能正常运行的。

大部分IT开发人员认为：“是个人就能测试”，不认可软件测试的专业技术，但是他们也不会随便让路人甲来测试。

这对你有好处吗？

如果对测试测试人员报以对开发人员，数据库管理人员等人同样的尊重，就会促进建立一个能吸引人才的测试团队，如果你的职位允许，公平的奖励你的测试团队。“暗黑的力量”，你也需要得力干将，因此你得尽力留住较强的测试力量。如果理解测试人员专业化学习成长要遇到的问题，有好的机会可以安排测试专家或者老师的培训，尽量扩展团队的能力，促进学习的氛围。通过培训，认可和平等的奖励对测试团队表现出重视，会帮助你得到一个肯为你上刀山下火海的测试团队，而且会把你的团队推荐给业界中和他们一样优秀的人才军团，并不需要业界最高的薪资待遇，你就可以保留住精英中的精英。

测试人员会因为推迟交互和代码很烂加班超过500小时，找出1200个错误，其中有40%都严重到搅黄产品发布（实际上测试人员不能决定什么...）  

这对你有好处吗？归根到底，测试对用户，对你的团队，对你的公司，对你的根本利益都是有好处的。