我有一个使用 RichFaces 4.1.0 的大型网络应用程序（100多个jsf页面）。我正在尝试 RichFaces 4.3.0 （ rich：placeHolder ）提供的新功能。这让我想到了一个问题：如果我真的想使用新的RichFaces版本，我怎么知道升级是否安全？
我认为由于不同的因素，它是非常不安全的：旧的错误，新的错误，功能的变化，已编写的代码（不一定好......），...
但是，我想知道，您通常如何处理生产项目中的这类问题。通过使用 JUnit ， Mockito ， Arquillian 或其他任何方式构建一个非常“良好”测试集是可以避免的？或者也许让应用程序成为最好的方法一旦交付？在这种情况下，我们永远不会升级其中的任何jar，（尽可能避免）？
在这个特定问题中，RichFaces团队开发了一个名为CDK的内部框架，它提供了组件独立性，以便于模块化。这意味着我们可以使用 rich：placeHolder 组件并为其创建一个 jar 。然后我们将不得不将这个新的 jar 添加到我们的应用程序中。这样可以避免升级所有主要的richfaces jar 。在这种情况下，这应该可以正常工作，因为 rich：placeHolder 是一个新组件，但如果我们尝试升级已经存在的组件，它将无法工作。
我认为同样的问题适用于其他框架：Primefaces，Icefaces ......
您对如何承担此升级问题有何建议？
此致
答案 0 :(得分：1)
这种升级有三种方法，这取决于最适合您团队的能力，预算和时间。
像Selenium这样有用的Web测试框架可以让您记录Web应用程序与最新稳定版本的交互，并在Web应用程序的原型版本上回放录制的交互。
这里的学习曲线是技术熟练的QA分析师应该能够通过独立的记录来验证每个记录的要求。
CDK的想法听起来像是一种风险厌恶的方法，可以随着时间的推移慢慢升级您的JSF框架。如果没有时间和人力，这可能是最好的方法。
质量保证团队基本上会手动遍历所有测试用例以满足所有要求，并验证测试用例是否仍在通过。这与第一种方法一样劳动密集，但是下次升级前端库或框架时，必须重复整个过程。
Netscape因其在90年代的浏览器大战期间的垮台而闻名。让他们失望的是他们的测试理念和质量保证。他们认为用户应该是QA，这是一个愚蠢的信念，因为用户根据第一印象形成他们对产品的90％意见。
这种方法基本上有开发人员强力升级，直到它编译，进行简单的冒烟测试，当一切似乎都没问题时，将其发布到生产中并等待用户反馈来确定错误。除非您有非关键应用程序和强制用户群，否则我不建议使用此方法。