软件测试教程 第五节 敏捷篇
我们在之前介绍了测试用例的各种设计方法。但是存在的一个问题是：越来越多的公司开始使用敏捷的开发模式，轻文档甚至无文档，需求不明确，测试时间越来越短。这对我们的测试设计带来了很大的挑战。
在这时我们需要更多的测试手段来进行测试。
在这里我们将回答以下问题
探索性测试
code review
代码静态分析
CI/CD
探索性测试
留给测试的时间越来越短，我们没有大量的专属时间来设计用例，然后再去执行了。这时候我们需要边设计边测试，这就是探索性测试。
在日常生活中，我们其实经常会进行探索性测试：例如我们买了一部新手机，试试拍照怎么样
什么是探索性测试（ET）
在概念上说，探索性测试是一种测试风格，而不是某一种具体的测试方法（等价类测试/边界测试等），它强调系统软件学习，设计测试用例以及测试执行同时进行,他适用于要求在短时间内以及测试需求频繁变更下寻找出重大缺陷的情况。
1、探索性测试是手工测试
2、探索性测试仍然需要写文档，但是在测试执行中写
3、探索性测试的缺点是可能没有重点，无法保证测试覆盖率，无法度量质量
4、探索性测试是有指导方法的自由测试
5、在项目中推荐用例测试和探索性测试同时进行。
6、测试的五个问题：漫无目的、重复、暂时性、单调性、健忘
探索性测试的来源
探索性测试是由测试专家Cem Kaner博士在1983年的时候提出。测试专家James A. Whittaker曾经是Cem Kaner佛罗里达工学院的同事，后来担任微软测试架构师以及Google总监，基于在这些公司的工作经验，他撰写了《Exploratory Software Testing》一书，进一步拓展了探索性测试的概念和方法。
探索性测试的指导思想
探索性测试跟传统的测试方法有很大的不同，在过去一般都是按照先编写完整的测试用例以及计划，然后再进行测试执行，最后再进行测试结果分析。与这种“先设计后测试”的思路有巨大的不同，在探索性测试中，软件学习，软件用例设计以及软件测试执行同时进行，这个适用于要求在短时间内或者在测试需要频繁变更下快速发现重大缺陷的情况。
探索性软件测试的三个目标：
1、理解应用程序的工作逻辑和原理，接口，以及实现了哪些功能
2、尽量了解熟悉软件的所有功能
3、寻找缺陷
这三个目标说明了我们的测试不是漫无目的的。所有的测试都应该围绕着软件功能来进行，而优先保证的是要实现的业务是正确的。
探索性测试方法
旅行者的漫游探索性测试方法
我们可以将软件的测试比做是去一个城市的旅游。那么我们如何快速的去到我们想去的地方呢？一个办法就是我们对这个城市很熟悉。另外一个办法就是找一个导游或者一份地图，用来指导我们去在这个城市旅游。
对于软件测试来说，我们同样需要对被测软件很熟悉，同时也需要一份测试地图或者测试指南，来帮助我们更好的探索性测试。
拿到地图后，我们可以根据地图将城市按照功能分为各种区域，比如：商业区，历史区，娱乐区，旅游区，旅馆区，破旧区等。而每个区域对应软件相应的功能。比如：
商业区：是工作得以完成的地方，对于旅游者来说没什么意思。对应软件包装上面的对应特性，类似我们的需求。
历史区：上一个版本遗留下来的代码、问题或则曾经出现多次bug的功能或者特性。
娱乐区：对应软件的辅助特性和功能，可以做完补充测试。
旅游区：旅游者聚集的地方，目的是为了到此一游。对应产品的某些特性和功能可以吸引新的用户，然而老用户不在使用它们。
旅馆区：旅游者的休息之处，所以旅馆区测试时指软件测试人员放过那些主要和最受欢迎的功能，而去测试在测试计划中较少描述的次要及辅助功能。
破旧区：对应软件的历史稳定的代码，一般很少人去接触
一、商业区测试方法：
指南测试法：城市的旅游手册通常都归纳出一些实现选好的景点，测试这些区域是非常重要的。要求测试人员通过阅读用户手册并验证遵守手册的建议执行操作。如果是帮助手册，请以完全不了解系统视角严格按照其使用进行操作。
案例：
1、手机的用户操作手册测试
2、用户注册时的完整流程
卖点测试法：发现软件最吸引人的这些特性功能，锁定测试范围。此方法是鼓励测试人员观看销售给客户演示的Demo，理解销售的角度哪些功能对客户来说是最大的卖点，他们未必就是核心功能，但值得测试人员把它们当核心功能来对待。同时，也许刁钻的客户会提出各种质疑，这些质疑和稀奇古怪的问题也可以纳入测试人员的设计中。
案例：
1、nubia手机的卖点是拍星星，怎么拍？怎么测试？
地标测试法： 在旅游的时候，如果我们设计了要到访的地方，通常会在地图上插上旗子，这就是地标。但是没有人规定我们应该按照何种顺序去到访这些地标。不同的测试人员可能会选择不同的顺序，有经验的测试人员会基于对软件产品架构和技术层面的理解，采取一些古怪的路径但更可能发现缺陷。
案例：
1、用户注册时有注册信息、激活、完善信息、登录等，我们可以在注册后就直接去登录
极限测试法：一个学者不断的质疑导游的各种说法。向软件提出难以回答的问题，比如最大可以发挥到什么程度，承受多少用户，承载多少数据。那个特性或功能会把软件逼到极限运作，哪些输入和数据会消耗软件最多的计算能力？哪些输入可能绕过它的错误检测？
案例：
1、用户注册时将所有的注册信息都输入到最大值，然后注册，最大值的email地址能否成功注册并登录？
2、手机空间满进行拍照
快递测试法：快递运送的货物，就好比软件里的数据，结果不同的地点转接，拆包装包最终到底目的地。主要关注关键数据流的走向，比如：输入一个数据后，最后该数据会去哪里
案例：
1、用户注册时填写的姓名、email等最后在哪里可以看到？个人信息？两者是否一致？
2、用户注册完善的信息在哪里可以看到？
深夜测试法：城市灯火阑珊会在午夜过后逐渐安静下来，商场店铺纷纷打烊。但是软件不应该停止工作，软件测试人员有时应该刻意的关注在冷门时间段软件所做的附属工作，比如数据备份归档、维护监控任务的运行等等。
遍历测试法：选定一个目标（比如：所有菜单项、所有错误框），然后用最短路径来访问这些目标对象，从而遍历完所有的路径点；
案例：
1、检查用户填写注册信息时，检查所有的输入错误提示，包括输入不符合要求，两个密码不一致，验证码不正确、没有输入等各种提示语
二、历史区类型：
恶邻测试法：在测试的过程中，当发现某一段代码的bug很多的时候，我们可以专门针对这段代码进行遍历测试，通过这样的方法很容易发现改动引发的bug。
类似于错误猜测法
博物馆测试法：找到那些遗留和很长时间没有被翻动的老代码，看看在新的环境是否可以运行，比如：某一个脚本可能就直接失效了。
回归测试的重要性
上一版本测试法：对先前版本的更新，运行上一个版本所有的分支和测试用例。确保老的功能还能正常使用。如果新版本更新或者删除了功能，应该仔细检查新版本无法运行的用例，保证没有遗漏必须的功能。
测试之前进行代码比较，确认差异项，然后进行测试
三、娱乐区类型：
配角测试法：鼓励测试人员关注某些特定的特性，并将这些特性与主流业务特性放在一个视角来测试；比如：一个菜单有多个选项，我们通常选择第2个选项，那么我们可以去测试第3个选项。
案例：
1、注册时选择不同意用户协议
深巷测试法：最不可能被用到的用户特性以及没有被覆盖过的代码；以及将不常用的特性和最常用的特性进行结合起来使用。
案例：
1、手机输入法中的帮助菜单
2、不常用的子功能，例如手机百度输入法中-设置-调整高度的功能
通宵测试法：尽可能不关闭程序，让程序一直去运行。比如：移动设备的某一个后台程序可能就是一直运行的。
案例：
1、手机不关机，一直运行，看新通知提示是否正确
四、旅游区类型：
收藏家法：建议我们收集软件的输出，收集的越多越好。然后可以将这些搜集进行梳理，可能会收到一些意想不到的惊喜。
案例：
测试中我们经常做的容错测试可以理解为是收藏家测试法的一种，通过输入不同的内容，看是否能输出合理的信息
1、注册时各种输入各种正确、不正确的信息，看能够注册
2、输入各种异常姓名，例如：英文、繁体、简体、阿拉伯语、特殊字符、数字等等，查看校验情况
长路径法：那些需要被点击N次才能激活的特性点，把那个埋在应用程序最深处的界面作为测试目标；
案例：
1、注册-激活-完善信息-登录-个人信息-修改头像
超模测试法：是一种纯界面测试方法，它的原理是不关注特性，而只关注界面的设计是否给我们带来愉悦感。针对UI的表面测试，衡量软件的展现能力。
功能测试中的界面测试
测一送一法：它只测试同时运行同一应用程序多个拷贝的情况。比如：运行一个应用程序，然后再去运行该应用程序的一个拷贝。
案例：
email注册一个email只能注册一个用户
1、两个用户同时用一个email进行注册，再先后进行激活，后激活者能成功么？能同时注册么?
苏格兰酒吧测试法：适用于大规模软件，测试角落中不易找到的功能。
五、旅馆区类型：
取消测试法：此方法的思想是启动了立即停止，特别是一些运行流程比较耗时的功能如备份还原或者搜索，在启动之后，立即取消。发散一点还可以变成，启动一个耗时操作，不停止立即启动另外一个耗时操作，以此来检测应用程序的自我清除能力。
案例：
1、手机开机过程中关机
2、用户注册时，激活后在完善信息时取消
懒汉测试法：软件必须处理默认值，它必须运行处理空白输入的代码，很多输入不填写就直接进入下一步等等；选择尽可能少的输入，能不输入尽量不输入，能不修改尽量不修改，观察应用程序是否能响应得出正确结果
案例：
1、注册时，不输入任何值
2、检查默认值，比如用户注册协议默认是否勾选
六、破旧区测试类型
破坏测试法：强迫软件做一些操作；掌握软件成功完成操作必须使用的资源；在不同程度上移除那些资源或限制使用那些资源；
案例：
1、注册时，断掉网络
2、发送激活邮件时，关闭邮件发送服务器
反叛测试法：故意输入一些最不可能的数据或者已知的恶意输入，然后判断程序如何去处理；
案例：
注册时，输入空格作为姓名
强迫症测试：一遍又一遍的输入同样的数据，反复的做一些同样的操作；
案例：
1、注册用户再次注册
2、已激活用户再次激活
code review
在敏捷中，质量提升是需要全员参与的
为什么执行review
1、代码评审可以及时发现一些容易发现的BUG，而不必将发现BUG的时间点推迟到测试阶段。
2、码评审可以保证至少有两个人都理解任何一份代码。当出现员工休假，离职等情况的时候，至少保证团队的代码不会陷入无人理解或者无人处理的状况。
3、代码评审的最大好处是纯社会性的，当你知道你的每一行代码都有另外一个人看，自然而然会更加卖力的表现，拿出最好的状态编码，因为每个人都有虚荣心嘛。
代码评审的流程有以下两种：
1、提交前评审(pre-pushcode review)
- 程序员在试图提交代码变更到代码库之前，先提交变更申请，变更申请包含了这次变更的内容，评审人；
- 评审人查看变更内容，评估变更，与变更申请人沟通，评估是否通过变更；
- 如果评审人通过变更，则变更申请人才可以提交代码到代码库；
- 如果评审人不通过变更，则变更申请人需要根据讨论结果或评审建议做出修改，直到与评审人达成一致，通过评审，才可以提交代码到代码库；
2、提交后评审(post-pushcode review)
程序员提交变更代码到代码库；
评审人审查这次变更的内容，如果评审通过，则标记此次的变更已审查；
如果评审人有疑义，则与变更人沟通，变更人根据讨论结果或评审意见做出修改，知道与评审人达成一致，通过评审。
提交前评审对比提交后评审有诸多好处
1、程序员会更积极的将变更的代码组织的更好，更模块化，更容易阅读；
2、评审人有机会在代码提交之前发现问题，或给出更好的建议，对应的程序员对这样的反馈更容易接受；
3、评审人给出建议或意见之后，相比提交后评审，程序员会更加积极的最反馈做出响应；
4、评审人会更加认真的对变更进行评审，并且发现问题后会更加积极的参与讨论，对发起变更的程序员提供支持；
5、在真正提交变更前发现问题并予以解决显然比提交后再进行评审，然后提交修改补丁更好；
**提交后评审对比提交前评审有诸多好处 **
1、post-push code review 更加容易实施，过程对现有的组织架构和流程没有完全的颠覆，对团队成员的要求没有那么高；
2、 相比pre-push code review，post-push code review不需要对修改代码&提交变更这个过程中断，不需要等待评审的时间；
3、可以作为组织向pre-push code review过程实施的过渡训练；
常用工具：
Phabricator、 Review Board、gitlab等
代码静态分析
代码静态分析（Program Static Analysis）是指在不运行代码的方式下，通过词法分析、语法分析、控制流、数据流分析等技术对程序代码进行扫描，验证代码是否满足规范性、安全性、可靠性、可维护性等指标的一种代码分析技术。
代码静态分析可以在开发阶段就找到一些bug，尤其是黑盒测试难易发现的bug，如资源未释放等。
代码静态分析的特点
代码静态分析是与程序动态分析相对应的代码分析技术，它通过对代码的自动扫描发现隐含的程序问题，主要具有以下特点：
（1）不实际执行程序。动态分析是通过在真实或模拟环境中执行程序进行分析的方法，多用于性能测试、功能测试、内存泄漏测试等方面。与之相反，静态分析不运行代码只是通过对代码的静态扫描对程序进行分析。
（2）执行速度快、效率高。目前成熟的代码静态分析工具每秒可扫描上万行代码，相对于动态分析，具有检测速度快、效率高的特点。
（3）误报率较高。代码静态分析是通过对程序扫描找到匹配某种规则模式的代码从而发现代码中存在的问题，这样有时会造成将一些正确代码定位为缺陷的问题，因此静态分析有时存在误报率较高的缺陷，可结合动态分析方法进行修正。
代码静态分析的工作内容
类型检查
风格检查
bug查找
安全漏洞
代码静态分析的时机
1、在编码时检查，在IDE中集成对应的插件
2、编码完成后统一检查
建议采用第一种方式
常用工具：
Pclint，checkstyle，pmd，findbugs，hp fortify，sonarqube
CI/CD、devops
持续集成是什么（CI）
持续集成（ContinousIntergration，CI）是一种软件开发实践，即团队开发成员经常集成它们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的编译、发布、自动化回归测试来验证，从而尽快地发现集成错误。许多团队发现这个过程可以大大减少集成的问题，让团队能够更快的开发内聚的软件。
持续集成是为了持续交付。
没有单元测试的持续集成基本无意义。
持续部署是什么（CD）
持续部署（ContinousDelivery，CD）在持续集成的基础上，将集成后的代码部署到更贴近真实运行环境中。比如，我们完成单元测试后，可以把代码部署到测试环境中，交付给质量团队或者用户，以供评审。如果评审通过，代码就进入生产阶段。
对于测试最大的好处是节约时间！
设想一下，一个常规的测试过程：开发送测一个版本---测试人员从配置库下载版本---编译版本---部署到测试环境---进行冒烟测试---进行功能测试。
而这些过程完全可以由CI/CD来替代。
DevOps：
DevOps 是一个完整的面向IT运维的工作流，以 IT 自动化以及持续集成（CI）、持续部署（CD）为基础，来优化程式开发、测试、系统运维等所有环节。
目标：
让生产端变得敏捷起来！
DevOps实际是一种文化上的变迁，代表了开发、运维、测试等环节之间的协作，因此DevOps工具是非常多种多样的，甚至可以由多种工具组成一个完整的DevOps工具链。此类工具可以应用于一种或多种类别，并可体现出软件开发和交付过程的不同阶段：
编码：代码开发和审阅，版本控制工具、代码合并工具
构建：持续集成工具、构建状态统计工具
测试：通过测试和结果确定绩效的工具
打包：成品仓库、应用程序部署前暂存
发布：变更管理、发布审批、发布自动化
配置：基础架构配置和部署，基础架构即代码工具
监视：应用程序性能监视、最终用户体验
工具：
- 版本控制&协作开发：GitHub、GitLab、BitBucket、SubVersion、Coding、Bazaar
- 自动化构建和测试:Apache Ant、Maven 、Selenium、PyUnit、QUnit、JMeter、Gradle、PHPUnit
- 持续集成&交付:Jenkins、Capistrano、BuildBot、Fabric、Tinderbox、Travis CI、flow.ci Continuum、LuntBuild、CruiseControl、Integrity、Gump、Go
- 容器平台: Docker、Rocket、Ubuntu（LXC）、第三方厂商如（AWS/阿里云）
- 配置管理：Chef、Puppet、CFengine、Bash、Rudder、Powershell、RunDeck、Saltstack、Ansible
- 微服务平台：OpenShift、Cloud Foundry、Kubernetes、Mesosphere
- 服务开通：Puppet、Docker Swarm、Vagrant、Powershell、OpenStack Heat
- 日志管理：Logstash、CollectD、StatsD
- 监控，警告&分析：Nagios、Ganglia、Sensu、zabbix、ICINGA、Graphite、Kibana