软件测试

核心业务功能产品特性

确定指标，如何衡量

数据类型覆盖引入线上数据

自动化

无法获知变更影响哪些功能

无法精确的选取测试用例

传统测试用例数量的增长会导致测试用例的代码覆盖率增长，但当覆盖率到达一定的数值时（75%左右），则出现了增长瓶颈，这时为了维护一个庞大的测试用例集，以保证产品新特性和老功能的正确性与稳定性，使覆盖率继续增长，需要花费越来越多的时间和人力成本

随着软件功能的不断丰富，相应测试用例集也愈加庞大，这时难免会出现“杀虫剂”效应，即：测试用例越来越多，而产品的“免疫力”也越来越强，测试效果却不明显。 造成这种问题的原因是，我们在测试早期已经发现了80%的软件缺陷，除非再花费巨大的人力和时间成本分析并增加大批量的测试用例，否则后期新增的测试用例已经很难再发现新的缺陷。

在传统测试理念中，每次添加新功能或者修复缺陷，一般都需要在产品上线前进行一轮全回归测试，哪怕这次的改动只有一行代码。但是，全回归测试的测试用例数量以及执行代价一般都比较大。 这里，我们之所以要采用全回归测试，是因为我们无法准确地知道这次更新到底会影响哪些功能，也无法知道应该从测试用例集中选取哪些必要的测试用例，无奈之下只能两眼一抹黑地执行全部用例。

在传统软件测试中，人工因素占据了测试数据的统计分析的绝大部分比重，由此导致测试数据本身的技术公信力不够高，进而需要依靠管理手段来保证真实的测试数据被准确地记录。这种做法不仅可靠性差，而且执行成本高。

如果完全基于黑盒测试，那么注定无法深入代码实现的细节，也就无法做到有的放矢地设计测试用例；而如果基于白盒测试技术，为了保证代码质量，往往会采用代码级测试和代码覆盖率技术。 但是，这些测试方法都强依赖于产品代码，一旦代码发生改变，很多测试都会因此失效，因此很难适应快速迭代的开发流程。 另外，由于目前的代码级测试和代码覆盖率技术还不支持测试用例级别的覆盖率分析，而是要将所有测试结果混在一起，导致白盒测试时无法区分代码覆盖率的贡献到底来自于哪个测试用例，这将极大地限制白盒测试工具在测试结果分析上的作用。

单元测试的目的在于发现各模块内部可能存在的各种错误， 主要是基于白盒测试

在C++这种面向对象的语言中，要进行测试的基本单元是类 或类的方法

单元测试的目的

单元测试的内容

单元测试环境

单元测试的开展

黑盒测试也称为功能测试,它着眼于程序的外部特征,而不考虑程序的内部逻辑结构。测试者把被测程序看成一个黑盒,不用关心程序的内部结构。黑盒测试是在程序接口处进行测试，它只检查程序功能是否能正常使用，程序是否能接收输入数据产生正确的输出信息，并且保持外部信息(如数据库或文件)的完整性。黑盒测试是基于用户角度进行的测试。

可以理解为静态的白盒测试或动态的黑盒测试，灰盒就是界于黑白之间, 对软件内部有所了解, 但不见得到了如指掌的程度, 却可以结合这些了解做些比黑盒多点的测试。

文档测试涵盖面很大，在软件的各个版本中均有所使用。随着软件版本的变化，文档测试的测试内容也有所变化。在需求分析以及原型架构阶段，文档测试主要目标是： Sitemap、动作分解列表、数据库ER图、UML用例图、流程图、需求文档等文档。

文档测试主要检查文档的正确性、完整性和可理解性。正确性是指不要把软件的功能和操作写错，也不允许文档内容前后矛盾。完整性是指文档不可以漏掉关键性内容。可理解性是指在文档中描述的语言要简明易懂，不能让别的开发人员拿到文档时看不懂文档的内容。

命名规范测试用于测试项目中的文件命名、代码以及版本号等书写是否符合规范。文件命名规范以及版本号命名规范可以参看第四部分里软件命名规范的详细信息；各种语言的命名规范可以参考语言自身的规范，如NoahWeb的可以参考 http://docs.noahweb.net附录中的《NoahWeb各类资源命名规范》。

需求完整性测试主要存在于需求探索阶段，在需求尚未完全明确之前对已收集到的需求做出整理性的、检查遗漏性的测试，确认需求是否明确。另外，需求完整性测试也承担着一部分澄清需求的任务。

在原型架构阶段，链接完整性的测试是非常有必要的。该项测试任务主要是检查假页面中各种链接是否完整，是否指向目标位置，属于检查性的测试。

