系统集成测试

Question

我在系统/集成测试方面有一些问题。我们有一个开发团队和一个完整的QA团队，为我们的产品进行以客户为中心的测试。如果您愿意的话，我们想介绍一个中间测试团队，它更像是一个工程orr的扩展，一个系统集成测试团队。

考虑开发人员需要测试的规则，这个新团队需要测试什么，以及最终的QA客户团队。它应该解决的问题是QA团队获得的代码并不是很好的测试，并且很快就会崩溃，因为开发人员主要是进行单元测试，而QA是在进行规模化的、以客户为中心的场景。我们正在做烟来照顾眼前的崩溃，但想做的更多，减轻一些开发人员的负担，但不是所有的方式。

这个项目在python中，它的一系列不同的模块相互交互。

今天的开发人员只进行单元测试、类级测试和一些非常有限的“系统”级测试。

我很想知道其他人会为这样的组合做些什么。我希望开发人员进行更多的“系统”级测试，在系统视图中对组件进行端到端的测试，其规模大于一个或两个并发操作。但我现在面临的问题是，在这种情况下，这支新球队的期望是什么。我唯一能想到的是规模和一个完整的组件--一起测试，但这是QA团队在任何情况下都会做的事情。

Answer 1

听起来好像你想避免给QA一个马上就会崩溃的构建。解决这一问题的一种方法是在开发周期中添加一个烟雾测试。有覆盖烟雾测试的其他SQA问题，例如由Dev小组进行的烟雾测试。我不会在这里重复这些信息。

烟雾测试的一个目标是鼓励开发人员交付至少通过最低质量水平的QA构建。另一个目标是避免浪费QA团队的时间。将烟雾测试委托给中间的QA团队可能会减少最终QA客户团队浪费的时间。我认为这不会鼓励开发人员提高QA构建的质量。

Answer 2

User246是对的，开发团队的烟雾测试应该给QA团队提供更稳定的测试产品。

但我很担心你的整个做法。你不能“通过更多的测试来保证质量”。更好的方法(更好地利用所有相关人员的时间)是认识到质量是必须建立的，这是每个人的责任，而不仅仅是QA。QA提供了有关产品质量现状的信息，但是如果开发人员不关心质量，就不能“保证”它。

更好地利用中级QA团队时间(投资的最佳时间回报)将是为最重要的功能开发自动化测试，并使用持续集成检查任何回归。按照增加复杂性的顺序运行所有这些自动测试(首先进行烟雾测试，然后是重要功能的愉快路径，然后是rest)。手动QA测试人员将测试一些您还没有自动化测试的棘手/特定场景。

Answer 3

我们目前在我们的持续集成系统中使用的是多层环境，这也可以满足您的需要。让我描述一下。

1. 开发环境-主要是Dev‘setup设置，代码在其中进行构建和单元测试。我们在这里学到的是，让测试人员在早期帮助解决方案会有很大帮助。
2. 系统测试-交付给QA的成功构建(可能从新团队开始)，在早期部署和测试。Dev的含义应该只是对配置/bug的支持。我不想让开发团队做“更多”测试，因为他们对他们的“小婴儿”有偏见。
3. UAT -在我看来，这主要是对您当前QA团队的描述。构建的质量将大于系统(可能希望在此系统上使用分支系统)。此外，我们使用这个env让客户QA团队在这里完成他们的工作。
4. PreProduction -最精确的prod环境副本，主要用于检查部署过程+ UAT/Systest团队的快速烟雾测试。
5. 生产。