如何规避敏捷测试中bug反复出现

Posted 2023-03-21

参考技术A 测试包括手工测试和自动化测试。这些测试可以分布在不同的地方进行：用于确保具体的功能是否正常工作，用于完成用户所期望的功能。当需要一些手工测试时（一般来说成本比较昂贵）？ 测试是得到反馈的一个重要方法。 什么样的测试技术是有用的，每种技术所扮演的不同角色。 为什么要测试。在构建整个应用时。一个好的方法就是在Wiki上使用一个特别的位置来显示当前的构建结果。每个捕获的测试用例都被加入到测试数据库中，还有一些是手工的。特别地。你可以执行针对某一层来建立自己的测试。 在敏捷开发中。因为即使软件通过了所有的自动化测试。其中一部分是自动化的。让测试人员集中精力于那些很难进行自动化测试的复杂的部分！ “Smoke”测试。 Test Harness。 我们如何测试？ 我想！在这里不多陈述，提供已知输入并把得到的结果和期望的结果进行对照，应该先了解一些细节。某些项目从自动化测试中得到了收益。测试也是开发人员知道什么时候算完成他所开发的一个特性。你可以自己定义自动化测试的频率的执行时间，并可以根据需要对总结进行钻取(drilldown)，没有“放之四海皆准”的策略。同时要做到适合手工测试的内容决不要花高昂地成本做成自动化测试，也就是有质量保证人员参与的较为正试的构建，对于那些基础服务的系统是非常容易地。另外，特别是那些代码中有错误的开发人员！下面有一些测试的种类及它们在开发过程中扮演的角色。现在，应该把它放在主构建中。您可根据捕获的用户输入，你需要跟踪这些要求是否满足，我们还要发送email通知大家，测试也需要你用你的大脑，但它并不是唯一的一种测试，运行一套测试来确保多个非功能度量要求得到满足是非常关键的，验收测试是一个具体的客户场景。 你应该做哪些种类的测试，测试以很多不同的方法扮演着同样的角色：一般包括一些页面流。 手工测试，你需要敏捷开发中一些基本思想作为基础。如果你的应用需要很严格的性能度量要求。此时：如果你做了分层式的架构设计，它常常需要人的参与，它在用户刚开始使用时也可能出现错误。 运行于构建服务器上的所有测试结果都应该以某种总结式的结果描述呈现出来，使用工具也可以做到），而且不同的测试种类扮演着不同的角色。目的是确保代码所完成的功能在任何变化时都是正确的。有些UI测试是使用bitmap进行对比。为了说明这些角色，单元测试的一个附加作用就是当作软件API的使用说明文档，并与后面的回归测试相配合。 验收测试（或叫接受性测试）、测试人员可以写出一个接受性测试 不但测试种类有所不同。关键要注意在开发过程中。这样做的前提是：一般是开发者在编写他们被分派的特性时建立的。要避免做代价很大而没有太多意义的“bad”构建，但是可用性经常是做为“make-or-break”的验收条件。你可以使用基于XML的配置文件来控制这些测试的运行，这些自动化测试确保软件遵守了UI标准？ 虽然自动化是一个关键。这样也就相当于做了非常简单的并发测试。有很多工具可以帮助我们来实现这个发布过程。尽管我们需要尽可能多地进行自动化测试，性能测试至少要在每个主构建时自动运行－也许你每星期五做一次或每次迭代做一次。 单元测试，在初始的架构和设计阶段：不可缺少的一小撮关键测试，或者说是目的。测试对于确保代码做了它应该做的事是非常有用的，用于确保基本的构建功能正常运行，所以。 下面是几种不同类型的测试以及在敏捷项目中扮演的角色，你可以构建一些自动化的测试“机器人”、开发人员可以提供一个相当准确的估计 2，可以帮助开发团队了解每日构建是有用的，并自动创建需要修改的Bug列表，并让它重复执行（UI这一层的部分测试，我们有两个原则作为判断一个特性是否被描述的足够详细，且各层之间较为有清晰的界线的话，TestHarness常常是一个好方法。将一个TestHarness作为新的功能加入到原有的测试套装中是很容易的。象敏捷开发中的每个事情一样！我更愿意使用手工与自动化相结合的测试：让配置文件来控制测试的全过程：被认为一定要用手工才能对系统的某个方面进行测试的那部分内容。通常。另外。运行“smoke”测试很容易的话： 1，产生测试的方法也不尽相同，当我们想讨论“测试的种类”时：对于很多应用来说。 根据敏捷原则（做聪明的事）: 对于粗粒度的功能（特别是对于验收测试和主要的系统场景）进行制度化地测试来说，你要确保性能要求得到满足。 可用性测试，要确保能用自动化测试的事情决不要用手工测试。 自动化压力测试“机器人”在敏捷实践中。 UI测试，对于代码的修改反过来可以影响功能也是很有用的、正确的输出建立一个TestHarness并使其自动化：这可以说是另一个领域的测试，但并不意味着所有的手工测试就不再需要啦。然而。 性能测试，它也是经常被过分谈论的术语，不要因为某方面不能自动化测试而不做测试。当新一轮的构建完成以后，“测试”毫无疑问地是一个经常谈论的话题

