累积测试分析和目标测试入门

 

1. Web性能测试资料及工具

　　1）Jmeter Wiki首页，Jmeter为一个开源的100%Java开发的性能测试工具

　　2） Apache Benchmark使用说明
    本文来自于Rational Edge：通常所说的“累积测试分析（Cumulative Test Analysis）”技术向软件测试团队提供了对自动化测试更合理的方法，特别是在回归测试集的领域内。理解CTA 如何提高您的测试效率。

    您的测试团队已经非常成功了。您已经对自动化大量投资，并且因生成大型且全面的测试集而著称–– 您可以无可非议地为之自豪！在整个开发过程和多个环境中，这些组合为您很好地服务。因此现在是您休息一会，并且收获您所劳动的好处的时候了，对吗？或者，您将成为您自己的自动化测试集的牺牲品？

    也许，像许多团队一样，您已经达到饱和点，现在您有太多的测试，以至于不能说明。也许运行测试的团队已经不再是撰写它们的团队了，并且知识是稀少的。或者也许您受困于对大量所支持的环境和代码流不断地重复运行同样的测试的工作。对于那些您不能运行的测试，或者您没有时间运行的，您对您所带来的风险进行过观察吗？

    无疑地，如果您只运行少量的测试，并且仍旧在代码中找到一样的缺陷，这是更好的。通过运行可能的测试尽可能快地找到第一次出现的缺陷不同样是更好的吗？

    不能达到的目标

    甚至是出于一片好心，每个测试人员在他或她的工作生涯中，都将撰写一个根本不测试所打算测试内容的测试。这可能是由于缺乏经验，对产品功能设计的变更，因为测试人员做出关于产品或其预期使用价值的无效假设，或者只是因为测试人员用尽了时间。总而言之，最终结果是由于与产品缺陷不相关的原因而失败的测试。

    这些失败测试的累积效应创造了回归套件中的灰色区域，您的回归测试的5％ 到15％是困难的、不可靠的或不可能成功地运行完成的。这些阻塞的或不可靠的测试消耗了宝贵的测试时间，并且混淆了测试人员对真实的产品缺陷的观察，这导致了在回归测试循环末尾的测试进度中的指数的缩小。虚幻的所有可用测试的100％ 的运行目标常常看起来非常接近，但是却难以达到。

    自动化陷阱

    也许您已经落入了严重依赖于您的测试自动化基础架构的陷阱了。这里有一些您可能考虑的问题。您是：

    缺少用于测试您所期望的每样东西的资源吗？
    陷入无休止的测试循环吗？
    在没有找到任何新的缺陷的情况下，运行成千上万的测试吗？
    瞄准100％ 运行您所有的测试的目标吗？在质量和风险方面您了解此目标吗？
    您可能需要的是，不再瞄准任意数量的测试，而着眼于从上次测试以来在产品中实际变更的功能是什么，以及测试此变更所需要的是什么。总而言之，您需要转移到更深思熟虑的“目标”测试的方法。

    停止运行测试，开始寻找缺陷

<