功能测试

测试用例的编写需要按照一定的思路进行，而不是想到哪写到哪，一般测试机制成熟的公司都会有公司自己自定义的测试用例模板，以及一整套的测试流程关注点，当然我们自己在测试生涯中也应当积累一套自己的测试框架，所有功能性的测试都可以依据框架的思路来进行，达到事半功倍的效果。 功能测试框架可以包括：界面友好性测试、功能测试、链接测试、容错测试、稳定性测试、常规性能测试、配置测试、算法测试等等。 1.1.1 界面友好性测试 1. 风格、样式、颜色是否协调 2. 界面布局是否整齐、协调（保证全部显示出来的，尽量不要使用滚动条 3. 界面操作、标题描述是否恰当（描述有歧义、注意是否有错别字） 4. 操作是否符合人们的常规习惯（有没有把相似的功能的控件放在一起，方便操作） 5. 提示界面是否符合规范（不应该显示英文的cancel、ok，应该显示中文的确定等） 6. 界面中各个控件是否对齐 7. 日期控件是否可编辑 8. 日期控件的长度是否合理，以修改时可以把时间全部显示出来为准 9. 查询结果列表列宽是否合理、标签描述是否合理 10. 查询结果列表太宽没有横向滚动提示 11. 对于信息比较长的文本，文本框有没有提供自动竖直滚动条 12. 数据录入控件是否方便 13. 有没有支持Tab键，键的顺序要有条理，不乱跳 14. 有没有提供相关的热键 15. 控件的提示语描述是否正确 16. 模块调用是否统一

对于一个 测试 人员来说测试用例的设计编写是一项必须掌握的能力。但有效的设计和熟练的编写却是一个十分复杂的技术，它需要你对整个软件不管从业务还是从功能上都有一个明晰的把握。 一、问题： 许多测试类书籍中都有大幅的篇章介绍用例的设计方法，如等价类划分，边界值，错误推断，因果图等。但 实际应用 中这些理论却不能给我们很明确的行为指导，尤其是业务复杂，关联模块紧密，输入标准和输出结果间路径众多时，完全的遵循这些方法只能让我们在心理上得到一种满足，而无法有效的提高测试效率。有时我们只有依靠以前项目的用例编写经验（或习惯），希望能在这一个项目中更加规范，但多数情况下我们规范的只是“书写的规范”，在用例设计上以前存在的问题现在依旧。 当好不容易用例基本完成，我们却发现面对随之而来的众多地区特性和新增需求，测试用例突然处于一种十分尴尬的境地： 从此几乎很少被执行 已经与程序的实现发生了冲突（界面变动，功能变动） 执行用例发现的bug很少 根本没有时间为新的功能需求增补用例 有时间补充，但用例结构越来越乱， 特性的用例与通性用例之间联系不明确（以新增需求为主线列出所有涉及到的更改，但特性与通行之间的数据或业务联系在用例中逐渐淡化） 知道怎样执行这个用例，但它要说明什么呢？（多数用例给我们的 感觉 是只见树木，不见森林，只对某一功能，无法串起） 通过上面的一系列问题可以看到

StringGrid1.Cells[cCol,cRow] := '测试1'+#13#10+'测试2'; procedure TForm1.StringGrid1DrawCell(Sender: TObject; ACol, ARow: Integer; Rect: TRect; State: TGridDrawState); var Area:TRect; begin StringGrid1.Canvas.Font.Assign (StringGrid1.Font); with StringGrid1,StringGrid1.Canvas do begin FillRect(Rect); Area:= Rect; InflateRect(Area, -2, -2); DrawText(Handle, PChar(Cells[ACol, ARow]),Length(Cells[ACol, ARow]), Area, DT_CENTER)//居中 end; end; 来源： https://www.cnblogs.com/zyb2016/p/11639525.html

接口测试 [腾讯 TMQ] 接口测试用例设计 腾讯移动品质中心 · 2018年01月17日 · 最后由 于静 回复于 20 天前 · 21794 次阅读 本帖已被设为精华帖！ 目录 作者：刘燕 团队：腾讯移动品质中心（TMQ） 导语 随着测试分析和分层测试的深化，“接口测试”出现在我们视野的频次越来越高。那么接口测的用例设计常用哪些方法呢？本文将详细描述。 1 接口测试 1.1 接口测试 接口：主要是子模块或者子系统间交互并相互作用的部分。 这里说的接口是广义的，客户端与后台服务间的协议；插件间通信的接口；模块间的接口；再小到一个类提供的方法；都可以理解为接口。 接口测试：是指针对模块或系统间接口进行的测试。 1.2 接口测试发现的典型问题 接口测试经常遇到的bug和问题，如下： （1）传入参数处理不当，导致程序crash； （2）类型溢出，导致数据读出和写入不一致； （3）因对象权限未进行校验，可以访问其他用户敏感信息； （4）状态处理不当，导致逻辑出现错乱； （5）逻辑校验不完善，可利用漏洞获取非正当利益等。 2 接口测试用例设计 上图为一个典型的接口。一个接口通常是有输入输出的，输入就是我们常见的入参，输出有时有，有时没有。调用相关接口，接口会执行相关处理逻辑。 接口测试的用例设计，主要从输入和接口处理两方面考虑： 1）针对输入，可按照参数类型进行设计； 2）针对接口处理

