个人测试架构体系

个人测试架构体系

软件测试全流程

健全的测试流程有助于规范测试各阶段活动的进行。本文主要描述测试全流程中各阶段活动的出入口条件、工作重点。

测试需求分析

责任主体：所有测试人员，测试经理负责组织

入口条件：客户需求说明书已完成签字。

工作重点：参与版本的所有测试人员熟悉所有交付需求，可以通过测试需求反串讲确认测试人员对需求的理解程度，可以安排产品经理或者架构师答疑。

出口条件：没有明确的文档承载，可以是疑问的澄清列表、重点需求或者易忽略需求描述记录的文档。

测试策略和测试计划

责任主体：测试经理，其他人参与评审、熟悉策略

入口条件：客户需求说明书已完成签字、产品经理完成需求传递、项目经理完成开工会。

工作重点：根据项目组通用的测试策略和测试计划模板完成测试策略，编写责任人通常是测试经理。完成后发起测试策略评审，参与人为项目中核心角色，包括项目经理、开发leader、产品经理、所有测试人员等。评审完成后对评审问题确认、修改，基线后归档到指定目录下。

出口条件：基线的测试策略文档

用户验收测试用例设计

责任主体：负责设计客户验收测试用例测试人员

入口条件：客户需求说明书已完成签字

工作重点：根据验收手册设计规范和签字的用户需求设计测试用例，设计原则基本是最小覆盖原则。用例模板参考项目组要求。完成后需评审、修改、基线。

测试用例基本概念

测试用例是为特定的目的而设计的一组测试输入、操作步骤和预期结果。每个测试用例都是用户实际可操作的步骤，通过测试用例的执行去

验证交付给客户的软件的功能是满足的用户的要求。测试用例不局限于功能测试用例，同时包括性能测试用例、安全测试用例及可靠性、可服务性等测试用例。

测试用例组成元素

1、用例序号。唯一标识用例。

2、用例标题。该测试用例的验证的主要概括，也就是描述该测试验证系统的功能点。

3、预置条件。条件描述清晰、无二义性，同时要考虑运行状态。预置条件包括修改标志位、预置和清除数据、修改配置文件等

4、操作步骤。步骤描述清晰、完整、精炼。步骤主要包括各种输入动作、控件按钮操作等。

5、预期结果。完整性（列出所有检查点）、正确性（检查点可检查）、需要包含过程打印日志的验证。

6、用例优先级。标志用例执行的优先级，Level0/Level1/Level2。考虑版本进度、质量目标、成本等因素影响，优先级高的用例优先执行。

7、测试类型。通常类型包括功能、兼容性、性能、安全、可靠性、可服务性等。

8、是否自动化。标识用例是自动执行还是手工测试

9、设计人员。

高质量测试用例要素

1、完整性，确保用例集覆盖所有功能点无遗漏。

2、有效性，尽量减少冗余用例，提供用例命中率。

3、准确性，能够正确反映系统的行为和状态。

黑盒测试用例设计方法

1、等价类。不仅要考虑输入等价类，也要考虑输出等价类进行覆盖。

2、边界值。考虑边界5点（上点、离点、内点）

3、因果图。考虑元素间的依赖、约束关系的用例设计。

4、判定表

5、错误推测

6、功能图

7、场景图

测试用例设计综合策略

前面我们已经分析讨论过了等价类、边界值、因果图、判定表、错误猜测等测试用例设计方法，但是我们知道，每一种方法都可以提供一组具体的有用的测试用例，但是都不能提供一个完整的、覆盖全面的测试用例集。因此，我们需要组合这些已知的测试用例设计方法、发挥各项测试设计方法的优点，设计出用例数少且覆盖全面的测试用例集。一组合理的策略如下：

用例设计测试策略

下述组合测试用例设计测试策略并不能保证可以发现程序所有的bug，但实践证明一个合理的折中方案。具体的方法如下：

（1）如果规格说明中包含输入条件组合的情况，应该首先使用因果图分析方法。

（2）在任何情况下都应该使用边界值分析方法。一定要记住，需要同时对输入和输出的边界进行分析。边界值分析可以产生一系列补充的条件。这些补充条件通常可以整合到因果图分析中。

（3）应为输入和输出确定有效和无效等价类，在必要情况下对上面确认的测试用例进行补充。

（4）使用错误猜测技术增加更多的测试用例。

（5）针对上述测试用例集检查程序的逻辑结构。应使用判定覆盖、条件覆盖、判定/条件覆盖或多重条件覆盖准则（最后的一个最为完整）。如果覆盖准则未能被前四个步骤中确定的测试用例所满足，并且满足准则也并非不可能（由于程序的性质限制，某些条件的组合也许是不可能实现的），那么可以增加足够数量的测试用例，以使覆盖准则得到满足。

业务特性测试策略

用例设计的结果是业务能力和测试能力、团队能力结合的综合体现。上述主要针对测试用例设计组合的测试策略的方法，这里，也谈谈个人对业务特性测试设计的测试策略：

（1）针对单特性考虑测试用例设计，单特性内可以考虑采用分而治之策略划分特性。不同的产品开发团队的组成方式可能不同。我经历过的有按照产品模块划分的、也有按照特性划分的。不管是以哪种形式划分，在分析规格时，先拆分业务特性（按业务模块或子特性）理解进行用例设计。业务颗粒度不大情况下会分析的更透彻，也就可以更有针对性的进行用例设计。

（2）考虑新特性（新增或修改）与产品其他特性的关联性，补充测试用例设计。这里最重要的一点是测试设计人员必须非常熟悉业务。同时，最好有产品特性矩阵。否则，很难完整的分析出特性间的影响关系。

