每个公司的软件测试工作流程也许会有些许不同,但大体上都不会有太大的误差,根基上包罗需求评审、拟定测试打算、设计测试用例、用例评审、测试执行、撰写测试陈述等文档,下面就来看看吧!
需求评审:
不管是自研产物或其他产物,测试人员都要加入需求评审的会议。一方面,便于领会需求进而更好地开展之后的测试工作;另一方面,测试人员往往是从用户角度考虑居多,加倍可以或许从用户的角度提出合适现实的建议。
拟定测试打算:
待需求最终确定下来后,则可以起头拟定测试打算,确定测试方针、测试规模、测试方式、测试策略、资本放置、风险评估等。
测试用例设计:
待测试打算拟心猿意马好后,可起头进行用例设计。一般先利用思维导图东西清算大要框架,再利用测试用例办理东西(如testlink)按功能模块、利用场景进行设计。
测试用例评审:
因为一小我的思惟是有局限性的,待用例设计好后,最好项目组的所有人员(产物司理、研发人员、测试人员)都介入用例评审,以便查漏补缺,尽可能利用例笼盖更周全。
冒烟测试:
待研发人员提交版本后,测试人员便可以进行冒烟测试(当然,冒烟测试的用例要提前选好)。
一轮测试:
待冒烟测试经由过程,则可以起头执行第一轮的测试。发现的bug利用缺陷办理东西(如jira/redmine/禅道等)记实下来。
N轮测试:
若是有需要,则进行第二轮、第三轮、第N轮的测试。
回归测试:
待研发人员把本次需修复的bug都修复完当作后(并纷歧心猿意马是所有bug都需要修复,有些推迟的、有些被鉴定为不是bug的、有些影响不大的都可以临时不修复),即可进行回归测试。本家儿如果验证缺陷是否真的修复,是否会影响现有系统的利用。
撰写文档:
之后就可以起头撰写测试陈述、用户手册等相关文档。测试陈述要能反映本次测试的方针、规模、对象、执行过程即结论和风险阐发。
0 篇文章
如果觉得我的文章对您有用,请随意打赏。你的支持将鼓励我继续创作!