页面完整性测试主要存在于集成测试阶段以及其后续其它阶段中，测试页面是否完整，页面质量是否达标，属于检查性测试。

UI合理性测试也就是人机交互界面的合理性，UI合理性测试的内容很多，具体测试内容如下：

因为在开发阶段开发人员随时都有可能根据需要来修改数据库，所以对数据和数据库完整性测试在软件项目的任何阶段也是非常必要的。该项测试内容主要是以数据库表为单位，检查数据库表以及表中各字段命名是否符合命名规范，表中字段是否完整，数据库表中的字段描述是否正确包括字段的类型、长度、是否为空，数据库表中的关系、索引、主键、约束是否正确。

功能测试在软件项目的任何阶段中都是重要的。实现功能，满足客户需求是软件本身最大的使命。功能测试在任何阶段下基本上都作为测试工作的第一项出现。该项测试任务主要为了测试已实现的功能是否满足需求，是否正确，是否有价值以及是否完整。在黑盒和白盒测试状态下，该测试均会被使用。

功能测试中测试人员往往会忽略掉一些细节问题，比如：一个功能的实现必须要经过6步操作才能完成，而且需要加入20条信息才能看得出测试结果，有的测试人员为了节省时间虽然做完了6步操作，但是没有加入足量的信息，,使得测试不全面,正是因为这样而导致一些隐藏的BUG没有被测试出来。所以说在功能测试中要按部就班的把所有要进行的测试功能每一步都执行一遍，应该添加的数据都添加完整，以避免遗漏掉BUG没有测试出来。

压力测试是为了发现在什么条件下您的应用程序的性能会变得不可接受。这通过改变应用程序的输入以对应用程序施加越来越大的负载并测量在这些不同的输入时性能的改变来实现的。这种操作也称为负载测试，但是负载测试通常描述一种特定类型的压力测试——增加用户数量以对应用程序进行压力测试。

对应用程序进行压力测试最简单的方法是手工改变输入（客户机数量、需求大小、请求的频率、请求的混合程度等等）并描绘性能的变化。但是如果有许多输入，或者需要在大的范围内改变输入，那么你可以借助一个自动化的压力测试工具来完成此测试。

安全性测试主要是测试系统在没有授权的内部或者外部用户对系统进行攻击或者恶意破坏时如何进行处理，是否仍能保证数据和页面的安全。测试人员可以学习一些黑客技术，来对系统进行攻击。 另外，对操作权限的测试也包含在安全性测试中。具体测试内容如下：

执行添加、删除、修改等动作中是否做过登录检测。

退出系统之后的操作是否可以完成。

所有插入表单操作中输入特殊字符是否可以正常输正常存储，特殊字符为：！?#￥%……—*（）~——-+=[]{}、|；：‘”？/《》<>，。

在带有参数的回显数据的动作中更改参数，把参数改为特殊字符并加入操作语句看是否出错。

测试表单中有没有做标签检测，标签检测是否完整。

在插入表单中加入特殊的HTML代码，例如：<marquee>表单中的字本是否移动？</marquee>。

页面中时常使用到JavaScript脚本，为了降低页面的出错率，则必须对页面脚本进行测试。其主要内容包括：相关页面中的脚本是否正常运行，JavaScript脚本是否有错误页面。

提示文本测试从严格意义上来讲应该属于UI合理性测试的一部分，该项测试主要针对各个页面中使用到的大量提示文档进行测试，主要包括：表达不明确的位置是否有提示文本、提示文本的弹出是否正常、提示信息含义是否明确易懂。

由于B/S结构项目是基于浏览器运行的，所以需要对浏览器进行必要的测试。该测试任务主要是软件对各种浏览器（IE5.5、IE6.0、 FireFox浏览器 ）的支持是否正常，在IE浏览器中可以正常显示的页面在其它浏览器中是否可以正常显示。

在软件项目的后期阶段，会对做好的软件进行打包把软件做成安装程序，以便用户可以正确的安装使用，所以需要对做好的安装文件进行安装功能方面的测试。该测试的主要任务是：检查软件是否能够正常安装使用、是否可以完全卸载此软件的所有功能和页面。

在常规测试时可能表中的测试项不能满足测试要求，如果有特殊测试项请测试人员自己定义修改测试的类型。

功能(初级-专职过渡阶段)

