软件测试的培训课件.ppt

* 系统测试 当软件开发完毕后，需要进行全面的系统测试。系统测试采用黑盒测方式，其目的是检查系统是否符合软件需求。系统测试的主要内容有：功能测试、健壮性测试、性能－效率测试、用户界面测试、安全性测试、压力测试、可靠性测试、安装/反安装测试等。为了保证测试的客观性，应当由机构的独立测试小组来执行系统测试。 验收测试 验收测试的内容与系统测试的内容几乎是相同的，主要区别在于测试人员不同。验收测试人员来自于客户方，而系统测试人员则来自于开发方。 难道开发方的测试人员执行的系统测试还不够客观公正吗？非得要请用户重新测试吗？ 这不仅仅是“客观公正”的问题，主要原因如下： （1）首先是“信任”问题。对于合同项目而言，如果测试小组是开发方的人员，客户怎么能够轻易相信“别人”呢? 所以当项目进行系统测试之后，客户再进行验收测试是情理之中的事。否则，那是客户失职。 （2）其次，即使开发方测试人员对天发誓“他们在系统测试时铁面无私、绝无半点虚假”，也不能因此省略客户验收测试。不论是合同项目还是非合同项目，软件的最终用户各色各样（如受教育程度不同、使用习惯不同等等）。测试小组至多能够模仿小部分用户的行为，但并不具有普遍的代表性。 验收测试可以分成两类：Alpha测试和Beta测试。两者的主要区别是测试的场所不同。Alpha测试是指把用户请到开发方的场所来测试，Beta测试是指在一个或多个用户的场所进行测测试。 Alpha测试的环境是受开发方控制的，用户的数量相对比较少，时间比较集中。而Beta测试的环境是不受开发方控制的，谁也不知道用户如何折磨软件，用户数量相对比较多，时间不集中。一般地，Alpha测试先于Beta测试执行。通用的软件产品需要较大规模的Beta测试，测试周期比较长。如果产品通过了Beta测试，那么就可以正式发行了。 如果是合同项目，应当在合同中说明验收测试是Alpha测试还是Beta测试，或者两个都要。 * 回归测试不象单元测试、集成测试、系统测试、验收测试那样能划分出清晰的阶段，实事上每一阶段的测试都可能附带回归测试。所以任何测试文档都必须纳入配置管理系统，否则弄丢了就没法进行“回归”测试。 回归测试没有新花样，其特点就是“重复”，让人厌烦。最笨的回归测试就是老老实实地从头到尾把上一次测试工作重复一遍。直觉告诉我们，这样的测试浪费太大，实在不值得。我们期望的是：找出“需且必需”回归测试的那个子集，使回归测试的代价降到最低。这种本事只能意会不可言传，难以写出操作规则来。 既然回归测试没有创新之处，最好设法使其自动化地执行，这样省时省力又免得遗漏。回归测试是自动化测试的一个重点研究对象，目前市场上有一些专用的回归测试工具。 * 只有开发人员最了解自己的程序，那么让开发人员测试自己的程序不是顺理成章的事情吗？ 必须先解开这个疑问，我们才能合理地组织测试队伍。 * 公司内部对产品的测试，最好是开发小组与独立测试小组共同参与。独立测试小组适合于从事黑盒测试，能保证测试的客观性，但他们通常缺乏白盒测试的能力。开发小组适合于从事白盒测试，因为他们最了解软件的内部结构。为了避免“心理作怪”，在进行白盒测试时，应当让开发小组的成员相互测试对方的程序。 * 据调查，对于大多数软件产品而言，用于测试与改错的时间一般会占软件开发周期的30%，这是一笔很大的花费。由于测试并没有为产品增加功能或添加特色，那么大的开销实在让人心疼。企业应当设法制定一些有效的策略来降低测试的代价。设想如果能把“30%”压缩至“10%”，真的可以榨出很多油水来！ 一些指导方针 （1）不论是开发人员还是独立测试人员，都应当对他们进行必要的测试技能培训。这样可以提高他们的工作效率。注意，很多开发人员并不懂得如何测试，出于本能的测试通常是低效率的。 （2）测试必须有计划，不可以胡乱测试。否则东测一下，西测一下，漏洞百出。 （3）测试过程中产生的所有文档，如测试计划、测试用例、测试报告、改错记录等等，必须纳入配置管理系统。 （4）在白盒测试之前，应当先进行代码审查，这样可以降低白盒测试的代价。 （5）对测试工作进行必要的审查，可由质量保证人员监督，防止测试流于形式。 如何合理地减少测试工作量 航空航天、武器、金融等领域的软件系统，要么性命攸关要么涉及重大财产。这类软件系统的质量重于“泰山”，因此对测试要求非常严格。有时对测试的投入甚至比对开发的投入还要高。之所以能这样做，一是值得，二是花费得起（有足够的经费和时间）。可是这样的系统毕竟是少数。 对于一般性的软件系统而言，开发商对测试的投入是有限度的。如果测试的代价过高，导致产品的利润低微甚至赔本，开发商绝对不会干这样“吃力不讨好”的事情。所以降低软件测试