（3）组织用例评审。邀请SE、TSE、MDE、TM等核心成员评审，利用团队的力量保证用例覆盖全面性。

（4）根据代码覆盖率执行结果重新设计测试用例去覆盖未覆盖到的测试逻辑。某些异常场景确实无法构造，也必须安排开发MDE进行代码走读确保逻辑无问题。这一条通常有要求执行代码覆盖率操作的产品才会实施。

测试用例执行规范

测试执行在测试工作中占了很大比重，有效的测试执行可以将测试用例发挥最大的价值。因此，测试用例规范执行有助于更好的发现代码中存在的缺陷。根据个人测试工作经验，好的测试执行应该包含如下内容：

1、测试执行中评估测试执行时间不足，需及时上报风险。满足质量优先，进度其次原则。

2、测试用例按优先级顺序执行，通常是基本、详细和异常顺序执行。

3、未执行用例、标志为删除或者无效的用例，需注明原因。

4、执行过程中有疑问的测试用例（场景、操作步骤、检查点等）需找测试设计人员澄清。

5、测试执行需对用例描述的检查点逐一检查，避免遗漏。

6、重视不易重现的缺陷场景，可能是一个bug。

7、执行过程中发现有前期设计遗漏用例需补充到用例文档并执行验证。

8、建议测试人员交叉执行重复测试用例，用例执行对相同测试人员有免疫性。避免可能的缺陷一直遗漏到现网。

9、如有需要，建议保留测试结果，结果可视。也便于不同版本间的测试结果对比。

10、已确认问题需及时按照问题单提单要求（规范和缺陷定级）提单。

11、跟踪问题单修复情况并回归验证问题单。

12、每轮次测试结束，find一下是否有core文件产生。

13、测试结束，将最终测试用例文档上传到归档目录，实现用例重用。

启发式测试策略模型(HTSM)

什么是HTSM

启发式测试策略模型（Heuristic Test Strategy Model，简称HTSM）是测试专家James Bach提出的一组帮助测试设计的指南（Guide line）。HTSM由一组指导性词语组成，它们构成一个

层次结构，让测试人员从高层抽象到底层细节对产品和测试进行思考。

为什么需要HTSM

HTSM中指导性词汇是测试的指南，其作用不是教导如何具体地测试，而是启发测试人员的思维，发掘测试对象和测试策略，重点在于"启发式"。HTSM对于测试设计的意义：

（1）测试设计以风险驱动。测试人员分析质量标准、项目环境、产品元素中的风险，设计有针对性的测试策略。

（2）在测试设计时，质量标准启发测试先知（Oracles），项目环境启发测试过程（Procedures），产品元素启发测试覆盖（Coverage），观察到的质量启发测试报告（Reporting）。

（3）对于测试，HTSM强调测试策略的多样性（Diversification），平衡代价和收益（Cost vs. Value），利用启发式方法（Heuristics）充分发挥测试人员的技能（Skill）。

HTSM的内容

上图是HTSM的概要描述，测试人员利用质量标准（Quality

Criteria）、项目环境（Project Environment）、产品元素（Product Element），指导测试技术（Test
Techniques）的选择与应

用，并产生观察到的质量（Perceived Quality）。

HTSM是层次结构，其顶层元素（质量标准、项目环境、产品元素、测试技术）可以分解为次层元素，而次层元素可进一步分解为第三层元素。本文只概要介绍次层元素，更多的细节请参考James Bach的文档。

测试技术：生成测试的策略。有效地选择和实施测试技术，需要综合分析项目环境、产品元素和质量标准。

功能测试(FunctionTesting):测试系统能够完成的功能。

（1）找出产品能够做的事情（功能和子功能）。

（2）判断你将怎么才能知道一个功能是否能正常工作。

（3）测试每个功能，一次测试一个。

（4）看看每个功能是否做了应该做的，而没有做不应该做的。

域测试(Domain Testing)

（1）分析产品的输入输出数据集。

（2）判断测试的特殊值。考虑边界值，典型值，常用值，无效值，以及最具代表性的值。

（3）考虑需要在一起测试的数据的组合。

压力测试(Stress Testing)

（1）找出在挑战性的数据或者压倒性的资源面前对超载或者“破坏”敏感的子系统和功能。

（2）辨识出与那些子系统和功能相关的数据和资源。

（3）选择或生成测试所需的挑战性的数据或约束条件的资源：例如，大量或复杂的数据结构，高负载，长时间运行，大量的测试用例，低速存储器的情况。

工作流测试(Flow Testing)：做完一件事再做另一件。

（1）定义把具体的多个活动首尾链接起来测试过程或者高水平的用例。

（2）在两个测试之间不要重置系统。

（3）改变时间和顺序，并且尝试并发的线程。

场景测试(Scenario Testing)：作为一个强制性的故事来测试。

（1）首先，思考与产品关联的每一件事。

（2）设计把产品中有意义的和复杂的相互作用包括在内的测试。

（3）一个好的场景测试是一个关于一些人或事可能对产品进行怎样的操作故事。

约束测试(Claims Testing)：验证每一条约束。

（1）在产品的参考资料中辨识出其包含的约束（隐藏的或直接的）。

（2）分析单个的约束，并明确比较含混的约束。
 验证产品的每条约束是否是正确的。

（3）如果你测试的依据是详细的规格说明书，就很值得使用这个技术，并且会把产品做的比较标准。

用户测试(User Testing)：涉及了用户的测试。

（1）分清楚用户的类别和角色。

（2）判断每类用户会执行什么样的用例，怎样来执行，以及这样做的价值。

（3）获得真实的用户数据，或者让真实的用户来测试。