经历1个多月的时间，软件工程视频和相关文档学习已近尾声，每个人都有不同程度的收获吧，来看看我的感受如何： 通过对软工视频的学习，已了解软工视频大致是在为写文档做预习，一个软件工程必不可少的一部分就是文档的编辑，文档亦难亦不难。不难在我们都能理解每一份文档，并且知道每份文档主要内容有什么，而难亦在怎么将文档的主要内容写出来，用什么表示主要内容，可以让读者更清晰的了解你需要表达什么内容。 通过一次文档的验收，暴露了我们很多问题，即使写的再详细，由于我们缺少经验，总是或多或少的存在某些问题。 比如，对于可行性研究报告主要给要看这份文档的人指出项目开发的实际效益，主要从技术与经济方面，而我的文档中掺杂着一些详细到具体功能的描述，这个是需求或者详细设计文档中的内容，从而使可行性研究报告过于赘余，其他文档也都存在这样的一些问题。 下面我来好好的总结下每份文档中都主要该有什么内容吧。 1.对于可行性研究报告 简单说来就是个老板看的，要让老板看到有利益，才会同意开发这个项目，说白了就是别人投资需要让人看到未来。所以，要对与能创造利益有关的一切因素谈起。这需要从 经济 、 技术 、 生产 、 供销 直到 社会 各种 环境 、 法律 等各种因素进行具体 调查 、 研究 、 分析 ，确定 有利 和 不利 的 因素 、项目是否可行，估计成功率大小、经济效益和社会效果程度

工作两年了，我一直希望让自己每年对测试的理解更深入一层。工作一年的时候我写了《 谈软件测试 --- 一年工作总结 》 ，谈轮了自己对各种测试的理解，这一年来，虽然对那些理概念的有所加强，自我感觉没有什么质的变化。前些天听我们公司的一位测试经理讲《敏捷测试》豁然开朗。他在学造飞机，而我一直在学造飞机里的一个发动机。我从来没想过，一个完整飞机的架构应该是怎样的。 　　如果想让测试在公司的项目中发挥出它最大的价值，并不是招两个测试技术高手，或引入几个测试技术，而是测试技术对项目流程的渗透，以及测试流程的改进与完善。虽然，当然测试行业前景乐观，许多中小企业也都在引入测试，但一百个公司就有一百种测试，每个公司对测试的看法不同，公司对测试的定位也不完全一样。本人前后经历两个公司，以自己的拙见浅谈一下对测试流程的看法。 这几天整理思路，回顾了前两份测试工作的流程与架构。 简陋的测试流程 　　先说笔者入职的第一个家公司，笔者是第一个入职的专职测试人员，相信一两个测试的公司还是不少的，入职后各种项目都在进行当中，上面给我的定位是并没完全融入到项目中去。而通过指派任务的方式。 下面是简陋的流程图： 需求分析与架构设计 ： 　　我们做的是某一移动公司内部使用的项目，需求分析与架构全部由项目经理完成，之后由项目经理给具体某个开发人员分配任务，具体对某个功能模块的实现。这个对项目经理的经验与技术要求很高

摘要：1. 登陆、添加、删除、查询模块是我们经常遇到的，这些模块的测试点该如何考虑 　1. 登陆、添加、删除、查询模块是我们经常遇到的，这些模块的测试点该如何考虑 　　1)登陆 　　① 用户名和密码都符合要求(格式上的要求) 　　② 用户名和密码都不符合要求(格式上的要求) 　　③ 用户名符合要求，密码不符合要求(格式上的要求) 　　④ 密码符合要求，用户名不符合要求(格式上的要求) 　　⑤ 用户名或密码为空 　　⑥ 数据库中不存在的用户名，不存在的密码 　　⑦ 数据库中存在的用户名，错误的密码 　　⑧ 数据库中不存在的用户名，存在的密码 　　⑨ 输入的数据前存在空格 　　⑩ 输入正确的用户名密码以后按[enter]是否能登陆 　　2) 添加 　　① 要添加的数据项均合理，检查数据库中是否添加了相应的数据 　　② 留出一个必填数据为空 　　③ 按照边界值等价类设计测试用例的原则设计其他输入项的测试用例 　　④ 不符合要求的地方要有错误提示 　　⑤ 是否支持table键 　　⑥ 按enter是否能保存 　　⑦ 若提示不能保存，也要察看数据库里是否多了一条数据 　　3) 删除 　　① 删除一个数据库中存在的数据，然后查看数据库中是否删除 　　② 删除一个数据库中并不存在的数据，看书否有错误提示，并且数据库中没有数据被删除 　　③ 输入一个格式错误的数据，看是否有错误提示

