功能测试

为公司项目整理的一份系统缺陷定义说明，根据网上公开资料整理，供大家参考，希望对大家有帮助 一、系统缺陷分类 测试中发现的系统缺陷等级分为以下5类： 缺陷等级 缺陷说明 缺陷主要特征 P5 重大 系统不能正常运行 P4 严重 主要功能不能正常运行 P3 一般 主要功能正常、次要功能异常 P2 较小 功能正常，但对系统品质有影响 P1 建议 测试过程中的合理化改进建议 P5类缺陷 该类缺陷主要特征：系统不能正常运行，系统重要功能无法运行，系统奔溃或挂起等导致系统不能正常运行。修改优先级为最高，该类问题需要立即修改。测试特征： 概述 测试主要特征 系统奔溃 资源不足（内存泄漏、CPU占用100%） 重启、死机或非法退出 硬件故障 执行某些操作后导致自动奔溃或死机 功能流程或系统不可用 程序出现死循环 操作某项功能，导致整个模块或系统不可用 业务流程错误或不可用 流程未达到设计要求，功能未完成 关键性能严重不达标 通信错误 上下位机通信帧错误或异常 网络接口故障或错误 P4类缺陷 该类缺陷主要特征：严重影响系统要求或基本功能实现，且无法自修复（重新安装、重启不属于自修复办法）。系统运行不稳定、数据破坏、数据计算错误。常规操作中经常发现或非常规操作中不可避免的出现的问题导致部分功能无法执行。系统无法满足主要业务要求、性能、功能或可用性严重降低。修改优先级为高，需要尽快修改。测试特征： 概述

链接 在学习通上注明结对的成员对: 1班胡晓松-1班高健 结对成员的博客连接: https://www.cnblogs.com/maxilong/p/11729323.html 代码复审 代码复审核查表（高健） 由一班胡晓松完成 1.概要部分 1）代码符合需求和规格说明吗符合？ 是 2）代码设计是否考虑周全？ 周全 功能和要求相符 3）代码可读性如何？ 一般 4）代码容易维护么？ 容易 5）代码每一行都检查过了吗？ 是 2.设计规范部分 1）设计是否遵循从已知的设计模式或项目中常用的模式？ 是 2）有没有硬编码或字符串/数字等存在？ 是 3）代码有没有依赖于某平台，是否会影响将来的移植？ 否 4）4.开发者新写的代码能否用已有Library/SDK/Framework中的功能实现？在本项目中是否存在类似的功能可以调用而不用全部重新实现？ 是 5）5.有没有无用的代码可以清除？ 否 3.代码规范部分 1）修改的部分符合代码标准和风格嘛？ 是 4.具体代码部分 1）有没有对错误进行处理？对于调用外部函数，是否检查了返回值或处理了异常？ 否 2）参数传递有无错误，字符串的长度是字节的长度还是字符（可能是单/双字节）的长度，是以0开始计数还是以1开始计数？ 0 3）边界条件如何处理的？switch语句的default分支是如何处理的？循环有没有可能出现死循环？ 否 在分支中填入跳转语句 4

探索性测试扫盲 　　关于2477203708探索性测试，之前在群里总是听到有人提起，也搜了相关书籍，但是一直没有仔细去瞧。今日刚好妍姐发了一篇跟探索性测试有关的博客，看完之后被扫盲，另外也引发了我的一些思考。 　　探索性测试，文章里面写了很多概念和方法，其实都是在表达，可以有这么些办法，让测试人员想到更多测试场景，而且根据不同的维度，能想得更全面一些，类似于我们的移动端专项测试中某些特有的场景，只是这个更加通用了。 　　文章里面说到的一句话特别有意思： 测试人员的绩效不是通过他们找到了多少Bug来评估的，而是他们究竟提高了多少开发人员的工作效率和工作质量，从而反应在产品的质量上。 　　因为很多公司的绩效考评都参考了这么一点，形成开发和测试之间一种竞争和紧张的关系，某种程度上一方面不利于公司团结，另一方面可能会对产品质量带来负面的影响。考评测试人员绩效，这句话提出了一种新的视角。 　　 测试人员当然需要读写代码，而且最好的选择是直接从产品的错误处理代码入手，这样能一眼发现何种输入数据、输入顺序能把产品逼到极限。 　　这句话也为我学习代码提供了方向和参考的入口。 　　在此感谢原作者的总结和妍姐的分享。 　　 探索性 测试 在开始实践 敏捷 的时候，就一直谈论着探索性测试。尝试了许多方式，多角度覆盖、路径漫游、逆向思维等等，虽然取得了一定的效果

