为什么满栈不够？
通常，从QA和终端用户的角度来看，完全堆栈测试为产品质量提供了足够的信心。然而，它的某些方面没有包括在内。原因可能不同，比如需求中没有提到，不明显，或者QA团队只是不知道如何进行这些测试，或者什么是验收标准等等。
目前，对所有层(后端/前端)的功能测试是现代质量保证的最低限度，但对于一个伟大的产品来说，这还不够。团队应该有动力，他们必须尽其所能提供最好的产品质量和最终用户体验。
在敏捷方法中，相对较小的团队在短跑中处理小部分功能。在这种情况下，团队成员之间的紧密沟通是可能的，而不会破坏流程。这反过来可以帮助共享知识，讨论代码改进，或者只是帮助向产品所有者提出正确的问题。
什么时候开始测试？
这个问题的答案是尽早开始。在某些情况下，在理想阶段考虑QA可能会指出薄弱的体系结构位置，并且可能需要从QA的角度提供一些信息。如果一个应用程序无法测试，那么它将对故障排除和测试成本产生巨大影响。
其中一些是：
制定测试策略的时间：团队必须找出在访问有限的情况下进行e2e测试的可能方法，并在不直接访问DB等情况下验证数据。
测试时间：由于标准方法不起作用，而且团队必须使用解决办法。
故障排除费用：再生缺陷的时间会越来越长。
超越和超越全堆栈测试
最好的bug是那些早在实现之前就被捕获的错误。这被认为是主动测试的主要成就，也是QA团队在创建技术需求/开发过程中的正确参与。
团队可以通过以下方式提高效率并扩展测试场景。
可进行测试的阶段：
与开发人员和产品负责人/实地专家一起进行需求评审：这是QA团队了解更多业务规则和项目背后价值的绝佳机会，也是与PO就需求进行直接讨论的最佳机会。虽然一个或几个会话是有用的，但它不能提供足够的信息来完全理解项目。
最好的方法是进行一些探索性测试，深入研究代码并阅读有关字段。课程结束后，你可以问一些受过教育的问题来澄清一些特定于应用程序的问题.
架构评审:这反过来对开发人员和QA都有帮助。QA应该了解体系结构、其局限性、瓶颈和各种测试方法。另一方面，开发人员需要知道QA计划执行哪些测试场景，或者扩展它们，或者确认体系结构中的弱点。
在这个阶段，团队完全了解需求：不应该有臭虫在功能和最终用户应该是快乐的。
还需要测试什么？
当问题出现时，还需要测试什么？答案是一些没有功能的测试。有一个清单非功能性试验要执行。下文对其中的几个问题作了简要介绍。
许多非功能性测试：
#1)性能测试
系统性能的多个方面可能会使用户抓狂。因此，性能测试技术已实现。
#2)速度测试
最简单的测试，以了解系统对用户调用/命令的响应速度。
#3)负荷试验
这类似于速度测试，但是使用不同数量的客户机来查看系统是否能够处理类似于生产的负载。
#4)稳定性试验
这是一种类型的负载测试，它检查系统在很长一段时间内处理负载的能力。最好的方法是连续几天模拟用户活动周期，看看系统是否能够释放用于高峰用户活动的资源。
#5)可伸缩性测试
对集群应用程序进行特定于体系结构的测试，以查看系统是否能够在负载不断增加的情况下具有稳定的平坦响应时间。
每个指标都需要自己的测试策略。这些测试的策略是根据负载配置文件及其预期的用户计数来定义的。
在某些情况下，使用起升-冷却测试(负荷随时间变化)来查看系统在负载增加(高于名义值)后是否能够达到正常状态。
有多个工具可以帮助完成任务，比如非常简单的Gatling，简单的使用，但敏捷的SoapUI到通用的JMeter，已经失去了组件和脚本能力。
系统性能测试：
#6)可用性
理想情况下，向团队提供工作流、设计和UX功能描述。在某些情况下，团队自己创建它。
QA将是第一批能够提供反馈的用户，但要找到合适的平衡可能并不容易。设计和可用性是开放的一个广泛的解释，可能没有完全正确的答案，它可能会浪费很多时间。
这里最理想的解决方案是带有公司配色方案、首选字体和设计模式的文档。有些事情最好留给合格的专业人员。
#7)行业标准
在某些情况下，用户有一些期望。
典型例子将是登录页面。用户有一定的期望和创造性，如交换登录和密码输入，这将不会很好。
一些设计元素/样式也正在成为用户期望的一部分，应该记住。QA专家不仅应该注意他测试的应用程序，还应该注意IT世界正在采取的总体方向。
#8)安全测试
最复杂的测试方面，很少得到足够的关注，需要非常高的IT能力和时间。安全测试技术。对于平台/应用程序特定的所有其他测试，可以执行的标准测试数量有限。
数据加密，访问限制，SQL注入是相当简单的测试，但通常情况下，漏洞会使用不同类型的bug。安全测试的最佳方法是具备体系结构和阅读方面的专业知识。
关于不同类型的安全×××以及如何避免这些×××，有许多有用的文章可供参考，阅读这些文章可以使咖啡休息变得更有趣。
9)主动
这是最重要的建议之一。学习新的技能，提供改进和对项目的未来感兴趣是一个人可以实施的很少的倡议。了解项目中使用的技术堆栈将有助于选择只包含相关场景并提高测试效率的高效测试策略。
除了简单地完成上午9点到下午5点的任务外，这就是允许“超越”的地方。
结语
在项目的早期阶段，质量保证是非常符合成本效益的。然而，超越和超越能够真正提高产品完美的标准。
单一可用性问题、单一安全漏洞或无法处理峰值负载可能导致现有客户端失去希望。这种QA方法要求每个团队成员都有很高的积极性，不一定能在所有团队中工作，但值得一试。