测试学习总结

1．敏捷测试

测试往往被期望承担项目质量控制的职责。这点很难做到，测试既不能控制代码如何编写，也不能控制开发人员测试他们编写的代码，但所有的质量把控都被期望能压缩在开发之后的测试阶段完成。

 

在敏捷项目中，测试人员不再被动等待工作降临，而是主动寻找在整个开发周期中都贡献价值的方式：与用户一起编写需求的测试用例，与开发人员一起寻找程序中的漏洞，聚焦使用覆盖更广、更灵活的测试方法。在敏捷中，开发人员从来不超前于测试人员，因为一个功能在被测试之前处于“未完成”状态。

 

敏捷测试关注点：

1.适应性

2.阶段性

3.强调写作

4.关注产品

5.全功能团队

 

传统测试关注点：

1.计划性

2.持续性

3.注重记录

4.关注bug

5.智能独立

 

不同时期的测试策略

1.在软件初期探索阶段。产品处于一个不确定状态，从前端的风格到整体的布局到后端的API都在时刻变化当中，而且变化比较频繁，由于自动化用例的生命周期比较短，所以在这一阶段创建一些自动化测试用例是不太划算的。而在这个时间段的产品，往往特性是可以控制的，只有几个测试，所以手动测试为主，不考虑自动化，让产品能够快速识别错误点，让用户能够用起来。

2.到了产品扩张阶段。用户认可产品，这是会出现两种情况。第一是用户量增长，第二时需求量增长。这时候必须考虑自动化。因为这个阶段每一次迭代的全量验证成本会越来越大，而交付的速度也越来越快。我们不可能每一次上线的时候都做全部的测试，这时候旧的模块需要自动化用例去保证。

3.提取阶段。产品已经到了需求的饱和期，产品的利益增长到了饱和期，这时候要严格控制产品需求，自动化用例的责任变成了守护，不允许变动引入额外的风险点、大的特性变动，导致对成熟的用户造成攻击。

 

并发性能测试
1.并发性能测试的过程是一个负载测试和压力测试的过程，即逐渐增加负载，直到出现系统的瓶颈或不能接受的性能点。通过综合分析交易执行指标和资源监控指标来确定系统并发性能的过程。负载测试确定在不同负载下系统的工作性能，目标时探测当前负载逐渐增加时，系统组成部分的相应输出项，例如通过量、CPU负载、内存使用等来决定系统的性能。负载测试是一个分析软件应用程序和支撑架构、模拟真实环境的使用，从而来确定能够接受的性能点，来获取系统所提供的最大服务级别的测试。

2.测试的基本策略是自动负载测试，通过在几台高性能CPU上模拟成千上完的虚拟用户同时执行业务的场景，对应用程序进行测试，同时记录下每一个事物处理的时间、中间件服务器峰值数据、数据库状态等。通过可重复的、真实的测试以度量应用

 

如何对测试人员进行考评

1.“衡量测试人员的最佳方式就是每个测试人员发现的bug数”，大多数人以及大多数企业还是以产出，而不是结果来衡量。

2.应该针对团队进行衡量，而不是个人。测试人员的职责是质量保证，而不是发现错误。测试往往会成为测试的瓶颈。基于团队质量保证的前提，他们最应该做的是赋能开发人员，应该在项目的更早阶段发现问题，而不是项目后期由测试人员来统一发现问题。要统计分析测试的逃逸率，包括逃逸到测试侧以及客户侧的缺陷。

 

什么是有效的质量控制

1.如果有唯一一条对测试的建议，就是快速获取反馈，最好的是几分钟就能得到反馈

2.让听得到炮声的人做出决策、而不是远离一线的人员做决策。

3.内建质量，所有人都对质量负责，质量不是QA部门的专属

4.结对变成、结对测试、结对设计、结对上线，让结对无处不在

5.要关注非功能需求，并且提前考虑

6.测试与框架有关，包括技术架构以及组织架构

7.测试的过程，是从失败中学习的过程

8.尽可能的自动化一切该自动化的测试，但又不要过度追求自动化。

 

测试能防范所有的问题吗

1.当然不能，有两种安全策略，一种是试图发现尽可能多的问题，甚至是消除错误的部分，达到绝对的安全，这种情况太理想。所以推荐第二种方法，构筑弹性安全，发现了错误，能具备快速恢复的能力。

 

什么是测试金字塔

1.测试金字塔的核心是从关注测试的数量，转而向关注测试的质量，尤其是在持续集成下，测试执行时间要求是快速闭环的。金字塔越往下层，隔离性越高，定位问题就约精准，反馈也越快，应该投入更多的精力， 自动化程度应该越高；金字塔越往上层，反馈周期越长，运行效率月底，修复和维护的成本更高。复杂性也随之升高，应该做的频度越低，修复和维护的成本就越高，复杂性也随之升高应该做的频度越少，自动化程度不宜过高。

2.对于能够接触到生产环境的企业自上而下包括：性能和安全测试

 

合并请求的提交要清晰

1.一个好的合并请求不只是代码的事情，还牵扯到代码审查者对代码的审查，所以开发者不仅要写出好的代码，还需要考虑如何让其他人更清晰的理解自己的想法和思路，这是一个用代码做交流的过程

-进行较小的合并请求

-每个合并请求只做一件事情

-代码行的字数，最好少于80个字

-避免重新格式化代码

-确保提交的代码能够编译通过并能通过所有测试

-详细记录下自己提交的原因

-避免重复修改和混入其他的merge

• 还没有人评论，欢迎说说您的想法！