隐示等待和显示等待 我们看看在功能测试中function_tests.py中的 time.sleep inputbox.send_keys(Keys.ENTER) time.sleep(1) self.check_for_row_in_list_table('1: Buy peacock feathers') 这就是所谓的“显性等待”。这与“隐式等待”形成对比：在某些情况下，selenium会在认为页面正在加载时尝试“自动”等待您。 它甚至提供了一个名为隐式等待的方法，让您可以控制如果您向它请求一个似乎还不在页面上的元素，它将等待多长时间。 问题是，隐式等待总是有点不稳定，随着selenium 3的发行，隐式等待变得更加不可靠。 同时，selenium团队的普遍观点是，隐性等待只是一个坏主意，应该避免。 所以这个版本从一开始就有明确的显示等待。但问题是那些时间谁说就是正确的时间呢？对于大多数测试，我们都是针对自己的机器来定，一秒钟太长了，0.1秒就可以了。 但如果你把它定得这么低，会因为笔记本电脑有点卡那就慢一点。 因此，让我们用一个工具来代替，这个工具将等待所需的时间，直到捕捉到任何故障的很长的超时时间。 我们将把check_for_row_in_list_table重命名为wait_for_row_in_list_table，并为其添加一些轮询/重试逻辑： from

为什么要做单元测试 通常我们在做任何工作会先考虑它的回报，编写代码更是如此。如果单元测试的作用不大，没有人会愿意再写一堆无用的代码，那么单元测试到底能够给我们带来什么优点呢？如下： 便于后期重构。单元测试可以为代码的重构提供保障，只要重构代码之后单元测试全部运行通过，那么在很大程度上表示这次重构没有引入新的BUG，当然这是建立在完整、有效的单元测试覆盖率的基础上。 优化设计。编写单元测试将使用户从调用者的角度观察、思考，特别是使用TDD驱动开发的开发方式，会让使用者把程序设计成易于调用和可测试，并且解除软件中的耦合。 文档记录。单元测试就是一种无价的文档，它是展示函数或类如何使用的最佳文档，这份文档是可编译、可运行的、并且它保持最新，永远与代码同步。 具有回归性。自动化的单元测试避免了代码出现回归，编写完成之后，可以随时随地地快速运行测试，而不是将代码部署到设备之后，然后再手动地覆盖各种执行路径，这样的行为效率低下，浪费时间。 等等，讲了这么多优点，无非就是良好的接口设计、正确性、可回归、可测试、完善的调用文档、高内聚、低耦合，这些优点已经足以让我们对单元测试重视起来了，但是个人觉得还有更重要的原因。 首先，带来自信。在接手一个新的项目，或者说是参与一个新的项目开发时，往往这种情况是你半途参加进去的，你需要对已有的代码结构进行解读和理解，对于业务的理解

1.在同一项目组或产品组内，要有一套统一的为集成测试与系统联调准备的调测开关及相 应打印函数，并且要有详细的说明。 说明：本规则是针对项目组或产品组的。 2.在同一组或产品组内，调测打印处的信息串的格式要有统一的形式。信息串中至少要有所在模块名（或源文件名）及行号。 说明：统一的调测信息格式便于集成测试。 3.编程的同时要为单元测试选择恰当的测试点，并仔细构造测试代码、测试用例，同时给出明确的注释。测试代码部分应作为（模块中的）一个子模块，以方便测试代码在模块中的安装与卸载（通过测试开关）。 说明：为单元测试而准备。 4. 在进行集成测试/系统联调之前，要构造好测试环境、测试项目及测试用例，同时仔细 分析并优化测试用例，以提高测试效率。 说明：好的测试用例应尽可能模拟出程序所遇到的边界值、各种复杂环境及一些极端情况等。 5.使用断言类发现软件问题，提高代码可测性。 说明：断言是对某种假设条件进行检查（可理解为若条件成立则无动作，否则应报告），它可以快速发现并定位软件问题，同时对系统错误进行自动报警。断言可以对在系统中隐藏很深，用其它手段极难发现的问题进行定位，从而缩短软件问题定位时间，提高系统的可测性。实际应用时，可根据具体情况灵活地设计断言。 示例：下面是 C 语言中的一个断言，用宏来设计的。（其中 NULL 为 0L） #ifdef _EXAM_ASSERT_TEST_ //

Dev(Developer) : 开发 TE(Test Engineer) ：测试 PM(Product Manager) ：产品 敏捷：快速的响应客户（需求），高效的完成开发，不断的追求完善。 TE 在敏捷中应该做些什么呢？ 流程 1- 故事分析 角色： Dev 、 TE 内容： 需求交接前夕， PM 将需求上传到文档管理区并邮件通知， Dev 、 TE 分析需求 初步制定测试策略与测试计划 初步安排测试任务 输出： 测试策略、测试计划 测试工作量初步评估 流程 2- 故事计划 角色： 整个 Team(PM 、 Dev 、 TE) 内容： 需求交接（宣讲），了解更多细节 确定测试工作量 更新测试策略各测试计划 考虑环境和并着手准备 输出： 测试策略、测试计划 测试工作量评估 流程 3-Story Kickoff 角色： Dev 、 TE 内容： TE 与 Dev 一起理解分析故事 列表疑虑点 Dev 拆分 task ，并思考设计思路 TE 列出测试要点 TE 各 Dev 一起就以上各点对 PM 和 Dev 进行反串讲（用例与设计评审） 输出： 测试用例 流程 4 - 故事开发 角色： TE 、 Dev 内容： TE 与 Dev 结对、实现自动化测试 输出： 自动化测试 PS: 关于这点，没有自然语言自动化体系支撑，无法达到实行标准 流程 5-Desk Check 角色： TE 、