性能(初级）

自动化(初级）

安全(初级）

白盒(初级）

业务(初级）

小组长，主管(初级）

质量保证工程师SQA(专职业务线)

测试分析师（专职-领导过渡阶段）

测试架构师初级专职-领导过渡阶段）

测试经理（执行领导-管理路线）

QA经理（执行领导-业务路线）

产品经理（执行领导-业务线）

项目经理（执行领导-技术路线）

系统分析师

测试培训师

测试总监

产品总监

行业资讯顾问

研发总监

项目总监

明确测试的目标和测试范围

根据测试目标和范围，选择相应的测试方法和策略

根据测试目标、范围、方法和策略，制定详细的测试计划

根据测试计划，编写详细的测试用例

根据测试计划和测试用例，执行测试

对测试结果进行分析

根据测试结果和分析，编写详细的测试报告

对测试的目标、范围、方法、策略等进行简要概述，以便读者了解测试的基本情况

对测试过程中的所有测试结果进行记录，

对测试过程中发现的所有问题进行记录

根据测试结果和问题列表，提出相应的建议

对整个测试过程进行总结

简明扼要：测试报告应该简洁明了，突出重点，避免冗长和重复。

准确无误：测试报告应该准确无误，所有数据和信息应该经过验证和确认。

规范统一：测试报告应该符合规范和标准，格式和样式应该统一。

重点突出：测试报告应该突出重点，重要的信息应该放在显眼的位置。

逻辑清晰：测试报告应该逻辑清晰，信息的组织和呈现应该合理有序。

1）等价类划分法

2）边界值法

3）因果图法

4）判定表法

5）正交排列法

6）测试大纲法

7）场景法

白盒测试是一种测试方法，它通过对软件内部结构的了解和分析，来设计测试用例，以检查软件的正确性、完整性和优化性。

语句覆盖测试：测试用例能够覆盖软件中的每一个语句，以检查每一个语句是否正确执行。

判定覆盖测试：测试用例能够覆盖软件中的每一个分支，以检查每一个分支是否正确执行。

条件覆盖测试：测试用例能够覆盖软件中的每一个条件，以检查每一个条件是否正确执行。

路径覆盖测试：测试用例能够覆盖软件中的每一条路径，以检查每一条路径是否正确执行。

边界值测试：测试用例能够覆盖软件中的边界值，以检查软件在边界值处是否正确执行。

错误处理测试：测试用例能够覆盖软件中的错误处理代码，以检查软件在出现错误时能否正确处理。

白盒测试方法的选择应该根据软件的特点和测试目标来确定，以保证测试的全面性和有效性

灰盒测试是介于白盒测试和黑盒测试之间的一种测试方法，它既考虑了软件的内部结构，也考虑了软件的外部行为。

数据库测试：测试数据库的正确性、完整性和安全性，以保证软件的数据存储和处理功能正常。

界面测试：测试软件的用户界面，包括界面的布局、颜色、字体、交互等，以保证软件的易用性和美观性。

集成测试：测试软件的不同模块之间的集成，以检查模块之间的接口是否正确，以及模块之间的交互是否正常。

性能测试：测试软件的性能和稳定性，包括响应时间、负载能力、并发能力等，以保证软件的可靠性和可扩展性。

安全测试：测试软件的安全性，包括网络安全、数据安全、用户身份验证等，以保护软件的安全和用户的隐私。

定义测试数据需求：根据测试用例和测试目标，定义测试数据的类型、格式、数量和质量等需求。

收集测试数据：根据测试数据需求，收集测试数据，包括手动输入、从生产环境中提取、从第三方数据源中获取等方式。

组织测试数据：将收集到的测试数据进行分类、整理和归档，建立测试数据库或测试数据仓库，以便于管理和使用。

清洗测试数据：对测试数据进行清洗和处理，包括去重、去噪、格式化、转换等操作，以保证测试数据的准确性和一致性。

生成测试数据：对于某些特定的测试场景，需要生成特定的测试数据，可以使用测试数据生成工具或编写脚本进行生成。

验证测试数据：对于重要的测试数据，需要进行验证和审查，以保证测试数据的正确性和合法性。

测试数据准备需要根据具体的测试需求和测试类型来确定，同时需要注意测试数据的保密性和安全性，避免敏感信息泄露和数据损坏。

story描述更详细

UI/UX输出

关联功能联动

story串讲

开发反串讲

测试点串讲

开发自测

bug数量

模块问题率收集

晨会

版本封板质量会

story用例使用飞书思维导图编写

代码静态扫描门禁

可测试性植入

更加符合敏捷测试的测试策略的制定

人员能力

问题都是Dev leader和PM商量说了算

项目的主动权都在测试这边，某个bug的要不要解决，或者项目进度控制都是测试leader说了算。

快的前提是什么

项目组的每个成员都被明确告知，如果这个项目每delay一天，就会损失多少个million的美元