是否有正确的方法来实施持续改进（AKA软件强化）流程？

作者: 咿呀哟
发布时间: 2024-01-10 01:13:08 (4月前)
转自：

6 条回复

0#
回复此人
淋了一整夜的雨 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> 编码结束后，首先应该进行单元测试。如果您将获得一些应该修复的错误，您应该执行另一轮单元测试以查找是否有新错误。完成单元测试后，您应该进行功能测试。 你在这里提到你的测试人员每月都会进行回归测试，但仍然会出现旧的错误。因此，最好与测试人员坐在一起审查测试用例，因为我觉得他们需要定期更新。在审查期间，还要强调错误来自哪个模块或功能。强调这些区域并在这些区域中添加更多测试用例，并在rgression测试用例中添加这些测试用例，以便一旦新构建到来，就应运行这些测试用例。 如果你的项目是一个长期项目，你可以尝试一件事，然后你应该与测试人员讨论自动化回归测试用例。它可以帮助您在夜间关机时运行测试用例，第二天您将获得结果。回归测试用例也应该更新，因为当回归测试用例没有定期更新时，以及通过运行旧的回归测试用例和新的进展测试用例，您缺少几个未经过测试的模块时，主要问题就会出现。 </DIV>

编辑
1#
回复此人
Let us fly | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> 回过头来为（所有）现有的东西实施测试策略是一件痛苦的事。这很长，很难，也没有人愿意去做。但是，我强烈建议在出现新bug时，围绕该bug开发测试。如果你没有得到关于它的错误报告，那么要么（a）有效，要么（b）用户不关心它不起作用。无论哪种方式，测试都是浪费你的时间。 一旦确定，就写一个测试的 红色 </强> 。马上。然后修复bug。确认它已修复。确认测试现在的 绿色 </强> 。重复，因为新的错误进来。 </DIV>

编辑
2#
回复此人
v-star*위위 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> 这里有很多关于单元测试的讨论，我不能同意。我希望Josh明白单元测试是一个机械化的过程。我不同意PJ，因为单元测试应该在编写应用程序之前编写，而不是之后编写。这称为TDD或测试驱动开发。 有些人编写单元测试来执行中间层代码，但忽略了测试GUI代码。这是不谨慎的。您应该为应用程序中的所有层编写单元测试。 由于单元测试也是代码，因此测试套件存在质量保证问题。代码覆盖率是否良好？单元测试中是否存在误报/否定错误？你在测试正确的东西吗？您如何确保质量保证流程的质量？基本上，答案归结为同行评审和文化价值观。团队中的每个人都必须致力于良好的测试卫生。 系统中引入的错误越早，系统停留的时间越长，移除系统的难度就越大，成本也就越高。这就是为什么你应该研究所谓的持续集成。正确设置后，持续集成意味着在您检查当天的更改后不久，项目就会编译并运行完整的单元测试。 如果构建或单元测试失败，则违规编码器和构建主机会收到通知。他们与团队领导一起确定最合适的课程修正应该是什么。有时它就像解决问题并检查修复一样简单。构建主管和团队负责人需要参与确定需要额外干预的任何总体模式。例如，家庭危机可能导致开发人员的编码质量达到最低点。如果没有CI和一些管理层监督，在您意识到正在发生的事情并采取纠正措施之前可能需要六个月的错误。 您没有提到您的开发环境。如果你的是J2EE商店，那么我建议你研究以下内容。 <UL> <LI> CruiseControl用于持续集成 </LI> <LI> Subversion用于源代码版本控制，因为它与CruiseControl很好地集成 </LI> <LI> Spring因为DI使单元测试更容易机械化以实现持续集成 </LI> <LI> JUnit用于中间层的单元测试 </LI> <LI> HttpUnit用于单元测试GUI </LI> <LI> Apache JMeter用于压力测试 </LI> </UL> </DIV>

编辑
3#
回复此人
只怕再见是故人 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> <BLOCKQUOTE> 这种测试有诀窍吗？ </BLOCKQUOTE> 你说，“我们让测试人员每月对一个应用程序进行几个小时的月度回归测试，以保持领先于小问题。” 我想通过“回归测试”你的意思是“手动操作旧功能”。 您应该决定是否正在寻找以前从未发现的旧错误（这意味着，运行以前从未运行过的测试）; 要么 ，是否要重复先前运行的测试以验证先前测试的功能是否未更改。这是两个相反的事情。 “回归测试”对我来说意味着你正在做后者。 如果问题是“客户发现我们的软件存在一些旧问题”，那么您的客户正在运行您以前从未运行的测试（在这种情况下，要找到这些问题，您需要运行 新 测试旧软件），或者他们发现了你的错误 有 以前的测试和发现，但你发现它们后你显然从未修复过。 <BLOCKQUOTE> 我是否需要一次定位一个特定功能？ </BLOCKQUOTE> 你准备做什么，确切地说： <UL> <LI> 在客户找到它们之前发现错误？ </LI> <LI> 说客户说这个问题没什么问题 新 发展？ </LI> <LI> 花尽可能少的时间进行测试？ </LI> </UL> 非常一般的建议是错误存在于家庭中：所以当你发现一个错误时，寻找它的父母，兄弟姐妹和堂兄弟，例如： <UL> <LI> 您可能在其他模块中有完全相同的错误 </LI> <LI> 这个模块可能比其他模块更麻烦（也许在休息日由somone编写），所以在这个模块中寻找其他各种错误 </LI> <LI> 也许这是一类问题（性能问题或低内存问题），这些问题表明整个领域（或整个类型的需求）需要更好的测试覆盖率 </LI> </UL> 其他建议是它与管理客户期望有关：你说，“它看起来好像每个版本都有多个错误，而实际上我们的新代码通常是可靠的”，好像真正的问题是错误认为错误是新编写的。 <BLOCKQUOTE> 因为总会有新的代码要写，所以感觉就像一个非常艰难的过程 </BLOCKQUOTE> 软件开发不是在后台发生的，而是在一个燃烧器上：要么有人正在研究它，要么它们不是。管理层必须决定是否指派任何人完成这项任务（即查找现有的先前未发现的错误，或修复以前发现但尚未报告的错误），或者他们是否更愿意专注于新开发并让客户进行错误检测。 <HR /> 的 编辑： </强> 值得一提的是，测试并不是发现bug的唯一方法。还有： <UL> <LI> 非正式设计评论（35％） </LI> <LI> 正式设计检查（55％） </LI> <LI> 非正式代码审查（25％） </LI> <LI> 正式代码检查（60％） </LI> <LI> 个人桌面检查代码（40％） </LI> <LI> 单元测试（30％） </LI> <LI> 组件测试（30％） </LI> <LI> 整合测试（35％） </LI> <LI> 回归测试（25％） </LI> <LI> 系统测试（40％） </LI> <LI> 低容量beta测试（<10个站点）（35％） </LI> <LI> 大批量beta测试（> 1000个站点）（70％） </LI> </UL> 我放在每个技术旁边的百分比是每种技术的缺陷去除率的度量（取自McConnel的第243页） 软件估算 书）。两种最有效的技术似乎是正式的代码检查和大批量beta测试。 因此，引入正式的代码审查可能是个好主意：在检测缺陷方面可能比黑盒测试更好。 </DIV>

编辑
4#
回复此人
࿏自ོ༾由ོ༽人͙⃡⌇ | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> 很抱歉这么说，但也许你只是测试不够，或者太晚，或者两者兼而有之。 </DIV>

编辑

登录后才能参与评论