1.性能评估模型概述 我们的系统性能到底能不能够支撑线上真实大量的订单交易？ 我想，这是我们每一个互联网交易或者负责大并发项目的同学都很关心的问题，也是性能评估模型篇需要解答的最终问题。所以我们就带着这个问题来一步步深入性能测试。本问题的难度不在于一个简单的结果，而在于答案背后的一系列性能测试的评估数据和算法，以及如何建立一个良好可持续的“性能评估模型”。 通常来讲，性能测试是指通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。 而要回答“能否支撑线上真实 大量的订单交易 ”这样带有预测性的问题，实际上还需要用上另一种手段，即“ 性能预测 ”，而“在线性能评估模型”就是用来做性能预测的。 在预测之前，我们先来做一个数据分析，通过这个分析我们可以大概了解线上与线下的推算过程。 2013年11月11日，支付宝实现了当天交易总金额 350 亿元 ，订单总数 1.8 亿笔 （其中手机支付占24%），活跃用户 1.2 亿 。（来源：支付宝官方微博 http://weibo.com/1627897870/AiiAjEwHO ） 显然这是一个非常震惊的数字，它见证着电商的今天也预示着电商的未来。针对这个数字，下面我们就一起来剖析数字背后的性能情况。 双11当天，支付宝的订单数是1.8亿笔，意味着每小时订单数达到1.8亿 / 24 = 750万笔

结对编程 Github项目地址 https://github.com/Tracerlyh/WordCount.git 结对伙伴作业地址 添加链接描述 一、psp表格 二、结对编程的过程 在编程之前，我们先一起讨论了该程序结构的设想，然后一起编写了本次项目的PSP表格，然后再商量了如何对各个模块的开发进行分工。 分工情况如下 我： 1、统计最多的10个单词及其词频 2、统计指定长度的单词的数量 3、两人代码的合成 结对伙伴： 1、统计字符数模块 2、统计单词数模块 代码规范 1、在使用文件之后要关闭文件。 2、主要的功能函数的参数中要有一个参数为文件类型。 3、在函数中打开和关闭文件。 4、在声明函数时在函数声明后面添加注释说明函数的功能。 5、在主函数中调用写的功能函数时添加注释说明函数得功能。 6、主函数中只进行与用户交互的提示信息的输出到屏幕。 7、各个功能的运行结果的输出都在相应的函数中输出到屏幕。 工作照片： 在结对编程过程之中，发现问题时及时沟通，尽量尽早地发现问题。 三、解题思路 按程序要实现的功能分别进行分析： 1、由用户输入文件的路径及名字。 解决思路：在屏幕输入提示信息，提示用户输入文件路径，将用户输入的文件的路径及名称存放在一个字符串中，在打开文件流时使用该字符串打开。 2、统计文件中字符的数量并在屏幕上输出。 解决思路：利用C++文件操作的fget(

最近做研发质量分析，大家共同提到了一个改进措施： 加强开发自测！ 但是如何加强开发自测、怎么做好开发自测？带着这个问题，进入我们今天的分享： 一、开发测试小记 开发同学功能开发完成后，简单自测通过后，填写提交单提交测试，然后： 制作的补丁，打到测试环境，发现丢了一些SQL、Dll、配置，然后提交单被测试无情地打回。 即便补丁更新成功，扛不住测试用例的第一轮饱和测试，出现影响测试进展的Bug，或者Bug太多，满足打回标准，提交单继续被无情打回。 提交单打回后，开发同学集中修复了Bug，再次提交测试。正常情况下，第二轮功能测试发现的Bug会大幅减少，如果重新提交的补丁质量不佳，修复Bug的同时，带来了更多新的Bug，提交单还是有可能继续被打回。 功能测试通过后，进行性能测试，并发压力上来后，功能被打爆、数据库被打爆、MQ被打爆，提交单再次被打回。 …… 上面的场景，大家都很熟悉，很多开发、测试同学通过都经历过。我们如何用真正的行动来加强开发自测，提升交付质量？ 我们需要有一套开发自测方法论： 二、开发自测方法论 我们详细展开讲一下： 1. 思想意识上，提升对自测的重视程度 开发阶段不仅是代码开发完成，编译通过，更重要的是自测通过。 自测工作投入应该占开发阶段整体投入的30%，如果保证不了资源投入，自测只是一个形式； 自测工作必须覆盖全面的自测场景：正向、逆向、正常、异常、并发性能等等；