保存Web应用程序中各个层的历史性能数据，有利于快速确定问题所在位置。典型的三层架构包括Web层、应用层和数据层。性能问题有可能出现在任一层，因而此举会增加排查问题的难度。通过保存各个层的性能数据，我们就有可能在最终用户遇到问题之前就检测并解决掉，或者，更关键的是，在这些问题影响到网站或应用中与收益相关的功能之前就将它们排除。Web开发人员必须与运维人员一起协作，监控各层的运行状况，确定各层的测试方式应该是两个团队的共同职责。例如，Web开发人员可能负责保存应用层和Web层的...
在任何网站上，在测试前端时都必须模拟真实用户在网站上执行真实功能的情形。这就是所谓的真实浏览器测试，它不同于使用工具( Apache-Bench或Jmeter)执行的合成测试，后者只是模拟网站前端的流量负载。真实浏览器需要一定的时间才能构造出文档对象模型( DOM)，这其中包括解析JavaScript， 然后再渲染网页。Apache-Bench和Jmeter等工具无法测试真实浏览器在这些方面的加载过程。...
测试对象取决于Web应用程序当前所处的软件开发生命周期。在开发早期，我们可能需要直接测试软件的各个独立组件，从而更好地理解各个组件的运行方式。这是因为，在一款Web应用程序中，实际上会有多个Web层参与到页面的显示与最终用户请求的响应中。...
安全至关重要，但在Web应用程序测试中经常被忽视。它经常被视为测试过程中不必要的部分，这是不正确的。将漏洞测试整合到测试和持续集成周期中，我们不仅能够发现安全漏洞，也能够发现性能问题、功能问题和其他不可预期的Bug否则无法检测到这些Bug，它们甚至在应用程序的真实应用中也极少出现。...
Web测试可以由负责开发某个应用程序的开发人员编写，也可以由其他工程师编写，主要就是编写功能测试。运维人员甚至可以使用Selenium测试框架( selenium.org)这样的工具来执行真实测览器的自动监控或测试。这里的关键是，使用真实浏览器测试Web应用程序，Web测试的准确性和真实性都会好于编写代码发起HTP请求的人工测试，而且后者还无法在浏览器中解析和渲染 Javascript.。用户使用Web浏览器访问网站，所以不使用浏览器，就无法在测试中产生最准确的结果。...
TDD的学习难度很大。我认为BD在很多方面都是对TD0的科充和修 BDD是在TDD出现5年之后才面市的，BDD是TDD的延续，因为正。BDD修正了我们对于例试的定义和命名，还对编写这些测试的方法以及适宜人员提出了一定的建设性意见。在过去六七年中，BDD一直在向前发展一也可能有8年时间了，我认为是从200年开始的。所以，对于我而育，现在BD更多是关于利益相关者、测试人员、程序员和用户之间的交流。...
测试使我们能够根据需要来修改软件。在我们的环境中，客户都是商人(手握钞票)，他们总会要求很多功能和特性，甚至一天会提几次要求，因此我们不得不做大量的小修改。测试可以帮助我们完成这些修改，并且保证不搞坏什么东西。也就是说，所有工作都依赖于测试带来的价值。有时候，测试很有难度，也可能变得很麻烦。如果想要快速完成软件的修改，那么就不太可能测试所有的方面，而且维护这些测试也很困难。例如，我的上一家公司就非常注重测试，因为他们的软件不会经常变化。但是，另一方面，我们也无法快速获得反馈。...
持续负载测试(浸泡测试)是指在一段较长时间里用不同的负载持续测试网站或应用程序。这种方法可以在应用程序正式上线之前发现有问题。一般只有在软件发生重大变化或重大版本发布时，才需要执行持续负载测试，测试的时间可能持续24小时或者几天。...
网站最大容量测试(压力测试)是指给最终用户服务施加一定的负载确定Web应用程序或网站崩溃和停止工作的临界点。这个方法是容量规划和确定应用程序可承受压力或负载的重要方法。这是测试环境内部经常会执行的合成测试。万万不可在生产网站上执行最大容量测试，因为它可能会导致网站停止响应，从而影响业务收益。最大容量测试有可能发现代码问题。负载相对较低或会话数量相对较少的应用程序也可能会出现一些功能问题，只有解决了这些问题，我们才能继续执行后续的测试。...
保证软件质量的责任并不专属于某个部门。只要使用一些常用的工具集，Web开发人员、运维工程师和QA工程师就都能执行各种测试一所有利益相关者都应该参与到软件质量的保证过程中。这就要求将测试整合到测试框架和持续集成过程中，或者用一些方法实现自动化测试，这样才能快速高效地检查Web或应用程序的性能。...
