《软件测试》书评

可能看软件测试视频更好一点

可能看软件测试视频更好一点 大家可以加群 333782754 更容易理解 有软件测试视频还有公开课 看书的话容易犯困 哈哈哈书的内容比较简单，适合入门的人对软件测试有个理论的认识。语言也不太枯燥，是难得一本让我看完整的书，可能是因为书也不厚的关系

入门的可以看一看

如果之前对软件测试基本没有概念可以看看这本书，这本书有很多形象的比喻可以帮助想了解软件测试的读者形成一个基本的理念。但是这本书对很多的东西都是点到为止，没有什么深入的方法和实践，不介绍软件测试的工具。

学校教材

学校用到的第一本外国人编的教材，还没开始看。看评价貌似是本还不错，但是很基础的书。不过学校能选这本看来还是挺靠谱的，用鼻子想它也必然比我们学校老师编的好，应该值得满足了。这本书显然比较基础，这也是很可贵的一点，那些比砖头还厚的书一般都只能作词典来用了，所谓入门有时真的不那么容易。能够把这本书真正看懂，与我这入门者该是不错的选择，学校的教条法则是否会埋没这书的价值还不清楚。很多教材都是看一遍都很累的，当然所有编程书看的都不轻松，如果有机会买到这本书，那就买吧，入门者，快速把它看看，然后再找本难些的。

飞鸟一般掠过：读《软件测试》有感

前一段时间和公司的一些同事聊软件测试，推荐我阅读两本书。这本是其中之一。看起来，这本书似乎已经成为软件测试入门的经典。刚刚看完，我认为作者似乎是想涉及到软件测试的每一个领域，但是却并不想执着于细节，目的是给读者一个全局观，像飞鸟一样翱翔在软件测试的天空。其中的大部分章节都可以细化成为一本书，因此如果需要针对某一个部分仔细钻研，可以寻找专门的书籍来读。作为阅读这部书的副产品，我绘制了一张知识结构图。似乎豆瓣网不能上传图片，所以如果您感兴趣的话，可以通过下面的链接获得我制作的脑图。http://p.blog.csdn.net/images/p_blog_csdn_net/yinhongquan/EntryImages/20090702/软件测试.png

听说软件测试活少钱多离家近

