软件测试新理念

随着社会的不断发展和环境的更新，对于时代赋予的使命也发生了翻天覆地的变化，然而在软件行业中软件测试在IT环境中也悄然的由量变到质变的过程以下内容是针对新旧理念而做的一个简单整理，欢迎讨论发言

软件测试的概念

传统“软件测试”定义：在规定的条件下对程序进行操作以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程
但是，软件工程发展到今天，测试要解决的早已不仅仅是 传统测试的流程了，而是尽可能的阻止问题的产生，一切有利于提高软件质量的行为都是测试人员和团队需要考虑的，质量是整个团队的目标，仅依赖于找bug，就像是只有守门员的球队，漏球是迟早的事情
现代软件测试定义：
怎么阻止问题的产生？沟通！！
在现代工程软件环境中，测试人员需要作为桥梁，协调团队各方，确保所有人对软件的设计要求和理解，都达成一致，帮助研发人员写出高质量的代码，从而减少bug的产生，所以软件测试是通过主动沟通，使得团队对需求理解一致，同时定位和督促修复问题，确保软件各方面符合需求的过程。

测试的七大原则

传统测试的七大原则：
1：尽早测试：就是越早测试越好，问题早发现，早治疗
2：穷尽测试是不可能的：指测试时考虑到所有输入条件和组合，这显然是不现实的
3：测试显示缺陷的存在：测试如果找到缺陷那就说明存在问题，但是如果没有找到缺陷，也不能说明没问题
4：缺陷具有集群性：意味着往往绝大数缺陷都会集中在某一小部分模块中
5：杀虫剂悖论：其实就是抗药性，如果重复用相同的测试用例或者方法手段，很难发现新的问题
6：测试是上下文相关的：就是不同类型的软件需要执行不同类型的测试，侧重点也会不同，就好比牙疼医生会用拔牙工具，骨折了医生会打石膏，不同的软件，用不同的方法
7：无错误谬论：简单来说，方向不对，一切白费，软件如果偏离了既定需求，即使所有的缺陷都发现完了，这个产品也是有问题的，
这些原则都是有一定的历史背景因素，更多关注的是测试执行层面，但是现代软件工程仅仅关注测试执行已经无法满足质量目标了，以下的现代测试原则值得关注

升级版原则：
1：以推进可交付的产品为先：可以最终交给客户、用户、市场的产品
2：达成质量目标，不能仅依赖测试：测试仅仅是确保质量的一部分，而非确保质量的全部
3：没有最佳测试，只有适合的测试：需要结合实际情况采取最合适的测试方案。己之蜜饯，乙之砒霜
4：更重视测试设计，而非关注测试执行：测试是门艺术，讲究的是对整体的把控和细节的敏感度，拍脑门的测试设计会把团队和质量带入无尽的深渊
5：测试是基于风险的平衡：虽然任何产品我们都期望能有完美的质量，遗憾的是测试往往只是在，需求、预算和时效中寻求最有平衡
6：重视客户和市场的反馈：闭着眼一条道走到黑是行不通的~
7：宣传质量文化，推广质量理念,而非充当守门员：bug数量是无穷的，只有将团队成员的整体质量意识提升起来，对于软件质量才能有整体的提升
可以看到这些都符合测试先行的理念，质量是整个团队的责任和目标

敏捷测试

敏捷软件开发宣言
核心价值观：
1.个体和互动高于流程和互动
2.工作的软件高于详尽的文档
3.客户合作高于合作谈判
4.响应变化高于遵循计划
十二条原则：【对四个核心价值观的进一步延展】
敏捷核心：将大任务分解为 短频快的流程，频繁的将可以工作的软件进行交付，使得各方面充分沟通，及时反馈及时调整，避免出现“早怎么不说”“这根本不是我想要的”等情况

但敏捷不能为了敏捷而敏捷，尽管核心价值观的右项有其价值，但是敏捷测试更注重核心价值观的左项价值， 因为传统的右项一样有价值，只是在敏捷测试里更重视左项价值。
因此敏捷的实施一定要根据团队和项目的实际情况来，因为大多数商业环境中，更看重清晰可控的流程和文档，也不是所有团队可以持续频繁的交付，更不是所有软件都需要频繁的被交付，更重要的是客户的合作、是基于信任，不是流程
【面试也是如此，如果面试官跟你交流过后发现你的思路跟他的不一致，那么也就无法建立信任，这也是人际交往的基础，但是这是需要时间去慢慢磨合的，这就很矛盾了，软硬实力都要有这就对自身素质的要求就更高了，社会的发展也是这样慢慢磨合的因此不要太过焦虑，加油哈】

