DevOps1.软件危机背景落后的软件生产方式无法满足迅速增长的计算机软件需求导致软件开发和维护过程中一系列的问题。于是诞生了软件工程的方法去解决软件危机。2.软件工程的核心思想把其他行业和领域里的工程化经验借鉴过来以系统性的、规范化的、可定量的工程化方法来开发和维护软件。包括相应的流程、工具、方法论等。3.敏捷核心思想由于软件开发难以准确预测工程化的思想和方法并不完全适用于软件开发于是诞生了敏捷思想对软件工程进行纠偏。敏捷软件开发宣言指出个体和互动高于流程和工具工作的软件高于详尽的文档客户合作高于合同谈判响应变化高于遵循计划。总之右项有价值但更偏于左项。4.精益核心思想更关注流动效率而不是资源效率。不停地消除任何不增加价值的工作。5.持续集成核心思想是一种软件开发实践即团队成员经常集成他们的工作每次集成通过自动化的构建包括测试来验证从而尽快检测出集成错误。例如一个软件开发6个月然后集成测试2个月就一定不是持续集成。持续表示均匀、频繁集成表示汇聚、测试。6.持续交付核心思想是一种软件开发实践令软件可以随时发布上线。为此需要持续地集成软件开发成果构建可执行程序并运行自动测试以发现问题进而把可执行程序逐步推送到越来越像生产环境的各个测试环境中并测试以保证它最终可以在生产环境中运行。是持续集成的延伸延伸到各类测试直到发布中间就会牵扯到测试环境和生产环境如何管理、配置、部署回滚人工测还是自动化测等问题。频繁程度小于持续集成。7.DevOps起源和演化7.1.瀑布是典型的预见性方法严格遵循预先计划的需求、分析、设计、编码、测试的步骤顺序进行上一阶段的输出作为下一阶段的输入。大体分为需求分析、设计、编码、测试、维护几个阶段。缺点是只有在项目生命周期后期才能看到结果尤其是不适应用户需求变化。7.2.敏捷由于软件开发难以准确预测工程化的思想和方法并不完全适用于软件开发于是诞生了敏捷思想对软件工程进行纠偏。敏捷是强调轻量的过程方法论强调拥抱变化而不是与之对抗。与客户亲密合作取代合同约定。多数都采用迭代/增量开发的过程模型。敏捷软件开发宣言指出个体和互动高于流程和工具工作的软件高于详尽的文档客户合作高于合同谈判响应变化高于遵循计划。总之右项有价值但更偏于左项。7.3.DevOps软件交付模式发生变化是诞生背景。Dev开发团队关注把新功能实现并上线Ops(运维包括测试)团队关注上线后运行的稳定性两个团队需要协作。devops促进软件开发、技术运营和质量保障等部门间的沟通和协作。特点有“大系统小做”服务/微服务架构师快速创新的技术基础小批量/小粒度频繁的发布和部署平滑集中部署的风险运营驱动开发小步快跑唯快不破运营中持续开发用开发构筑运营竞争力自营合营的运作模式变“卖产品”为“卖服务”打破研发和运营团队之间的界限。“自己开发自己运营”传统交付方式交付整系统测试整系统。devops模式交付以微服务为主微服务独立发布。支持微服务独立开发、验证与上线。8.devops三步工作法快速流动持续交付流水线等、快速反馈、持续学习与实验。9.devops与软件技术的演进是相互促进的开发过程从瀑布--敏捷--devops应用架构从单体--分层--微服务部署与打包从物理机--虚拟机--容器应用基础设施从数据中心--托管服务--云10.软件交付的效能度量指标部署频率越高越好变更前置时间越小越好服务恢复时间越快越好变更失败率越低越好11.DevOps的追求目标效率要兼顾需求吞吐量和需求响应时长质量不是越高越好而是要适合业务质量由问题出现量和问题修复时长共同决定兼顾短期和长期12.总结DevOps和CI/CD的定义DevOpsDevelopment Operations开发和运维。DevOps更偏向于一种对于文化氛围的构建。DevOps也即是促使开发人员与运维人员之间相互协作的文化。CICONTINUOUS INTEGRATION持续集成。指的是开发人员频繁的一天多次的将所有开发者的工作合并到主干上。这些新提交在最终合并到主线之前都需要通过编译和自动化测试流进行验证以保障所有的提交在合并主干之后的质量问题对可能出现的一些问题进行预警。持续集成的核心在于确保新增的代码能够与原先代码正确的集成。CDCONTINUOUS DELIVERY持续交付。侧重点在于交付其核心对象不在于代码而在于可交付的产物。由于持续集成仅仅针对于新旧代码的集成过程执行了一定的测试其变动到持续交付后还需要一些额外的流程。与持续集成相比较持续交付添加了测试Test-模拟Staging-生产Production的流程也就是为新增的代码添加了一个保证确保新增的代码在生产环境中是可用的。持续部署CONTINUOUS DEPLOYMENT指的是通过自动化部署的手段将软件功能频繁的进行交付。与持续交付以及持续集成相比持续部署强调了通过自动部署的手段对新的软件功能进行集成。同持续交付相比持续集成的区别体现在对生产的自动化。从开发人员提交代码到编译、测试、部署的全流程不需要人工的干预完全通过自动化的方式执行。这一策略加快了代码提交到功能上线的速度保证新的功能能够第一时间部署到生产环境并被使用。版本控制工具Git1.什么是版本控制版本控制是一种记录一个或若干文件内容变化以便将来查阅特定版本修订情况的系统方便查看更改历史备份以及恢复以前的版本保证多人的协作不出问题。2.版本控制的起源与历史diff与patch是两个比较源码和补丁的工具diff比较两个文件得出差异patch是diff的反向操作它通过一个文件和差异结果反推出另一个文件。diff的用法diff -u left.c right.cpatch的用法patch left.c diff.txt 、 patch -R right.c diff.txtRCS是最早期的本地版本控制工具CVSSVN是集中式版本控制工具Git是分布式版本控制工具3.集中式CVSSVN与分布式git的差异集中式工具记录差异Git是记录快照。集中式只有脆弱的中央库Git有强壮的分布库。SVN不适合跨地域的协同开发Git不适合Word等二进制文档的版本控制解决方法版本库按照目录拆分4.linux下安装git4.1.包管理器方式安装sudo aptitude install git、sudo aptitude install git-doc git-svn git-email gitkUbuntu、Debian的yum install git、yum install git-svn git-email gitk RHEL、Fedora、CentOS 等4.2.从源代码安装访问Git的官方网站 http://git-scm.com/ 。下载Git源码包例如git-2.19.0.tar.gz。解压后进入目录tar -jxvf git-2.19.0.tar.bz2、cd git-2.19.0、安装方法写在INSTALL文件当中参照其中的指示完成安装。下面的命令将Git安装在 /usr/local/bin 中 make prefix/usr/local all、sudo make prefix/usr/local install安装Git文档可选make prefix/usr/local doc info、sudo make prefix/usr/local install-doc install-html install-info自动补齐bash-completion软件包提供命令补齐功能安装方法将Git源码包中的命令补齐脚本复制到bash-completion对应的目录中:cp contrib/completion/git-completion.bash /etc/bash_completion.d/重新加载自动补齐脚本使之在当前shell中生效: . /etc/bash_completion为了能够在终端开启时自动加载bash_completion脚本需要在本地配置文件 ~/.bash_profile 或全局文件/etc/bashrc 文件中添加下面的内容:if [ -f /etc/bash_completion ]; then . /etc/bash_completion fi5.Windows下安装git到 https://git-scm.com/download/win 下载 Windows 安装包例如: Git-2.19.0-64-bit.exe执行exe开始图形化安装在安装过程中会询问是否修改环境变量。建议选择“Use Git Bash Only”即只在 MinGW 提供的shell环境中使用Git不修改 PATH 环境变量避免 Git 自带的工具与 Windows 下已有的产生冲突。安装完成后我们可以在 Windows 任意目录下右键单击选中 Git Bash 启动 Git Bash。git version 查看安装的 git 版本信息Windows下除了git还有一个就是基于msysGit的图形界面工具——TortoiseGit人称小乌龟。访问网站 http://code.google.com/p/tortoisegit/ 下载安装包然后根据提示完成安装。6.总结git基本配置Git有三种配置分别以文件的形式存放在三个不同的地方。可以在命令行中使用git config工具查看这些变量系统配置对所有用户都适用存放在git的安装目录下%Git%/etc/gitconfig若使用 git config 时用 --system 选项读写的就是这个文件git config --system core.autocrlf用户配置只适用于该用户存放在用户目录下。例如linux存放在~/.gitconfig若使用 git config 时用 --global 选项读写的就是这个文件git config --global user.name仓库配置只对当前项目有效当前仓库的配置文件也就是工作目录中的 .git/config 文件若使用git config 时用 --local 选项读写的就是这个文件git config --local remote.origin.url6.1.配置个人身份git config --global user.name “Zhang San” ----个人名称git config --global user.email zhangsan123huawei.com ----个人邮箱6.2.文本换行符配置假如你正在和其他人合作他们在Windows上编程而你却在其他系统上在这些情况下你可能会遇到行尾 结束符问题。 这是因为Windows使用回车和换行两个字符来结束一行而Mac和Linux只使用换行一个字符。 虽然这是小问题但它会极大地扰乱跨平台协作git config --global core.autocrlf true 可以在你提交时自动地把行结束符CRLF转换成LF而在签出代码时把LF转换成CRLFgit config --global core.autocrlf input 把core.autocrlf设置成input来告诉Git在提交时把CRLF转换成LF签出时不转换。这样会在Windows系统上的签出文件中保留CRLF会在Mac和Linux系统上包括仓库中保留LFgit config --global core.autocrlf false 假如正在开发仅运行在Windows上的项目可以设置false取消此功能6.3文本编码支持# 中文编码支持git config --global gui.encoding utf-8git config --global i18n.commitencoding utf-8 用来让git commit log存储时采用的编码默认UTF-8git config --global i18n.logoutputencoding utf-8 查看git log时显示采用的编码建议设置为UTF-8.# 显示路径中的中文git config --global core.quotepath false6.4.与服务器的认证配置http / https 协议认证设置口令缓存git config --global credential.helper store添加 HTTPS 证书信任git config http.sslverify falsessh 协议认证SSH协议是一种非常常用的Git仓库访问协议使用公钥认证、无需输入密码加密传输操作便利又保证安全性生成公钥ssh-keygen -t rsa –C zhangsan1123huawei.com添加公钥到代码平台登录代码平台、进入“Profile Settings”、点击左侧栏的“SSH Keys”、点击“Add SSH Key”,将刚生成的公钥文件的内容复制到“Public Key”栏保存即可7.总结git命令7.1、Git版本控制下有三种工程区域文件状态Git版本控制下的工程区域只有三种版本库 Repository 在工作区中有一个隐藏目录.git这个文件夹就是Git的版本库里面存放了Git用来管理该工程的所有版本数据也可以叫本地仓库工作区 Working Directory 日常工作的代码文件或者文档所在的文件夹暂存区 stage 一般存放在工程根目录 .git/index文件中所以我们也可以把暂存区叫作索引indexGit版本控制下的文件状态只有三种已提交 committed 该文件已经被安全地保存在本地数据库中了已修改modified 修改了某个文件但还没有提交保存已暂存staged把已修改的文件放在下次提交时要保存的清单中7.2、基本上库流程pull(远端库更新到本地) --每次上库之前一定要先更新避免上库后出现冲突add(新增文件添加到暂存区只有新增的文件需要 git add file)commit暂存区的文件改动提交到本地库 git commit -m 修改描述push本地库推送到远端分支git push origin 远端分支merge远端分支合并到远端master7.3、工程准备命令git init 项目名称用于在本地目录下新建git项目仓库。执行git init后当前目录下自动生成一个名为.git的目录这代表当前项目所在目录已纳入Git管理。.git目录下存放着本项目的Git版本库在此强烈不建议初学者改动.git目录下的文件内容。Git仓库下的.git目录默认是不可见的有一定程度上是出于防止用户误操作考虑。但我们日常工作中几乎全部都是基于已有的git工程进行本地开发不需要我们做新建git仓库都是从远端服务器上克隆到本地所以直接git clonegit clone用于克隆远端工程到本地磁盘。如果想从远端服务器获取某个工程那么确定自己Git账号拥有访问、下载该工程的权限获取该工程的Git仓库URL本地命令行执行git clone [URL]或git lfs clone [URL]如果你所在的项目git服务器已支持git-lfs对二进制文件进行了区别管理那么克隆工程的时候务必使用git lfs clone。否则克隆操作无法下载到工程中的二进制文件工程内容不完整。7.4、新增/删除/移动文件到暂存区在提交你修改的文件之前需要git add把文件添加到暂存区。如果该文件是新创建尚未被git跟踪的需要先执行 git add 将该文件添加到暂存区再执行提交。如果文件已经被git追踪即曾经提交过的 。在早期版本的git中需要git add再提交在较新版本的git中不需要git add即可提交。git rm将指定文件彻底从当前分支的缓存区删除因此它从当前分支的下一个提交快照中被删除。如果一个文件被git rm后进行了提交那么它将脱离git跟踪这个文件在之后的节点中不再受git工程的管理。执行git rm后该文件会在缓存区消失。你也可以直接从硬盘上删除文件然后对该文件执行 git commitgit会自动将删除的文件从索引中移除效果一样。git mv命令用于移动文件也可以用于重命名文件。举例移动目录git mv codehunter_nginx.conf config 举例重命名git mv config/codehunter_nginx.conf config/new_nginx.conf7.5、查看工作区、提交更改的文件、查看日志git diff用于比较项目中任意两个版本分支的差异也可以用来比较当前的索引和上次提交间的差异。git diff aaa bbb(两个节点或分支)git diff --cached(当前的索引和上次提交间的差异)git diff aaa bbb --name-status(只看文件列表)git status命令用于显示工作目录和暂存区的状态。使用此命令能看到修改的git文件是否已被暂存, 新增的文件是否纳入了git版本库的管理。git commit主要是将暂存区里的文件改动提交到本地的版本库。在此强调提交这个动作是本地动作是往本地的版本库中记录改动不影响远端服务器。git commit一般需要附带提交描述信息所以常见用法是git commit file_name –m “commit message”。如果要一次性提交所有在暂存区改动的文件到版本库可以执行:git commit –am “commit message”git log用于查看提交历史。默认加其他参数的话git log 会按提交时间由近到远列出所有的历史提交日志。每个日志基本包含提交节点、作者信息、提交时间、提交说明等。git log配合不同参数具有相当灵活强大的展示功能常见的如—name-status/-p/--pretty/--graph等等自行了解。7.6、推送至远端库在使用git commit命令将自己的修改从暂存区提交到本地版本库后可以使用git push将本地版本库的分支推送到远程服务器上对应的分支。成功推动远端仓库后其他开发人员可以获取到你新提交的内容。常用的推送命令格式git push origin branch_namebranch_name决定了你的本地分支推送成功后在远端服务器上的分支名其他人据此可以获取该分支上的改动内容。你的本地分支名可以与推送到远端的分支名不同 git push origin branch_name:new_branch_name7.7、分支管理查看分支git branch查看本地工程的所有git分支名称。显示结果前面带*的绿色高亮的表示当前工作区所在分支git branch –r查看远端服务器上拥有哪些分支返回的分支名带origin前缀表示在远端git branch –a查看远端服务器和本地工程所有的分支。创建分支、删除分支、更新分支git branch new_branch_name新建分支不会切换到新分支git checkout –b branch_name新建分支并自动切换到新分支git branch –d branch_name删除本地分支git branch –D branch_name删除本地分支强制删除git branch -d -r branch_name删除服务器上的远程分支。其中branch_name为本地分支名。删除后还要推送到服务器上才行即git push origin : branch_namegit checkout branch_namegit checkout除了创建分支还用来切换分支当然比较官方的叫法是“检出”。有时候当前分支工作区存在修改而未提交的文件与目的分支上的内容冲突会导致checkout切换失败这时候可以使用git checkout –f进行强制切换。git checkout对象可以是分支也可以是某个提交节点或者节点下的某个文件。git pull origin remote_branch:local_branch从远端服务器中获取某个分支的更新再与本地指定的分支进行自动合并。 相当于git fetch git merge。如果远程指定的分支与本地指定的分支相同则可直接执行git pull origin remote_branchgit fetch origin remote_branch:local_branch从远端服务器中获取某个分支的更新到本地仓库。与git pull的区别是并不会进行合并。如果远程指定的分支与本地指定的分支相同则可直接执行git fetch origin remote_branchgit merge branch_name用于从指定的分支节点合并到当前分支的操作。分支合并实际上是分支间差异提交节点的合并。git rebase branch_name合并目标分支内容到当前分支。如果你要将其他分支的提交节点合并到当前分支那么git rebase和git merge都可以达到目的。git rebase、git merge背后的实现机制和对合并后节点造成的影响有很大差异有各自的风险存在暂不在本课中展开。7.8、撤销操作git reset commit_id撤销当前工作区中的某些git add/commit操作可将工作区内容回退到历史提交节点。git reset –-mixed/hard/soft的三种参数模式涉及概念较多需要去了解。git checkout .用于回退本地所有修改而未提交的文件内容。这是条有风险的命令因为它会取消本地工作区的修改(相对于暂存区)用暂存区的所有文件直接覆盖本地文件达到回退内容的目的。但它不给用户任何确认机会所以谨慎使用。git checkout –filename仅仅想回退某个文件的未提交改动git checkout commit_id想将工具区回退检出到某个提交版本关于测试1、测试的基础理论1.1、为什么要做测试缺陷不可避免软件未正确执行可能会导致很多问题所以需要通过测试控制风险1.2、什么是软件测试描述一种用来促进鉴定软件的正确性、完整性、安全性和质量的过程。是一个包含计划、准备和测量活动的过程。目的是确认被测系统的特性并指出需求和实现之间的差异。1.3、测试的目的发现缺陷、质量评估、预防缺陷、分享信息、消除风险、建立信心等1.4、不同的测试阶段测试目的有所不同单元、集成、系统测试目的是尽可能发现失效从而识别和修正尽可能多的缺陷验收测试目的是确认系统是否按预期工作建立满足了需求的信心有些情况下目的是对软件质量进行评估从而为利益相关人提供给定时间点发布系统版本可能存在的风险的信息。回归测试通常是为了验证开发过程中的软件变更是否引入了新缺陷1.5、测试的依据是不仅仅依据产品业务的需求还要看合同要求、法律标准、行业标准等1.6、测试的开始与停止时间什么时候开始测试越早越好。越晚修复bug付出的代价就越大。什么时候停止测试要从多个维度评估例如达到了必要信心级别风险可接受时、发现缺陷的代价高于缺陷本身带来的代价时、达到测试完成标准时1.7、谁来测试测试是研发团队所有人的职责不只是测试人员的事情。1.8、基本的测试过程计划、控制、分析和设计、执行和评估、结束1.9、测试的七项基本原则穷尽测试不可能测试所有内容不可行应使用风险分析和优先级来聚焦测试投入本质上就是抽样检验。缺陷集群性二八法则无处不在。大部分缺陷集中于少部分模块杀虫剂悖论同一个用例反复测试最后将不能发现新缺陷。所以用例需求经常性的评审修改不断增加新的不同角度的用例。测试指出缺陷的存在测试能指出存在缺陷但不能证明没有缺陷。测试降低软件有缺陷的可能即使没发现缺陷也不能证明软件完全正确。absence-of-errors谬误系统的发布不取决于是否有缺陷而是取决于是否满足客户需求和期望。如果不满足用户需求找再多bug修订也没用。测试要尽早介入要尽早在软件开发中启动测试活动聚焦于测试目标开发人员也应提前测试自己的代码测试活动依赖于测试context南橘北枳。测试的目标定义、策略指定、技术选择等都要充分考虑上下文客户需求技术难度项目时间人员能力资源状态等。测试人员要主动快速响应上下文的变化。没有最佳方案不能一成不变要随时改进。尤其要重视客户的反馈现网问题、需求、抱怨和赞誉等1.10、测试人员应该具备的测试知识、领域知识、IT知识、批判性思维、自我教育等要有好奇心就是要验证一些奇怪场景。要有主观能动性。开展测试活动必备对常见错误进行判断的经验敢于提出问题的勇气探究根底的精神多维度思考的能力挑剔的眼睛专业的怀疑态度。测试活动需要良好沟通。1.11、一些测试名词错误error--缺陷bug/defect/fault--失效failures1.12、软件测试的分类按是否运行程序静态测试评审和静态分析动态测试运行程序检查结果。其中动态分为白盒与黑盒。按阶段划分单元测试测单个模块集成测试测多个模块的集成交互系统测试测整个系统验收测试以是否满足客户需求为目标按用例设计是否设计代码划分黑盒测试功能、性能、可靠性、易用性、可服务性、维护性等白盒测试按针对的质量目标划分功能、适用性、性能、安全、可靠性其他分类资料、自动化、回归代码修改后重新测试确认没有新错误引入、精准测试时间精力有限情况下对于大量用例如何挑选出最合适的部分进行测试最简单的依据是开发修改了哪些就测哪些2、测试设计2.1、为什么要做测试设计保证测试质量理清测试思路、通过用例评审避免遗漏、通过执行用例评估产品质量与需求满足度提高测试效率提前规划资源、准备人力、有效执行测试活动是测试执行的依据依据用例执行、证明用例确实执行了、记录问题支撑问题复现跟进测试进度用用例衡量测试进度留下测试资产给后续版本继承2.2、测试设计目的明确测试活动的范围和目标明确测试方法指导测试执行过程开展规范测试行为2.3、测试覆盖目的基于测试的风险分析定义被测对象覆盖的深度保障高风险的规格能够更充分的覆盖满足交付质量要求2.4、测试设计交付件包括测试方案和测试用例是测试的核心资产通过测试设计实现系统测试过程可定义、可重复、可改进。建议借助思维导图来梳理需求完成测试因子的分析与提取2.5、测试方案的目的指导用例设计、传递测试设计思路2.6、测试方案内容被测对象分析需求价值、应用场景、组网、被测边界接口、约束、继承性测试风险分析分析主要风险点识别测试重点关注点测试类型分析功能测试、性能测试、安全测试、可靠性测试……测试技术分析分析测试难点考虑应对方案自动化分析考虑自动化策略、AW设计测试环境与物料需求功能点划分2.7、三种测试设计方法处理周期亿图图示画流程图圆角矩形开始结束直角矩形操作步骤菱形是判定点。然后可覆盖不同的路径深度来设计用例状态转换亿图图示不同状态之间的转换不同的转换次数0-switch、1-switch等数据组合因子组合方法2.8、因子组合技术选择哪种组合技术依赖于被测对象的风险对于开发者测试可以同时考虑实现成本和执行成本。因子取值等价类划分、分析边界值AC将每个测试因子所有取值进行全组合。AC是覆盖最全面的覆盖方式。 缺点是对于复杂的对象组合数量太庞大。组合个数每个因子取值个数的乘积BC以一个因子组合为基准每次只改变一个因子的取值直到所有取值都覆盖到。组合个数 所有因子取值个数 因子个数 1EC每一个测试因子的每一个取值在所有测试因子组合中至少出现一次。组合个数 所有因子中取值最多的那个因子的取值个数N-Wise组合每N个测试因子的取值进行AC全组合。其中用的最多的是pair-Wise2-wise组合。组合个数 最多因子取值个数 × 次多因子取值个数举例假如三个因子分别有2/3/4种取值。那么AC组合有有 2*3*4种。BC组合有234-3-1种。EC组合有max(2,3,4)种pair-wise有4*3种2.9、做好测试设计的几个关键因素需求分析时更充分的理解需求、测试设计时系统化的思考、输出用例时科学的测试覆盖、充分利用测试因子库经验库等组织积累的经验、最后进行评审可以更容易发现问题2.10、常用的测试设计工具PICT、iCase、MTG等3、测试流程参看前面DevOps的章节4、测试管理4.1、看业界类互联网速度为王而类CT质量要求更高。所以类CT公司的测试人员占比远高于类互联网公司。类互联网的开发人员承担了更多的测试任务。4.2、测试角色测试经理TM通常指产品测试经理负责一个产品的测试工作。规模小时测试经理就是测试组长规模大时测试经理下有多名测试组长测试组长owner指定本测试小组活动计划并监控执行组织开展测试活动测试系统工程师TSE在产品级测试技术方面引导测试组开展测试活动。需求分析、测试设计、策略制定等测试工程师TE测试设计、测试执行、结果分析报告等。4.3、测试计划是测试工作的主线需要动态调整受测试策略、范围、目标、风险、资源、可测试性等条件的制约。4.4、测试估计对象包括用例规模、工作量、进度、资源4.5、常用的测试度量项测试执行阶段用例执行率、通过率、缺陷密度、缺陷趋势、用例执行效率、回归不通过率、缺陷修改引入率、工作量分布每个特性的投入比例、每个阶段的投入比例测试退出的评估测试特性覆盖率、测试用例覆盖率、测试用例通过率、DI值、问题单解决率4.6、测试报告把测试的过程和结果写成文档对问题与缺陷进行分析为纠正质量问题提供依据同时为软件验收和交付打下基础。可以是多个层次级别的系统的、集成的、单元的等。首先要给出明确结论和关键风险关键风险要区分风险和限制场景化描述影响遗留问题要场景量化数据说清影响措施4.7、一个集成验证测试报告模板评估结论总体结论需求交付情况用例覆盖情况遗留问题说明测试执行数据测试策略闭环发布门禁等。需求与修复缺陷列出本次版本的需求情况问题单情况产品遗留缺陷讲一下遗留的问题单质量评估维度功能结论特性需求情况性能 结论测试策略用例情况需求结论性能结果分析版本问题分析韧性可靠性结论策略用例情况需求结论可靠性基线满足度评估专委会评审结论安全性结论策略发布门禁需求结论用例情况遗留问题评估版本趋势分析可服务性结论策略用例结果需求结论包含安装部署、无损升级、扩容等资料资料清单结论责任人归档链接包括运维指导、SOP/runbook等长稳结论策略用例结果需求结论升级到本次版本配合周边服务端到端读写持续14天自定义信息4.8、风险就是目标与实际的差距没有目标就没有差距。风险失效概率*失效影响其中失效概率使用频率*缺陷概率穷尽测试是不可能的所以测试就是基于风险的测试。风险管理物料、人员能力、测试周期、工程技术等。4.9、缺陷管理测试的目的之一就是发现缺陷。需要从缺陷的发现、提交、分类、修改、解决方案验证等过程跟踪。要有一套完整的缺陷管理过程和规则。缺陷管理作用通过缺陷管理控制测试进度调整测试策略促进质量改进。通过缺陷管理的各类数据评价开发测试的工作质量评价员工绩效预测将来缺陷的趋势。缺陷管理原则问题单要遵循完整性、一致性、时效性、有效性、5、自动化测试5.1、自动化价值提升测试深度--完成手工不可能完成的任务。提升测试效率--执行速度比人快还能持续执行不休息。凸显工程师态度--重复的事情和讨厌的事情都自动化5.2、自动化的误区完全代替手工、发现大量新缺陷、用好自动化工具就可以做好自动化测试、初期对自动化报以高期望、自动化覆盖率越高越好、自动化用例只是对手工用例的翻译。----以上都是错误观点。5.3、手工和自动化怎么选择手工更适合探索性、一次性、依赖智力判断的。自动化更适合机械重复的、大量快速的、基于规则穷尽的自动化第一代简单的捕捉回放QTP、Winrunner、QRun等第二代以脚本为核心TCL第三代以AW为核心第四代进行测试建模5.4、自动化技术的发展过程是用例脚本的“可维护性、可读性、可重用性”不断提升、脚本编写维护成本不断下降的过程核心思想和软件开发思想的演变类似分层、封装、结构化、以及面向对象。5.5、自动化分类按开发阶段单元、接口、集成按测试活动功能、DFX、场景按OM类型WEB、APP、CLI、MIB按设计方法录制回放、面向对象、模型生成按架构思想线性测试、模块驱动、数据驱动、关键字驱动5.6、自动化测试元素AW常用的通用测试动作的封装、脚本一个脚本对应一个用例、测试套一组按场景组织到一起的用例集合、测试框架定义组织整个自动化的系统、执行引擎自动化框架的一部分驱动用例执行并输出报告5.7、自动化调度方式自动化流水线反馈快、轻量、人工干预少、适用测试前移和CICDDevOps模式和CICD这一套用的就是流水线。自动化工厂覆盖全面、时间长人工分析量大、适用版本过点全量验证。5.8、脚本工程的双解耦理念测试数据和脚本解耦AW封装测试脚本和环境解耦环境标准化5.9、脚本工程设计目标使一套脚本工程可自动适应不同的环境实例、测试数据、软件版本等5.10、脚本框架组成测试套是一个集合包括测试逻辑组网、测试数据, pytest中对应conftest.py测试数据测试的输入数据包括环境数据与用例样本点数据逻辑组网 是物理组网的描述里面有环境数据测试脚本根据测试用例实现的自动化代码文件5.11、测试套由数据环境数据测试公共数据和操作公共配置清除公共配置两部分组成环境数据从逻辑组网中获取使于将被测对象的数据传递到测试脚本中测试公共数据如测试规格、硬件规格等被测试脚本反复调用的数据公共配置 脚本中进行的公共操作建议放到测试套中清除公共配置所有脚本执行结束之后对公共配置进行删除5.12、测试脚本组成测试数据对应手工用例中的样本点数据执行前准备对应用例中的预置条件脚本框架中对应方法setup_class测试执行 对应TMSS上的测试执行字段脚本框架中对应方法test_procedure清除配置对过程中产生的配置进行清除脚本框架中对应方法teardown_class5.13、脚本的执行顺序测试套: setup ----脚本1的setup_class、test_procedure 、 teardown_class----脚本2的setup_class、test_procedure、 teardown_class---- ......----脚本n的setup_class、test_procedure、 teardown_class脚本套: teardown5.14、自动化代码上库代码配置管理包含变更管理和版本控制工具Git6、一个软件产品的生命周期需求通过市场调研或客户提出等方式产生需求RR原始需求进行分解设计架构师/设计师/需求owner进行设计产品框架分解出各个特性。测试则参与其中的测试评审如果有测试设计遗漏测试是第一责任人开发开发在alpha环节完成各个特性代码的实现功能的自测要拦截80%的问题。到达转测标准90%通过10%问题单后转测。通常转测时间在正式版本发布的前一个月如果延期测试有权不接收。测试beta测试输出测试策略、测试设计、测试用例、实现自动化、上流水线、输出测试报告给发布结论、发布产品版本。开发的alpha自测是各个特性分别测试而测试的beta测试则是集成测试重点在于端到端。通常只有一到两周所以如果有环境规划等事务一定要在转测之前就提前进行。运维OPS运作支持和SRE安全响应要24小时关注网上情况出现网上问题立刻处理灭火然后展开回溯。EOS停止服务支持被新产品取代。 
长河君 · 2026/10/30 6:12:07 · 阅读 1.2k 软件流程DevOps，版本管理工具Git，测试知识等
DevOps1.软件危机背景落后的软件生产方式无法满足迅速增长的计算机软件需求导致软件开发和维护过程中一系列的问题。于是诞生了软件工程的方法去解决软件危机。2.软件工程的核心思想把其他行业和领域里的工程化经验借鉴过来以系统性的、规范化的、可定量的工程化方法来开发和维护软件。包括相应的流程、工具、方法论等。3.敏捷核心思想由于软件开发难以准确预测工程化的思想和方法并不完全适用于软件开发于是诞生了敏捷思想对软件工程进行纠偏。敏捷软件开发宣言指出个体和互动高于流程和工具工作的软件高于详尽的文档客户合作高于合同谈判响应变化高于遵循计划。总之右项有价值但更偏于左项。4.精益核心思想更关注流动效率而不是资源效率。不停地消除任何不增加价值的工作。5.持续集成核心思想是一种软件开发实践即团队成员经常集成他们的工作每次集成通过自动化的构建包括测试来验证从而尽快检测出集成错误。例如一个软件开发6个月然后集成测试2个月就一定不是持续集成。持续表示均匀、频繁集成表示汇聚、测试。6.持续交付核心思想是一种软件开发实践令软件可以随时发布上线。为此需要持续地集成软件开发成果构建可执行程序并运行自动测试以发现问题进而把可执行程序逐步推送到越来越像生产环境的各个测试环境中并测试以保证它最终可以在生产环境中运行。是持续集成的延伸延伸到各类测试直到发布中间就会牵扯到测试环境和生产环境如何管理、配置、部署回滚人工测还是自动化测等问题。频繁程度小于持续集成。7.DevOps起源和演化7.1.瀑布是典型的预见性方法严格遵循预先计划的需求、分析、设计、编码、测试的步骤顺序进行上一阶段的输出作为下一阶段的输入。大体分为需求分析、设计、编码、测试、维护几个阶段。缺点是只有在项目生命周期后期才能看到结果尤其是不适应用户需求变化。7.2.敏捷由于软件开发难以准确预测工程化的思想和方法并不完全适用于软件开发于是诞生了敏捷思想对软件工程进行纠偏。敏捷是强调轻量的过程方法论强调拥抱变化而不是与之对抗。与客户亲密合作取代合同约定。多数都采用迭代/增量开发的过程模型。敏捷软件开发宣言指出个体和互动高于流程和工具工作的软件高于详尽的文档客户合作高于合同谈判响应变化高于遵循计划。总之右项有价值但更偏于左项。7.3.DevOps软件交付模式发生变化是诞生背景。Dev开发团队关注把新功能实现并上线Ops(运维包括测试)团队关注上线后运行的稳定性两个团队需要协作。devops促进软件开发、技术运营和质量保障等部门间的沟通和协作。特点有“大系统小做”服务/微服务架构师快速创新的技术基础小批量/小粒度频繁的发布和部署平滑集中部署的风险运营驱动开发小步快跑唯快不破运营中持续开发用开发构筑运营竞争力自营合营的运作模式变“卖产品”为“卖服务”打破研发和运营团队之间的界限。“自己开发自己运营”传统交付方式交付整系统测试整系统。devops模式交付以微服务为主微服务独立发布。支持微服务独立开发、验证与上线。8.devops三步工作法快速流动持续交付流水线等、快速反馈、持续学习与实验。9.devops与软件技术的演进是相互促进的开发过程从瀑布--敏捷--devops应用架构从单体--分层--微服务部署与打包从物理机--虚拟机--容器应用基础设施从数据中心--托管服务--云10.软件交付的效能度量指标部署频率越高越好变更前置时间越小越好服务恢复时间越快越好变更失败率越低越好11.DevOps的追求目标效率要兼顾需求吞吐量和需求响应时长质量不是越高越好而是要适合业务质量由问题出现量和问题修复时长共同决定兼顾短期和长期12.总结DevOps和CI/CD的定义DevOpsDevelopment Operations开发和运维。DevOps更偏向于一种对于文化氛围的构建。DevOps也即是促使开发人员与运维人员之间相互协作的文化。CICONTINUOUS INTEGRATION持续集成。指的是开发人员频繁的一天多次的将所有开发者的工作合并到主干上。这些新提交在最终合并到主线之前都需要通过编译和自动化测试流进行验证以保障所有的提交在合并主干之后的质量问题对可能出现的一些问题进行预警。持续集成的核心在于确保新增的代码能够与原先代码正确的集成。CDCONTINUOUS DELIVERY持续交付。侧重点在于交付其核心对象不在于代码而在于可交付的产物。由于持续集成仅仅针对于新旧代码的集成过程执行了一定的测试其变动到持续交付后还需要一些额外的流程。与持续集成相比较持续交付添加了测试Test-模拟Staging-生产Production的流程也就是为新增的代码添加了一个保证确保新增的代码在生产环境中是可用的。持续部署CONTINUOUS DEPLOYMENT指的是通过自动化部署的手段将软件功能频繁的进行交付。与持续交付以及持续集成相比持续部署强调了通过自动部署的手段对新的软件功能进行集成。同持续交付相比持续集成的区别体现在对生产的自动化。从开发人员提交代码到编译、测试、部署的全流程不需要人工的干预完全通过自动化的方式执行。这一策略加快了代码提交到功能上线的速度保证新的功能能够第一时间部署到生产环境并被使用。版本控制工具Git1.什么是版本控制版本控制是一种记录一个或若干文件内容变化以便将来查阅特定版本修订情况的系统方便查看更改历史备份以及恢复以前的版本保证多人的协作不出问题。2.版本控制的起源与历史diff与patch是两个比较源码和补丁的工具diff比较两个文件得出差异patch是diff的反向操作它通过一个文件和差异结果反推出另一个文件。diff的用法diff -u left.c right.cpatch的用法patch left.c diff.txt 、 patch -R right.c diff.txtRCS是最早期的本地版本控制工具CVSSVN是集中式版本控制工具Git是分布式版本控制工具3.集中式CVSSVN与分布式git的差异集中式工具记录差异Git是记录快照。集中式只有脆弱的中央库Git有强壮的分布库。SVN不适合跨地域的协同开发Git不适合Word等二进制文档的版本控制解决方法版本库按照目录拆分4.linux下安装git4.1.包管理器方式安装sudo aptitude install git、sudo aptitude install git-doc git-svn git-email gitkUbuntu、Debian的yum install git、yum install git-svn git-email gitk RHEL、Fedora、CentOS 等4.2.从源代码安装访问Git的官方网站 http://git-scm.com/ 。下载Git源码包例如git-2.19.0.tar.gz。解压后进入目录tar -jxvf git-2.19.0.tar.bz2、cd git-2.19.0、安装方法写在INSTALL文件当中参照其中的指示完成安装。下面的命令将Git安装在 /usr/local/bin 中 make prefix/usr/local all、sudo make prefix/usr/local install安装Git文档可选make prefix/usr/local doc info、sudo make prefix/usr/local install-doc install-html install-info自动补齐bash-completion软件包提供命令补齐功能安装方法将Git源码包中的命令补齐脚本复制到bash-completion对应的目录中:cp contrib/completion/git-completion.bash /etc/bash_completion.d/重新加载自动补齐脚本使之在当前shell中生效: . /etc/bash_completion为了能够在终端开启时自动加载bash_completion脚本需要在本地配置文件 ~/.bash_profile 或全局文件/etc/bashrc 文件中添加下面的内容:if [ -f /etc/bash_completion ]; then . /etc/bash_completion fi5.Windows下安装git到 https://git-scm.com/download/win 下载 Windows 安装包例如: Git-2.19.0-64-bit.exe执行exe开始图形化安装在安装过程中会询问是否修改环境变量。建议选择“Use Git Bash Only”即只在 MinGW 提供的shell环境中使用Git不修改 PATH 环境变量避免 Git 自带的工具与 Windows 下已有的产生冲突。安装完成后我们可以在 Windows 任意目录下右键单击选中 Git Bash 启动 Git Bash。git version 查看安装的 git 版本信息Windows下除了git还有一个就是基于msysGit的图形界面工具——TortoiseGit人称小乌龟。访问网站 http://code.google.com/p/tortoisegit/ 下载安装包然后根据提示完成安装。6.总结git基本配置Git有三种配置分别以文件的形式存放在三个不同的地方。可以在命令行中使用git config工具查看这些变量系统配置对所有用户都适用存放在git的安装目录下%Git%/etc/gitconfig若使用 git config 时用 --system 选项读写的就是这个文件git config --system core.autocrlf用户配置只适用于该用户存放在用户目录下。例如linux存放在~/.gitconfig若使用 git config 时用 --global 选项读写的就是这个文件git config --global user.name仓库配置只对当前项目有效当前仓库的配置文件也就是工作目录中的 .git/config 文件若使用git config 时用 --local 选项读写的就是这个文件git config --local remote.origin.url6.1.配置个人身份git config --global user.name “Zhang San” ----个人名称git config --global user.email zhangsan123huawei.com ----个人邮箱6.2.文本换行符配置假如你正在和其他人合作他们在Windows上编程而你却在其他系统上在这些情况下你可能会遇到行尾 结束符问题。 这是因为Windows使用回车和换行两个字符来结束一行而Mac和Linux只使用换行一个字符。 虽然这是小问题但它会极大地扰乱跨平台协作git config --global core.autocrlf true 可以在你提交时自动地把行结束符CRLF转换成LF而在签出代码时把LF转换成CRLFgit config --global core.autocrlf input 把core.autocrlf设置成input来告诉Git在提交时把CRLF转换成LF签出时不转换。这样会在Windows系统上的签出文件中保留CRLF会在Mac和Linux系统上包括仓库中保留LFgit config --global core.autocrlf false 假如正在开发仅运行在Windows上的项目可以设置false取消此功能6.3文本编码支持# 中文编码支持git config --global gui.encoding utf-8git config --global i18n.commitencoding utf-8 用来让git commit log存储时采用的编码默认UTF-8git config --global i18n.logoutputencoding utf-8 查看git log时显示采用的编码建议设置为UTF-8.# 显示路径中的中文git config --global core.quotepath false6.4.与服务器的认证配置http / https 协议认证设置口令缓存git config --global credential.helper store添加 HTTPS 证书信任git config http.sslverify falsessh 协议认证SSH协议是一种非常常用的Git仓库访问协议使用公钥认证、无需输入密码加密传输操作便利又保证安全性生成公钥ssh-keygen -t rsa –C zhangsan1123huawei.com添加公钥到代码平台登录代码平台、进入“Profile Settings”、点击左侧栏的“SSH Keys”、点击“Add SSH Key”,将刚生成的公钥文件的内容复制到“Public Key”栏保存即可7.总结git命令7.1、Git版本控制下有三种工程区域文件状态Git版本控制下的工程区域只有三种版本库 Repository 在工作区中有一个隐藏目录.git这个文件夹就是Git的版本库里面存放了Git用来管理该工程的所有版本数据也可以叫本地仓库工作区 Working Directory 日常工作的代码文件或者文档所在的文件夹暂存区 stage 一般存放在工程根目录 .git/index文件中所以我们也可以把暂存区叫作索引indexGit版本控制下的文件状态只有三种已提交 committed 该文件已经被安全地保存在本地数据库中了已修改modified 修改了某个文件但还没有提交保存已暂存staged把已修改的文件放在下次提交时要保存的清单中7.2、基本上库流程pull(远端库更新到本地) --每次上库之前一定要先更新避免上库后出现冲突add(新增文件添加到暂存区只有新增的文件需要 git add file)commit暂存区的文件改动提交到本地库 git commit -m 修改描述push本地库推送到远端分支git push origin 远端分支merge远端分支合并到远端master7.3、工程准备命令git init 项目名称用于在本地目录下新建git项目仓库。执行git init后当前目录下自动生成一个名为.git的目录这代表当前项目所在目录已纳入Git管理。.git目录下存放着本项目的Git版本库在此强烈不建议初学者改动.git目录下的文件内容。Git仓库下的.git目录默认是不可见的有一定程度上是出于防止用户误操作考虑。但我们日常工作中几乎全部都是基于已有的git工程进行本地开发不需要我们做新建git仓库都是从远端服务器上克隆到本地所以直接git clonegit clone用于克隆远端工程到本地磁盘。如果想从远端服务器获取某个工程那么确定自己Git账号拥有访问、下载该工程的权限获取该工程的Git仓库URL本地命令行执行git clone [URL]或git lfs clone [URL]如果你所在的项目git服务器已支持git-lfs对二进制文件进行了区别管理那么克隆工程的时候务必使用git lfs clone。否则克隆操作无法下载到工程中的二进制文件工程内容不完整。7.4、新增/删除/移动文件到暂存区在提交你修改的文件之前需要git add把文件添加到暂存区。如果该文件是新创建尚未被git跟踪的需要先执行 git add 将该文件添加到暂存区再执行提交。如果文件已经被git追踪即曾经提交过的 。在早期版本的git中需要git add再提交在较新版本的git中不需要git add即可提交。git rm将指定文件彻底从当前分支的缓存区删除因此它从当前分支的下一个提交快照中被删除。如果一个文件被git rm后进行了提交那么它将脱离git跟踪这个文件在之后的节点中不再受git工程的管理。执行git rm后该文件会在缓存区消失。你也可以直接从硬盘上删除文件然后对该文件执行 git commitgit会自动将删除的文件从索引中移除效果一样。git mv命令用于移动文件也可以用于重命名文件。举例移动目录git mv codehunter_nginx.conf config 举例重命名git mv config/codehunter_nginx.conf config/new_nginx.conf7.5、查看工作区、提交更改的文件、查看日志git diff用于比较项目中任意两个版本分支的差异也可以用来比较当前的索引和上次提交间的差异。git diff aaa bbb(两个节点或分支)git diff --cached(当前的索引和上次提交间的差异)git diff aaa bbb --name-status(只看文件列表)git status命令用于显示工作目录和暂存区的状态。使用此命令能看到修改的git文件是否已被暂存, 新增的文件是否纳入了git版本库的管理。git commit主要是将暂存区里的文件改动提交到本地的版本库。在此强调提交这个动作是本地动作是往本地的版本库中记录改动不影响远端服务器。git commit一般需要附带提交描述信息所以常见用法是git commit file_name –m “commit message”。如果要一次性提交所有在暂存区改动的文件到版本库可以执行:git commit –am “commit message”git log用于查看提交历史。默认加其他参数的话git log 会按提交时间由近到远列出所有的历史提交日志。每个日志基本包含提交节点、作者信息、提交时间、提交说明等。git log配合不同参数具有相当灵活强大的展示功能常见的如—name-status/-p/--pretty/--graph等等自行了解。7.6、推送至远端库在使用git commit命令将自己的修改从暂存区提交到本地版本库后可以使用git push将本地版本库的分支推送到远程服务器上对应的分支。成功推动远端仓库后其他开发人员可以获取到你新提交的内容。常用的推送命令格式git push origin branch_namebranch_name决定了你的本地分支推送成功后在远端服务器上的分支名其他人据此可以获取该分支上的改动内容。你的本地分支名可以与推送到远端的分支名不同 git push origin branch_name:new_branch_name7.7、分支管理查看分支git branch查看本地工程的所有git分支名称。显示结果前面带*的绿色高亮的表示当前工作区所在分支git branch –r查看远端服务器上拥有哪些分支返回的分支名带origin前缀表示在远端git branch –a查看远端服务器和本地工程所有的分支。创建分支、删除分支、更新分支git branch new_branch_name新建分支不会切换到新分支git checkout –b branch_name新建分支并自动切换到新分支git branch –d branch_name删除本地分支git branch –D branch_name删除本地分支强制删除git branch -d -r branch_name删除服务器上的远程分支。其中branch_name为本地分支名。删除后还要推送到服务器上才行即git push origin : branch_namegit checkout branch_namegit checkout除了创建分支还用来切换分支当然比较官方的叫法是“检出”。有时候当前分支工作区存在修改而未提交的文件与目的分支上的内容冲突会导致checkout切换失败这时候可以使用git checkout –f进行强制切换。git checkout对象可以是分支也可以是某个提交节点或者节点下的某个文件。git pull origin remote_branch:local_branch从远端服务器中获取某个分支的更新再与本地指定的分支进行自动合并。 相当于git fetch git merge。如果远程指定的分支与本地指定的分支相同则可直接执行git pull origin remote_branchgit fetch origin remote_branch:local_branch从远端服务器中获取某个分支的更新到本地仓库。与git pull的区别是并不会进行合并。如果远程指定的分支与本地指定的分支相同则可直接执行git fetch origin remote_branchgit merge branch_name用于从指定的分支节点合并到当前分支的操作。分支合并实际上是分支间差异提交节点的合并。git rebase branch_name合并目标分支内容到当前分支。如果你要将其他分支的提交节点合并到当前分支那么git rebase和git merge都可以达到目的。git rebase、git merge背后的实现机制和对合并后节点造成的影响有很大差异有各自的风险存在暂不在本课中展开。7.8、撤销操作git reset commit_id撤销当前工作区中的某些git add/commit操作可将工作区内容回退到历史提交节点。git reset –-mixed/hard/soft的三种参数模式涉及概念较多需要去了解。git checkout .用于回退本地所有修改而未提交的文件内容。这是条有风险的命令因为它会取消本地工作区的修改(相对于暂存区)用暂存区的所有文件直接覆盖本地文件达到回退内容的目的。但它不给用户任何确认机会所以谨慎使用。git checkout –filename仅仅想回退某个文件的未提交改动git checkout commit_id想将工具区回退检出到某个提交版本关于测试1、测试的基础理论1.1、为什么要做测试缺陷不可避免软件未正确执行可能会导致很多问题所以需要通过测试控制风险1.2、什么是软件测试描述一种用来促进鉴定软件的正确性、完整性、安全性和质量的过程。是一个包含计划、准备和测量活动的过程。目的是确认被测系统的特性并指出需求和实现之间的差异。1.3、测试的目的发现缺陷、质量评估、预防缺陷、分享信息、消除风险、建立信心等1.4、不同的测试阶段测试目的有所不同单元、集成、系统测试目的是尽可能发现失效从而识别和修正尽可能多的缺陷验收测试目的是确认系统是否按预期工作建立满足了需求的信心有些情况下目的是对软件质量进行评估从而为利益相关人提供给定时间点发布系统版本可能存在的风险的信息。回归测试通常是为了验证开发过程中的软件变更是否引入了新缺陷1.5、测试的依据是不仅仅依据产品业务的需求还要看合同要求、法律标准、行业标准等1.6、测试的开始与停止时间什么时候开始测试越早越好。越晚修复bug付出的代价就越大。什么时候停止测试要从多个维度评估例如达到了必要信心级别风险可接受时、发现缺陷的代价高于缺陷本身带来的代价时、达到测试完成标准时1.7、谁来测试测试是研发团队所有人的职责不只是测试人员的事情。1.8、基本的测试过程计划、控制、分析和设计、执行和评估、结束1.9、测试的七项基本原则穷尽测试不可能测试所有内容不可行应使用风险分析和优先级来聚焦测试投入本质上就是抽样检验。缺陷集群性二八法则无处不在。大部分缺陷集中于少部分模块杀虫剂悖论同一个用例反复测试最后将不能发现新缺陷。所以用例需求经常性的评审修改不断增加新的不同角度的用例。测试指出缺陷的存在测试能指出存在缺陷但不能证明没有缺陷。测试降低软件有缺陷的可能即使没发现缺陷也不能证明软件完全正确。absence-of-errors谬误系统的发布不取决于是否有缺陷而是取决于是否满足客户需求和期望。如果不满足用户需求找再多bug修订也没用。测试要尽早介入要尽早在软件开发中启动测试活动聚焦于测试目标开发人员也应提前测试自己的代码测试活动依赖于测试context南橘北枳。测试的目标定义、策略指定、技术选择等都要充分考虑上下文客户需求技术难度项目时间人员能力资源状态等。测试人员要主动快速响应上下文的变化。没有最佳方案不能一成不变要随时改进。尤其要重视客户的反馈现网问题、需求、抱怨和赞誉等1.10、测试人员应该具备的测试知识、领域知识、IT知识、批判性思维、自我教育等要有好奇心就是要验证一些奇怪场景。要有主观能动性。开展测试活动必备对常见错误进行判断的经验敢于提出问题的勇气探究根底的精神多维度思考的能力挑剔的眼睛专业的怀疑态度。测试活动需要良好沟通。1.11、一些测试名词错误error--缺陷bug/defect/fault--失效failures1.12、软件测试的分类按是否运行程序静态测试评审和静态分析动态测试运行程序检查结果。其中动态分为白盒与黑盒。按阶段划分单元测试测单个模块集成测试测多个模块的集成交互系统测试测整个系统验收测试以是否满足客户需求为目标按用例设计是否设计代码划分黑盒测试功能、性能、可靠性、易用性、可服务性、维护性等白盒测试按针对的质量目标划分功能、适用性、性能、安全、可靠性其他分类资料、自动化、回归代码修改后重新测试确认没有新错误引入、精准测试时间精力有限情况下对于大量用例如何挑选出最合适的部分进行测试最简单的依据是开发修改了哪些就测哪些2、测试设计2.1、为什么要做测试设计保证测试质量理清测试思路、通过用例评审避免遗漏、通过执行用例评估产品质量与需求满足度提高测试效率提前规划资源、准备人力、有效执行测试活动是测试执行的依据依据用例执行、证明用例确实执行了、记录问题支撑问题复现跟进测试进度用用例衡量测试进度留下测试资产给后续版本继承2.2、测试设计目的明确测试活动的范围和目标明确测试方法指导测试执行过程开展规范测试行为2.3、测试覆盖目的基于测试的风险分析定义被测对象覆盖的深度保障高风险的规格能够更充分的覆盖满足交付质量要求2.4、测试设计交付件包括测试方案和测试用例是测试的核心资产通过测试设计实现系统测试过程可定义、可重复、可改进。建议借助思维导图来梳理需求完成测试因子的分析与提取2.5、测试方案的目的指导用例设计、传递测试设计思路2.6、测试方案内容被测对象分析需求价值、应用场景、组网、被测边界接口、约束、继承性测试风险分析分析主要风险点识别测试重点关注点测试类型分析功能测试、性能测试、安全测试、可靠性测试……测试技术分析分析测试难点考虑应对方案自动化分析考虑自动化策略、AW设计测试环境与物料需求功能点划分2.7、三种测试设计方法处理周期亿图图示画流程图圆角矩形开始结束直角矩形操作步骤菱形是判定点。然后可覆盖不同的路径深度来设计用例状态转换亿图图示不同状态之间的转换不同的转换次数0-switch、1-switch等数据组合因子组合方法2.8、因子组合技术选择哪种组合技术依赖于被测对象的风险对于开发者测试可以同时考虑实现成本和执行成本。因子取值等价类划分、分析边界值AC将每个测试因子所有取值进行全组合。AC是覆盖最全面的覆盖方式。 缺点是对于复杂的对象组合数量太庞大。组合个数每个因子取值个数的乘积BC以一个因子组合为基准每次只改变一个因子的取值直到所有取值都覆盖到。组合个数 所有因子取值个数 因子个数 1EC每一个测试因子的每一个取值在所有测试因子组合中至少出现一次。组合个数 所有因子中取值最多的那个因子的取值个数N-Wise组合每N个测试因子的取值进行AC全组合。其中用的最多的是pair-Wise2-wise组合。组合个数 最多因子取值个数 × 次多因子取值个数举例假如三个因子分别有2/3/4种取值。那么AC组合有有 2*3*4种。BC组合有234-3-1种。EC组合有max(2,3,4)种pair-wise有4*3种2.9、做好测试设计的几个关键因素需求分析时更充分的理解需求、测试设计时系统化的思考、输出用例时科学的测试覆盖、充分利用测试因子库经验库等组织积累的经验、最后进行评审可以更容易发现问题2.10、常用的测试设计工具PICT、iCase、MTG等3、测试流程参看前面DevOps的章节4、测试管理4.1、看业界类互联网速度为王而类CT质量要求更高。所以类CT公司的测试人员占比远高于类互联网公司。类互联网的开发人员承担了更多的测试任务。4.2、测试角色测试经理TM通常指产品测试经理负责一个产品的测试工作。规模小时测试经理就是测试组长规模大时测试经理下有多名测试组长测试组长owner指定本测试小组活动计划并监控执行组织开展测试活动测试系统工程师TSE在产品级测试技术方面引导测试组开展测试活动。需求分析、测试设计、策略制定等测试工程师TE测试设计、测试执行、结果分析报告等。4.3、测试计划是测试工作的主线需要动态调整受测试策略、范围、目标、风险、资源、可测试性等条件的制约。4.4、测试估计对象包括用例规模、工作量、进度、资源4.5、常用的测试度量项测试执行阶段用例执行率、通过率、缺陷密度、缺陷趋势、用例执行效率、回归不通过率、缺陷修改引入率、工作量分布每个特性的投入比例、每个阶段的投入比例测试退出的评估测试特性覆盖率、测试用例覆盖率、测试用例通过率、DI值、问题单解决率4.6、测试报告把测试的过程和结果写成文档对问题与缺陷进行分析为纠正质量问题提供依据同时为软件验收和交付打下基础。可以是多个层次级别的系统的、集成的、单元的等。首先要给出明确结论和关键风险关键风险要区分风险和限制场景化描述影响遗留问题要场景量化数据说清影响措施4.7、一个集成验证测试报告模板评估结论总体结论需求交付情况用例覆盖情况遗留问题说明测试执行数据测试策略闭环发布门禁等。需求与修复缺陷列出本次版本的需求情况问题单情况产品遗留缺陷讲一下遗留的问题单质量评估维度功能结论特性需求情况性能 结论测试策略用例情况需求结论性能结果分析版本问题分析韧性可靠性结论策略用例情况需求结论可靠性基线满足度评估专委会评审结论安全性结论策略发布门禁需求结论用例情况遗留问题评估版本趋势分析可服务性结论策略用例结果需求结论包含安装部署、无损升级、扩容等资料资料清单结论责任人归档链接包括运维指导、SOP/runbook等长稳结论策略用例结果需求结论升级到本次版本配合周边服务端到端读写持续14天自定义信息4.8、风险就是目标与实际的差距没有目标就没有差距。风险失效概率*失效影响其中失效概率使用频率*缺陷概率穷尽测试是不可能的所以测试就是基于风险的测试。风险管理物料、人员能力、测试周期、工程技术等。4.9、缺陷管理测试的目的之一就是发现缺陷。需要从缺陷的发现、提交、分类、修改、解决方案验证等过程跟踪。要有一套完整的缺陷管理过程和规则。缺陷管理作用通过缺陷管理控制测试进度调整测试策略促进质量改进。通过缺陷管理的各类数据评价开发测试的工作质量评价员工绩效预测将来缺陷的趋势。缺陷管理原则问题单要遵循完整性、一致性、时效性、有效性、5、自动化测试5.1、自动化价值提升测试深度--完成手工不可能完成的任务。提升测试效率--执行速度比人快还能持续执行不休息。凸显工程师态度--重复的事情和讨厌的事情都自动化5.2、自动化的误区完全代替手工、发现大量新缺陷、用好自动化工具就可以做好自动化测试、初期对自动化报以高期望、自动化覆盖率越高越好、自动化用例只是对手工用例的翻译。----以上都是错误观点。5.3、手工和自动化怎么选择手工更适合探索性、一次性、依赖智力判断的。自动化更适合机械重复的、大量快速的、基于规则穷尽的自动化第一代简单的捕捉回放QTP、Winrunner、QRun等第二代以脚本为核心TCL第三代以AW为核心第四代进行测试建模5.4、自动化技术的发展过程是用例脚本的“可维护性、可读性、可重用性”不断提升、脚本编写维护成本不断下降的过程核心思想和软件开发思想的演变类似分层、封装、结构化、以及面向对象。5.5、自动化分类按开发阶段单元、接口、集成按测试活动功能、DFX、场景按OM类型WEB、APP、CLI、MIB按设计方法录制回放、面向对象、模型生成按架构思想线性测试、模块驱动、数据驱动、关键字驱动5.6、自动化测试元素AW常用的通用测试动作的封装、脚本一个脚本对应一个用例、测试套一组按场景组织到一起的用例集合、测试框架定义组织整个自动化的系统、执行引擎自动化框架的一部分驱动用例执行并输出报告5.7、自动化调度方式自动化流水线反馈快、轻量、人工干预少、适用测试前移和CICDDevOps模式和CICD这一套用的就是流水线。自动化工厂覆盖全面、时间长人工分析量大、适用版本过点全量验证。5.8、脚本工程的双解耦理念测试数据和脚本解耦AW封装测试脚本和环境解耦环境标准化5.9、脚本工程设计目标使一套脚本工程可自动适应不同的环境实例、测试数据、软件版本等5.10、脚本框架组成测试套是一个集合包括测试逻辑组网、测试数据, pytest中对应conftest.py测试数据测试的输入数据包括环境数据与用例样本点数据逻辑组网 是物理组网的描述里面有环境数据测试脚本根据测试用例实现的自动化代码文件5.11、测试套由数据环境数据测试公共数据和操作公共配置清除公共配置两部分组成环境数据从逻辑组网中获取使于将被测对象的数据传递到测试脚本中测试公共数据如测试规格、硬件规格等被测试脚本反复调用的数据公共配置 脚本中进行的公共操作建议放到测试套中清除公共配置所有脚本执行结束之后对公共配置进行删除5.12、测试脚本组成测试数据对应手工用例中的样本点数据执行前准备对应用例中的预置条件脚本框架中对应方法setup_class测试执行 对应TMSS上的测试执行字段脚本框架中对应方法test_procedure清除配置对过程中产生的配置进行清除脚本框架中对应方法teardown_class5.13、脚本的执行顺序测试套: setup ----脚本1的setup_class、test_procedure 、 teardown_class----脚本2的setup_class、test_procedure、 teardown_class---- ......----脚本n的setup_class、test_procedure、 teardown_class脚本套: teardown5.14、自动化代码上库代码配置管理包含变更管理和版本控制工具Git6、一个软件产品的生命周期需求通过市场调研或客户提出等方式产生需求RR原始需求进行分解设计架构师/设计师/需求owner进行设计产品框架分解出各个特性。测试则参与其中的测试评审如果有测试设计遗漏测试是第一责任人开发开发在alpha环节完成各个特性代码的实现功能的自测要拦截80%的问题。到达转测标准90%通过10%问题单后转测。通常转测时间在正式版本发布的前一个月如果延期测试有权不接收。测试beta测试输出测试策略、测试设计、测试用例、实现自动化、上流水线、输出测试报告给发布结论、发布产品版本。开发的alpha自测是各个特性分别测试而测试的beta测试则是集成测试重点在于端到端。通常只有一到两周所以如果有环境规划等事务一定要在转测之前就提前进行。运维OPS运作支持和SRE安全响应要24小时关注网上情况出现网上问题立刻处理灭火然后展开回溯。EOS停止服务支持被新产品取代。