目录

一、 测试用例

二、 缺陷报告

三、 测试总结报告

四、 缺陷（Bug）

五、缺陷评估

一、 测试用例

1. 测试用例制定的原则？

答：Test cases include the functionality to be tested、The data that should be entered and the expected output.A small amount of test data should be selected、Efficient test data for testing as complete as possible;基本目标是：Design a set of test data that finds a bug or class of bugs,Test cases should cover aspects：

1、 正确性测试：Enter user actual data to verify that the system meets the requirements of the requirements specification;测试用 The test points in the example should first be guaranteed to cover at least the functions in the requirements specification,并且正常.

2、 容错性（健壮性）测试：程序能够接收正确数据输入并且产生正确（预期）的输出, 输入非法数据（非法类型、不符合要求的数据、溢出数据等）,The program should be able to give hints 并进行相应处理.Think of yourself as a customer who doesn't know anything about the operation of the product,performing any operation.

3、 完整（安全）性测试：对未经授权的人使用软件系统或数据的企图,系统能够控制的程度,程序的数据处理能够保持外部信息（数据库或文件）的完整.

4、 接口间测试：测试各个模块相互间的协调和通信情况,数据输入输出的一致性和正确性.

5、 数据库测试：依据数据库设计规范对软件系统的数据库结构、数据表及其之间的数据调用关系进行测试.

6、 边界值分析法：确定边界情况（刚好等于、Slightly less than and slightly greater than and just greater than the equivalence class boundary value）,For our system, some legitimate data is mainly entered during the testing process/非法数据,It is mainly selected near the boundary value.

7、 压力测试：输入10A record runs each function,输入30records are run,输入50records are run...进行测试.

8、等价划分：将所有可能的输入数据（有效的和无效的）划分成若干个等价类.

9、错误推测：主要是根据测试经验和直觉,Refer to the errors in the previous software system.

10、效率：完成预定的功能,系统的运行时间（Mainly for databases）.

11、可理解（操作）性：理解和使用该系统的难易程度（界面友好性）.

12、可移植性：在不同操作系统及硬件配置情况下的运行性.

13、回归测试：按照测试用例将所有的测试点测试完毕,Developers of issues found during testing 已经解决,Go to the next round of testing.

14、比较测试：Run a comparison of a similar product that has been released or a legacy legacy product and the tested product at the same time,Or compare with previous test results .

2. 测试用例是否纳入测试基线管理？测试用例发生变更的流程？测试用例如何进行标识？

答：是.There is no change process for test cases

The test case is identified as ST-001This format identifier

3. 什么时候编写测试用例？依据是什么？如何保证测试用例与需求的一致性？Peer review is required吗？

答：After the test plan is completed,Write test cases on schedule.

The basis is the software requirements specification

Use cases are reviewed through peer review,Peer review is required

4. 测试用例如何设计的？

答：Before the design of the test case, it is necessary to read the detailed design document of the development carefully,Fully understand the detailed features of the product,Unclear place to communicate with developers,Understand each function,Be as detailed as possible into the input box、small functions such as buttons,After the function points are clear, use cases are written according to the function module classification.Equivalence classes are used in specific use case design 边界值等黑盒测试方法

5. 如何保证用例覆盖到罕见缺陷？

答：Adequate design time Adequate needs analysis Each function point has use case coverage

Strict review process Guaranteed output is valid

在测试执行过程中 will be based on the actual project situation Add and modify use cases

6. 什么时候编写测试用例？依据是什么？如何保证测试用例与需求的一致性？Peer review is required吗？

答：After the test plan is completed,Write test cases on schedule.

The basis is the software requirements specification

Use cases are reviewed through peer review,Peer review is required

二、 缺陷报告

1. 缺陷报告的优先级别

答：最高优先级：立即修复,停止进一步测试

次高优先级：在产品发布之前必须修复

中等优先级：如果时间允许应该修复

最低优先级：可能会修复,But can also publish

2. 简单概述缺陷报告

答：Now defect reports are generally no longer written in paper documents,Rather, it is a dedicated test management tool（如TestDirector）,This facilitates defect management.在这些工具中,Each defect is entered as a record in the designated defect management system.

3. 缺陷报告包括哪些项？

答：缺陷报告包括：软件名称、版本号、功能模块、缺陷编号、The corresponding use case number、编写时间、编写人、测试员、预期结果、实际结果、缺陷描述、严重级别、优先级别

三、 测试总结报告

1. What items are included in the test summary report？

答：主要是：Summary of the testing process Evaluation of release quality

四、 缺陷（Bug）

1. 软件缺陷的原则