敏捷测试也是在敏捷软件开发思想指导下的产物，敏捷往往是先开枪，再瞄准，先迈出第一步，快速响应、快速试错、快速调整。那敏捷测试其实就应该做到，先测试，再实现，
1.测试需要更深入、完整的理解整体需求和细节
2.需求评审阶段就可以先设计测试用例
3.重视单元测试，部署持续集成和持续交付（CI/CD）
4.在条件允许的条件下，尽可能实现测试自动化
5.通过每次的反馈、总结、优化测试用例，调整测试设计和策略

先测试再实现，其实就是测试先行的原则：
通俗的理解为：
1.需求的理解和统一也是一种测试
2.先设计的测试用例，开发甚至可以参考来写代码，因为测试用例其实就是需求的抽取俱现
3.持续集成和交付，可以确保每次新增的功能，都不会破坏原有的软件，软件是可以一直使用的
4.测试自动化一旦部署，团队就能在关键部分投入更多的精力。比如：通过SBTM(基于测程的测试管理)提高测试的广度和深度
5.调整测试设计和策略，可以避免杀虫剂效应（如果重复用相同的测试用例或者方法手段是很难发现新的问题的）
所以敏捷测试需要先做到先测试、再实现、测试先行，当然也别忘了最重要的是沟通

SCRUM是敏捷软件开发流程的一种
关键词：
product owner （产品负责人）：主要梳理需求，确定产品方向
scrum master （团队协调者）：让团队高效运转
sprint cycle （一个迭代周期）：在这个周期内完成某一些功能的开发、测试、部署
backlog（需开发的功能列表）：分为product backlog（整个产品的功能列表）、sprint backlog（一个迭代周期需要完成的功能列表）
burndown chart（燃尽图）：用来展示理想和实际的进度比对
story point （故事点）：完成某个功能需要的工作量
dome （产品演示）
SCRUM流程：Scrum master 组织团队 对产品进行梳理，这时product owner 向团队详解 product backlog里的产品功能，接着团队每个人都用故事点，估算每个功能需要多久完成，评估完成后，product owner 根据情况，挑一些功能放进 sprint backlog中，开始一个sprint的迭代循环，sprint完成后演示这个周期的工作成果，同时复盘然后重复以上内容，知道所有需求实现。

两个关键点：
1.故事点可以带上单位，比如人天（工作量的一种计量方式;一天一个人能干多少活，一个人一天的工作时间），这样计算方便
2.功能完成：是指测试完成没有问题，不是仅仅是开发完成
而scrum就是把传统大又长的流程，分解为短频快的流程，同时让各个利益方充分沟通，这就是多方合作、小跑快跑、快速迭代

自动化测试

一、定义：自动化测试就是把人工执行的测试，通过工具或者代码，转化为机器执行，测试开始后就不用管了，直到最终对测试结果查看分析即可
二、自动化测试的关键认知：
1.自动化测试不是万金油，它有很多限制条件
比如：自动化测试环境的搭建、代码的编写和维护都需要时间和人力投入，如果代码只执行一两次、项目周期非常短、需求变更很频繁，这都不适合做自动化测试
2.自动化测试的自动化指的是无人值守。也就是说从测试开始，到最后团队收到测试结果中途不需要人的介入，这才是自动化测试，如下图

3.自动化测试的目的，不是发现bug，自动化测试可以替代一些冒烟测试和回归测试，加快测试结果的反馈，但是不具备启发式的测试能力，所以很难发现新的bug，

（1）冒烟测试：覆盖系统的主要功能，以确定程序中最关键的功能可以工作每天的构建版本和冒烟测试是行业最佳实践之一
（2）回归测试：在修改问题后对先前测试的程序进行重新测试，以确保问题得到修改，并且不会引起新的问题

因此，它的目的更多是确保软件基础功能的正常，而不是用它找bug，需要与其他测试相辅相成，做到合理的测试分布，有助于提高软件质量，自动化测试不会雪中送炭，只能锦上添花，当测试质量或者进度出现问题的时候，首先要考虑，测试策略、计划、方法是否合理，甚至重新审视需求，也不要盲目考虑自动化测试，自动化测试虽好但是也不能乱用

测试自动化

定义：在软件测试中的任何方面都通过各种自动化的方式和手段来加快测试结果的效率和测试结果的反馈

简单理解就是自动化测试只是测试自动化的一部分而已，也就是说，除了执行测试本身的操作，其他一切过程都可以用工具或者代码来实现
比如：测试任务的分发、测试数据的准备、生成,测试结果的收集、统计，持续集成、持续部署、持续交付，以及各种提升各个环节效率的小代码、小工具

测试自动化并不需要一整套完整的机制，它更多的体现在一点一滴提升测试效率、加速测试反馈的思想上，就如在敏捷测试中提到的，测试自动化，可以让团队在关键部分，投入更多精力，来进一步提高软件质量