快速迭代的测试人员的思考

如何在快速迭代的当今，测试人员在使用更少的时间的测试

对于质量保障这一块，该采取哪些质量控制手段来保证软件/系统质量？

总体思路是这样的：流程控制 + 测试深度 + 测试广度。

其中流程控制主要有：质量保障工作前置，越早发现问题修复代价越小。流程埋点，流程数据分析及改进，流程基本稳定后再着手将其系统化，以提升效率。

流程控制中的一些关键阶段的质量保障措施如下：

提测前质量保障：需求评审 +设计评审 +代码评审 +用例评审 +静态代码扫描；

测试中质量保障：分层测试 +自动化测试 +上线前checklist检查点 +产品试用机制 +基线压测机制；

上线后质量保障：线上验证 + 定期自动化回归 + 系统稳定性监控 + 线上压测；

测试深度包括：自动化测试 + 接口测试 + 少量白盒测试 + 探索性测试；

测试广度包括：功能 + 性能（线上压测 + 线下基线检测） + 安全 + 易用性 +可维护性（注释 + 重要行为日志）。

未来测试人员技能全面化是一个趋势。但要求测试人员既要懂产品，又要懂开发，这对于要经常赶工期的测试人员来说是非常大的挑战。

建议是：

重点在工作中学习，在工作中提升，或者挤出一些业余时间来学习。

关于赶工期，大家普遍有这样的观点：因为测试时间少，大家就会赶工期，然后就拼命地去通过手工测试的方法赶工，因为手工测试来的直接哇，直接上手就测。长久看来就会发现，越这样，未来随着项目的增多就越需要赶工，时间就越不够用，长此以往，形成恶性循环。

所以大家必须改变思维，解放思想，要在繁杂的工作中坚持学习。我们是否能够挤出一点时间来尝试新的实践呢？如：采用静态代码扫描的方式将大量低级错误在代码提交前就修复，采用自动化测试将一些重复的劳动用机器来代替。这些都是值得学习并实践的。

 

 

如何在功能测试阶段自动化测试思考

在功能开始阶段全部实现自动化测试不现实，用例数目过多。是否可以在功能测试阶段先实现冒烟用例的自动化测试，并把自动化脚本个人构建提供给开发。开发在修改完代码后可以先个人构建成功后在提交代码。

 

在冒烟用例后的的快速测试思考

是否可以对已知代码只修改算法规则进行手动直接插入数据库数据来验证算法，而不用每次手动模拟用户来创建数据？

或者专门创建UI自动化用例来每次创建数据？但是对于多场景快速迭代情况，UI用例变化很大。

 

如何在质量有保证前提下，使用更短测试时间内

细分测试影响点：需要和开发一期分析。本次迭代修影响到那些，重点测试。然后分析修改点相关联的模块，做次要测试点。

审核开发代码：审核开发代码也可以更清楚查看到开发有何地方为覆盖，防止漏测

__EOF__

本文作者：闪电旅途
本文链接：https://www.cnblogs.com/jiaoyang77/p/10368207.html
关于博主：评论和私信会在第一时间回复。或者直接私信我。
版权声明：本博客所有文章除特别声明外，均采用 BY-NC-SA 许可协议。转载请注明出处！
声援博主：如果您觉得文章对您有帮助，可以点击文章右下角【推荐】一下。您的鼓励是博主的最大动力！