舞台为我而敞开！
-
WinRunner和QTP的对比(转)
2007-04-15 15:27:55
很多初入行的朋友使用测试工具进行功能测试的时候,总是会遇到QTP和WinRunner的选择问题,为什么同样一家公司会出两个功能类似的工具哪? 下面是一篇关于这两个工具的对比介绍,其实从我自己的经验来看,WinRunner虽然推出较早,但是因为一些功能的缺陷,导致后期很难推广,而Quick Test Professinal(QTP)虽然没有师兄WinRunner出道早,然后内功深厚,所以很受欢迎,而且Mercury公司以后的主要发展策略是QTP,虽然文章中说并没有计划Phase out WR,但是已经不再出新版本了. 针对这两个工具的3年左右的使用经验,我的感受是WR比QTP的逊色的地方主要是几点:
1. WR的对象管理不如QTP那么有效
2. WR的语言主要是基于类C的TSL,是Mercury发明的语言,明显不如基于VBscrīpt的QTP强
3. WR的稳定性不行,而且无意人为的干扰可能导致回放的失败
4. WR对Java的支持也不如QTP那么强
-
软件测试中的基本词汇
2007-03-30 20:14:11
软件测试中的基本词汇
ü 黑盒测试 (Black box testing) ── 不考虑内部设计和代码，根据需求和功能进行测试。
ü 白盒测试 (White box testing) ── 根据应用软件的代码的内部逻辑，按照代码的语句、分支、路径和条件进行测试。
ü 功能测试 (functional testing) ── 对一个应用软件的功能模块进行黑盒测试。这种测试应当由测试人员进行。但这并不意味着程序员在推出软件之前不进行代码检查。(这一原则适用于所有的测试阶段。)
ü 系统测试 ── 针对全部需求说明进行黑盒测试，包括系统中所有的部件。
ü 端到端测试 (end-to-end testing) ── 类似于系统测试，但测试范围更“宏观”一些。模仿实际应用环境，对整个应用软件进行使用测试。例如与数据库进行交互作业、使用网络通信、与其他硬件、应用程序和系统之间的相互作用是否满足要求。
ü 回归测试 (regression testing) ── 每当软件经过了整理、修改、或者其环境发生变化，都重复进行测试。很难说需要进行多少次回归测试，特别是是到了开发周期的最后阶段。进行此种测试，特别适于使用自动测试工具。
ü 负荷试验 (load testing) ── 在大负荷条件下对应用软件进行测试。例如测试一个网站在不同负荷情况下的状况，以确定在什么情况下系统响应速度下降或是出现故障。
ü 压力测试 (stress testing) ── 经常可以与“负荷测试”或“性能测试”相互代替。这种测试是用来检查系统在下列条件下的情况：在非正常的巨大负荷下、某些动作和输入大量重复、输入大数、对数据库进行非常复杂的查询，等等。
ü 性能测试 (performance testing) ── 经常可以与“压力测试”或“负荷测试”相互代替。理想的“性能测试”(也包括其他任何类型的测试) 都应在质量保障和测试计划的文档终予以规定。
ü 可用性测试 (usability testing) ── 是专为“对用户友好”的特性进行测试。这是一种主观的感觉，取决于最终用户或顾客。可以进行用户会见、检查、对用户会议录像、或者使用其他技术。程序员和测试人员通常不参加可用性测试。
ü 恢复测试 (recovery testing) ── 在系统崩溃、硬件故障、或者其他灾难发生之后，重新恢复系统的情况。
ü 安全测试 (security testing) ── 测试系统在应付非授权的内部/外部访问、故意的损坏时的防护情况。这需要精密复杂的测试技术。
ü α 测试 (alpha testing) ── 在开发一个应用软件即将完成时所进行的测试。此时还允许有较小的设计修改。通常由最终用户或其他人进行这种测试，而不是由程序员和测试人员来进行。
ü β 测试 (beta testing) ── 当开发和测试已基本完成，需要在正式发行之前最后寻找毛病而进行的测试。通常由最终用户或其他人进行这种测试，而不是由程序员和测试人员来进行。 -
浅谈冒烟测试与随机测试
2007-03-30 19:57:27
冒烟测试
冒烟测试（smoke testing）,据说是微软起的名字。在《微软项目求生法则》一书第14章“构建过程”关于冒烟测试，就是开发人员在个人版本的软件上执行目前的冒烟测试项目，确定新的程序代码不出故障。
冒烟测试的名称可以理解为该种测试耗时短，仅用一袋烟功夫足够了。也有人认为是形象地类比新电路板功基本功能检查。任何新电路板焊好后，先通电检查，如果存在设计缺陷，电路板可能会短路，板子冒烟了。
冒烟测试的对象是每一个新编译的需要正式测试的软件版本，目的是确认软件基本功能正常，可以进行后续的正式测试工作。冒烟测试的执行者是版本编译人员。
在一般软件公司，软件在编写过程中，内部需要编译多个版本(Builds)，但是只有有限的几个版本需要执行正式测试（根据项目开发计划），这些需要执行的中间测试版本，在刚刚编译出来后，软件编译人员需要进行基本性能确认测试，例如是否可以正确安装/卸载，主要功能是否实现，是否存在严重死机或数据严重丢失等Bug。如果通过了该测试，则可以根据正式测试文档进行正式测试。否则，就需要重新编译版本，再次执行版本可接收确认测试，直到成功。
新版本的基本功能确认检查的测试，有的公司成为版本健康检查(Build Sanity Check)。对于编译的本地化软件新版本，除了进行上面提到的各种测试检查，还要检查是否在新的本地化版本中正确包含了全部应该本地化的文件。可以通过采用文件和目录结构比较工具，首先比较源语言版本和本地化版本的文件和目录中的文件数目、文件名称和文件日期等，这个过程称为版本镜像检查(Build Image Check)。其次，分别安装源语言版本和本地化版本，比较安装后的文件和目录结构中的文件数目、文件名称和文件日期等，这个过程称为版本安装检查(Build Installing Check)。
随机测试
在软件测试中除了根据测试样例和测试说明书进行测试外，还需要进行随机测试(Ad-hoc testing)，主要是根据测试者的经验对软件进行功能和性能抽查。随机测试是根据测试说明书执行样例测试的重要补充手段，是保证测试覆盖完整性的有效方式和过程。
随机测试主要是对被测软件的一些重要功能进行复测，也包括测试那些当前的测试样例(TestCase)没有覆盖到的部分。另外，对于软件更新和新增加的功能要重点测试。重点对一些特殊点情况点、特殊的使用环境、并发性、进行检查。尤其对以前测试发现的重大Bug，进行再次测试，可以结合回归测试(Regressive testing)一起进行。
理论上，每一个被测软件版本都需要执行随机测试，尤其对于最后的将要发布的版本更要重视随机测试。随机测试最好由具有丰富测试经验的熟悉被测软件的测试人员进行测试。对于被测试的软件越熟悉，执行随机测试越容易。只有不断的积累测试经验，包括具体的测试执行和对缺陷跟踪记录的分析，不断总结，才能提高。 -
Alpha和Beta测试的区别
2007-03-29 18:53:53
大型通用软件，在正式发布前，通常需要执行Alpha和Beta测试，目的是从实际终端用户的使用角度，对软件的功能和性能进行测试，以发现可能只有最终用户才能发现的错误。
Alpha测试（α测试）是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试，Alpha测试不能由程序员或测试员完成。Alpha测试发现的错误，可以在测试现场立刻反馈给开发人员，由开发人员及时分析和处理。目的是评价软件产品的功能、可使用性、可靠性、性能和支持。尤其注重产品的界面和特色。Alpha测试可以从软件产品编码结束之后开始，或在模块（子系统）测试完成后开始，也可以在确认测试过程中产品达到一定的稳定和可靠程度之后再开始。有关的手册（草稿）等应该在Alpha测试前准备好。
Beta测试（β测试）是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场，Beta测试不能由程序员或测试员完成。因而，Beta测试是在开发者无法控制的环境下进行的软件现场应用。在Beta测试中，由用户记下遇到的所有问题，包括真实的以及主管认定的，定期向开发者报告，开发者在综合用户的报告后，做出修改，最后将软件产品交付给全体用户使用。Beta测试着重于产品的支持性，包括文档、客户培训和支持产品的生产能力。只有当Alpha测试达到一定的可靠程度后，才能开始Beta测试。由于Beta测试的主要目标是测试可支持性，所以Beta测试应该尽可能由主持产品发行的人员来管理。
由于Alpha和Beta测试的组织难度大，测试费用高，测试的随机性强、测试周期跨度较长，测试质量和测试效率难于保证，所以，很多专业软件可能不再进行Beta测试。随着测试技术的提高，以及专业测试服务机构的大量涌现，很多软件的Beta测试外包给这些专业测试机构进行测试。α测试和β测试在软件交付使用之后,用户将如何实际使用程序,对于开发者来说是无法预测的.
α测试是由一个用户在开发环境下进行的测试,也可以是公司内部的用户在模拟实际操作环境下进行的测试.
α测试的目的是评价软件产品的FLURPS(即功能,局域化,可使用性,可靠性,性能和支持).尤其注重产品的界面和特色.
α测试可以从软件产品编码结束之时开始,或在模块(子系统)测试完成之后开始,也可以在确认测试过程中产品达到一定的稳定和可靠程度之后再开始.
β测试是由软件的多个用户在实际使用环境下进行的测试.这些用户返回有关错误信息给开发者.
测试时,开发者通常不在测试现场.因而,β测试是在开发者无法控制的环境下进行的软件现场应用.
在β测试中,由用户记下遇到的所有问题,包括真实的以及主观认定的,定期向开发者报告.
β测试主要衡量产品的FLURPS.着重于产品的支持性,包括文档,客户培训和支持产品生产能力.
只有当α测试达到一定的可靠程度时,才能开始β测试.它处在整个测试的最后阶段.同时,产品的所有手册文本也应该在此阶段完全定稿.α、β、λ常用来表示软件测试过程中的三个阶段，α是第一阶段，一般只供内部测试使用；β是第二个阶段，已经消除了软件中大部分的不完善之处，但仍有可能还存在缺陷和漏洞，一般只提供给特定的用户群来测试使用；λ是第三个阶段，此时产品已经相当成熟，只需在个别地方再做进一步的优化处理即可上市发行。 -
软件测试的原则
2007-03-29 18:45:52
软件测试从不同的角度出发会派生出两种不同的测试原则，从用户的角度出发，就是希望通过软件测试能充分暴露软件中存在的问题和缺陷，从而考虑是否可以接受该产品，从开发者的角度出发，就是希望测试能表明软件产品不存在错误，已经正确地实现了用户的需求，确立人们对软件质量的信心。中国软件评测中心的测试原则就是从用户和开发者的角度出发进行软件产品测试的，通过我们的测试，可以为用户提供放心的产品，并对优秀的产品进行认证。为了达到上述的原则，那么需要注意以下几点：
1．应当把“尽早和不断的测试”作为开发者的座右铭
2．程序员应该避免检查自己的程序，测试工作应该由独立的专业的软件测试机构来完成。
3．设计测试用例时应该考虑到合法的输入和不合法的输入以及各种边界条件，特殊情况下要制造极端状态和意外状态，比如网络异常中断、电源断电等情况。
4．一定要注意测试中的错误集中发生现象，这和程序员的编程水平和习惯有很大的关系。
5．对测试错误结果一定要有一个确认的过程，一般有A测试出来的错误，一定要有一个B来确认，严重的错误可以召开评审会进行讨论和分析。
6．制定严格的测试计划，并把测试时间安排的尽量宽松，不要希望在极短的时间内完成一个高水平的测试。
7．回归测试的关联性一定要引起充分的注意，修改一个错误而引起更多的错误出现的现象并不少见。
8．妥善保存一切测试过程文档，意义是不言而喻的，测试的重现性往往要靠测试文档。 -
Pareto原则（也叫80/20原则）？
2007-03-29 18:43:13
Pareto原则（也叫80/20原则）？
某个功能出问题，其对用户的影响有多大？然后根据风险大小确定测试的优先级。优先级高的测试，优先得到执行，一般来讲，针对用户最常用的20％功能（优先级高）的测试会得到完全执行，而低优先级的测试（另外用户不经常用的80％功能）就不是必要的，如果时间或经费不够，就暂时不做或少做。1879年，意大利人Villefredo Pareto提出：社会财富的80%是掌握在20%的人手中，而余下的80%的人只占有20%的财富。渐渐地，这种“关键的少数（vital few）和次要的多数（trivial many）”的理论，被广为应用在社会学和经济学中，并被成之为Pareto原则（Pareto Principle）。