答：A、软件缺陷区别于软件bug,它是在测试过程中出现的对系统有影响的,但是在设计中没有的或者对修改后的bug测试和开发人员有不同意见等

B、软件未达到产品说明书标明的功能.

C、软件出现了产品说明书指明不会出现的错误.

D、软件功能超出产品说明书指明范围.

E、软件未达到产品说明书虽未指出但应达到的目标.

F、软件测试员认为软件难以理解、不易使用、运行速度缓慢,或者最终用户认为不好.

2. 软件缺陷的特征.

1) “看不到”

2) ——软件的特殊性决定了缺陷不易看到

3) “看到但是抓不到”

4) ——发现了缺陷,但不易找到问题发生的原因所在

软件缺陷产生的原因

1) Software product manual（需求）——56%

2) 设计——27%

3) 编写代码——7%

4) 其他——10%

3. 什么是Bug？

答：软件的Bug指的是软件中（包括程序和文档）不符合用户需求的问题.

常见的软件Bug分为以下三类：

没有实现的功能

完成了用户需求的功能,但是运行时会出现一些功能或性能上的问题

Implemented redundant functions that users do not need

4. 缺陷处理流程

答：测试人员提交新的Bug入库,错误状态为New. 高级测试人员验证错误,如果确认是错误,分配给相应的开发人员,设置状态为Open.如果不是错误,则拒绝,设置为Declined(拒绝)状态. 开发人员查询状态为Open的Bug,如果不是错误,则置状态为Declined;如果是Bug则修复并置状态为Fixed.不能解决的Bug,要留下文字说明及保持Bug为Open状态.对于不能解决和延期解决的Bug,不能由开发人员自己决定,一般要通过某种会议（评审会）通过才能认可. 测试人员查询状态为Fixed的Bug,然后验证Bug是否已解决,如解决置Bug的状态为Closed,如没有解决置状态为Reopen.

5. 缺陷的等级划分

答：严重： 系统崩溃 数据丢失 数据毁坏

较严重：Operational error 错误结果 遗漏功能

一般： 小问题 错别字 UI布局 罕见故障

建议：不影响使用的瑕疵或更好的实现

6. 开发人员修复缺陷后,如何保证不影响其他功能？

答：重新执行用例、See if there is an error result.And add new test cases to some related function points around.

7. 状态为已修改的缺陷,实际没有修改怎么办？

答：Strengthen project quality management,Improve project execution capabilities.If the tester finds such a problem,The first thing to do is to figure out what is causing this,Ultimately, it's up to the developers,Fix these issues.If it is a problem that cannot be reproduced or a problem left over from an old version, it cannot be modified to mark.

8. 生产软件的最终目的是为了满足客户需求,我们以客户需求作为评判软件质量的标准,认为软件缺陷（ Software Bug ）The specific meaning includes the following factors

答：

1) 软件未达到客户需求的功能和性能;

2) The software is beyond the scope of the customer's needs;

3) 软件出现客户需求不能容忍的错误;

4) 软件的使用未能符合客户的习惯和工作环境.

五、缺陷评估

评估软件质量的重要指标,通常评估模型假设缺陷的发现是呈泊松分布的;严格的缺陷评估要考察在测试过程中发现缺陷的间隔时间长短.评估要估计软件当前的可靠性并预测随着测试的继续进行,软件可靠性会怎样提高.

SQA Suite 提供四种形式进行缺陷评估：

1) 缺陷分布报告可以生成缺陷数量与缺陷属性的函数.Such as test requirements and status.

2) 缺陷趋势报告可以看出缺陷增长和减少的趋势;

3) 缺陷年龄报告展示一个缺陷处于某种状态的时间长短

4) The test results progress report shows the execution results of the test process in several versions of the application under test

5) 测试周期.

具体步骤

1) 回顾测试日记

2) 评估测试需求的覆盖率

3) 分析缺陷

4) 决定是否达到完成测试的标准,没有满足标准时

5) 再测试

6) 降低标准

7) 确定软件的一个满足标准的子集,看是否可以发布.

感谢每一个认真阅读我文章的人！！！

如果下面这些资料用得到的话可以直接拿走：

1、自学开发或者测试必备的完整项目源码与环境

2、测试工作中所有模板（测试计划、测试用例、测试报告等）

3、软件测试经典面试题

4、Python/Java自动化测试实战.pdf

5、Jmeter/postman接口测试全套视频获取

我个人整理了我这几年软件测试生涯整理的一些技术资料,包含：电子书,简历模块,各种工作模板,面试宝典,自学项目等.如果在学习或工作中遇到问题可以直接进群询问,群里也会有大神帮忙解答,需要的可以找我谢谢.