　　自动化测试用例的编写是实现项目自动化的核心，合理的用例设计是保证自动化效益和实用性的关键，也直接决定了自动化脚本是否具备可扩展和可维护性。由此，本篇文章主要为大家介绍了测试用例编写的规范和注意事项。 　 　一、自动化测试用例选择 　　自动化测试主要应用于基础功能的验证和回归，对于在项目迭代过程中不断修改的功能来说，手工测试的效率是大大高于自动化测试的。因此，我们在进行自动化之前，要挑选基础功能来进行自动化。在这个过程中，我们可以从手工测试用例中进行挑选，也可以专门为自动化编写一套用例。 　　在自动化初期，建议从手工测试用例中进行挑选。一方面手工测试用例的覆盖度最为全面，可以保证测试的全面性；另一方面，也会提高测试效率。我们挑选用例的原则是：清晰、简单、基础、改动小的功能。 　　 二、自动化测试用例编写 　　挑选完合适的用例之后，就是通过代码编写自动化用例的过程。这个过程主要包括数据预置、用例编写和用例后置三个步骤。 　 　1、数据预置 　　在进行用例编写之前，我们需要准备一些数据，保证用例能够真正的执行起来。比如，我们在测试一个网页登录功能，我们需要系统的URL参数、需要一个可以登录的用户名和密码；我们需要测试删除文件的功能，就需要提前上传一个文件，这个文件可以提前预置，也可以在执行删除操作之前，执行一个上传操作；通过哪种方式预置数据，需要根据项目的实际情况选择

1 、问：你在测试中发现了一个bug ，但是开发经理认为这不是一个bug ，你应该怎样解决？ 首先，将问题提交到缺陷管理库里面进行备案。 然后，要获取判断的依据和标准： 根据需求说明书、产品说明、设计文档等，确认实际结果是否与计划有不一致的地方，提供缺陷是否确认的直接依据； 如果没有文档依据，可以根据类似软件的一般特性来说明是否存在不一致的地方，来确认是否是缺陷； 根据用户的一般使用习惯，来确认是否是缺陷； 与设计人员、开发人员和客户代表等相关人员探讨，确认是否是缺陷； 合理的论述，向测试经理说明自己的判断的理由，注意客观、严谨，不参杂个人情绪。 等待测试经理做出最终决定，如果仍然存在争议，可以通过公司政策所提供的渠道，向上级反映，并有上级做出决定。 2 、问：给你一个网站，你如何测试？ 首先，查找需求说明、网站设计等相关文档，分析测试需求。 制定测试计划，确定测试范围和测试策略，一般包括以下几个部分：功能性测试；界面测试；性能测试；数据库测试；安全性测试；兼容性测试 设计测试用例： 功能性测试 可以包括，但不限于以下几个方面： 链接测试。链接是否正确跳转，是否存在空页面和无效页面，是否有不正确的出错信息返回。 提交功能的测试。 多媒体元素是否可以正确加载和显示。 多语言支持是否能够正确显示选择的语言等。 界面测试 可以包括但不限于一下几个方面： 页面是否风格统一，美观

基础题（65分） 1、什么是需求？需求有哪些来源？（3分） 答：需求的分类：直接需求（用户直接需求告知要求）和间接需求（行业需求要求）；需求的定义：准确的描述用户需求； 来源：行业、用户、团队、运营、客服、自己（调研反馈、数据分析、竞品分析）；数据分析：产品功能使用情况，如行业报告、产品后台数据等挖掘用户需求；调研反馈：通过市场调研或用户调研等方式挖掘用户真实需求；竞品分析：确立竞品分析的目的，然后分析竞品的功能和内容都有什么，通过与竞品的对比得出自身产品的需求； 直白点说：01：来源客户要求；02行业要求；03公司内部分析的需求； 2、为什么说需求需要测试，如何测试？（4分） 答：需求是标准，贯穿整个项目，是项目中最重要的标准，必须经过多方面（技术、角色：用户、产品、测试、开发）测试，才能合理安排项目进度和技术分析设计，确保需求符合用户要求和课实现。 测试方法：01评审，参加人员（用户、产品、测试、开发）；02场景和技术模拟，确保可实现；03行业调研； 3、单元测试的定义？测试意义是什么？（3分） 答：指对软件中的最小可测试单元进行检查和验证。对于单元测试中单元的含义，一般来说，要根据实际情况去判定其具体含义，如C语言中单元指一个函数，Java里单元指一个类，图形化的软件中可以指一个窗口或一个菜单等。总的来说，单元就是人为规定的最小的被测功能模块