（4）否则，就要系统地模拟一个用户了（当心――想像你是一个用户很容易，但是实际上你并不是）。

（5）非常有效的用户测试应该要涉及各种各样的用户和用户角色。而不是仅仅一个。

风险测试(Risk Testing)：设想一个问题，然后去找到它。

（1）这个产品会有哪些种类的问题？

（2）哪种问题是最要紧的？关注那些问题。

（3）如果真有这些问题，你将怎样来侦测？

（4）做一个有趣的问题的列表，并特别设计一些测试来发现这些问题。

（5）可能需要一些帮助，包括咨询顾问、设计文档、以前的缺陷报告、或者使用风险启发法。

自动化测试(AutomaticTesting)：运行大量不同的测试。

（1）寻找适合自动的生成大量的测试的机会。

（2）开发一套自动化的、高速评估的机制。

（3）写程序来生成、执行并评估这些测试。

项目环境：资源、约束和其他影响测试的项目元素。测试总是受到项目环境的约束。在某个团队运转良好的策略不一定适合另一个相似的团队，以往富有成效的方法未必适应当前的项目。有经验的

测试人员会根据当前语境（Context），在约束条件下充分运用资源，以高效地测试。

用户(Customers)：这个测试项目中作为客户的任何人。

（1）你知道谁是你的客户么？谁的意见要紧？谁从你做的工作中受益或者利益收到损害？

（2）你同你的客户联系和交流过了么？可能他们对你的测试有帮助。

（3）可能你的客户对你要创建和运行的测试有很强烈的想法。

（4）可能客户之间对测试有相冲突的期望。你可能不得不帮着分析清楚并解决这些冲突。

信息(Information)：关于需要被测试的产品或项目的信息。

（1）有任何的可获得的工程文档么？用户手册？网上的资料？

（2）这个产品有历史渊源么？有已经被修复或者遗留的老问题么？客户有经常抱怨什么？

（3）在你知道怎么测试该产品之前，你需要更熟悉该产品么？

（4）你的信息是最新的么？你怎样得知新的或者修改的信息？

（5）看起来信息好像异乎寻常少的产品中有任何复杂或者富有挑战性的部分么？

开发者关系(DeveloperRelations)：你怎样同程序员相处。

（1）傲慢型：开发团队看起来对于产品的任何方面都过于自信？

（2）防卫型：产品中存在开发人员似乎很奇怪地反对进行测试的部分？

（3）融洽：你同开发人员发展出了一种伙伴合作关系？

（4）反馈环路：你能同程序员根据需要进行快速交流么？

（5）反馈：开发人员对你的测试策略怎么想？

测试团队(Test Team)：任何会执行或支持测试工作的人。

（1）你知道谁会来测试这个项目？

（2）有不在测试团队中，但可能会有帮助的人么？有人以前测试过类似的产品，并可能提供一些建议么？作者？用户？还是程序员？

（3）你有足够的有正确的技能来执行一个合理的测试策略的人么？

（4）这个团队有没有基于一些特殊技能或者动机地需要，来刻意执行使用一些测试技术？

（5）需要任何的培训么？可以获得一些什么培训？

设备与工具(Equipment &Tools)：管理测试所需要的硬件、软件或者文档。

（1）硬件：我们有执行测试所需要的所有的设备么？是否已经安装好，并准备运行了？

（2）自动化：需要使用任何的自动化测试工具么？工具是否都准备好了？

（3）探测器：在测试产品时，需要任何辅助性的工具来帮助我们观察么？

（4）矩阵和一览表：有需要跟踪或者记录测试的进程的任何文档么？

进度(Schedule)：项目事件的顺序、持续时间和同步。

（1）测试设计：我们有多少时间？这些测试晚一点创建是否会好一点？

（2）测试执行：测试应该什么时候执行？是否有些测试要被重复的执行，比如说，在回归测试中？

（3）开发：版本什么时候可以来测试，增加了功能，代码冻结，等等？

（4）文档：用户文档什么时候可以评审？

测试项(Test Items)：被测试的产品对象。

（1）范围：在你的测试职责范围中，包含产品中的哪一部分功能，不包含哪些？

（2）可用性：你有需要被测试的产品么？

（3）易变性：产品是否在不断的变化？再次测试时需要些什么？

（4）新元素：最近，产品中新增或者修改了些什么？

（5）可测试性：产品的功能和可靠性是否足够让你能有效的来进行测试？

（6）将来的版本：你测试中哪部分，如果有的话，必须被设计来应用到产品的将来的版本中？

交付件(Deliverable)：测试工程的可以看得见的提交物。

（1）内容：你要提交哪种报告？你会分享你的工作记录，还是只有结果？

（2）目的：你的提交物是不是作为产品的一部分？有别的其他人要运行你的测试么？

（3）标准：你有要遵循的一些特别的测试文档标准么？

（4）媒体：你要怎样记录和并与其它人交流你的报告？

产品元素：需要测试的对象

结构(Structure): 构成产品本身的任何东西。

（1）代码。构成产品的代码结构，从可执行到独特的例程（from executables to individual routines）

（2）接口。子系统间连接和通讯的点。

（3）硬件。对产品必不可少的任何硬件组件。

（4）非可执行的文件。与多媒体和程序不同的任何文件，例如文本文件，样品数据，或者帮助文件。

（5）附属品。产品中除了软件和硬件之外的任何其它部分，例如纸质文档，Web链接和内容，包装，许可声明，等等…

功能(Functions)：产品能做的任何事情。

（1）用户界面。用来给用户交互数据的任何功能（例如，浏览器，显示界面，数据输入窗口）。