2015年股市很火爆，互联网金融揭竿而起，软件测试与开发也受到众多想跨行业工作者的喜爱，众所周知，软件行业工资高于平均薪资水平。最近有朋友和网友向我咨询软件测试的事情，大意是：小白如何入门软件测试行业，且听我说。我从事软件测试行业整整5年，先说点我的测试经历，让大家对软件测试有些认识，其次说说小白如何跨行从事软件测试，最后推荐些软件测试方面的书。NO.1我的软件测试经验作为一枚女汉子，大学学计算机科学与技术专业也是十分痛苦的，刚入学就学习C++，老师口中各种鸟语，听不懂啊毕业找工作肿么办，就这么糊里糊涂的学了3年的计算机语言c++、java、c#、oracle数据库、linux操作系统，时刻担心毕业=失业。害怕大四找不到工作，我在大三暑假就开始准备实习，留意教务处发布的各公司实习岗位；刚好A公司来校宣传找实习生，A公司主要做银行系统，招测试与开发，听说测试门槛低，逻辑思维有条理、能看懂代码就可以。第二天直接去参观公司并且报名考试（2011年各种城镇银行成立，公司大量缺人手，招聘了大量物美价廉的学生），下午公司打电话说我通过了，明天开始实习培训。由于态度积极主动（面试人员之后说的），实习了几天就进入了项目组实习--银行系统；从实习到转正一路走来累啊，学校学习的只是很基础的知识，工作中远远不够。城镇银行--麻雀虽小五脏俱全，学习了业务：存款、贷款、卡、大小额支付、票据、中间业务、网银、信用卡等；工作中需要搞配置库svn、缺陷管理工具qc、部署版本、操作数据库、linux系统命令、重现生产bug等。当时这个公司开发人员很忙，测试人员测试出bug，首先得自己对照需求，看日志定位，然后找开发解决。非常感谢当时的师傅领我入门。别人的大四在宿舍睡觉、看电视剧、打游戏，而我每天7点起床倒2趟公交车去实习，现在想想当时真的很拼，每天累的焦头烂额，一脸痘，但是很值。由于在这个公司学到很多技能，2013年通过了北京一家大行的面试（大行--人员外包），区别与项目外包，一会给大家解释）。大行工作内容如下：评审文档：大行文档超级多很细，比如：需求说明文档、设计说明书、组建设计说明书、动不动就上千页。刚开始评审各种文档，其实就是找某些功能描述模糊不清或多种描述的，然后整理成excel和需求人员确认。web界面测试：类似与银行的网银系统，点击系统，如有报错直接丢给开发，测试人员只需要描述错误即可。看不到数据库、看不到后台、看不到报错日志，每天汇总案例执行个数和bug测试情况，天天整理一堆excel文档，时间久了会感觉自己像机器人，没有激情。很多时候在大行恨不得一份工作5个人来干，每天很闲，姐姐还很年轻好不好，需要工作带来的成就感，想看代码、想了解单元测试、性能测试、linux、数据库，身边的同事各种跳槽（人员外包没出息啊，随时换工作地点、不让玩手机、不让干这不让干那、跳槽加薪啊）憋屈，姐下决心辞职不干了---ByeBye‘A’公司。2014年5月换到了B公司，项目外包--理财系统，公司有自己的产品（理财、基金、支付、P2P）项目经理很nice、主管也很nice；理财之前没有一点基础，从头学起（和比我早到1月的实施美女共同学习，成长蛮快的），也和业务人员经常打交道，学到很多。第一次用loadrunner做性能测试加班到凌晨2点，这是平身第一次啊，实体环境中调通了脚本并且跑起来了，明白了性能测试场景设计、TPS、通过事务数、最大并发用户数等，了解了性能瓶颈如：查询耗时、实时写日志、缺少索引、硬盘等；最近在配合各个渠道做测试，理财处于中间系统，接一堆外围渠道，宝宝心里苦。我的测试经历讲完了，想必大家已经了解了从事软件测试需要的一些基本技能。NO.2软件测试人员的工作地点以我现在的公司为例，公司分为产品部、实施部、测试部等；产品部人员一般在自己家公司工作，有时候会出差到现场去解决问题，自己家公司环境好、自由，公司有微波炉、下午茶、水果等。实施部人员一般在客户现场做实施（公司把理财产品卖给客户，需要实施维护），现场工作的宗旨是：客户虐我千百遍，我待客户如初恋。客户会不定期有个性需求，实施人员维护。环境一般般，在现场就会有银行的人管着。测试部：有的在公司做产品测试、有的在客户现场做测试，比如我在客户现场，科技部人都还不错，相处蛮愉快的。软件测试工作性质分3种:1、找个非外包公司，公司自己给自己做项目，比如链家app等，人员很和谐，在自己家公司做项目很幸福。2、进入大点的公司，做项目外包，项目外包对测试人员较严格，功能测试、性能测试都得会，人员比例：10个开发1个测试。3、刚培训完人员外包，有些公司专卖人员，某些银行给价2.5万每人月，公司横竖都是赚。缺点：人员管理松散，找不到组织。NO.3软件测试入门如果你身处北上深，想跨行做软件测试，前途还是很光明的，这些城市需求多，提升很快，尤其是越来越多的创业公司，找工作不难。如果你身处某些二线城市，尤其是平均工资较低的情况，不建议转行做软件测试，大家转行是为了挣钱，除非你学习后想去北上深发展或是特别爱好。1、如果你的亲人在做软件测试，这是个特别好的资源，买本软件测试的书籍，让他教你；他个人电脑里会有他公司的资料需求、设计文档、测试案例、被测系统、数据库等，利用周末时间在家教，先看需求了解业务--找出测试点-写案例，然后自己跑系统。之后教数据库的增删改查语句以及一些简单的linux操作命令。我同事利用周末时间已经把他弟弟、他女朋友都培训成了软件测试人员，现在工资相当不菲。2、培训班众所周知，培训班费用很高，如果你学过c语言，了解软件开发与测试流程，就自己买本书多看，网上关于软件测试的资源很多，多看，多投简历，必定会找到份工作。如果你是其他专业毕业，对计算机软件一点都不了解，那就可以考虑报培训班学习，至于报哪个班，大家上网自行搜索，最好去知乎找答案，满满的都是干货。3、工作态度：跨行业进入软件测试，隔行如隔山，想必大家都会珍惜这份来之不易的工作，首先端正态度入职新人都会有老员工带着，一般公司都有配置库，里面有各种文档，测试案例、测试bug文档等；多看测试文档、你的师傅加班时你就在旁边看着帮助他干点零碎活，很快熟络之后工作中遇到问题也会积极帮助你，不懂就要问，多问多思考，最好和他要套测试环境，自己跑案例，遇到问题多记录。微软的OneNote很好用，记录问题可以分各个页签。NO.4测试流程1、需求分析需求分析是软件工程中的一个关键过程，只有吃透需求，后续工作才能得以开展。每次有新需求要求参与讨论，否则后期测试各种疑问（测试人员和开发人员思考问题角度不同），讨论时记录关键点，整理在OneNote里，以便日后查看。2、写测试案例如：地铁里的自动贩卖机，提炼测试点，然后写测试案例；有效的等价类有：金额正好，顺利出货金额超出，找零出货金额不足，提示，并吐出货币金额足够，取消交易假币，吐出无效等价类：放入金额，不出货，不找零放入金额，不出货，退钱金额超出，出货，不找零金额超出，不出货，找零金额不足，出货，找零金额不足，出货，不找零金额不足，不出货，不退钱金额正好，不出货，退钱金额正好，出货，找零金额正好，不出货，找零不投金额，直接出货测试案例设计有很多种方法，大家可以看书学习。3、执行测试案例把2的测试点，完全形成文档，在测试环境执行每条案例。4、测试bug追踪测试过程中难免会出现bug，如果有bug先自己对照着需求自查，看日志，确认无误，找开发人员看代码，记录测出的bug，实时更新bug状态；5、写测试报告主要写测试背景、测试目标、测试案例覆盖率、测试周期、测试bug修复率等。NO.5测试书籍《软件测试 原书第二版》老外写的，佩螣译，机械工业出版社 ，实习时培训老师介绍的，众多测试书中最好的一本入门书，此书浅显易懂，很全面的讲解 ，适合软件测试入门的同学学习，我也会经常翻阅。《软件性能测试过程详解与案例剖析(第2版)》段念，清华大学出版社，想学性能测试，然后百度搜索的答案，买了这本书，真的很不错；银行业务数据量大所以需要压力，第一次做看的这本书，加班到凌晨2点，终于成功了，内容丰富，有大量的案例供大家参考，每次做性能测试，都会看，每次都有不同的收获。《Google软件测试之道》老外写的，人民邮电出版社，未来是软件测试开发工程师（SET）的天下，抓紧时间学点开发知识。《探索式软件测试》老外写的，清华大学出版社，如果你抱着未来手工测试人员会消失，不妨看看这本探索式测试。题外：虽然软件测试人员有时会被开发人员鄙视，但是没有测试过的程序他敢上生产？bug一堆一堆的，做测试很好，未来测试会越来越被重视的！！！欢迎大家围观创建于 11:48著作权归作者所有