灵魂拷问：如何规避生产环境的性能测试风险？

Hi，大家好，常言道，上线一时爽，事后火葬场。隐秘Bug的哲学之道：不知道藏在哪里，不知道有多少，总是在你准备休息的时候出现。生产环境一旦出问题，内心一阵发凉，当天必须解决，大家手忙脚乱思考解决方案。最紧张的当属测试人员，我漏测了？主机锁表？服务异常？…

以下，主要介绍生产环境中的性能测试风险以及风险规避的方法。

一、生产环境进行性能测试的必要性？

性能测试是针对系统的既定性能指标，制定测试方案，并执行测试，得出测试结果来验证系统性能是否满足用户要求而进行的测试。性能测试结果的可参考性与测试环境有着直接的关系，如果测试是在模拟环境下进行，会存在一些问题，比如硬件和软件配置与生产环境的不一致、测试数据量和实际生产环境的数据相差太远等，这些因素都会影响测试结果的可参考性，因此，为了获取准确的性能数据，真实的反映系统性能，性能测试应尽量在生产环境进行。

生产环境是业务系统正式运行的环境，一般已经上线使用了一段时间，系统中存在大量的真实业务数据，且业务数据随着系统的运行在不断的增加和更新中，因此在生产环境进行性能测试必然会对业务系统产生影响，甚至造成一定的风险，作为测试方，我们必须预知风险，并有效的规避风险。那么在生产环境进行性能测试可能的风险有哪些？我们在测试中应采用什么样的手段来规避这些风险呢？

二、生产环境进行性能测试存在哪些风险？

在生产环境进行测试可能会对系统造成一定的风险，测试中应尽量规避这些风险的发生。

图片

1、测试可能会导致系统奔溃

考虑到系统的业务发展，通常设定的性能指标会一定程度的高于目前系统运行时承受的压力，在系统能承受的最大压力未知的情况下，测试对系统施加的压力可能超过其所能承受的压力，导致系统崩溃，影响系统正常的业务运行。

2、测试可能会造成数据损坏

在对系统进行压力测试时，可能会因为系统压力过大导致某些事务未成功执行，从而导致相关数据被破坏；有些操作需要直接修改系统中的原始数据等，这些都可能对系统数据造成损坏。

3、测试会产生大量垃圾数据

由于性能测试的并发用户量大，而且要重复执行多次，所以会在系统中产生大量的垃圾数据，影响系统的使用。

为规避以上的风险，在生产环境进行性能测试时，我们应采取有效的手段避免上述风险的发生。

三、如何规避生产环境性能测试的风险？

在生产环境进行测试会对系统造成一定的风险，测试中可以从以下方面规避这些风险。

1、重要数据事前备份、事后恢复

在执行测试前，应尽可能对系统进行备份，至少对系统的重要数据和文件进行备份，确保系统测试结束后可以恢复到初始状态。

2、测试时选择系统空闲时间

对于系统并发负载测试或者其他可能影响系统运行并导致系统崩溃的测试操作，可以安排在系统空闲时间进行，出现系统异常时有时间可进行系统的恢复工作，不致于影响业务的正常运行。

3、给测试数据加标记

对于系统测试过程中产生的垃圾数据要进行特殊标记，测试结束后要及时清理。测试数据可以事先准备并予以特殊标记，也可以是带有特定意义的区域数据或者是特殊时间段内的数据，这样，当系统测试结束后，我们可以根据这些特殊标记将相应的垃圾数据删除，保证系统的正常运行，对于那些需要直接在系统中进行变更的数据在相应的业务操作和功能确认完成后应予以及时恢复，确保将系统恢复到数据变更前的正常状态。

4、实时关注系统状态

在具体实施系统并发负载测试时，应按照指标驱动和用户逐渐增加的方法对系统进行测试。在测试过程中，应实时关注系统状态，当系统不能承受相应的压力时，测试立即终止，以有效保证测试不会超出系统的最大可承受压力，避免系统崩溃和数据损坏。

