修改个人信息测试用例,数据测试是干嘛的
如何编写有效测试用例
测试用例，是一份关于具体测试步骤的文档，它描述了测试的输入参数、条件及配置、预期的输出结果等，以判断被测软件的工作是否正常。
设计、书写和执行测试案例是测试活动中重要的组成部分，测试案例通常由测试案例管理系统或工具进行管理。
测试用例的重要性是毋庸置疑的，它是软件测试全部过程的核心，是测试执行环节的基本依据。测试用例编写应该遵循的原则：
特性：
一个好的测试用例应该具有较高的发现某个尚未发现的错误的可能性，而一个成功的测试案例能够发现某个尚未发现的错误，通常一个好的测试案例有以下特性：
测试用例不可能设计得天衣无缝，也不可能完全满足软件需求的覆盖率，测试执行过程里肯定会发现有些测试路径或数据在用例里没有体现，那么事后该将其补充到用例库里，以方便他人和后续版本的测试。
测试用例的信息有很多，可以根据实际的情况进行增删，一般来说一个优秀的测试用例应该包含以下信息：
这些信息建议可以由测试案例自动生成。
测试级别进行说明：
6.测试类型：功能测试、边界测试、异常测试、性能测试、压力测试、兼容测试、安全测试、恢复测试、安装测试、界面测试、启动/停止 测试、文档测试、配置测试、可靠性测试、易用性测试、多语言测试。
7.预置条件：对测试的特殊条件或配置进行说明
8.测试步骤：详细描述测试过程，案例的操作步骤建议少于15个。
9.预期结果：预期的测试结果
例如：假设目前测试中国移动互联短信网关是否能正确发送短信给中国联通互联网关，测试用例的设计如下：
（1）测试用例ID：TC000001
（2）测试用例名称：中国移动全球通手机用户成功发送短信给中国联通手机用户
（3）测试功能点：中国移动全球通手机用户成功短信给中国联通手机用户，中国联通网关返回成功的状态报告
（4）测试目的：
A、中国移动互联短信网关能否正确处理全球通用户发送给中国联通用户的短信；
B、中国移动互联短信网关能否正确处理中国联通互联短信网关返回成功的状态报告的情况。
（5）测试级别：基本功能测试
（6）测试类型：功能测试
（7）预置条件：各网关实体按照组网图中的关系连接好，各实体之间的连接和通信正常。
（8）测试步骤：
A、中国移动全球通手机用户（13901000001）给中国联通手机用户（13001000001）发送MO短信，内容为“测试”，目的号码填为中国联通手机号码；
B、中国联通互联短信网关把短信下发给中国联通用户成功后，给中国移动互联短信网关返回一个标识成功的状态报告。
（9）预期结果：
A、中国联通手机用户（13001000001）接收到了短信，内容为“测试”，源号码为中国移动全球通的用户号码（13901000001）；
B、在中国移动互联短信网关上产生SMO话单，其中“短消息发送状态”填0（表示成功），“源手机号码”13001000001，“目的手机号码”为13001000001。
下面是一个完整的测试用例的模版：
对一个全新的产品来说，首先需要了解的是产品需求文档和产品模块之间的关系。然后需要从需求文档中书写与所有需求相对应的主路径测试案例和烟雾测试案例， 这个时候也同时会包括一定的基本路径测试案例甚至是详细测试案例。在这个时候，因为对产品没有直接的使用感受，书写测试案例要考虑面广而不要太过精细。继 续阅读产品功能定义文档，将所有的功能定义直接对应写相关的测试案例，这个时候，最好能够对程序的本身有一定的接触，加深对程序的了解，以便写出更好，更 全面的测试案例。最后，在实际测试中，还需要不断扩充，修改以前的测试案例，得到完整的基本功能测试案例和详细测试案例。如果对于一个已有一定或大部分案 例的产品来说，不管测试者是否本身熟悉这个产品，其主要的任务就是阅读，检查需求及相关的变更，然后对原有的案例进行理解，扩充和修改。这就是案例的重用 /复用。设计测试案例的时候，需要有清晰的测试思路，对要测试什么，按照什么顺序测试，覆盖哪些需求做到心中有数。测试用例编写者不仅要掌握软件测试的技 术和流程，而且要对被测软件的设计、功能规格说明、用户试用场景以及程序/模块的结构都有比较透彻的理解。
测试用例设计一般包括以下几个步骤：
1、测试需求分析从软件需求文档中，找出待测试软件/模块的需求，通过自己的分析、理解，整理成为测试需求，清楚被测试对象具有哪些功能。测试需求的特点是：包含软件需求，具有可测试性。
测试需求应该在软件需求基础上进行归纳、分类或细分，方便测试用例设计。测试用例中的测试集与测试需求的关系是多对一的关系，即一个或多个测试用例集对应一个测试需求。
2、业务流程分析软件测试，不单纯是基于功能的黑盒测试，还需要对软件的内部处理逻辑进行测试。为了不遗漏测试点，需要清楚的了解软件产品的业务流程。建 议在做复杂的测试用例设计前，先画出软件的业务流程。如果设计文档中已经有业务流程设计，可以从测试角度对现有流程进行补充。如果无法从设计中得到业务流 程，测试工程师应通过阅读设计文档，与开发人员交流，最终画出业务流程图。业务流程图可以帮助理解软件的处理逻辑和数据流向，从而指导测试用例的设计。
从业务流程上，应得到以下信息：
A、主流程是什么
B、条件备选流程是什么
C、数据流向是什么
D、关键的判断条件是什么
3、测试用例设计
完成了测试需求分析和软件流程分析后，开始着手设计测试用例。测试用例设计的类型包括功能测试，边
界测试，异常测试，性能测试，压力测试等。在用例设计中，除了功能测试用例外，应尽量考虑边界、异
常、性能的情况，以便发现更多的隐藏问题。
黑盒测试的测试用例设计方法有：等价类划分、边界值划分、因果图分析和错误猜测，白盒测试的测试用
例设计方法有：语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、多重条件覆盖。在这里主要讨论黑盒测
试。在设计测试用例的时候可以使用软件测试用例设计方法，结合前面的需求分析和软件流程分析进行设
计：
功能测试：测试某个功能是否满足需求的定义，功能是否正确，完备。
适合的技术：由业务需求和设计说明导出的功能测试、等价类划分
边界测试：对某个功能的边界情况进行测试。
适合的技术：边界值划分
异常测试：对某些功能来说，其边界情况无法简单的了解或某些操作不完全是正确的但又是可能发生的，
类似这样的情况需要书写相关的异常测试。
适合的技术：由业务需求和设计说明导出的特殊业务流程、错误猜测法、边界值分析、内部边界值测试、
性能测试：检查系统是否满足在需求中所规定达到的性能，性能主要包括了解程序的内外部性能因素。内部性能因素包括测试环境的配置，系统资源使用状况；外部因素包括响应时间，吞吐量等。
适合的技术：业务需求和设计说明导出的测试
压力测试：压力测试又称强度测试，主要是检查系统运行环境在极限情况下软件运行的能力，比如说给一个相当大的负荷或网络流量给应用软件兼容测试：测试软件产品在不同的平台，不同的工具，相同工具的不同版本下功能的兼容性。
4、测试用例评审
测试用例设计完成后，为了确认测试过程和方法是否正确，是否有遗漏的测试点，需要进行测试用例的评审。
测试用例评审一般是由测试leader安排，参加的人员包括：测试用例设计者、测试leader、项目经理、开发工程师、其它相关开发测试工程师。测试用例评审完毕，测试工程师根据评审结果，对测试用例进行修改，并记录修改日志。
5、测试用例更新完善
测试用例编写完成之后需要不断完善，软件产品新增功能或更新需求后，测试用例必须配套修改更新；在测试过程中发现设计测试用例时考虑不周，需要对测试用例 进行修改完善；在软件交付使用后客户反馈的软件缺陷，而缺陷又是因测试用例存在漏洞造成，也需要对测试用例进行完善。一般小的修改完善可在原测试用例文档 上修改，但文档要有更改记录。软件的版本升级更新，测试用例一般也应随之编制升级更新版本。测试用例是“活”的，在软件的生命周期中不断更新与完善。
谈谈如何做好测试用例评审
开篇先来说说，什么是测试用例评审？测试用例评审是通过测试人员组织用例评审会议，邀约项目相关人员，主要包括产品，开发及测试三方，对测试人员设计的测试用例的可执行性和全面性进行评估，同时消除各方对需求文档理解的偏差达到对需求理解的一致。
测试用例评审是测试流程中极为关键的一环，用例评审何为如此重要？首先，通过测试用例的评审不仅可以消除产品、开发、测试三方对需求文档理解的偏差，还可以保证测试内部人员，即测试执行者和测试用例设计者在测试质量保障方面保持一致性；其次，通过测试用例评审，产品和开发可以通过对用例合理性和全面性进行评估，指出用例设计不合理或遗漏之处，以便更好的完善测试用例，提高测试用例的质量。再者，如果囿于各种限制条件导致开发无法展开技术评审会议，那么在用例评审也可以和开发沟通确认实现方式，关注不同实现方式的测试点，以实现全面测试；最后，常言道，测试人员是项目的前灯，是一个探路的角色，所谓良医治未病，那么测试人员就应该在项目前期多挖掘潜在的坑，并提醒开发注意，慎防掉坑，同时也降低了bug出现的概率，减少开发测试成本。
说了这么多，那么测试用例评审该如何评审呢？个人认为可以从以下几个步骤来组织实行测试用例的评审工作。
1.首先，测试人员提前准备好用例评审的资料，提前定好会议室发出会议邀约并附上用例评审资料
测试用例评审最好以Xmind脑图的形式进行，脑图可以清晰的展示用例的设计思路和关键信息，让参与评审的人员可以一目了然，能更快的捕获到用例设计者要表达的思想，降低阅读成本，提高会议效率。脑图需要包含全部用例的设计思路及测试功能点，并重点标注出有疑问的测试点。在评审前一天提前发出给相关与会人。
2.开始用例评审，会议组织者即测试人员做好会议记录，并标注清楚需要修改的用例内容
用例评审很多人会走进一个误区，就是对着测试用例Excel列表，在会议上逐条逐字的念一遍，如此一次用例评审时间不到2个小时肯定结束不了，其实这种做法是很不科学的,不仅浪费时间还不能达到完善用例的目的。有研究表明成人的注意力高度集中只能维持约20分钟，如何把握住这20分钟让用例评审会议高效有收获？那就只能挑重点讲，对于已经明确的测试点也可一语带过，主要挑存疑需要三方共同确认的功能点讲，所以第一步在评审资料准备时要求在Xmind标注出存疑的测试点，就是在这个时候就派上用场的。
另外，在评审过程中，如果对技术实现方案有疑问的也要提出来和开发确认，比如，哪些数据是从接口获取的，哪些数据是从其他页面的接口请求带过来的，哪些是前端写死的；哪些页面有必要实时刷新，哪些页面无需已进入就刷新。如果对于实现方式存在不合理之处可以提出可行的实现建议供开发开发参考。对于开发可能考虑遗漏的功能点或细节及时在会议上提醒，可从根源上遏制bug的出现，比如开发可能会忘记考虑防重点击的处理、一些特殊的异常逻辑处理等。
评审过程中，测试人员要做好会议纪要，如果用例有需要补充或修改的地方快速在Xmind上标注清楚，便于会后进行整理补充测试用例。
3.用例评审会议后整理完善测试用例并再次同步
用例评审会议后测试人员根据会议上各方建议进行测试用例的修改完善，再将整理补充后的用例同步给项目相关人员，是具体情况确定是否有必要进行二轮评审。若无其他问题则将用例整理后即可导入用例系统以供测试执行时使用。
python单元测试引入unittest模块后一个类里面包含多个方法怎么只让se...
不是有一个全局的setup和teardonw吗
@classmod
def tearDownClass(cls): # 必须使用 @ classmod装饰器, 所有test运行完后运行一次
print('4444444')
@classmod
def setUpClass(cls): # 必须使用@classmod 装饰器,所有test运行前运行一次
print('33333')
在PRD 文档提到的「测试用例」是什么意思? 一个完整的产品需求文档大概...
个人观点：用例图的目的是对系统进行业务建模，具体一点就是用户对系统进行的一项功能性需求描述，可以直观的表达用户使用系统的业务目的，所以用例包含了参与者（用户或者其他系统）、需求描述；因此，一个用例需要具备以下特征：1能完整的表达用户的需求或者目的（比如atm机“存钱”是用户的目的，就表达一个完整的用例，而存钱过程中的插卡、点钞就不是用户的完整意愿，只是存钱用例的一部分流程）；2、必须包含参与者即系统的真实用户或系统；3、动宾短语形式的描述；至于你提到的另一个问题则涉及到明确用例粒度的划分，在业务建模阶段仍然是以用户表达完整的业务需求为标准，比如“管理信息”可以作为用例，但管理信息包含“新增信息”“删除信息”“修改信息”三个用例，如果用户的目的是管理信息则可以用一个用例（这类描述有利于用户需求的扩展，这一点可以自己思考），如果用户准确到具体的操作则可以使用三个细化的用例。就看产品经理的具体选择了，最终目标还是能完整表达用户业务场景。以上属于个人拙见，请甄别采纳。
软件测试主要做什么工作?
软件测试，在专业上区分，也是有所区分的，分黑盒和白盒测试两种，白盒测试一般在一些大的软件工程项目里面使用得到，要求的技术层次相对较高，基本上是半个以上研发人员的技术水平要求。（具体两者区分可以自行百度）这里具体说说软件测试中，两种测试工种的工作内容。
白盒测试，往往要直接接触程序的源代码，所以白盒测试人员任职的一个很重要的条件就是读懂对应开发语言，最好是半个以上的开发人员。
黑盒测试，则没有要能读懂程序源代码要求（当然有软件开发这方面知识的更佳），黑盒测试人员的要求往往更侧重测试人员对软件测试理论和对应行业了解。
现在很多的测试人员对于白盒测试这个工作近乎有一种膜拜的心态，个人觉得没有必要。做你喜欢做的，做你最擅长做的，坚持你所做的，我想最后被人膜拜的人就是你。
两者在工作的内容上存在相同之处也存在不同之处。
相同之处在于：都要进行测试用例设计，也都要执行测试用例，报告缺陷。
不同之处在于：白盒测试人员是在能看到程序内部实现、及程序需求的情况下进行的测试用例设计，而黑盒测试人员只能通过程序的需求文档进行测试用例设计；往往黑盒测试用例的量相对白盒测试而言要多一些。
软件测试中,数据流测试方法主要用于对什么进行测试
数据流测试可理解为‘流程性’测试；即数据在整个系统内全部流向的测试。
主要测试方法使用‘因果图法’
概念：
因果图法是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件的各种组合情况。
因果图法的应用：
等价类划分法和边界值分析方法都是着重考虑输入条件，但没有考虑输入条件的各种组合、输入条件之间的相互制约关系。这样虽然各种输入条件可能出错的情况已经测试到了，但多个输入条件组合起来可能出错的情况却被忽视了。
如果在测试时必须考虑输入条件的各种组合，则可能的组合数目将是天文数字，因此必须考虑采用一种适合于描述多种条件的组合、相应产生多个动作的形式来进行测试用例的设计，这就需要利用因果图（逻辑模型）。
采用因果图法设计测试用例的步骤：
1) 分析软件规格说明描述中, 那些是原因(即输入条件或输入条件的等价类),那些是结果(即输出条件), 并给每个原因和结果赋予一个标识符。
2) 分析软件规格说明描述中的语义，找出原因与结果之间, 原因与原因之间对应的关系，根据这些关系,画出因果图。
3) 由于语法或环境限制, 有些原因与原因之间,原因与结果之间的组合情况不可能出现，为表明这些特殊情况, 在因果图上用一些记号表明约束或限制条件。
4) 把因果图转换为判定表。
5) 把判定表的每一列拿出来作为依据,设计测试用例。