（2）系统接口。用来给不同于用户的其它事物交互数据的任何功能，例如，其它程序，硬件，网络，打印机，等等。

（3）应用。用来定义或区分产品或者实现核心需求的任何功能。

（4）算法。任何计算的功能或者算法的操作嵌入在其它功能里面的。

（5）与时间有关的。暂停时间设置；每日或每月报告；每晚的批处理作业；时区；商业假日；利息算法；条款和担保期；以及要求精确的功能。

（6）改变。修改或改变某些东西的功能（例如，设置字体，插入剪贴画，从账户中取钱）

（7）startup/shutdown。启用和初始化或者退出产品时需要用到的任何方法与接口。

（8）多媒体。声音，图片、视频、或者嵌入在产品中任何图形化的显示。

（9）出错处理。侦测错误并从错误中恢复的任何功能，包括所有的错误信息。

（10）集成交互。产品的功能之间的任何交互或接口。

（11）可测性。提供的可以用来帮助测试的任何功能，例如诊断(diagnostics)，日志文件，断言，测试的菜单，等等

数据(Data)：产品处理的所有东西

（1）输入。产品要处理的任何数据。

（2）输出。产品处理过的结果数据。

（3）预设值：作为产品的一部分提供的任何数据，或者直接在产品中创建的数据，例如初始化数据库，系统默认值，等等。

（4）配置项：任何内置的并且会在多个操作持续使用数据。包括产品的状态或样式，例如参数设置，视图模式，文档目录，等等。

（5）数据排序：数据的任何顺序或排列，例如文字的排序，分类或未分类的数据，测试顺序。

（6） 数据规模(Big and little)：数据的大小和聚集的变化量。

（7）异常数据：以不受控制或不正确的方式产生的无效的、被破坏掉的、或者产生的任何数据或者状态。

（8）生命周期：在数据实体的整个生命周期中的变化，包括创建、访问、修改和删除。

平台(Platform)：产品所依赖的所有事物

（1）外部硬件。并不是要交付的产品的一部分，但是是为了保证产品运行的必须的硬件组件和配置（或者是可选的）：CPU，内存，键盘，外设，等等。

（2）外部软件。并不是要交付的产品的一部分，但是是为了保证产品运行的必须的软件组件和配置（或者是可选的）：

（3）操作系统。同时执行的应用程序，驱动，字体，等等。

（4）内部组件。被嵌入在你的产品中，但是不是由你的项目生产的库或者其它组件。既然你不能控制它们，你必须决定如果它们失效了该做些什么来解决问题。

操作(Operations)：产品将会被怎样的使用

（1）用户：各种不同的用户的属性。

（2）环境：产品操作所在的物理环境，包括例如噪音、灯光、和分心的事物这样的元素。

（3）正常操作(Common Use)：产品输入的模式和顺序可能会与通常的使用习惯冲突。这根据用户的不同而不同。

（4）异常操作(Disfavored Use)：由不了解、误解、不小心或者恶意的使用产生的输入模式。

（5）极端操作(Extreme Use)：挑战与产品期望的使用方法一致的输入模式和顺序。

时序(Time)：产品与时间之间的任何关系。

（1）输入/输出：什么时候提供输入，什么时候创建输出，以及他们之间的时间联系（延迟、间隔，等等）。

（2）快/慢：用“快速”输入或者“慢速”输入来测试；最快和最慢；快和慢结合起来测试。

（3）变化率：加速和减慢（峰值、突然爆发、中止、瓶颈、中断）。

（4）并发：一次发生超过一件事情（多用户，分时，线程、信号、和共享数据）。

质量标准之操作性标准（OperationalCriteria）：面向用户和运营团队

能力(Capability): 产品是否能完成需要的功能

可靠性(Reliability): 是否运行得很好并且在所有需要的情况下都不会失效？

（1）出错处理。产品在出错的时候抵制失效，并很快恢复，这在失效时是非常棒的。

（2）数据完整性。业务数据避免丢失或者被破坏

可用性(Usability): 对于一个真实用户来使用这个产品到底有多容易？

（1）可学习。产品的预期用户能够很快的掌握其操作。

（2）可操作。产品操作起来不会很费劲，也不会很麻烦。

（3）可接近。产品接近相关的标准，并且与操作系统的相关标准比较接近。

安全性(Security): 在保护产品不受到非法的使用或入侵上做得有多好？

（1）证明。系统验证用户的确是她所说的那个人的方式。

（2）授权。授予被证明的用户不同程度的权限级别的权利。

（3）隐私。客户或雇员数据避免受到未授权的人的危害的方式。

（4）安全漏洞。系统不能保证安全的方式（例如社会工程的脆弱性）。

可伸缩性(Scalability): 产品按照比例放大或缩小的部署表现得有多好？

性能(Performance): 系统有多快的响应速度？

可安装性(Installability): 产品安装到目标平台上有多容易？

（1）系统需求。如果一些必须的组件缺失或者无效，产品是否能够识别？

（2）配置。系统的哪一部分会受到安装的影响？这些文件和资源都保存在什么地方？

（3）卸载。当产品被卸载时，是否可以干净的移除？

（4）升级。新模块或者版本是否能很容易的增加？它们是否不改变已有的配置。

兼容性(Compatibility): 同外部组件和配置一起运行得有多么好？

（1）应用兼容性。产品和其它软件产品一起运行。

（2）OS兼容性。产品运行在特定得操作系统上。

（3）硬件兼容性。产品运行在特定的硬件组件和配置上。

（4）向后兼容性。产品同自身早期的版本一起运行。

（5）资源利用。产品没有使用不必要的大量内存、存储空间，或者其它系统资源。