四、实际运用案例

案例1：“计生委人口宏观管理与决策信息系统”，系统上线运行一年，业务数据实行全国中心集中管理。对系统进行“流入人口登记”负载压力测试，并发用户数分别为100、200、500。

分析该系统的实际情况，全国各区县上报的业务数据在全国中心实行集中管理，在测试过程中如果由于系统压力过大，出现系统崩溃或数据损坏的情况，那么将会导致系统不可用或一整年的业务数据丢失，损失一旦造成将不可挽回。基于以上的考虑，在测试中采用方法一、二、四来进行风险规避。首先，将测试时间安排在周末进行，避开了业务系统使用的繁忙期；其次，在实施测试前，要求厂商进行全库数据备份，并做了数据恢复测试，在确保数据可以正确恢复的情况下开始进行测试；同时，在测试实施过程中，对必要的操作系统、数据库的指标进行监控，根据系统的资源占用情况和响应时间等判断是否可进一步对系统施加压力。在测试结束后，厂商对系统进行了数据恢复，使系统恢复到了测试前的初始状态，避免了数据丢失或损坏的风险。

案例2：“北京市社会保险信息系统升级改造项目”，根据业务情况，需进行“183号令补缴明细录入”操作的负载压力测试。但该操作为不可逆操作，即系统未提供取消补缴的操作，为了清除测试数据，需手工修改数据库。

在这个项目测试中，采用了方法二、三、四进行风险规避，首先选择周末进行测试；其次，为了保障测试结束后系统可恢复到测试前的状态，选择对北京市石景山区的参保用户进行该操作，测试执行完成后，由厂商对石景山区的数据进行了恢复，确保系统与测试前保持一致。

案例3：对线上的两台服务器做性能压测时，发现单台Tomcat的QPS达到600左右处理业务就明显变慢，一次请求处理时间大约上升到七秒左右(正常情况下一秒内就处理完成)，给人的感觉就是Tomcat跑不动。

在Java语言中，凡是涉及到行号信息的获取，只能通过构造异常new Throwable()抛出，之后在函数内部通过异常或上层捕获异常来拿到栈信息，从栈信息中解析出行号信息，因此在Java中凡是涉及到行号信息的获取操作，都非常的耗性能。log4j影响性能的程度依次为：日志的location信息(如:行号函数名) > console(关闭日志输出到控制台) > 异步打印 > 日志文件的大小(日志追加模式)。线上环境如果对性能有一定要求的话，建议关闭location和console控制台。

JVM调优一般来说都是出问题或告警的时候注意进行优化，可谓”水无常形，兵无常势”,具体问题具体分析。

五、总结

在现在的系统测试，特别是大型项目的测试中，系统性能的好坏已经成为评价系统总体质量的一个必不可少的方面，在生产环境实施性能测试的时候，必须对系统进行深入的了解，分析系统特点，采取合适的测试方法并综合运用风险规避手段，既要准确的获得系统的性能数据，又要保证系统的安全，这样才是一个成功的性能测试。

最后，下面是我整理出来的一份软件测试工程师发展方向知识架构体系图。

希望大家能在这个成长过程中收益良多。可以说，这个过程会让你痛不欲生，但只要你熬过去了。以后的生活就轻松很多。正所谓万事开头难，只要迈出了第一步，你就已经成功了一半，古人说的好“不积跬步，无以至千里。”等到完成之后再回顾这一段路程的时候，你肯定会感慨良多。

由于CSDN上传图片大小有限，有需要的朋友可以关注我的公众号：程序员二黑，回复1，即可获取原图。

下面是一份配套的软件测试资源包：

上面是一些配套资源，对于软件测试的的朋友来说应该是最全面最完整的备战仓库，为了更好地整理每个模块，我也参考了很多网上的优质博文和项目，力求不漏掉每一个知识点，很多朋友靠着这些内容进行复习，拿到了BATJ等大厂的offer，这个仓库也已经帮助了很多的软件测试的学习者，希望也能帮助到你。

关注我的微信公众号：程序员二黑，即可免费获取！

最困难的时候，也就是我们离成功不远的时候！如果你不想再体验一次自学时找不到资料，没人解答问题，坚持几天便放弃的感受的话，可以加入我们的群：785128166 大家一起讨论交流学习。

推荐阅读

高薪程序员也躲不过35岁这一关…当能力与年龄脱节，我们该如何自救？

清华学姐熬了一个月肝出这份32W字Linux知识手册，在 Github标星31K+

字节跳动软件测试岗，前两面过了，第三面HR天坑！竟然跟我说……