用例测试质量相关问题解答
1、如何保证客户产品的保密性和安全性？
我们平台的每个参与测试的测试者，都与平台签署了保密协议，并提供了其真实身份信息，包括身份证号、手机号等。高保密的项目，我们还会和参与测试的每个测试者签订纸质的保密协议。
2、你们怎么来确保能够很好的理解我们的产品
首先，我们挑选的测试专家都是具备相关行业经验的自身测试专家，理解您的产品会非常快。如银行类的测试，我们会安排由专门测试银行产品的专家进行对接。
其次，测试专家会在测试前和客户就产品进行深度地沟通，并提出针对产品的功能点分析、测试计划、测试方案，直到客户认可我们的测试计划和方案后，才开始进行用例的编写或探索测试。
再次，在测试过程中，专家会将编写的部分用例随时和客户进行沟通确认，保证对产品的理解与客户期望一致。
3、如何保证测试者的质量？
平台有多层考核机制来保证测试者质量，测试者首先需要经过专业的测试能力考试，才具备参与测试任务的资格，测试者只有在 真实测试任务重表现出突出的测试能力，才能成为平台合格测试者。每次测试任务，测试者的测试结果都会被评分考核，类似滴滴对司机的打分，评分低的测试者会被淘汰，只有评分高，测试能力强的测试者才能在平台中进行测试任务。
4、怎么确保测试结果？
首先，保证测试者的质量，通过严格的测试者筛选，能力考核，保证执行测试的测试者都是合格测试者，从中挑选的测试专家，更是经过视频认证和真实任务中验证过来的。
其次，测试过程中，众测制定了大量的测试规范和流程保证测试结果，测试开始前，测试专家需要提供详尽的测试计划，并进行功能点确认，众测有大量的PM进行过程管理，对交付的测试结果进行实时审查。
再次，每次测试我们都会对测试进行评估和考核，评分低的测试者将直接失去测试资格。
经过5年的积累，众测平台上已经沉淀大量各行各业高评分的专业测试者。
5、用例编写的覆盖度如何？
用例测试编写的基本要求是覆盖度保证功能点的100%覆盖。
6、如何保证用例质量和覆盖度？
首先，我们的测试人员经过层层筛选，我们的测试用例是由负责本次测试的测试专家（测试经验在5年以上，并且有丰富的行业经验），带领3年以上测试经验的测试者，严格按照我们的测试用例规范进行编写。
其次，用例编写前会进行需求的深层次沟通，需要客户首先将需求文档尽可能详尽的提供给我们的测试专家，测试专家会一边学习需求文档，一边使用客户的产品，并与客户进行产品的功能点沟通和需求确认。测试专家会根据自己理解进行功能点分析，并将功能分析文档交由客户确认，客户确认后，才开始进行用例编写。用例测试编写的基本要求是覆盖度保证功能点的100%覆盖，测试专家通过功能分析文档确保所测试的测试点100%覆盖。
专家团队编写完用例后，会将用例给到客户，由客户确定用例的质量和覆盖度，平台根据客户评价决定专家团队的收益。
用例测试效率相关问题解答
1、 一般一个APP需要设计多少条用例？
不同App根据其复杂度不同，用例条数不同，通常一个功能完善的App一个端的用例在1000条左右。
2、用例测试有多少人设计和执行？
一般用例测试项目，我们会用5-8个人进行用例设计和执行，用例工作量的大项目，我们会将团队扩大3倍以上，保证交付效率的稳定性。
3、用例由几个人执行，如何保证效率？
用例执行一般由5-8人执行，我们会将用例分成多个模块，分由多个测试者进行执行。
4、用例设计和执行多长时间交付？
用例设计：在首次沟通需求和确认需求这块需要较长时间，需求确认后，用例设计交付效率为60-80条/人天，测试团队规模5-8人，交付效率为48小时/500条用例，更多用例设计交付可以通过扩大交付团队的方式保持48小时内交付。
用例执行，用例执行交付效率为100条/人天，测试团队规模5-8人，交付效率为24小时／500条用例，更多用例执行交付可以通过扩大交付团队的方式保持24小时内交付。
5、如何保障用例编写前期的沟通效率？
对于具有专业测试经理的客户：用例编写前，需要客户首先将需求文档尽可能详尽的提供给我们的测试专家，测试专家会一边学习需求文档，一边使用客户的产品，并与客户进行产品的功能点沟通和需求确认。测试专家会根据自己理解进行功能点分析，并将功能分析文档交由客户确认，客户确认后，才开始进行用例编写。
对于没有专业测试经理的客户：用例编写前，需要众测专职项目经理了解客户产品需求，定制测试策略后，告知测试专家，双方确认完毕后，才开始用例编写。
6、用例测试的标准流程是怎么样的？
我们的用例测试包括用例编写和用例执行，编写用例我们会按照严格测试用例规范进行编写，这是我们的用例模板。编写完用例，我们会根据客户的需要进行部分或全部的用例按条执行，执行完每一条用例都会标示出执行结果是Pass（成功）还是Fail（失败），对于失败的用例，我们会标明这是一个Bug，会记录测试的过程，复现概率，出错的截图和视频，并提供错误日志。同时，我们也会对测试中出现的所有Bug进行汇总。
测试专家会给参与测试的每个测试者下发其专属测试任务，并在指定时间内收集每个测试者的测试结果，对测试结果进行审核，将所有人的测试结果汇集整理成测试报告。
7、测试对象范围标准是什么？
APP：包含Android和iOS两大平台应用，支持原生，H5和混合开发类型的应用；
Web：支持PC端网站的功能测试；
H5：支持H5页面的功能测试。
8、测试机型选择标准是什么？
不支持机型选择；
支持多机型交叉验证。
9、测试收费标准是什么？
功能测试按用例条数收费，用例设计和用例执行单独收费；
提供功能用例条数评估支持，用于确认工作量和商务费用；
10、用例覆盖度标准是什么？
用例覆盖度 = 100%；
标准概述：遍历覆盖，产品设计和开发的功能都得到100%验证和遍历测试。
11、用例通过率标准是什么？
通过率 ≥ 96%；
标准概述：开发的功能达到预定功能和使用目的，功能实现与产品需求说明及用户文档描述一致。
12、缺陷存活率标准是什么？
优先级为P1、P2的测试用例发现的缺陷，存活率 = 0%；
优先级为P3的测试用例发现的缺陷，存活率 ≤ 1%；
优先级为P4的测试用例发现的缺陷，存活率 ≤ 3%；
13、用例颗粒度标准是什么？
一级标准颗粒度：
定义：仅包含发生概率较高和使用率较高的功能用例；
说明：大部分公司处在此等级阶段，仅验证核心功能是否能够跑通的check list作为用例，极易漏测。
二级标准颗粒度：
定义：覆盖所有基本功能，对功能点进一步拆分、细化和补充，检查点更完善。
三级标准颗粒度：
定义：在二级标准的基础上增加网络场景，异常情况，功能交互，手机和H5特性等多种场景下的用例覆盖；
说明：Tetsin的绝大部分客户都把颗粒度控制在2级和3级，以达成更优的投入产出比。企业一般会考虑每个项目的特殊性，包括APP功能的复杂程度，项目整体周期以及开发者购买力度等做合适的选择。
四级标准颗粒度：
定义：在三级标准的基础上适当增加弱网、安全验证等非功能点的测试用例；
说明：投入较高，需要依赖特定专项测试完成。
14、用例覆盖度标准是什么？
标准要求：直观和可量化，可读的用例覆盖标准；
①功能脑图清晰，完整：
概述说明：完整对应功能模块，子模块和细分结构，有不同色区区分每个版本的模块/业务优先级，能根据脑图初步判断和评估用例条数；
②遍历场景：
概述说明：首次测试，上线前测试，大迭代大改动测试，时间充裕下至少全用例执行一次，遍历所有功能模块和业务逻辑；
③优先级明确：
概述说明：如上文，3级别用例优先级划分正确，比例合适；
④用例覆盖度可量化：
概述说明：开发的功能达到预定功能和使用目的，功能实现与产品需求说明及用户文档描述一致等都可以使用用例量化。
15、用例特征标准是什么？
用例特征符合ISO/IEC 25051-2014国际标准特征：
唯一性：
每条用例有相应且唯一的用例ID，其用例前提，用例标题，用例步骤其中有且至少有一个具备唯一性特征；
同样用例前提，用例环境，用例步骤下的用例测试结果通过必须预备唯一性；
一致性：
用例与用例之间，用例与产品设计文档之间必须具备一致性，无矛盾，无相悖的用例存在；
可移植性：
用例足够清晰，前提，环境，用例的测试步骤等都具备移植和复用性；
可维护性：
用例和用例库具备简单易操作的维护可能，用例本身存在直接区分优先级，直接升级修改，存档，建库的可操作性；
可执行性：
用例前提，用例步骤清晰，用例的预期结果有明确的验证方法和明确的通过/失败标准。
16、用例执行结果标准是什么？
用例完成的实际结果以与预期结果的比对校验而得，结果有且仅有以下六种：
Pass，（实际结果与预期结果一致）；
Fail，（实际结果与预期结果不一致，且初步判断是由Bug导致）；
Block，（测试步骤在本次因为其他Bug存在而导致无法执行，或因为临时测试环境局限导致本次无法执行）；
N/A，（Not Available，测试用例不适用于本次测试环境，场景或业务）；
No Run，（测试用例暂时还未被执行）；
No Need，（测试用例在本轮测试中被评定为无需执行）；
I/Q，（即In Queue，用于自动化测试，列队中待执行用例）；
I/P，（即In progress，用于自动化测试，正在执行中用例）。
17、用例报告标准是什么？
用例测试报告基本十大要素齐全：
用例ID（由数字和字母组成的字符串，以简单易识别，具备唯一性为根本）；
用例模块（用以表明测试用例所属的功能模块）；
用例子模块（用以表明测试用例所属的子功能模块）；
用例优先级（详见上文）；
用例标题（简单明确的描述测试部位和测试点（即：Test point））；
用例前提（执行当前测试用例需要达到的必要前提条件。此前提条件决定测试预期结果的准确性和可操作性）；
用例步骤（完成测试点验证需要的测试路径，要求简洁明了，无不确定和跳跃）；
用例预期结果（测试执行完成后所要达到的正确输出（返回值，页面响应结果，UI输出等），能用于较为明确的实际结果比对）；
用例执行结果（详见上文）；
相关bug和备注（执行用例的过程中发现的相关Bug, 以及必要备注，相关Bug可以是New，Open，Detect，Reopen，pending等有效状态。不能引用Rejected，Closed，Duplicated等无效Bug）。