质量标准之开发标准（Development Criteria）：面向开发团队

可支持性(Supportability): 是否可以很经济的为产品用户提供支持？

可测试性(Testability)：产品如何能够被有效的测试？

可维护性(Maintainability)：是否可以很经济的对产品进行打包、修复或者增强？

可移植性(Portability)： 是否可以很经济在其它地方移植或重用该技术？

本地化(Localizability)： 产品是否可以很经济的适应其它地方？

（1）规则。是否有超越州或国家边界的不同的规则或报告的需求？

（2）语言。产品能容易适应更长信息,从右到左或者表意字的字体么？

（3）货币。产品能够支持多币种么？币种汇率呢？

（4）社会或文化差异。顾客可以发现文化参考资料中有令人费解的或者侮辱的吗?

性能测试全流程

性能测试阶段划分为需求阶段、测试准备、测试过程和测试结束四个阶段。根据个人性能测试经验，经常会出现某个过程的某些检查点遗漏而导致返工造成工作量浪费的浪费，进而影响测试进度。这里总结一下每个测试阶段关注点。

需求阶段

1、了解性能测试需求背景。需要先搞清楚为什么要进行本次性能测试需求。通常进行性能测试常见有以下几种：

（1）逻辑复杂且用户使用较多的新需求；

（2）核心功能逻辑变更或者增加处理逻辑可能影响性能；

（3）重现生产问题需要压测性能；

（4）生产需要替换新硬件，需要获取新硬件业务性能指标；

（5）生产环境需要扩容，了解现网环境指标。 

2、评审性能测试需求方案，明确性能测试需求。

（1）测试硬件环境要求。主要包括服务器型号、CPU个数、内存大小、磁阵型号。

（2）测试软件要求，包括操作系统类别和版本、Oracle版本、业务版本、JDK版本、中间件版本。

（3）确业务模型。主要包括总TPS数、是单一场景还是混合场景压测，混合场景各各业务的TPS值分别是多少。

（4）数据模型。主要包括用户模型（注册用户数、活跃用户数、非注册用户数、不同层级用户数等）、交易历史记录表数量<特别是查询历史交易记录性能>及其他关键大表。

（5）数据收集要求，是否有无特别要求。主要包括TPS、成功率、响应时间。其他可能会要求TPS数和资源消耗的曲线图。

（6）测试测试交付件。主要包括性能测试报告、性能测试过程记录截图等。

（7）测试组网。是单网元还是负载均衡。

（8）测试工具。是否有特殊工具的要求、是否需要License、是否需要新开发测试套，谁负责提供

3、评估测试工作量。除了任务本身工作量外，需要考虑依赖测试资源的到位时间点。

4、输出性能测试策略和测试计划并评审。评审角色要求项目经理、测试经理和开发一同评审。

准备阶段

1、检查操作系统版本、orace版本、JDK版本、中间件版本。

2、调整操作系统内核参数与生产环境保持一致。

3、调整Oracle核心参数与生产环境保持一致。包括Oracle SGA大小、processes/sessions数、大内存页设置、redo文件大小、temp/system表空间大小等

4、检查文件系统规划和oracle数据文件规划是否与生产环境一致。特别注意的是oracle数据文件通常是在磁阵上。

5、检查文件系统空间和oracle数据表空间大小。特别是写文件空间和业务插数据表空间。

6、检查影响性能的业务核心参数与生产环境一致。比如线程数、JVM大小、静态控制参数等。

7、导入业务数据，调试业务功能成功。参数化数据第1个、中间、最后1个调试业务全部成功。

8、关闭所有业务环境的debug日志打印，清理log和temp文件以及性能统计文件。

测试过程阶段

1、检查压测工具发起TPS数、测试工具是否有错误日志。

2、检查业务环境是否有错误日志。

3、检查环境消息队列是否正常接收和处理，是否有不断堆积接收消息。

4、检查业务环境接收处理TPS是否与测试工具发起一致。

5、检查业务处理消息成功率，通常要求100%。

6、检查业务处理响应时间分布情况。

7、检查服务器资源消耗情况，主要是CPU、内存和IO资源消耗。业务不同，资源瓶颈不同。

8、记录测试过程数据，包括参数调整、发现的问题、TPS及对应资源消耗收集(CPU、内存、IO)、响应时间、成功率等。

9、所有上述检查项处于正常范围后，可进行持续压测至少30分钟进行数据收集（TPS及对应资源消耗收集(CPU、内存、IO)、响应时间、成功率等）

测试结束阶段

1、所有测试用例已执行完成，测试结果达标。如果不达标，已分析出结论。

2、测试过程参数调整已确认、发现问题已提单并完成处理。

3、测试报告按照模板或者指定要求完成输出。

4、确认测试环境是否保留及保留时长。如不需保留，清理恢复测试环境。

接口测试用例设计策略

接口测试主要分为系统作为服务端和系统作为客户端2种类型考虑进行用例设计。接口测试需要考虑业务组网和接口类型。通常来说系统在一个接口测试场景中会同时作为服务端和客户端。

系统做服务端考虑

1、功能。系统能够正确处理所有参数正常值、异常值，并按照要求响应客户端，包括结果码、成功或者失败处理消息等。

2、性能。系统能够处理客户指定的性能指标、最大压测TPS，确保消息不丢失。系统最可以考虑静态、动态负荷控制（流控）。

3、并发。系统能够正确处理并发，不造成客户损失。特别是支付类（涉及钱）接口。

4、安全。需要考虑协议安全、参数传输安全（密码加密传输）、访问权限控制、其他安全控制（如pin多次错误输入锁pin）。

5、组网考虑。业务处理结果能够正确返回对应的客户端。

