TDD的学习难度很大。我认为BD在很多方面都是对TD0的科充和修 BDD是在TDD出现5年之后才面市的，BDD是TDD的延续，因为正。BDD修正了我们对于例试的定义和命名，还对编写这些测试的方法以及适宜人员提出了一定的建设性意见。在过去六七年中，BDD一直在向前发展一也可能有8年时间了，我认为是从200年开始的。所以，对于我而育，现在BD更多是关于利益相关者、测试人员、程序员和用户之间的交流。...

测试使我们能够根据需要来修改软件。在我们的环境中，客户都是商人(手握钞票)，他们总会要求很多功能和特性，甚至一天会提几次要求，因此我们不得不做大量的小修改。测试可以帮助我们完成这些修改，并且保证不搞坏什么东西。也就是说，所有工作都依赖于测试带来的价值。有时候，测试很有难度，也可能变得很麻烦。如果想要快速完成软件的修改，那么就不太可能测试所有的方面，而且维护这些测试也很困难。例如，我的上一家公司就非常注重测试，因为他们的软件不会经常变化。但是，另一方面，我们也无法快速获得反馈。...

持续负载测试(浸泡测试)是指在一段较长时间里用不同的负载持续测试网站或应用程序。这种方法可以在应用程序正式上线之前发现有问题。一般只有在软件发生重大变化或重大版本发布时，才需要执行持续负载测试，测试的时间可能持续24小时或者几天。...

网站最大容量测试(压力测试)是指给最终用户服务施加一定的负载确定Web应用程序或网站崩溃和停止工作的临界点。这个方法是容量规划和确定应用程序可承受压力或负载的重要方法。这是测试环境内部经常会执行的合成测试。万万不可在生产网站上执行最大容量测试，因为它可能会导致网站停止响应，从而影响业务收益。最大容量测试有可能发现代码问题。负载相对较低或会话数量相对较少的应用程序也可能会出现一些功能问题，只有解决了这些问题，我们才能继续执行后续的测试。...

保证软件质量的责任并不专属于某个部门。只要使用一些常用的工具集，Web开发人员、运维工程师和QA工程师就都能执行各种测试一所有利益相关者都应该参与到软件质量的保证过程中。这就要求将测试整合到测试框架和持续集成过程中，或者用一些方法实现自动化测试，这样才能快速高效地检查Web或应用程序的性能。...

测试web应用程序不仅要测试网站本身，还需要检查网站各个层次的应用程序指标。这就像建造一架飞机:飞机的每一个部件都必须经过安全性设计和测试，只有各个子系统完成了开发并通过测试，它们才可以组装到最终产品上，进行飞行测试。对于这样一个复杂的系统，我们必须先保证各个部件的可靠性，然后才能假定最终成品有可能符合要求网站也类似。它也由各种组件和子系统构成，如网络、数据库、应用逻辑和前端，它们分布在各个层上，甚至每一层还可能有多个交互系统。通常，测试一个网站需要经过下面几个步骤:...

行政管理层不接纳实现网站创新及改进建议的一些现象。企业文化、安于现状和疏忽都会妨碍业务团队与工程团队的协调。...

如果业务团队与工程团队开始有共同语言，更好地理解对方，以及在组织中建立良好的相处关系，那么这对于公司肯定是好事，但是这些方法并不一定有效。有时候，是因为业务管理本身做得不好，特别是那些有较大影响力的行政角色做得不好。我将介绍一些破坏业务团队与技术团队之间协作的常见问题，以及相应的应对方法。...

业务团队和开发团队一定要在各自目标以及公司总体的业务目标上保持步调一致。当公司能够善加利用技术人员的特长和技能时，这种效果就能实现。形成孕育这种效果的文化和组织环境并不容易，但是如果两个团队都开始不断地向对方靠近(尽管这对于技术和非技术团队而言并不容易)，那么就可能实现这种效果。...

激励是提高员工生产力的重要因素。有时候，Web开发者会由于日复一日地重复相同工作而变得单调无趣。这在大型公司中尤为明显，因为在大公司中，人们更难尝试或创造新东西，而只有新东西才能吸引人们享受自己的日常工作。我们越是鼓励开发者做一些新工作，他们就会越积极主动，团队成员也会越积极主动，从而越有可能真正勤奋地工作第一时间解决问题，或是开发新网站和应用。只有积极主动的团队才最有可能与业务人员进行沟通，致力于公司长远目标的实现，而其他人则只会安于完成自己的本职工作。体现在公司的招聘实践...