1、要参与需求评审，评审需求的过程实际也是熟悉业务需求的过程。只有对业务比较熟悉了，才能更好的，更充分的设计出高质量的测试用例。
2、要多阅读文档，其中包括产品策划书、规格说明书、需求文档，接口文档等，我们可以收集一切相关的文档来帮助理解所要测试的产品需要完成的目标。
3、尽量多参加项目组内的会议。比如需求讨论、设计讨论、计划讨论等会议，这样在讨论过程中也能加深对产品的理解。
4、要善于沟通，多和客户、开发、测试人员进行沟通。遇到不明确的问题、有疑问的需求，可以咨询项目负责人或者客户等。这样才能提前解决需求理解偏差等。
5、测试用例名称，也叫测试用例标题，一定要写得简洁、明了，需要用概括的语言描述该用例的出发点和关注点，使得测试人员第一眼看到测试用例名称就能够明白测试用例的目的。用例名称中一般要求不能存在假设性的语句，并且原则上每个用例的名称不能重复。
6、预置条件要明确，包括测试环境、测试数据、测试场景。因为许多BUG只有在特定的环境、特定的场景下才可以重现。没有正确的前提条件，就无法进行后面的测试步骤或无法得到预期的结果。
7、测试步骤描述要简单、清晰，并且要清楚每一个步骤的描述，我们平常的鼠标和键盘的每一动作都代表一个 *** 作步骤。比如：第一步，输入用户姓名；第二步，输入登录密码；第三步，用户点击登录。步骤写的明确时就利于提高用例的可 *** 作性。
8、用例的预期结果要完整而且清晰，并且要将各个输出的结果写出来，包括：返回值的内容、数据库相关字段的记录、界面的响应结果、输出结果的规则符合度、日志的检查和对其它业务影响的检查。
9、测试用例级别要划分清楚，这样在测试执行时有主次之分。
11、评审用例很关键，因为经过测试用例的评审可以发现：用例设计的结段物族构安排是否清晰、合理；是否覆盖所有的需求功能点；是否存在冗余的用例；是否具有很好的可执行性；是否存在对需求理解上的差异等。评审需要项目经理、需求分析人员、架构设计人员、开发人员和测试人员都参与，也需要客户方的开发人员和测试人员。
12、召开测试用例评审会议，在会议上大家可以提问互答，对模糊不清的地方可以进行讨论。这样可以站在不同的角度，站在很多人的思维和思考方式下设计用例。
13、站在用户的角度来设计用例，以用户的使用逻辑及 *** 握弊作习惯为出发点，从用户实际可能的 *** 作场景考虑，一定要脱离系统提供功能。
14、测试用例需要不断更新和维护，不要认为测试用例的设计是一个阶段，测试用例的设计也需要迭代，在软件开发的不同的阶段都要回来重新审视和完善测试用例。并且需要在测试执行时利用发散思维不断的构造和完善测试用例。
总的来说，写出好的测试用例需要我们不断的积累和完善，需要我们不断的在工作中去总结。写出好的测试用例没有简单的公式或规定可以遵循。即使是多年以来在测试方面感兴趣的人也很难做到这一点。
1. 添加F28335.GEL, 文件路径：C:\CCStudio_v3.3\cc\gel\F28335.gel；2. 添加C:\CCStudio_v3.3\MyProjects\WDPT_STEP(DSP)10\Source\DSP2833x_CodeStartBranch.asm文件，此文件负责上电后程序执行顺序跳转的；
3. 修改工程的build option，将LINKER中的Autoinit参数改成：Run-Time Autoinitial；
4. 添加DSP281x_Headers_nonBIOS.cmd文件，用于将DSP28头文件中的外设结构与存储器地址对应起来；
5. 向工程中添加C:\CCStudio_v3.3\MyProjects\WDPT_STEP(DSP)10\F28335.cmd文件，它是用于flash烧纤缓写的困森CMD文件，用于替毁尺模换原有的用于RAM中调试的28335_RAM_lnk.cmd文件。
.global start 定义全局标号.mmregs
.data
.bss x,1 开设全局变量（非初始如槐首化段）
.bss y,1 三个变量各为一个字渣数（16位）
.bss z,1
.text
start:
ST #0f000h,*(x)
ST #0e000h,*(y)
LD #0h,A
ADD *(x),A
ADD *(y),A
STL A,*(z)
xh:
b xh 空明桥循环
.end
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）