系统做服务端用例设计

1、参数完全覆盖，用例是否覆盖所有必须参数、可选参数；

2、参数值范围设计，用例是否包含参数设计的范围内所有的值，如果是枚举，需要逐一覆盖；

3、参数状态设计，用例是否包含改参数所特有的状态（如密码参数，包含正常、过期、锁定、待修改等）

4、参数边界值设计，用例是否包含边界5点（上点、内点、离点）；

5、参数属性设计（必选），用例是否包含参数不存在、参数值为空；

6、参数属性设计（可选），用例是否包含该参数不存在、参数存在但是值为空；

7、参数间关系设计。用例是否包含参数间约束、依赖关系。

8、参数安全性设计，考虑参数是否需要加密，用哪种安全算法加密，考虑正确加密密文、正确明文进行设计；

9、参数边界值设计，用例是否包含边界5点（上点、内点、离点）；

10、接口消息传输协议考虑，是否需要使用安全协议，如HTTPS。

11、参数响应结果设计。用例是否对响应结果的结构检查、所有成功或者失败结果码和消息的覆盖。

12、组网考虑。用例是否包含返回给客户端的消息能否正确返回到发送的客户端。

13、访问权限设计。用例是否包含用户有权限、无权限访问场景。

系统做客户端考虑

1、功能（报文发送）。系统能够按照协议规范或者格式要求正确发送报文。

2、功能（响应结果处理）。系统能够正确处理服务端响应的结果，并按照响应结果在本系统进行正确处理。响应结果考虑成功，失败，超时。

3、组网。系统能够将报文正确发送到指定的服务端。

系统做客户端用例设计

1、参数完全覆盖，用例是否覆盖所有必须参数、可选参数。这里需要考虑2种情况。一种是用户直接与系统交互输入相应的信息，系统根据设计拼接对应参数发送到服务端。另一种是系统根据用户输入再加工后再发送报文到服务端。对于后者需要针对性设计。

2、参数默认值。用例是否包含不指定参数默认值和指定默认值参数的值。

3、组网考虑。是否是否包含考虑报文正确发送的指定功能的服务端。

4、响应结果处理。用例是否包含第三方返回成功结果码和成功结果码及相应消息的场景。

5、响应结果处理（超时）。用例是否包含对服务端超时响应的处理，重点关注业务对超时处理逻辑（消息重发、按照成功还是失败处理或者是挂起手工干预等）。

6、超时结果处理。用例是否包含超时结果处理。比如手工干预，设计用例手工干预成功或者手工干预失败，包括单个和批量干预情况。

7、超时时长。用例是否包含等待超时消息时长的设计。包括超时时长是否合理、超时时长是业务设置还是平台设置、是否有依赖关系、客户端超时时长是否大于服务端配置超时时长、服务端处理业务耗时时长考虑。

8、发送第三方请求消息检查，检查请求消息中所有参数类型、参数值是否符合接口设计规范。

如何提高项目的测试效率

想要提高版本测试效率，首先需要清楚影响测试效率的主要因素都有哪些，有什么方法可以解决这些问题。根据这些年项目测试经验总结，有几个影响版本测试效率的关键因素，包括：转测试版本质量差、重复测试工作量、需求实现方案复杂、问题单回归不通过、缺少测试经验文档积累、人员技能弱。下面分别阐述为什么这些问题会造成测试效率低和如何解决这些问题的一些建议。

测试前移，提高转测试版本质量

转测试版本质量差转测试后，测试人员疲于处理低级问题、无法第一时间聚焦核心功能测试。同时，质量差的版本会增加测试迭代轮次，测试人员会浪费大量的测试时间，包括测试环境重复的版本升级、回滚、备份操作。

解决建议：1、利用流程，严守版本转测试入口，确保版本质量达到转测试标准。2、测试前移，做好测试需求分析、评审开发自测试用例、确认开发相应阶段输出件结果达标。

降低重复测试工作量

导致重复测试工作量的通常有原需求变更、新需求合入影响前期测试、实现方案（业务逻辑）变更、版本测试依赖因素前期不具备、版本转测试范围未100%转测。导致测试用例重复执行。

解决建议：1、测试前移，做好需求评审，确保需求可行性或者可测试性。有疑问或者模糊需求及时澄清基线。2、需求合入需走变更流程，不能随意合入。不合理的需求或者严重影响已实现需求的进度、测试的引导客户下一个迭代合入（告知变更的风险、成本、进度）。3、规格设计和产品需求评审，确保方案满足可测试性和产品可维护性等要求。4、守好入口条件，确保转测试范围100%转测。

控制问题单回归不通过，明确奖惩机制

问题单回归不通过会导致重复用例测试，也可能会增加版本测试轮次。严重浪费成本。

解决建议：1、利用绩效考核牵引，提高开发重视问题单自验证，引导问题单一次回归通过率。

增加测试经验文档积累

1、复杂产品特性测试缺失。测试人员完成这类特性测试后也容易遗忘。如果没有文档继承，下次测试又需要重头熟悉，浪费时间。

2、环境操作类文档不全或者缺失。比如oracle数据库安装指导、Linux系统安装指导、linux磁盘分区、环境克隆文档等等，导致安装效率低。

3、典型测试工具使用文档缺失。某些模拟庄或者测试工具使用较为奇特，需要特殊配置或者比较繁琐配置才能使用。

解决建议：1、利用流程或者考核牵引测试人员对经验文档沉淀的重视，某些时候测试经理可以指明需要上述相关文档的编写。2、建议使用PDCA法则维护这类文档，不断使用、修改、使用，最后实现任何测试人员按照指导均可一次完成。

