0

我有一个使用RichFaces 4.1.0的大型 Web 应用程序（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 ......

您对如何承担升级问题有何建议？

问候，

4

1 回答 1

1

这种升级有三种方法，这一切都取决于最适合您团队能力、预算和时间的方法。

1) 自动化网络测试

像Selenium这样有用的 Web 测试框架可以让您记录 Web 应用程序与最新稳定版本的交互，并在 Web 应用程序的原型版本上回放记录的交互。

这里的学习曲线是这样的，技术熟练的 QA 分析师应该能够通过独立的记录来验证每个记录的需求。

2) 模块化升级

CDK 的想法听起来像是一种很好的规避风险的方法，可以随着时间的推移慢慢升级 JSF 框架。如果没有时间和人力，这可能是最好的方法。

3）QA蛮力

质量保证团队基本上将手动遍历所有需求的所有测试用例，并验证测试用例是否仍然通过。这与第一种方法一样耗费人力，但是下次升级前端库或框架时，整个过程将不得不重复。

网景方法

Netscape 因其在 90 年代浏览器大战中的垮台而闻名。让他们失望的是他们的测试和质量保证理念。他们认为用户应该是 QA，这是一个愚蠢的信念，因为用户对产品的 90% 的意见都是基于第一印象。

这种方法基本上是让开发人员暴力升级，直到它编译完成，做简单的冒烟测试，当一切似乎都正常时，将其发布到生产环境中，等待用户反馈确定错误。我不推荐这种方法，除非你有一个非关键的应用程序和一个固定的用户群。

于 2013-04-19T12:10:38.273 回答