6.1测试执行过程—带你揭开测试过程
破枪式—测试执行管理
6.1.1测试执行过程
6.1.2测试执行阶段的主要任务
①确定测试用例的优先级
②开发测试规程并确定优先级，创建测试数据，同时也可以准备测试用具和设计自动化测试脚本。
③根据测试规程创建测试套件，以提高测试执行的效率。
④确定已经正确搭建了测试环境。
⑤根据测试计划的执行顺序，通过手工或使用测试工具来执行测试规程。
⑥记录测试执行的结果，以及被测软件、测试工具和测试件的标识和版本。
⑦将实际结果和预期结果进行比较。
⑧对实际结果和预期结果之间的差异，作为事件上报，并且进行分析以确定引起差异的原因。
⑨缺陷修正后，重新进行测试活动。
6.2测试准入准出—必知标准
6.2.1测试准入标准
①开发编码结束，并在开发环境已完成单元测试。
②需求上规定的功能均已实现；如没有完全实现，请提供测试范围。
③已完成集成测试，被测系统的基本流程可以走通，界面上的功能均实现，经过代码评审并符合软件编码规范。
④开发提交最新版本，以此为基线，提交并通知测试组进行测试。
⑤兼容性测试要求明确。
⑥安全测试和性能测试范围和要求。
6.2.2测试暂停、停止
①测试人员先进行冒烟测试，若发现重大缺陷或bug过多时、或者流程卡壳导致基本流程无法走通，测试无法正常进行，可以暂停测试并返回开发。
②被测项目需调整而暂停的，测试也相应暂停。
③存在其他优先级更高的任务是，可以向领导申请暂停测试。
④被测系统经过系统测试，达到系统准出标准，可以停止测试。
6.2.3测试准出标准
6.3软件缺陷概述—缺陷产生的原因
6.3.1软件缺陷
定义：
缺陷是一种泛称，它可以指功能的错误，也可以指性能低下，易用性差等。并不是所有的测试人员都能提交被开发认可的缺陷，也不是测试员在任何时候都能提交被开发认可的缺陷。
6.3.2什么是软件缺陷
①软件未达到产品说明书表明的功能。
②软件出现了产品说明书指明不会出现的错误。
③软件功能超出产品说明书指明范围。
④软件未达到产品说明书虽未指出但应达到的目标。
⑤软件测试员认为软件难以理解、不宜使用、运行速度缓慢，或者最终用户认为不好。
6.3.3缺陷产生的原因
6.3.4发现缺陷
①用户体验不好
②界面上有明显的错误信息
③功能不完备，没有按照需求说明编写代码，致使某些功能缺失
④功能不完善，不能正常运行或者运行的过程中出现程序崩溃、停止运行的情况。
⑤逻辑不正确，与需求说明书、测试用例不符。
⑥模块之间的交互性不好，与其他的模块做集成测试时遇到问题。
⑦程序的性能不够好，不能承载压力考验。
6.4缺陷报告—注意事项
6.4.1BUG重现
①不要想当然的接受任何假设，要做好记录。
②查找时间依赖和竞争条件的问题。
③边界条件软件缺陷、内容泄露和数据溢出等白盒问题可能会慢慢自己显露出来。
④状态缺陷仅在特定软件状态中显露出来。
⑤考虑资源依赖性和内存、网络、硬件共享的相互作用。
6.4.2无法重现的BUG
①首先，应当对这样的缺陷进行详细的记录，并尽快提交给开发人员。
②其次，对于寻找难以再现的缺陷要合理的安排时间，要考虑到测试项目的整体进度，对一时难以再现的缺陷可以暂时搁置，以保证项目的正常进度。
③最后在测试过程中对未再现缺陷予以关注。
6.4.3缺陷报告
定义：
缺陷报告是对缺陷进行记录、分类和跟踪的文档。
软件测试人员的任务之一就是书写良好的软件缺陷报告。
提供准确、完整、简洁、一致的缺陷报告是体现软件测试的专业性、高质量的主要评价标准。通常来说，缺陷报告的直接读者是软件开发人员和质量管理人员，除此之外，来自市场和技术支持等部门的人也可能需要查看缺陷情况。
6.4.4缺陷报告包含信息
①易于搜索软件测试报告的缺陷。（要有自己的关键词管理）
②报告的软件缺陷进行了必要的隔离，报告的缺陷信息具体、准确。
③软件开发人员希望获得缺陷的本质特征和复现步骤。
④市场和技术等部门希望获得缺陷类型分布以及对市场和用户的影响程度。
6.4.5缺陷报告的写作准则（5C）
①Correct（准确）：每个组成部分的描述准确，不会引起误解。
②Clear（清晰）：每个组成部分的描述清晰，易于理解。
③Concise（简洁）：只包含不可少的信息，不包括任何多余的内容。
④Complete（完整）：包含复现该缺陷的完整步骤和其他本质信息。
⑤Consistent（一致）：按照一致的格式书写全部缺陷报告。
6.4.6缺陷报告的组织结构
①缺陷的标题。
②缺陷的基本信息。
③测试的软件的硬件环境。
④测试的软件版本。
⑤缺陷的类型。
⑥缺陷的严重程度。
⑦缺陷的处理优先级。
⑧复现缺陷的操作步骤。
⑨缺陷的实际结果描述。
⑩期望的正确结果描述。
⑪注释文字和截取的缺陷图像。
缺陷标题：
①尽量按缺陷发生的原因与结果的方式书写（“执行完A后，发生B”，或者“发生B，当A执行完后”）。
②避免使用模糊不清的词语，例如“功能中断” “功能不准确” “行为不起作用” 等。应该使用具体文字说明功能如何中断，如何不正确，或如何不起作用。
③为了方便搜索和查询，请使用关键字。
④为了便于他人理解，避免使用术语、俚语或过分具体的测试细节。
eg:
6.4.7复现步骤
定义：
复现步骤包含如何使别人能够很容易的复现该缺陷的完整步骤。为了达到这个要求，复现步骤的信息必须是完整的、准确的、简明的、可复现的。
但是实际软件测试过程中，总是存在一些不良的缺陷报告，主要的问题在于多余步骤、可读性差、难以理解、缺失步骤等。
步骤：
①提供测试的预备步骤和信息。
②简单的一步一步的引导复现该缺陷。
③每一个步骤尽量只记录一个操作。
④每一个步骤前使用数字对步骤编号。
⑤尽量使用短语和短句，避免复杂句型和句式。
⑥复现的操作步骤要完整，准确，简短。
⑦没有缺漏任何操作步骤。
⑧每个步骤都是准确无误的。
⑨没有任何多余的步骤。
⑩将常见步骤合并为较少步骤。
⑪只记录各个操作步骤是什么，不需要包括每个步骤的执行结果。
6.4.8缺陷报告的注意事项
①缺陷报告已经向读者包含完整、准确、必要的信息了吗？
②一个缺陷报告中是否只报告了一种缺陷？
③读者是否能容易的搜索该缺陷？
④步骤是否可以完全复现而且表达清楚吗？
⑤是否包含了复现缺陷需要的环境变量或测试所用的数据文件？
⑥缺陷的标题是按照原因与结果的方式书写的吗？
⑦实际结果和期望结果是否描述不够清楚而容易引起歧义吗？
6.5缺陷报告的原则—十大原则
①组织Structure：测试人员应该采用深思熟虑的，小心谨慎的方法执行测试，并且做详尽的记录。这样可以促使他们对待测试系统有很好的认识。当错误发生的时候，一个有组织的测试人员能够知道最早出现问题的地方。
②重现Prproduce：测试人员在编写缺陷报告之前必须在检查问题是否可重现。如果错误不可再重现，仍然应该写下来，但是必须说明问题的偶然性。一个好的处理原则就是在编写缺陷报告之前反复尝试3次。
③隔离Isolate：在尝试编写缺陷报告之前，必须试着隔离错误。可以采用改变一些变量的方法，如系统的配置，它可能可以改变错误的症状。这些信息可以为开发人员着手调试提供思路。
④归纳Generalize：发现了一个已隔离的，可重现的问题后，应该对问题进行归纳。同一个问题是否出现在其他的模块或其它的地方？同一个故障是否有更加严重的问题？
⑤对比Compare：如果测试人员以前曾经验证过现在出错的测试用例，那么他就应该检查以前的测试结果以检查相同的条件以前的测试是否通过。如果是的话，那么这个问题就像是一个回归的错误。注意由于同一个测试条件有可能出现在多个测试用例中，这个步骤就不仅仅只是检查一个测试用例在以前的多个结果。
⑥总结Summarize：在缺陷报告的第一行写上错误的总结是非常关键的。测试人员要花一些时间思考已发现的错误对客户有何影响。这不仅仅要求测试人员编写的报告要能顾吸引读者，使和管理层的沟通清晰，还要能够帮助设置错误修复的优先级别。
⑦精简Condense：在缺陷报告的初稿完成后，测试人员应该反复阅读它，集中剔除那些没有关系的步骤或词语。隐含的或模糊的说明和那些由于对没有任何关系的细节或者那些在重现错误的过程中不需要的步骤而消磨报告欢迎程度的无穷唠叨都不是缺陷报告的目标。
⑧消除歧义Disambiguate：测试人员在精简空话的同时或其之后随即应该仔细检查报告是否有会产生误解的地方。测试人员应该尽量避免使用模糊的，会产生歧义的和主观的词语。目标是使用能够表述事实，清楚的，不会产生争执的词语。
⑨中立Neutralize：作为坏消息的传递人，和善地提交消息是一个挑战。如同所有的错误总结一样，独立的缺陷报告在措词方面应该保持公正。攻击开发人员，指责潜在的错误，企图诙谐或使用挖苦将引起开发人员的憎恶，并且使注意力从“提高产品质量”这个大的目标上转移开了。
⑩检查Reciew：一旦测试人员感觉缺陷报告是他能够编写的最好版本，他应该将报告再给一个或多个同行进行检查。在允许的时间里，测试小组应该尽可能提交最好的缺陷报告。
6.6缺陷跟踪—持续跟踪才能高效测试
6.6.1缺陷状态迁移图
6.6.2缺陷跟踪管理系统
早期的缺陷跟踪大都是以缺陷记录单的形式完成，现在还有很多项目还用此方法，但是随着用户对软件功能需求不断增加，软件算法和复杂度都发生了很多变化，随之而来的软件缺陷的增长，这给缺陷跟踪带来很大的挑战。 于是，缺陷管理系统应运而生：
在软件行业发展历程中，曾经或者正在被大量使用的缺陷管理系统包括JIPA、BUGZILLA、QC、禅道等。而目前，除了部分大型IT公司拥有自研的缺陷跟踪管理系统外，很多公司应用禅道来进行缺陷跟踪甚至是项目管理。
6.7禅道项目管理及实战—项目管理
软件介绍：
禅道是一款基于Scrum思想并集产品管理、项目管理、测试管理于一体，同时还包含了事务管理、组织管理等诸多功能的项目管理软件。
6.7.1用户角色
①系统管理员（Admin）：系统管理员主要负责添加用户，分配权限。
②产品人员（Produce owner）：产品人员主要负责产品管理。
③项目经理（Project Manager）：通过项目，协调产品人员，开发人员，测试人员完成产品。
④开发人员（developer）：开发人员负责产品的研发。
⑤测试人员（QA）：测试人员保证产品的质量。
6.7.2最简使用
①只使用禅道来进行产品管理。
②使用禅道来进行项目任务管理。
③只使用禅道来做bug管理。
④个人使用禅道来做事物跟踪管理。
6.7.3项目模式基本流程
①产品经理创建产品。
②产品经理创建需求。
③项目经理创建项目。
④项目经理确定项目要做的需求。
⑤项目经理分解任务，指派到人。
⑥测试人员测试，提交bug。
6.8易用性测试—测试点的总结
定义：
指的是用户使用软件是是否感觉方便，比如是否最多点击鼠标三次就可以达到用户的目的。
易用性和可用性的区别：
①可用性是指是否可以使用。
②易用性是指是否方便使用。
6.7.1易用性测试内容
易用性测试包括针对应用程序的测试，同时还包括对用户手册系统文档的测试。通常采用质量外部模型来评价易用性。
包括如下方面的测试：
①易理解性。
②易学习性。
③易操作性。
④吸引性。
⑤依从性。
6.8.2易用性测试方法—导航测试
通过考虑下列问题，可以解决一个应用系统是否易于导航：导航是否直观？系统的主要部分是都可通过主页存取？系统是否需要站点地图、搜索引擎或其他的导航帮助？
6.8.3易用性测试方法—图形测试
在应用系统中，适当的图片和动画既能起到广告宣传的作用，又能起到美化页面的功能。一个应用系统的图片可以包括图片、动画、边框、颜色、字体、背景、按钮等。
图形测试要考量的方面有：
①要确保图形有明确的用途，图片或动画不要胡乱的堆在一起，以免浪费传输时间。
②应用系统的图片尺寸要尽量的小，并且能清楚的说明某件事情，一般都连接到某个具体的页面。
③验证所有页面字体的风格是否一致。
④背景颜色应该与字体颜色和前景颜色相搭配。
⑤图片的大小和质量也是一个很重要的因素，一般采用JPG或GIF压缩。
6.8.4易用性测试方法—内容测试
定义：
内容测试用来检验应用系统提供信息的正确性、准确性和相关性。
6.8.5易用性测试方法—整体界面测试
定义：
整体界面是指整个应用系统的页面结构设计，是给用户的一个整体感。
eg:当用户浏览应用系统时是否感到舒适，是否凭感觉就知道要找的信息在什么地方？整个应用系统的设计风格是否一致。
6.8.6测试点总结
①控件类：
②菜单测试：
③快捷键设置：
6.9兼容性测试—提高产品质量和用户体验
定义：
兼容性测试简称CTS，指对所设计程序与硬件、软件之间的兼容性的测试。一般来说，兼容性指能同时容纳多个方面，在计算机术语上兼容是指几个硬件之间、几个软件之间或是软硬件之间的相互配合程度。
对于我们测试来说，通俗一点的理解可以认为是被测软件在不同的硬件平台（PC||Mobile）,不同的软件（浏览器），不同的操作系统平台、不同的网络环境中是否能够很友好运行的测试。
6.9.1兼容性测试—分类
6.9.2兼容性测试—作用
兼容性测试是软件测试过程必不可少的一个过程，没有兼容性测试的测试是不完整的测试，兼容性测试的存在是有一定作用的。
作用：
①兼容性测试能够进一步提高产品的质量，提高用户体验。
②兼容性测试能使软件与尽可能多的其他软件“和平共处”，尽可能达到平台无关性。
③兼容性测试能尽可能的保证软件存在的价值，它是衡量一个软件质量的重要标准。
④兼容性测试能使软件产品的市场更广阔。
6.9.3WEB兼容性测试
1、WEB兼容性测试方向
①浏览器兼容性
②操作系统兼容性
2、测试方法
①人工测试：测试工程师测试主流浏览器和常用操作系统测试主流程和主页面，看看主流程和主界面是否有问题。
②第三方测试工具：部分情况下，部分浏览器可以依赖第三方工具辅助测试。
3、内核分析
测试选型：
①Chrome：Webkit内核*1 &Blink内核*1
②FireFox：最新版本
③IE：7-11
④Safari：mac版本单独测试
⑤Edge：Window10
⑥360安全浏览器（双核）
⑦搜狗等其他浏览器任选其一
⑧如有需要Linux系统下FireFox、ChromeOS下Chrome
4、三方工具—IETESTER
①可以进行IE5.5-IE11的兼容性测试，能够满足一定程度的测试需求。
②但随着IETESTER后期维护乏力，对浏览器的支持不足。
③同时目前对于IE兼容性来说，更多支持IE7+，万平米可以使用IE浏览器自带的调试工具来测试，故IETESTER逐步从重要变为鸡肋。
5、三方工具—BrowserShots
①www.crowsershots.org通过在线截图的方式展现页面的兼容性。
②限制在于只可以通过输入网址的方式查看，对于还未上线，测试中的网站比较难于使用。
6、三方工具—Super preview
①SuperPreview是微软将推出的Expression Web 3的一部分，同时，微软也提供了SuperPreview的独立安装包。
②他的目标是集成IETESTER和BrowserShots的功能，但是目前还没有完善。
6.9.4APP兼容性测试
1、APP兼容性测试方向
①硬件设备兼容性
②操作系统版本兼容性
2、测试方法
①人工测试：测试工程师测试主流手机设备对主流程和主功能进行验证测试。
②第三方测试工具：三方主要以云平台为主。
3、设备选型TOP20
4、补充说明
①使用TOP20的机型，指定系统版本。
②Android 机一律要求使用真机或者相应的云服务测试，iOS允许使用模拟器。
③如果上述的设备无法获取到的，允许选取同类（iOS/Android ）机型作为替代，但最多不超过4个替代机型。