降低需求实现方案复杂度，提高可测试性

需求实现方案复杂，需求可测试性差，会增加很多的测试用例。

解决建议：1、评审需求可测试性。2、利用代码检查工具降低代码圈复杂度等，可以减少测试用例设计。

降低耗时重复的手工操作，提高自动化

测试环境维护或者测试用例执行中会存在大量的、重复繁琐的手工操作，这些手工操作占用测试执行的大部分时间。比如环境克隆、手工执行基础用例等。

解决建议：1、动手完成相应测试工具替代重复手工操作，比如一键打包环境工具。工具也可以最大程度降低人为造成的错误并固话已有经验

提升测试人员技能

由于不同的测试人员的基本能力、测试思维、测试方法、测试工具、业务理解的掌握程度不同。人员技能强的测试人员效率远高于测试技能低的人。

解决建议：1、培训，缺啥补啥。但是效果不一定好，这有关于测试人员的主动性。2、招高手。成本就高了，也不一定好找。

如何评估软件产品的质量

如何评估软件产品质量是每个产品测试经理以及每个测试人员都要面对的问题，但是这个问题又没有一个标准的、统一的、可量化的方法。本文根据个人的测试经验说说自己的看法，欢迎探讨。

我主要碰到的几个的问题

1、测试过程中，产品相关责任人询问测试能否结束？版本质量如何？能否按计划发布？

2、测试结束，是否允许版本发布？

这里核心的问题软件产品质量如何，我们是怎么评估我们的产品质量的。如果你有自己的评估方法和体系，我想就可以相对比较清晰的回答出产品的质量状况。比如产品测试过程中用了哪些测试方法、发现了什么缺陷，可能存在的风险。如果还有时间，会再做哪些测试去保证测试质量。如果不允许发布，理由是什么。有一套自己的质量评估体系，就不会出现含糊其辞的对于质量的答复或者模棱两可的就发布了版本。

当前现状

1、版本测试结束，输出测试报告，版本发布。当然，这个过程中会做一些客观的度量数据分析。主要包括需求范围是否100%交付、缺陷加权值是否正常、用例数是否正常等。也包括考虑对异常分布的缺陷值是否做进一步分析或者做了特殊说明、用例数太少是否做了特殊说明等。如果评估没有什么问题，版本就审批通过发布了。这里会有几个明显的问题。我们来分析下：

（1）缺陷值在合理范围内，版本质量就满足发布要求了吗？缺陷严重程度虽然有标准但是不同的测试人员执行起来结果还是会有偏差。

（2）用例数在合理范围内，版本质量就满足发布要求了吗？用例是否有冗余，是否考虑产品特有的典型用例？不同的测试人员用例有效性会有很大的区别。

（3）如果这时评审发现产品某些特性需要补充测试，是否还有时间？已经到版本发布时间了。

2、测试过程中对于答复质量如何或者能不能结束、什么时候能够结束。我比较常见的答复是还有多少用例没有执行、大概需要多少天。也就是以手上的剩余工作去判断测试结束时间。或者答复质量还行，这个版本测试用例是评审过的。

这2种情况是我经常见到的，版本计划安排的测试时间结束版本就发布，至于一些对测试报告中的质疑下面的人总是能找到一个合理的描述去解释，自己有时候确实也没精力去深入分析就把版本发布了。除了几个重要的版本。很少能看到或者听到一个人可以很清晰的去阐述产品的质量如何或者他自己手上的工作如何。

上述发生的问题也描述了，看着好像问题抛的也很合理，是不是就没有办法解决了，个人认为也不是。我理解主要是保证好测试前端工作和把控好测试过程。基于风险的测试策略，主动分析解决，版本发布或者不能发布就不会再最后时间才有定论。

如何评估软件质量

如何评估软件质量，确保软件质量符合发布要求，我理解主要有如下几个关键内容。

1、需求复杂度+代码量

这里的需求复杂度主要是指需求实现的难易程度，需要综合考虑开发对需求实现难易的程度、测试对需求可测试性评估程度、是否有成熟的方案、代码是否复用等。通常来说需求实现越复杂，代码量大的版本风险较高。

2、人力成熟度

人力成熟度，需要综合考虑PM、开发、测试人力的成熟度。人力越成熟，开发、测试的风险就会降低。如果是新手开发的模块，就需要特别重视了。当然，在开发、测试分工时，开发经理和测试经理通常是回根据需求复杂度和人力成熟度进行相应的分工。降低版本质量风险。

3、版本开发测试流程

版本开发测试流程，包括开发团队和测试团队工作的测试流程，从需求进入研发团队到版本发布上线。包括各个阶段的出、入口准则和工作内容、版本发布的准则等。这里重点描述几个环节的出、入口条件和注意事项。

（1）需求准入和传递。需求已签字和所有参与该版本的测试、开发及其他相关人员斗殴参与了需求传递。可以开展开发需求反串讲和测试需求反串讲活动保证开发、测试人员斗殴熟悉理解需求内容。

（2）代码检视。首先确保检视人员，通常是项目组的核心骨干，熟悉业务特性和代码框架。安排检视活动时间，有些项目组会忽略这个活动。同时，输出检视结果，会起到一定的督促效果，也便于回顾。

（3）代码工具扫描。确保项目组规定的代码扫描工具完成，并提供扫描报告，要求扫描结果通过。可以减少代码低级bug、降低圈复杂度，保证代码质量。同时也可以降低后续测试人员用例设计代码覆盖的难度。