读书笔记

1. 只有至少满足下列5个规则之一才称发生了一个Bug：（1）软件未实现产品说明书（product specification）要求的功能。（2）软件出现了产品说明书指明不应该出现的错误。（3）软件实现了产品说明书未提到的功能。（4）软件未实现产品说明书虽未明确提及但应该实现的目标。（5）软件难以理解，不易使用，运行缓慢或者--从测试员的角度看--最终用户会认为不好。2. 软件测试员的目标是尽可能早地找出软件缺陷，并确保其得以修复。3. 次边界条件：2的幂，ASCII表等默认值、空白、空值、零值和NULL4. 测试软件兼容性时选择程序的标准：流行程度、年头、类型、生产厂商。5. 优秀UI的7个要素：符合标准和规范、直观、一致、灵活、舒适、正确、实用。6. DREAD Formula：潜在的危害、可反复性、可利用性、受影响的用户、可发现性。7. Beta测试是将软件分发给选定的潜在客户群，让他们在实际环境中使用软件。Beta测试时寻找配置、兼容性和易用性缺陷的好方法，但对寻找普通软件缺陷表现很差。不能依靠Beta测试来代替实际测试。8. 测试计划的目的：规定测试活动的范围、方法、资源和进度；明确正在测试的项目、要测试的特性、要执行的测试任务，每个任务的负责人，以及与计划相关的风险。测试计划的最终目标是交流（而不是记录）软件测试小组的意图、期望，以及对要执行的测试任务的理解。重要的是计划过程，而不是产生的结果文档。产品的质量和可靠性目标必须明确，必须绝对。9. Alpha版本：意在对少数主要客户和市场进行数量有限的分发、用于演示目的的早期版本。10. 报告软件缺陷的基本原则：（1）尽快报告Bug （2）有效描述Bug （3）在报告Bug时不要做评价（4）对Bug跟踪到底，跟踪其生命周期11. 有效描述Bug：（1）短小（2）单一：一个报告只针对一个软件缺陷（3）明显且通用。使用简明易行的步骤来描述发现Bug的过程，分离Bug（4）可再现12. 计划测试用例的4个原则：组织、重复性、跟踪和测试证实。13. 分离和再现Bug（1）不要想当然地接受任何假设，记下所做的每一件事（2）查找时间依赖和竞争条件的问题（3）查找边界条件、内存泄露和数据溢出问题（4）状态缺陷仅在特定的软件状态中显露出来，重要的是事件的次序（5）考虑资源依赖性和内存、网络、硬件共享的相互作用（6）不要忽视硬件14. 严重性：Bug的恶劣程度，当用户碰到该缺陷时影响的可能性和程度1：系统崩溃、数据丢失、数据毁坏、安全性被破坏2：操作性错误、结果错误、功能遗漏3：小问题、拼写错误、UI布局、罕见故障4：建议15：优先级：修复Bug的重要程度和紧迫程度1：立即修复，阻止了进一步测试2：在产品发布前必须修复3：如果时间允许应该修复4：可能会修复，但即使有此Bug产品也能发布16. 常用项目级Bug度量（1）将Bug按发现的功能区域进行划分（2）发现的Bug随时间推移的情况（3）随时间推移累计发现的Bug。Resolved/Fixed Bugs（4）需标明项目的进度和重大事件17. 软件质量保证人员的主要职责是检查和评价当前软件开发的过程，找出改进过程的方法，以达到防止软件缺陷出现的目标。18. 软件测试员不负责软件的质量，质量不是靠测试来解决的。19. 假设自己是客户；像黑客一样考虑问题。20. 产品说明书属性检查清单：完整；准确；精确，不含糊；前后一致；贴切；合理；代码无关；可测试性21. 状态测试的方法：（1）每种状态至少测试一次（2）测试最常见和最普遍的状态转换（3）测试最不常用的分置（4）测试所有错误状态及其返回值（5）测试随机状态转换22. 硬件配置测试：明确与硬件配置有关的特性。软件兼容性测试：测试程序之间不同的数据流动方式。23. 网站测试（1）首先建立状态表，把每个网页当做不同的状态，链接当做状态之间的连接线（2）通过大幅缩放浏览器窗口来检查文字布局问题（3）查找孤页，向网页设计人员索要网页清单24. 半聪明的猴子：记录行为日志，只在被测试软件商运行，具备崩溃辨认能力聪明的猴子：会阅读软件的状态转换图，能够验证遇到的情况。

普普通通

这本书还行，作为初学者，如果想对软件测试有一个全面的了解，不想急于一头跳下去，可以先读读这本书。这本书只讲原理，简单的原理，然而越简单的便是越重要的。不过可能很多人会觉得看了半天原理，没有实作 还是很不爽的感觉。

普普通通

入门书，也就是入门了，一切泛泛而谈，普及概念。少有具体动手的实例，此外感觉知识有点陈旧了，即便是现在常用的一些手段，也没有介绍。看了一半，继续修炼自己的耐心中。。。。。看完了，收获有，但是不是想象中大，他重点介绍测试的各个方面，少有细节。比如如何编写测试用例，如何对一个项目进行实际操作。理论性强，动手细节少。全面，就就是全面的范范而谈了，很多是已经知道了的，毕竟我关心测试也不是一天了。一无所知的初学者可能更合适。倒是书后面列出来了一堆得推荐书列表，可以将来参考一下，进一步学习学习。