软件测试培训基础篇

软件测试的流程,首先，在项目的初期，需要由测试经理或是测试组长根据需求规格说明书或是界面原形来编写测试计划（TestPlan），生成测试计划文档（比较规范的公司一般有需求评审这个过程,测试人员也要参与到其中来）然后，在概要设计和详细设计阶段由测试设计人员根据需求规格说明书、概要设计说明书、详细设计说明书、界面原形、来进行测试设计（TestDesign），主要编写测试用例（TestCase），生成测试用例文档（如果从规范的角度来说测试用例也需要评审）,1,2020/4/30,软件测试的流程,其次，在开发编码的后期，由测试执行人员参考需求规格说明书和测试用例来对系统进行测试，这里面包含单元测试，集成测试和系统测试，这个过程中包含大量的回归测试验证，主要生成大量的缺陷报告最后，在项目后期，由测试经理或是测试组长评估一下测试的过程和结果，为下一阶段或是下一个项目的测试积累一些经验和教训，一般生成一个测试总结报告,2,2020/4/30,一：如何找软件中的Bug,按照作者的观点:凡是不符合用户需求的，或者应用用户使用的、给用户在使用软件过程中造成不便的，都认为它是软件缺陷-话虽然说的有点极端，但是事实就是如此-那么我们作为一名软件测试人员，如何去找到软件中的缺陷Bug呢？,3,2020/4/30,首先：最重要的是业务,（1）首先我们要迅速熟悉公司的产品业务，比如我们公司做ERP软件的，我肯定要迅速熟悉EPR的业务流程；比如我们公司是做法院软件的，那么我一定要熟悉法院在审判案件的流程，只有熟悉了产品的业务流程、那么你发现的软件缺陷才有价值。否则你找到的软件缺陷是纯软件的缺陷、价值不大-什么叫纯软件的缺陷呢？-对于不夜城这样的互联网系统，我们所关注的业务重点在哪里？,4,2020/4/30,其次把自己当成是使用的用户,从用户使用的角度去测试系统，比如用户在使用这个系统过程中是这样操作的吗？这样操作方便吗？比如在大量信息要求用户输入的软件界面中，有一些用户喜欢使用Tab键采用全键盘的输入；此时的接口应该采取从左到右，从上到下的顺序比如有的用户使用快捷键操作等（易用性测试）比如程序激活后，按F1键会出现软件的帮助页面（易用性测试）比如软件在需要用户输入的信息的时候，必填项一律在后面用*表示（必填项为空在处理之前要有相关的提示信息）下拉框不选值的时候，应该选择默认值；并且要多检查程序中的多处下拉框，因为很多情况下下拉框取不到值,5,2020/4/30,善于怀疑,善于怀疑，世界上没有绝对正确的，总有错误的地方，具有叛逆心理，别人认为不可能发生的事，测试人员要认为可能发生。别人认为是对的，我却认为有可能是不对的。如果你认为某个或者某些程序员水平很高，他写的这个地方应该没问题吧，这样很容易遗漏软件中的Bug。因为程序开发人员毕竟是普通的人，只要是人就会犯错误的,6,2020/4/30,不要让程序开发人员的观点：“比如用户不会进行这样的操作”而说服自己,不要让程序开发人员的观点：“比如用户不会进行这样的操作”而说服自己。在这个时候你要坚持你自己正确的想法，以后对方会明白你的。比如在一个录入员工基本信息的系统中，系统中对员工的年龄作为负值、而没有作为判断、也可以保存到数据库中，此时你不要被程序员的用户不会进行这样操作的观点说服自己，你要坚持自己正确的观点-谈一下我自己的亲身经历，比如程序员统计报表的测试-切记！,7,2020/4/30,跟踪一条完整的数据流,在测试的时候要跟踪一条数据的流程,保证数据的正确性这个真的是太重要了：假如我们在测试一个销售的类型的软件的时候：我们应该先做订货-入库-盘点-销售-查询，首先我们要保证这个数据的流向是正确的无误的。假如我们在测试法院的一款软件的时候，你要先收案子-立案子-发送审批-排期-审理审判-结案-判决-归档-查询。总之跟踪一条数据的流程,保证数据的正确性。如果经过我们测试的软件在用户使用过程中业务流程上都走不通的话，那么这样的软件你说经过我们的测试，但是在比人看来与没有测试有什么区别呢？-不夜城网站，怎么跟踪完整的数据流（包括前台和后台如如何跟踪完整的数据流）,8,2020/4/30,程序员提交版本后回归测试,程序员提交新的程序版本后，作为测试人员应该立即与程序员沟通这个修改的功能、并且这个新的修改的功能影响哪些功能举个简单的例子来说明一下：比如在一款软件中，程序开发人员修改了某个会员的某个字段。作为测试人员首先你要测试会员的功能这个是你首先需要做的。另外你还要和程序员沟通咨询他们新修改的这个会员的字段，会影响会员的销售功能吗？会对会员以前的销售记录的查询有影响吗？如果对这些功能有影响，那么这些功能都是你在回归测试的时候重点测试的地方，也是最容易产生Bug的地方了,9,2020/4/30,回归测试需要注意的事项,首先测试经过变更（修改的功能）的部分，然后测试没有变化的部分。修改和更新都意味着新的风险首先测试核心功能，然后测试辅助功能，测试产品所完成的关键和常用功能，测试完产品基本任务的功能（比如我近期测试点法院审判软件，首先一定要保证整个审判的流程能跑通）首先测试能力（功能），然后测试可靠。先测试每个功能是否完全能用，然后在深入检查任何一个功能在很多条件不同条件下的表现如何首先测试常见情况，然后测试少见情况。使用常用的数据和使用场景（比如一款销售类软件先要测试正常的数据能否销售，然后在测试异常的数据比如负数销售）,10,2020/4/30,回归测试需要注意的事项,首先测试常见威胁，然后测试罕见威胁。用最有可能出现的压力和错误情况进行测试首先测试影响大的问题，然后测试影响小的问题。测试在失效的情况下会产生大量破坏的产品部件首先测试最需要的部分，然后测试没有要求的部分，测试对团队其他人有重要意义的任何部分的任何问题（你的测试会影响到其他人其他模块的测试）,11,2020/4/30,软件与使用者的互动缺陷,如填写资料错误应的时候，应该能够提示错误的位置，让用户知道是这个地方输入数据不对删除数据之前给一定要给出是否删除确认提示不要在软件中使用中英文混合的提示比如：比如对于用户某个操作的错误提示，不要一会用“error”、一会用“错误”；一会用“succeed”另一会用“成功”另外要对程序员出现错别字进行检查，比如把“登录”写成“登陆”另外，在软件中不要对用户使用很专业的术语比如“记录”、“字段”等,12,2020/4/30,软件与使用者的互动缺陷,新增/修改信息保存提交后系统给出“保存/提交/修改成功”提示信息，并自动更新显示在用户进行大量的输入后，点击保存按钮，仅仅是因为某个地方的输入选择不正确，点击确定后发现所有的输入的内容都全部被清空了，花费很长时间的输入、仅仅是某个地方的输入不正确，而把该用户的所有输入的其他内容也清空了，假如你是这个软件的使用者、你肯定感觉挺挺恼火的（航班信息填写）,13,2020/4/30,软件边界值的测试,软件边界值的测试：软件最容易在边界值上发生问题了。众所周知软件最容易在边界值上出现问题了，所以作为测试人员一定要在边界值上多测试，比如测试用户输入框中的数值的最大数和最小数，以及为空时的情况软件最容易在边界值上出错误,如果N是一个边界值的话,那么根据边界值的测试法,至少需要测试下面三种情况:N-1,N,N+1举例:在一款法院的管理软件中,年龄是判断犯罪嫌疑人是否承担刑事责任的一个条件,其中16岁就是一个边界值,那么我们可以设计测试用例如下:(1)N-1=15(2)N=16(3)N+1=17,14,2020/4/30,非法容错性测试,非法容错性测试：比如在需要输入数字的地方输入字母,比如：软件在突然断电情况下，比如在输入手机号码的位置，输入汉字，来检验程序的容错性和健壮性在需要输入字母的地方输入数字在需要用户输入的文本框中拷贝字数很多的整篇文章到这里测试看看软件是如何做处理的在需要输入整数的地方输入负数，或者是用鼠标右键或者是Ctr+V形式粘贴负数,15,2020/4/30,关于接口,如果软件不同部分是由多个程序员共同完成的，那么要在他们程序接口相关联的地方多检查，因为有时候在接口的地方，A程序员认为B程序员做了处理；B程序员认为A程序员做了处理；但是事实上他们双方都没有做处理我的亲身经历：曾经做过一款销售类型的软件，A程序员做订货、B程序员做入库，他们每个人的程序都能单独运行，结果集成到一起就出现了错误，这个问题在测试过程中居然没有被发现，在用户的实际使用环境中用户发现报表查询出来的结果不准确，才发现了这个问题,16,2020/4/30,兼容性测试,兼容性检测：测试要在不同的硬件、软件（包括操作系统、IE浏览器、网络带宽）下的测试：有时候软件在配置很高的机器上，有时候会隐瞒一些错误，比如CPU过快的时候，很多东西发现不了特别是对于CS结构的软件比如以前最近测试的一款软件在不同的浏览器下看到的菜单权限不一样，下图中同一个用户再IE6.0和IE7.0下看到的菜单权限不一样（大家可以看一下在IE7.0下明显少了很多东西），这肯定是软件中的一个Bug了,17,2020/4/30,不同的浏览器的兼容性测试,18,2020/4/30,软件在压力之下容易产生错误,软件在压力之下容易产生功能上的错误，作为一个有经验的测试人员，你应该把你的软件在压力之下长时间运行测试，然后看看软件能否在压力之下经的住考验经验1：在“提交订单”、“下订单”、“转立案”那里经常会在多用户使用的情况下产生性能上的问题经验2：在多用户并发销售的情况下，会卖成负的库存,19,2020/4/30,在测试过程中要多看服务器日志,无论是测试B/S或者C/S结构的软件，无论是在做功能测试还是做性能测试的时候一定要多看服务器端的日志文件，举例：（1）比如查看IIS日志，tomcat日志，在日志当中你会发现很多东西。(比如中国软件评测中心遗留下的测试问题的举例)（2）比如在欧莱雅（中国）的service.exe程序的时候，当时测试人员忽略了看日志文件信息，导致欧莱雅的服务器平均每隔2-3天重新启动-这是一个很严重的问题-但是当时测试人员没有发现,20,2020/4/30,对于一些比较成熟的开源框架和技术,对于一些比较成熟的框架和性能一般不会考虑其功能和性能上的问题，比如：ApacheLucene是一个开放源程序的搜寻器引擎，我们一般不会考虑其功能和性能上的问题,21,2020/4/30,随机测