（4）测试分层出入口条件。严守各个环节的出入口条件。测试分层包括UT/IT/MST/BBIT/SDV/SIT/SVT等，通常不会分的这么细，根据自己项目情况进行变更。确保各个环节的工作内容、测试对象都已达到出口准则。分析各个环节的执行情况和交付件，调整下一环节的测试策略，确保已知风险尽早解决。

（5）测试用例评审。确保核心人员参与，特别是SE、开发Leader、测试Leader以及核心人员、版本维护人员等。评审形式采用尽量采用会议形式。对于电话会议或者邮件评审，酱油居多，不建议采用，其他特殊情况特殊考虑。评审闭环，确保意见全部修复。

（6）测试策略和测试计划评审。核心人员必须参与评审，包括pm、开发Leader、测试Leader及相关人员等。确保测试任务分工、测试时间合理。不出现明显的时间压缩，因为版本计划通常都是根据发布计划倒排的，所以测试Leader必须有主见，对于测试时间有风险必须及时提出。

（7）测试报告评审。测试报告评审通常都有规定的人员参与。希望到这一步骤时在任何人提出质疑时都可以准确答复质疑。对于版本的质量能有一个相对清晰的描述。虽然很多描述还是依靠主观的。

4、需求变更

需求变更在软件开发测试过程都是难以避免，在需求变更管控流程规范下积极面对。做好需求变更管理，分析引入变更对现有交付范围、影响，刷新测试策略和计划。确保风险可控。不能盲目的、一味的接受，避免到最后风险不可控。

总结

软件质量的评估我理解是重在过程。在版本开发测试流程指导下基于风险的测试策略层层递进，降低或者消灭各个环节暴露的风险。确保版本发布上线质量。

不可忽略的功能测试检查点

测试检查点是测试用例执行的最后一个步骤，不同的测试用例会呈现出不同或者相近的测试检查点。由于测试人员的主观臆断会忽略某些检查点的检查或者未意识到某些隐形的检查点检查（如业务日志）从而导致缺陷遗漏到现网。因此，细致、耐心的对检查点逐一检查以及根据检查点补充用例降低测试低级错误的发生，提高产品的质量。

什么是检查点

所谓的检查点，就是系统根据用户的输入，按照业务要求的逻辑处理后产生的输出，不同的业务场景、不同的结果（成功或者失败）会有不一样的要求。部分输出是客户在需求中明确要求展示的，比如展示的字段可以直接观察到或者获取到，部分输出是服务于系统维护人员、客服人员等。当然，部分输出也包括不能输出或者加密输出，比如客户的银行账号要求部分数字用*号替代，客户的密码不能再日志中输出等。检查点的检查包括客户或者系统质量要求的必须输出的或者不应该输出两种情况。

检查点分类

测试检查点主要包括界面展示、文件、数据库、短消息、业务日志等。

界面展示

界面展示主要包括表记录的直接查询、控件的排序和默认值、控件是否展示、控件的标志（必须带*号）、冒泡提示、控件是否冗余或者缺少展示、界面风格等。

1、检查展示字段是否按照客户要求展示，包括字段名称、个数、顺序、取值来源、展示风格。

2、展示内容是否符合要求，比如菜单界面只展示成功记录或者只展示失败记录或者全部展示。

3、根据查询条件展示的内容是不是与在后台查询数据库的完全一致。

4、检查展示表记录的排序是否按照需求要求、是否需要去重。如果需求没有明确要求，也需要检查展示顺序是否合理。

5、检查新增记录，表可查询，删除记录，无法查询、修改就，查询修改符合修改。

6、检查控件默认值、控件放置位置和顺序、控件属性是否合理、下拉框展示值和排序，特别是时间控件和下拉框。

7、文本框是否有冒泡提示，提示描述是否正确。

8、界面风格是否与其他菜单一致，是否符合UI规范。

文件

文件的检查，主要包括文件是否存在、文件名检查、文件内容检查等。

1、检查文件是否按照逻辑处理成功生成、删除。包括检查是否有重复生成文件或者覆盖文件。

2、检查文件名是否正确，包括格式（abc_20170921.txt）、大小写、后缀。

3、检查文件内容，是否按固定格式生成、有无重复记录、指定字段的值是否记录正确等。

数据库

数据库的检查主要包括表的操作（新增、删除或者修改表字段）、表记录的操作（删除、新增、修改）、索引的操作等。

1、检查是否删除表、新增表，新增表检查需要包括字段个数、字段类型和长度。

2、检查表字段修改，特别是新增字段并且赋默认值。查看大表执行效率。

3、检查关键字段是否特殊处理。比如密码需要加密后保存。

4、检查表记录是否正确删除、新增、修改。考虑所有表是否都正确操作，比如日志表、关联表等。可以配合界面查询检查，确保一致性。

5、检查索引正确修改、创建，检查索引类型是否正确。

短消息

短消息检查主要包括短消息是否要发送、发送内容和格式等

1、检查短消息是否正确发送到用户手中。是否由本系统发送。比如充值成功发送给用户的消息可能是由第三方系统发送而不是本系统发送。

2、检查短消息内容是否正确，特别是关键字段展示。如金额、是否包括税收通知。

3、检查短消息是否被拆分，拆分消息发送是否完整。因为短消息过长（超过140个字符）会被拆分发送。

4、检查短消息是否发送反了。比如发送充值代理商给终端用户成功。但是扣款成功消息却发给终端用户。充值成功消息发给了代理商。

业务日志

业务日志检查非常重要，包括一些敏感信息的处理或者后续用于问题分析定位的关键信息打印。

1、检查业务日志不打印敏感信息，包括用户的号码、密码、余额等。

2、检查业务日志打印关键定位信息，特别是异常场景的ERROR日志，确保ERROR信息清晰、容易理解，可以用于快速定位问题。